Patent Application
20170244692
The present invention relates generally to user authentication, and more particularly to a secure mechanism for authenticating a user using a security device.
In the brief history of mobile communications devices, the devices have quickly evolved from being primarily or even exclusively dedicated to mobile telephone communication to being extraordinarily powerful multi-purpose devices. With recent technical developments it is now possible to use mobile devices, e.g., mobile telephones, for disparate applications such as payment, transportation ticketing, loyalty programs, bank account access, access control for physical access to buildings or offices, etc. A consequence of the versatility of mobile devices is that mobile computing is becoming an increasingly important tool in the digital identity landscape, partly because of the personal nature of the mobile devices as users increasingly consider their mobile phone and mobile number as identity attributes, and partly because of the unique technological characteristics of mobile devices.
SIM cards connected to mobile devices provide secure network connectivity to mobile devices; as such SIM cards represent some of the most sophisticated security technology available. Furthermore, Mobile Network Operators (MNOs) are very experienced with registering customers, managing data, and developing fraud detection and prevention tools. It is desirable to make use of these complementary technologies in the domain of providing user identity and authentication.
One current technology for using a mobile device as an identity document is the GSMA Mobile Connect technology (GSM Association, headquartered in London, UK), which enables MNOs to act as Identity Providers (IdPs) so that users can authenticate to Service Providers (SPs) using their mobile devices. GSMA Mobile Connect is described at https://developer.mobileconnect.io/docs_overview (accessed on Dec. 16, 2015). Typically GSMA member companies, such as Gemalto S. A., headquartered in Amsterdam, The Netherlands, implement Mobile Connect on both the identity provider (IdP) side and the mobile device side. On the mobile device, Mobile Connect relies on the SIM that is connected to the mobile device and there is a SIM Applet, which executes on the SIM to support the Mobile Connect authentication protocol.
Unfortunately, hitherto the adopted architectures and protocols for Mobile Connect are burdensome in at least two regards, affecting both development and deployment costs, namely: a heavy registration and provisioning process and a large footprint for the Mobile Connect Authentication SIM Applet. (Herein, the term “applet” or “the applet” is used as shorthand for a SIM applet that provides registration and authentication services on behalf of a user using a mobile device.)
Heavy Registration and Provisioning Process.
Registration of a mobile device as an authentication device is typically a very involved process due to the various activities involved, such as language setting and establishment of a shared One-Time-Password (OTP) seed. For example, Gemalto's OCRA (OATH-OCRA is described in D. M'Raihi, OCRA: OATH Challenge-Response Algorithm, Internet Engineering Task Force (IETF) Request for Comments: 6287, (2011)) implementation requires 13 distinct GSM SMS messages in order to complete registration. Such a heavy registration process demands significant resource usage, which can be difficult to attain, for example, in areas with low bandwidth.
High Applet Footprint.
Current applets used in UICCs in conjunction with mobile devices to provide identity services have a very large applet footprint. For example, for a level of assurance (LoA) of 2 or 3, OATH OCRA applet size is approximately 12 KB; for a 3DES (Digital Encryption Standard) the applet size is approximately 8 KB. For a more complex level of assurance the applet size is even larger, such as with LoA 4, which typically requires an applet size of approximately 50 KB. Level of assurance refers to the degree of certainty associated with an identity assertion made by an identity provider by presenting an identity credential to a relying party (RP), e.g., a service provider. The levels of assurance (LoA) as used herein are defined by GSMA Mobile Connect Specification, and should not be confused with LoA defined by National Institute of Standards and Technology (NIST).
Complex applets and their correspondingly large applet footprints present several problems:
From the foregoing it will be apparent that there is still a need for an improved method to provide a flexible, convenient and yet powerful mechanism to provide for reliable identity authentication using a mobile device and a security device associated therewith while both streamlining the registration and provisioning process and also minimizing the footprint of the applet executing on the security device.
In the following detailed description, reference is made to the accompanying drawings that show, 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. It is to be understood that the various embodiments of the invention, although different, are not necessarily mutually exclusive. For example, a particular feature, structure, or characteristic described herein in connection with one embodiment may be implemented within other embodiments without departing from the spirit and scope of the invention. In addition, it is to be understood that the location or arrangement of individual elements within each disclosed embodiment may be modified without departing from the spirit and scope of the 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, appropriately interpreted, along with the full range of equivalents to which the claims are entitled. In the drawings, like numerals refer to the same or similar functionality throughout the several views.
In an embodiment of the invention, a technology is presented that provides a mechanism by which a security device, e.g., a universal integrated circuit card (UICC) such as a GSM subscriber identity module (SIM) card, may be used to secure provisioning of identity of a user using a mobile device in a secure and efficient manner which requires a UICC applet having a relatively small footprint. The presented mechanism allows for such applets to be developed that may be readily downloaded or installed in a UICC in a fashion in which the applet is ready for immediate use in registering a mobile device into a system in which a mobile network operator may act as an identity provider such that users may use their mobile device as an authentication medium for access to service provider services.
Conceptually, the technology presented herein reduces and simplifies the activities that the identity applet of the security device performs, transferring some activities to the server side, e.g., to an authentication server, while maintaining the security device connected to the mobile device as a security enabler. In one embodiment, user interaction and security level is maintained consistent with existing SIM-based user authentication, i.e., at LoA 2 and 3 as defined in the GSMA Mobile Connect Specification.
The SPs 114 may provide any of a myriad of possible services. Typical examples include online banking, online commerce, online instruction, online voting, etc. As a reader hereof appreciates, in these examples transaction security is extremely important.
A user 101 operates a user computer 105 to interact with one of the SP servers 115 over the network 113. Such interactions are advantageously performed using general-purpose web browser programs downloaded to the computer 105. Such web browser programs may execute particular web applications during interactions between the web browser and server software of the service provider 115.
A user 101 may also interact with service providers 115 using mobile device 103. Such interaction may also be via general-purpose web browsers. However, more common interaction between a user 101 using a mobile device 103 and a service provider 115 is by way of special purpose applications, also known as apps, that provide the user with a feature rich environment through which the user 101 interacts with server applications.
As discussed herein above, an aspect of interaction between a user 101 and a service provider 115 is provisioning of the identity of the user 101 to the service provider 115 using the mobile device 103. This interaction includes the secure authentication of the provided user identity using a security device 107 connected to the mobile device 103. As described herein above, GSMA Mobile Connect provides an example of such technology.
When a user 101 seeks to interact with a service provider 115, the user 101 may be identified using the user's mobile device 103 through the network 111 of a mobile network operator (MNO). Indeed, the network 111 may connect to other mobile networks and to the publically switched telephone network (PSTN). Network 111 should be considered to include all such alternatives. However, for the sake of a streamlined presentation of the technology, the technology is described as if the service providers and user mobile device 103 are connected to one network 111.
The network 111 contains three principal nodes according to a preferred embodiment:
The NVM 205 may include computer programs 301 as is illustrated in
The security device 107 programs 301 may include a cryptography module 213, a communications module 217, and the operating system OS 219.
As discussed herein above, an identity applet 215, executing on the security device 107, is used to receive secure registration and authentication requests from the authentication server 118 and create responses for these request to the authentication server 118.
The server-side, e.g., the authentication server 118, is the principal actor in the mechanism. The identity applet of the security device complements the server-side by managing interaction with the user 101 and performing required security tasks. For example,
Security of requests transmitted from the authentication server 118 to the security device 107 is ensured using 03.48 OTA Security.
Registration of a Mobile Device for Use as an Identity and Authentication Device
There are two principal phases to the use of a mobile device 103 as an identity and authentication device for use with a service provider 115: the registration phase in which a user registers the mobile device 103 with an authentication server 118 and the authentication phase in which the user confirms to the authentication server 118 an attempted use of the mobile device 103 to authenticate to a service provider 115.
Turning first to the registration phase.
A user 101 seeks to register the user's mobile device 103 for authentication to the service provider 115. The user causes either the mobile device 103 or the computer 105 of the user to start the registration process by sending a registration message to the identity gateway 116, step 1, optionally through the service provider 115.
The identity gateway 116 responds by requesting the user to enter an identifier, e.g., the MSISDN of the user's mobile telephone or an alternate identifier, step 2.
The user 101 enters the MSISDN or alternate identifier on whichever device the user is using to interact with the identity gateway 116, e.g., on the host computer 105, step 3, and that response is transmitted to the identity gateway 116.
The identity gateway 116 forwards the identifier to the authentication server 118, step 4.
In an alternative embodiment the identity gateway 116 and the authentication server 118 are merged.
The authentication server 118 builds and transmits a registration authentication request to the security device 107 via the OTA server 120 to verify the mobile device 103, step 5. For LoA 2, the registration authentication request merely requires the user 101 to acknowledge and OK the registration request. For LoA 3, the user 101 is requested to enter a PIN that is to be used in future authentication activities wherein the mobile device 103 is used to authenticate a user to the service provider 115. The registration authentication request includes transaction ID, LoA, user interface text to be displayed to the user 101 on the mobile device 103 and a nonce that is used either as a key for the response sent back to the authentication server 118 or from which a key is derived. The registration authentication request message may contain a salt to be used by the applet 215 executing on the security device 107 to compute a salted hash of the PIN which is included in the response message that the security device 107 transmits back to the authentication server 118. In yet another alternative embodiment, the registration authentication request message may contain a pepper, e.g., an iteration number.
Upon receiving the registration authentication request (step 5), the security device 107 causes the user interface text to be displayed on the mobile device 103.
For the LoA 2 case 401, the user 101 clicks “OK” or “Cancel” on the mobile device 103 in response to the security device 107 and the security device 107 creates a response message based on the user input, step 6. The security device 107 encrypts the response message using the nonce from the registration authentication request. The nonce can either be used directly, or a derivation can be performed on the nonce to generate the cryptographic key used in encrypting the response.
The security device 107 transmits the response back to the authentication server 118, step 7.
For the LoA 3 case 403, the user is required to create a PIN. The user 101 may be required to enter the PIN twice and check that both are the same, step 8.
The security device 107 computes a salted crypto hash from the PIN using either a salt (a random data) sent by the server or, if no salt, using the nonce (or a portion of the nonce) sent by the server as a salt, resulting in H=saltedhash (PIN,salt), step 9. If the registration authentication request message contains a pepper (another random data), the salted hash of the PIN is computed using both the salt and the pepper. The applet constructs a response, which includes H and any other data required for a response and encrypts the response directly or indirectly using the nonce as a key, step 10. The encryption key may be derived from the nonce.
The security device 107 deletes the PIN, the user interface text, etc., step 11.
In response to receiving the registration request response, either response 7 or response 10, the authentication server 118 decrypts the response using the nonce (or using a key derived from the nonce) and records the response, i.e., either recording that the user has acknowledged and acquiesced to the use of the mobile device as an authentication device, has not acquiesced to such use, or records the salted hash of the PIN if the LoA requires a PIN entry by the user and the salt, step 12. In the alternative embodiment that also includes a pepper, the authentication server 118 also stores the pepper so that it may be communicated to the security device 107 during subsequent authentication verification steps.
As is discussed herein below in the discussion of the authentication phase, because the authentication server 118 knows the salt as well as the salted hash of the PIN, in one embodiment, the subsequent authentication request responses is encrypted by the security device 107 using a key that is derived from the nonce coming with the authentication request and the salted hash of the PIN. The authentication server 118 may then derive the same key as the one generated by the secure device 107 and decrypt the response. The response itself does not need to contain the PIN nor the salted hash of the PIN.
Subsequently, the identity gateway 116 may send a query to and receive a response from the authentication server about the registration status of the mobile device, step 13, and the identity gateway 116 informs the user device to inform the user the status of the registration, step 14, e.g., “Your device has been registered for use as an authentication device with service provider XYZ,” step 14.
Thus, at the conclusion of the process of
In a first alternative embodiment, the authentication server 118 applies additional hashing (with salt or pepper) on top of PIN Hash received in response. In this embodiment, the authentication server 118 stores the resultant hash along with the salts or peppers involved. In this embodiment, the authentication server 118 derives the encryption key for authentication messages from the nonce.
In a second alternative embodiment, the PIN is managed on the security device 107, for example, by the identity applet 215. In this case, the PIN is stored locally by on the security device 107 and the PIN data is not sent in the registration response of Step 10. Of course, in that embodiment, the PIN is not deleted by the identity applet 215 as discussed herein above.
Authentication of an Attempt to Use the Mobile Device as an Authentication Device.
Turning now to the use of the mobile device 103 as an authentication device when a user seeks to access services provided by a service provider 115. If the mobile device 103 of the user has affirmed the registration, and, in the case of LoA 3, created a PIN, the mobile device 103 may be used as an authentication device for authenticating the user 101 to the service provider 115.
Consider the LoA 2 case wherein the authentication is merely acknowledged by the user 101 on the mobile device 103. A user 101 operating a user device 105 (note that if the user device is the mobile device 103, a case that is included herein as if mobile device 103 serves both as a user device 105 on which an interaction with a service provider 115 takes place as well as a mobile device 103 used for authenticating the service provider 115) uses a web browser program on the user device 105 to access a service provider web site on the service provider server 115, step 61.
The service provider 115 requires user authentication of the user 101 and transmits an authentication request to the authentication server 118 via the identity gateway 116, step 62.
The authentication server 118 builds an authentication request and transmits it to the security device 107 via the OTA server 120, step 63. The authentication request contains: a transaction ID, specification of required LoA, a nonce, and user interface text to be displayed to the user 101 on the mobile device 103 and an indication to the mobile device indicating which actions the user may take, e.g., “OK”, “Cancel”, “Yes”, “No”. The nonce is used in conjunction with the user's response to derive a key used to encrypt a response from the security device 107. In a preferred embodiment the authentication request is transmitted securely using OTA secure transport, e.g., using secure SMS messages.
The security device 107 receives the authentication request message and verifies the request, step 64. The security device 107 decrypts the OTA message and forwards the message to the applet 215. The applet validates the request.
The user interface text and UI elements are displayed on the mobile device 103, step 65.
The user 101 enters a response, which is transmitted back to the security device 107, specifically, the applet 215, step 66.
Having received the user response, for an LoA 2 case, the user's response is encrypted using a key derived from the nonce provided by the server in the authentication request message and the user response, step 67. The response would contain: a) the transaction id received in the request; b) the status code pertaining to the user action. In case the User Action is “OK”, the text displayed can also be included.
The encrypted response is transmitted back to the authentication server 118, for example, using an SMS message to the OTA server 120, step 68, which forwards it to the authentication server 118, step 69.
The authentication server 118 decrypts the received response and verifies the user action by the status code, step 70. As the message is encrypted using a key derived from the nonce sent in the authentication request message as well as the user response, a correct decryption that results in a verifiable transaction ID and an appropriate status code may be used to confirm that the response was created by the security device 107 in response to the authentication server 118. The nonce acts as a one-time-key. Only responses that are encrypted in response to new authentication request messages will be accepted as verified authentication acknowledgement from the user 101 operating the mobile device 103. By deriving possible keys from the various possible user responses (together with the nonce), the authentication server 118 determines which user response was provided by the user.
Note that while it is preferable to use the nonce together with the user response to derive the encryption key for the response message, in an alternative embodiment, only the nonce is used to derive the encryption key or, in yet another alternative, the nonce is used directly as an encryption key.
The authentication status may be transmitted to the service provider 115, step 71, which forwards a status to the user 101 on the web browser application on the user device 105, step 72.
Steps 61 through 64 are analogous to the same-numbered steps of
As the flow of
Steps 65 and 66 are also analogous to the like-numbered steps of
Continuing with
In an alternative embodiment, a further integrity check is included in the response. The applet 215 computes a hash of the response, or of some relevant elements, e.g., the result of the operation (i.e., “OK”, “Cancel”, “Timeout”), a portion or the entire display text, or a hash of the PIN.
The response is transmitted back to the authentication server 118 via the OTA server 120, step 69, for example, in the form of an SMS message, step 68.
The authentication server 118 derives the key for the received message using the stored hash of the PIN and the nonce transmitted in the authentication request message, step 82. If the authentication server 118 is able to interpret the decrypted message that is an indication that the PIN was entered correctly as the derived keys must then match.
As the authentication server 118 does not know whether a PIN was entered or not, the authentication server 118 may need to try both a derived key from the salted hash of the PIN and from the nonce alone. Thus, if the authentication server 118 cannot interpret the response using a key it derives from the PIN and the salted hash, it attempts to decrypt the response message using a key derived from the nonce alone, which corresponds to the user 101 not having entered a PIN, step 83.
In the alternative embodiment, which includes an integrity check, the authentication server 118 verifies the integrity hash to confirm the integrity of the response.
If neither step 82 nor 83 result in a response that the authentication server 118 may interpret, the authentication attempt has failed. Similarly, if the response is decoded to correspond to a cancel or timeout, the authentication is declined.
The authentication server 118 responds to the service provider 115 with the authentication status, step 71, and the service provider 115 may notify the user of the user device 105 of the authentication status, step 72.
In an alternative embodiment, the PIN is established on the server side. During registration the user 101 sets the PIN at the server portal accessed using a web browser via the user device 105. The authentication server 118 stores the PIN safely. In this embodiment, during the registration process, the authentication server 118 transmits a verification request message to the mobile device 103, which forwards the verification request message to the security device 107. On the security device 107, the applet 215 verifies the PIN as follows:
For illustrative purposes, we describe the technology presented herein as it may be used in a mobile device 103. However, the technology presented is applicable to any programmable electronic device with a need for a secure trusted execution environment.
A number of advantages are achieved using the herein described technology. The technology improves the use of a mobile device having a security device connected thereto in that a security device applet used to provide security functionality in provisioning of identity and authentication of a user using a mobile device has a significantly smaller footprint than prior art applets. This advantage is achieved both by avoiding storage of a PIN on the security device and avoiding storage of user interaction prompts on the security device because PIN prompts are provided from the authentication server 118. Further, transport keys are not stored on the security device (other than OTA transport keys which are stored on the security device for other purposes) as the transport keys are derived from information provided by the authentication server 118 to the security device 107 during both the registration and authentication processes.
The provisioning of the applet 215 is robust because the applet 215 may be either preloaded on the security device 107 or readily downloaded without the need for personalization; the applet 215 is ready to use as soon as it is installed on the security device 107.
The registration and provisioning process is reduced to a single SMS message. Minimizing the number of SMS messages is a great advantage to end-users as the provisioning process can occur very quickly with a minimum of resource usage. That advantage likely produces a higher user acceptance of the process and end-users are likely to see a benefit in using their mobile device as an identity device rather than to see it as a hindrance to using service provider services. That, in turn, provides service providers an incentive to adopt mobile devices as optional or required identity devices for use with their services.
The herein described technology provides a high level of security, as no sensitive information is stored on the security device 107 to enable its use as a mobile identity device. Transport security for messages sent in both directions is at least as high as the security defined by 3DES encryption. Both mobile originated and mobile terminated messages are encrypted, which provides a higher level of security than conventional OTA secure transport.
Because the applet 215 is relatively small, the applet 215 may be download using OTA provisioning. This is a significant advantage in that mobile identity may be provided using a security device 107 to secure the authentication even on mobile devices for which the security device 107 is not pre-provisioned with an applet to provide the requisite functionality to secure mobile device identity and authentication.
While the technology described herein above is advantageously applied to the authentication of a mobile device 103 for use as an authentication device for authenticating a user 101 to a service provider 115, the technology also has other applications. For example, the mechanisms described herein may be advantageously used to obtain user confirmation of electronic transactions, i.e., to provide an out-of-band verification of a user. The technology may also be used to obtain consent of a user 101 to particular transactions that are attempted, for example, using a user device 105 interacting with a service provider 115.
From the foregoing it will be apparent that a technology has been presented that improves the mechanisms used to authenticate a user by a service provider through an identity provider and a security device in a mobile device.
Although specific embodiments of the invention have been described and illustrated, the invention is not to be limited to the specific forms or arrangements of parts so described and illustrated. The invention is limited only by the claims.
