U.S. patent application number 14/810395 was filed with the patent office on 2016-03-03 for method of using one device to unlock another device.
The applicant listed for this patent is Apple Inc.. Invention is credited to Wade BENSON, John IAROCCI, Marc KROCHMAL, Alexander LEDWITH, Gregory NOVICK, Conrad SAUERWALD, Noah WITHERSPOON.
Application Number | 20160065374 14/810395 |
Document ID | / |
Family ID | 54292241 |
Filed Date | 2016-03-03 |
United States Patent
Application |
20160065374 |
Kind Code |
A1 |
SAUERWALD; Conrad ; et
al. |
March 3, 2016 |
METHOD OF USING ONE DEVICE TO UNLOCK ANOTHER DEVICE
Abstract
A method of unlocking a second device using a first device is
disclosed. The method can include: the first device pairing with
the second device; 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 a 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 a
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.
Inventors: |
SAUERWALD; Conrad; (Mountain
View, CA) ; LEDWITH; Alexander; (Santa Cruz, CA)
; IAROCCI; John; (Los Gatos, CA) ; KROCHMAL;
Marc; (Cupertino, CA) ; BENSON; Wade; (San
Jose, CA) ; NOVICK; Gregory; (San Francisco, CA)
; WITHERSPOON; Noah; (San Francisco, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Apple Inc. |
Cupertino |
CA |
US |
|
|
Family ID: |
54292241 |
Appl. No.: |
14/810395 |
Filed: |
July 27, 2015 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
62044907 |
Sep 2, 2014 |
|
|
|
Current U.S.
Class: |
726/19 |
Current CPC
Class: |
G06F 21/44 20130101;
H04W 12/003 20190101; H04W 12/08 20130101; H04L 9/3234 20130101;
G06F 2221/2147 20130101; H04L 9/3271 20130101; H04L 9/0838
20130101; H04L 9/0822 20130101; H04L 9/3226 20130101; H04L 2209/24
20130101; G06F 21/32 20130101; H04L 9/0866 20130101; H04W 4/80
20180201; H04L 9/0825 20130101 |
International
Class: |
H04L 9/32 20060101
H04L009/32; H04L 9/08 20060101 H04L009/08; G06F 21/44 20060101
G06F021/44 |
Claims
1. 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.
2. The method of claim 1, wherein 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.
3. The method of claim 2, wherein pairing with the second device is
done with a Bluetooth out-of-band key.
4. The method of claim 1, wherein establishing the trusted
relationship with the second device comprises sending a public key
to the second device.
5. The method of claim 4, wherein 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.
6. The method of claim 4, further comprising validating the public
key using a key generated from a hardware key associated with the
first device.
7. The method of claim 6, wherein the hardware key is shared with
the second device.
8. The method of claim 4, wherein the public key is certified by a
shared authority.
9. The method of claim 1, further comprising authenticating the
second device using a device key associated with the second
device.
10. The method of claim 9, wherein the device key associated with
the second device is configured to indicate whether the second
device has been unlocked before.
11. 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.
12. The method of claim 11, further comprising authenticating the
first device using a device ID associated with the first
device.
13. The method of claim 11, further comprising unlocking the second
device using the passcode.
14. The method of claim 11, wherein the secret key comprises a
random key.
15. The method of claim 11, wherein the private device key is
configured to indicate whether the second device has been unlocked
with a passcode before.
16. 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.
17. The non-transitory computer-readable storage medium of claim
16, the method further comprising detecting whether the second
device is within a Bluetooth range of the first device.
18. The non-transitory computer-readable storage medium of claim
16, the method further comprising signing a first key with a second
key.
19. The non-transitory computer-readable storage medium of claim
18, wherein the first key comprises a device key and the second key
comprises a SEP global key.
20. The non-transitory computer-readable storage medium of claim
16, the method further comprising generating at least one of: a SEP
global key, a device key, and a device unlock key.
21. 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.
22. The non-transitory computer-readable storage medium of claim
21, the method further comprising authenticating the first device
using a device ID associated with the first device.
23. The non-transitory computer-readable storage medium of claim
21, the method further comprising unlocking the second device using
the passcode.
24. 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.
25. 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.
Description
CROSS-REFERENCE TO RELATED APPLICATION
[0001] This application claims the benefit under 35 U.S.C.
.sctn.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.
FIELD
[0002] This relates generally to a device-unlocking method and
system, and more particularly, to unlocking one device using
another device.
BACKGROUND
[0003] 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.
SUMMARY
[0004] 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.
[0005] 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.
[0006] 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.
[0007] 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.
[0008] 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.
BRIEF DESCRIPTION OF THE DRAWINGS
[0009] 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.
[0010] 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.
[0011] FIG. 3 is a flowchart illustrating the exemplary steps in a
registration process, according to an embodiment of the
disclosure.
[0012] 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.
[0013] 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.
[0014] FIG. 6 illustrates the exemplary steps in the pairing of the
two devices, according to an embodiment of the disclosure.
[0015] 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.
[0016] 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.
[0017] 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.
[0018] FIG. 10 illustrates exemplary components of a computing
system such as the first device or second device described in the
embodiments of the disclosure.
DETAILED DESCRIPTION
[0019] 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.
[0020] 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.
[0021] FIG. 1 illustrates a first device 100 and a second device
112. In this embodiment, 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). The
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. 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.
[0022] In this embodiment, there can be multiple processes within
the SEP 105. As illustrated in FIG. 1, the SEP can include a
biometric matching module 104 and key management module 106.
[0023] 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.
[0024] 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.
[0025] As illustrated in FIG. 1, the second device 112 can include
the same components as the first device. For example, 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. 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, the second device 112 may not have
SEP 116 and biometric matching module, and the key management
module 122 can reside in kernel 118.
[0026] 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.
[0027] As described above, 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. In the embodiments described
below, the first device 100 can unlock the second device 112 based
on similar principles. In particular, 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.
[0028] 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).
[0029] 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., K.sub.SEP GLOBAL, can be
derived from a symmetric hardware key shared by the SEPs of the two
devices. K.sub.SEP 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, K.sub.SEP 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.
[0030] One of the keys that can be validated by K.sub.SEP GLOBAL
can be a device key, K.sub.d, which can be unique to each device
and used for identifying the device. As referred to hereinafter,
K.sub.d1 can be a key identifying the first device and K.sub.d2 can
be a key identifying the second device. In one embodiment, K.sub.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.sub.SEP LOCAL. K.sub.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.
During the unlocking process, K.sub.d1 and K.sub.d2 can
authenticate the first and second devices, respectively. In some
embodiments, K.sub.d1 and K.sub.d2 can be used for the first device
to unlock the second device when the second device has never been
unlocked previously.
[0031] In the embodiments where the second device has been unlocked
previously, a device unlock key, K.sub.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.sub.du can be
generated in the SEP of the corresponding device and protected
using a passcode associated with the device. As referred to
hereinafter, K.sub.du1 can be a device unlock key associated with
the first device and K.sub.du2 can be a device unlock key
associated with the second device. In one embodiment, K.sub.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. If the new user attempts to
restore the device to its original state by erasing all the data on
the device, K.sub.du can be lost. Without K.sub.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.sub.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.sub.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.
[0032] 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.
[0033] 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.
[0034] 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.
[0035] 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.
[0036] FIG. 3 is a flow chart illustrating the exemplary algorithm
steps in the registration step 202 of FIG. 2. First, the first
device (i.e., the device performing the unlocking) can send a
public key, e.g., K.sub.du1, 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 K.sub.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.sub.du1, pub, with its private key,
K.sub.du2, private (step 303). As a result, the second device can
determine that a device using K.sub.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. 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 K.sub.du1 (step 403).
Additionally or alternatively, the second device can be
authenticated using K.sub.du2. 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.
[0037] 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 K.sub.du2 (step 410). The first device can be
authenticated with K.sub.du1 (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).
[0038] In some embodiments where the second device has never been
unlocked before, K.sub.d2 can be used in place of K.sub.du2 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.
[0039] 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.sub.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.sub.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.
[0040] In various embodiments, some of the 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. In some embodiments, the modules of device 500 are
software modules for performing the algorithms disclosed herein. In
some embodiments, the modules of device 500 represent one or more
processors coupled to memory storing computer-readable instructions
for performing the algorithms disclosed herein. In some
embodiments, 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.
[0041] 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.
[0042] 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 in FIG. 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 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).
[0043] Referring now to FIG. 6, after receiving Key 2 and Key 3,
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). With the session created, 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). 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).
[0044] FIG. 7 illustrates the exemplary algorithm steps in a method
of using the first device to unlock the second device. As
illustrated in FIG. 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 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). In this embodiment, 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.
Because 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.
[0045] 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 encrypt Key 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 retrieve Key 4 and using Key 4 to
unlock the second device.
[0046] 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).
[0047] 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. 6 and 7). 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).
[0048] In various embodiments, some of the 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. In some embodiments, the modules
of device 800 and 900 are software modules for performing the
algorithms disclosed herein. In some embodiments, 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. In some embodiments, 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.
[0049] In some embodiments, 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. In the context of this document, 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.
[0050] 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, 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.
[0051] 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.
[0052] 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.
[0053] 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.
[0054] 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.
[0055] 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.
[0056] 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.
[0057] 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.
* * * * *