US20180295121A1 - Secure element authentication - Google Patents

Abstract

Secure element authentication techniques are described. In implementations, a confirmation is received that an identity of a user has been physically verified using one or more physical documents. One or more credentials that are usable to authenticate the user are caused to be stored in a secure element of a mobile communication device of the user, the secure element implemented using tamper-resistant hardware.

Description

CROSS-REFERENCE TO RELATED APPLICATION
• This application is a continuation of U.S. patent application Ser. No. 15/340,493, filed Nov. 1, 2016, which is a continuation of U.S. patent application Ser. No. 12/959,715, filed Dec. 3, 2010, which are both hereby incorporated by reference herein for all purposes.
BACKGROUND
• Mobile communication devices such as wireless phones have become a common part in the everyday life of a wide variety of users. Consequently, the mobile communication device may serve as a primary point of contact for a variety of business and personal uses. For example, a business user may utilize the mobile communication device to receive email, a casual user may send text messages to friends, either one of the users may share pictures, and so on.
• However, traditional techniques that were employed to securely store data on the mobile communication device as well as to communicate data to the mobile communication device could result in the data being “in the clear.” Even if but for a brief moment in time, malicious parties may take advantage of this vulnerability to steal sensitive data. This may even result in the ability by the malicious party to access other information on the mobile communication device itself. Consequently, functionality of the mobile communication device may be limited from meeting its true potential due to the ability to compromise data on the mobile communication device.
SUMMARY
• Secure element authentication techniques are described. In implementations, a confirmation is received that an identity of a user has been physically verified using one or more physical documents. One or more credentials that are usable to authenticate the user are caused to be stored in a secure element of a mobile communication device of the user, the secure element implemented using tamper-resistant hardware.
• In one or more implementations, a challenge is received at a mobile communication device to authenticate an identity of a user of the mobile communication device. The challenge is processed by a secure element of the mobile communication device using one or more credentials, the challenge being processed without exposing the one or more credentials outside of hardware that implements the secure element. An answer to the challenge is exposed by the secure element.
• In one or more implementations, a mobile communication device comprises a secure element implemented in tamper-resistant hardware that is configured to decrypt credentials using a private key included in the secure element and store the credentials once decrypted in the secure element, the credentials configured to authenticate a user of the mobile communication device for access to a resource.
• This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
BRIEF DESCRIPTION OF THE DRAWINGS
• The detailed description is described with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The use of the same reference numbers in different instances in the description and the figures may indicate similar or identical items.
• FIG. 1 is an illustration of an example implementation of a mobile communication device in accordance with one or more embodiments of devices, features, and systems for mobile communications.
• FIG. 2 is a flow diagram depicting a procedure in an example implementation in which a public key is located to communicate with a mobile communication device.
• FIG. 3 is a chart depicting a procedure in an example implementation in which a technique to communicate data securely to a mobile communication device is shown
• FIG. 4 is a flow diagram depicting a procedure in an example implementation in which a technique to receive and process data received by a mobile communication device from a provisioning service is shown.
• FIG. 5 is a flow diagram depicting a procedure in an example implementation in which example operation of a secure element ofFIG. 1 is shown.
• FIG. 6 is a flow diagram depicting a procedure in an example implementation in which credentials are stored in a secure element responsive to a confirmation that an identity of a user has been verified using physical documents.
• FIG. 7 is a flow diagram depicting a procedure in an example implementation in which credentials are provisioned on a mobile communication device that are usable to authenticate a user's identity.
• FIG. 8 is a flow diagram depicting a procedure in an example implementation in which a secure element of a mobile communication device is configured to answer a challenge that is usable to authenticate an identity of a user.
• FIG. 9 is a flow diagram depicting a procedure in an example implementation in which an answer to a challenge processed by a secure element of a mobile communication device is used as part of a multi-tier remote authentication technique.
• FIG. 10 illustrates various components of an example device that can be implemented in various embodiments as any type of a mobile device to implement embodiments of devices, features, and systems for mobile communications.
DETAILED DESCRIPTION
• Overview
• Mobile communication devices (e.g., wireless phones) are configured to provide a wide variety of functionality. However, data may be compromised on the mobile communication devices using traditional techniques. Therefore, the mobile communication device may not realize its true potential.
• Secure element authentication techniques are described through use of a variety of different examples. In implementations, a secure element may be employed to authenticate an identity of a user. For example, the secure element may be implemented using tamper-resistant hardware, such as an integrated circuit secured to a printed circuit board that is to resistant snooping and removal from the board. The secure element may be configured to maintain credentials that are usable to authenticate an identity of a user. The credentials may be utilized in a variety of different ways to authenticate the user, such as communicated via a secure communication channel, usable to answer a challenge without exposing the credentials themselves, and so on. Further, authentication may be utilized for a variety of purposes, such as to access resources including an online account, serve as a signature to sign a document, and so on, further discussion of which may be found in relation to the following sections.
• In the following discussion, a variety of example implementations of a mobile communication device (e.g., a wireless phone) are described. Additionally, a variety of different functionality that may be employed by the mobile communication device is described for each example, which may be implemented in that example as well as in other described examples. Accordingly, example implementations are illustrated of a few of a variety of contemplated implementations. Further, although a mobile communication device having one or more modules that are configured to provide telephonic functionality are described, a variety of other mobile devices are also contemplated, such as personal digital assistants, mobile music players, dedicated messaging devices, portable game devices, netbooks, and so on.
• Example Environment
• FIG. 1 is an illustration of an example implementation of anenvironment100 that is operable to employ the techniques described herein. The environment includes aservice provider102, amobile communication device104, and aprovisioning service106 that are illustrated as communicatively coupled, one to another, via anetwork108. Although thenetwork108 is illustrated as the Internet, the network may assume a wide variety of configurations. For example, thenetwork108 may include a wide area network (WAN), a local area network (LAN), a wireless network, a public telephone network, an intranet, and so on. Further, although asingle network108 is shown, thenetwork108 may be representative of multiple networks.
• Themobile communication device104 is further illustrated as including acommunication module110. Thecommunication module110 is representative of functionality of themobile communication device102 to communicate via thenetwork108. For example, thecommunication module110 may include telephone functionality to make and receive telephone calls, such as by employing a telephone module to communicate via a plain old telephone service (POTS), wireless network (e.g., cellular and/or Wi-Fi), and so on.
• Thecommunication module110 may also include a variety of other functionality, such as to capture content, form short message service (SMS) text messages, multimedia messaging service (MMS) messages, emails, status updates to be communicated via a social network service or micro-blog, and so on. For instance, thecommunication module110 may also support browser functionality to browse thenetwork108.
• Themobile communication device104 is further illustrated as including asecure element112. In one or more implementations, thesecure element112 is representative of functionality to support secure communications with themobile communication device104. For example, thesecure element112 may be implemented using hardware and configured during manufacture to include aprivate key114, securely provision later, and so on. For instance, thesecure element112 may be implemented using a tamper-resistant integrated circuit that is resistant to “snooping” as well as physical removal from themobile communication device104 by a manufacturer of the device. For example, the manufacturer may cover a surface-mounted integrated circuit with an epoxy that helps to prevent snooping of the circuit as well as causing the circuit to break if removal is attempted from a circuit board. Further, this manufacturing process may be auditable to ensure that theprivate key114 is kept secret.
• In implementations, thesecure element112 includes functionality to perform a variety of different options, such as encryption and/or decryption operations, store credentials, and so on. For example, thesecure element112 may use theprivate key114 to perform a decryption operation and expose a result of the operation to other functionality of themobile communication device104, such as to one ormore applications116 that are executable by themobile communication device104.
• In this example, thesecure element112 may receive data to be decrypted from theapplication116, decrypt the data using theprivate key114, and then expose a result of the decryption operation (i.e., the decrypted data) to theapplication116. Therefore, inclusion of theprivate key114 in thesecure element112 may help to protect theprivate key114 from discovery “outside” thesecure element112 by keeping theprivate key114 from being exposed in the clear during the decryption operation.
• A variety of other functionality may also be supported through use of thesecure element112. For example, thesecure element112 may support a protected communication channel through theprovisioning service106. Theprovisioning service106, for instance, may include aprovisioning module118 andstorage120. Thestorage120 may be used to maintain aserial number122 assigned to an integrated circuit that includes thesecure element112 and a correspondingpublic key124 that forms an asymmetric public/private key pair with theprivate key114 of themobile communication device104. Theprovisioning module118 may thus provide thepublic key124 to third-party services such that communication between the third-party service and themobile communication device104 is protected, even if that communication occurs using theprovisioning service106 or other service as an intermediary.
• For example, a user of themobile communication device104 may interact with thecommunication module110 or other functionality (e.g., an application116) to navigate to aservice provider102 over thenetwork108. Theservice provider102 as illustrated includes aservice module126 that is representative of functionality to provide one or more services for access via thenetwork108.
• An example of one of these services is illustrated as implemented by anapplication service module128. Theapplication service module128 is representative of functionality to manage dissemination of one ormore applications130 via thenetwork108. Although theapplications130 are illustrated as stored instorage132 local to the service provider102 (e.g., as part of a server farm that implements the service provider102), thestorage132 may be representative of a wide variety of different types of storage, e.g., third party storage.
• In an example, the application service module138 manages a marketplace configured to provideapplications130 for purchase via thenetwork108. Therefore, a user of themobile communication device104 may access the marketplace to purchase one or more of theapplications130 for download to local storage, which is illustrated asapplication116 in this example. To purchase and/or transport theapplication130, themobile communication device104 and theservice provider102 may utilize secure communications implemented at least in part through use of thesecure element112. The secure communications may be implemented in a variety of ways.
• In one instance, thepublic key124 is provided to secure communications between theservice provider102 and themobile communication device104 directly. For example, thepublic key124 may be located by theprovisioning module118 of theprovisioning service106 by obtaining aserial number122 for the integrated circuit that implements thesecure element112, e.g., from themobile communication device104. Theprovisioning module118 may then use theserial number122 to locate thepublic key124 and provide thepublic key124 to theservice provider102. Thepublic key124 may then be used to encrypt data to be communicated to themobile communication device104, such as theapplication130, billing information and other credentials, and so on.
• In another instance, theprovisioning service106 provides thepublic key124 to theservice provider102 as a basis to support indirect communications, such as to securely transport credentials and other data (e.g., cryptographic keys) that are to be used as a basis to form a communication channel. For example, theservice provider102 may provide credentials (e.g., other cryptographic keys) that are to be used to secure communications between theservice provider102 and themobile communication device104. To protect these credentials from compromise by malicious parties, the credentials may be encoded using thispublic key124. In other words, the other cryptographic keys may be encrypted using thepublic key124 for communication to themobile communication device104 to protect the other cryptographic keys from discovery by malicious parties.
• In this way, regardless of whether the communication is communicated indirectly via theprovisioning service106 or directly via thenetwork108, the credentials (e.g., the other cryptographic keys) are protected from discovery through encryption using thepublic key124. Therefore, even theprovisioning service106 itself is not able to determine “what” is being communicated between theservice provider102 and themobile communication device104.
• Themobile communication device104 may then decrypt the communication using thesecure element112, and more particularly theprivate key114, to obtain the other cryptographic keys. A variety of different techniques may then be employed to utilize the other cryptographic keys once decrypted.
• In one technique, the other cryptographic keys are exposed for use outside thesecure element112, such as by anapplication116 or other functionality of themobile communication device104. Thus, in this techniques thesecure element112 is leveraged to provide the credentials that are used to serve as a basis to secure communications but is not used to secure the communications itself, i.e., to provide the actual encryption/decryption.
• In another technique, the other cryptographic keys may be kept from being exposed outside thesecure element112 through storage within thesecure element112. Thesecure element112 may then use the cryptographic keys as previously described to decrypt and/or encrypt data received by thesecure element112 without exposing the cryptographic keys “outside” thesecure element112. Thesecure element112 may thus employ a variety of different techniques to secure communications with themobile communication device104, the example of theservice provider102 above being but one of many such examples.
• Additionally, thesecure element112 may be used to obtain a variety of other credentials that may be used to provide a wide variety of functionality. For example, thesecure element112 may maintain functionality to act as part of a multi-tiered authentication system. For instance, thesecure element112 may be configured to answer a challenge. This answer may then be provided as part of an authentication process with a user name and password, a personal identification number (PIN), and so on such that the user may be authenticated with increased trustworthiness. Further discussion of the leveraging of techniques to answer a challenge by thesecure element112 may be found in relation toFIGS. 8 and 9.
• In another example, thesecure element112 may be leveraged for remote identification. Themobile communication device104, for instance, may be used to store an “identity” of a user of the device. This identity may then be provided to other parties to verify that the user “is who they say they are.” In one such implementation, themobile communication device104 may be “tapped” against a reader at a physical location of an entity that desires to verify the identity of a user of themobile communication device104. Additionally, this identity may be used to sign documents using themobile communication device104. Further, themobile communication device104 may be configured to maintain a plurality of such identities for verification by a plurality of different entities, further discussion of which may be found in relation toFIGS. 6 and 7.
• Generally, any of the functions described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or a combination of these implementations. The terms “module,” “functionality,” and “logic” as used herein generally represent software, firmware, hardware, or a combination thereof. In the case of a software implementation, the module, functionality, or logic represents program code that performs specified tasks when executed on a processor (e.g., CPU or CPUs). The program code can be stored in one or more computer readable memory devices, further description of which may be found in relation toFIG. 2. The features of the provisioning techniques described below are platform-independent, meaning that the techniques may be implemented on a variety of commercial computing platforms having a variety of processors.
• Example Procedures
• The following discussion describes techniques that may be implemented utilizing the previously described systems and devices. Aspects of each of the procedures may be implemented in hardware, firmware, software, or a combination thereof. The procedures are shown as a set of blocks and/or arrows that specify operations performed by one or more devices and/or data communicated between the devices and are not necessarily limited to the orders shown for performing the operations by the respective blocks or arrows. In portions of the following discussion, reference will be made to theenvironment100 ofFIG. 1.
• FIG. 2 depicts aprocedure200 in an example implementation in which a public key is located to communicate with a mobile communication device. A request is transmitted that includes an identifier of a secure element implemented in hardware of a mobile communication device (block202). For example, the identifier may describe a serial number of an integrated circuit that implements thesecure element112 of themobile communication device104. Theserial number122, for instance, may be stored during manufacture of themobile communication device104 with a correspondingpublic key124. As previously noted, thepublic key124 may be part of a public/privatekey pair124,114 that uses asymmetric encryption.
• The request may be transmitted by a variety of different entities, such as by aservice provider102 in order to communicate with themobile communication device104, by themobile communication device104, itself, to provision functionality, and other entities. For example, theservice provider102 may obtain theserial number112 from themobile communication device104 and communicate it to theprovisioning service106 to secure communications between theservice provider102 and themobile communication device104. In another example, themobile communication device104 may receive a request from a user of the device to provision functionality of themobile communication device104, such as to enable execution of anapplication116 by the device, provide a secure communication channel with another device (e.g., the service provider), and so on. A variety of other examples are also contemplated.
• A particular one of a plurality of public keys is located using an identifier included in a request received via a network (block204). Continuing with the previous example, the identifier (e.g., a serial number or other identifier) may be used by theprovisioning service106 to locate thepublic key124. In this way, theprovisioning service106 may locate thepublic key124 without engaging in an encryption or decryption operation itself. Further, theprovisioning service106 may be configured to be auditable by other entities to verify that theprovisioning service106 is not able to decrypt data to be sent to themobile communication device104 that is encrypted using thepublic key124. And thus, theprovisioning service106 may be “trusted” byservice provider102, themobile communication device104, and other entities that are to communicate via the service.
• The located public key is communicated via the network, the public key configured to encrypt data that is to be decrypted by a secure element of a mobile communication device, the secure element implemented using hardware and including a private key that is configured to decrypt the data that was encrypted using the public key (block206). Thesecure element112, for instance, may receive data encrypted by thepublic key124 and decrypt the data using hardware functionality of thesecure element112 itself. In this way, theprivate key114 as well as the data are protected from malicious parties. Thesecure element112 may then expose the data or keep the data internal, further discussion of which may be found in relation toFIGS. 4 and 5.
• FIG. 3 depicts aprocedure300 in an example implementation in which a technique to communicate data securely to a mobile communication device is shown. Theprocedure300 is illustrated as including acredit service302, anissuing entity304, (e.g., a bank or other financial institution), an issuing service306 (e.g., Gemalto), anauditable reference service308, a provisioning service310 (which may or may not correspond to theprovisioning service106 ofFIG. 1), a mobile operator (e.g., an operator of a wireless network), and amobile communication device314, which may or may not correspond to themobile communication device104 ofFIG. 1. In the following discussion, the arrows will be used in indicate an example flow of data. It should be readily apparent however, that the order and the data referenced therein describe one of a variety of different implementations.
• Atarrow316, data is communicated from the credit service302 (e.g., a credit card service such as Visa) to anissuing entity304, such as a bank or other financial institution that issues credit cards. Atarrow318, the issuingentity304 communicates data to anissuing service306 to issue one or more credit cards, e.g., to permit use of the credit cards for online payments and so on.
• Atarrow320, amobile communication device314 makes a request to aprovisioning service310 to provision functionality of themobile communication device314. A wide variety of functionality may be provisioned, such as to enable execution of an application by themobile communication device314, to obtain credentials to access a web service, and so on.
• Atarrow322, theprovisioning service310 communicates with anauditable reference service308 to locate a public key that is associated with themobile communication device314. As stated in relation toFIG. 2, for instance, the request may include an identifier (e.g., a serial number) that is usable to locate a public key ofmobile communication device314. Further, theauditable reference service308 may be configured to permit other entities to “check” the device to ensure that communication performed through the device or other devices are protected from discovery as previously described.
• Atarrow324, theprovisioning service310 receives a response to the request ofarrow322 that includes the public key that corresponds to themobile communication device314. Atarrow326, theprovisioning service310 then provides this public key to theissuing service306 along with a request for data (e.g., credentials) to be communicated to themobile communication device314. Atarrow328, theprovisioning service310 receives the data encrypted by the public key and atarrow330 communicates the data to themobile communication device314.
• Thus, in this example theprovisioning service310 acts as an intermediary to manage provisioning of the mobile communication device. Further, the “trustworthiness” of this function may be verified by outside entities through auditing of theauditable reference service308. In this way, even if theauditable reference service308 is compromised by a malicious party the integrity of data on the mobile communicatesdevice314 is maintained, further discussion of which may be found in relation to the following figures.
• FIG. 4 depicts aprocedure400 in an example implementation in which a technique to receive and process data received by a mobile communication device from a provisioning service is shown. A request is transmitted that includes an identifier of a secure element implemented in hardware of the mobile communication device (block402). As before, the secure element may be identified in a variety of ways, such as through a serial number of an integrated circuit that includes the secure element.
• A response is received to the request that includes data that is encrypted using a public key that corresponds to a private key (block404). The response, for instance, may be obtained directly from aservice provider102 and encrypted using the public key provided by theprovisioning service106. In another instance, the response may be received indirectly via theprovisioning service310 as described in relation toFIG. 3, and so on.
• The data is decrypted by the secure element using the private key (block406). For example, thesecure element112 may be configured using hardware as previously described and include functionality to decrypt the data using theprivate key114 without communicating the key “off” an integrated circuit (e.g., computer chip) that implements the element. Functionality of the mobile communication device may then be provisioned using the data (block408). A variety of different functionality may be provisioned, an example of which is discussed in relation to the following figure.
• FIG. 5 is a flow diagram depicting a procedure in an example implementation in which example operation of a secure element ofFIG. 1 is shown. Continuing fromFIG. 3, themobile communication device314 is illustrated as including aclient502 and a secure element implemented using a secure elementexternal library504 and a secure elementinternal library506.
• Atarrow508, the client502 (e.g., an application) of themobile communication device314 is illustrated as receiving theencrypted data330, e.g., from theprovisioning service310 ofFIG. 3. Theclient502 may then detect that the data is encrypted and accordingly utilize the secure element to decrypt the data. For example, atarrow510 theclient502 may initiate the secure element (e.g., an integrated circuit on which the secure element is implemented), initiate an application atarrow512, perform an authorization handshake atarrow514, and pass theencrypted data330 to the secure elementexternal library504 of the secure element atarrow516.
• The secure elementexternal library504 may then pass the encrypted data to the secure elementinternal library506 atarrow518, which is then decrypted by the secure element. A result of the decryption is then provided back from the secure elementinternal library506 to the secure elementexternal library504. As previously described, a variety of different examples are also contemplated, such as to keep the data internal to the secure element for subsequent use (e.g., for decryption and/or encryption operations to form a secure channel), expose the data for use by the client502 (e.g., as credentials for logon, to perform a purchase), and so on. Thus, a variety of different data may be communicated securely to the mobile communication device, such as data to make a purchase using information relating to a credit card, provide an identifier for use as a transit access card, provide an identifier associated with a loyalty card, or provide credentials usable by the mobile communication device to access a premises.
• FIG. 6 depicts aprocedure600 in an example implementation in which credentials are stored in a secure element responsive to a confirmation that an identity of a user has been verified using physical documents. A confirmation is received that an identity of a user has been physically verified using one or more physical documents (block602). For example, a user may go to a physical location and show documents to a person that may be used to confirm the identity of the user, such as a driver's license, passport, social security card, birth certificate, marriage license, and so on. The person that examines these documents may then interact with a computing device to confirm that the user “is who they say they are” based on the physical documents, such as by interacting with a user interface of the computing device.
• One or more credentials that are usable to authenticate the user are caused to be stored in a secure element of a mobile communication device of the user, the secure element implemented using tamper-resistant hardware (block604). Continuing with the previous example, the confirmation received by the computing device from the person may cause the computing device to initiate one or more techniques to provision credentials on themobile communication device102. For instance, techniques may be implemented that involve theprovisioning service106 to communicate the credentials securely “over the cloud” from thesearch provider102.
• As previously described in relation toFIGS. 2-5, these techniques may include communication of thepublic key124 to aservice provider102 which uses the key to encrypt credentials for communication over thenetwork108 to themobile communication device104. Themobile communication device104 may then provide the encrypted data to thesecure element112, which may use theprivate key114 to decrypt the encrypted data that includes the credentials.
• The credentials may then be stored within the secure element112 (e.g., an integrated circuit that implements the secure element112) without exposing the credentials. Additionally, thesecure element112 may be configured to be tamper resistant to reduce a likelihood of snooping and/or physical removal of the element as previously mentioned in relation toFIG. 1. In this way, the credentials may be stored securely with a reduced likelihood of being compromised by malicious parties. Further, the credentials may be used for a variety of different purposes, one example of which may be found in relation to the following figure.
• FIG. 7 depicts aprocedure700 in an example implementation in which credentials are provisioned on a mobile communication device that are usable to authenticate a user's identity. As before, physical documents are examined at a physical location, the documents presented by a user to authenticate the user's identity (block702). For example, a user may take a mobile communication device to a passport office along with documents that are usable to authenticate the user's identity, such as a driver's license, social security card, and so on. An employee or other person at the passport office may then examine the documents to authenticate that the user “is who they say they are.”
• The employee may then initiate an operation to provision credentials on a secure element of the mobile communication device of the user at the physical location (block704). For example, a computing device at the passport office may be used to securely provide credentials to themobile communication device104 over a local connection between the computing device and themobile communication device104. For instance, the credentials may be communicated responsive to tapping the device on an NFC reader and read using near field technology.
• The credentials may be generated locally by the computing device, obtained remotely over thenetwork108, and so on. Further, other provisioning techniques are also contemplated such as those previously described in relation toFIGS. 2-5. Thus, the credentials may be securely maintained by amobile communication device104 of the user, which may support a variety of different functionality.
• A user may encounter a situation that involves authentication of the user's identity (block706), such as travel to a foreign country following the previous passport example. Upon entering immigration, the foreign country may demand a passport.
• In response, credentials from the secure element are communicated securely to a requestor of the authentication (block708). The user, for instance, may “tap” themobile communication device102 against a reader. Credentials from thesecure element112 may then be used to authenticate the user, such as to obtain an electronic copy of the user's passport from a service over thenetwork108. Further, themobile communication device104 may be used also to sign paperwork using credentials stored in the secure element, such as to sign a declaration form. Thus, themobile communication device104 may serve as a ready source to authenticate an identity of the user. Although these examples describe communicating credentials that are stored in the secure element, the credentials may also be used to answer challenges to authenticate a user's identity, further discussion of which may be found in relation to the following figure.
• FIG. 8 depicts aprocedure800 in an example implementation in which a secure element of a mobile communication device is configured to answer a challenge that is usable to authenticate an identity of a user. A challenge is received at a mobile communication device to authenticate an identity of a user of the mobile communication device (block802). The challenge, for instance, may be include a collection of letters that are entered by a user of themobile communication104, received via an application that is executed on a processor of themobile communication device104 that is separate from thesecure element112, and so on.
• The challenge is processed by a secure element of the mobile communication device using one or more credentials, the challenge being processed without exposing the one or more credentials outside of hardware that implements the secure element (block804). As discussed in relation toFIG. 5, the mobile communication device may receive data and perform processing using the data without exposing intermediate results of the processing or data used to perform the processing (e.g., the credentials) outside of thesecure element112. Therefore, the challenge may be processed using credentials that may be kept secret before, during, and after the processing, such as through use of cryptographic techniques and so on.
• An answer to the challenge may then be exposed by the secure element (block806). The answer may be output in a variety of ways. The answer may be for manual entry by a user into a user interface, may be output to an application that is to use to answer as part of a login operation, and so on, further discussion of which may be found in relation to the following figure.
• FIG. 9 depicts aprocedure900 in an example implementation in which an answer to a challenge processed by a secure element of a mobile communication device is used as part of a multi-tier remote authentication technique. An application is downloaded from an application marketplace to a mobile communication device (block902). Themobile communication device104, for instance, may navigate to aservice provider102 over anetwork108 to cause anapplication130 to be downloaded to themobile communication device104. In this example, the application is provided by a bank to perform online banking and other account management operations.
• Credentials are provisioned onto a secure element of the mobile communication device (block904). A variety of different techniques may be used to provision the credentials. In one example, “in person” techniques are utilizes as previously described in which the user presents physical documents at a physical location (e.g., a branch of the bank) to cause credentials to be stored in thesecure element112. In another example, theprovisioning service106 may be utilized to securely communicate the credentials between the bank and themobile communication device104, either directly or indirectly. A variety of other examples are also contemplated.
• A login to a website is initiated by entering a user name and password (block906). The user, for example, may be prompted to enter this information by the banking application. In response, a challenge may be received from the website (block908), which may be configured as a string of characters, a question, and so on. The challenge is then communicated to thesecure element112, which processes the challenge using the provisioned credentials (block910). Thesecure element112, for instance, may apply one or more cryptographic techniques to the string of letters (e.g., process using a cryptographic key) to produce an answer, find an answer to the quest using the credentials, and so on.
• The answer to the challenge is then provided to the website (block912) which may then be used to complete login to the website. Thus, a multi-tiered approach may be utilized to login to the website that leverages the secure element. Although a website was described, a variety of different resources are contemplated, such as to access an ATM, data storage, computing device, lock of a physical location, safe, opening a vehicle door, starting a vehicle, and so on. Thus, the credentials stored in thesecure element112 may be used for a variety of purposes, such as to authenticate the user to make a purchase using information relating to a credit card, provide an identifier for use as a transit access card, provide an identifier associated with a loyalty card, or provide credentials usable by the mobile communication device to access a premises.
• Example Device
• FIG. 10 illustrates various components of anexample device1000 that can be implemented in various embodiments as any type of a mobile device to implement embodiments of devices, features, and systems for mobile communications. For example,device1000 can be implemented as any of themobile communication devices104 described with reference to respectiveFIG. 1.Device1000 can also be implemented to access a network-based service, such as a social network service as previously described.
• Device1000 includesinput1002 that may include Internet Protocol (IP) inputs as well as other input devices.Device1000 further includescommunication interface1004 that can be implemented as any one or more of a wireless interface, any type of network interface, and as any other type of communication interface. A network interface provides a connection betweendevice1000 and a communication network by which other electronic and computing devices can communicate data withdevice1000. A wireless interface enablesdevice1000 to operate as a mobile device for wireless communications.
• Device1000 also includes one or more processors1006 (e.g., any of microprocessors, controllers, and the like) which process various computer-executable instructions to control the operation ofdevice1000 and to communicate with other electronic devices.Device1000 can be implemented with computer-readable media1008, such as one or more memory components, examples of which include random access memory (RAM) and non-volatile memory (e.g., any one or more of a read-only memory (ROM), flash memory, EPROM, EEPROM, etc.).
• Computer-readable media1008 provides data storage to store content anddata1010, as well as device applications and any other types of information and/or data related to operational aspects ofdevice1000. For example, anoperating system1012 can be maintained as a computer application with the computer-readable media1008 and executed onprocessor1006. Device applications can also include a communication manager module1014 (which may be used to provide telephonic functionality) and amedia manager1016.
• Device1000 also includes an audio and/orvideo output1018 that provides audio and/or video data to an audio rendering and/ordisplay system1020. The audio rendering and/ordisplay system1020 can be implemented as integrated component(s) of theexample device1000, and can include any components that process, display, and/or otherwise render audio, video, and image data.Device1000 can also be implemented to provide a user tactile feedback, such as vibrate and haptics.
• Generally, the blocks may be representative of modules that are configured to provide represented functionality. Further, any of the functions described herein can be implemented using software, firmware (e.g., fixed logic circuitry), manual processing, or a combination of these implementations. The terms “module,” “functionality,” and “logic” as used herein generally represent software, firmware, hardware or a combination thereof. In the case of a software implementation, the module, functionality, or logic represents program code that performs specified tasks when executed on a processor (e.g., CPU or CPUs). The program code can be stored in one or more computer readable memory devices. The features of the techniques described above are platform-independent, meaning that the techniques may be implemented on a variety of commercial computing platforms having a variety of processors.
• Conclusion
• Although the invention has been described in language specific to structural features and/or methodological acts, it is to be understood that the invention defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as example forms of implementing the claimed invention.

Claims (20)

What is claimed is:

1. A method comprising:

receiving, from an application executing on a mobile communication device, a request for a secure element to provision credentials for the application;

based at least on receiving the provisioning request, storing the credentials in the secure element;

receiving, by the application, a request for a signature of data using the credentials; and

based at least on receiving the request for the signature, returning the signature stored in the secure element without exposing the credentials outside of the secure element.

2. The method ofclaim 1, wherein an integrated circuit implements the secure element.

3. The method ofclaim 2, wherein the integrated circuit is resistant to removal from a circuit board of the mobile communication device.

4. The method ofclaim 1, wherein the credentials are configured to authenticate a user's identity for the application.

5. The method ofclaim 1, wherein the secure element includes a private key configured to decrypt data that includes the credentials encrypted using a corresponding public key, the secure element configured to perform the decryption without exposing the private key and the one or more credentials outside of the secure element.

6. The method ofclaim 5, wherein the private key is configured during manufacture of the secure element.

7. The method ofclaim 1, wherein the one or more credentials are configured for use by the mobile communication device to authenticate the user to make a purchase using information relating to a credit card, provide an identifier for use as a transit access card, provide an identifier associated with a loyalty card, or provide credentials usable by the mobile communication device to access a premises.

8. A mobile computing device comprising a secure element implemented in tamper-resistant hardware that is configured to:

receive, from an application executing on the mobile communication device, a request for the secure element to provision credentials for the application;

based at least on receiving the provisioning request, store the credentials in the secure element;

receive a request by the application for a signature of data using the credentials; and

based at least on receiving the request for the signature, return the signature stored in the secure element without exposing the credentials outside of the secure element.

9. The mobile computing device ofclaim 8, wherein an integrated circuit implements the secure element.

10. The mobile computing device ofclaim 9, wherein the integrated circuit is resistant to removal from a circuit board of the mobile communication device.

11. The mobile computing device ofclaim 8, wherein the credentials are configured to authenticate a user's identity for the application.

12. The mobile computing device ofclaim 8, wherein the secure element includes a private key configured to decrypt data that includes the credentials encrypted using a corresponding public key, the secure element configured to perform the decryption without exposing the private key and the one or more credentials outside of the secure element.

13. The mobile computing device ofclaim 12, wherein the private key is configured during manufacture of the secure element.

14. The mobile computing device ofclaim 8, wherein the one or more credentials are configured for use by the mobile communication device to authenticate the user to make a purchase using information relating to a credit card, provide an identifier for use as a transit access card, provide an identifier associated with a loyalty card, or provide credentials usable by the mobile communication device to access a premises.

15. One or more computer storage media storing computer readable instructions that, when executed by at least a processor, cause the at least one processor to perform operations comprising:

receiving, from an application executing on a mobile communication device, a request for a secure element to provision credentials for the application;

in response to the provisioning request, storing the credentials in the secure element;

receiving, by the application, a request for a signature of data using the credentials; and

in response to the request for the signature, returning the signature stored in the secure element without exposing the credentials outside of the secure element.

16. The one or more computer storage media ofclaim 15, wherein an integrated circuit implements the secure element.

17. The one or more computer storage media ofclaim 16, wherein the integrated circuit is resistant to removal from a circuit board of the mobile communication device.

18. The one or more computer storage media ofclaim 15, wherein the credentials are configured to authenticate a user's identity for the application.

19. The one or more computer storage media ofclaim 15, wherein the secure element includes a private key configured to decrypt data that includes the credentials encrypted using a corresponding public key, the secure element configured to perform the decryption without exposing the private key and the one or more credentials outside of the secure element, and wherein the private key is configured during manufacture of the secure element.

20. The one or more computer storage media ofclaim 15, wherein the one or more credentials are configured for use by the mobile communication device to authenticate the user to make a purchase using information relating to a credit card, provide an identifier for use as a transit access card, provide an identifier associated with a loyalty card, or provide credentials usable by the mobile communication device to access a premises.

Images