VeriSign OTP Credential Provisioning Protocol For Trusted Devices Technical Specification v6

VIP OTP Credential Provisioning Protocol for
Trusted Devices
Verisign Technical Specification Document
Version: 65.0
Last updated: 12/1073/2010
VeriSign, Inc. CONFIDENTIAL Page 1 Version: 6.0Version: 5.0

VIP OTP Credential Provisioning Protocol for Trusted Devices Verisign Technical Specification Document
© 2010 VeriSign, Inc. All rights reserved.
Printed in the United States of America
Trademark Notices
VeriSign and VIP are registered trademarks of VeriSign, Inc. The VeriSign logo, VeriSign Trust Network, and Go Secure! are
trademarks and service marks of VeriSign Inc. Other trademarks and service marks in this document are the property of their
respective owners.
No part of this publication may be reproduced, stored in or introduced into a retrieval system, or transmitted, in any form or by
any means (electronic, mechanical, photographic, audio, or otherwise) without prior written permission of VeriSign, Inc.
Change History
Date Name Reviewers Description

06/01/2010 Mingliang Pei Initial version.
06/17/2010 Mingliang Pei Incorporated feedbacks from several partners. Support
HMAC-SHA1 and AES-128 with either CBC or CTR mode. A
test vector is added.
08/05/2010 Mingliang Pei Added description about application key delivery XML format
and updated VIP service message schema.
08/11/2010 Mingliang Pei Added test server information. Added error code list;
changed to use token prefix VSFS.
12/07/2010 Mingliang Pei Changed test server URL. Added production application key
transport certificate.
12/13/2010 Mingliang Pei Updated schema to include <Platform> element.

Verisign Technical Specification Document VIP OTP Credential Provisioning Protocol for Trusted Devices
Contents
1 Overview............................................................................................................................ 4
2 Terminologies..................................................................................................................... 4
3 Provisioning Flow Specification.......................................................................................... 5

3.1 Register an OTP client application ID and share applications keys with VeriSign.......6
3.1.1 Application Key ID....................................................................................................... 6
3.1.2 Application Keys.......................................................................................................... 7
3.1.3 Key registration process and data format....................................................................8
3.2 Acquire an OTP Credential from VIP Provisioning Protocol......................................10
3.2.1 Client Authentication.................................................................................................. 11
3.2.2 OTP secret encryption method by the VIP service....................................................12
3.2.3 OTP secret data integrity check method....................................................................13
3.2.4 Processing encrypted VIP service response message..............................................14
3.3 VIP Protocol Messages............................................................................................. 14
3.3.1 GetSharedSecret....................................................................................................... 14
3.3.2 GetSharedSecretResponse.......................................................................................16
3.3.3 Error Codes............................................................................................................... 18
4 Protect the function call that generates OTP....................................................................18
5 Test environment............................................................................................................. 19
6 Appenix A: Application Key Registration XML Schema....................................................19
7 Appendix B: VIP Provisioning Protocol Message Schema...............................................20
8 Appendix C: Test VeriSign Key Transport Certificate.......................................................22
9 Appendix D: Test Code.................................................................................................... 23

1 Overview
This document describes the high level VIP OTP credential provisioning protocol for third party trusted
devices that can provide end-to-end authentication with a shared application key with VIP service.
The main target of the supported devices is the secure fingerprint sensors. A fingerprint sensor is
generally able to embed a symmetric key and performs symmetric key based cryptographic functions
such as AES and HMAC. Such a device usually lacks support of PKI functionalities that the current VIP
provisioning protocol requires. Only some advanced sensors may support PKI functions.
In this document, we expand VIP OTP credential provisioning protocol to support shared symmetric key
based authentication method. The existing VIP provisioning protocol supports a third party organization
to acquire an activation code after it authenticates an end user. An end user or client can acquire an OTP
credential with an activation code.
In the new symmetric key based authentication scenario, a device manufacturer shares two global
application keys with VIP service: one for authentication and one for response encryption by the VIP
service. The global application keys must only be known to the secure devices and only used within the
device for any cryptographic functions so that a client application running outside of the device will
never be able to get the raw clear OTP seed at any time during and after provisioning. This effectively
mitigates the risk where a malware client acquires an OTP credential from VIP service and then makes a
copy of OTP seed.
Additional client side security steps are recommended to ensure proper protection and use of the OTP
credential.
2 Terminologies
Terminology Definition
OTP One Time Password.
OTP Credential The data that represents an OTP token and contains at least an
identifier, a shared secret and an OTP algorithm that uses the shared
secret and some moving factor to derive an OTP.

OTP Secret The shared secret value in an OTP credential. It is 20-byte long.
OTP Algorithm The formula to derive an OTP. According to the moving factor choice,
there is the so-called event based and time based algorithms. HOTP
algorithm is a standard event based OTP algorithm defined in RFC, and
TOTP is time based variant of HOTP.
VIP Provisioning The OTP credential provisioning API service as part of VeriSign
Service Identity Protection (VIP) Authentication Service.
3 Provisioning Flow Specification

The VIP OTP credential provisioning flow for a trusted device vendor involves the following steps.
1. Register an application ID and share applications keys with VeriSign. A device manufacturer
registers its OTP client application at VeriSign to get a unique application ID for its application.
The manufacturer securely sends VeriSign two application keys that will be only securely used
within its devices for the registered application.
2. Acquire a credential from the VIP service - the OTP client application handles OTP credential
provisioning according to VIP provisioning web service specification described in this
document. The client relies on the secure device for authentication data generation and
decryption of OTP seed received from the VIP service. The client won’t be able to decrypt and
get the raw OTP seed at any time.
3. Generate an OTP - the OTP client application can request an OTP from the underlying device,
which may generally protect the call with some kind of user authentication such as finger print
swipe match.

Device
Manufacturer VeriSign
Application
ID pp
er A
Registration
Regist ys
1. K e
Information with
1.2
CS
Re
Encrypted
gis
t
Application Keys
er
rive Device Key
Ke
(K_ENC, K_AUTH)
De eys
0.
y
Management
pK
s
Ap
VIP
Key Encryption
Key Manager
VIP
edential
2. Get OTP Cr Service
OTP Client
Application
VIP
Credential
Device DB
Encrypted
OTP Credential
In the following sections, we describe each of the above steps in more detail.
3.1 Register an OTP client application ID and share applications keys with VeriSign
3.1.1 Application Key ID

An application Key ID will be used in the provisioning protocol for VIP service to locate the proper
keys that the manufacturer shared with VeriSign for authentication of the client and encryption of an
OTP seed to be replied. An application Key ID will be assigned by VeriSign upon the manufacturer’s
request.
The following information needs to be sent from a manufacturer for its OTP application ID registration:
 Manufacturer name (e.g. Acme Inc.)

 Application name (e.g. Acme OTP Client for Fingerprint Sensor)
Upon receiving the information, VeriSign will try to use the application name as the key ID for future
key lookup when it is sent in a request. If the value isn’t unique, VeriSign will assign a unique

application key ID for the client application. An application key ID is case insensitive to the VIP
service.
A client application needs to send the application key ID in each OTP credential provisioning request.
3.1.2 Application Keys

Two symmetric keys are shared between a set of devices and VIP provisioning service to ensure end-to-
end security. The two keys can be derived by a manufacturer from a global root secret key that is
embedded in its devices. The key derivation algorithm is up to the manufacturer to define. It is
recommended that the keys are not shared between different applications. A new set of keys should be
used for a different application from the OTP application.
The two keys must meet the following specifications.
 K_AUTH: an authentication key that will be used as the MAC key for HMAC-SHA1. The key
size should be 160 bits. The key is expected to consist of strong random data. If it is derived
from some other global key, the key derivation should ensure strong entropy for its result.
 K_ENC_KD: an encryption key derivation key that will be used to derive encryption session
keys. A different session encryption key derived from this root encryption key will be used to
protect each OTP secret in transport from VIP provisioning service to a client device. The key
derivation method is HMAC-SHA1. The K_KDF is used as the MAC key. Its size should be
160-bits.
The HMAC-SHA1 algorithm can be replaced with more secure HMAC-SHA-256 for vendors whose
device can support the algorithm. In this case, the key size for both above application keys should be 32
byte long. For the initial phase, only HMAC-SHA1 will be supported. Note that the known vulnerability
about SHA1 doesn’t apply to HMAC algorithms, see http://www.openauthentication.org/pdfs/Attacks
%20on%20SHA-1.pdf. The security strength of HMAC-SHA1 is sufficient.
The encryption key algorithm will be AES-128 with either CBC or CTR (the counter) mode. The VIP
provisioning protocol allows a client to specify a preference of the encryption algorithm. See section
3.2.2 for detail.

3.1.3 Key registration process and data format

To securely send the keys to VeriSign, the key provider (a manufacturer) should send the keys in an
encrypted form. The keys MUST be encrypted with a VeriSign designated RSA public key such that the
keys will be only known to the key provider system and VeriSign VIP provisioning service system that
hosts the corresponding RSA private key. The encrypted keys and other related registration information
MUST be included in an XML document published by VeriSign as follows. The manufacturer sends
XML document to VeriSign contact via email.
The key registration XML data schema is the following.
<xs:complexType name="OTPClientAppKeyRegistrationType">
<xs:annotation>
<xs:documentation>The top element for application key information shared
between OTP devices and VeriSign.</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="Manufacturer" type="xs:string"/>
<xs:element name="Platform" type="xs:string"/>
<xs:element name="ApplicationKeyID" type="xs:string"/>
<xs:element name="Description" type="xs:string"/>
<xs:element name="EncryptionKey" type="ds:KeyInfoType" minOccurs="0"/>
<xs:element name="EncryptedAuthKey" type="xs:base64Binary"/>
<xs:element name="EncryptedEncKey" type="xs:base64Binary"/>
<xs:element name="CreationDate" type="xs:dateTime" minOccurs="0"/>
<xs:element name="StartDate" type="xs:dateTime" minOccurs="0"/>
<xs:element name="ExpiryDate" type="xs:dateTime" minOccurs="0"/>
<xs:element name="Mac" type="vipk:MacType" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="MacType">
<xs:annotation>
<xs:documentation>The type represents MAC information.</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="EncryptedMacKey" type="xs:base64Binary"/>
<xs:element name="Mac" type="xs:base64Binary"/>
</xs:sequence>
<xs:attribute name="MacAlgorithm" type="xs:anyURI" use="required" />
</xs:complexType>
where
 Manufacturer – the name of the application key provider

 Platform – the device type information. For finger print sensors, it can be “FingerPrintSensor”.

 ApplicationKeyID – the application name that is associated with the key. It should be unique
such that it can be readily used to look up the key. A manufacturer may have multiple keys for
the same application on different device models. A different application key ID value should be
used for each different key set. The value should be UTF-8 encoded string and should try to use
7-bit ASCII value as much as possible. If it appears to be not unique when it is submitted to
Verisign, VeriSign will assign a unique key ID for the client to use.
 Description – additional description information about the key and application for reference
purpose. It is optional.
 EncryptionKey – the certificate that is used to encrypt the keys should be placed here. If it is
omitted, the VIP production certificate will be assumed.
 EncryptedAuthKey – the encrypted data of K_AUTH.
 EncryptedEncKey – the encrypted data of K_ENC_KD
 CreationDate – the time when the key set was derived. It is optional.
 StartDate – the expected time when the key set should be first used. It is optional.
 ExpiryDate – the expected expiry time when the key set should be stopped for further use. It is
optional.
 Mac – the MAC data over the message content for data integrity check purpose. It is optional.
o MacAlgorithm – the MAC algorithm that is used for MAC generation. By default, it
should be http://www.w3.org/2000/09/xmldsig#hmac-sha1.
o EncryptedMacKey – a randomly generated MAC key is encrypted by the same certificate
that is used to transport the K_AUTH in the main message.
o Mac – the MAC value that is generated with the MAC key over the message content C
where
 C = concatenation of values of each preceding element. Each element value is
UTF-8 encoded before it is concatenated.
Example:
<?xml version="1.0" encoding="UTF-8"?>

<vipk:OTPClientAppKeyRegistration xmlns:vipk="http://schema.verisign.com/vip/key"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance" xsi:schemaLocation="http://schema.verisign.com/vip/key vipclientappkey.xsd">
<vipk:Manufacturer>Acme Inc.</vipk:Manufacturer>
<vipk:Platform>FingerPrintSensor</vipk:Platform>
<vipk:ApplicationKeyID>Acme OTP Client for Fingerprint Sensor</vipk:ApplicationKeyID>

<vipk:Description>The key is derived from global key in Acme's fingerprint

sensors</vipk:Description>
<vipk:EncryptionKey>
<ds:X509Data>
<ds:X509Certificate>
MIIDyzCCArOgAwIBAgIQIZrIfQCG9bY4x70XD2FCQTANBgkqhkiG9w0BAQUFADBO
MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xJjAkBgNVBAMT
HVZJUCBBdXRoZW50aWNhdGlvbiBTZXJ2aWNlIENBMB4XDTA5MDIxOTAwMDAwMFoX
DTExMDIxOTIzNTk1OVowXTEcMBoGA1UECwwTUGFydG5lciBWSVAgTWFuYWdlcjEX
MBUGA1UECgwOVmVyaVNpZ24sIEluYy4xJDAiBgNVBAMMG1BhcnRuZXIgVklQIE1h
bmFnZXIgUkEgMjAwOTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAqOyZMI0E
VH8TmMZ6BYW3hb4Nz9clukOykahNhwKdQEV/G63mMcrzVCCLsYeSF1Ks1fJccgaJ
A4cK9oJrrLast5Mq5//v9FfGucrercyH7rDsPGk+g1QxygpE9Lw8AkTSK9C3tbgV
wzngtMYz9VUqaIQVibc1PHbvHBaRwjN9lm0CAwEAAaOCARgwggEUMAkGA1UdEwQC
MAAwCwYDVR0PBAQDAgWgMGAGA1UdHwRZMFcwVaBToFGGT2h0dHA6Ly9vbnNpdGVj
cmwudmVyaXNpZ24uY29tL1ZlcmlTaWduSW5jVklQQXV0aGVudGljYXRpb25TZXJ2
aWNlL0xhdGVzdENSTC5jcmwwHwYDVR0jBBgwFoAUZiuI19oojLzejQJfMqApZcRK
rpIwHQYDVR0OBBYEFM0K7IYp9JfQCV39drQDQsRwNwcYMBEGCWCGSAGG+EIBAQQE
AwIHgDATBgNVHSUEDDAKBggrBgEFBQcDAjAwBgpghkgBhvhFAQYLBCIWIGFlMTMy
YTVjN2QyNDJhMDczMDZmMzI2YjNhOWQ0ZTI3MA0GCSqGSIb3DQEBBQUAA4IBAQAv
ZFNTRJAi/cK7npTO3V/4601ZU1ESeATKam0fkBFpx0xOz/kSXyT1tV5BG4DJel5h
B5BHCfS3fWnTEd/uF8i+Azv7GChBuyzldWdYvhOjWIFoX1mJUeDNfuVOa1whxRxw
f1HTJc1yNTLdtuZadZX6hUIJ2rdNtIO0C4oyO/l91dLebYVqbKx0eLznIWOP/dd6
aVUrh2ZRM2YA6o8jQu91o9rn2GviOWBFwY18mSXW8guiGv2uREv8BUy9Mos9D5P9
BSpxDVBr8zLANxYzAe2F4GGe2JmPejEd9pf5lQXsapKTbyVrfAB0xin+aBAzse06
yW3ykIfognE+mSetqmvV
</ds:X509Certificate>
</ds:X509Data>
</vipk:EncryptionKey>
<vipk:EncryptedAuthKey>
Eh8+YvlDHHkhZ4HCXl7kXvvdJuoaOeOtxJvNnj0EYbOjzO8XAgPreBMru5wnMdTx/JnzCCIYpfNtbfmb9F0oEavJwzy5C
YKnjyBYYUBeJPQTG7iFpPULu/cBKxLpab2r5/kOT0OK37OeKGVMicF2/Kg4KbBC6OFyzLw5fiik5Cw=
</vipk:EncryptedAuthKey>
<vipk:EncryptedEncKey>
hJ+fvpoMPMO9BYpK2rdyQYGIxiATYHTHC7e/sPLKYo5/r1v+4xTYG3gJolCWuVMydJ7Ta0GaiBPHcWa8ctCVYmHKfSz5f
deV5nqbZApe6dofTqhRwZK6Yx4ufevi91cjN2vBpSxYafvN3c3+xIgk0EnTV4iVPRCR0rBwyfFrPc4=
</vipk:EncryptedEncKey>
<vipk:CreationDate>2010-08-05T00:00:00Z</vipk:CreationDate>
<vipk:StartDate>2011-01-01T00:00:00Z</vipk:StartDate>
<vipk:ExpiryDate>2020-12-31T00:00:00Z</vipk:ExpiryDate>
</vipk:OTPClientAppKeyRegistration>
3.2 Acquire an OTP Credential from VIP Provisioning Protocol

VIP Provisioning Service is a web service that supports SOAP and plain XML messages. An OTP client
application can make the web service API call of type <GetSharedSecret> as specified in VIP WSDL
file to acquire an OTP secret.
One of the main characteristics of the API is about request authentication and response encryption. This
document mainly focuses on these two aspects while the rest message specification may refer to the
existing VeriSign VIP developer guide.

3.2.1 Client Authentication

An OTP client application must generate and include the derived authentication data in every request to
VIP web service for acquiring an OTP credential. The client authentication data must be calculated with
the following formula.
Client_Auth_Data = HMAC-SHA1(K_AUTH, <application_id> | <nonce> | <timestamp>)
where
 K_AUTH is the authentication MAC key that is known to devices and previously registered
at VIP service
 ‘|’ indicates data concatenation
 application_id is the registered client application ID at VeriSign.
 nonce is a 16 byte long randomly generated data in a device
 timestamp indicates the current Unix time (i.e. the number of seconds elapsed since midnight
UTC of January 1, 1970), for example, 1276623728. The decimal character string data will be
used in the data concatenation.
Example:
Assume that
 K_AUTH = 0x3132333435363738393031323334353637383930
 application_key_id = “Sensor Manufacture X OTP Client”
 nonce = 0x31323334353637383930313233343536
 timestamp = “2000000000” where the corresponding UTC time string is “2033-05-18 03:33:20”
we have the following data output

 Concatenated input data in hex format:
o 53656e736f72204d616e75666163747572652058204f545020436c69656e7431323334
35363738393031323334353632303030303030303030

 Client_Auth_Data = 0x688fcb668536380deb9d43f038b42b10042ac9d4
The authentication data computation must be performed within a device instead of a software client
application. The device should also protect the method call before it generates the HMAC data. Both
requirements are necessary and important for mitigating the risk that any client could freely call the
device API to get valid authentication data and subsequently obtain OTP credential from VIP service. If
a software client were able to compute the authentication data, a malware client could discover the key
K_AUTH and acts if it is a vendor’s client when communicating with VIP service.
3.2.1.1 Security practice recommendations for finger print sensors

When a fingerprint device is used, two layers of API call protection on the authentication data
generation may be used, namely,
 Client software authentication by the device

 User fingerprint match
3.2.2 OTP secret encryption method by the VIP service

The VIP service includes an encrypted OTP secret value along with other OTP credential attributes in its
response message for a successfully authenticated OTP credential provisioning request. The raw OTP
secret value is encrypted with the encryption method AES in CBC or CTR mode. The encryption key,
called the session encryption key (K_ENC_S), is a 128-bit long AES key derived from the device
manufacturer shared application encryption key K_ENC_KD. The key derivation function KDF uses
HMAC-SHA1 as follows.
K_ENC_S = Truncate(HMAC_SHA1(K_ENC_KD, nonce | timestamp))
where the nonce and timestamp data are the ones received from a provisioning request. The truncate
keeps the first 16 bytes of the 20 byte output from the HMAC-SHA1.
The VIP provisioning service encrypts an OTP secret with the AES algorithm using the key K_ENC_S.
Encrypted_OTP_Secret = AES-128(K_ENC_S, <OTP secret>)

where the AES encryption must use either CBC or CTR mode. A client can specify its choice in a
provisioning request message, see section 3.3.1 for detail. The IV value (16 byte long) is prepended to
the AES encrypted data when it is included in the VIP response message.
Example:
Assume the sample nonce and timestamp value in the early example and the following data
 K_ENC_KD = 0x3031323334353637383930313233343536373839
 IV = 0x31323334353637383930313233343536
 OTP Secret = 0x3132333435363738393031323334353637383930
we have the following

 K_ENC_S = 0x8610ba57f42bd7a39af72f917de58b0a
 Encrypted_OTP_Secret with CTR mode = 0xaef6804af77fede72e827f5678c21c1d71c99433
 Encrypted_OTP_Secret with CBC mode =
0x85c4bc62d4df6dc7ba3835edc96cd4350cf0443fd119606d11ccde8a27c9be10
3.2.3 OTP secret data integrity check method

When an OTP secret is returned from the VIP service, a MAC value over the OTP secret is included for
a client to verify the data integrity. The MAC key uses the pre-shared authentication key K_AUTH as
follows.
OTP_Secret_MAC = HMAC-SHA1(K_AUTH, <OTP secret>)
Example:
Assume the sample data in the above examples, we have the following output data.
 OTP_Secret_MAC = 0x190709f411e63ac5abf0fd1f06afe80a654bcf49

3.2.4 Processing encrypted VIP service response message

Upon receiving a successful response message from the VIP Provisioning Service for a request, an OTP
client performs the following actions.
1. Parse the XML response message

2. Extract OTP credential information including credential ID and the encrypted OTP secret, and
the OTP secret MAC value.
3. Pass the encrypted OTP secret data to the underlying device
4. The device derives session encryption key with the encryption key associated with the client
application and decrypts the encrypted data. It computes MAC data over the raw secret value
with the associated authentication key. Upon successful check, it re-encrypts the raw secret data
with the device specific key that is embedded in the device.
5. The device returns the encrypted OTP secret value to the client application.
6. The client application stores the encrypted OTP secret value and other OTP credential attributes
in the hosting computer.
3.3 VIP Protocol Messages
3.3.1 GetSharedSecret
This message is used to request an OTP credential from the VIP service. It contains a token ID prefix
that can be the one assigned to the manufacturer or VeriSign standard one for the class of devices. The
authentication data is required for each request. The message also contains additional information about
the client and requested OTP credential type.
Example 1: Request an OTP secret using AES encryption in CBC mode

<GetSharedSecret xmlns="http://www.verisign.com/2006/08/vipservice" Id="1234abcd"
Version="1.0">
<TokenModel>VSFS</TokenModel>
<OtpAlgorithm type="HMAC-SHA1-TRUNC-6DIGITS"/>
<SupportedEncryptionAlgorithm>AES128-CBC</SupportedEncryptionAlgorithm>
<DeviceId>
<Manufacturer>Sensor Manufacturer X</Manufacturer>
<SerialNo>XA1234</SerialNo>

<Model>SPH-A900</Model>
</DeviceId>
<Extension xsi:type="DeviceProvisionInfoType">
<Platform>HP Commercial</Platform>
<ApplicationID>Sensor Manufacture X OTP Client</ApplicationID>
<Nonce>MTIzNDU2Nzg5MDEyMzQ1Ng==</Nonce>
<ClientTimestamp>2000000000</ClientTimestamp>
<AuthenticationData>aI/LZoU2OA3rnUPwOLQrEAQqydQ=</AuthenticationData>
</Extension>
</GetSharedSecret>
where
 TokenModel – a token ID manufacturer code registered at OATH. It is used as token ID prefix

for the issued VIP credential.
 OtpAlgorithm – default value HMAC-SHA1-TRUNC-6DIGITS to indicate that the VIP credential should
use TOTP algorithm with HMAC and generates 6-digit OTP
 SupportedEncryptionAlgorithm – indicates the preferred encryption algorithm for the OTP secret
protection in the response message
 Platform – an optional field that indicates the underlying computer platform where the OTP
application runs
 ApplicationID – the application key ID registered at VeriSign for the devices
Example 2: Request an OTP secret using AES encryption in CTR mode

<GetSharedSecret xmlns="http://www.verisign.com/2006/08/vipservice" Id="1234abcd"
Version="1.0">
<TokenModel>VSFS</TokenModel>
<OtpAlgorithm type="HMAC-SHA1-TRUNC-6DIGITS"/>
<SupportedEncryptionAlgorithm>AES128-CTR</SupportedEncryptionAlgorithm>
<DeviceId>
<Manufacturer>Sensor Manufacturer X</Manufacturer>
<SerialNo>XA1234</SerialNo>
<Model>SPH-A900</Model>
</DeviceId>
<Extension xsi:type=”DeviceProvisionInfoType”>
<Platform>HP Commercial</Platform>
<ApplicationID>Sensor Manufacture X OTP Client</ApplicationID>
<Nonce>MTIzNDU2Nzg5MDEyMzQ1Ng==</Nonce>
<ClientTimestamp>2000000000</ClientTimestamp>
<AuthenticationData>aI/LZoU2OA3rnUPwOLQrEAQqydQ=</AuthenticationData>
</Extension>
</GetSharedSecret>

3.3.2 GetSharedSecretResponse
The VIP service returns an XML message of type <GetSharedSecretResponse> upon successful
authentication of a request. The response contains the encrypted OTP seed and other OTP credential
attributes. The key encryption key to encrypt the OTP seed is a derived session key with the
manufacturer supplied application encryption key K_ENC_DF and some request data according to
section 3.2.2.
Example 1 (AES-CBC):

<GetSharedSecretResponse xmlns="http://www.verisign.com/2006/08/vipservice"
RequestId="1234abcd" Version="1.0">
<Status>
<ReasonCode>0000</ReasonCode>
<StatusMessage>Success</StatusMessage>
</Status>
<SharedSecretDeliveryMethod>HTTPS</SharedSecretDeliveryMethod>
<SecretContainer Version="1.0">
<EncryptionMethod>
<EncryptionAlgorithm>AES128-CBC</EncryptionAlgorithm>
<EncKeyLabel>Sensor Manufacture X OTP Client</EncKeyLabel>
</EncryptionMethod>
<Device>
<Secret type="HOTP" Id=" VSFS00000001">
<Issuer>OU = VIP ID Center Dev, O = VeriSign</Issuer>
<Usage otp="true">
<AI type="HMAC-SHA1-TRUNC-6DIGITS"/>
<TimeStep>30</TimeStep>
<Time>0</Time>
<ClockDrift>4</ClockDrift>
</Usage>
<FriendlyName>OU = VIP ID Center Dev, O = VeriSign</FriendlyName>
<Data>
<Cipher>MTIzNDU2Nzg5MDEyMzQ1NoXEvGLU323Hujg17cls1DUM8EQ/0RlgbRHM3oonyb4Q
</Cipher>
<Digest algorithm="HMAC-SHA1">GQcJ9BHmOsWr8P0fBq/oCmVLz0k=</Digest>
</Data>
<Expiry>2015-06-30T12:00:00</Expiry>
</Secret>
</Device>
</SecretContainer>
</GetSharedSecretResponse>
where

 SecretContainer/Device/Secret@Id – the VIP credential ID
 SecretContainer/Device/Secret@type – the value is “HOTP” for both event and time based HOTP VIP
credentials. Time based credentials is indicated by the presence of the TimeStep element.
 SecretContainer/Device/Secret/Usage/TimeStep – the time step value as defined in TOTP RFC

specification.
 SecretContainer/Device/Secret/Usage/Time – the initial time from which the number of time steps will be
calculated. It corresponds to the T0 defined in TOTP RFC specification. A client application must store
this data along with the VIP credential, credential secret, and this initial time (T0) for complete use of
TOTP algorithm.
 SecretContainer/Device/Secret/Usage/ClockDrift – the maximal daily clock drift expected in the client

device where OTP generation is carried out. The TOTP algorithm doesn’t use this value. It is used by VIP
service for OTP moving factor out of synchronous period estimate.
 SecretContainer/Device/Secret/Data/Cipher – the encrypted OTP secret with IV value prepended. The

encryption algorithm follows the specification described in this document.
Example 2 (AES-CTR):

<GetSharedSecretResponse xmlns=" http://www.verisign.com/2006/08/vipservice"
RequestId="1234abcd" Version="1.0">
<Status>
<ReasonCode>0000</ReasonCode>
<StatusMessage>Success</StatusMessage>
</Status>
<SharedSecretDeliveryMethod>HTTPS</SharedSecretDeliveryMethod>
<SecretContainer Version="1.0">
<EncryptionMethod>
<EncryptionAlgorithm>AES128-CTR</EncryptionAlgorithm>
<EncKeyLabel>Sensor Manufacture X OTP Client</EncKeyLabel>
</EncryptionMethod>
<Device>
<Secret type="HOTP" Id=" VSFS00000001">
<Issuer>OU = VIP ID Center Dev, O = VeriSign</Issuer>
<Usage otp="true">
<AI type="HMAC-SHA1-TRUNC-6DIGITS"/>
<TimeStep>30</TimeStep>
<Time>0</Time>
<ClockDrift>4</ClockDrift>
</Usage>
<FriendlyName>OU = VIP ID Center Dev, O = VeriSign</FriendlyName>
<Data>
<Cipher>MTIzNDU2Nzg5MDEyMzQ1Nq72gEr3f+3nLoJ/VnjCHB1xyZQz</Cipher>
<Digest algorithm="HMAC-SHA1">GQcJ9BHmOsWr8P0fBq/oCmVLz0k=</Digest>
</Data>
<Expiry>2015-06-30T12:00:00</Expiry>

</Secret>
</Device>
</SecretContainer>
</GetSharedSecretResponse>
3.3.3 Error Codes
This section lists the error codes you may encounter using the GetSharedSecret API.
4e00: Malformed request

4e01: Service Internal Error
4e02: Authentication failed
4e03: Authorization failed
4e04: Unsupported protocol version
4e09: Unsupported OTP algorithm
4e0d: Unsupported token model
4e0a: Token orders for this credential type already fulfilled or expired
4e10: This URL does not support this operation
The XML schema for the messages is described in Appendix, see Section 7. The VIP provisioning service WSDL
file will be sent separately to the manufacturers.
4 Protect the function call that generates OTP

OTP generation will be solely handled by a client application. An OTP client application and the
associated OTP generation flow must ensure that the function call to generate an OTP isn’t exposed to
any other unauthorized applications and that an OTP is released only after certain user verification or
other proper check has been carried out. It should mitigate the risk that a rogue application or flow can
automatically retrieve an OTP from the user computer without a user’s notice.
For the OTP credentials acquired via a finger print sensor, the following steps are recommended to
guard an OTP release.
1. An OTP will be generated only after a finger swipe on the sensor

 This will make sure that the malware cannot automatically request OTP token at
any time. A physical person must be present at the time of token generation.
2. An OTP will be generated only after authenticating the user on the device with a finger
print match. This check isn’t required for OTP release.
 This will make sure that only the valid person can generate OTP using this device.

5 Test environment
The following VIP provisioning service URL should be used for test.
https://ptnr-vipservices.bbtest.net/prov
The previous one https://ptnr-vipservices.bbtest.net/VIP/prov will be retired in the end of Dec. 2010. The
credentials are not in production for use in actual VIP web site. The OTP can be validated at the
following test web site:
https://ptnr-mtp.bbtest.net/trustedbank/app
Steps for OTP validation test:
1. Click on “Open An Account” to create a test user

2. Click “Add VIP Credential” to add the VIP credential you have provisioned by your client
application in the page.
3. Logout, and then try to login back. You will be prompted to enter an OTP on the login.
4. You can check and update VIP credential use via the menu “Update Profile”.
6 Appenix A: Application Key Registration XML Schema

<xs:schema xmlns:vipk="http://schema.verisign.com/vip/key"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
targetNamespace="http://schema.verisign.com/vip/key" elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-
schema.xsd"/>
<xs:element name="OTPClientAppKeyRegistration"
type="vipk:OTPClientAppKeyRegistrationType"/>
<xs:complexType name="OTPClientAppKeyRegistrationType">

<xs:annotation>
<xs:documentation>The top element for application key information shared
between OTP devices and VeriSign.</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="Manufacturer" type="xs:string"/>
<xs:element name="Platform" type="xs:string"/>
<xs:element name="ApplicationKeyID" type="xs:string"/>
<xs:element name="Description" type="xs:string"/>
<xs:element name="EncryptionKey" type="ds:KeyInfoType" minOccurs="0"/>
<xs:element name="EncryptedAuthKey" type="xs:base64Binary"/>
<xs:element name="EncryptedEncKey" type="xs:base64Binary"/>
<xs:element name="CreationDate" type="xs:dateTime" minOccurs="0"/>
<xs:element name="StartDate" type="xs:dateTime" minOccurs="0"/>
<xs:element name="ExpiryDate" type="xs:dateTime" minOccurs="0"/>
<xs:element name="Mac" type="vipk:MacType" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="MacType">
<xs:annotation>
<xs:documentation>The type represents MAC information.</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="EncryptedMacKey" type="xs:base64Binary"/>
<xs:element name="Mac" type="xs:base64Binary"/>
</xs:sequence>
<xs:attribute name="MacAlgorithm" type="xs:anyURI" use="required" />
</xs:complexType>
</xs:schema>
7 Appendix B: VIP Provisioning Protocol Message Schema
<element name="GetSharedSecret" type="vips:GetSharedSecretType"/>


<complexType name="GetSharedSecretType">
<annotation>
<documentation xml:lang="en">
Type for a shared-secret provisioning request.
</documentation>
</annotation>
<complexContent>
<extension base="vips:RequestAbstractType">
<sequence>
<element ref="vips:TokenModel"/>
<element ref="vips:ActivationCode" minOccurs="0"/>
<element name="Pin" type="string" minOccurs="0"/>
<element name="OtpAlgorithm"
type="vips:OtpAlgorithmIdentifierType" maxOccurs="5"/>
<element name="ClockDrift" minOccurs="0">
<simpleType>
<restriction base="integer">
<minInclusive value="0"/>

<maxInclusive value="255"/>

</restriction>
</simpleType>
</element>
<element ref="vips:SharedSecretDeliveryMethod" minOccurs="0"/>
<element ref="vips:SupportedEncryptionAlgorithm"
minOccurs="0"/>
<element name="DeviceId" type="vips:DeviceIdType"
minOccurs="0"/>
<element name="Extension" type="vips:AbstractExtensionType"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>

<complexType name="DeviceProvisionInfoType" mixed="false">
<complexContent mixed="false">
<extension base="vips:AbstractExtensionType">
<sequence>
<element name="ApplicationID">
<simpleType>
<restriction base="string">
<minLength value="1" />
<maxLength value="64" />
</restriction>
</simpleType>
</element>
<element name="Nonce" type="base64Binary" />
<element name="ClientTimestamp" type="long" />
<element name="AuthenticationData" type="base64Binary" />
</sequence>
</extension>
</complexContent>
</complexType>


<complexType name="GetSharedSecretResponseType">
<annotation>
<documentation xml:lang="en">
Type for a shared-secret provisioning response.
</documentation>
</annotation>
<complexContent>
<extension base="vips:ResponseWithStatusType">
<sequence minOccurs="0">
<element ref="vips:SharedSecretDeliveryMethod" minOccurs="0"/>
<element ref="vips:SecretContainer" minOccurs="0"/>
<element name="BrandInfo" type="vips:BrandInfoType"
minOccurs="0"/>
<element name="UTCTimestamp" type="string" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>



<complexType name="SecretContainerType">
<sequence>
<element name="EncryptionMethod" type="vips:EncryptionMethodType"/>
<element name="Device" type="vips:DeviceType" maxOccurs="unbounded"/>
</sequence>
<attribute name="Version" type="vips:VersionType" use="required"/>
</complexType>

<complexType name="EncryptionMethodType">
<sequence>
<element ref="vips:EncryptionAlgorithm" minOccurs="0"/>

<choice>
<element name="EncKeyLabel" type="string" minOccurs="0"/>
<sequence>
<element name="PBESalt" type="base64Binary"/>
<element name="PBEIterationCount" type="integer"
minOccurs="0"/>
<element name="IV" type="base64Binary" minOccurs="0"/>
</sequence>
</choice>
</sequence>
</complexType>
8 Appendix C: Test VeriSign Key Transport Certificate
The following test certificate can be used for encrypting application keys by device manufacturers
during test phase. Production certificate will be provided in a later revision.
-----BEGIN CERTIFICATE-----
MIIDyzCCArOgAwIBAgIQIZrIfQCG9bY4x70XD2FCQTANBgkqhkiG9w0BAQUFADBO
MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xJjAkBgNVBAMT
HVZJUCBBdXRoZW50aWNhdGlvbiBTZXJ2aWNlIENBMB4XDTA5MDIxOTAwMDAwMFoX
DTExMDIxOTIzNTk1OVowXTEcMBoGA1UECwwTUGFydG5lciBWSVAgTWFuYWdlcjEX
MBUGA1UECgwOVmVyaVNpZ24sIEluYy4xJDAiBgNVBAMMG1BhcnRuZXIgVklQIE1h
bmFnZXIgUkEgMjAwOTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAqOyZMI0E
VH8TmMZ6BYW3hb4Nz9clukOykahNhwKdQEV/G63mMcrzVCCLsYeSF1Ks1fJccgaJ
A4cK9oJrrLast5Mq5//v9FfGucrercyH7rDsPGk+g1QxygpE9Lw8AkTSK9C3tbgV
wzngtMYz9VUqaIQVibc1PHbvHBaRwjN9lm0CAwEAAaOCARgwggEUMAkGA1UdEwQC

MAAwCwYDVR0PBAQDAgWgMGAGA1UdHwRZMFcwVaBToFGGT2h0dHA6Ly9vbnNpdGVj
cmwudmVyaXNpZ24uY29tL1ZlcmlTaWduSW5jVklQQXV0aGVudGljYXRpb25TZXJ2
aWNlL0xhdGVzdENSTC5jcmwwHwYDVR0jBBgwFoAUZiuI19oojLzejQJfMqApZcRK
rpIwHQYDVR0OBBYEFM0K7IYp9JfQCV39drQDQsRwNwcYMBEGCWCGSAGG+EIBAQQE
AwIHgDATBgNVHSUEDDAKBggrBgEFBQcDAjAwBgpghkgBhvhFAQYLBCIWIGFlMTMy
YTVjN2QyNDJhMDczMDZmMzI2YjNhOWQ0ZTI3MA0GCSqGSIb3DQEBBQUAA4IBAQAv
ZFNTRJAi/cK7npTO3V/4601ZU1ESeATKam0fkBFpx0xOz/kSXyT1tV5BG4DJel5h
B5BHCfS3fWnTEd/uF8i+Azv7GChBuyzldWdYvhOjWIFoX1mJUeDNfuVOa1whxRxw
f1HTJc1yNTLdtuZadZX6hUIJ2rdNtIO0C4oyO/l91dLebYVqbKx0eLznIWOP/dd6
aVUrh2ZRM2YA6o8jQu91o9rn2GviOWBFwY18mSXW8guiGv2uREv8BUy9Mos9D5P9
BSpxDVBr8zLANxYzAe2F4GGe2JmPejEd9pf5lQXsapKTbyVrfAB0xin+aBAzse06
yW3ykIfognE+mSetqmvV
-----END CERTIFICATE-----
9 Appendix D: VeriSign Production Key Transport Certificate
-----BEGIN CERTIFICATE-----
MIID0jCCArqgAwIBAgIQdU0Ap5ByQLfgxMCtY2hPyDANBgkqhkiG9w0BAQUFADCB
hDELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQDEzJWZXJpU2lnbiBDbGFz
cyAzIE1hbmFnZWQgUEtJIEFkbWluaXN0cmF0b3IgQ0EgLSBHMzAeFw0xMDAyMTAw
MDAwMDBaFw0xMTAyMTAyMzU5NTlaMIGYMQswCQYDVQQGEwJVUzETMBEGA1UECBMK
Q2FsaWZvcm5pYTEWMBQGA1UEBxQNTW91bnRhaW4gVmlldzEXMBUGA1UEChQOVmVy
aVNpZ24sIEluYy4xHzAdBgNVBAsUFlByb2R1Y3Rpb24gVklQIE1hbmFnZXIxIjAg
BgNVBAMUGVByb2R1Y3Rpb24gVklQIE1hbmFnZXIgUkEwgZ8wDQYJKoZIhvcNAQEB
BQADgY0AMIGJAoGBAJm7JQ5dsoWVosqnlzUnJ42nyndGKqF4DQx68V9XgA0Nb9wV
BpEfslNANIZZdJPnD5DItl7JAkh2GLc3LxU8iXMm7enYJTbCU164vmVCTE/KkuY/
UWP5VQ+joe3xo4XavjI3jMQFWevwft/g8JtnVCdE+KuWhTbCCotRwhCBtd9TAgMB

AAGjga0wgaowCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcDMCow
KAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwEQYJYIZI
AYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgsEIhYgMzdlNTEzY2IzOGE5MDA3ZDBj
M2Y1NDJkNTIyYzUxZmQwEgYKYIZIAYb4RQEGDQQEAwIDCDANBgkqhkiG9w0BAQUF
AAOCAQEAjuOdH29TvmEpCJhHGwU9K3hyCDC6odZUdYCZm1dXqpn+tARq/pvOnDfr
mzaVCJ7JXV0/+f3fxnxF2/ZjiNgRXCU4rIfTLWd9GjAATp73yxFsj3IxxA8Ud827
D/LyUcn+uT4w6XxV0pijtgVaYvPyXxYjQeLOitmSadWDVZb7AWUW/rZxw8JOk2t8
TmCKsBVBkFjtNmcIncmZicRwLuXOWLUbjZNeXhiQ1Nm53zt29bZMqzwEL007em0j
6OzcesQWSNogRWIiJy6zC0dPyvJCykia4weZVE1DpBKs0gDslVTOVi+i5suBFe3H
SnInr9FA7C0paF1Vy7FEmYSLvpTO8g==
-----END CERTIFICATE-----
10 Appendix E: Test Code
import javax.crypto.*;
import java.security.*;
import java.security.spec.*;
import javax.crypto.spec.*;
import java.io.ByteArrayOutputStream;
import java.math.BigInteger;
public class TestHMAC {
static byte[] k_auth = "12345678901234567890".getBytes();
static byte[] k_enc_kd = "01234567890123456789".getBytes();
static byte[] iv = "1234567890123456".getBytes();
static byte[] otp_secret = "12345678901234567890".getBytes();
static byte[] nonce = "1234567890123456".getBytes();
static byte[] timestamp = "2000000000".getBytes();

static byte[] application_id = "Sensor Manufacture X OTP Client".getBytes();
public static void main(String[] args) {
byte[] c_auth_data = testHMACAuth();
byte[] K_enc_s = testHMACKDF();
byte[] encCTR = testAESCTR(K_enc_s, iv, otp_secret);
byte[] encCBC = testAESCBC(K_enc_s, iv, otp_secret);
try {
byte[] mac = getHMAC(k_auth, otp_secret);
System.out.println("----- OTP Secret MAC Test -----");
System.out.println("Input: " + new BigInteger(1, otp_secret).toString(16));
System.out.println("key: " + new BigInteger(1, k_auth).toString(16));
System.out.println("Output: " + new BigInteger(1, mac).toString(16));
} catch(Throwable t) {
t.printStackTrace();
static byte[] testHMACAuth() {
try {
ByteArrayOutputStream bos = new ByteArrayOutputStream();
bos.write(application_id);
bos.write(nonce);
bos.write(timestamp);
byte[] data = bos.toByteArray();
byte[] result = getHMAC(k_auth, data);
System.out.println("----- HMAC Authentication Data Test -----");

System.out.println("Input: " + new BigInteger(1, data).toString(16));
System.out.println("key: " + new BigInteger(1, k_auth).toString(16));
System.out.println("Output: " + new BigInteger(1, result).toString(16));
return result;
return null;
static byte[] testHMACKDF() {
try {
ByteArrayOutputStream bos = new ByteArrayOutputStream();
bos.write(nonce);
bos.write(timestamp);
byte[] data = bos.toByteArray();
byte[] result = getHMAC(k_enc_kd, data);
byte[] K_enc_s = new byte[16];
System.arraycopy(result, 0, K_enc_s, 0, K_enc_s.length);
System.out.println("----- HMAC Key Derivation Test -----");
System.out.println("key: " + new BigInteger(1, k_enc_kd).toString(16));
System.out.println("Output: " + new BigInteger(1, K_enc_s).toString(16));
return K_enc_s;
return null;

static byte[] testAESCTR(byte[] key, byte[] iv, byte[] data) {
try {
System.out.println("----- AES CTR Test -----");
byte[] encData = AESCTR(Cipher.ENCRYPT_MODE, iv, key, data);
System.out.println("key: " + new BigInteger(1, key).toString(16));
System.out.println("IV: " + new BigInteger(1, iv).toString(16));
System.out.println("Output: " + new BigInteger(1, encData).toString(16));
byte[] decData = AESCTR(Cipher.DECRYPT_MODE, iv, key, encData);
System.out.println("Decrypt: " + new BigInteger(1, decData).toString(16));
return encData;
return null;
static byte[] testAESCBC(byte[] key, byte[] iv, byte[] data) {
try {
System.out.println("----- AES CBC Test -----");
byte[] encData = AESCBC(Cipher.ENCRYPT_MODE, iv, key, data);
System.out.println("key: " + new BigInteger(1, key).toString(16));
System.out.println("IV: " + new BigInteger(1, iv).toString(16));
System.out.println("Output: " + new BigInteger(1, encData).toString(16));
byte[] decData = AESCBC(Cipher.DECRYPT_MODE, iv, key, encData);

System.out.println("Decrypt: " + new BigInteger(1, decData).toString(16));
return encData;
return null;
public static byte[] AESCTR(int mode, byte[] iv, byte[] key, byte[] data) throws
Exception
Cipher cipher = Cipher.getInstance("AES/CTR/NoPadding");
AlgorithmParameterSpec paramSpec = new IvParameterSpec(iv);
SecretKeySpec secretKeySpec = new SecretKeySpec(key, "AES");
cipher.init(mode, secretKeySpec, paramSpec);
return cipher.doFinal(data);
public static byte[] AESCBC(int mode, byte[] iv, byte[] key, byte[] data) throws
Exception
Cipher cipher = Cipher.getInstance("AES/CBC/PKCS7Padding");
AlgorithmParameterSpec paramSpec = new IvParameterSpec(iv);
SecretKeySpec secretKeySpec = new SecretKeySpec(key, "AES");
cipher.init(mode, secretKeySpec, paramSpec);
return cipher.doFinal(data);

public static byte[] getHMAC(byte[] key, byte[] data) throws Exception {
SecretKey SHA1key = (SecretKey)new SecretKeySpec(key, "HmacSHA1");
Mac m = Mac.getInstance("HmacSHA1");
m.init(SHA1key);
m.update(data);
return m.doFinal();

VeriSign OTP Credential Provisioning Protocol For Trusted Devices Technical Specification v6

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

VeriSign OTP Credential Provisioning Protocol For Trusted Devices Technical Specification v6

Transféré par

Droits d'auteur :

Formats disponibles

VIP OTP Credential Provisioning Protocol for

Verisign Technical Specification Document

Last updated: 12/1073/2010

VeriSign, Inc. CONFIDENTIAL Page 1 Version: 6.0Version: 5.0

© 2010 VeriSign, Inc. All rights reserved.

Printed in the United States of America

Date Name Reviewers Description

VeriSign, Inc. CONFIDENTIAL Page 2 Version: 6.0Version: 5.0

3 Provisioning Flow Specification.......................................................................................... 5

4 Protect the function call that generates OTP....................................................................18

6 Appenix A: Application Key Registration XML Schema....................................................19

7 Appendix B: VIP Provisioning Protocol Message Schema...............................................20

8 Appendix C: Test VeriSign Key Transport Certificate.......................................................22

9 Appendix D: Test Code.................................................................................................... 23

VeriSign, Inc. CONFIDENTIAL Page 3 Version: 6.0Version: 5.0

VeriSign, Inc. CONFIDENTIAL Page 4 Version: 6.0Version: 5.0

3 Provisioning Flow Specification

VeriSign, Inc. CONFIDENTIAL Page 5 Version: 6.0Version: 5.0

3.1.1 Application Key ID

 Manufacturer name (e.g. Acme Inc.)

VeriSign, Inc. CONFIDENTIAL Page 6 Version: 6.0Version: 5.0

3.1.2 Application Keys

The two keys must meet the following specifications.

VeriSign, Inc. CONFIDENTIAL Page 7 Version: 6.0Version: 5.0

3.1.3 Key registration process and data format

The key registration XML data schema is the following.

 Manufacturer – the name of the application key provider

VeriSign, Inc. CONFIDENTIAL Page 8 Version: 6.0Version: 5.0

<?xml version="1.0" encoding="UTF-8"?>

VeriSign, Inc. CONFIDENTIAL Page 9 Version: 6.0Version: 5.0

<vipk:Description>The key is derived from global key in Acme's fingerprint

3.2 Acquire an OTP Credential from VIP Provisioning Protocol

VeriSign, Inc. CONFIDENTIAL Page 10 Version: 6.0Version: 5.0

3.2.1 Client Authentication

Client_Auth_Data = HMAC-SHA1(K_AUTH, <application_id> | <nonce> | <timestamp>)

we have the following data output

VeriSign, Inc. CONFIDENTIAL Page 11 Version: 6.0Version: 5.0

3.2.1.1 Security practice recommendations for finger print sensors

 Client software authentication by the device

3.2.2 OTP secret encryption method by the VIP service

Encrypted_OTP_Secret = AES-128(K_ENC_S, <OTP secret>)

VeriSign, Inc. CONFIDENTIAL Page 12 Version: 6.0Version: 5.0

we have the following

3.2.3 OTP secret data integrity check method

OTP_Secret_MAC = HMAC-SHA1(K_AUTH, <OTP secret>)

VeriSign, Inc. CONFIDENTIAL Page 13 Version: 6.0Version: 5.0

3.2.4 Processing encrypted VIP service response message

1. Parse the XML response message

3.3 VIP Protocol Messages

Example 1: Request an OTP secret using AES encryption in CBC mode

<?xml version="1.0" encoding="UTF-8"?>

VeriSign, Inc. CONFIDENTIAL Page 14 Version: 6.0Version: 5.0

 TokenModel – a token ID manufacturer code registered at OATH. It is used as token ID prefix

Example 2: Request an OTP secret using AES encryption in CTR mode

<?xml version="1.0" encoding="UTF-8"?>

VeriSign, Inc. CONFIDENTIAL Page 15 Version: 6.0Version: 5.0

<?xml version="1.0" encoding="UTF-8"?>

VeriSign, Inc. CONFIDENTIAL Page 16 Version: 6.0Version: 5.0

 SecretContainer/Device/Secret@Id – the VIP credential ID

 SecretContainer/Device/Secret/Usage/TimeStep – the time step value as defined in TOTP RFC

 SecretContainer/Device/Secret/Usage/ClockDrift – the maximal daily clock drift expected in the client

 SecretContainer/Device/Secret/Data/Cipher – the encrypted OTP secret with IV value prepended. The