US20180091498A1 - Secure element installation and provisioning - Google Patents
Secure element installation and provisioning Download PDFInfo
- Publication number
- US20180091498A1 US20180091498A1 US15/277,618 US201615277618A US2018091498A1 US 20180091498 A1 US20180091498 A1 US 20180091498A1 US 201615277618 A US201615277618 A US 201615277618A US 2018091498 A1 US2018091498 A1 US 2018091498A1
- Authority
- US
- United States
- Prior art keywords
- secure identifier
- authority
- identifier
- secure
- pseudo
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/006—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols involving public key infrastructure [PKI] trust models
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
- H04L9/065—Encryption by serially and continuously modifying data stream elements, e.g. stream cipher systems, RC4, SEAL or A5/3
- H04L9/0656—Pseudorandom key sequence combined element-for-element with data sequence, e.g. one-time-pad [OTP] or Vernam's cipher
- H04L9/0662—Pseudorandom key sequence combined element-for-element with data sequence, e.g. one-time-pad [OTP] or Vernam's cipher with particular pseudorandom sequence generator
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
- H04L9/0866—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving user or device identifiers, e.g. serial number, physical or biometrical information, DNA, hand-signature or measurable physical characteristics
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
- H04L9/0869—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving random numbers or seeds
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
Definitions
- Connected devices include hundreds of millions of cell phones and now additional millions, if not billions, of automobiles, electric meters, kitchen appliances, watches, and other wearable devices.
- Connected devices include hundreds of millions of cell phones and now additional millions, if not billions, of automobiles, electric meters, kitchen appliances, watches, and other wearable devices.
- each device In order for these devices to interact effectively as a part of connected systems it is necessary for each device to have a unique identifier that can be bound to an owner or other kind of account for the purpose of pairing, establishing ownership, transaction processing, or record keeping such as fitness tracking, or online data access, such as iTunes.
- FIG. 1 is a block diagram a system for generation of a secure identifier at a device and registration of the device with an authority;
- FIG. 2 is an alternate embodiment of the system for secure identifier generation and device registration
- FIG. 3 is another embodiment of the system for secure identifier generation and device registration
- FIG. 4 is yet another embodiment of the system for secure identifier generation and device registration
- FIG. 5 is still another embodiment of the system for secure identifier generation and device registration.
- FIG. 6 is a flow chart of a method for secure identifier generation and device registration.
- Past attempts to proactively assign unique identifiers to devices at the time of manufacture have failed due to the number of manufacturers, the global nature of marketplace, and the late binding between devices and related authorities, often well after the original sale of the device.
- the need to establish trust between the device and the authority is not reduced by these factors, as the devices may be called on to share personal data, enter contractual relationships, or verify an identity of an individual, e.g., for boarding an airplane, to name a few.
- the following description uses the term secure identifier for the identifier generated at a device to give a unique identity to the device.
- the identifier is secure in that it is unaltered after generation, but is not secret in that once generated, the identifier may be shared with other entities beyond the device.
- a process for creating identifiers at the device and subsequently registering them with an authority moves the creation of a globally unique and secure identifier to the device itself. Ensuring that the self-generated identifier is sufficiently unique, relocating the generation of the secure identifier to the device allows the registration process to be implemented both as needed and when needed. Should an identifier be needed at the time of issuance, such as for a smart card-based driver's license, the process of generating the unique and secure identifier can be performed while the device is still in the hands of the issuing agency.
- the process can be performed at the time of registration, with or without explicit involvement of the user/owner.
- the device is never registered, such as a connectable watch that is used simply as a watch, no extra data is being stored at a potential registration site for a device that will never be registered. That is, an exhaustive list of every possible device that could be registered is not required. Only those devices that require a particular service are registered with that service.
- the secure identifier generation process is designed to be globally unique over all possible devices, the device's secure identifier can be used by multiple services associated with the same device, such as a coffee shop loyalty system and a building access system.
- a combination of device data and random numbers are processed by a cryptographic algorithm to ensure that the identifier is sufficiently unique to not be aliased by another identifier, even in a field of billions of devices. As long as the device can store the identifier securely so that its value does not change, the trust relationship established during registration (or binding) is persistent over the life of the device without regard to other devices in the field.
- FIG. 1 generally discloses components usable for generating and installing a secure identifier in a device 102 for the purpose of binding the device 102 to an authority 150 .
- the authority 150 is an entity that receives information from the device and, in some cases, acts on the information received from the device to perform a service either with respect to device itself or on behalf of a user of the device. Exemplary use cases are discussed in more detail below.
- a device 102 in an embodiment, has a processor 104 that executes instructions stored in a memory 106 .
- the memory 106 includes program code or instructions 108 that provides core functionality to the device 102 , such as in one embodiment, fitness tracking where the program code 108 executes in combination with other sensors (not depicted) that may be used to determine heart rate, step count or other health-related statistics.
- the memory 106 can also include, in various embodiments, registration code 110 and/or a registration application 112 used for generation of a secure identifier 120 and subsequent binding or registration of the device 102 with the authority 150 .
- the memory 106 includes a certificate 114 .
- the certificate 114 may be a public key infrastructure (PKI) certificate in an X.509 format.
- PKI public key infrastructure
- the certificate 114 may be requested from a certificate authority 170 although other parties, such as a registration authority (not depicted) may also be involved.
- the certificate authority 170 will establish an identity of the device owner, or in some cases, the device 102 itself and generate the certificate 114 which includes the device public key signed by the certificate authority private key. This allows verification of the device public key using the certificate authority public key.
- the memory 106 may also include, in various embodiments, cryptographic routines 116 that can be used to implement key generation, random number generation, signing, and encryption. In some embodiments, these functions may be supported in either the registration application 112 , a hardware security module (HSM) or a combination of these. A random number, or more likely, a pseudo-random number 117 may be generated and stored, at least temporarily, on the device 102 .
- HSM hardware security module
- the device 102 also includes an unalterable memory 118 .
- unalterable memory 118 There are various forms of unalterable memory, some referred to as “write once, read many” (WORM) including, but not limited to, a fuseable link memory. Other programmatic steps can be taken to ensure that once written, a memory location is not over-written or erased.
- the unalterable memory 118 is used to store the secure identifier 120 that is the basis of trust between the device and the authority 150 . In some cases, the entire memory 118 is protected after the desired write process while in other cases only a portion of the memory 118 is protected, allowing additional data to be written to the memory 118 without disturbing previously written data.
- the unalterable memory 118 may be permanently attached to a main board of the device 102 , such as with an epoxy “potting” compound such that an attempt to remove the memory 118 is likely to permanently damage both the memory 118 and the device 102 .
- the device 102 may also include a hardware security module (HSM) 122 .
- HSM hardware security module
- the HSM 122 provides cryptographic services 126 in addition to or instead of those services being provided by cryptographic program 116 .
- the HSM 122 may also be a repository for private keys and, in an embodiment, may be the storage location for the secure identifier 120 because the HSM 122 is likely to have as part of its security features the capability to securely store data.
- the device 102 communicates with external entities either via a direct connection to a network 140 or through a connected device 130 , as discussed in more detail below.
- An application service 180 for example, the iTunes Store or Google Play can be used to download the registration application 112 to the device 102 .
- other sources such as a service provider can also supply the registration application 112 .
- the authority 150 stores, in an exemplary embodiment, information about a plurality of users and devices illustrated as user data stores 152 , 153 , and 154 .
- the authority 150 also includes executable code 156 for server-side execution of a process for binding the device 102 to the authority during the registration process.
- a device binding system 190 not only includes the device 102 and the authority 150 but the certificate authority 170 as well.
- the authority 150 also includes cryptographic services 158 and other related information that may include certificates 160 issued by a certificate authority (CA) 170 for verification of the device credentials, when presented.
- CA certificate authority
- the application service 180 is used to download the registration application 112 even though the application service 180 is not explicitly a part of the device binding system 190 .
- the secure identifier 120 can be used as a basis of trust for future interactions with the authority 150 or a related entity such as a music site, health site, shopping site, etc.
- the math associated with the uniqueness of the secure identifier is discussed below, however, in the extremely unlikely event that another device has the same unique identifier, the duplicate number can be flagged at the time of registration and a the device 102 can be requested to generate a new secure identifier 120 .
- a time displacement between registration operations, differences in device characteristics, and a location of the requester, among others, can be used to identify that a second device is attempting to register with the duplicate secure identifier 120 .
- the chance of a duplicate is extremely low.
- FIG. 2 is a diagram illustrating one embodiment of the device binding system 190 with a minimally configured device 102 .
- the device 102 is connected to the authority 150 via the network 140 .
- the device 102 has local registration code 110 that is used to generate the secure identifier 120 .
- the device 102 stores the secure identifier 120 in an unalterable memory 118 .
- the registration code 110 in combination with the device program code 108 may, in one case, provide a user interface (not depicted) for performing the registration process.
- the device 102 executes the registration code which connects to the authority 150 . The user may be prompted to enter identifying information establish identity prior to allowing the binding.
- the authority 150 will establish the owner's identity so that subsequent information sent from the device can be correctly attributed to the owner.
- Processes for identifying a user are well known and may include matching login information with a previously established account, matching identifying information such as driver's license or passport information with the user, or the use of two factor identification involving sending a passcode to another device such as a cell phone known to be affiliated with the user.
- the registration may be anonymous with the knowledge that future access will be based only on credentials established during the registration process. In one such case, an ID and password can be established along with the secure identifier during the binding process.
- the secure identifier 120 may be used and the data is stored anonymously based solely on the secure identifier 120 .
- a public/private key pair may be generated on the device 102 so that the device 102 can sign, for example, the secure identifier 120 .
- the process involving signing and encryption is more suitable to the embodiment illustrated in FIG. 3 .
- FIG. 3 The use of public key infrastructure (PKI) as part of establishing and maintaining the trust relationship between the device 102 and the authority 150 is shown in FIG. 3 .
- the device 102 is shown as having an HSM 122 , however, the HSM 122 is not a requirement.
- This illustrated embodiment also shows that the HSM 122 , when present, can be used to store the secure identifier 120 as an alternative to storage in the unalterable memory 118 .
- the device 102 generates a PKI key pair, one stored locally and not shared, making it the private key 124 , the other key of the key pair being the public key 128 which is freely shared.
- the embodiment of FIG. 3 uses a certificate authority (CA) 170 to sign the device's public key after sending the public key to the CA 170 and performing some level of identity verification.
- the CA 170 may verify an identity of the device owner/user while in another embodiment, the device 102 may have separate credentials that are tied to the identity being bound to the public key.
- the CA 170 then issues a certificate 114 that includes the public key 128 signed by the CA private key (or equivalent sub-key) so that a subsequent participant can trust data signed by the device private key 124 .
- the details of trust relationships in a PKI infrastructure are well known in the industry.
- the device 102 can use the certificate 114 as part of the binding process. For example, the device 102 can sign (encrypt) the secure identifier 120 with its private key 124 and provide the signed private key and the certificate 114 to the authority 150 . The authority 150 can then verify an identity associated with the device 102 by confirming the validity of the certificate 114 and determining the identity via the certificate 114 or the CA 170 .
- FIG. 4 is an alternate embodiment of the system described above illustrating that the registration process may be supported by a registration application 112 that is downloaded prior to the binding process.
- the registration application 112 may be installed on the device 102 from an application service 180 .
- the device 102 directly supports downloading and executing the registration application 112 .
- the application 112 is used for the generation of the secure identifier 120 and subsequent registration procedure discussed briefly above and in more detail below.
- the registration application 112 may include the cryptographic routines required to generate and use public/private key pairs.
- a connected device 130 such as a smart phone may provide a user interface for downloading the application 112 , executing the registration process, or both. That is, even though the registration application 112 may be stored on and executed by the device 102 , the connected device 130 can provide a display and a keyboard (not depicted) useful for receiving prompts and entering data used by the device 102 . Other variations for location and execution of the registration application 112 are possible.
- the connected device 130 can also provide a wide-area network connection 132 that supports a data connection between the user device 102 and the network 140 .
- the user device 102 is networked to the connected device 130 via a physical connection, a BluetoothTM or a near-field communication (NFC).
- the connected device 130 is coupled to the network 140 via WiFi or a cellular data connection such as WiMax or 4G LTE.
- the device 102 is then able to communicate via the network 140 through this indirect connection.
- Some smaller devices, such as wearable devices or smart cards may not be able to support direct connections to a network 140 via wide area network. This additional capability allows even more devices to participate in this late binding process.
- FIG. 6 is a flow chart illustrating one method 600 of binding a device 102 to an authority 150 .
- the method 600 generally outlines a two-step process to generate a secure identifier 120 and then to register that secure identifier 120 with an authority 150 .
- an unalterable memory 118 is provided in the device 102 to permanently store information.
- the unalterable memory 118 is a fuseable link memory.
- a hardware security module (HSM) 122 is used instead of or supplementary to the unalterable memory 118 such that the HSM 122 can be used to store information that must remain unaltered.
- HSM hardware security module
- the registration code 110 may be installed at the time of manufacture. If yes, that is, that code embedded in the device 102 at the time registration is requested is available, execution continues at block 606 . If, at block 604 , no code is available for device registration, execution may continue at block 622 where the device 102 sends enough information about itself so that an application service 180 can determine what version registration application to deliver. For example, the application service 180 may need to know the device manufacturer, model number and operating system version in order to deliver the correct registration application 112 . In an embodiment, the registration application 112 may also be specific to an authority 150 to which the device 102 will be bound.
- the correct registration application 112 is downloaded and instantiated.
- the registration application 112 is downloaded at the time of binding.
- the registration application 112 may also include executable code that performs cryptographic functions 116 used to generate the secure identifier 120 , discussed more below.
- the cryptographic functions 116 are native to the device 102 , such as on HSM 122 .
- Predetermined device data is read by the registration code 110 at block 606 .
- the registration code 110 or the registration application 112 is device-specific, the device-specific data read can be tailored based on type. That is, different data is used when registering a smart phone vs. a fitness tracker, or even fitness trackers from different manufacturers.
- a model number, serial number, and operating system version can be used as the device-specific data.
- 60 bytes of device-specific data can be used.
- the device-specific data is data from transient memory or a version number of a tool, such as a Java API. Since the operation to develop the secure identifier 120 is a one-time process on the device 102 only, and does not need to be recreated at another system element, such transient information may be used.
- a pseudo-random (or random) number 117 may be obtained.
- the pseudo-random number may be generated by registration code 110 or the registration application 112 , by local cryptographic code 116 , by an HSM 122 , or even received via a network connection 131 from another device, for example, the connected device 130 , given trust in the device 130 .
- the pseudo-random number 117 may be 16 bytes.
- the device-data and pseudo-random number are combined at block 610 to develop a base number.
- the base number is transient.
- the combination may simply be a concatenation of the two numbers.
- Other combination techniques are available and well known, such as a bit XOR.
- the base number is transient and can be discarded after the secure identifier 120 is generated.
- the secure identifier is generated from the base number, that is the combination of the device-specific data and the pseudo-random number 117 .
- a one-way cryptographic hash is used to generate the secure identifier 120 . Any of several well-known hashing functions could be used including MD5, SHA, or in one embodiment, a SHA 256 algorithm.
- the resultant secure identifier 120 is a 32 byte number.
- the collision probability for the latter alternative decreases the chance of duplication by almost 40 orders of magnitude, so that for the foreseeable future, no two devices would have the same secure identifier 120 .
- other cryptographic functions could be used to create further distance between possible duplicates, such as a block cipher using another random number as the key.
- the secure identifier 120 may be registered with an authority at block 620 using a manual login and password process. However, in many embodiments, an additional process may be implemented to allow continued assertion of the secure identifier as being from the same device 102 .
- a key pair may be generated at block 614 following a known public/private key generation sequence.
- the private key 124 of the key pair may be stored securely, for example, in the HSM 122 .
- the ‘no’ branch from block 616 may be followed to block 618 where the secure identifier 120 is signed with the device private key 124 .
- the signed identifier and the device public key may be send to the authority 150 at block 620 .
- the authority 150 can then store the device public key in one of the user stores 152 - 154 and used to confirm future activity with the device 102 by verifying data signed with the device private key 124 .
- a certificate authority 170 can be included in the process and the ‘yes’ branch from block 616 can be taken to block 626 . There, a request can be made to the certificate authority 170 for a certificate 114 .
- the CA 170 or a registration authority can perform a supplemental validation of the identity of the device 102 , or more often, a user associated with the device 102 .
- the process for issuing a certificate 114 is well known and not discussed here in more detail.
- the device 102 can then send the certificate to the authority 150 at block 628 .
- the device 102 can also then sign and send the signed secure identifier 120 to the authority 150 .
- the authority 150 can then check the identity of the device/user using the certificate 114 and use the device public key embedded in the certificate 114 to decrypt the secure identifier 120 for the purpose of binding the secure identifier to the device 102 .
- the above disclosure allows late binding of devices so that a trust relationship can be developed even after a device 102 has left a secure and controlled manufacturing process.
- the technical effect is that the creation and storage of a device's unique identifier can be moved from the manufacturer or authority 150 to the device itself.
- the need to pre-set billions of devices with transport keys or other security measures is eliminated.
- additional program memory is not required. For example, after the binding/registration process is complete, a registration application 112 can be deleted so that there is virtually no impact on the long-term configuration of the device 102 . Whether the binding occurs early or late, the unalterable memory requirements are also the same.
- the effect of using a combination of device characteristics and random numbers creates distance between the initial number sets.
- a hardware security module 122 The technical effect of a hardware security module 122 is that the device 102 can securely generate keys, perform cryptographic functions, such as signing and encryption, and store data with the highest level of security.
- the HSM 122 can be in part or in whole a smart chip such as are used in smart cards for access control and financial transactions.
Abstract
Description
- The background description provided herein is for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.
- Identification of items is a common practice. In the past, for everything from a driver's license to an insurance card, the name of the end user was known at the time the identification card was issued. However, now that virtually any object that uses electricity can be a connected device, for example the Internet of Things (IoT), there is an explosion in the number of devices that must be given a verifiable identity in order to securely communicate on behalf of an entity such as an owner of the device
- Connected devices include hundreds of millions of cell phones and now additional millions, if not billions, of automobiles, electric meters, kitchen appliances, watches, and other wearable devices. In order for these devices to interact effectively as a part of connected systems it is necessary for each device to have a unique identifier that can be bound to an owner or other kind of account for the purpose of pairing, establishing ownership, transaction processing, or record keeping such as fitness tracking, or online data access, such as iTunes.
- Attempts to centrally pre-assign known numbers to devices and bind them to owners at the time of manufacture or sale have been overwhelmed by the sheer volume of candidate products being produced as well as by the late binding required by mass-sale consumer products, for example, connected watches and fitness trackers.
- The figures depict a preferred embodiment for purposes of illustration only. One skilled in the art may readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles described herein.
-
FIG. 1 is a block diagram a system for generation of a secure identifier at a device and registration of the device with an authority; -
FIG. 2 is an alternate embodiment of the system for secure identifier generation and device registration; -
FIG. 3 is another embodiment of the system for secure identifier generation and device registration; -
FIG. 4 is yet another embodiment of the system for secure identifier generation and device registration; -
FIG. 5 is still another embodiment of the system for secure identifier generation and device registration; and -
FIG. 6 is a flow chart of a method for secure identifier generation and device registration. - The explosion in the number of devices requiring binding (or registration) with an authority has increased significantly in the last several years, especially with the advent of connected devices such as connected wearable devices and the Internet of Things (IoT) including, but not limited to, watches, fitness trackers, automobiles/key fobs, thermostats, home security systems, refrigerators and other appliances. In order for the device to provide meaningful information to or on behalf of the device owner, an authority, such as a service provider, must be able to uniquely identify the device from amongst potentially billions of other such devices. The consequences of duplication of unique identifiers can be far reaching with implications into the fields of healthcare, personal security, personal privacy, or finances should multiple devices accidentally, or worse, deliberately be registered to the wrong entity.
- Past attempts to proactively assign unique identifiers to devices at the time of manufacture have failed due to the number of manufacturers, the global nature of marketplace, and the late binding between devices and related authorities, often well after the original sale of the device. The need to establish trust between the device and the authority is not reduced by these factors, as the devices may be called on to share personal data, enter contractual relationships, or verify an identity of an individual, e.g., for boarding an airplane, to name a few.
- The following description uses the term secure identifier for the identifier generated at a device to give a unique identity to the device. The identifier is secure in that it is unaltered after generation, but is not secret in that once generated, the identifier may be shared with other entities beyond the device.
- As opposed to prior art system that centrally assign identifiers, a process for creating identifiers at the device and subsequently registering them with an authority moves the creation of a globally unique and secure identifier to the device itself. Ensuring that the self-generated identifier is sufficiently unique, relocating the generation of the secure identifier to the device allows the registration process to be implemented both as needed and when needed. Should an identifier be needed at the time of issuance, such as for a smart card-based driver's license, the process of generating the unique and secure identifier can be performed while the device is still in the hands of the issuing agency. If the device, such as a fitness tracker, is registered after delivery to the end user the process can be performed at the time of registration, with or without explicit involvement of the user/owner. Lastly, if the device is never registered, such as a connectable watch that is used simply as a watch, no extra data is being stored at a potential registration site for a device that will never be registered. That is, an exhaustive list of every possible device that could be registered is not required. Only those devices that require a particular service are registered with that service. Further, since the secure identifier generation process is designed to be globally unique over all possible devices, the device's secure identifier can be used by multiple services associated with the same device, such as a coffee shop loyalty system and a building access system.
- In an embodiment, a combination of device data and random numbers are processed by a cryptographic algorithm to ensure that the identifier is sufficiently unique to not be aliased by another identifier, even in a field of billions of devices. As long as the device can store the identifier securely so that its value does not change, the trust relationship established during registration (or binding) is persistent over the life of the device without regard to other devices in the field.
-
FIG. 1 generally discloses components usable for generating and installing a secure identifier in adevice 102 for the purpose of binding thedevice 102 to anauthority 150. In an embodiment, theauthority 150 is an entity that receives information from the device and, in some cases, acts on the information received from the device to perform a service either with respect to device itself or on behalf of a user of the device. Exemplary use cases are discussed in more detail below. - A
device 102, in an embodiment, has aprocessor 104 that executes instructions stored in amemory 106. Thememory 106 includes program code orinstructions 108 that provides core functionality to thedevice 102, such as in one embodiment, fitness tracking where theprogram code 108 executes in combination with other sensors (not depicted) that may be used to determine heart rate, step count or other health-related statistics. Thememory 106 can also include, in various embodiments,registration code 110 and/or aregistration application 112 used for generation of asecure identifier 120 and subsequent binding or registration of thedevice 102 with theauthority 150. - In an embodiment, the
memory 106 includes acertificate 114. Thecertificate 114 may be a public key infrastructure (PKI) certificate in an X.509 format. When participating in a PKI environment, thecertificate 114 may be requested from acertificate authority 170 although other parties, such as a registration authority (not depicted) may also be involved. Thecertificate authority 170 will establish an identity of the device owner, or in some cases, thedevice 102 itself and generate thecertificate 114 which includes the device public key signed by the certificate authority private key. This allows verification of the device public key using the certificate authority public key. - The
memory 106 may also include, in various embodiments,cryptographic routines 116 that can be used to implement key generation, random number generation, signing, and encryption. In some embodiments, these functions may be supported in either theregistration application 112, a hardware security module (HSM) or a combination of these. A random number, or more likely, apseudo-random number 117 may be generated and stored, at least temporarily, on thedevice 102. - The
device 102 also includes anunalterable memory 118. There are various forms of unalterable memory, some referred to as “write once, read many” (WORM) including, but not limited to, a fuseable link memory. Other programmatic steps can be taken to ensure that once written, a memory location is not over-written or erased. Theunalterable memory 118 is used to store thesecure identifier 120 that is the basis of trust between the device and theauthority 150. In some cases, theentire memory 118 is protected after the desired write process while in other cases only a portion of thememory 118 is protected, allowing additional data to be written to thememory 118 without disturbing previously written data. Because thememory 118 is used to store information that binds thedevice 102 to an authority, it is preferable that thememory 118 physically is difficult to remove from thedevice 102. In an embodiment, theunalterable memory 118 may be permanently attached to a main board of thedevice 102, such as with an epoxy “potting” compound such that an attempt to remove thememory 118 is likely to permanently damage both thememory 118 and thedevice 102. - In some embodiments, the
device 102 may also include a hardware security module (HSM) 122. In those instances, the HSM 122 providescryptographic services 126 in addition to or instead of those services being provided bycryptographic program 116. The HSM 122 may also be a repository for private keys and, in an embodiment, may be the storage location for thesecure identifier 120 because the HSM 122 is likely to have as part of its security features the capability to securely store data. - The
device 102 communicates with external entities either via a direct connection to anetwork 140 or through a connecteddevice 130, as discussed in more detail below. Anapplication service 180, for example, the iTunes Store or Google Play can be used to download theregistration application 112 to thedevice 102. Alternatively, other sources, such as a service provider can also supply theregistration application 112. - The
authority 150 stores, in an exemplary embodiment, information about a plurality of users and devices illustrated asuser data stores authority 150 also includesexecutable code 156 for server-side execution of a process for binding thedevice 102 to the authority during the registration process. - In various embodiments, a
device binding system 190 not only includes thedevice 102 and theauthority 150 but thecertificate authority 170 as well. In such embodiments, theauthority 150 also includescryptographic services 158 and other related information that may includecertificates 160 issued by a certificate authority (CA) 170 for verification of the device credentials, when presented. In yet other embodiments, theapplication service 180 is used to download theregistration application 112 even though theapplication service 180 is not explicitly a part of thedevice binding system 190. These and other variations are discussed in more detail below. - Once the
device 102 is bound at theauthority 150, thesecure identifier 120 can be used as a basis of trust for future interactions with theauthority 150 or a related entity such as a music site, health site, shopping site, etc. The math associated with the uniqueness of the secure identifier is discussed below, however, in the extremely unlikely event that another device has the same unique identifier, the duplicate number can be flagged at the time of registration and a thedevice 102 can be requested to generate a newsecure identifier 120. A time displacement between registration operations, differences in device characteristics, and a location of the requester, among others, can be used to identify that a second device is attempting to register with the duplicatesecure identifier 120. However, as discussed below, the chance of a duplicate is extremely low. -
FIG. 2 is a diagram illustrating one embodiment of thedevice binding system 190 with a minimally configureddevice 102. In this embodiment, thedevice 102 is connected to theauthority 150 via thenetwork 140. Thedevice 102 haslocal registration code 110 that is used to generate thesecure identifier 120. Thedevice 102 stores thesecure identifier 120 in anunalterable memory 118. Theregistration code 110, in combination with thedevice program code 108 may, in one case, provide a user interface (not depicted) for performing the registration process. In this embodiment, thedevice 102 executes the registration code which connects to theauthority 150. The user may be prompted to enter identifying information establish identity prior to allowing the binding. In the case where personal information is being tracked by the device, such as eating habits, fitness routines, or even financial tracking, theauthority 150 will establish the owner's identity so that subsequent information sent from the device can be correctly attributed to the owner. Processes for identifying a user are well known and may include matching login information with a previously established account, matching identifying information such as driver's license or passport information with the user, or the use of two factor identification involving sending a passcode to another device such as a cell phone known to be affiliated with the user. Alternatively, the registration may be anonymous with the knowledge that future access will be based only on credentials established during the registration process. In one such case, an ID and password can be established along with the secure identifier during the binding process. In another case, only thesecure identifier 120 may be used and the data is stored anonymously based solely on thesecure identifier 120. In the embodiment illustrated inFIG. 2 , a public/private key pair may be generated on thedevice 102 so that thedevice 102 can sign, for example, thesecure identifier 120. However, the process involving signing and encryption is more suitable to the embodiment illustrated inFIG. 3 . - The use of public key infrastructure (PKI) as part of establishing and maintaining the trust relationship between the
device 102 and theauthority 150 is shown inFIG. 3 . In this exemplary embodiment, thedevice 102 is shown as having anHSM 122, however, theHSM 122 is not a requirement. This illustrated embodiment also shows that theHSM 122, when present, can be used to store thesecure identifier 120 as an alternative to storage in theunalterable memory 118. - The
device 102 generates a PKI key pair, one stored locally and not shared, making it theprivate key 124, the other key of the key pair being thepublic key 128 which is freely shared. The embodiment ofFIG. 3 uses a certificate authority (CA) 170 to sign the device's public key after sending the public key to theCA 170 and performing some level of identity verification. In an embodiment, theCA 170 may verify an identity of the device owner/user while in another embodiment, thedevice 102 may have separate credentials that are tied to the identity being bound to the public key. TheCA 170 then issues acertificate 114 that includes thepublic key 128 signed by the CA private key (or equivalent sub-key) so that a subsequent participant can trust data signed by the deviceprivate key 124. The details of trust relationships in a PKI infrastructure are well known in the industry. - After the
CA 170 provides thecertificate 114 to thedevice 102, thedevice 102 can use thecertificate 114 as part of the binding process. For example, thedevice 102 can sign (encrypt) thesecure identifier 120 with itsprivate key 124 and provide the signed private key and thecertificate 114 to theauthority 150. Theauthority 150 can then verify an identity associated with thedevice 102 by confirming the validity of thecertificate 114 and determining the identity via thecertificate 114 or theCA 170. -
FIG. 4 is an alternate embodiment of the system described above illustrating that the registration process may be supported by aregistration application 112 that is downloaded prior to the binding process. Theregistration application 112 may be installed on thedevice 102 from anapplication service 180. In one embodiment, thedevice 102 directly supports downloading and executing theregistration application 112. Once downloaded, theapplication 112 is used for the generation of thesecure identifier 120 and subsequent registration procedure discussed briefly above and in more detail below. In one embodiment, theregistration application 112 may include the cryptographic routines required to generate and use public/private key pairs. - In another embodiment, a
connected device 130, such as a smart phone may provide a user interface for downloading theapplication 112, executing the registration process, or both. That is, even though theregistration application 112 may be stored on and executed by thedevice 102, theconnected device 130 can provide a display and a keyboard (not depicted) useful for receiving prompts and entering data used by thedevice 102. Other variations for location and execution of theregistration application 112 are possible. - A variation shown in
FIG. 5 illustrates that theconnected device 130 can also provide a wide-area network connection 132 that supports a data connection between theuser device 102 and thenetwork 140. In an embodiment, theuser device 102 is networked to theconnected device 130 via a physical connection, a Bluetooth™ or a near-field communication (NFC). Theconnected device 130 is coupled to thenetwork 140 via WiFi or a cellular data connection such as WiMax or 4G LTE. Thedevice 102 is then able to communicate via thenetwork 140 through this indirect connection. Some smaller devices, such as wearable devices or smart cards may not be able to support direct connections to anetwork 140 via wide area network. This additional capability allows even more devices to participate in this late binding process. -
FIG. 6 is a flow chart illustrating onemethod 600 of binding adevice 102 to anauthority 150. In this embodiment, themethod 600 generally outlines a two-step process to generate asecure identifier 120 and then to register thatsecure identifier 120 with anauthority 150. Atblock 602, anunalterable memory 118 is provided in thedevice 102 to permanently store information. In an embodiment, theunalterable memory 118 is a fuseable link memory. In an alternate embodiment, a hardware security module (HSM) 122 is used instead of or supplementary to theunalterable memory 118 such that theHSM 122 can be used to store information that must remain unaltered. - At
block 604, a determination is made ifregistration code 110 is available locally for performing a binding operation. For example, theregistration code 110 may be installed at the time of manufacture. If yes, that is, that code embedded in thedevice 102 at the time registration is requested is available, execution continues atblock 606. If, atblock 604, no code is available for device registration, execution may continue atblock 622 where thedevice 102 sends enough information about itself so that anapplication service 180 can determine what version registration application to deliver. For example, theapplication service 180 may need to know the device manufacturer, model number and operating system version in order to deliver thecorrect registration application 112. In an embodiment, theregistration application 112 may also be specific to anauthority 150 to which thedevice 102 will be bound. That is, a coffee shop may use a different registration application than a financial institution. However, in other embodiments, once asecure identifier 120 is generated, it is possible to use thatsecure identifier 120 for multiple authorities. In that case, asingle registration code 110 orregistration application 112 may be sufficient for all needs. Atblock 624, thecorrect registration application 112 is downloaded and instantiated. In an embodiment, theregistration application 112 is downloaded at the time of binding. Theregistration application 112 may also include executable code that performscryptographic functions 116 used to generate thesecure identifier 120, discussed more below. In other embodiments, thecryptographic functions 116 are native to thedevice 102, such as onHSM 122. Once theregistration application 112 is installed and operational, execution of themethod 600 continues atblock 606. - Predetermined device data is read by the
registration code 110 atblock 606. Because theregistration code 110 or theregistration application 112 is device-specific, the device-specific data read can be tailored based on type. That is, different data is used when registering a smart phone vs. a fitness tracker, or even fitness trackers from different manufacturers. In an embodiment, a model number, serial number, and operating system version can be used as the device-specific data. In one embodiment, 60 bytes of device-specific data can be used. In some cases, the device-specific data is data from transient memory or a version number of a tool, such as a Java API. Since the operation to develop thesecure identifier 120 is a one-time process on thedevice 102 only, and does not need to be recreated at another system element, such transient information may be used. - At
block 608, a pseudo-random (or random)number 117 may be obtained. In various embodiments, the pseudo-random number may be generated byregistration code 110 or theregistration application 112, bylocal cryptographic code 116, by anHSM 122, or even received via anetwork connection 131 from another device, for example, theconnected device 130, given trust in thedevice 130. In an embodiment, thepseudo-random number 117 may be 16 bytes. - The device-data and pseudo-random number are combined at
block 610 to develop a base number. The base number is transient. In an embodiment, the combination may simply be a concatenation of the two numbers. Other combination techniques are available and well known, such as a bit XOR. The base number is transient and can be discarded after thesecure identifier 120 is generated. - At
block 612, the secure identifier is generated from the base number, that is the combination of the device-specific data and thepseudo-random number 117. In an embodiment, a one-way cryptographic hash is used to generate thesecure identifier 120. Any of several well-known hashing functions could be used including MD5, SHA, or in one embodiment, a SHA 256 algorithm. In an embodiment, the resultantsecure identifier 120 is a 32 byte number. - By way of comparison, a collision probability for a simple 16 byte random number is about 3.6e−2 using the formula:
-
- where the number of devices is 5 billion (n=5e9) and a 16 byte secure random is used x=128.
- Alternatively, using the one way hash function to further process the larger base number has a collision probability of 1.0e−58 using the formula
-
- where the number of devices, n, is the same as above and b=256 for the SHA 256.
- The collision probability for the latter alternative decreases the chance of duplication by almost 40 orders of magnitude, so that for the foreseeable future, no two devices would have the same
secure identifier 120. In other embodiments, other cryptographic functions could be used to create further distance between possible duplicates, such as a block cipher using another random number as the key. - In an embodiment, the
secure identifier 120 may be registered with an authority atblock 620 using a manual login and password process. However, in many embodiments, an additional process may be implemented to allow continued assertion of the secure identifier as being from thesame device 102. In such an embodiment, a key pair may be generated atblock 614 following a known public/private key generation sequence. Theprivate key 124 of the key pair may be stored securely, for example, in theHSM 122. - If no certificate authority is used, the ‘no’ branch from
block 616 may be followed to block 618 where thesecure identifier 120 is signed with the deviceprivate key 124. The signed identifier and the device public key may be send to theauthority 150 atblock 620. Theauthority 150 can then store the device public key in one of the user stores 152-154 and used to confirm future activity with thedevice 102 by verifying data signed with the deviceprivate key 124. - If it is desirable to increase the level of security, a
certificate authority 170 can be included in the process and the ‘yes’ branch fromblock 616 can be taken to block 626. There, a request can be made to thecertificate authority 170 for acertificate 114. TheCA 170 or a registration authority can perform a supplemental validation of the identity of thedevice 102, or more often, a user associated with thedevice 102. The process for issuing acertificate 114 is well known and not discussed here in more detail. After theCA 170 provides the certificate to thedevice 102, thedevice 102 can then send the certificate to theauthority 150 atblock 628. Thedevice 102 can also then sign and send the signedsecure identifier 120 to theauthority 150. Theauthority 150 can then check the identity of the device/user using thecertificate 114 and use the device public key embedded in thecertificate 114 to decrypt thesecure identifier 120 for the purpose of binding the secure identifier to thedevice 102. - The above disclosure allows late binding of devices so that a trust relationship can be developed even after a
device 102 has left a secure and controlled manufacturing process. The technical effect is that the creation and storage of a device's unique identifier can be moved from the manufacturer orauthority 150 to the device itself. By creating and installing theunique identifier 120 on thedevice 102, the need to pre-set billions of devices with transport keys or other security measures is eliminated. Because the identifier generation process and self-storage is minimally invasive, additional program memory is not required. For example, after the binding/registration process is complete, aregistration application 112 can be deleted so that there is virtually no impact on the long-term configuration of thedevice 102. Whether the binding occurs early or late, the unalterable memory requirements are also the same. - The effect of using a combination of device characteristics and random numbers creates distance between the initial number sets. The use of the hashing or another cryptographic function, as shown above, creates a larger number space and reduces the likelihood of identifier collisions to a level that is mathematically insignificant.
- The technical effect of a
hardware security module 122 is that thedevice 102 can securely generate keys, perform cryptographic functions, such as signing and encryption, and store data with the highest level of security. In various embodiments, theHSM 122 can be in part or in whole a smart chip such as are used in smart cards for access control and financial transactions. - The figures depict preferred embodiments for purposes of illustration only. One skilled in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles described herein
- Upon reading this disclosure, those of skill in the art will appreciate still additional alternative structural and functional designs for the systems and methods described herein through the disclosed principles herein. Thus, while particular embodiments and applications have been illustrated and described, it is to be understood that the disclosed embodiments are not limited to the precise construction and components disclosed herein. Various modifications, changes and variations, which will be apparent to those skilled in the art, may be made in the arrangement, operation and details of the systems and methods disclosed herein without departing from the spirit and scope defined in any appended claims.
Claims (20)
Priority Applications (8)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/277,618 US10397215B2 (en) | 2016-09-27 | 2016-09-27 | Secure element installation and provisioning |
CN201780059285.8A CN109997119B (en) | 2016-09-27 | 2017-10-02 | Secure element installation and setting |
PCT/US2017/054729 WO2018064661A1 (en) | 2016-09-27 | 2017-10-02 | Secure element installation and provisioning |
CA3035663A CA3035663A1 (en) | 2016-09-27 | 2017-10-02 | Secure element installation and provisioning |
AU2017337127A AU2017337127A1 (en) | 2016-09-27 | 2017-10-02 | Secure element installation and provisioning |
GB1903911.4A GB2569062B (en) | 2016-09-27 | 2017-10-02 | Secure element installation and provisioning |
GB2202748.6A GB2604242B (en) | 2016-09-27 | 2017-10-02 | Secure element installation and provisioning |
US16/508,746 US11025613B2 (en) | 2016-09-27 | 2019-07-11 | Secure element installation and provisioning |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/277,618 US10397215B2 (en) | 2016-09-27 | 2016-09-27 | Secure element installation and provisioning |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/508,746 Continuation US11025613B2 (en) | 2016-09-27 | 2019-07-11 | Secure element installation and provisioning |
Publications (2)
Publication Number | Publication Date |
---|---|
US20180091498A1 true US20180091498A1 (en) | 2018-03-29 |
US10397215B2 US10397215B2 (en) | 2019-08-27 |
Family
ID=61685848
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/277,618 Active 2037-01-18 US10397215B2 (en) | 2016-09-27 | 2016-09-27 | Secure element installation and provisioning |
US16/508,746 Active 2036-11-29 US11025613B2 (en) | 2016-09-27 | 2019-07-11 | Secure element installation and provisioning |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/508,746 Active 2036-11-29 US11025613B2 (en) | 2016-09-27 | 2019-07-11 | Secure element installation and provisioning |
Country Status (6)
Country | Link |
---|---|
US (2) | US10397215B2 (en) |
CN (1) | CN109997119B (en) |
AU (1) | AU2017337127A1 (en) |
CA (1) | CA3035663A1 (en) |
GB (2) | GB2604242B (en) |
WO (1) | WO2018064661A1 (en) |
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20180227128A1 (en) * | 2017-02-08 | 2018-08-09 | Ca, Inc. | Secure device registration for multi-factor authentication |
CN108737449A (en) * | 2018-06-26 | 2018-11-02 | 华立科技股份有限公司 | Soft encryption authentication method, device and electronic equipment |
US10579987B2 (en) * | 2013-08-30 | 2020-03-03 | Thales Dis France Sa | Method for authenticating transactions |
US10592872B2 (en) * | 2012-05-21 | 2020-03-17 | Nexiden Inc. | Secure registration and authentication of a user using a mobile device |
US20210328807A1 (en) * | 2020-04-15 | 2021-10-21 | Salesforce.Com, Inc. | Stateless mutual authentication between services |
US11218330B2 (en) * | 2019-03-25 | 2022-01-04 | Micron Technology, Inc. | Generating an identity for a computing device using a physical unclonable function |
US11233650B2 (en) | 2019-03-25 | 2022-01-25 | Micron Technology, Inc. | Verifying identity of a vehicle entering a trust zone |
US11323275B2 (en) | 2019-03-25 | 2022-05-03 | Micron Technology, Inc. | Verification of identity using a secret key |
US11361660B2 (en) | 2019-03-25 | 2022-06-14 | Micron Technology, Inc. | Verifying identity of an emergency vehicle during operation |
US20220217136A1 (en) * | 2021-01-04 | 2022-07-07 | Bank Of America Corporation | Identity verification through multisystem cooperation |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
RU2018138396A (en) | 2016-05-03 | 2020-06-03 | Виза Интернэшнл Сервис Ассосиэйшн | PLATFORM FOR THE RESOURCE CATALOG BASED ON THE DEVICE |
CN116150731B (en) * | 2022-11-28 | 2023-09-15 | 深圳市富临通实业股份有限公司 | Method for preventing MCU internal program from plagiarism based on UID |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US3872450A (en) * | 1973-06-21 | 1975-03-18 | Motorola Inc | Fusible link memory cell for a programmable read only memory |
US20050268115A1 (en) * | 2004-04-30 | 2005-12-01 | Microsoft Corporation | Renewable and individualizable elements of a protected environment |
US20060090070A1 (en) * | 2004-10-21 | 2006-04-27 | International Business Machines Corporation | Method and system for verifying binding of an initial trusted device to a secured processing system |
US20110082966A1 (en) * | 2009-10-02 | 2011-04-07 | Yu Samuel Y | Authentication and Securing of Write-Once, Read-Many (WORM) Memory Devices |
US20130097274A1 (en) * | 2011-10-13 | 2013-04-18 | People Power Company | Method and system for managing a slave device through a master device |
US20150312255A1 (en) * | 2012-05-22 | 2015-10-29 | Verizon Patent And Licensing Inc. | Encrypting a unique identification header to create different transactional identifiers |
US20170034168A1 (en) * | 2014-09-16 | 2017-02-02 | Nok Nok Labs, Inc. | System and method for integrating an authentication service within a network architecture |
Family Cites Families (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1779635B1 (en) | 2004-08-19 | 2008-03-05 | France Télécom | Method for assigning an authentication certificate and infrastructure for assigning a certificate |
US20060072748A1 (en) | 2004-10-01 | 2006-04-06 | Mark Buer | CMOS-based stateless hardware security module |
WO2008073606A2 (en) * | 2006-11-02 | 2008-06-19 | Legitimi Limited | Access control system based on a hardware and software signature of a requesting device |
US8689300B2 (en) * | 2007-01-30 | 2014-04-01 | The Boeing Company | Method and system for generating digital fingerprint |
US9117060B2 (en) | 2009-05-07 | 2015-08-25 | Cadence Design Systems, Inc. | System and method for preventing proper execution of an application program in an unauthorized processor |
CN101968774A (en) * | 2010-10-21 | 2011-02-09 | 中国人民解放军61938部队 | Device and method for storing mobile data safely |
US9407329B2 (en) | 2013-04-19 | 2016-08-02 | Nxp B.V. | Secure near field communication solutions and circuits |
EP2665235B1 (en) | 2012-05-15 | 2016-01-06 | Nxp B.V. | Method for establishing secure communication between nodes in a network, network node, key manager, installation device and computer program product |
AU2013204953B2 (en) | 2012-08-30 | 2016-09-08 | The Nielsen Company (Us), Llc | Methods and apparatus to collect distributed user information for media impressions |
CN103095460B (en) * | 2013-01-22 | 2015-07-22 | 飞天诚信科技股份有限公司 | Intelligent card safety communication method |
GB2515833A (en) * | 2013-07-05 | 2015-01-07 | Recipero Ltd | System for generating a security document |
US20150113291A1 (en) * | 2013-10-23 | 2015-04-23 | Spectra Logic Corporation | Cyptographic branding of data containers |
US9953144B2 (en) * | 2014-03-27 | 2018-04-24 | Nxp B.V. | Constellation based device binding |
KR20150117225A (en) * | 2014-04-09 | 2015-10-19 | (주) 아이씨티케이 | Apparatus and method for authenticating |
US9197414B1 (en) | 2014-08-18 | 2015-11-24 | Nymi Inc. | Cryptographic protocol for portable devices |
WO2016061588A1 (en) * | 2014-10-17 | 2016-04-21 | Cloudwear, Inc. | Verifying a user based on digital fingerprint signals derived from out-of-band data |
CN106161017A (en) * | 2015-03-20 | 2016-11-23 | 北京虎符科技有限公司 | ID authentication safety management system |
US10735200B2 (en) * | 2015-03-27 | 2020-08-04 | Comcast Cable Communications, Llc | Methods and systems for key generation |
US9853975B2 (en) * | 2015-08-26 | 2017-12-26 | Ca, Inc. | Restricting access to content based on measurements of user terminal operational performance |
CN106506479B (en) * | 2016-10-24 | 2019-09-13 | 北京明华联盟科技有限公司 | Method, system and the client of cipher authentication, server and smart machine |
-
2016
- 2016-09-27 US US15/277,618 patent/US10397215B2/en active Active
-
2017
- 2017-10-02 GB GB2202748.6A patent/GB2604242B/en active Active
- 2017-10-02 CN CN201780059285.8A patent/CN109997119B/en active Active
- 2017-10-02 GB GB1903911.4A patent/GB2569062B/en active Active
- 2017-10-02 WO PCT/US2017/054729 patent/WO2018064661A1/en active Application Filing
- 2017-10-02 AU AU2017337127A patent/AU2017337127A1/en not_active Abandoned
- 2017-10-02 CA CA3035663A patent/CA3035663A1/en not_active Abandoned
-
2019
- 2019-07-11 US US16/508,746 patent/US11025613B2/en active Active
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US3872450A (en) * | 1973-06-21 | 1975-03-18 | Motorola Inc | Fusible link memory cell for a programmable read only memory |
US20050268115A1 (en) * | 2004-04-30 | 2005-12-01 | Microsoft Corporation | Renewable and individualizable elements of a protected environment |
US20060090070A1 (en) * | 2004-10-21 | 2006-04-27 | International Business Machines Corporation | Method and system for verifying binding of an initial trusted device to a secured processing system |
US20110082966A1 (en) * | 2009-10-02 | 2011-04-07 | Yu Samuel Y | Authentication and Securing of Write-Once, Read-Many (WORM) Memory Devices |
US20130097274A1 (en) * | 2011-10-13 | 2013-04-18 | People Power Company | Method and system for managing a slave device through a master device |
US20150312255A1 (en) * | 2012-05-22 | 2015-10-29 | Verizon Patent And Licensing Inc. | Encrypting a unique identification header to create different transactional identifiers |
US20170034168A1 (en) * | 2014-09-16 | 2017-02-02 | Nok Nok Labs, Inc. | System and method for integrating an authentication service within a network architecture |
Cited By (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10592872B2 (en) * | 2012-05-21 | 2020-03-17 | Nexiden Inc. | Secure registration and authentication of a user using a mobile device |
US10579987B2 (en) * | 2013-08-30 | 2020-03-03 | Thales Dis France Sa | Method for authenticating transactions |
US20180227128A1 (en) * | 2017-02-08 | 2018-08-09 | Ca, Inc. | Secure device registration for multi-factor authentication |
US10461939B2 (en) * | 2017-02-08 | 2019-10-29 | Ca, Inc. | Secure device registration for multi-factor authentication |
CN108737449A (en) * | 2018-06-26 | 2018-11-02 | 华立科技股份有限公司 | Soft encryption authentication method, device and electronic equipment |
US11218330B2 (en) * | 2019-03-25 | 2022-01-04 | Micron Technology, Inc. | Generating an identity for a computing device using a physical unclonable function |
US11233650B2 (en) | 2019-03-25 | 2022-01-25 | Micron Technology, Inc. | Verifying identity of a vehicle entering a trust zone |
US11323275B2 (en) | 2019-03-25 | 2022-05-03 | Micron Technology, Inc. | Verification of identity using a secret key |
US11361660B2 (en) | 2019-03-25 | 2022-06-14 | Micron Technology, Inc. | Verifying identity of an emergency vehicle during operation |
US11962701B2 (en) | 2019-03-25 | 2024-04-16 | Micron Technology, Inc. | Verifying identity of a vehicle entering a trust zone |
US20210328807A1 (en) * | 2020-04-15 | 2021-10-21 | Salesforce.Com, Inc. | Stateless mutual authentication between services |
US11552802B2 (en) * | 2020-04-15 | 2023-01-10 | Salesforce, Inc. | Stateless mutual authentication between services |
US20220217136A1 (en) * | 2021-01-04 | 2022-07-07 | Bank Of America Corporation | Identity verification through multisystem cooperation |
Also Published As
Publication number | Publication date |
---|---|
GB2604242A (en) | 2022-08-31 |
WO2018064661A1 (en) | 2018-04-05 |
GB202202748D0 (en) | 2022-04-13 |
US11025613B2 (en) | 2021-06-01 |
CN109997119A (en) | 2019-07-09 |
GB2569062B (en) | 2022-04-13 |
GB201903911D0 (en) | 2019-05-08 |
CN109997119B (en) | 2022-11-04 |
US20190334888A1 (en) | 2019-10-31 |
AU2017337127A1 (en) | 2019-04-04 |
GB2604242B (en) | 2022-11-16 |
CA3035663A1 (en) | 2018-04-05 |
GB2569062A (en) | 2019-06-05 |
US10397215B2 (en) | 2019-08-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11025613B2 (en) | Secure element installation and provisioning | |
US10904002B2 (en) | Token security on a communication device | |
ES2820554T3 (en) | Method and apparatus for authenticating a user, method and apparatus for registering a wearable device | |
AU2010215040B2 (en) | System and methods for online authentication | |
US9734091B2 (en) | Remote load and update card emulation support | |
CN110300972B (en) | Anonymous attestation | |
US20190251561A1 (en) | Verifying an association between a communication device and a user | |
JP2017503254A (en) | Method and system for determining whether a terminal logged into a website is a mobile terminal | |
KR101210260B1 (en) | OTP certification device | |
CN102096841B (en) | Integrated circuit and system for installing computer code thereon | |
US11140156B2 (en) | Systems and methods for use in binding internet of things devices with identities associated with users | |
AU2015323425A1 (en) | Systems and methods for identifying mobile devices | |
TWI784456B (en) | Data processing method, device, equipment and medium | |
TW202238478A (en) | Card binding method, terminal equipment, authentication server and storage medium | |
CN110705985B (en) | Method and apparatus for storing information | |
US9246677B2 (en) | Method and system for secure data communication between a user device and a server | |
KR20170026060A (en) | Apparatus and method for processing payment information of electronic device | |
AU2015202661A1 (en) | System and methods for online authentication | |
US20230116566A1 (en) | Method and apparatus for managing application | |
CN112583606B (en) | Security verification method, server, terminal and storage medium | |
US20230073894A1 (en) | Blockchain network-based virtual common id service method and service provision server using same | |
EP2985724A1 (en) | Remote load and update card emulation support | |
KR20160039593A (en) | Method for Providing OTP based on Location | |
CN115004629A (en) | Apparatus, method and program for enabling digital use of certificate data | |
KR20150140453A (en) | Banking service providing method by contacting card and system performing the same |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: VISA INTERNATIONAL SERVICE ASSOCIATION, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:KEKICHEFF, MARC;PIRZADEH, KIUSHAN;CHEN, YUEXI;SIGNING DATES FROM 20161003 TO 20161017;REEL/FRAME:040124/0121 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NOTICE OF ALLOWANCE MAILED -- APPLICATION RECEIVED IN OFFICE OF PUBLICATIONS |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: PUBLICATIONS -- ISSUE FEE PAYMENT VERIFIED |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 4 |