US20160065374A1 - Method of using one device to unlock another device - Google Patents
Method of using one device to unlock another device Download PDFInfo
- Publication number
- US20160065374A1 US20160065374A1 US14/810,395 US201514810395A US2016065374A1 US 20160065374 A1 US20160065374 A1 US 20160065374A1 US 201514810395 A US201514810395 A US 201514810395A US 2016065374 A1 US2016065374 A1 US 2016065374A1
- Authority
- US
- United States
- Prior art keywords
- key
- receiving
- secret
- unlocking
- passcode
- 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.)
- Abandoned
Links
- 238000000034 method Methods 0.000 title claims abstract description 66
- 230000004044 response Effects 0.000 claims abstract description 13
- 238000012545 processing Methods 0.000 claims description 20
- 230000008569 process Effects 0.000 description 14
- 238000004891 communication Methods 0.000 description 8
- 230000007246 mechanism Effects 0.000 description 8
- 230000007774 longterm Effects 0.000 description 7
- 238000010586 diagram Methods 0.000 description 6
- 229920001098 polystyrene-block-poly(ethylene/propylene) Polymers 0.000 description 4
- 230000006870 function Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000013475 authorization Methods 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 238000009795 derivation Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Images
Classifications
-
- 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/3234—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 additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/44—Program or device authentication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/44—Program or device authentication
- G06F21/445—Program or device authentication by mutual authentication, e.g. between devices or programs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/32—User authentication using biometric data, e.g. fingerprints, iris scans or voiceprints
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards
- G06F21/35—User authentication involving the use of external additional devices, e.g. dongles or smart cards communicating wirelessly
-
- 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/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
- H04L9/0822—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using key encryption key
-
- 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/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
- H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
-
- 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/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
-
- 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/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
-
- 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/3226—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 using a predetermined code, e.g. password, passphrase or PIN
-
- 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/3271—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 using challenge-response
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/08—Access security
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/50—Secure pairing of devices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2129—Authenticate client device independently of the user
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2133—Verifying human interaction, e.g., Captcha
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2147—Locking files
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/24—Key scheduling, i.e. generating round keys or sub-keys for block encryption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
Definitions
- This relates generally to a device-unlocking method and system, and more particularly, to unlocking one device using another device.
- Modern electronic devices such as smartphones and tablet PCs typically have one or more locking/unlocking mechanisms to keep the devices secure.
- a user can input a passcode on a login screen of the device or employ a different mechanism such as scanning his fingerprint with a fingerprint scanner. These mechanisms are typically carried out directly on the device being unlocked.
- the device that can unlock another device can be the first device and the device that can be unlocked by another device can be the second device.
- a method of unlocking a second device using a first device can include: the first device pairing with the second device; establishing a trusted relationship with the second device; mutually authenticating both devices (i.e., building a trusted relationship between the devices) using a distinct device key in each device (that cannot be removed from the device); receiving a secret key from the second device during setup and storing it; and transmitting the received secret key to the second device to unlock the second device in response to receiving the user input.
- the first device can initially contact the second device.
- the second device can then send the first device a secret and ask the user for the passcode.
- the second device can derive the master key, validate unlock and store an escrow record.
- the escrow record contains the master key encrypted by the unlock key as well as the unlock key encrypted by the master key, so that any time the master key changes, the record can be updated.
- a method of a second device being unlocked by a first device is disclosed.
- one handheld device can unlock another handheld device.
- the method can include: establishing a trusted relationship with the second device; mutually authenticating both devices using a distinct device key in each device; sending a secret key to the first device during registration; unlocking the second device after receiving a passcode; deriving a master key from the passcode; encrypting the master key with the secret key previously sent to the first device; receiving the secret key from the first device; retrieving the master key using the received secret key; and using the master key to perform an unlocking operation.
- the first device can first check in, perform mutual authentication, and exchange a secret with the second device.
- the second device can keep the master key wrapped to the exchanged secret.
- a first device capable of unlocking a second device can include: a pairing module configured for pairing with the second device; an authentication module configured for authenticating itself using a device key; a receiving module configured for receiving a secret key from the second device; a user input processing module configured for processing a user input received from an input/output device of the first device; and a transmitting module configured for transmitting the received secret key to the second device to unlock the second device in response to the user input.
- a second device capable of being unlocked by a first device.
- the second device can include: a pairing module configured for pairing with the first device; a receiving module configured for receiving a public device key and a secret key from the first device; a key signing module configured for signing the received public device key with a private device key associated with the second device; a transmitting module configured for sending a secret key to the first device; a user input processing module configured for processing a passcode; a deriving module configured for deriving a master key from the passcode; an encrypting module configured for encrypting the master key with the secret key; a retrieving module configured for retrieving the master key using the received secret key; and an unlocking module configured for using the master key to perform an unlocking operation.
- FIG. 1 illustrates a first device and a second device, the first device capable of unlocking the second device, according to an embodiment of the disclosure.
- FIG. 2 is a flowchart illustrating the exemplary steps in a method of using a first device to unlock a second device, according to an embodiment of the disclosure.
- FIG. 3 is a flowchart illustrating the exemplary steps in a registration process, according to an embodiment of the disclosure.
- FIG. 4 is a flowchart illustrating the exemplary steps in a method of using a first device to unlock a second device, according to an embodiment of the disclosure.
- FIG. 5 is a block diagram illustrating the exemplary modules of a device such as the first device or second device of FIG. 1 , according to an embodiment of the disclosure.
- FIG. 6 illustrates the exemplary steps in the pairing of the two devices, according to an embodiment of the disclosure.
- FIG. 7 illustrates the exemplary steps in a method of using the first device to unlock the second device, according to an embodiment of the disclosure.
- FIG. 8 is a block diagram illustrating the exemplary modules of a second device that can be remotely unlocked by another device, according to an embodiment of the disclosure.
- FIG. 9 is a block diagram illustrating the exemplary modules of a first device that can perform a remote unlocking of another device, according to an embodiment of the disclosure.
- FIG. 10 illustrates exemplary components of a computing system such as the first device or second device described in the embodiments of the disclosure.
- the device that can unlock another device can be the first device and the device that can be unlocked by another device can be the second device.
- FIG. 1 illustrates a first device 100 and a second device 112 .
- the first device 100 can be used for unlocking the second device 112 .
- the first device can be, for example, a smartphone, tablet PC, laptop, desktop PC, Mac, electronic reader, smart TV, or game console, or any other devices capable of communicating with another device.
- the first device 100 can include a secure processor such as a secure enclave processor (SEP) 105 and an application processor that includes a kernel 108 and a user land 110 (also referred to commonly as userspace).
- SEP 105 can be a processor separate from the application processor (AP) containing kernel 108 and user land 110 .
- the user land 110 can facilitate the operations of third party applications on the device.
- SEP secure enclave processor
- the kernel 108 can be the core of the OS and provide a number of interfaces to the user land and manage the input/output (I/O) requests from the applications. In some embodiments, the kernel 108 can also perform key management operations to protect data on the device 100 .
- the SEP 105 can be a relatively small processor that can define a security boundary within which a key management module can reside. The keys can be available when the device is or was previously unlocked. The kernel 108 can communicate with the SEP 105 .
- the SEP can include a biometric matching module 104 and key management module 106 .
- the first device 100 can include one or more locking/unlocking mechanisms.
- One of the mechanisms to unlock the first device can be by entering a passcode on an I/O device such as a touch screen or a physical keypad. Once entered, the passcode can be carried through the user land 110 , the kernel 108 , to the SEP 105 .
- the SEP can perform a derivation based on the passcode to determine whether the first device 100 can be unlocked and to attempt to unlock its set of user data keys. When the first device is unlocked, the user data keys in the key management module 106 can become available to the device 100 .
- the first device 100 can also include a fingerprint scanner 102 designed to unlock the device with a user's fingerprint.
- the fingerprint scanner 102 can capture an image of the fingerprint and send the image to the biometric matching module 104 for processing. After the biometric matching module verifies the captured fingerprint image, it can hand the random key back to the key management module 106 , which can prompt the keys in the key management module 106 to be made available to the device 100 .
- the biometric matching module 104 can optionally hold on to the random key in memory after it finishes analyzing the fingerprint.
- the second device 112 can include the same components as the first device.
- the second device 112 can also include a SEP 116 and an application processor including kernel 118 and user land 120 .
- the SEP 116 , kernel 118 , and user land 120 can operate in a similar way as their counterparts in the first device 100 .
- the second device may not include a fingerprint scanner.
- the second device may have a fingerprint scanner.
- the second device 112 may not have SEP 116 and biometric matching module, and the key management module 122 can reside in kernel 118 .
- the first device can be an iPhone with a fingerprint scanner and the second device can be an iPad, a wearable device, or any other device without a fingerprint scanner.
- the biometric matching module 104 of the first device can receive a secret (e.g., random key) from the key management module 106 when it was unlocked with a passcode and handed it out to the key management module when the first device is unlocked by a fingerprint match.
- the first device 100 can unlock the second device 112 based on similar principles.
- a fingerprint image received by the fingerprint sensor can cause the biometric matching module 104 of the first device 100 to hand out a secret key. Instead of unlocking the first device it can cause key management module 106 to release a secret to key management module 122 on the other device 112 .
- This secret key can be passed through the user land 110 of the first device 100 , over a communication channel 130 connecting both key management modules 106 , 122 on the two devices 100 , 112 , and through the user land 120 of the second device 112 to the SEP 116 of the second device 112 .
- the secret key can then be used to unlock the second device 112 , as will be described in detail in the embodiments below.
- the device with a SEP may refuse to send its keys to the device without the SEP to avoid a device with weaker protection being able to unlock one with stronger protection.
- the devices can authenticate each other as trusted devices (e.g., a device with a SEP).
- a common key can be used to validate that a device key (discussed below) associated with each of the first and second devices is owned by a SEP of a trusted device.
- the remote unlocking operation can be enabled only between devices having the same type of SEPs (e.g., Apple's SEP).
- a common key e.g., K SEP GLOBAL
- K SEP GLOBAL can be derived from a symmetric hardware key shared by the SEPs of the two devices. K SEP GLOBAL can then be used for signing one or more other keys that can be used during a remote unlocking process.
- K SEP GLOBAL A key that is signed by the common key, K SEP GLOBAL , can be deemed to be generated from a device with a SEP, i.e., a device that can be trusted.
- a device specific asymmetric key that has been certified by a common authority can be used. Certification can include a classification of the device that can be used to determine its level of protection.
- K SEP GLOBAL One of the keys that can be validated by K SEP GLOBAL can be a device key, K d , which can be unique to each device and used for identifying the device.
- K d1 can be a key identifying the first device
- K d2 can be a key identifying the second device.
- K d can be derived from a randomly generated secret for this pairing, a randomly-generated universally unique identifier (UUID) (e.g., KeyBag UUID identifying the current set of User Keys), and a device specific hardware key, e.g., K SEP LOCAL .
- UUID universally unique identifier
- K SEP LOCAL can be one of the device keys in the key management module of the device that can be used for protecting data associated with the device.
- the randomly generated secret can be a random value generated by the key store on creation to provide key entropy and uniqueness.
- the UUID can be for the KeyBag that is being unlocked by the mechanism.
- the device specific hardware key can be a data protection class key with particular availability (e.g., available at any time, after having been unlocked, or when the device is unlocked).
- the first device can use an “is-unlocked” device key so it can only authenticate while it is unlocked itself.
- the second device can use a “been-unlocked” device key, which can require it to having been unlocked once before it can be remotely unlocked.
- K d1 and K d2 can authenticate the first and second devices, respectively.
- K d1 and K d2 can be used for the first device to unlock the second device when the second device has never been unlocked previously.
- K du can be used not only for authenticating the device, but also for identifying whether a device has been unlocked by a user before.
- K du can be generated in the SEP of the corresponding device and protected using a passcode associated with the device.
- K du1 can be a device unlock key associated with the first device
- K du2 can be a device unlock key associated with the second device.
- K du can be derived only if the device has been unlocked before, which can imply that it had been accessed by someone with the correct passcode. If the device is lost, a new user likely would not have the passcode to unlock the device.
- K du can be lost. Without K du , the device would no longer be able to prove to another device that it is still under the control of the same user. In other words, K du can be used for proving not only that the device is a trusted device, but also that it is still under the same user's control. As such, the first device can rely on the presence of K du2 to make sure that it does not accidentally unlock the second device when the second device is no longer in the possession of the user and has been rebooted.
- FIGS. 2-5 illustrate exemplary algorithm steps in the various stages of a remote unlocking method, according to embodiments of the disclosure.
- a one-direction unlocking process e.g., using the first device to unlock the second device
- the disclosed systems and methods can be easily modified to perform unlocking in both directions (e.g., also using the second device to unlock the first device), without departing from the spirit of the disclosure.
- the algorithm for the remote unlocking process can include three main steps. First, the first device and the second device can be paired (step 201 ). Next the second device can authorize remote unlocking by the first device (step 202 ). Finally, the first device can unlock the second device in response to a user input on the first device (step 203 ). Each of these steps is discussed in more detail below.
- the two devices can be paired (step 201 ).
- the devices can be paired using any suitable pairing mechanisms such as Bluetooth when the devices are in close proximity of each other.
- the Bluetooth pairing can be a secure pairing using a Bluetooth out-of-band key.
- the devices can be paired by using a camera on one of the devices to capture a computer-readable code (e.g., a QR code or bar code) displayed on the display of the other device.
- This code can include information such as a device ID and other information (e.g., a Bluetooth out-of-band key) needed to pair the two devices.
- close proximity pairing is discussed in these embodiments, it should be understood that pairing the two devices does not necessarily require that the devices to be in close proximity. Indeed, any pairing mechanism designed to pair devices at any distance can be used in this step.
- the devices After being paired, the devices can go through a registration process that can establish a trusted relationship between the two devices so that one of the devices can be securely unlocked by the other device.
- remote unlocking between the devices can be authorized (step 202 ).
- registration can involve pairing the controllers (e.g., SEPs) of the keys of the two devices and also potentially binding the SEPs of the two devices.
- This step can involve, for example, the devices exchanging and cross-signing their public keys that can be used when authenticating during the registration process, setting up a shared key, and during the unlocking process when this shared key is used.
- pairing can be performed on both devices symmetrically.
- FIG. 3 is a flow chart illustrating the exemplary algorithm steps in the registration step 202 of FIG. 2 .
- the first device i.e., the device performing the unlocking
- the second device i.e., the device to be unlocked
- This public key can be used to validate that the first device is a trusted device when the first device attempts to unlock the second device.
- the second device can also perform an authorization, which can include receiving a passcode from the user and optionally an out-of-band verification when the user unlocks the second device locally (step 302 ). Because the passcode protects K du2 , it can be used to prove that the device is in the possession of the user.
- the second device can then sign the public key, K du1, pub , with its private key, K du2, private (step 303 ). As a result, the second device can determine that a device using K du1, pub to authenticate during an unlocking operation can be a trusted device. If the registration is successful, the first device can be used to unlock the second device as follows.
- FIG. 4 illustrates the exemplary algorithm steps in using the first device to unlock the second device (i.e., step 203 of FIG. 2 ), according to an embodiment of the disclosure.
- the first device can be a handheld device and the second device can be a wearable device. First, the two devices can detect that they are in the vicinity of each other (step 401 ).
- this step can only require that the devices to be able to locate each other without requiring them to be close to each other.
- a communication channel such as a Bluetooth or Wi-Fi channel can be established between the two devices (step 402 ).
- the first device can be authenticated using K du1 (step 403 ).
- the second device can be authenticated using K du2 .
- the station-to-station protocol can be used for setting up a mutually authenticated and encrypted tunnel.
- both devices can use ephemeral encryption keys, which in the process are authenticated using the signing keys exchanged during pairing.
- the second device can send a random secret key, S, to the first device using, for example, the negotiated session key derived from the ephemeral encryption keys used by both devices (step 404 ).
- the first device can store the secret key (step 405 ).
- the second device can be unlocked with a passcode (step 406 ).
- a master key, M can be derived from the passcode by the second device (step 407 ).
- the second device can build a token by encrypting the master key M with the secret key S (step 408 ) so that when the first device returns the secret key S to the second device, the second device can use S to decrypt the token to retrieve the master key M.
- the second device can concatenate the token with a secret key S encrypted using the master key M, and store this concatenation as an escrow record (step 409 ). This can allow the second device to recover the secret key S when the master key M changes and build a new token.
- the second device can produce an escrow record for the first device using the secret key S stored the master key M wrapped to the secret key S, which can allow the device to be unlocked without having been unlocked before.
- a fixed secret and escrow record can be established during setup, and in an alternative embodiment, a random secret and a temporary escrow record can be established in response to a device unlock during registration.
- the second device can be authenticated using K du2 (step 410 ).
- the first device can be authenticated with K du1 (step 411 ).
- the devices can exchange secrets with one another.
- the first device can send the secret key S that it received from the second device back to the second device (step 412 ). This can be in response to the user scanning his fingerprint using the fingerprint scanner of the first device.
- the second device can retrieve the master key M by decrypting the token with the secret key S (step 413 ).
- the master key M can allow the second device to be unlocked (step 414 ).
- K d2 can be used in place of K du2 in the method described above in view of FIG. 4 .
- the second device can produce an escrow record for the first device using the secret key S stored the master key M wrapped to the secret key S, which can allow the device to be unlocked without having been unlocked before.
- the second device can use the device key to locate the escrow record and the secret key S to unwrap the master key M, which can be used to unlock the second device.
- FIG. 5 is a block diagram illustrating the exemplary modules of a device 500 such as the first device 100 or the second device 112 of FIG. 1 that is capable of either unlocking another device or being unlocked by another device or both.
- the device 500 can include, for example, a detecting module 501 , a pairing module 502 , a key signing module 503 , a transmitting module 504 , a receiving module 505 , an authentication module 506 , a key generating module 507 , and a user input processing module 508 .
- the detecting module 501 can detect the second device (e.g., when the second device is in its vicinity).
- the pairing module 502 can pair the first device with the second device.
- the key signing module 503 can sign one or more keys with another key.
- the transmitting module 504 can transmit one or more keys (e.g., K du1 , S) to another device.
- the receiving module 505 can receive one or more keys (e.g., S) from another device.
- the authentication module 506 can authenticate the device 500 .
- the key generating module 507 can include a deriving module, and can derive a master key from a passcode and generate one or more hardware keys (e.g., K SEP GLOBAL ) that can be used in the unlocking process.
- the user input processing module 508 can process user input, including but not limited to, passcodes and/or fingerprints.
- modules of FIG. 5 can be optional and additional modules can be included in the device 500 .
- Each of the modules can be implemented in either software, hardware or both.
- the modules of device 500 are software modules for performing the algorithms disclosed herein.
- the modules of device 500 represent one or more processors coupled to memory storing computer-readable instructions for performing the algorithms disclosed herein.
- the modules of device 500 comprise hardware and software elements of an ASIC, such as a system-on-a-chip, for performing the functions described above.
- FIGS. 6 and 7 illustrate an embodiment of a transport protocol algorithm that can facilitate the exchanging of keys (or records) in the remote unlocking of the second device by the first device, as described in the above embodiments.
- FIG. 6 illustrate the exemplary algorithm steps in the pairing of the two devices.
- This pairing process can take place after a communication channel has already been established between the two devices.
- the second device can receive a password entered by a user (step 601 ).
- the password can be used for later use.
- the second device can generate a long term key, Key 1 (step 602 ).
- generating a long term key can refer to creating a key pair of which one can be sent to another device.
- Key 1 i.e., one of keys in the key pair, Key 1
- the first device can sign and store Key 1 (step 604 ).
- the first device can then generate its own long term key, Key 2 (step 605 ).
- a session can then be created on the first device using the signed Key 1 received from the second device and the newly-generated short term Key 2 (step 606 ).
- the long term keys, Key 1 and Key 2 can be kept to create other sessions in the future.
- Another short term key, Key 3 can be created when the session is created (step 607 ). Keys 2 and 3 can then be sent across the communication channel to the second device (step 608 ).
- the second device can sign and store Key 2 (step 609 ).
- the second device can then create a session at its end using both Key 2 and Key 3 (step 610 ).
- the second device can generate Key 4 using Key 3 received from the first device (step 611 ).
- Key 4 can then be sent across the communication channel to the first device (step 612 ).
- the first device confirms and stores Key 4 (step 613 )
- Key 4 can be registered as a key for unlocking the second device (step 614 ). If the registration fails, a message can be sent back to the first device, which can cause the first device to delete Key 4 (step 615 ). Otherwise, the pairing of the devices is successful and the devices are set up to perform a remote unlock operation (e.g., using the first device to unlock the second device).
- FIG. 7 illustrates the exemplary algorithm steps in a method of using the first device to unlock the second device.
- the first device can receive a user input to unlock the second device (step 701 ).
- the first device can create a session using long term Keys 1 and 2 (step 702 ).
- Another short term key, Key A can be generated from the newly-created session (step 703 ).
- the first device can then send Key A across the communication channel to the second device (step 704 ).
- steps 703 and 704 can be to set up a short term key agreement between the first and second devices so that Key 4 can be sent across later to unlock the second device.
- the short term key (e.g., Key A) is unique for each session and only used once for encrypting Key 4 , the short term key exchange can prevent a replay attack in which Key 4 is captured when transmitted across the communication channel and then resent from a device other than the first device to the second device to unlock the second device.
- the short term key A is then sent to the second device (step 704 ) to create a session on the second device (step 705 ).
- the second device can then use Key A to create another key, Key B (step 706 ).
- Key B can be sent back to the first device (step 707 ).
- the first device can use Key B to encrypt Key 4 to generate a new key, Key C (step 708 ).
- the encrypted Key 4 i.e., Key C
- the unlocking process can involve decrypting Key C to retrieve Key 4 and using Key 4 to unlock the second device.
- FIG. 8 is a block diagram illustrating the exemplary modules of the second device 800 of FIGS. 6 and 7 that can be remotely unlocked by another device (e.g., the first device).
- the second device 800 can include, for example, a password receiving module 801 , a key generating module 802 , a transmitting module 803 , a receiving module 804 , a key signing module 805 , a storing module 806 , a session creating module 807 , a registering module 808 , a decrypting module 809 , and an unlocking module 810 .
- the password receiving module 801 can receive a password (or other input) from a user.
- the key generating module 802 can generate long term and/or short term keys (e.g., Keys 1 , 4 , and B of FIGS. 6 and 7 ).
- the transmitting module 803 can transmit one or more encrypted or unencrypted keys to another device (e.g., the first device).
- the receiving module 804 can receive one or more encrypted or unencrypted keys from another device (e.g., the first device).
- the key signing module 805 can sign a key (e.g., Key 2 ) received from another device.
- the storing module 806 can store keys generated locally or received from another device.
- the session creating module 807 can create a session using a key (e.g., Key 2 and Key A) received from another device.
- the registering module 808 can register a key (e.g., Key 4 ) as a key for unlocking the second device.
- the decrypting module 809 can decrypt any decrypted key (e.g., Key C) received from another device.
- the unlocking module 810 can unlock the second device using a key (e.g., Key 4 obtained by decrypting Key C).
- FIG. 9 is a block diagram illustrating the exemplary modules of the first device 900 of FIGS. 6 and 7 that can perform a remote unlocking of another device (e.g., the second device).
- the first device 900 can include, for example, a transmitting module 901 , a receiving module 902 , a key signing module 903 , a storing module 904 , a session creating module 905 , a key generating module 906 , a confirming module 907 , a key deleting module 908 , and an encrypting module 909 .
- the transmitting module 901 can transmit one or more keys (e.g., Keys 2 , 3 , A, C) to another device (e.g., the second device of FIGS.
- the receiving module 902 can receive one or more keys (e.g., Keys 1 , 4 , B) from another device (e.g., the second device).
- the key signing module 903 can sign a key (e.g., Key 1 ) received from another device.
- the storing module 904 can store one or more keys generated locally or received from another device.
- the session creating module 905 can create a session using one or more keys (e.g., Keys 1 and 2 ).
- the key generating module 906 can generate one or more long term and/or short term keys (e.g., Keys 2 , 3 , A, C).
- the confirming module 907 can confirm a key (e.g., Key 4 ) as a key for unlocking another device.
- the key deleting module 908 can delete a key from the device.
- the encrypting module 909 can encrypt a key (e.g., Key 4 ) using another key (e.g., Key B) to generate an encrypted key (e.g., Key C).
- modules of FIGS. 8 and 9 can be optional and additional modules can be included in the devices 800 and 900 .
- Each of the modules can be implemented in either software, hardware or both.
- the modules of device 800 and 900 are software modules for performing the algorithms disclosed herein.
- the modules of device 800 and 900 represent one or more processors coupled to memory storing computer-readable instructions for performing the algorithms disclosed herein.
- the modules of device 800 and 900 comprise hardware and software elements of an ASIC, such as a system-on-a-chip, for performing the functions described above.
- one or more of the modules of the devices 500 , 800 , and 900 can be stored and/or transported within any non-transitory computer-readable storage medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions.
- an instruction execution system, apparatus, or device such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions.
- a “non-transitory computer-readable storage medium” can be any medium that can contain or store the program for use by or in connection with the instruction execution system, apparatus, or device.
- the non-transitory computer readable storage medium can include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus or device, a portable computer diskette (magnetic), a random access memory (RAM) (magnetic), a read-only memory (ROM) (magnetic), an erasable programmable read-only memory (EPROM) (magnetic), a portable optical disc such a CD, CD-R, CD-RW, DVD, DVD-R, or DVD-RW, or flash memory such as compact flash cards, secured digital cards, USB memory devices, memory sticks, and the like.
- the non-transitory computer readable storage medium can be part of a computing system serving as the first device or the second device.
- FIG. 10 illustrates exemplary common components of one such computing system.
- the system 1000 can include a central processing unit (CPU) 1002 , I/O components 1004 including, but not limited to one or more of display, keypad, touch screen, speaker, and microphone, storage medium 1006 such as the ones listed in the last paragraph, and network interface 1008 , all of which can be connected to each other via a system bus 1010 .
- the storage medium 1006 can include the modules of FIGS. 5 , 8 , and 9 .
- some examples of the disclosure are directed to a method of unlocking a second device from a first device, comprising: establishing a trusted relationship with the second device; authenticating the first device using a device key; receiving a secret key from the second device; receiving user input from an input/output device; and transmitting the received secret key to the second device to unlock the second device in response to receiving the user input, wherein establishing the trusted relationship with the second device comprises using a key generated from a hardware key associated with the first device to authenticate the device key.
- the method further comprises pairing the first device with the second device by displaying a code on a display to be captured by the second device. Additionally or alternatively to one or more of the examples disclosed above, in some examples pairing with the second device is done with a Bluetooth out-of-band key. Additionally or alternatively to one or more of the examples disclosed above, in some examples establishing the trusted relationship with the second device comprises sending a public key to the second device. Additionally or alternatively to one or more of the examples disclosed above, in some examples the public key comprises a device key generated from an instance secret, a UUID identifying a set of keys, and a private device hardware key.
- the method further comprises validating the public key using a key generated from a hardware key associated with the first device. Additionally or alternatively to one or more of the examples disclosed above, in some examples the hardware key is shared with the second device. Additionally or alternatively to one or more of the examples disclosed above, in some examples the public key is certified by a shared authority. Additionally or alternatively to one or more of the examples disclosed above, in some examples the method further comprises authenticating the second device using a device key associated with the second device. Additionally or alternatively to one or more of the examples disclosed above, in some examples the device key associated with the second device is configured to indicate whether the second device has been unlocked before.
- Some examples of the disclosure are directed to a method performed at a second device for being unlocked by a first device, comprising: receiving a public device key from the first device; signing the received public device key with a private device key associated with the second device; sending a secret key to the first device; receiving a passcode; deriving a master key from the passcode; encrypting the master key with the secret key; receiving the secret key from the first device; retrieving the master key using the received secret key; and using the master key to perform an unlocking operation. Additionally or alternatively to one or more of the examples disclosed above, in some examples the method further comprises authenticating the first device using a device ID associated with the first device.
- the method further comprises unlocking the second device using the passcode.
- the secret key comprises a random key.
- the private device key is configured to indicate whether the second device has been unlocked with a passcode before.
- Some examples of the disclosure are directed to a non-transitory computer-readable storage medium of a first device capable of unlocking a second device, the storage medium storing instructions which, when executed by a processor, perform a method comprising: authenticating the first device using a device key; receiving a secret key from the second device; processing a user input received from an input/output device of the first device; and transmitting the received secret key to the second device to unlock the second device in response to the user input. Additionally or alternatively to one or more of the examples disclosed above, in some examples the method further comprises detecting whether the second device is within a Bluetooth range of the first device. Additionally or alternatively to one or more of the examples disclosed above, in some examples the method further comprises signing a first key with a second key.
- the first key comprises a device key and the second key comprises a SEP global key. Additionally or alternatively to one or more of the examples disclosed above, in some examples the method further comprises generating at least one of: a SEP global key, a device key, and a device unlock key.
- Some examples of the disclosure are directed to a non-transitory computer-readable storage medium of a second device capable of being unlocked by a first device, the storage medium storing instructions, which, when executed by a processor, perform a method comprising: receiving a public device key and a secret key from the first device; signing the received public device key with a private device key associated with the second device; sending a secret key to the first device; processing a passcode; deriving a master key from the passcode; encrypting the master key with the secret key; retrieving the master key using the received secret key; and using the master key to perform an unlocking operation.
- the method further comprises authenticating the first device using a device ID associated with the first device. Additionally or alternatively to one or more of the examples disclosed above, in some examples the method further comprises unlocking the second device using the passcode.
- Some examples of the disclosure are directed to a first device capable of unlocking a second device, the first device comprising: an authentication module configured for establishing a trusted relationship with the second device and authenticating the first device using a device key; a receiving module configured for receiving a secret key from the second device; a user input processing module configured for processing user input received from an input/output device; and a transmitting module configured for transmitting the received secret key to the second device to unlock the second device in response to receiving the user input, wherein establishing the trusted relationship with the second device comprises using a key generated from a hardware key associated with the first device to authenticate the device key.
- Some examples of the disclosure are directed to a second device capable of being unlocked by a first device, the second device comprising: a receiving module configured for receiving a public device key from the first device; a key signing module configured for signing the received public device key with a private device key associated with the second device; a transmitting module configured for sending a secret key to the first device; a user input processing module configured for processing a passcode; a deriving module configured for deriving a master key from the passcode; an encrypting module configured for encrypting the master key with the secret key; a receiving module for receiving the secret key from the first device and retrieving the master key using the received secret key; and an unlocking module configured for using the master key to perform an unlocking operation.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Software Systems (AREA)
- General Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- Lock And Its Accessories (AREA)
- Telephone Function (AREA)
- Selective Calling Equipment (AREA)
Abstract
Description
- This application claims the benefit under 35 U.S.C. §119(e) of U.S. Provisional Patent Application No. 62/044,907, filed Sep. 2, 2014, the content of which is incorporated herein by reference in its entirety for all purposes.
- This relates generally to a device-unlocking method and system, and more particularly, to unlocking one device using another device.
- Modern electronic devices such as smartphones and tablet PCs typically have one or more locking/unlocking mechanisms to keep the devices secure. To unlock a device, a user can input a passcode on a login screen of the device or employ a different mechanism such as scanning his fingerprint with a fingerprint scanner. These mechanisms are typically carried out directly on the device being unlocked.
- This generally relates to unlocking one device using another device. As referred to in this document, the device that can unlock another device can be the first device and the device that can be unlocked by another device can be the second device.
- In one embodiment, a method of unlocking a second device using a first device is disclosed. For example, a handheld electronic device can unlock a wearable device that has never been unlocked through the exchange of secret keys. The method can include: the first device pairing with the second device; establishing a trusted relationship with the second device; mutually authenticating both devices (i.e., building a trusted relationship between the devices) using a distinct device key in each device (that cannot be removed from the device); receiving a secret key from the second device during setup and storing it; and transmitting the received secret key to the second device to unlock the second device in response to receiving the user input. In other words, the first device can initially contact the second device. The second device can then send the first device a secret and ask the user for the passcode. With this passcode, the second device can derive the master key, validate unlock and store an escrow record. The escrow record contains the master key encrypted by the unlock key as well as the unlock key encrypted by the master key, so that any time the master key changes, the record can be updated.
- In another embodiment, a method of a second device being unlocked by a first device is disclosed. For example, one handheld device can unlock another handheld device. The method can include: establishing a trusted relationship with the second device; mutually authenticating both devices using a distinct device key in each device; sending a secret key to the first device during registration; unlocking the second device after receiving a passcode; deriving a master key from the passcode; encrypting the master key with the secret key previously sent to the first device; receiving the secret key from the first device; retrieving the master key using the received secret key; and using the master key to perform an unlocking operation. In other words, the first device can first check in, perform mutual authentication, and exchange a secret with the second device. When the second device is unlocked for the first time (since boot-up), the second device can keep the master key wrapped to the exchanged secret.
- In yet another embodiment, a first device capable of unlocking a second device is disclosed. The first device can include: a pairing module configured for pairing with the second device; an authentication module configured for authenticating itself using a device key; a receiving module configured for receiving a secret key from the second device; a user input processing module configured for processing a user input received from an input/output device of the first device; and a transmitting module configured for transmitting the received secret key to the second device to unlock the second device in response to the user input.
- In yet another embodiment, a second device capable of being unlocked by a first device is disclosed. The second device can include: a pairing module configured for pairing with the first device; a receiving module configured for receiving a public device key and a secret key from the first device; a key signing module configured for signing the received public device key with a private device key associated with the second device; a transmitting module configured for sending a secret key to the first device; a user input processing module configured for processing a passcode; a deriving module configured for deriving a master key from the passcode; an encrypting module configured for encrypting the master key with the secret key; a retrieving module configured for retrieving the master key using the received secret key; and an unlocking module configured for using the master key to perform an unlocking operation.
-
FIG. 1 illustrates a first device and a second device, the first device capable of unlocking the second device, according to an embodiment of the disclosure. -
FIG. 2 is a flowchart illustrating the exemplary steps in a method of using a first device to unlock a second device, according to an embodiment of the disclosure. -
FIG. 3 is a flowchart illustrating the exemplary steps in a registration process, according to an embodiment of the disclosure. -
FIG. 4 is a flowchart illustrating the exemplary steps in a method of using a first device to unlock a second device, according to an embodiment of the disclosure. -
FIG. 5 is a block diagram illustrating the exemplary modules of a device such as the first device or second device ofFIG. 1 , according to an embodiment of the disclosure. -
FIG. 6 illustrates the exemplary steps in the pairing of the two devices, according to an embodiment of the disclosure. -
FIG. 7 illustrates the exemplary steps in a method of using the first device to unlock the second device, according to an embodiment of the disclosure. -
FIG. 8 is a block diagram illustrating the exemplary modules of a second device that can be remotely unlocked by another device, according to an embodiment of the disclosure. -
FIG. 9 is a block diagram illustrating the exemplary modules of a first device that can perform a remote unlocking of another device, according to an embodiment of the disclosure. -
FIG. 10 illustrates exemplary components of a computing system such as the first device or second device described in the embodiments of the disclosure. - In the following description of example embodiments, reference is made to the accompanying drawings in which it is shown by way of illustration specific embodiments that can be practiced. It is to be understood that other embodiments can be used and structural changes can be made without departing from the scope of the various embodiments.
- This generally relates to unlocking one device using another device. As referred to in this document, the device that can unlock another device can be the first device and the device that can be unlocked by another device can be the second device.
-
FIG. 1 illustrates afirst device 100 and asecond device 112. In this embodiment, thefirst device 100 can be used for unlocking thesecond device 112. The first device can be, for example, a smartphone, tablet PC, laptop, desktop PC, Mac, electronic reader, smart TV, or game console, or any other devices capable of communicating with another device. Thefirst device 100 can include a secure processor such as a secure enclave processor (SEP) 105 and an application processor that includes akernel 108 and a user land 110 (also referred to commonly as userspace). The SEP 105 can be a processor separate from the application processor (AP) containingkernel 108 anduser land 110. Theuser land 110 can facilitate the operations of third party applications on the device. Thekernel 108 can be the core of the OS and provide a number of interfaces to the user land and manage the input/output (I/O) requests from the applications. In some embodiments, thekernel 108 can also perform key management operations to protect data on thedevice 100. The SEP 105 can be a relatively small processor that can define a security boundary within which a key management module can reside. The keys can be available when the device is or was previously unlocked. Thekernel 108 can communicate with theSEP 105. - In this embodiment, there can be multiple processes within the
SEP 105. As illustrated inFIG. 1 , the SEP can include abiometric matching module 104 andkey management module 106. - The
first device 100 can include one or more locking/unlocking mechanisms. One of the mechanisms to unlock the first device can be by entering a passcode on an I/O device such as a touch screen or a physical keypad. Once entered, the passcode can be carried through theuser land 110, thekernel 108, to theSEP 105. The SEP can perform a derivation based on the passcode to determine whether thefirst device 100 can be unlocked and to attempt to unlock its set of user data keys. When the first device is unlocked, the user data keys in thekey management module 106 can become available to thedevice 100. - The
first device 100 can also include afingerprint scanner 102 designed to unlock the device with a user's fingerprint. Thefingerprint scanner 102 can capture an image of the fingerprint and send the image to thebiometric matching module 104 for processing. After the biometric matching module verifies the captured fingerprint image, it can hand the random key back to thekey management module 106, which can prompt the keys in thekey management module 106 to be made available to thedevice 100. Thebiometric matching module 104 can optionally hold on to the random key in memory after it finishes analyzing the fingerprint. - As illustrated in
FIG. 1 , thesecond device 112 can include the same components as the first device. For example, thesecond device 112 can also include aSEP 116 and an applicationprocessor including kernel 118 anduser land 120. TheSEP 116,kernel 118, anduser land 120 can operate in a similar way as their counterparts in thefirst device 100. Unlike the first device, in this embodiment, the second device may not include a fingerprint scanner. Alternatively, the second device may have a fingerprint scanner. In some embodiments, thesecond device 112 may not haveSEP 116 and biometric matching module, and thekey management module 122 can reside inkernel 118. - In one example, the first device can be an iPhone with a fingerprint scanner and the second device can be an iPad, a wearable device, or any other device without a fingerprint scanner.
- As described above, the
biometric matching module 104 of the first device can receive a secret (e.g., random key) from thekey management module 106 when it was unlocked with a passcode and handed it out to the key management module when the first device is unlocked by a fingerprint match. In the embodiments described below, thefirst device 100 can unlock thesecond device 112 based on similar principles. In particular, a fingerprint image received by the fingerprint sensor can cause thebiometric matching module 104 of thefirst device 100 to hand out a secret key. Instead of unlocking the first device it can causekey management module 106 to release a secret tokey management module 122 on theother device 112. This secret key can be passed through theuser land 110 of thefirst device 100, over acommunication channel 130 connecting bothkey management modules devices user land 120 of thesecond device 112 to theSEP 116 of thesecond device 112. The secret key can then be used to unlock thesecond device 112, as will be described in detail in the embodiments below. - If one of the devices includes a SEP and the other one does not, the device with a SEP may refuse to send its keys to the device without the SEP to avoid a device with weaker protection being able to unlock one with stronger protection. Thus, before information (e.g., one or more keys for remotely unlocking the other device) is transmitted between the devices, the devices can authenticate each other as trusted devices (e.g., a device with a SEP).
- First, a common key can be used to validate that a device key (discussed below) associated with each of the first and second devices is owned by a SEP of a trusted device. For example, in one embodiment, the remote unlocking operation can be enabled only between devices having the same type of SEPs (e.g., Apple's SEP). In one embodiment, a common key, e.g., KSEP GLOBAL, can be derived from a symmetric hardware key shared by the SEPs of the two devices. KSEP GLOBAL can then be used for signing one or more other keys that can be used during a remote unlocking process. A key that is signed by the common key, KSEP GLOBAL, can be deemed to be generated from a device with a SEP, i.e., a device that can be trusted. In another embodiment, a device specific asymmetric key that has been certified by a common authority can be used. Certification can include a classification of the device that can be used to determine its level of protection.
- One of the keys that can be validated by KSEP GLOBAL can be a device key, Kd, which can be unique to each device and used for identifying the device. As referred to hereinafter, Kd1 can be a key identifying the first device and Kd2 can be a key identifying the second device. In one embodiment, Kd can be derived from a randomly generated secret for this pairing, a randomly-generated universally unique identifier (UUID) (e.g., KeyBag UUID identifying the current set of User Keys), and a device specific hardware key, e.g., KSEP LOCAL. KSEP LOCAL can be one of the device keys in the key management module of the device that can be used for protecting data associated with the device. The randomly generated secret can be a random value generated by the key store on creation to provide key entropy and uniqueness. The UUID can be for the KeyBag that is being unlocked by the mechanism. The device specific hardware key can be a data protection class key with particular availability (e.g., available at any time, after having been unlocked, or when the device is unlocked). The first device can use an “is-unlocked” device key so it can only authenticate while it is unlocked itself. The second device can use a “been-unlocked” device key, which can require it to having been unlocked once before it can be remotely unlocked. During the unlocking process, Kd1 and Kd2 can authenticate the first and second devices, respectively. In some embodiments, Kd1 and Kd2 can be used for the first device to unlock the second device when the second device has never been unlocked previously.
- In the embodiments where the second device has been unlocked previously, a device unlock key, Kdu, can be used not only for authenticating the device, but also for identifying whether a device has been unlocked by a user before. Kdu can be generated in the SEP of the corresponding device and protected using a passcode associated with the device. As referred to hereinafter, Kdu1 can be a device unlock key associated with the first device and Kdu2 can be a device unlock key associated with the second device. In one embodiment, Kdu can be derived only if the device has been unlocked before, which can imply that it had been accessed by someone with the correct passcode. If the device is lost, a new user likely would not have the passcode to unlock the device. If the new user attempts to restore the device to its original state by erasing all the data on the device, Kdu can be lost. Without Kdu, the device would no longer be able to prove to another device that it is still under the control of the same user. In other words, Kdu can be used for proving not only that the device is a trusted device, but also that it is still under the same user's control. As such, the first device can rely on the presence of Kdu2 to make sure that it does not accidentally unlock the second device when the second device is no longer in the possession of the user and has been rebooted.
-
FIGS. 2-5 illustrate exemplary algorithm steps in the various stages of a remote unlocking method, according to embodiments of the disclosure. Although the embodiments below describe a one-direction unlocking process (e.g., using the first device to unlock the second device), it should be understood that the disclosed systems and methods can be easily modified to perform unlocking in both directions (e.g., also using the second device to unlock the first device), without departing from the spirit of the disclosure. - In the embodiment illustrated in
FIG. 2 , the algorithm for the remote unlocking process (e.g., using the first device to unlock the second device) can include three main steps. First, the first device and the second device can be paired (step 201). Next the second device can authorize remote unlocking by the first device (step 202). Finally, the first device can unlock the second device in response to a user input on the first device (step 203). Each of these steps is discussed in more detail below. - In the first step, the two devices can be paired (step 201). The devices can be paired using any suitable pairing mechanisms such as Bluetooth when the devices are in close proximity of each other. In one embodiment, the Bluetooth pairing can be a secure pairing using a Bluetooth out-of-band key. For example, the devices can be paired by using a camera on one of the devices to capture a computer-readable code (e.g., a QR code or bar code) displayed on the display of the other device. This code can include information such as a device ID and other information (e.g., a Bluetooth out-of-band key) needed to pair the two devices. Although close proximity pairing is discussed in these embodiments, it should be understood that pairing the two devices does not necessarily require that the devices to be in close proximity. Indeed, any pairing mechanism designed to pair devices at any distance can be used in this step.
- After being paired, the devices can go through a registration process that can establish a trusted relationship between the two devices so that one of the devices can be securely unlocked by the other device. In other words, remote unlocking between the devices can be authorized (step 202). In particular, registration can involve pairing the controllers (e.g., SEPs) of the keys of the two devices and also potentially binding the SEPs of the two devices. This step can involve, for example, the devices exchanging and cross-signing their public keys that can be used when authenticating during the registration process, setting up a shared key, and during the unlocking process when this shared key is used. In some examples, pairing can be performed on both devices symmetrically.
-
FIG. 3 is a flow chart illustrating the exemplary algorithm steps in theregistration step 202 ofFIG. 2 . First, the first device (i.e., the device performing the unlocking) can send a public key, e.g., Kdu1, pub, to the second device (i.e., the device to be unlocked) (step 301). This public key can be used to validate that the first device is a trusted device when the first device attempts to unlock the second device. The second device can also perform an authorization, which can include receiving a passcode from the user and optionally an out-of-band verification when the user unlocks the second device locally (step 302). Because the passcode protects Kdu2, it can be used to prove that the device is in the possession of the user. The second device can then sign the public key, Kdu1, pub, with its private key, Kdu2, private (step 303). As a result, the second device can determine that a device using Kdu1, pub to authenticate during an unlocking operation can be a trusted device. If the registration is successful, the first device can be used to unlock the second device as follows.FIG. 4 illustrates the exemplary algorithm steps in using the first device to unlock the second device (i.e., step 203 ofFIG. 2 ), according to an embodiment of the disclosure. In some examples, the first device can be a handheld device and the second device can be a wearable device. First, the two devices can detect that they are in the vicinity of each other (step 401). In some embodiments, this step can only require that the devices to be able to locate each other without requiring them to be close to each other. A communication channel such as a Bluetooth or Wi-Fi channel can be established between the two devices (step 402). The first device can be authenticated using Kdu1 (step 403). Additionally or alternatively, the second device can be authenticated using Kdu2. The station-to-station protocol can be used for setting up a mutually authenticated and encrypted tunnel. In one embodiment, both devices can use ephemeral encryption keys, which in the process are authenticated using the signing keys exchanged during pairing. Because the first device has been authenticated, the second device can send a random secret key, S, to the first device using, for example, the negotiated session key derived from the ephemeral encryption keys used by both devices (step 404). The first device can store the secret key (step 405). At a later time, the second device can be unlocked with a passcode (step 406). A master key, M, can be derived from the passcode by the second device (step 407). The second device can build a token by encrypting the master key M with the secret key S (step 408) so that when the first device returns the secret key S to the second device, the second device can use S to decrypt the token to retrieve the master key M. Additionally, the second device can concatenate the token with a secret key S encrypted using the master key M, and store this concatenation as an escrow record (step 409). This can allow the second device to recover the secret key S when the master key M changes and build a new token. In an alternative embodiment, the second device can produce an escrow record for the first device using the secret key S stored the master key M wrapped to the secret key S, which can allow the device to be unlocked without having been unlocked before. In other words, in the first embodiment, a fixed secret and escrow record can be established during setup, and in an alternative embodiment, a random secret and a temporary escrow record can be established in response to a device unlock during registration. - Referring to
FIG. 4 again, when the user decides to unlock the second device with the first device, the second device can be authenticated using Kdu2 (step 410). The first device can be authenticated with Kdu1 (step 411). Once authenticated, the devices can exchange secrets with one another. For example, the first device can send the secret key S that it received from the second device back to the second device (step 412). This can be in response to the user scanning his fingerprint using the fingerprint scanner of the first device. The second device can retrieve the master key M by decrypting the token with the secret key S (step 413). The master key M can allow the second device to be unlocked (step 414). - In some embodiments where the second device has never been unlocked before, Kd2 can be used in place of Kdu2 in the method described above in view of
FIG. 4 . In one embodiment, the second device can produce an escrow record for the first device using the secret key S stored the master key M wrapped to the secret key S, which can allow the device to be unlocked without having been unlocked before. When the first device attempts to unlock the second device, the second device can use the device key to locate the escrow record and the secret key S to unwrap the master key M, which can be used to unlock the second device. -
FIG. 5 is a block diagram illustrating the exemplary modules of adevice 500 such as thefirst device 100 or thesecond device 112 ofFIG. 1 that is capable of either unlocking another device or being unlocked by another device or both. Thedevice 500 can include, for example, a detectingmodule 501, apairing module 502, akey signing module 503, a transmittingmodule 504, a receivingmodule 505, anauthentication module 506, akey generating module 507, and a userinput processing module 508. The detectingmodule 501 can detect the second device (e.g., when the second device is in its vicinity). Thepairing module 502 can pair the first device with the second device. Thekey signing module 503 can sign one or more keys with another key. The transmittingmodule 504 can transmit one or more keys (e.g., Kdu1, S) to another device. The receivingmodule 505 can receive one or more keys (e.g., S) from another device. Theauthentication module 506 can authenticate thedevice 500. Thekey generating module 507 can include a deriving module, and can derive a master key from a passcode and generate one or more hardware keys (e.g., KSEP GLOBAL) that can be used in the unlocking process. The userinput processing module 508 can process user input, including but not limited to, passcodes and/or fingerprints. - In various embodiments, some of the modules of
FIG. 5 can be optional and additional modules can be included in thedevice 500. Each of the modules can be implemented in either software, hardware or both. In some embodiments, the modules ofdevice 500 are software modules for performing the algorithms disclosed herein. In some embodiments, the modules ofdevice 500 represent one or more processors coupled to memory storing computer-readable instructions for performing the algorithms disclosed herein. In some embodiments, the modules ofdevice 500 comprise hardware and software elements of an ASIC, such as a system-on-a-chip, for performing the functions described above. -
FIGS. 6 and 7 illustrate an embodiment of a transport protocol algorithm that can facilitate the exchanging of keys (or records) in the remote unlocking of the second device by the first device, as described in the above embodiments. -
FIG. 6 illustrate the exemplary algorithm steps in the pairing of the two devices. This pairing process can take place after a communication channel has already been established between the two devices. As illustrated inFIG. 6 , to pair the two devices, first, the second device can receive a password entered by a user (step 601). The password can be used for later use. The second device can generate a long term key, Key 1 (step 602). In one embodiment, generating a long term key can refer to creating a key pair of which one can be sent to another device. Here, Key 1 (i.e., one of keys in the key pair, Key 1) can then be sent via the communication channel to the first device (step 603). The first device can sign and store Key 1 (step 604). The first device can then generate its own long term key, Key 2 (step 605). A session can then be created on the first device using the signedKey 1 received from the second device and the newly-generated short term Key 2 (step 606). The long term keys,Key 1 andKey 2, can be kept to create other sessions in the future. Another short term key,Key 3, can be created when the session is created (step 607).Keys - Referring now to
FIG. 6 , after receivingKey 2 andKey 3, the second device can sign and store Key 2 (step 609). The second device can then create a session at its end using bothKey 2 and Key 3 (step 610). With the session created, the second device can generateKey 4 usingKey 3 received from the first device (step 611).Key 4 can then be sent across the communication channel to the first device (step 612). After the first device confirms and stores Key 4 (step 613),Key 4 can be registered as a key for unlocking the second device (step 614). If the registration fails, a message can be sent back to the first device, which can cause the first device to delete Key 4 (step 615). Otherwise, the pairing of the devices is successful and the devices are set up to perform a remote unlock operation (e.g., using the first device to unlock the second device). -
FIG. 7 illustrates the exemplary algorithm steps in a method of using the first device to unlock the second device. As illustrated inFIG. 7 , first, the first device can receive a user input to unlock the second device (step 701). In response, the first device can create a session usinglong term Keys 1 and 2 (step 702). Another short term key, Key A can be generated from the newly-created session (step 703). The first device can then send Key A across the communication channel to the second device (step 704). In this embodiment, steps 703 and 704 can be to set up a short term key agreement between the first and second devices so thatKey 4 can be sent across later to unlock the second device. Because the short term key (e.g., Key A) is unique for each session and only used once for encryptingKey 4, the short term key exchange can prevent a replay attack in whichKey 4 is captured when transmitted across the communication channel and then resent from a device other than the first device to the second device to unlock the second device. - The short term key A is then sent to the second device (step 704) to create a session on the second device (step 705). The second device can then use Key A to create another key, Key B (step 706). Referring to
FIG. 7 , Key B can be sent back to the first device (step 707). The first device can use Key B to encryptKey 4 to generate a new key, Key C (step 708). The encrypted Key 4 (i.e., Key C) can be sent to the second device (step 709) and used for unlocking the second device (step 710). The unlocking process can involve decrypting Key C to retrieveKey 4 and usingKey 4 to unlock the second device. -
FIG. 8 is a block diagram illustrating the exemplary modules of thesecond device 800 ofFIGS. 6 and 7 that can be remotely unlocked by another device (e.g., the first device). Thesecond device 800 can include, for example, apassword receiving module 801, akey generating module 802, a transmittingmodule 803, a receivingmodule 804, akey signing module 805, astoring module 806, asession creating module 807, a registeringmodule 808, adecrypting module 809, and an unlockingmodule 810. Thepassword receiving module 801 can receive a password (or other input) from a user. Thekey generating module 802 can generate long term and/or short term keys (e.g.,Keys FIGS. 6 and 7 ). The transmittingmodule 803 can transmit one or more encrypted or unencrypted keys to another device (e.g., the first device). The receivingmodule 804 can receive one or more encrypted or unencrypted keys from another device (e.g., the first device). Thekey signing module 805 can sign a key (e.g., Key 2) received from another device. Thestoring module 806 can store keys generated locally or received from another device. Thesession creating module 807 can create a session using a key (e.g.,Key 2 and Key A) received from another device. The registeringmodule 808 can register a key (e.g., Key 4) as a key for unlocking the second device. Thedecrypting module 809 can decrypt any decrypted key (e.g., Key C) received from another device. The unlockingmodule 810 can unlock the second device using a key (e.g.,Key 4 obtained by decrypting Key C). -
FIG. 9 is a block diagram illustrating the exemplary modules of thefirst device 900 ofFIGS. 6 and 7 that can perform a remote unlocking of another device (e.g., the second device). Thefirst device 900 can include, for example, a transmittingmodule 901, a receivingmodule 902, akey signing module 903, astoring module 904, asession creating module 905, akey generating module 906, a confirmingmodule 907, a key deletingmodule 908, and anencrypting module 909. The transmittingmodule 901 can transmit one or more keys (e.g.,Keys FIGS. 6 and 7 ). The receivingmodule 902 can receive one or more keys (e.g.,Keys key signing module 903 can sign a key (e.g., Key 1) received from another device. Thestoring module 904 can store one or more keys generated locally or received from another device. Thesession creating module 905 can create a session using one or more keys (e.g.,Keys 1 and 2). Thekey generating module 906 can generate one or more long term and/or short term keys (e.g.,Keys module 907 can confirm a key (e.g., Key 4) as a key for unlocking another device. The key deletingmodule 908 can delete a key from the device. Theencrypting module 909 can encrypt a key (e.g., Key 4) using another key (e.g., Key B) to generate an encrypted key (e.g., Key C). - In various embodiments, some of the modules of
FIGS. 8 and 9 can be optional and additional modules can be included in thedevices device device device - In some embodiments, one or more of the modules of the
devices - The non-transitory computer readable storage medium can be part of a computing system serving as the first device or the second device.
FIG. 10 illustrates exemplary common components of one such computing system. As illustrated, thesystem 1000 can include a central processing unit (CPU) 1002, I/O components 1004 including, but not limited to one or more of display, keypad, touch screen, speaker, and microphone,storage medium 1006 such as the ones listed in the last paragraph, andnetwork interface 1008, all of which can be connected to each other via asystem bus 1010. Thestorage medium 1006 can include the modules ofFIGS. 5 , 8, and 9. - Therefore, according to the above, some examples of the disclosure are directed to a method of unlocking a second device from a first device, comprising: establishing a trusted relationship with the second device; authenticating the first device using a device key; receiving a secret key from the second device; receiving user input from an input/output device; and transmitting the received secret key to the second device to unlock the second device in response to receiving the user input, wherein establishing the trusted relationship with the second device comprises using a key generated from a hardware key associated with the first device to authenticate the device key. Additionally or alternatively to one or more of the examples disclosed above, in some examples prior to establishing the trusted relationship with the first device, the method further comprises pairing the first device with the second device by displaying a code on a display to be captured by the second device. Additionally or alternatively to one or more of the examples disclosed above, in some examples pairing with the second device is done with a Bluetooth out-of-band key. Additionally or alternatively to one or more of the examples disclosed above, in some examples establishing the trusted relationship with the second device comprises sending a public key to the second device. Additionally or alternatively to one or more of the examples disclosed above, in some examples the public key comprises a device key generated from an instance secret, a UUID identifying a set of keys, and a private device hardware key. Additionally or alternatively to one or more of the examples disclosed above, in some examples the method further comprises validating the public key using a key generated from a hardware key associated with the first device. Additionally or alternatively to one or more of the examples disclosed above, in some examples the hardware key is shared with the second device. Additionally or alternatively to one or more of the examples disclosed above, in some examples the public key is certified by a shared authority. Additionally or alternatively to one or more of the examples disclosed above, in some examples the method further comprises authenticating the second device using a device key associated with the second device. Additionally or alternatively to one or more of the examples disclosed above, in some examples the device key associated with the second device is configured to indicate whether the second device has been unlocked before.
- Some examples of the disclosure are directed to a method performed at a second device for being unlocked by a first device, comprising: receiving a public device key from the first device; signing the received public device key with a private device key associated with the second device; sending a secret key to the first device; receiving a passcode; deriving a master key from the passcode; encrypting the master key with the secret key; receiving the secret key from the first device; retrieving the master key using the received secret key; and using the master key to perform an unlocking operation. Additionally or alternatively to one or more of the examples disclosed above, in some examples the method further comprises authenticating the first device using a device ID associated with the first device. Additionally or alternatively to one or more of the examples disclosed above, in some examples the method further comprises unlocking the second device using the passcode. Additionally or alternatively to one or more of the examples disclosed above, in some examples the secret key comprises a random key. Additionally or alternatively to one or more of the examples disclosed above, in some examples the private device key is configured to indicate whether the second device has been unlocked with a passcode before.
- Some examples of the disclosure are directed to a non-transitory computer-readable storage medium of a first device capable of unlocking a second device, the storage medium storing instructions which, when executed by a processor, perform a method comprising: authenticating the first device using a device key; receiving a secret key from the second device; processing a user input received from an input/output device of the first device; and transmitting the received secret key to the second device to unlock the second device in response to the user input. Additionally or alternatively to one or more of the examples disclosed above, in some examples the method further comprises detecting whether the second device is within a Bluetooth range of the first device. Additionally or alternatively to one or more of the examples disclosed above, in some examples the method further comprises signing a first key with a second key. Additionally or alternatively to one or more of the examples disclosed above, in some examples the first key comprises a device key and the second key comprises a SEP global key. Additionally or alternatively to one or more of the examples disclosed above, in some examples the method further comprises generating at least one of: a SEP global key, a device key, and a device unlock key.
- Some examples of the disclosure are directed to a non-transitory computer-readable storage medium of a second device capable of being unlocked by a first device, the storage medium storing instructions, which, when executed by a processor, perform a method comprising: receiving a public device key and a secret key from the first device; signing the received public device key with a private device key associated with the second device; sending a secret key to the first device; processing a passcode; deriving a master key from the passcode; encrypting the master key with the secret key; retrieving the master key using the received secret key; and using the master key to perform an unlocking operation. Additionally or alternatively to one or more of the examples disclosed above, in some examples the method further comprises authenticating the first device using a device ID associated with the first device. Additionally or alternatively to one or more of the examples disclosed above, in some examples the method further comprises unlocking the second device using the passcode.
- Some examples of the disclosure are directed to a first device capable of unlocking a second device, the first device comprising: an authentication module configured for establishing a trusted relationship with the second device and authenticating the first device using a device key; a receiving module configured for receiving a secret key from the second device; a user input processing module configured for processing user input received from an input/output device; and a transmitting module configured for transmitting the received secret key to the second device to unlock the second device in response to receiving the user input, wherein establishing the trusted relationship with the second device comprises using a key generated from a hardware key associated with the first device to authenticate the device key.
- Some examples of the disclosure are directed to a second device capable of being unlocked by a first device, the second device comprising: a receiving module configured for receiving a public device key from the first device; a key signing module configured for signing the received public device key with a private device key associated with the second device; a transmitting module configured for sending a secret key to the first device; a user input processing module configured for processing a passcode; a deriving module configured for deriving a master key from the passcode; an encrypting module configured for encrypting the master key with the secret key; a receiving module for receiving the secret key from the first device and retrieving the master key using the received secret key; and an unlocking module configured for using the master key to perform an unlocking operation.
- Although embodiments have been fully described with reference to the accompanying drawings, it is to be noted that various changes and modifications will become apparent to those skilled in the art. Such changes and modifications are to be understood as being included within the scope of the various embodiments as defined by the appended claims.
Claims (25)
Priority Applications (24)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/810,395 US20160065374A1 (en) | 2014-09-02 | 2015-07-27 | Method of using one device to unlock another device |
DE102015215120.4A DE102015215120B4 (en) | 2014-09-02 | 2015-08-07 | METHOD OF USING ONE DEVICE TO UNLOCK ANOTHER DEVICE |
FR1557932A FR3025339B1 (en) | 2014-09-02 | 2015-08-26 | METHOD OF USING A DEVICE FOR UNLOCKING ANOTHER DEVICE. |
GB1515176.4A GB2533187B (en) | 2014-09-02 | 2015-08-26 | Method of using one device to unlock another device |
JP2015167428A JP6017650B2 (en) | 2014-09-02 | 2015-08-27 | How to use one device to unlock another |
AU2015218507A AU2015218507B2 (en) | 2014-09-02 | 2015-08-27 | Method of using one device to unlock another device |
CN202311039188.6A CN117077103A (en) | 2014-09-02 | 2015-08-31 | Method for unlocking one device by using the other device |
CN201910622229.1A CN110334498B (en) | 2014-09-02 | 2015-08-31 | Method for unlocking one device by using the other device |
CN201910622230.4A CN110334503B (en) | 2014-09-02 | 2015-08-31 | Method for unlocking one device by using the other device |
CN201510544492.5A CN105389500B (en) | 2014-09-02 | 2015-08-31 | The method for unlocking another equipment using an equipment |
KR1020150122859A KR101727660B1 (en) | 2014-09-02 | 2015-08-31 | Method of using one device to unlock another device |
JP2016189123A JP6382272B2 (en) | 2014-09-02 | 2016-09-28 | How to use one device to unlock another |
US15/286,505 US11329827B2 (en) | 2014-09-02 | 2016-10-05 | Method of using one device to unlock another device |
KR1020170046734A KR101892203B1 (en) | 2014-09-02 | 2017-04-11 | Method of using one device to unlock another device |
AU2017204624A AU2017204624B2 (en) | 2014-09-02 | 2017-07-06 | Method of using one device to unlock another device |
JP2018144795A JP6571250B2 (en) | 2014-09-02 | 2018-08-01 | How to use one device to unlock another |
KR1020180097494A KR101958909B1 (en) | 2014-09-02 | 2018-08-21 | Method of using one device to unlock another device |
KR1020190027522A KR102138283B1 (en) | 2014-09-02 | 2019-03-11 | Method of using one device to unlock another device |
AU2019201720A AU2019201720B2 (en) | 2014-09-02 | 2019-03-13 | Method of using one device to unlock another device |
KR1020200090417A KR102328725B1 (en) | 2014-09-02 | 2020-07-21 | Method of using one device to unlock another device |
FR2009689A FR3101167B1 (en) | 2014-09-02 | 2020-09-24 | METHOD FOR USING ONE DEVICE TO UNLOCK ANOTHER DEVICE |
AU2021202620A AU2021202620B2 (en) | 2014-09-02 | 2021-04-28 | Method of using one device to unlock another device |
US18/053,352 US20230231718A1 (en) | 2014-09-02 | 2022-11-07 | Method of using one device to unlock another device |
AU2023204649A AU2023204649A1 (en) | 2014-09-02 | 2023-07-13 | Method of using one device to unlock another device |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201462044907P | 2014-09-02 | 2014-09-02 | |
US14/810,395 US20160065374A1 (en) | 2014-09-02 | 2015-07-27 | Method of using one device to unlock another device |
Related Child Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/286,505 Continuation US11329827B2 (en) | 2014-09-02 | 2016-10-05 | Method of using one device to unlock another device |
US18/053,352 Continuation US20230231718A1 (en) | 2014-09-02 | 2022-11-07 | Method of using one device to unlock another device |
Publications (1)
Publication Number | Publication Date |
---|---|
US20160065374A1 true US20160065374A1 (en) | 2016-03-03 |
Family
ID=54292241
Family Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/810,395 Abandoned US20160065374A1 (en) | 2014-09-02 | 2015-07-27 | Method of using one device to unlock another device |
US15/286,505 Active US11329827B2 (en) | 2014-09-02 | 2016-10-05 | Method of using one device to unlock another device |
US18/053,352 Pending US20230231718A1 (en) | 2014-09-02 | 2022-11-07 | Method of using one device to unlock another device |
Family Applications After (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/286,505 Active US11329827B2 (en) | 2014-09-02 | 2016-10-05 | Method of using one device to unlock another device |
US18/053,352 Pending US20230231718A1 (en) | 2014-09-02 | 2022-11-07 | Method of using one device to unlock another device |
Country Status (8)
Country | Link |
---|---|
US (3) | US20160065374A1 (en) |
JP (3) | JP6017650B2 (en) |
KR (5) | KR101727660B1 (en) |
CN (4) | CN110334498B (en) |
AU (5) | AU2015218507B2 (en) |
DE (1) | DE102015215120B4 (en) |
FR (2) | FR3025339B1 (en) |
GB (1) | GB2533187B (en) |
Cited By (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20160196420A1 (en) * | 2015-01-07 | 2016-07-07 | Htc Corporation | Electronic system and device unlock method of the same |
CN105915336A (en) * | 2016-05-24 | 2016-08-31 | 珠海市魅族科技有限公司 | Object cooperative decryption method and device thereof |
WO2017160471A1 (en) | 2016-03-18 | 2017-09-21 | Ozzie Raymond E | Providing low risk exceptional access |
CN108055132A (en) * | 2017-11-16 | 2018-05-18 | 阿里巴巴集团控股有限公司 | The method, apparatus and equipment of a kind of service authorization |
US10055567B2 (en) | 2014-05-30 | 2018-08-21 | Apple Inc. | Proximity unlock and lock operations for electronic devices |
US10079677B2 (en) | 2015-06-05 | 2018-09-18 | Apple Inc. | Secure circuit for encryption key generation |
US20180317271A1 (en) * | 2017-04-27 | 2018-11-01 | Abb Schweiz Ag | Local connection establishment |
US10305686B2 (en) * | 2015-10-02 | 2019-05-28 | Orion Labs | Encrypted group communications |
CN110602309A (en) * | 2019-08-02 | 2019-12-20 | 华为技术有限公司 | Device unlocking method and system and related device |
US20200235932A1 (en) * | 2017-02-21 | 2020-07-23 | Fingerprint Cards Ab | Trusted key server |
US10742414B1 (en) | 2019-10-18 | 2020-08-11 | Capital One Services, Llc | Systems and methods for data access control of secure memory using a short-range transceiver |
US10820198B2 (en) | 2016-03-18 | 2020-10-27 | Raymond Edward Ozzie | Providing low risk exceptional access with verification of device possession |
US20210288795A1 (en) * | 2020-03-11 | 2021-09-16 | Cloudflare, Inc. | Establishing a cryptographic tunnel between a first tunnel endpoint and a second tunnel endpoint where a private key used during the tunnel establishment is remotely located from the second tunnel endpoint |
US11176237B2 (en) | 2016-06-12 | 2021-11-16 | Apple Inc. | Modifying security state with secured range detection |
US11178127B2 (en) * | 2016-06-12 | 2021-11-16 | Apple Inc. | Modifying security state with secured range detection |
US11250118B2 (en) | 2016-06-12 | 2022-02-15 | Apple Inc. | Remote interaction with a device using secure range detection |
US11329827B2 (en) | 2014-09-02 | 2022-05-10 | Apple Inc. | Method of using one device to unlock another device |
US11424921B2 (en) | 2015-11-09 | 2022-08-23 | Dealerware, Llc | Vehicle access systems and methods |
US11593797B2 (en) | 2016-06-12 | 2023-02-28 | Apple Inc. | Authentication using a secure circuit |
US11599322B1 (en) * | 2019-09-26 | 2023-03-07 | Apple Inc. | Systems with overlapped displays |
US11991157B2 (en) | 2013-03-07 | 2024-05-21 | Cloudflare, Inc. | Secure session capability using public-key cryptography without access to the private key |
Families Citing this family (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR20160039680A (en) * | 2013-08-06 | 2016-04-11 | 베드락 오토메이션 플렛폼즈 인크. | Smart power system |
CN106096362B (en) * | 2016-06-01 | 2020-07-24 | 联想(北京)有限公司 | Control method and electronic equipment |
JP6717108B2 (en) * | 2016-08-10 | 2020-07-01 | 富士通株式会社 | Information processing apparatus, information processing system, program, and information processing method |
CN107920097B (en) * | 2016-10-09 | 2020-04-14 | 中国移动通信有限公司研究院 | Unlocking method and device |
US10356067B2 (en) * | 2016-11-02 | 2019-07-16 | Robert Bosch Gmbh | Device and method for providing user-configured trust domains |
US10404691B2 (en) | 2017-03-02 | 2019-09-03 | Bank Of America Corporation | Preventing unauthorized access to secured information systems using authentication tokens |
WO2018218541A1 (en) * | 2017-05-31 | 2018-12-06 | 华为技术有限公司 | Connection establishment method and device |
JP2019008524A (en) * | 2017-06-23 | 2019-01-17 | 富士通コネクテッドテクノロジーズ株式会社 | Function control program, terminal apparatus, pairing registrable device, and system |
CN109800552A (en) * | 2017-11-17 | 2019-05-24 | 上海箩箕技术有限公司 | A kind of circumscribed fingerprint identification device |
CN108494550B (en) * | 2018-03-12 | 2021-08-06 | 长春大学 | Mobile terminal safety unlocking method based on quantum key |
CN109033781A (en) * | 2018-07-04 | 2018-12-18 | Oppo(重庆)智能科技有限公司 | A kind of electronic equipment control method, electronic appliance controlling device and electronic equipment |
CN109284595B (en) * | 2018-10-09 | 2021-07-13 | Oppo广东移动通信有限公司 | Equipment unlocking control method and device and electronic equipment |
CN111489461B (en) * | 2019-01-26 | 2022-07-15 | 合肥智辉空间科技有限责任公司 | Bluetooth key system for group |
US11240026B2 (en) | 2019-05-16 | 2022-02-01 | Blackberry Limited | Devices and methods of managing data |
WO2020241947A1 (en) * | 2019-05-31 | 2020-12-03 | 엘지전자 주식회사 | Body area network-based authentication system and method therefor |
US20210397425A1 (en) | 2020-06-22 | 2021-12-23 | Apple Inc. | Systems and Methods for Performing Binary Translation |
EP4222623A1 (en) | 2020-10-01 | 2023-08-09 | Oboren Systems, Inc. | Exclusive self-escrow method and apparatus |
Citations (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030108205A1 (en) * | 2001-12-07 | 2003-06-12 | Bryan Joyner | System and method for providing encrypted data to a device |
US7111165B2 (en) * | 2000-03-10 | 2006-09-19 | Assa Abloy Ab | Key and lock device |
US20110305337A1 (en) * | 2010-06-12 | 2011-12-15 | Randall Devol | Systems and methods to secure laptops or portable computing devices |
US20120015629A1 (en) * | 2010-07-13 | 2012-01-19 | Google Inc. | Securing a mobile computing device |
US20120124373A1 (en) * | 2007-08-21 | 2012-05-17 | Motorola, Inc. | Method and apparatus for authenticatiing a network device |
US20140220897A1 (en) * | 2013-02-01 | 2014-08-07 | Min-Chuan Wan | Pairing method between bluetooth devices and bluetooth system using the same |
US20140282877A1 (en) * | 2013-03-13 | 2014-09-18 | Lookout, Inc. | System and method for changing security behavior of a device based on proximity to another device |
US20150207795A1 (en) * | 2014-01-21 | 2015-07-23 | EveryKey, LLC | Authentication device and method |
US20150229619A1 (en) * | 2014-02-07 | 2015-08-13 | Microsoft Corporation | Trusted execution within a distributed computing system |
US20150296074A1 (en) * | 2014-04-15 | 2015-10-15 | Google Inc. | Limiting user interaction with a computing device based on proximity of a user |
US20160234214A1 (en) * | 2013-10-15 | 2016-08-11 | Telefonaktiebolaget L M Ericsson (Publ) | Establishing a Secure Connection between a Master Device and a Slave Device |
US20160286587A1 (en) * | 2013-12-05 | 2016-09-29 | Per Åstrand | Pairing Consumer Electronic Devices Using a Cross-Body Communications Protocol |
Family Cites Families (62)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5483261A (en) | 1992-02-14 | 1996-01-09 | Itu Research, Inc. | Graphical input controller and method with rear screen image detection |
US5880411A (en) | 1992-06-08 | 1999-03-09 | Synaptics, Incorporated | Object position detector with edge motion feature and gesture recognition |
US5488204A (en) | 1992-06-08 | 1996-01-30 | Synaptics, Incorporated | Paintbrush stylus for capacitive touch sensor pad |
US6044154A (en) * | 1994-10-31 | 2000-03-28 | Communications Devices, Inc. | Remote generated, device identifier key for use with a dual-key reflexive encryption security system |
US5825352A (en) | 1996-01-04 | 1998-10-20 | Logitech, Inc. | Multiple fingers contact sensing method for emulating mouse buttons and mouse operations on a touch sensor pad |
US5835079A (en) | 1996-06-13 | 1998-11-10 | International Business Machines Corporation | Virtual pointing device for touchscreens |
US6539479B1 (en) | 1997-07-15 | 2003-03-25 | The Board Of Trustees Of The Leland Stanford Junior University | System and method for securely logging onto a remotely located computer |
US6310610B1 (en) | 1997-12-04 | 2001-10-30 | Nortel Networks Limited | Intelligent touch display |
EP2256605B1 (en) | 1998-01-26 | 2017-12-06 | Apple Inc. | Method and apparatus for integrating manual input |
US7663607B2 (en) | 2004-05-06 | 2010-02-16 | Apple Inc. | Multipoint touchscreen |
US8479122B2 (en) | 2004-07-30 | 2013-07-02 | Apple Inc. | Gestures for touch sensitive input devices |
US6188391B1 (en) | 1998-07-09 | 2001-02-13 | Synaptics, Inc. | Two-layer capacitive touchpad and method of making same |
JP4542637B2 (en) | 1998-11-25 | 2010-09-15 | セイコーエプソン株式会社 | Portable information device and information storage medium |
US20030021417A1 (en) * | 2000-10-20 | 2003-01-30 | Ognjen Vasic | Hidden link dynamic key manager for use in computer systems with database structure for storage of encrypted data and method for storage and retrieval of encrypted data |
JP3800984B2 (en) | 2001-05-21 | 2006-07-26 | ソニー株式会社 | User input device |
JP2003173237A (en) | 2001-09-28 | 2003-06-20 | Ricoh Co Ltd | Information input-output system, program and storage medium |
US6690387B2 (en) | 2001-12-28 | 2004-02-10 | Koninklijke Philips Electronics N.V. | Touch-screen image scrolling system and method |
US11275405B2 (en) | 2005-03-04 | 2022-03-15 | Apple Inc. | Multi-functional hand-held device |
JP4244130B2 (en) * | 2002-11-07 | 2009-03-25 | ソニー・エリクソン・モバイルコミュニケーションズ株式会社 | Mobile terminal system and mobile terminal device |
US7269732B2 (en) * | 2003-06-05 | 2007-09-11 | Sap Aktiengesellschaft | Securing access to an application service based on a proximity token |
US7885411B2 (en) * | 2004-04-02 | 2011-02-08 | Research In Motion Limited | Key agreement and re-keying over a bidirectional communication path |
FR2882839A1 (en) * | 2005-03-07 | 2006-09-08 | Laurent Michel | Computer e.g. fixed computer, access protection device for use as e.g. pendant, has memory to contain stored biometric fingerprints and computer access conditions, and microprocessor to compare captured and stored fingerprints |
JP4363361B2 (en) * | 2005-04-28 | 2009-11-11 | 沖電気工業株式会社 | PORTABLE ELECTRONIC DEVICE, SECURITY SYSTEM AND METHOD FOR DETERMINING OPERATION PERMITTED RANGE |
ATE444533T1 (en) | 2006-06-23 | 2009-10-15 | Research In Motion Ltd | PAIRING A WIRELESS PERIPHERAL DEVICE WITH LOCKED SCREEN |
US8171527B2 (en) | 2007-06-26 | 2012-05-01 | General Instrument Corporation | Method and apparatus for securing unlock password generation and distribution |
WO2009063947A1 (en) * | 2007-11-16 | 2009-05-22 | Fujitsu Ten Limited | Authentication method, authentication system, on-vehicle device, and authentication device |
KR101442169B1 (en) * | 2007-11-27 | 2014-11-03 | 삼성전자주식회사 | A Public Key Infrastructure-based Bluetooth Smart-Key System and Operating Method Thereof |
US8095799B2 (en) | 2008-07-28 | 2012-01-10 | Apple Inc. | Ticket authorized secure installation and boot |
US20100058450A1 (en) * | 2008-08-28 | 2010-03-04 | Gene Fein | Pass code provision |
US8045961B2 (en) * | 2009-06-22 | 2011-10-25 | Mourad Ben Ayed | Systems for wireless authentication based on bluetooth proximity |
US8515077B2 (en) | 2010-05-12 | 2013-08-20 | Research In Motion Limited | Automatic application management in a short-range wireless system |
US8464061B2 (en) | 2010-08-30 | 2013-06-11 | Apple Inc. | Secure wireless link between two devices using probes |
US8650654B2 (en) * | 2010-09-17 | 2014-02-11 | Kabushiki Kaisha Toshiba | Memory device, memory system, and authentication method |
JP5198539B2 (en) | 2010-11-05 | 2013-05-15 | 株式会社東芝 | Storage device, access device and program |
JP2012108698A (en) * | 2010-11-17 | 2012-06-07 | Ntt Docomo Inc | Portable terminal, lock control system, and program |
CN102547502B (en) * | 2010-12-17 | 2014-12-24 | 索尼爱立信移动通讯有限公司 | Headset, headset use control method and terminal |
CN102611956A (en) * | 2011-01-21 | 2012-07-25 | 富泰华工业(深圳)有限公司 | Earphone and electronic device with earphone |
CN102184352A (en) * | 2011-03-16 | 2011-09-14 | 东南大学 | Automatic protecting method for computer system based on Bluetooth device authentication |
EP2535833A1 (en) | 2011-06-15 | 2012-12-19 | Gemalto SA | Method for securing an electrical device |
EP2747335B1 (en) * | 2011-08-16 | 2017-01-11 | ICTK Co., Ltd. | Device and method for puf-based inter-device security authentication in machine-to-machine communication |
CN102497465A (en) * | 2011-10-26 | 2012-06-13 | 潘铁军 | High-secrecy mobile information safety system and safety method for distributed secret keys |
CN102571802B (en) * | 2012-01-18 | 2016-04-13 | 深圳市文鼎创数据科技有限公司 | Information safety devices and Server remote unlock method, equipment and server |
US9547761B2 (en) * | 2012-04-09 | 2017-01-17 | Mcafee, Inc. | Wireless token device |
CN103378876A (en) * | 2012-04-16 | 2013-10-30 | 上海博路信息技术有限公司 | Bluetooth-based terminal unlocking method |
US8700899B1 (en) | 2012-06-27 | 2014-04-15 | Emc Corporation | Forward-secure key unlocking for cryptographic devices |
US20140085048A1 (en) | 2012-09-25 | 2014-03-27 | Motorola Mobility Llc | System and Method for Unlocking an Electronic Device Via a Securely Paired Remote Device |
US8787902B2 (en) * | 2012-10-31 | 2014-07-22 | Irevo, Inc. | Method for mobile-key service |
JP2016506101A (en) | 2012-11-16 | 2016-02-25 | テレフオンアクチーボラゲット エル エム エリクソン(パブル) | Neighborhood-based multi-factor authentication |
GB201221433D0 (en) | 2012-11-28 | 2013-01-09 | Hoverkey Ltd | A method and system of providing authentication of user access to a computer resource on a mobile device |
US9549323B2 (en) | 2012-12-03 | 2017-01-17 | Samsung Electronics Co., Ltd. | Method and mobile terminal for controlling screen lock |
JP2014123204A (en) * | 2012-12-20 | 2014-07-03 | Casio Comput Co Ltd | Information processing system, portable information terminal, radio terminal and lock release method |
US9942750B2 (en) | 2013-01-23 | 2018-04-10 | Qualcomm Incorporated | Providing an encrypted account credential from a first device to a second device |
JP5534483B1 (en) * | 2013-01-24 | 2014-07-02 | 株式会社ブリヂストン | Sector mold and manufacturing method |
US11127001B2 (en) * | 2013-05-09 | 2021-09-21 | Wayne Fueling Systems Llc | Systems and methods for secure communication |
US9400892B2 (en) | 2013-06-28 | 2016-07-26 | Broadcom Corporation | Apparatus and method to secure an electronic storage using a secure element |
US10460314B2 (en) * | 2013-07-10 | 2019-10-29 | Ca, Inc. | Pre-generation of session keys for electronic transactions and devices that pre-generate session keys for electronic transactions |
CN103442120A (en) * | 2013-08-09 | 2013-12-11 | 北京纽曼腾飞科技有限公司 | Smart phone locking and unlocking method |
CN103442129A (en) * | 2013-08-09 | 2013-12-11 | 宇龙计算机通信科技(深圳)有限公司 | Interactive method and system between intelligent watch and mobile terminal |
CN103473514A (en) * | 2013-09-06 | 2013-12-25 | 宇龙计算机通信科技(深圳)有限公司 | Data storage access method and device |
CN103647587B (en) * | 2013-12-30 | 2016-08-17 | 华为终端有限公司 | Method, system, mobile terminal and the wearing electronic equipment unlocked for mobile terminal |
US20160065374A1 (en) * | 2014-09-02 | 2016-03-03 | Apple Inc. | Method of using one device to unlock another device |
US10437981B2 (en) * | 2015-01-07 | 2019-10-08 | Htc Corporation | Electronic system and device unlock method of the same |
-
2015
- 2015-07-27 US US14/810,395 patent/US20160065374A1/en not_active Abandoned
- 2015-08-07 DE DE102015215120.4A patent/DE102015215120B4/en active Active
- 2015-08-26 GB GB1515176.4A patent/GB2533187B/en active Active
- 2015-08-26 FR FR1557932A patent/FR3025339B1/en active Active
- 2015-08-27 AU AU2015218507A patent/AU2015218507B2/en active Active
- 2015-08-27 JP JP2015167428A patent/JP6017650B2/en active Active
- 2015-08-31 CN CN201910622229.1A patent/CN110334498B/en active Active
- 2015-08-31 CN CN202311039188.6A patent/CN117077103A/en active Pending
- 2015-08-31 CN CN201910622230.4A patent/CN110334503B/en active Active
- 2015-08-31 CN CN201510544492.5A patent/CN105389500B/en active Active
- 2015-08-31 KR KR1020150122859A patent/KR101727660B1/en active IP Right Grant
-
2016
- 2016-09-28 JP JP2016189123A patent/JP6382272B2/en active Active
- 2016-10-05 US US15/286,505 patent/US11329827B2/en active Active
-
2017
- 2017-04-11 KR KR1020170046734A patent/KR101892203B1/en active IP Right Grant
- 2017-07-06 AU AU2017204624A patent/AU2017204624B2/en active Active
-
2018
- 2018-08-01 JP JP2018144795A patent/JP6571250B2/en active Active
- 2018-08-21 KR KR1020180097494A patent/KR101958909B1/en active IP Right Grant
-
2019
- 2019-03-11 KR KR1020190027522A patent/KR102138283B1/en active IP Right Grant
- 2019-03-13 AU AU2019201720A patent/AU2019201720B2/en active Active
-
2020
- 2020-07-21 KR KR1020200090417A patent/KR102328725B1/en active IP Right Grant
- 2020-09-24 FR FR2009689A patent/FR3101167B1/en active Active
-
2021
- 2021-04-28 AU AU2021202620A patent/AU2021202620B2/en active Active
-
2022
- 2022-11-07 US US18/053,352 patent/US20230231718A1/en active Pending
-
2023
- 2023-07-13 AU AU2023204649A patent/AU2023204649A1/en active Pending
Patent Citations (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7111165B2 (en) * | 2000-03-10 | 2006-09-19 | Assa Abloy Ab | Key and lock device |
US20030108205A1 (en) * | 2001-12-07 | 2003-06-12 | Bryan Joyner | System and method for providing encrypted data to a device |
US20120124373A1 (en) * | 2007-08-21 | 2012-05-17 | Motorola, Inc. | Method and apparatus for authenticatiing a network device |
US20110305337A1 (en) * | 2010-06-12 | 2011-12-15 | Randall Devol | Systems and methods to secure laptops or portable computing devices |
US20120015629A1 (en) * | 2010-07-13 | 2012-01-19 | Google Inc. | Securing a mobile computing device |
US20140220897A1 (en) * | 2013-02-01 | 2014-08-07 | Min-Chuan Wan | Pairing method between bluetooth devices and bluetooth system using the same |
US20140282877A1 (en) * | 2013-03-13 | 2014-09-18 | Lookout, Inc. | System and method for changing security behavior of a device based on proximity to another device |
US20160234214A1 (en) * | 2013-10-15 | 2016-08-11 | Telefonaktiebolaget L M Ericsson (Publ) | Establishing a Secure Connection between a Master Device and a Slave Device |
US20160286587A1 (en) * | 2013-12-05 | 2016-09-29 | Per Åstrand | Pairing Consumer Electronic Devices Using a Cross-Body Communications Protocol |
US20150207795A1 (en) * | 2014-01-21 | 2015-07-23 | EveryKey, LLC | Authentication device and method |
US20150229619A1 (en) * | 2014-02-07 | 2015-08-13 | Microsoft Corporation | Trusted execution within a distributed computing system |
US20150296074A1 (en) * | 2014-04-15 | 2015-10-15 | Google Inc. | Limiting user interaction with a computing device based on proximity of a user |
Non-Patent Citations (1)
Title |
---|
Shah, Provisional application No. 61/980,018, filed on Apr. 15, 2014, specification * |
Cited By (47)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11991157B2 (en) | 2013-03-07 | 2024-05-21 | Cloudflare, Inc. | Secure session capability using public-key cryptography without access to the private key |
US11741210B2 (en) | 2014-05-30 | 2023-08-29 | Apple Inc. | Proximity unlock and lock operations for electronic devices |
US10055567B2 (en) | 2014-05-30 | 2018-08-21 | Apple Inc. | Proximity unlock and lock operations for electronic devices |
US11055392B2 (en) * | 2014-05-30 | 2021-07-06 | Apple Inc. | Proximity unlock and lock operations for electronic devices |
US10546113B2 (en) | 2014-05-30 | 2020-01-28 | Apple Inc. | Proximity unlock and lock operations for electronic devices |
US11329827B2 (en) | 2014-09-02 | 2022-05-10 | Apple Inc. | Method of using one device to unlock another device |
US10437981B2 (en) * | 2015-01-07 | 2019-10-08 | Htc Corporation | Electronic system and device unlock method of the same |
US20160196420A1 (en) * | 2015-01-07 | 2016-07-07 | Htc Corporation | Electronic system and device unlock method of the same |
US11764954B2 (en) | 2015-06-05 | 2023-09-19 | Apple Inc. | Secure circuit for encryption key generation |
US10079677B2 (en) | 2015-06-05 | 2018-09-18 | Apple Inc. | Secure circuit for encryption key generation |
US10484172B2 (en) | 2015-06-05 | 2019-11-19 | Apple Inc. | Secure circuit for encryption key generation |
US10523431B2 (en) | 2015-06-05 | 2019-12-31 | Apple Inc. | Secure circuit for encryption key generation |
US10305686B2 (en) * | 2015-10-02 | 2019-05-28 | Orion Labs | Encrypted group communications |
US20200119914A1 (en) * | 2015-10-02 | 2020-04-16 | Orion Labs | Encrypted group communications |
US11683160B2 (en) * | 2015-10-02 | 2023-06-20 | Orion Labs, Inc. | Encrypted group communications |
US11463246B2 (en) * | 2015-11-09 | 2022-10-04 | Dealerware, Llc | Vehicle access systems and methods |
US11451384B2 (en) | 2015-11-09 | 2022-09-20 | Dealerware, Llc | Vehicle access systems and methods |
US11424921B2 (en) | 2015-11-09 | 2022-08-23 | Dealerware, Llc | Vehicle access systems and methods |
US10826701B2 (en) | 2016-03-18 | 2020-11-03 | Raymond Edward Ozzie | Providing low risk exceptional access |
US10820198B2 (en) | 2016-03-18 | 2020-10-27 | Raymond Edward Ozzie | Providing low risk exceptional access with verification of device possession |
US10819521B2 (en) | 2016-03-18 | 2020-10-27 | Raymond Edward Ozzie | Providing low risk exceptional access |
EP3437322A4 (en) * | 2016-03-18 | 2019-08-14 | Raymond E. Ozzie | Providing low risk exceptional access |
US10505734B2 (en) | 2016-03-18 | 2019-12-10 | Raymond Edward Ozzie | Providing low risk exceptional access |
US10644886B2 (en) | 2016-03-18 | 2020-05-05 | Raymond Edward Ozzie | Providing low risk exceptional access |
WO2017160471A1 (en) | 2016-03-18 | 2017-09-21 | Ozzie Raymond E | Providing low risk exceptional access |
CN105915336A (en) * | 2016-05-24 | 2016-08-31 | 珠海市魅族科技有限公司 | Object cooperative decryption method and device thereof |
US11178127B2 (en) * | 2016-06-12 | 2021-11-16 | Apple Inc. | Modifying security state with secured range detection |
US11176237B2 (en) | 2016-06-12 | 2021-11-16 | Apple Inc. | Modifying security state with secured range detection |
US11250118B2 (en) | 2016-06-12 | 2022-02-15 | Apple Inc. | Remote interaction with a device using secure range detection |
US11582215B2 (en) | 2016-06-12 | 2023-02-14 | Apple Inc. | Modifying security state with secured range detection |
US11438322B2 (en) | 2016-06-12 | 2022-09-06 | Apple Inc. | Modifying security state with secured range detection |
US11593797B2 (en) | 2016-06-12 | 2023-02-28 | Apple Inc. | Authentication using a secure circuit |
EP3449611B1 (en) * | 2016-06-12 | 2023-10-11 | Apple Inc. | Modifying security state with secured range detection |
US20200235932A1 (en) * | 2017-02-21 | 2020-07-23 | Fingerprint Cards Ab | Trusted key server |
US10951413B2 (en) * | 2017-02-21 | 2021-03-16 | Fingerprint Cards Ab | Trusted key server |
US20180317271A1 (en) * | 2017-04-27 | 2018-11-01 | Abb Schweiz Ag | Local connection establishment |
US10892900B2 (en) | 2017-11-16 | 2021-01-12 | Advanced New Technologies Co., Ltd. | Verification-based service authorization |
US11316702B2 (en) | 2017-11-16 | 2022-04-26 | Advanced New Technologies Co., Ltd. | Verification-based service authorization |
CN108055132A (en) * | 2017-11-16 | 2018-05-18 | 阿里巴巴集团控股有限公司 | The method, apparatus and equipment of a kind of service authorization |
CN110602309A (en) * | 2019-08-02 | 2019-12-20 | 华为技术有限公司 | Device unlocking method and system and related device |
US11599322B1 (en) * | 2019-09-26 | 2023-03-07 | Apple Inc. | Systems with overlapped displays |
US11444770B2 (en) | 2019-10-18 | 2022-09-13 | Capital One Services, Llc | Systems and methods for data access control of secure memory using a short-range transceiver |
US10742414B1 (en) | 2019-10-18 | 2020-08-11 | Capital One Services, Llc | Systems and methods for data access control of secure memory using a short-range transceiver |
US11764962B2 (en) | 2019-10-18 | 2023-09-19 | Capital One Services, Llc | Systems and methods for data access control of secure memory using a short-range transceiver |
US11677545B2 (en) * | 2020-03-11 | 2023-06-13 | Cloudflare, Inc. | Establishing a cryptographic tunnel between a first tunnel endpoint and a second tunnel endpoint where a private key used during the tunnel establishment is remotely located from the second tunnel endpoint |
US20210288795A1 (en) * | 2020-03-11 | 2021-09-16 | Cloudflare, Inc. | Establishing a cryptographic tunnel between a first tunnel endpoint and a second tunnel endpoint where a private key used during the tunnel establishment is remotely located from the second tunnel endpoint |
US11949776B2 (en) | 2020-03-11 | 2024-04-02 | Cloudflare, Inc. | Establishing a cryptographic tunnel between a first tunnel endpoint and a second tunnel endpoint where a private key used during the tunnel establishment is remotely located from the second tunnel endpoint |
Also Published As
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20230231718A1 (en) | Method of using one device to unlock another device | |
CN106575326B (en) | System and method for implementing one-time passwords using asymmetric encryption | |
US10289835B1 (en) | Token seed protection for multi-factor authentication systems | |
US10511438B2 (en) | Method, system and apparatus using forward-secure cryptography for passcode verification | |
US10742410B2 (en) | Updating biometric template protection keys | |
US20210073359A1 (en) | Secure one-time password (otp) authentication | |
US20220052838A1 (en) | Reinitialization of an application secret by way of the terminal |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: APPLE INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SAUERWALD, CONRAD;LEDWITH, ALEXANDER;IAROCCI, JOHN;AND OTHERS;SIGNING DATES FROM 20141125 TO 20141215;REEL/FRAME:036199/0223 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
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: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
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: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |