verisign otp credential provisioning protocol for trusted devices technical specification v6

VIP OTP Credential Provisioning Protocol for Trusted DevicesVerisign Technical Specification DocumentVersion: 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 HistoryDate06/01/2010 06/17/2010

NameMingliang Pei Mingliang Pei

ReviewersInitial version.

DescriptionIncorporated feedbacks from several partners. Support HMAC-SHA1 and AES-128 with either CBC or CTR mode. A test vector is added. Added description about application key delivery XML format and updated VIP service message schema. Added test server information. Added error code list; changed to use token prefix VSFS. Changed test server URL. Added production application key transport certificate. Updated schema to include element.

08/05/2010 08/11/2010 12/07/2010 12/13/2010

Mingliang Pei Mingliang Pei Mingliang Pei Mingliang Pei


Page 2




ContentsChange History..............................................................................................................................2 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: VeriSign Production Key Transport Certificate......................................................23 10 Appendix E: Test Code............................................................................................................24


Page 3




1 OverviewThis 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 TerminologiesTerminology OTP OTP Credential Definition One Time Password. 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.


Page 4




OTP Secret OTP Algorithm

The shared secret value in an OTP credential. It is 20-byte long. 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. The OTP credential provisioning API service as part of VeriSign Identity Protection (VIP) Authentication Service.

VIP Provisioning Service

3 Provisioning Flow SpecificationThe 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 wont 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.


Page 5




Device ManufacturerApplication ID Registration Information Encrypted Application Keys (K_ENC, K_AUTH)

VeriSi

p r Ap i ste s eg y 1 . R ith Ke w

2 1.

CS

ve eri . D Keys 0 p Ap

Device Key Management

Key Encryption Key

r edenti al 2. G et OTP C

VIP Service

OTP Client Application

In the following sections, we describe each of the above steps in more detail. 3.13.1.1

Register an OTP clientApplication Key ID

Device Encrypted OTP Credential application

ID and share applications keys with VeriSign

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 manufacturers 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 isnt unique, VeriSign will assign a unique


Page 6




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-toend 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 doesnt 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.


Page 7




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. The top element for application key information shared between OTP devices and VeriSign.

The type represents MAC information.

where Manufacturer the name of the application key provider Platform the device type information. For finger print sensors, it can be FingerPrintSensor.


Page 8




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: Acme Inc. FingerPrintSensor Acme OTP Client for Fingerprint Sensor


Page 9




The key is derived from global key in Acme's fingerprint sensors 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 Eh8+YvlDHHkhZ4HCXl7kXvvdJuoaOeOtxJvNnj0EYbOjzO8XAgPreBMru5wnMdTx/JnzCCIYpfNtbfmb9F0oEavJwzy5C YKnjyBYYUBeJPQTG7iFpPULu/cBKxLpab2r5/kOT0OK37OeKGVMicF2/Kg4KbBC6OFyzLw5fiik5Cw= hJ+fvpoMPMO9BYpK2rdyQYGIxiATYHTHC7e/sPLKYo5/r1v+4xTYG3gJolCWuVMydJ7Ta0GaiBPHcWa8ctCVYmHKfSz5f deV5nqbZApe6dofTqhRwZK6Yx4ufevi91cjN2vBpSxYafvN3c3+xIgk0EnTV4iVPRCR0rBwyfFrPc4= 2010-08-05T00:00:00Z 2011-01-01T00:00:00Z 2020-12-31T00:00:00Z

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 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.


Page 10




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, | | ) 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 beused 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


Page 11




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 vendors 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, )


Page 12




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, ) Example: Assume the sample data in the above examples, we have the following output data. OTP_Secret_MAC = 0x190709f411e63ac5abf0fd1f06afe80a654bcf49


Page 13




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.33.3.1

VIP Protocol MessagesGetSharedSecret

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 VSFS AES128-CBC Sensor Manufacturer X XA1234


Page 14




SPH-A900 HP Commercial Sensor Manufacture X OTP Client MTIzNDU2Nzg5MDEyMzQ1Ng== 2000000000 aI/LZoU2OA3rnUPwOLQrEAQqydQ=

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 VSFS AES128-CTR Sensor Manufacturer X XA1234 SPH-A900 HP Commercial Sensor Manufacture X OTP Client MTIzNDU2Nzg5MDEyMzQ1Ng== 2000000000 aI/LZoU2OA3rnUPwOLQrEAQqydQ=


Page 15




3.3.2

GetSharedSecretResponse

The VIP service returns an XML message of type 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): 0000 Success HTTPS AES128-CBC Sensor Manufacture X OTP Client OU = VIP ID Center Dev, O = VeriSign 30 0 4 OU = VIP ID Center Dev, O = VeriSign MTIzNDU2Nzg5MDEyMzQ1NoXEvGLU323Hujg17cls1DUM8EQ/0RlgbRHM3oonyb4Q GQcJ9BHmOsWr8P0fBq/oCmVLz0k= 2015-06-30T12:00:00

where


Page 16




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 doesnt 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): 0000 Success HTTPS AES128-CTR Sensor Manufacture X OTP Client OU = VIP ID Center Dev, O = VeriSign 30 0 4 OU = VIP ID Center Dev, O = VeriSign MTIzNDU2Nzg5MDEyMzQ1Nq72gEr3f+3nLoJ/VnjCHB1xyZQz GQcJ9BHmOsWr8P0fBq/oCmVLz0k= 2015-06-30T12:00:00


Page 17




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 OTPOTP 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 isnt 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 users 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 isnt required for OTP release. This will make sure that only the valid person can generate OTP using this device.


Page 18




5 Test environmentThe 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


Page 19




The top element for application key information shared between OTP devices and VeriSign. The type represents MAC information.

7 Appendix B: VIP Provisioning Protocol Message Schema Type for a shared-secret provisioning request.


Page 20




Type for a shared-secret provisioning response.


Page 21




8 Appendix C: Test VeriSign Key Transport CertificateThe 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


Page 22




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


Page 23




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 Codeimport 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();


Page 24




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: System.out.println("key: " + new BigInteger(1, otp_secret).toString(16)); " + 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 -----");


Page 25




System.out.println("Input: System.out.println("key:

" + new BigInteger(1, data).toString(16)); " + new BigInteger(1, k_auth).toString(16));

System.out.println("Output: " + new BigInteger(1, result).toString(16)); return result; } catch(Throwable t) { t.printStackTrace(); } 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("Input: System.out.println("key: " + new BigInteger(1, data).toString(16)); " + new BigInteger(1, k_enc_kd).toString(16));

System.out.println("Output: " + new BigInteger(1, K_enc_s).toString(16)); return K_enc_s; } catch(Throwable t) { t.printStackTrace(); } return null;


Page 26




}

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("Input: System.out.println("key: System.out.println("IV: System.out.println("Output: " + new BigInteger(1, data).toString(16)); " + new BigInteger(1, key).toString(16)); " + new BigInteger(1, iv).toString(16)); " + 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; } catch(Throwable t) { t.printStackTrace(); 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("Input: System.out.println("key: System.out.println("IV: System.out.println("Output: " + new BigInteger(1, data).toString(16)); " + new BigInteger(1, key).toString(16)); " + new BigInteger(1, iv).toString(16)); " + new BigInteger(1, encData).toString(16));

byte[] decData = AESCBC(Cipher.DECRYPT_MODE, iv, key, encData);


Page 27




System.out.println("Decrypt: " + new BigInteger(1, decData).toString(16)); return encData; } catch(Throwable t) { t.printStackTrace(); 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); }


Page 28




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(); } }


Page 29


verisign otp credential provisioning protocol for trusted devices technical specification v6

Documents

verisign logo

service marks of verisign

vip protocol messages

verisign trust network

shared application key

otp client application

application keys

test code