DESC:FORM 2
THE PATENTS ACT, 1970
[39 of 1970]
&
THE PATENTS RULES, 2003
COMPLETE SPECIFICATION
(Section 10; Rule 13)

METHOD OF SECURE PROVISIONING AND BINDING OF ONE-TIME PASSWORD (OTP) SECRET TO A DEVICE

SAMSUNG R&D INSTITUTE INDIA – BANGALORE Pvt. Ltd.
# 2870, ORION Building, Bagmane Constellation Business Park,
Outer Ring Road, Doddanekundi Circle,
Marathahalli Post,
Bangalore -560037, Karnataka, India
Indian Company

The following Specification particularly describes the invention and the manner in which it is to be performed

RELATED APPLICATION

The present invention claims benefit of the Indian Provisional Application No. 5325/CHE/2015 titled "SYSTEM AND METHOD FOR SECURE PROVISIONING AND BINDING OF OTP SECRET TO A DEVICE” by Samsung R&D Institute India – Bangalore Private Limited, filed on 5th October 2015, which is herein incorporated in its entirety by reference for all purposes.

FIELD OF THE INVENTION

The present invention generally relates to secure communication of information, and more particularly relates to a method of secure provisioning and binding of one-time password (OTP) secret to a device.

BACKGROUND OF THE INVENTION

With an increased advancement in online services in the field of shopping, banking and other financial transactions, one-time password (OTP) is necessary for the user, to do their transactions in a secure way. Generally, OTP relies on symmetric key referred as “OTP secret” or “OTP seed” to generate OTP values. The OTP generation happens with “OTP secret” and combined with other parameters including but not limited to time, counter, challenge, PIN and using OTP algorithm such as hash message authentication code (hmac), TOTP and the like. The OTP secret is the core to security of overall OTP operation.

The OTP secret should be provisioned securely to a device for a secure communication. Figure 1 illustrates an exemplary method of provisioning OTP secret to the user device by an OTP server, according to the existing art. As shown in Figure 1, one or more entities involved in provisioning the OTP secret comprises of a device 102, an OTP application 104 and an OTP server 106. At step 108, the OTP application is downloaded and installed by the device 102. At step 110, the OTP application is invoked by the user to get registered with the OTP app 104. In turn, the OTP app prompts the user to enter user credentials. The user registers his/her username, password, activation code etc. with the OTP application 104 at step 112.

Upon accepting the user information, a secure connection (SSL/TLS) is established between the OTP server and the OTP application, at step 114. At step 116, the user using the OTP application is authenticated by the OTP server. Upon authenticating the OTP app 104, the OTP server 106 at step 118, provides a OTP secret to the OTP app 104 in an encrypted form, wherein for encryption, the OTP server 106 uses one of the credential details provided by the user during registration process. At step 120, the OTP app stores the OTP secret in a data store of the application. However, it is possible that, a malicious app or user may use user credential to create OTP token including ‘OTP secret’ and copy on some other device without knowledge of OTP server as OTP server may simply trust that everything is fine as user/app has presented credentials. Further, the OTP secret stored in app’s sandbox may be copies if device is rooted. Thus, secure communication may not take place between the device and OTP server, due to which there may be a probability of copy or leakage of OTP secret outside the device.

Currently, there exists no solution for securely provisioning of the OTP secret to the user device.

In view of the foregoing, there is a need for a novel method for securely provisioning and binding OTP secret to the device.

The above mentioned shortcomings, disadvantages and problems are addressed herein and which will be understood by reading and studying the following specification.

SUMMARY OF THE INVENTION

Various embodiments herein describe a method for securely provisioning and binding one-time password (OTP) secret to a device, the method comprising the steps of: receiving, by an OTP Server, a request from an OTP application residing in a device for provisioning an OTP secret to the device, wherein the OTP application is capable of operating in a normal world and in a secure world, authenticating, by the OTP server, the OTP application in response to the received request,
requesting, by the OTP server, the OTP application on the device to produce an OTP certificate to securely transport the OTP secret to the device, generating, by the device, an OTP certificate by a secure OTP application on device, validating, by the OTP server, the received OTP certificate with root certifying authority (CA), generating, by the OTP server, an OTP Token using the validated OTP Certificate, extracting, by the device, the OTP Secret by the Secure OTP application and validating the OTP Token data, and storing, by the device, the extracted OTP Secret in secure world, thereby enabling the OTP application to securely access the OTP secret.

According to one embodiment, the OTP certificate is a unique certificate associated with the device.

According to one embodiment, the method of generating OTP certificate by the secure OTP application comprises of: receiving, by the secure OTP application, a request from the normal OTP application to create OTP certificate, checking, by the secure OTP application, whether any OTP certificate associated with the device is available in the device, generating, by the secure OTP application, a public-private key pair for the OTP certificate if the OTP certificate is unavailable in the device, creating, by the secure OTP application, subject information for OTP certificate to uniquely identify the device, wherein the subject information comprises of International Mobile Station Equipment Identity (IMEI), serial number of the device and extensions for the indication of OTP certificate, signing, by the secure OTP application, the OTP certificate using Device certificate which is in turn signed by the root certificate authority (CA) to generate OTP certificate; and storing the generated private Key associated with the OTP certificate in the secure world.

According to one embodiment, the method of generating OTP certificate by secure OTP application comprises of: forwarding, by the OTP server, a device encryption certificate received from normal OTP application to a CA server for obtaining information needed to provision the OTP certificate, generating, by the CA server, a challenge and encrypting the challenge using the device encryption certificate for transmitting the encrypted challenge to the OTP server, forwarding, by the OTP server, the encrypted challenge along with URL of CA server to the normal OTP application to provision the OTP certificate, generating, by a secure OTP, certificate signing request (CSR), key pair for embedding the challenge in the CSR,wherein the CSR is signed using device signing certificate, providing, by the secure OTP application, the CSR to the CA server for allowing the CA server to execute certificate enrollment protocol between the normal OTP application and the CA server, providing, by the CA server, the OTP certificate to the device after validating the CSR.

According to one embodiment, the method further comprises of checking, by the OTP server, device platform integrity for the provisioning of the OTP certificate.

According to one embodiment, the method of checking device platform integrity comprises of: requesting, by the OTP server, the device to provide device integrity measurement, transmitting, by the normal OTP application, device integrity measurement to the OTP server in response to the request, wherein the blob carries measurements of the device platform, forwarding, by the OTP server, the device integrity measurements received from the normal OTP application to an attestation server for verification, and indicating, by the attestation server, the status of the device platform based on the integrity measurements forwarded to the OTP server.

According to one embodiment, the method of generating the OTP Token comprising the steps of: validating, by the OTP server, the OTP certificate provided by the OTP application with the Root CA, generating, by the OTP server, an OTP token along with OTP secret, details of OTP algorithm and integrity protection bytes after validating the OTP certificate, generating, by the OTP server, the data by combining the generated OTP secret and integrity protection bytes, encrypting, by the OTP server, the generated data using OTP certificate, collecting, by the OTP server, information regarding the OTP application, generating, by the OTP server, a message by combining data, OTP token details and OTP application details, applying, by the OTP server, a keyed-hash message authentication code (hmac) to the generated message to obtain a hmac value, wherein the message is transmitted as message and integrity protection bytes is passed as key, and transmitting the message and hmac value to the OTP application.

According to one embodiment, the method of extracting the OTP Secret by the secure OTP application and validating the OTP Token data comprises of: decrypting, by the secure OTP application, data using private key of the OTP certificate to obtain OTP secret and integrity protection bytes, receiving, by the secure OTP application, details of token and application from the normal OTP application, preparing, by the secure OTP application, a message by combining data, details of OTP token and OTP application, applying, by the secure OTP application, keyed hmac to the message and as integrity protection bytes as key to create a hmac value, comparing, by the secure OTP application, whether hmac value calculated by Secure OTP application matches with the hmac value provided by OTP server, and storing, by the secure OTP application, the OTP secret, if the hmac value calculated by the secure OTP application matches with the hmac value provided by the OTP server.

Various embodiments herein further describe a device for securely provisioning and binding an OTP secret to the device. In one embodiment, the device comprise of a processor, a memory coupled to the processor, wherein the memory separately comprising: a normal OTP application adapted to send a request to an OTP server for provisioning an OTP secret to the device, produce an OTP certificate to the OTP server to securely transport the OTP secret to the device, and a secure OTP application adapted to generate an OTP certificate on device, to receive OTP token generated by the OTP server, extract the OTP Secret and validate the OTP Token data, and store the extracted OTP Secret to securely access the OTP secret.

The foregoing has outlined, in general, the various aspects of the invention and is to serve as an aid to better understanding the more complete detailed description which is to follow. In reference to such, there is to be a clear understanding that the present invention is not limited to the method or application of use described and illustrated herein. It is intended that any other advantages and objects of the present invention that become apparent or obvious from the detailed description or illustrations contained herein are within the scope of the present invention.

BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS

The other objects, features and advantages will occur to those skilled in the art from the following description of the preferred embodiment and the accompanying drawings in which:

Figure 1 is a flow diagram illustrating an exemplary method of provisioning of ‘OTP secret’ to a device, according to the existing art.

Figure 2 is a flowchart diagram illustrating a method of securely provisioning of OTP secret to a device, according to one embodiment.

Figure 3 is a flow diagram illustrating a method of securely provisioning of OTP secret to a device, according to one embodiment.

Figure 4 is a flow diagram illustrating a method of securely provisioning of OTP secret to a device, according to another embodiment.

Figure 5A is a flow diagram illustrating a method of generating OTP certificate for securely provisioning OTP secret to a device, according to one embodiment.

Figure 5B is a flow diagram illustrating a method of generating OTP certificate for securely provisioning OTP secret to a device, according to another embodiment.

Figure 6 is a block diagram illustrating one or more components of a device for securely receiving the OTP secret, according to one embodiment.

Although specific features of the present invention are shown in some drawings and not in others, this is done for convenience only as each feature may be combined with any or all of the other features in accordance with the present invention.

DETAILED DESCRIPTION OF THE INVENTION

The present invention describes a method for securely provisioning and binding of one-time password secret to a device. In the following detailed description of the embodiments of the invention, reference is made to the accompanying drawings that form a part hereof, and in which are shown by way of illustration specific embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention, and it is to be understood that other embodiments may be utilized and that changes may be made without departing from the scope of the present invention. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present invention is defined only by the appended claims.

The specification may refer to “an”, “one” or “some” embodiment(s) in several locations. This does not necessarily imply that each such reference is to the same embodiment(s), or that the feature only applies to a single embodiment. Single features of different embodiments may also be combined to provide other embodiments.

As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless expressly stated otherwise. It will be further understood that the terms “includes”, “comprises”, “including” and/or “comprising” when used in this specification, specify the presence of stated features, integers, steps, operations, elements and/or components, but do not preclude the presence or addition of one or more other features integers, steps, operations, elements, components, and/or groups thereof. As used herein, the term “and/or” includes any and all combinations and arrangements of one or more of the associated listed items.

Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

The present invention describes a method for securely provisioning and binding of an OTP secret to device. The embodiments of the present invention are described with respect to a device that can be any of electronic devices such as, but not limited to, mobile phone, smart phone, tablet, PDA, and the like, and the person having ordinarily skilled in the art can understand that any of the device with communication with other entities can be used, without departing from the scope of the invention.

The present invention enables an OTP server to know about which application is requesting for OTP secret and to which device the OTP secret is provisioned. Some of the entities involved in securely provisioning OTP secret are: an OTP framework, an OTP application, a secure OTP application, a certificate authority (CA) server, an OTP server, and an attestation server. The OTP framework is a software component resides in normal world of device. The ‘OTP app’ in normal world interacts with an OTP app on secure world through the OTP framework. The application (say an Android app) performs OTP related operations in co-ordination with OTP framework, secure OTP app and the OTP server. The OTP app may have user interface to display OTP values. The secure OTP app works on secure world of device and performs all core OTP related operations and manages ‘OTP secret’ values. The secure OTP app typically resides on ARM trust zone or eSE (embedded Secure Element).

The certificate authority (CA) server is responsible for issuing, revocation of digital OTP certificates, whereas the OTP server performs all server side activities related to OTP. The attestation server is used for checking integrity of device platform is good or not before server proceeds with creation of OTP token on device.

Figure 2 is a flowchart illustrating a method for securely provisioning and binding OTP secret to a device, according to one embodiment. The steps involved in securely provisioning and binding OTP secret to the device are explained as follows. At step 202, a request is received by an OTP server from an OTP application residing in the device for provisioning an OTP secret to the device. At step 204, the OTP application is authenticated in response to the received request. At step 206, the OTP application on the device is requested to produce an OTP certificate to securely transport the OTP secret to the device. At step 208, an OTP certificate is generated by a secure OTP application on device. The received OTP certificate is then validated with root certifying authority (CA). This is performed at step 210. At step 212, an OTP Token is generated using the validated OTP Certificate. The generated OTP token data is then validated to extract the OTP Secret by the Secure OTP application at step 214. Finally, at step 216, the extracted OTP Secret is stored in secure world, thereby enabling the OTP application to securely access the OTP secret.

Figure 3 is a flow diagram illustrating a method for securely provisioning and binding OTP secret to a device, according to one embodiment. In this embodiment, the one or more entities involved in provisioning OTP secret to a device comprises of a normal OTP app 302, an OTP framework 304, a secure OTP app 306 and an OTP server 308. The one or more steps performed by each of the entities in secure provisioning of OTP secret is explained below.

At step 1, a request is transmitted to the OTP server 308 by the normal OTP app 302 to provision OTP secret. In response, the OTP server 308 requests the normal OTP app 302 to produce OTP certificate, at step 2. Optionally, the OTP server also requests the end user to authenticate using relevant credentials such as username, password etc. Once the authentication is successful, the OTP server 308 proceeds to next step of action.

At step 3, the normal OTP app obtains the OTP certificate by interacting with OTP framework 304 and secure OTP app 306 and presents the OTP certificate to the OTP server 308. In one embodiment, the normal OTP app 302 also provides other relevant information such as application details to the OTP server 308. The application details correspond to collection of information and enables the OTP server 308 to identify which application has requested the OTP secret. Then, the OTP server 308 uses the OTP certificate to generate OTP token, wherein the step of generating OTP token comprises of validating the received OTP certificate from the normal OTP app 302 at step 4. At step 5, OTP secret and integrity protection bytes are generated by the OTP server 308. Both the OTP secret and integrity protection bytes are concatenated at step 5, to generate DATA. At step 6, the generated DATA is encrypted using OTP certificate and denoted as ‘protected data’. In one embodiment, the protected data can be generated using one or two methods. In the first method, the public key in OTP certificate is used to encrypt the data and in second method, a random encryption key (EK) is generated to encrypt data and EK in turn wrapped using public key of the OTP certificate.

Thus, the generation of protected data is communicated to normal OTP app 302 along with protected data (PROTECTED DATA). For example, if extensible mark-up language (XML) is used to communicate messages, the XML tags and associated data indicates how PROTECTED_DATA is generated. At step 6, OTP token details (TOKEN _DETAILS) and applications on device that can access the token is set. At step 7, OTP app details are gathered, where the OTP applications are identified using by combination of package name, certificate used to sign OTP app, version code and hash of application. At step 8, a message is generated by concatenating all protected data (PROTECTED_DATA), token details and application details. At step 9, a key hashed message authentication code (hmac) is applied on the message and the message is transmitted to OTP app and protection integrity bytes is passed as key.

The received OTP token and other details are passed by the normal OTP app 302 to the OTP framework 304. The OTP framework 304 gathers information about the caller/ OTP app from relevant platform components and forwards the token and information received from OTP server 308 to the secure OTP app 306. The secure OTP app 306 performs the following operations to retrieve the OTP secret.

At step 10, the encrypted protected data (PROTECTED_DATA) is decrypted by the secure OTP app 306 using private key of the OTP certificate to obtain OTP secret and integrity protection bytes (INTEG). Using the OTP secret and integrity bytes, a message (MSG) is prepared by combining the PROTECTED_DATA, TOKEN_DETAILS, APP_DETAILS at step 11. At step 12, hmac is applied, where MSG is passed as message and INTEG is passed as key. At step 13, it is compared whether the hmac value received from OTP server 308 matches with the hmac value generated by the secure OTP app 306. If the hmac values are matching, it is compared at step 14, whether application details received from OTP server 308 and app details passed by the OTP framework 304 are same. If yes, at step 15, the OTP secret is stored by the secure OTP app and status is communicated to the normal OTP app 302. Once the secure OTP app returns status as success, the OTP framework creates OTP token, set applications that can access OTP token and turns audit on depending on information passed by OTP server.

Figure 4 is a flow diagram illustrating a method of securely provisioning of OTP secret to a device, according to another embodiment. In this embodiment, the steps of authenticating a user/device remains same as that of steps performed in Figure 3. However, the generation of OTP certificate differs from the method mentioned in Figure 3. Here, an OTP app 402 in normal world (hereinafter called as ‘normal OTP app’) sends a OTP provisioning request to an OTP server at step 1. In response, the OTP server 408 asks the normal OTP app 402 to produce OTP certificate, nonce, pass list of trusted signers accepted by the OTP server 408, at step 2. The normal OTP app 402, at step 3, forwards the requested details to an OTP framework and instructs the OTP framework to collect caller OTP app information from a package manager along with nonce provided by the OTP server 408. At step 4, the secure OTP application 406 obtains the command from the OTP framework 404 to obtain OTP cert, pass trusted signers etc. The secure OTP application then retrieves OTP certificate, at step 5. The secure OTP app 406 then returns OTP cert to the OTP framework 406, at step 6 and then forwards to the normal OTP app 402, at step 7. In the next steps 8 to 10, the OTP application details are extracted. The secure OTP app 406 further encrypts the OTP certificate in a step by step process, wherein the secure OTP app 406 generates integrity protection bytes, at step 11 and then DATA is prepared by combining nonce, server certificate details and integrity bytes. Then, the DATA is encrypted using OTP certificate to create PROTECTED_DATA. In some embodiments, the PROTECTED_DATA can be encrypted using public key of the OTP certificate. In other embodiments, the PROTECTED_DATA can be encrypted using a random secret key. Later, a message (MSG) is prepared by the secure OTP app 406 by combining protected data (PROTECTED_DATA) and application details (APP_DETAILS).

In addition, a keyed hash message authentication code (hmac) is applied on the message, where MSG is sent as message and INTEG is key input to the normal OTP app 402. The normal OTP app then forwards the MSG, hmac value to OTP server 408 to proceed with OTP token creation. Before proceeding with the creation of OTP token, the OTP server 408 has to validate the OTP app 402. At step 12, the OTP app is validated by the OTP server 408 which comprises of decrypting the protected data to obtain nonce, server certificate details and integrity bytes. Then, hmac is applied by passing MSG as input and integrity bytes as key value which is hmac1. Now, both the hmac and hmac1 values are compared by comparing nonce value received from OTP app with nonce value sent by OTP server 408. When the nonce values are same, it is checked whether the OTP application details such as package name, app signer certificate details, app version code are valid. If valid, then OTP token related activities are performed between OTP server 408 and OTP app 402.

At step 13, the status of OTP token creation is communicated to the normal OTP app 402. Then, at step 14, both the OTP server 408 and the normal OTP app 402 proceed with OTP token creation related activities.

In one embodiment, OTP tokens audit is turned On and the OTP framework performing the following. In this embodiment, the OTP framework logs time change events on device. Further, the OTP framework logs 'OTP token' access for OTP value generation, particularly, logs for successful OTP value generation, logs for failed OTP value generation requests, and logs details of application (if Android package name + app signer certificate details) which requested an operation (create/delete/generate OTP/re-provisioning request) over 'OTP token'. Also, the applications can make use of API exposed by 'OTP framework' to read audit events related to a token. The App that created OTP token will be notified when an event related to operations on 'OTP token' such as success or failure in generating OTP values/deletion of OTP token /re-provisioning of OTP token/time change.

In one embodiment, the OTP server can make use of audit information for 'OTP token' information to check if 'OTP token' on device is used properly or not.

Figure 5A is a flow diagram illustrating a method of generating OTP certificate for securely provisioning OTP secret to a device, according to one embodiment. In the present invention, an OTP application is capable of operating in both normal and secure world and sends request to an OTP server to obtain an OTP secret. As shown in Figure 5A, the one or more entities involved in the process of generating the OTP certificate includes an OTP application in normal world 502, OTP framework 504, and a secure OTP application in a secure world 506. In one embodiment, all the entities reside in a device. Further, it is to be noted that the device has a device certificate in the secure world, wherein the device certificate corresponds to a certificate authority (CA) certificate signed by an external root CA. The device certificate also has a private key associated with it on device and stores the private key in a secure manner. Both the device certificate and the private key are provisioned to the device during device manufacturing time. The device has modules for handling device certificate and sign certificates requested by only known secure applications.

In one exemplary operation of the present invention, the OTP application in normal world, (hereinafter referred to as “normal OTP app”) 502 interacts with the secure OTP app 506 via the OTP framework 504 in order to provision the OTP secret. The step by step process for provisioning OTP secret is explained as follows. At step 1, a request to setup or initialize OTP is sent to the secure OTP app 506 by the normal OTP app 502 via the OTP framework 504. Upon receiving the request, at step 2, the secure OTP app 506 checks whether an OTP certificate is present in the device. If certificate is not present, then at step 3, a public, private key pair is created by the secure OTP app 506 in order to generate OTP certificate, wherein the public and private key pair is used in encryption of the OTP certificate. Further, information including international mobile equipment identity (IMEI), serial number of the device, extensions are used for generation of OTP certificate. Thus, the generated OTP certificate have details required to identify the device. Also, at step 4, the public key and other information are consolidated and at step 5, the OTP certificate is signed using device CA certificate to provision the OTP certificate. Then, at step 6, status of generation of OTP certificate is informed by the secure OTP app 506 to the normal app 502 via the OTP framework 504. The secure OTP app 506 also transmits the generated OTP certificate to the normal OTP app 502 in an encrypted form, wherein the generated public key is used for encrypting the OTP certificate. It is to be noted that the generated private key is made to be used only by the secure OTP app and aids in transmitting the OTP certificate to the device in a secure way.

Figure 5B is a flow diagram illustrating a method of generation of OTP certificate on a device, according to another embodiment. According to this embodiment, the one or more entities involved in generating the OTP certificate comprises of a normal OTP app 502, aa secure OTP app 504, an OTP server 506, a certificate authority (CA) server 508, and an attestation server 510. In this embodiment, the OTP app 502 in normal world requests an OTP server 506 for provisioning an OTP certificate. This is performed at step 1. When this OTP operation is triggered, the OTP server discovers that there is no valid OTP certificate is available on a respective device at step 2 and initiates certificate enrollment process. At step 3, it is checked whether platform integrity of the device is good by asking the platform to report integrity of the platform. Then, the OTP server 506 triggers attestation similar to knox attestation process with CA server 508 and asks the device to prove integrity of the platform at step 4. In response, the normal OTP app 502, at step 5, prepares the integrity report of the platform by calling relevant platform APIs which is basically signed blob that carries platform measurements and shares the report with the OTP server 506. At step 6, the integrity report is forwarded to an attestation server 510. At step 7, the measurement blob is verified by the attestation server 510 and status of the platform is returned to the OTP server 506. It is to be noted that the OTP server 506 proceed with certificate enrollment process only if the status of platform is good.

Upon verifying that the platform integrity is good, the OTP server 506 request the normal OTP app 502 to produce device encryption certificate, at step 8. The normal OTP app 502 receives the device encryption certificate along with private, public key pair from the secure OT app 504 at step 9 and provides the device encryption certificate to the OTP server 506 at step 10. At step 11, the device encryption certificate is forwarded to CA server 508 for obtaining details needed to provision OTP certificate. The CA server 508, at step 12, a challenge or secret is generated and challenge is encrypted using device encryption certificate’s public key. The CA server 508 then forwards the challenge to the OTP server 506, at step 13. At step 14, the encrypted challenge, details about CA server URL and information needed to perform certificate enrollment is forwarded to the normal OTP app on the device. At step 15, the normal OTP app 502 generates a certificate signing request and passes the request along with encrypted challenge to the secure OTP app 504.

At step 16, the challenge is decrypted by the secure OTP app 504 using the private key of the device encryption certificate and key pair is generated. Further, at step 17, the CSR is signed by secure OTP app 504 using device signing certificate so as to enable the CA server 508 to establish that it is the right secure app that generated key pair and signed CSR. In addition, since the challenge is encrypted using device encryption cert, it can be decrypted only by secure app that has access to private key of device encryption certificate. Also, by system design, CSR will be signed by device signing certificate only if it is called from OTP secure app or from limited set of trustworthy apps in secure world. Hence, even if challenge is copied by app in normal Android world, CSR can be generated, however it will not be able to sign using device signing certificate as they won't have access to device signing certificate's private key.

At step 20, the signed CSR which is received from secure OTP app 504 is forwarded to the CA server 508 by the normal OTP app 502. The CA server executes relevant certificate enrollment method such as SCEP (Simple Certificate Enrollment Protocol), EST (Enrollment over Secure Transport) or proprietary protocol between ‘OTP app’ and CA server 508. The CA server 508, after necessary validation which also includes checking if CSR is signed by trust device signing certificate and issues OTP certificate to the normal OTP app 502. The normal OTP app 502 instruct the secure OTP app to add the certificate in a relevant store at step 23. At step 24, the OTP certificate is stored and the status is informed to the normal OTP app 502, AT step 25.

Figure 6 is a block diagram illustrating one or more components of a device for securely receiving the OTP secret, according to one embodiment. As shown in Figure 6, the device comprises of a processor 602, a memory 604, a normal OTP application 606, an OTP framework 608 and a OTP secure application 610. The device may further comprise of display units and other processing units. A person skilled in the art understands the functioning of these components and hence not explained in detail herein.

The processor 602 in one embodiment coupled to a memory 604. The processor 602 can be an Application Specific Integrated Circuit that embodies at least part of the method in accordance with an embodiment of the present invention in hardware and/or firmware. An example of an ASIC is a digital signal processor. The processor 602 can also be a general purpose microprocessor, such as the Pentium IV processor manufactured by the Intel Corporation of Santa Clara, Calif. Token memory 604 can be any device adapted to store digital information, such as Read Only Memory (ROM), Electronically Erasable Read Only Memory (EEPROM), Random Access Memory (RAM), a hard disk, flash memory, etc.

The memory 604 may store an OTP certificate public key, private key received from a secure OTP application, hmac key etc. These secrets can be stored more securely by implementing tamper resistant features for memory 604, as is known in the art. The memory 604 can also public key and private key of device encryption certificates adapted to be executed by the processor 602 to perform functions such as OTP secret generation, communication with the attestation server, communication with the CA, communication with application programs with which the token interoperates, etc.

Although the invention of the method and system has been described in connection with the embodiments of the present invention illustrated in the accompanying drawings, it is not limited thereto. It will be apparent to those skilled in the art that various substitutions, modifications and changes may be made thereto without departing from the scope and spirit of the invention.

,CLAIMS:

Claims
We claim:

1. A method for securely provisioning and binding one-time password (OTP) secret to a device, the method comprising the steps of:
receiving, by an OTP Server, a request from an OTP application residing in a device for provisioning an OTP secret to the device, wherein the OTP application is capable of operating in a normal world and in a secure world;
authenticating, by the OTP server, the OTP application in response to the received request;
requesting, by the OTP server, the OTP application on the device to produce an OTP certificate to securely transport the OTP secret to the device;
generating, by the device, an OTP certificate by a secure OTP application on device;
validating, by the OTP server, the received OTP certificate with root certifying authority (CA);
generating, by the OTP server, an OTP Token using the validated OTP Certificate;
extracting, by the device, the OTP Secret by the Secure OTP application and validating the OTP Token data.
storing, by the device, the extracted OTP Secret in secure world, thereby enabling the OTP application to securely access the OTP secret.

2. The method as claimed in claim 1, wherein the OTP certificate is a unique certificate associated with the device.

3. The method as claimed in claim 1, wherein generating OTP certificate by the secure OTP application comprises of:
receiving, by the secure OTP application, a request from the normal OTP application to create OTP certificate;
checking, by the secure OTP application, whether any OTP certificate associated with the device is available in the device;
generating, by the secure OTP application, a public-private key pair for the OTP certificate if the OTP certificate is unavailable in the device;
creating, by the secure OTP application, subject information for OTP certificate to uniquely identify the device, wherein the subject information comprises of International Mobile Station Equipment Identity (IMEI), serial number of the device and extensions for the indication of OTP certificate;
signing, by the secure OTP application, the OTP certificate using Device certificate which is in turn signed by the root certificate authority (CA) to generate OTP certificate; and
storing the generated private Key associated with the OTP certificate in the secure world.

4. The method as claimed in claim 1, wherein generating OTP certificate by secure OTP application comprises of:
forwarding, by the OTP server, a device encryption certificate received from normal OTP application to a CA server for obtaining information needed to provision the OTP certificate;
generating, by the CA server, a challenge and encrypting the challenge using the device encryption certificate for transmitting the encrypted challenge to the OTP server;
forwarding, by the OTP server, the encrypted challenge along with URL of CA server to the normal OTP application to provision the OTP certificate;
generating, by a secure OTP, certificate signing request (CSR), key pair for embedding the challenge in the CSR,wherein the CSR is signed using device signing certificate;
providing, by the secure OTP application, the CSR to the CA server for allowing the CA server to execute certificate enrollment protocol between the normal OTP application and the CA server;
providing, by the CA server, the OTP certificate to the device after validating the CSR.

5. The method as claimed in claim 1, further comprising:
checking, by the OTP server, device platform integrity for the provisioning of the OTP certificate.

6. The method as claimed in claim 5, wherein checking device platform integrity comprises of:
requesting, by the OTP server, the device to provide device integrity measurement;
transmitting, by the normal OTP application, device integrity measurement to the OTP server in response to the request, wherein the blob carries measurements of the device platform;
forwarding, by the OTP server, the device integrity measurements received from the normal OTP application to an attestation server for verification; and
indicating, by the attestation server, the status of the device platform based on the integrity measurements forwarded to the OTP server.

7. The method as claimed in claim 1, wherein OTP certificate is an X.509 certificate.

8. The method as claimed in claim 1, wherein OTP certificate is certificate chain.

9. The method as claimed in claim 1, wherein the OTP application is configured to run in both normal world and in secure world.

10. The method as claimed in claim 1, wherein generating the OTP Token comprising the steps of:
validating, by the OTP server, the OTP certificate provided by the OTP application with the Root CA;
generating, by the OTP server, an OTP token along with OTP secret, details of OTP algorithm and integrity protection bytes after validating the OTP certificate;
generating, by the OTP server, the data by combining the generated OTP secret and integrity protection bytes;
encrypting, by the OTP server, the generated data using OTP certificate;
collecting, by the OTP server, information regarding the OTP application;
generating, by the OTP server, a message by combining data, OTP token details and OTP application details;
applying, by the OTP server, a keyed-hash message authentication code (hmac) to the generated message to obtain a hmac value, wherein the message is transmitted as message and integrity protection bytes is passed as key.
transmitting the message and hmac value to the OTP application.

11. The method as claimed in claim 1, wherein the step of extracting the OTP Secret by the secure OTP application and validating the OTP Token data comprises of:
decrypting, by the secure OTP application, data using private key of the OTP certificate to obtain OTP secret and integrity protection bytes;
receiving, by the secure OTP application, details of token and application from the normal OTP application;
preparing, by the secure OTP application, a message by combining data, details of OTP token and OTP application;
applying, by the secure OTP application, keyed hmac to the message and as integrity protection bytes as key to create a hmac value;
comparing, by the secure OTP application, whether hmac value calculated by Secure OTP application matches with the hmac value provided by OTP server; and
storing, by the secure OTP application, the OTP secret, if the hmac value calculated by the secure OTP application matches with the hmac value provided by the OTP server.

12. A device comprising:
A processor;
A memory coupled to the processor, wherein the memory separately comprising:
A normal OTP application adapted to
send a request to an OTP server for provisioning an OTP secret to the device;
produce an OTP certificate to the OTP server to securely transport the OTP secret to the device; and
a secure OTP application adapted to
generate an OTP certificate on device;
to receive OTP token generated by the OTP server;
extract the OTP Secret and validate the OTP Token data; and
store the extracted OTP Secret to securely access the OTP secret.

Dated this the 22nd day of July 2016
Signature

KEERTHI J S
Patent agent
Agent for the applicant