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.

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&#39;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&#39;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&#39;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.