SYSTEMS AND METHODS FOR SECURING THE BOOT PROCESS OF A DEVICE USING CREDENTIALS STORED ON AN AUTHENTICATION TOKEN

- OPTIO LABS, INC.

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.

Skip to: Description  ·  Claims  · Patent History  ·  Patent History
Description
CROSS-REFERENCE TO RELATED APPLICATIONS

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

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.

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

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.

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.

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.

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

FIG. 1 depicts certain components of a system for providing a secure device.

FIG. 2 depicts a workflow for securing a device.

DETAILED DESCRIPTION

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Patent History
Publication number: 20140282992
Type: Application
Filed: Mar 13, 2014
Publication Date: Sep 18, 2014
Applicant: OPTIO LABS, INC. (Boston, MA)
Inventors: Thomas Charles CLANCY, III (Washington, DC), Brian DOUGHERTY (Nashville, TN), David Alexander HAMRICK (Nashville, TN), Grayson Gates SHARPE (Louisville, KY), Robert Austin HANLIN (Nashville, TN), Krzysztof Kamil ZIENKIEWICZ (Nashville, TN), Christopher Michael THOMPSON (Nashville, TN), Christopher Jules WHITE (Nashville, TN)
Application Number: 14/209,950
Classifications
Current U.S. Class: Tokens (e.g., Smartcards Or Dongles, Etc.) (726/9)
International Classification: H04L 29/06 (20060101);