U.S. patent application number 14/209950 was filed with the patent office on 2014-09-18 for systems and methods for securing the boot process of a device using credentials stored on an authentication token.
This patent application is currently assigned to OPTIO LABS, INC.. The applicant listed for this patent is OPTIO LABS, INC.. Invention is credited to Thomas Charles CLANCY, III, Brian DOUGHERTY, David Alexander HAMRICK, Robert Austin HANLIN, Grayson Gates SHARPE, Christopher Michael THOMPSON, Christopher Jules WHITE, Krzysztof Kamil ZIENKIEWICZ.
Application Number | 20140282992 14/209950 |
Document ID | / |
Family ID | 51529248 |
Filed Date | 2014-09-18 |
United States Patent
Application |
20140282992 |
Kind Code |
A1 |
CLANCY, III; Thomas Charles ;
et al. |
September 18, 2014 |
SYSTEMS AND METHODS FOR SECURING THE BOOT PROCESS OF A DEVICE USING
CREDENTIALS STORED ON AN AUTHENTICATION TOKEN
Abstract
Methods and systems are provided for securing devices in which a
secure external authentication token is used to verify user
credentials prior to enabling the operating system of the device by
loading or decrypting the operating system. Suitable external
authentication tokens can include smartcards such as a common
access card and may be verified by cryptographic processes either
at a local server or via a remote credentials processor.
Inventors: |
CLANCY, III; Thomas Charles;
(Washington, DC) ; DOUGHERTY; Brian; (Nashville,
TN) ; HAMRICK; David Alexander; (Nashville, TN)
; SHARPE; Grayson Gates; (Louisville, KY) ;
HANLIN; Robert Austin; (Nashville, TN) ; ZIENKIEWICZ;
Krzysztof Kamil; (Nashville, TN) ; THOMPSON;
Christopher Michael; (Nashville, TN) ; WHITE;
Christopher Jules; (Nashville, TN) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
OPTIO LABS, INC. |
Boston |
MA |
US |
|
|
Assignee: |
OPTIO LABS, INC.
Boston
MA
|
Family ID: |
51529248 |
Appl. No.: |
14/209950 |
Filed: |
March 13, 2014 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61779931 |
Mar 13, 2013 |
|
|
|
61780408 |
Mar 13, 2013 |
|
|
|
61781252 |
Mar 14, 2013 |
|
|
|
61785109 |
Mar 14, 2013 |
|
|
|
61790728 |
Mar 15, 2013 |
|
|
|
Current U.S.
Class: |
726/9 |
Current CPC
Class: |
H04W 4/80 20180201; H04W
12/00503 20190101; G01S 5/02 20130101; H04W 64/00 20130101; H04L
63/20 20130101; H04W 4/029 20180201; H04L 63/0428 20130101; H04L
63/107 20130101; Y02D 30/70 20200801; G06F 21/44 20130101; H04W
4/02 20130101; H04W 64/006 20130101; H04W 84/10 20130101; G06F
21/6218 20130101; G06F 2221/2111 20130101; G01S 5/00 20130101 |
Class at
Publication: |
726/9 |
International
Class: |
H04L 29/06 20060101
H04L029/06 |
Claims
1. An apparatus for providing a secure device, comprising: an
operating system, for operating the device; an authentication token
reading facility for reading an external authentication token; and
a credential processing facility for determining whether a user is
authorized to access the device and to load the operating system,
based on the external authentication token.
2. The apparatus of claim 1, wherein the authentication token
reading facility comprises a common access card reader.
3. The apparatus of claim 1, wherein the credential processing
facility comprises a remote credential processing facility.
4. The apparatus of claim 1, wherein the external authentication
token comprises one or more of a cryptographic key, a public key
certificate, a digital signature, biometric data, or a user id.
5. A method for securing a device, comprising: reading an external
authentication token; determining whether a user is authorized to
access a device, based on the external authentication token;
enabling an operating system of the device if the user is
determined to be authorized; and processing a password from the
user to access the operating system of the device.
6. The method of claim 5, wherein the authentication token reading
facility reads the token from a common access card.
7. The method of claim 5, wherein a public key is involved in the
determination if the token indicates that the user is authorized to
use the device.
8. The method of claim 5, wherein the external authentication token
or a component of the token is read in full or part from one or
more proximity signals.
9. The method of claim 5, wherein one or more user access
permissions are obtained from a network resource before the
authentication to determine what data, hardware, or software
components can be accessed by the user.
10. The method of claim 9, wherein one or more updated user access
permissions are obtained from the network resource after the
authentication to determine what data, hardware, or software
components can be accessed by the user.
11. The method of claim 5, wherein enabling the operating system
comprises decrypting a root filesystem.
12. The method of claim 11, wherein the entire root filesystem is
not decrypted and instead a subset of the data on the root
filesystem is decrypted.
13. The method of claim 12, wherein the subset of the data
decrypted is determined based on the external authentication
token.
14. The method of claim 5, wherein the authentication process
varies based on the device's indoor or outdoor location.
15. The method of claim 5, wherein enabling the operating system
comprises loading an operating system.
16. The method of claim 5, wherein determining whether a user is
authorized further comprises: decrypting the external
authentication token; and comparing the external authentication
token to a stored authentication credential for the user.
17. The method of claim 16, wherein the stored authentication
credential is obtained from a remote credential server.
18. The method of claim 16, wherein the stored authentication
credential is obtained from a public key server.
19. A method for authenticating a device, comprising: receiving a
first authentication data via a short range wireless signal;
generating a second authentication data from the first
authentication data; transmitting the second authentication data to
an in-location access point; receiving a third authentication data
from the in-location access point, wherein the third authentication
data is based on the second authentication data; communicating a
fourth authentication data to a server, wherein the fourth
authentication data comprises at least a portion of the first,
second, and third authentication data.
20. The method of claim 19, further comprising granting the device
access to a network resource based on the fourth authentication
data.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] Some of the aspects of the methods and systems described
herein have been described in U.S. Provisional Application Nos.
61/780,408 entitled "Systems And Methods To Synchronize Data To A
Mobile Device Based On A Device Usage Context", filed Mar. 13,
2013; 61/781,252 entitled "Systems And Methods To Secure
Short-Range Proximity Signals", filed Mar. 14, 2013; 61/781,509
entitled "Systems And Methods For Securing And Locating Computing
Devices", filed Mar. 14, 2013; 61/779,931 entitled "Systems And
Methods For Securing The Boot Process Of A Device Using Credentials
Stored On An Authentication Token", filed Mar. 13, 2013; 61/790,728
entitled "Systems And Methods For Enforcing Security In Mobile
Computing", filed Mar. 15, 2013; and U.S. Non-Provisional
application Ser. No. 13/735,885 entitled "Systems and Methods for
Enforcing Security in Mobile Computing", filed Jan. 7, 2013, each
of which is hereby incorporated by reference herein in its
entirety.
BACKGROUND OF THE INVENTION
[0002] The present invention is in the technical field of computer
security. More particularly, the present invention is in the
technical field of securing the boot process of a device using
credentials stored on an authentication token.
[0003] As mobile devices, such as smartphones and tablet computers,
become more powerful and ubiquitous, it becomes advantageous to use
them for an increasing number of applications. In some instances,
these applications may require that sensitive information be stored
in nonvolatile memory on the device. It is therefore important to
be able to protect said information stored on the device both while
the device is running and while the device is powered off.
Regardless, it is imperative that the identity of the user be
verified before granting access to the information stored on the
device. Current solutions to this problem involve using a password
to protect the device once the operating system has been started.
However, passwords may still be a point of insecurity, since the
passwords may be shared, stolen, sniffed, cracked, and/or have poor
password strength. Such vulnerabilities relating to password
security present a broad attack surface to malicious users. A need
exists for improved solutions.
SUMMARY OF THE INVENTION
[0004] To provide the greatest level of security, methods and
systems are provided herein to prevent unauthorized users from even
turning on a device, including without limitation reducing the
exposure to attacks by requiring a user to authenticate himself or
herself prior to loading the operating system into memory.
[0005] Embodiments of the present invention include a system for
securing the boot process of a device using credentials stored on
an authentication token. Other embodiments include a method for
securing the boot process of a device by reading an external
authentication token, determining whether a user is authorized to
access a device, based on the external authentication token,
enabling an operating system of the device if the user is
determined to be authorized, and processing a password from the
user to access the operating system of the device. Another
embodiment includes a method wherein first authentication data is
received via a short range wireless signal, second authentication
data is generated from the first authentication data, the second
authentication data is transmitted to an in-location access point,
third authentication data is received from the in-location access
point, wherein the third authentication data is based on the second
authentication data, and a fourth authentication data is
communicated to a server, wherein the fourth authentication data
includes at least a portion of the first, second, and third
authentication data.
[0006] In various embodiments of the invention, the authentication
token may be read from a common access card or from one or more
proximity signals. A public key may be involved in determining if
the token indicates the user is authorized to access the device. In
an embodiment of the invention, user access permissions are
obtained from a network resource before authentication to determine
what data, hardware, or software components can be accessed by the
user. In some embodiments, updated user access permissions are
obtained from a network resource after the authentication. Enabling
the operating system may include decrypting a root filesystem,
decrypting a subset of the root filesystem, or loading an operating
system. In some embodiments, the subset of the root filesystem that
is decrypted is determined based on the external authentication
token. In an embodiment of the invention, the authentication
process is varied based on the device's location indoors or
outdoors. In another embodiment of the invention, the determination
of whether a user is authorized involves decrypting the external
authorization token and comparing the external authorization token
to a stored authentication credential for the user. In some
embodiments, the stored authentication credential is obtained from
a remote credential server. In some embodiments, the stored
authentication credential is obtained from a public key server.
[0007] The present disclosure may provide greater security than
just password protection by requiring users of a device to
authenticate with an external authentication token before the
device allows the users to access the operating system.
BRIEF DESCRIPTION OF THE FIGURES
[0008] FIG. 1 depicts certain components of a system for providing
a secure device.
[0009] FIG. 2 depicts a workflow for securing a device.
DETAILED DESCRIPTION
[0010] This disclosure may increase the security of a mobile device
by preventing access to the operating system at system boot using
an external authentication token.
[0011] Referring to FIG. 1, a device 102 may comprise an operating
system 104, an authentication token reading facility 108 and a
credential processing facility 110. The device 102 may be a mobile
device, such as a mobile phone, a smartphone, a tablet, a laptop or
some other device. The operating system 104 may be Android, bada,
BlackBerry OS, iOS, Series40, Symbian OS, Windows Phone or some
other operating system.
[0012] The device may also include one or more of a processor, a
memory, and a network interface. Network interface may provide an
input and/or output mechanism to communicate with other network
devices such as a router or server. The network interface may also
provide communication with, for example, other gateways, wireless
access nodes, and application servers to send and receive data such
as packets and messages. The network interface may provide
connectivity to 3G, 4G, WiFi, or other network types. Processor may
run software which uses the network interface and the memory such
as a tangible, non-transitory computer readable medium, a
programmable read only memory (PROM), or flash memory. Processor
may be any computer chip that is capable of executing program
instruction streams that are part of a software program. Processor
may have multiple cores for executing multiple streams of program
instructions simultaneously. The processor may also have multiple
sub-processors which are optimized for executing particular
categories of program instructions and are controlled by the
processor. The memory is capable of storing and retrieving program
instructions, program data, or any other data that is used by the
processor. The processor may store and retrieve data from the
memory as a software program is executed. Memory may include or
store one or more of an authentication token reading facility 108
and or a credential processing facility. Memory may also include
associated policies and configurations. The processor may
optionally access and update a authentication token reading
facility 108 and/or a credential processing facility and associated
policies and configurations.
[0013] The user equipment (e.g., mobile device) described above can
be a smart phone offering advanced capabilities including, but not
limited to word processing, web browsing, gaming, e-book
capabilities, an operating system, a user interface, and a full
keyboard. The user equipment may run an operating system such as
SYMBIAN OS, APPLE IOS, RIM's BLACKBERRY, WINDOWS MOBILE, Linux,
PALM WEBOS, and ANDROID. The screen may be a touch screen that can
be used to input data to the mobile device and the screen can be
used instead of a full keyboard. The user equipment may have the
capability to run applications or communicate with applications
that are provided by servers in the communication network. The user
equipment can receive updates and other information from these
applications on the network.
[0014] In embodiments, a user may be required to authenticate on
the device 102 using an external authentication token 112 in order
to use the operating system 104 on the device 102. When the device
102 is powered up, the credential processing facility 110 may
instruct the user of the device 102 to provide authentication
information via the authentication token reading facility 108. The
authentication token reading facility 108 may read authentication
information from a physical device. The information may be an
authentication token 112. The authentication token 112 may be
stored on a Common Access Card, a smartcard, a USB token, an SD
card, a key fob, or some other physical device. The authentication
token 112 may be a cryptographic key, such as a public key
certificate, a digital signature, biometric data, a user id, or
some other authentication information. In some embodiments, the
authentication token reading facility 108 may be an external device
connected to the device 102. In such embodiments, the
authentication token reading facility 108 may be configured to
communicate with the device 102 using the network interface of the
device. Communication may occur via a communications medium, such
as Bluetooth, near field communication ("NFC"), Wi-Fi, or other
wired or wireless communications medium. For example, the
authentication token reading facility 108 may be a smartcard reader
connected to the network interface of device 102 via Bluetooth.
[0015] In some embodiments, the boot loader for the device, which
is a piece of software responsible for initiating the boot process
of the operating system, may include or communicate with the
credential processing facility. The boot loader, upon loading into
memory, may use its internal or communicate with an external
credential processing facility as part of a boot verification
process. The boot loader may selectively perform one or more
operating system boot steps as a result of token reading,
authentication, permission, or other determinations in the
credential processing facility. The boot verification steps may
include, but are not limited to: selecting the operating system
kernel to boot, identifying a master boot record, loading one or
more operating system kernel components into memory, executing one
or more operating system components, validating one or more
operating system components in memory or on a storage medium,
verifying a master boot record or operating system kernel or kernel
component, writing to an input/output device, displaying one or
more user interface or informational components on a device user
interface component, displaying one or more interactive user
interface components to acquire additional information from the
user relevant to one or more boot process steps, or initializing
one or more hardware components. In some embodiments, the boot
loader may require user input to be provided via one or more user
interface components, including, but not limited to, a display,
microphone, accelerometer, touch input, keyboard, trackball,
external device, or other sensor/input mechanism. The user input,
token, sensor data, location of the device, or wireless signals in
proximity, such as Bluetooth Low Energy, infrared, or acoustic
signals, can be used to aid in determining the boot process
components run by the boot loader.
[0016] In embodiments, the device 102 may be enabled to connect to
a network 114. For example, device 102 may connect to network 114
via the network interface of the device. In such embodiments,
authenticating the user on the device 102 may include communicating
first, second, and third authentication data over a short-range
wireless signal between the device 102 and an in-location access
point, wherein the second authentication data from the device 102
is based on the first authentication data from the in-location
access point and the third authentication data from the in-location
access point is based on the second authentication data;
communicating a fourth authentication data between the mobile
device and a web-based information system, wherein the fourth
authentication data comprises at least a portion of at least one of
the first, second, and third authentication data; and
authenticating access to network accessible content by the mobile
device with the web-based information system. The first
authentication data may be the authentication token 112 data. The
web-based information system may be a proxy 118. For example, the
authentication token reading facility 108 associated with the
device 102 may receive the authentication token 112 via NFC, send
the second authentication data to the in-location access point via
Bluetooth heartbeat messages, receive the third authentication data
as responses to the Bluetooth heartbeat messages, send a request to
a web proxy 118 that includes the third authentication data (e.g.
in the form of hypertext transport protocol (HTTP) request with
such data in the HTTP headers), and receive access to the device if
the proxy 118 determines that the user is authorized, based on the
third authentication data.
[0017] The credential processing facility 110 may determine whether
the authentication token 112 data is valid and whether the user is
permitted to access the operating system 104, based on the user
provided authentication token 112. Credential processing may
include local or distributed processing, using processing and
storage capabilities of the authentication token device 112 or
using remote (e.g., server-based) processing capabilities. In
embodiments, local credential processing may include one or more of
decrypting, reviewing and comparing the user provided
authentication token 112 by the credential processing facility 110.
In embodiments, distributed credential processing may include one
or more of decrypting, reviewing and comparing the user provided
authentication token 112 by the credential processing facility 110
in connection with some authentication facility, such as a private
key or public key service. Comparing the user provided
authentication token 112 may include looking up the user provided
authentication token 112 in a database or file for a match or for a
permission. Credential processing may be performed using private or
public key authentication.
[0018] Upon determining that the authentication token 112 data is
valid and the user is permitted to access the operating system 104,
the device 102 may begin the operating system 104 boot process.
Upon determining that the authentication token 112 data is invalid
and/or the user is not permitted to access the operating system
104, the credential processing facility 110 prevents the operating
system 104 from beginning the boot process. In some embodiments,
the credential processing facility 110 may erase part or all of the
data stored on the device 102 upon a predetermined number of failed
authentication attempts, which may be, but is not limited to, 3
attempts.
[0019] For example, the user of the device 102 may provide a
smartcard to be read by the authentication token reading facility
108 associated with the device 102, where the smartcard includes
the user's authentication token 112. The authentication token 112
data could be one or more X.509 certificates. In this example, the
authentication token reading facility 108 may read the
authentication token 112 from the smartcard and provide the
authentication token 112 information to the credential processing
facility 110. The credential processing facility 110 may, then,
determine whether the user is authorized to access the operating
system 104, based on the authentication token 112 information.
[0020] A determination that the user is authorized may form an
event suitable for use in determining a device context as described
in U.S. Provisional Patent Application No. 61/780,408, at pages
3-4, which is incorporated herein by reference. Some embodiments of
the invention may be used by incorporating location-based
authorization into credential processing, as described in U.S.
Provisional Patent Application No. 61/785,109 at paragraphs
[0020]-[0025], which is incorporated herein by reference. In some
embodiments, reading of the authentication token and credential
processing may be performed in a trusted zone of a processor as
described in U.S. Provisional Patent Application No. 61/790,728 at
paragraphs [0091]-[0095], which is incorporated herein by
reference. The credential processing of some embodiments of the
invention may incorporate a secure location determination, as
described in U.S. Provisional Patent Application No. 61/781,252 at
pages 2-4, which is incorporated herein by reference.
[0021] Referring now to FIG. 2, the process for authenticating the
user may comprise powering on a device 202; prompting a user to
provide an authentication token 204; reading, by the device, the
authentication token 208; determining, by a credential processing
facility, whether the user is authorized to access the device,
based on the authentication token 210; and granting a user access
to the device. In embodiments, if the user is unauthorized to
access the device by the credential processing facility based on
the authentication token 210, the user may be prohibited from
accessing the device 212. In some embodiments, granting the user
access to the device may include decrypting the root filesystem if
the user is determined to be authorized by the credential
processing facility. In some embodiments, granting the user access
to the device may include booting an operating system if the user
is determined to be authorized by the credential processing
facility 214. In some embodiments, granting the user access to the
device may include both decrypting the root filesystem and booting
the operating system. Additional security may be required at the
operating system level, after the user has been authenticated.
Therefore, in some embodiments, authenticating the user may also
comprise processing a password from the user to access the
operating system 218. For example, several users may be authorized
to use a device and may be authorized to access the device, but may
each such user may have a different account at the operating system
level. In this example, such users may be required to provide
additional credentials at an operating system login in order to
access their operating system account.
[0022] While the foregoing written description of the invention
enables one of ordinary skill to make and use what is considered
presently to be the best mode thereof, those of ordinary skill will
understand and appreciate the existence of variations,
combinations, and equivalents of the specific embodiment, method,
and examples herein. The invention should therefore not be limited
by the above described embodiment, method, and examples, but by all
embodiments and methods within the scope and spirit of the
invention.
* * * * *