Escolar Documentos
Profissional Documentos
Cultura Documentos
Trusted Devices
Version: 65.0
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
Contents
1 Overview............................................................................................................................ 4
2 Terminologies..................................................................................................................... 4
5 Test environment............................................................................................................. 19
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.
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
The following information needs to be sent from a manufacturer for its OTP application ID registration:
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.
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.
<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
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:
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.
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”
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.
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.
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
Example:
Assume the sample data in the above examples, we have the following output data.
OTP_Secret_MAC = 0x190709f411e63ac5abf0fd1f06afe80a654bcf49
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.
<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
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):
where
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/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.
Example 2 (AES-CTR):
</Secret>
</Device>
</SecretContainer>
</GetSharedSecretResponse>
This section lists the error codes you may encounter using the GetSharedSecret API.
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.
For the OTP credentials acquired via a finger print sensor, the following steps are recommended to
guard an OTP release.
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
<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>
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-----
-----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-----
import javax.crypto.*;
import java.security.*;
import java.security.spec.*;
import javax.crypto.spec.*;
import java.io.ByteArrayOutputStream;
import java.math.BigInteger;
try {
} catch(Throwable t) {
t.printStackTrace();
try {
bos.write(application_id);
bos.write(nonce);
bos.write(timestamp);
return result;
} catch(Throwable t) {
t.printStackTrace();
return null;
try {
bos.write(nonce);
bos.write(timestamp);
return K_enc_s;
} catch(Throwable t) {
t.printStackTrace();
return null;
try {
return encData;
} catch(Throwable t) {
t.printStackTrace();
return null;
try {
return encData;
} catch(Throwable t) {
t.printStackTrace();
return null;
public static byte[] AESCTR(int mode, byte[] iv, byte[] key, byte[] data) throws
Exception
return cipher.doFinal(data);
public static byte[] AESCBC(int mode, byte[] iv, byte[] key, byte[] data) throws
Exception
return cipher.doFinal(data);
Mac m = Mac.getInstance("HmacSHA1");
m.init(SHA1key);
m.update(data);
return m.doFinal();