US20090113543A1 - Authentication certificate management for access to a wireless communication device - Google Patents

Abstract

A system and method for authenticating a user to a user device using one or more-factor authentication with a certificate are provided. The status of the certificate is stored at the user device such that the stored status is queried during the authentication process. The status is updated as a background operation on the user device on a periodic basis. In the event that the user device fails to obtain updated status information, further status update requests are issued by the user device at varying time intervals until a response is received. In the event that the user is authenticated to the device but the certificate is subsequently revoked, access to all or a subset of user data and functions on the user device may be restricted.

Description

BACKGROUND
• 1. Technical Field
• The present invention relates generally to mobile devices, and in particular to systems, methods, and software for authentication certificate management for access to a wireless communication device.
• 2. Description of the Related Art
• User devices, including, but not restricted to, wireless mobile communication devices, personal computers, laptop or portable computers, smartphones, personal digital assistants (PDAs), and the like, may be secured from unauthorized access by means of an authentication process having one or more factors. Such a process may require the user to provide a smart card or other authorization token storing a secret value, which must be validated by the user device before the user is allowed to access the functions and/or data stores of the user device. It is known in the art to implement this type of authentication feature using a Public Key Infrastructure (PKI), wherein the user device is provided with a public key certificate, and the authentication token is provided with the corresponding private key. In order to authenticate the user with the authentication token, the authentication token signs a message using the private key that is transmitted to the user device for verification using the public key certificate.
• Such digital certificates are issued by Certificate Authorities (CAs). The certificates expire after a given time, at which point the certificate is not intended to be relied on for authentication purposes. The expiration time may be embedded in the certificate itself, so the user device can ascertain whether the certificate has expired. However, the CA may revoke the certificate, in which case the certificate is intended to be unusable for authentication purposes. This information is not embedded in the certificate previously stored at the user device. Therefore, in order to determine whether a certificate may be relied on for authenticating a user, the user device must obtain the updated revocation status of the certificate when a user attempts to log into the device. In some PKI systems, an Online Certificate Status Protocol (OCSP) responder is provided, which is a dedicated server used to provide access to updated certificate status; the user device may query the OCSP responder over a network, for example over the Internet, in order to obtain updated revocation information before authenticating the user. Thus, if the user device is unable to query the OCSP for some reason, then the device will be unable to authenticate the user. In other systems, the user device must consult a Certificate Revocation List (CRL), which is a listing of all certificates in the system that had been revoked by the corresponding CA. The CRL typically evolves into a lengthy document over time, and in order to consult the list, the user device must download a copy over the network, or alternatively in response to a request from the user device, a proxy server on the user's network must download the appropriate CRL and respond to the user device once the CRL is received and checked. These processes delay the authentication process, and furthermore if the user device is unable to access a copy of a CRL to consult during the authentication process or is unable to contact the proxy server, then again the user device will be unable to authenticate the user. In the case of a wireless user device that may happen to be outside of radio coverage or may otherwise be unable to connect to a wireless gateway to the required network to contact the OCSP responder or obtain a CRL, the user will be locked out of his or her mobile device, even if he or she would be otherwise authorized to use the device, simply because no wireless network connection can be maintained.
• It is therefore desirable to provide an improved system and method to handle certificate status checking on a mobile device.
BRIEF DESCRIPTION OF THE DRAWINGS
• Embodiments of the inventive aspects of this disclosure will be best understood with reference to the following detailed description, when read in conjunction with the accompanying drawings, in which:
• FIG. 1 is a schematic diagram of an exemplary network topology, including certificate status sources, a mobile device, and a security token access device;
• FIG. 2 is a schematic representation of exemplary embodiments of the mobile device and the security token access device ofFIG. 1;
• FIGS. 3aand3bare flowcharts of methods of authenticating a user;
• FIG. 4 is a flowchart of a method of authenticating a user and updating the status of the authentication certificate; and
• FIG. 5 is a further schematic diagram of an exemplary wireless mobile communications device.
DETAILED DESCRIPTION
• In the embodiments described herein, a method for authenticating a user to a user device is provided, wherein the method comprises verifying, using authentication information stored at a user device, data received in association with a request for access to the user device and checking a status indicator stored at the user device and associated with the authentication information to determine whether the authentication information is valid; allowing access to the user device if the data received in association with the request for access is verified and the status indicator indicates that the authentication information is valid; and updating the status indicator on an intermittent basis when the user device is in communication with an authentication information status source. One aspect of this embodiment is that the act of updating the status indicator may comprise, if the user device is in communication with a network providing access to the authentication information status source, transmitting a request for status information for the authentication information to the authentication information status source; and if a response to the request comprising status information is received, updating the status indicator with the received status information.
• In a further embodiment, an authentication system for a user device is provided, wherein the authentication system comprises a memory storing authentication information for authenticating a user to the user device and for storing a status indicator comprising status information associated with the authentication information; a status checking module for checking the status indicator stored in association with the authentication information, wherein the user is allowed access to the user device if the user is authenticated wherein the status indicator indicates that the authentication information is valid; and an updating module for transmitting a request for status information for the authentication information to a authentication information status source periodically at a first predetermined time interval, receiving a response comprising status information in response to the request, and updating the stored status indicator with the received status information. In a further aspect of the authentication system, the updating module is configured to transmit a further request for status information at a further predetermined time interval if a response to a previous request is not received, wherein the further predetermined time interval is less than the first predetermined time interval.
• Still a further embodiment provides a method for managing secure access to a wireless communication device, the method comprising receiving a request to authenticate a security token; determining, using authentication certificate status information, whether an authentication certificate is revoked, wherein the authentication certificate comprises public key data and wherein both the authentication certificate and the authentication certificate status information are locally stored at the wireless communication device; authenticating the security token using the locally stored authentication certificate if the locally stored authentication certificate is determined to be not revoked; and requesting authentication certificate status information from a remotely located certificate status source via a wireless communication link, wherein the act of requesting authentication certificate status information is automatically performed periodically according to a predetermined time interval.
• In the foregoing embodiments, the updating of a status indicator may be repeated intermittently, for example at a first predetermined time interval, and if a response to a request for information regarding authentication information status is not received, the updating of the status indicator may be repeated at further time intervals that may be the same, or shorter or longer than the first predetermined time interval. Such further time intervals may be increased or decreased from the length of the first predetermined time interval. The further time interval may be a fraction of, or a multiple of the first predetermined time interval, although the further time interval may be set at an arbitrary value. For example, the further time interval may be less than half, half, double, or more than double, the first time interval. If a response to a repeated request is received, then further updating of the status indicator may be repeated again at the first predetermined time interval. If a response to a repeated request is not received, the updating of the status indicator may be repeated at the further time interval, or at yet a further time interval that is longer or shorter than the previous time interval. The authentication information or certificate may comprise public key data, and thus verifying data received in association with a request for access to the user device may comprise providing an authentication token storing private key data; transmitting a challenge to the authentication token; receiving from the authentication token a response comprising the challenge signed using the private key data; and verifying the response using the public key data, such that the user is authenticated if the response is verified and the status indicator indicates that the certificate comprising the public key data is valid. The authentication token may communicate via an authentication token access device; the authentication token or the access device, or both the authentication token and access device, may be separate from the user device. For access to the user device to be allowed, a user-entered password may also be verified.
• Referring toFIG. 1, an overview of an exemplary system for use with the embodiments described below is shown. One skilled in the art will appreciate that there may be many different topologies, but the system shown inFIG. 1 helps demonstrate the operation of the systems and methods described in the present application. For example, there may be many user devices connected to the system that are not shown in the simple overview ofFIG. 1.
• FIG. 1 shows auser device100, which may comprise a mobile communication device. It will be appreciated by those skilled in the art that the mobile device may comprise any computing or communication device that is capable of connecting to a network by wireless means, including, but not limited, to personal computers (including tablet and laptop computers), personal digital assistants, smart phones, and the like. It will further be appreciated by those skilled in the art that these devices may be referred to herein as computing devices or communication devices, and may have principal functions directed to data or voice communication over a network, data storage or data processing, or the operation of personal or productivity applications; those skilled in the art will appreciate that terminology such as “mobile device”, “communication device”, “computing device”, or “user device” may be used interchangeably.
• Theuser device100 may, for example, be connected to an Internet Service Provider on which a user of the system ofFIG. 1, likely the user associated with theuser device100 illustrated inFIG. 1, has an account. The system ofFIG. 1 may be located within a company, possibly connected to a local area network, and connected to the Internet or to another wide area network, or connected to the Internet or other network through a large application service provider. Other features for network connectivity, such as the infrastructure of the local area network, Internet, wide area network, wireless gateway, and the like, are not shown inFIG. 1 but are known to those having ordinary skill in the art. Theuser device100 may be capable of sending and receiving messages and other data via wireless transmission, typically at a radio frequency (RF), from a base station in a wireless network to the user device. The particular network may be any wireless network over which messages may be exchanged with a user device such as theuser device100. The user device may receive data by other means, for example through a direct connection to a port provided on the user device such as a Universal Serial Bus (USB) link.
• In accordance with various embodiments, theuser device100 is capable of communicating with a securitytoken access device104 over a wired orwireless communication link36. In other embodiments, communication takes place overwireless communication link36. A non-exhaustive list of examples of wireless local area network standards forwireless communication link36 includes the Institute of Electrical and Electronic Engineers (IEEE) for Wireless LAN MAC and Physical layer (PHY) 802.11a, b, g and n specifications or future related standards, the Bluetooth® standard, the Zigbee™ standard and the like. The securitytoken access device104 may comprise a reader device or a read-write device. Thus, for example, if the securitytoken access device104 is a read-write device, theaccess device104 may be configured to not only read data from an associated security token, but to also write data to the security token. It will be appreciated by those skilled in the art that the systems and methods disclosed herein may incorporate a security token access device that is capable of both reading and writing to a security token, and that the embodiments described herein are not limited to a security token reader device.
• A security token, here shown as asmart card108, is shown inserted into theaccess device104. Smart cards are personalized security devices, defined by the ISO7816 standard and its derivatives, as published by the International Organization for Standardization. A smart card may have a form factor of a credit card and may include a semiconductor device. The semiconductor device may include a memory that can be programmed with a secret key and with an authentication certificate, and may include a decryption engine, e.g., a processor and/or dedicated decryption logic. The smart card's functionality may be embedded in a device having a different form factor and being capable of communicating over an additional communication protocol, for example a USB device.
• Thesecurity token108 may include a connector for powering the semiconductor device and performing serial communication with an external device. Theaccess device104 may be provided in one of a number of form factors, including, but not limited to, a portable access device that can be worn on the person, for example by means of a lanyard (not shown) suspended around a user's neck. Alternatively, theaccess device104 may be provided in a desktop reader or reader-writer form factor, or other form factor suitable for the security token environment that will be apparent to the skilled reader. In a further embodiment, the functionality of thesecurity token108 and theaccess device104 may be integrated into a single unit.
• While the configuration ofaccess devices104 anduser devices100 will be generally appreciated by those skilled in the art,FIG. 2 provides a schematic overview of select components of such devices. Theaccess device104 may comprise aprocessor326, configured to executecode329 stored in amemory element328. Theprocessor326 andmemory element328 may be provided on a single application-specific integrated circuit, or theprocessor326 and thememory element328 may be provided in separate integrated circuits or other circuits configured to provide functionality for executing program instructions and storing program instructions and other data, respectively. The processor is connected to a securitytoken interface330. Thememory328 may comprise both volatile and non-volatile memory such as random access memory (RAM) and read-only memory (ROM); sensitive information, such as keys and personal identification numbers (PINs), may be stored in volatile memory.
• Thecode329 provided in theaccess device104 may include operating system software, password verification code, and specific applications, which may be stored in non-volatile memory. For example thecode329 may comprise drivers for theaccess device104 and code for managing the drivers and a protocol stack for communicating with thecommunications interface324 which comprises a receiver and a transmitter (not shown) and is connected to anantenna322.
• Theaccess device104 may also be configured to interface with the user via the input means112, such as a button for manipulation by the user, and via adisplay110, such as a single-line readout for displaying strings of alphanumeric characters. Thecommunications interface324 may also comprise other processing means, such as a digital signal processor and local oscillators. If theaccess device104 is separate from theuser device100, it may include a power supply (not shown), which in the case of a portable security token access device may be provided by at least one battery or power cell. The casing and the power supply of theaccess device104 is configured such that removal of the casing disconnects the power supply, thereby clearing the volatile memory of theaccess device104. Theaccess device104 may also be provided with a further output means, not shown, such as a light emitting diode (LED), which may be tri-coloured for indicating the status of theaccess device104.
• Theuser device100 comprises an input means, for example akeyboard114, although alternative or additional input means, such as thumbwheels, trackballs, touchpads, and buttons, may also be provided. Theuser device100 also comprises an output means, such as adisplay116; theuser device100 may also be provided with a speaker for non-visual communication, not shown. The input and output may be integrated, such as, for example, in a touchscreen display. The mobile device comprises anantenna302 connected to acommunication interface304, which in turn communicates with aprocessor306. Thecommunication interface304 may include similar components as thecommunication interface324 of theaccess device104, such as a digital signal processor, local oscillator, a receiver, and a transmitter. Theprocessor306 accesses amemory element308 which stores code309, which may include operating system software and application-specific software, as well as drivers and protocol stacks for handling communication over one or more communication links, such as thewireless communication link36, as well as an authentication module for carrying out the various processes described below. Thememory element308 may include both volatile and non-volatile memory. Thememory element308 and theprocessor306 may be provided in a single application-specific integrated circuit, or may be provided as separate components. Theprocessor306 may execute a number of applications that control basic operations, such as data and voice communications via thecommunication interface304, as well as a personal information manager that may be installed during manufacture and e-mail client for composing, editing, digitally signing and encrypting, and digitally verifying and decrypting messages.
• The user whose security information is stored on thesecurity token108 may use theaccess device104 for identification and authentication to theuser device100, and optionally to digitally sign and/or decrypt messages sent or received by theuser device100. As one example, theuser device100 may be configured to send and receive e-mail, and may be configured to employ the Secure Multipurpose Internet Mail Extensions (S/MIME) protocol, such that e-mail messages received at theuser device100 are encrypted using a symmetric algorithm with a random session key generated by the sender of the e-mail message and encrypted by the recipient's (most likely theuser device100 user's) public key and sent with the message, and messages sent from theuser device100 are likewise encrypted with a random session key generated at theuser device100. Upon receipt of an encrypted e-mail message, theuser device100 may extract the encrypted session key and send it to theaccess device104 via thecommunication link36, which may be a secure communication link. Theaccess device104 then sends the encrypted session key to thesecurity token108, and the decryption engine of thesecurity token108 may decrypt the encrypted session key using the recipient's private decryption key, which is stored in thesecurity token108. Theaccess device104 retrieves the decrypted session key from thesecurity token108 and forwards it to theuser device100 viacommunication link36 so that the user device can decrypt the received e-mail message. Thesecurity token108 may prevent unauthorized use of the recipient's private decryption key by requiring that a password or personal identification number (PIN) be supplied at the user device100 (and verified against a password or PIN stored at thesecurity token108 either in the clear or in an encoded form) before allowing the decryption operation to proceed. In the embodiments described herein, it will be understood by those skilled in the art that a password may comprise alphanumeric characters or other indicia, but may alternatively comprise only alphabetic characters or numeric characters; similarly, the PIN may comprise alphanumeric characters or other indicia, but may also alternatively comprise only alphabetic characters or numeric characters. Both a password and a PIN may be of any desired character length, according to the information technology policy or strength of protection desired. In the following embodiments, the selection of the format of password or PIN (e.g., the number of characters in length, and whether the password or PIN may comprise exclusively numeric characters, or may comprise other combinations of alphanumeric characters or other indicia) is a minor variation within the scope of these embodiments.
• Similarly, to add a digital signature to an e-mail message or other message being sent byuser device100, the mobile device may send a hash of the contents of the message to theaccess device104 over thecommunication link36. Theaccess device104 passes the hash to thesecurity token108, which produces a digital signature from the hash and the sender's private signing key, which is stored in thesecurity token108. Thesecurity token108 then passes the digital signature to theaccess device104, which forwards it to theuser device100 via thecommunication link36 so that the user device can transmit it along with the message to the appropriate messaging server. Again, thesecurity token108 may prevent unauthorized use of the sender's private signing key by requiring that a password or PIN, or both, be supplied before allowing the signing operation to proceed. A recipient of a message thus signed would procure a copy of the sender's public key certificate corresponding to the private signing key used to sign the message, and may verify the authenticity of the signed message using the public key and checking the status of the public key certificate to determine whether it is still valid and not revoked.
• Further, theuser device100 may be configured to require user authentication before allowing the user to access some or all of the data stores or functionality of theuser device100. In accordance with various embodiments, two-factor authentication may be employed. In other embodiments, fewer or more than two factors may be employed. In two-factor authentication, the user must provide a token such as thesecurity token108 comprising authentication information associated with that user that is capable of verification by a third party, and in addition, the user is also required to enter a predetermined device password or other PIN using an input device on theuser device100. This device password may be stored in the clear in the non-volatile memory of theuser device100, or stored in a hashed, salted and hashed, or encrypted form in the device memory. If two-factor authentication is employed, then the user is authenticated to theuser device100 upon verification by theuser device100 of both the user-entered password and the response from the user-suppliedauthentication token108. If the verification fails, then theuser device100 remains locked to the user. Again, the various algorithms by which a challenge may be issued, signed or encrypted, and verified, will be known to those skilled in the art.
• In the two-factor authentication embodiment, both a device and security token password (or PIN) verification is required. Not only is the user asked to supply thesecurity token108 and enter a predetermined device password or PIN using an input device on theuser device100 that is verified at the mobile device, but the user is asked to enter a further password or PIN, for example via the input device of theuser device100, which is verified against a further password or further PIN stored either at theaccess device104 or on thesecurity token108. This further password or further PIN may be stored at theaccess device104 orsecurity token108 in the clear or in an obfuscated format (such as in a hashed, salted and hashed, or encrypted form). The verification of the further password or further PIN may be carried out at the same time as the verification of the response received from the security token. In a further one-factor authentication embodiment, the password or PIN verification at theuser device100 may be omitted, and the user is only authenticated using the suppliedsecurity token108.
• With reference toFIG. 1, in accordance with various embodiments, authentication by an authentication token, such as a smart card, is enabled on theuser device100. Theuser device100 is provided with authentication information such as anauthentication certificate35 comprising key data which is to be used for user authentication. Theuser device100 may be supplied with a number of certificates stored in memory; for example, anauthentication certificate35 may be designated for use in verifying the user's identity at login, or when the user attempts to access certain functions or data on theuser device100. A further certificate stored at theuser device100 may be designated for use as a signing certificate (not shown) for signing or encrypting messages, as described above. Various asymmetric or elliptical key algorithms and the like, and the format and utilization of digital certificates for signing, verifying, encrypting or decrypting messages, or for verifying a user's identity, will be known to those skilled in the art. In the exemplary embodiment described here, the authentication information comprises anauthentication certificate35, which itself comprises a public key, likewise stored at theuser device100.
• The authentication information may comprise security information associated with the user by a trusted issuing authority such as a CA, as will be understood by those skilled in the art; thus, in one embodiment thesecurity token108 stores a private key while a corresponding public key, typically associated with a digital certificate, may be made available to third parties and is provided to and stored at theuser device100.
• Turning toFIG. 3a, the authentication process by which the user may gain access to the data stores and/or functions of theuser device100 will be described. At step500, theuser device100 receives a request for user access. The form of this request will be understood by those skilled in the art; the request may be detected by detecting a keystroke or activation of an input means on the user device, or may be triggered by another event at the user device. In a two-factor authentication embodiment, theuser device100 then engages in two of the verification branches shown inFIG. 3a. In a two-factor authentication embodiment, a user-entered password (or PIN) is received and verified against a mobile device password (or PIN) at510, such as in the manner described above. A determination is made as to whether each of these verifications was successful, and whether the authentication information stored at the security token, for example, a digital certificate, is valid, at550. The manner of determining the validity of the authentication information is described in detail below. If the verification is successful and the authentication information is determined to be valid, then the user is authenticated to theuser device100 and access to the device's data stores and functions is granted at560. Otherwise, the user is not authenticated and access is not granted at570. The user may be offered another opportunity to gain access to theuser device100, not shown.
• In a further two-factor authentication embodiment, in addition to theverification user device100 password or PIN, a further PIN or password for thesecurity token108 is received and verified at520. Thus, the user is authenticated and granted access at560 only if both the password or PIN for each of theuser device100 and thesecurity token108 is verified, and if the authentication information is determined to be valid. In a three-factor authentication embodiment, an additional authentication process is executed at530. In the example ofFIG. 3, biometric data is received from the user (for example, a fingerprint is detected and scanned), and compared against previously stored biometric data for an authenticated user. This previously stored biometric data may be stored on the network, for example at theserver40 or another server; it may be stored on theuser device100; it may be stored on theauthentication token108; or it may be stored on theaccess device104. This biometric data may be stored in an obfuscated format, or it may be stored in the clear. The biometric data received from the user at530 may be received via an input device on theuser device100, or it may be implemented at theaccess device104 orsecurity token108, or in a further separate device in communication with theuser device100. The implementation of biometric scanning and verification will be understood by those skilled in the art. Thus, in the three-factor authentication embodiment, the user is authenticated and granted access at560 only if (i) if both the password or PIN for each of theuser device100 and optionally of thesecurity token108, is verified; (ii) if the biometric data received from the user is verified; and (iii) if the authentication information is determined to be valid. It will be appreciated by those skilled in the art that not all of these verification processes510,520,530 need be carried out; and indeed further verification processes, not shown, may also be carried out prior to granting user access to theuser device100. These verification processes may be implemented, effectively, in parallel—that is to say, each executed independently of each other—or in sequence, such that verification of one identifier (e.g., the biometric data, or the security token PIN or password, or the device password or PIN) must be successful before another identifier is verified.
• A further embodiment is shown inFIG. 3b, in which the validity of the authentication information is determined at505 after a receipt of a request for user access at500, but prior to the verification of other identifiers at510,520 or530. If the authentication information, which is used to authenticate thesecurity token108 in the manner described in further detail below, is not valid, then the user is denied access at570. If the authentication information is valid, then theother verification steps510,520,530 (or a subset thereof) are carried out; if it is determined at555 that each of the verifications that were carried out were successful, then the user is authenticated and access is granted to theuser device100 and its data stores and functions at560; otherwise, user access is denied at570. All of the processes and branches inFIGS. 3aand3bmay be executed by an authentication module resident on theuser device100, and, where applicable, with an authentication module resident at thesecurity token108 oraccess device104 or at a separate device for receiving biometric data.
• FIG. 4 illustrates an embodiment such as that inFIG. 3b, in which the validity of the authentication information, such as a digital certificate, is determined prior to the execution of other authentication processes. For simplicity, additional verification such as biometric data verification is not shown. A user request for access is received at theuser device100 at350. The form of this request, as noted above, may be detected by detecting a keystroke or activation of an input means on the user device, or it may be triggered by another event at the user device. First, the validity of the authentication information (referred to inFIG. 4 as a certificate) is determined at359. If the certificate is not valid, then the user is not authenticated and access is denied at360. If the certificate is determined to be valid, then three of the possible authentication branches are shown inFIG. 4.
• In a first branch, theuser device100 receives and verifies a password or PIN entered by the user at351. The user-entered password or PIN may then be compared by theuser device100 to a previously stored password or PIN; if the previously stored password or PIN is in encrypted or hashed form, as noted above, then the user-entered password or PIN may first be hashed or encrypted and the result verified against the previously stored value to authenticate the user. Verification of the password or PIN may be carried out using any other process that will be apparent to those skilled in the art. If theuser device100 determines that the password or PIN is not verified at356, then the user is not authenticated to thedevice100, and is denied access to the functions and/or data stores of the device at360. If the password or PIN is verified at356, then theuser device100 awaits verification of other security factors at361.
• In a second branch, a PIN or password for accessing thesecurity token108 is received, for example via an input device on theuser device100. The PIN or password is verified against a value stored at thesecurity token108 at371; this verification may take place at thesecurity token108 itself, or at theaccess device104. If it is determined that the PIN or password is not verified at372, then the user is not authenticated to thedevice100, and is denied access to the functions and/or data stores of the device at360. If the password or PIN is verified at372, then theuser device100 awaits verification of other security factors at361. As noted above, in another embodiment these two password or PIN authentication branch may be omitted; thus, inFIG. 4, the steps relating to the password or PIN branches are shown in phantom. Furthermore, it will be appreciated by those skilled in the art that if two-factor authentication is employed, then the two branches (i.e., the password or PIN branch and the security token challenge-response branch) may be carried out either concurrently or consecutively. For example, the authentication module on theuser device100 may execute351,356,371 and372 first, before commencing352, described below. Alternatively, the authentication module may execute the password or PIN branches only after the security token challenge-response branch,352,355,357, and358, are completed and the response is verified at358. In a further alternative, the authentication module may execute the password or PIN branch while it awaits a response from the security token at355, or execute the verification of the challenge response at357 while it awaits a password or PIN from the user at351 or371.
• In the security token challenge-response branch, theuser device100 issues a challenge to theauthentication token108 via theaccess device104 over thewireless link36, if communication between theaccess device104 and theuser device100 is wireless, at352. The challenge may be a randomly generated value or nonce which is temporarily stored in memory at theuser device100, or a hash of a value, which may be randomly generated, with other data. Theauthentication token108 receives the challenge at353 and prepares and transmits a response to theuser device100 at354; the response may comprise the challenge, signed or encrypted using aprivate key55 stored at theauthentication token108. Thus, in this embodiment, the request for access ofstep350 is associated with authentication information to be verified. The receipt and verification of the security token PIN or password may be carried out at the same time; for example, the challenge transmitted to theauthentication token108 may also comprise the user-entered PIN or password that is to be verified against a PIN or password stored at thesecurity token108, and the response from thesecurity token108 may further comprise an indicator that the PIN or password was verified, or alternatively, thesecurity token108 may not return a correct response at354 if the PIN or password is not verified. Theuser device100, upon receipt of the response at355, verifies the response using the public key data stored in association with theauthentication certificate35 at357; if the response is verified at358 (i.e. theuser device100 successfully extracts the original challenge value, or an expected value based on the challenge, from the response), and if the device password or PIN is verified at356 and the security token PIN or password is verified at372 (and if any other authentication identifiers, such as biometric data, are verified), then the user is authenticated to theuser device100 and is granted access to its functions and/or data stores at362. Thus, it can be seen that in a two-factor authentication process if one of these three conditions—verification of the password or PIN, verification of the response, and validity of thecertificate35—are not met, then the user is denied access to the user device at360. The denial of access to the device,360, may be determined at any time once one of these three conditions is determined to have failed; thus, a second360 is also shown inFIG. 4 in phantom as the consequence if the response fails to verify at358 or372, or after an attempt at verifying other authentication identifiers, not shown.
• It will be appreciated by those skilled in the art that the foregoing process is only one example in which a request for access associated with authentication information, such as theauthentication certificate35, is presented to theuser device100. The granting of access to the device at362 is contingent on theuser device100 successfully using the authentication information stored at thedevice100 to verify data provided to thedevice100 as a consequence of the request for access. Further, although not specifically depicted inFIG. 4 it will be appreciated that the step of determining whether thecertificate35 is valid at359 may be carried out later in the authentication process, although efficiencies may be realized by implementing the validity check359 immediately after the receipt of a user request for access at350; if the certificate is determined to be invalid at that point, then the other authentication branches need not be followed; the user will be denied access at360. If thecertificate35 is determined to be valid, then the other authentication branches will proceed generally as described above. Alternatively, the validity determination at359 may be carried out before the challenge response is verified atstep357, or determining the validity of thecertificate359 may be carried out at the same time as the verification of thechallenge response357; i.e., these two steps may be combined into the single “verify challenge response”process357.
• The validity of authentication information such as a certificate, meaning whether the authentication information should be relied on or not to authenticate the identity of the user presenting the authentication information may be determined by its expiration date and its revocation status. For example, authentication information such as a certificate may be provided with an embedded expiration date, the passing of which may be determined with reference to an internal clock by any device in possession of a replica of the certificate. In a further embodiment, the validity of the authentication information may be determined by one or more of its expiration date, revocation status, and trust status. Thus trust status is an indicator which indicates whether the authentication information is either inherently or explicitly trusted by theuser device100 or by the user's network. For example, trusted certificates may be explicitly trusted by storing them in a trusted key store at theuser device100, whereas untrusted certificates are stored elsewhere; alternatively, trusted certificates may be identified in a list or other data store, which may be consulted by an authentication module at theuser device100 whenever the trust status of a certificate is to be determined.
• Furthermore, thecertificate35 may be a certificate in a chain of certificates. As will be understood by those skilled in the art, a certificate chain is a sequence of certificates in which each subsequent certificate is signed by the certificate preceding it in the chain. Thus, the validity of acertificate35 may be verified not only with reference to the expiration date, revocation status, or trust status of thecertificate35 itself, but also with reference to the expiration date and revocation status of each of the certificates preceding thecertificate35 in the chain.
• Unlike the expiration date, which may be embedded in the certificate itself, information relating to trust status and the revocation status is not; trust status indicia is typically stored on theuser device100 itself, although it may be stored elsewhere on theuser device100's network; revocation status of a certificate, however, is typically obtained from sources external to theuser device100. For example, turning back toFIG. 1, the status of a certificate may be found in a certificate revocation list (CRL). While the certification authority that issued the certificate in the first place is typically the entity that may revoke the certificate, the server responsible for maintaining a CRL, or the server queried in order to determine the status of a given certificate, is not necessarily at the certification authority. For example, a CRL may be maintained at akey server220. When thekey server220 receives a notification that a certificate has been revoked, it updates the CRL to reflect the revocation; it may then either “push” notifications and/or copies of the CRL to other points on the network, or it may simply allow other servers or devices on the network to access the CRL and “pull” the data from thekey server220. For example, aresponder210 may pull the CRL on a periodic basis from thekey server220. Theresponder210, itself, receives queries from devices over theInternet20 regarding the status of a given certificate, and transmits responses to those devices over theInternet20 regarding the certificate status. Further, aproxy server200 may be connected to theInternet20, and may respond to requests regarding certificate status from other devices over theInternet20. Theproxy server200 itself may maintain a cache of certificate status which it updates by querying theresponder210. Theproxy server200 may be incorporated into a user's home network, for example at amessage server40 or another server in that local network. Thus, to check the status of a certificate, a device generally must communicate over thewireless network105 and theInternet20 with a server in order to determine the status of the certificate.
• However, it is desirable to avoid the delay incurred by obtaining information from a certificate status source such as theproxy server200,responder210, orkey server220. Further, if theuser device100 is unable to access thewireless network105 or theInternet20 when a user attempts to log in, in the prior art system of user authentication, theuser device100 would not be able to determine the status of thecertificate35, and therefore would not allow the user to authenticate him or herself to thedevice100. The user would therefore remain locked out of the functions and/or data stores of theuser device100.
• Thus, in accordance with various embodiments, theuser device100 stores in its non-volatile memory not only theauthentication certificate35 but also astatus indicator45. Thestatus indicator45 comprises status information for theauthentication certificate35. The status indicator may comprise a subset of a CRL or a response from a certificate status source such as theproxy server200 orresponder210. The status indicator may further comprise a timestamp, representing the last time that thestatus indicator45 had been refreshed in the memory of theuser device100, and optionally an identifier of the source of the certificate status, such as thekey server220,responder210, orproxy server200.
• In various embodiments, the status represented in thestatus indicator45 may be indicated as being “valid”, “revoked”, or “on hold.” A status such as “on hold” may be a subcategory of “revoked”; if subcategories of “revoked” status are provided, then the status indicator may also comprise a reason code as well, which provides a further explanation why the certificate was revoked. The “on hold” status may mean that an administrator may have reason to believe that theprivate key55 corresponding to thecertificate35 has been compromised for some reason. For example, the user may have reported that he or she had misplaced thesecurity token108, which may prompt an administrator to change the status of the certificate to “revoked” and/or “on hold”. If the user had reported thesecurity token108 stolen, then thestatus indicator45 would indicate “revoked” and the reason code may indicate “stolen”, or may be blank. This status information may first be updated at the source CRL or other certificate status source, and would be updated at theuser device100 as described below. Other revocation reasons will be apparent to those skilled in the art. It will also be apparent that the certificate status need not literally comprise indicators such as “revoked” or “on hold”; thestatus indicator45 may be encoded in any appropriate format. For example, thestatus indicator45 may comprises numeric codes which may be interpreted by a human with reference to an established information technology policy for thatuser device100.
• Returning toFIG. 4, when theuser device100 checks the validity of the certificate at359, the device not only checks that thecertificate35 is not expired, but also checks thestatus indicator45 stored at theuser device100 in order to determine whether thecertificate35 is valid. A “valid”certificate35 is defined according to one or more of the expiration, revocation, and trusted status. For example, avalid certificate35 may be considered to be one that is not expired and is not revoked (without any consideration of whether the certificate is explicitly or implicitly trusted). Alternatively, avalid certificate35 may be defined to be a certificate that is at least one of not expired, not revoked, and trusted; or it may be a certificate that it as least two of not expired, not revoked, and trusted; or it may be a certificate that is not expired, not revoked, and trusted. In a further embodiment, a policy may be implemented at theuser device100 such that if thestatus indicator45 indicates that thecertificate35 is revoked for a particular reason—for example, if thecertificate35 is “on hold”—the user device may still deem thecertificate35 to be valid until thestatus indicator45 is updated to indicate that thecertificate35 is revoked for another reason, such as “stolen”. Thus, as an example, a valid certificate may be defined as a certificate that is at least one of (i) not expired; and (ii) on hold or not revoked, and (iii) trusted; as a certificate that is at least two of the foregoing criteria; as a certificate that is all three of the foregoing criteria; or as a certificate that is both (i) not expired and (ii) on hold or not revoked. In still a further embodiment, while theuser device100 may be configured to authenticate the user with an “on hold” certificate, if the certificate is “on hold” rather than not revoked, the access granted to the user may be limited to access to only a subset of user data and functions on thedevice100. For example, the user may only be permitted to make outgoing calls or send outgoing messages using thedevice100, and many not be permitted to access the data stores or encrypted data until thecertificate35 status is updated in thestatus indicator45 to be not revoked and unexpired. Alternatively, the user may only be permitted to access a message inbox or other personal information management data, provided the data is not stored in encrypted from on theuser device100. In yet a further embodiment, if thecertificate35 is part of a chain of certificates, then each of the certificates preceding thecertificate35 in the chain must also share the same characteristics as the certificate35 (e.g., at least one of (i) on hold and not revoked, (ii) not expired, and (iii) trusted, or a combination of at least one or two of these criteria) for thecertificate35 to be valid. The definition of avalid certificate35 will depend on the information technology policy implemented at theuser device100.
• In accordance with various embodiments, theuser device100 is further configured to perform background updates of thestatus indicator45. InFIG. 4, even while the user is authenticated to the device, theuser device100 periodically queries the status of thecertificate35 at364 by contacting a certificate status source, for example theresponder210 or theproxy200, and querying the status of thecertificate35. This query may be made at the expiry of a first predetermined time interval, for example once every 60 minutes, or at another first predetermined time interval configurable at theuser device100 or in an information technology policy or other security rule provided to theuser device100. The user device may contact thekey server220 in order to obtain a copy of an updated CRL, although this would likely consume more bandwidth and be less desirable. The frequency at which theuser device100 transmits these queries is set at a first frequency that may be determined by an administrator, and for example established in an information technology policy implemented at theuser device100; this first frequency may be once a day or once an hour. If theuser device100 receives a response at366, then thestatus indicator45 is updated at thedevice100 at368, and a determination is made at379 whether thecertificate35, which had been used to authenticate the user as described earlier, is still valid. If thecertificate35 is still valid according to thestatus indicator45, the user access to the functions and/or data stores of thedevice100 is maintained, and the user may not detect any interruption in his or her operation of the device. If thestatus indicator45 indicates that thecertificate35 is now invalid because it is revoked, then the user's active session may terminate, and the authentication module may lock the user out of theuser device100 immediately at360. In a further embodiment, theuser device100 may be configured to automatically delete user data, such as inbox messages, calendar, or personal information management data, if the certificate is revoked. However, if thestatus indicator45 indicates that the certificate is merely “on hold”, theuser device100 may be configured to offer the user the option to terminate the session and lock thedevice100, or may provide the user with a warning that failure to remove the “on hold” status within a set period of time will result in termination of the session and locking out the user at360.
• During these repeated determinations of whether the certificate is valid at359, it will be appreciated that the determination of validity may also comprise a check to determine whether the certificate is still unexpired, or whether each of the certificates in a chain of certificates including thecertificate35 is still determined to be valid. In one embodiment, if a certificate ceases to be valid because it is expired, but it is not revoked and is otherwise in good standing, the user is not immediately locked out of theuser device100; rather, theuser device100 is configured to allow the user's session to end at the user's discretion, but the next time the user attempts to log into the device if expiration is a criteria used to determine if a certificate is valid, the user may be locked out until a new certificate is supplied to theuser device100, or the now-expiredcertificate35 is renewed.
• If, however, a response is not received at366 (a response may be deemed to have not been received if a predetermined timeout occurs or if the response comprises an error, for example) then theuser device100 repeats its query to the certificate status source at370. There are many reasons why a response may not be received; theresponder210 or theproxy server200 may be down, or the user device, if wireless, may be unable to access thewireless gateway105, or even if thewireless gateway105 is accessible, contact with the certificate status source through theInternet20 may fail. Therefore, theuser device100 attempts to repeat the query at370 until a response is received at366. The time interval before subsequent queries may vary until a response is received at366. After a first error is received or a first predetermined timeout occurs, the query may be repeated after a first time interval, for example 5 minutes. If an error is again received or if a predetermined timeout again occurs, the query may be repeated after a second, longer time interval, for example 10 minutes. Upon subsequent errors or timeouts, the time interval before a further query may be increased until a response is received; in this embodiment, the time interval may be increased until the interval reaches the first predetermined time interval. For example, if the first predetermined time interval is 60 minutes, when repeated errors are received or repeated timeouts occur in response to theuser device100's certificate status queries, theuser device100 may attempt to repeat the query after 5 minutes, 10 minutes, 20 minutes, and 40 minutes, and then after 60 minute intervals thereafter. Thus, in this embodiment, if the conditions giving rise to the first error received or first timeout detected by theuser device100 are only temporary, by making the initial reattempts at shorter intervals, a successful result to the reattempted query will be realized sooner; if the conditions giving rise to the receipt of an error or detection of a timeout at theuser device100 persist, then subsequent attempts to query the certificate status are made at longer intervals until the first predetermined time interval is reached.
• In a further embodiment, with each failed attempt to receive a response, the time interval before the next query attempt is reduced. In other words, the request attempts are made at370 with decreasing time intervals until a predetermined minimum time interval is reached. For example, if the first predetermined time interval is once per hour, if a first query fails, the first query attempt may be made 30 minutes later; if the first query attempt fails, then the second query attempt may be made 15 minutes later; and if the second query attempt fails, then the third query attempt may be made 5 minutes later; but if the third query attempt fails, subsequent query attempts are still made at 5 minute intervals. Once a query attempt succeeds and a response is received at366, the time interval at which queries are made returns to the first predetermined time interval.
• In addition, theuser device100 may also be configured to allow the user to force astatus indicator45 update at any time, rather than wait for the next scheduled update attempt.
• It will be appreciated that the background update procedure commencing at364 ofFIG. 4 may be executed by theuser device100, even if the user is not currently authenticated to the device. In that case, of course, there is no need to terminate a user's access to the device in the event thestatus indicator45 is updated to indicate that thecertificate35 designated for use as the authentication certificate is revoked.
• Thus, it can be seen that even if theuser device100 is unable to connect to a network over a wireless gateway and is unable to determine the current status of thedigital certificate35 from a source on the network, the user will still be able to log in to theuser device100 depending on the certificate status information stored in the local status copy on theuser device100. In various embodiments, theuser device100 refers to the local status copy during the authentication process, whether theuser device100 is able to connect wirelessly to a network or not. This enhances the user experience since the likelihood of delay during login and the likelihood that a legitimate user will be locked out due to a lack of radio coverage is reduced.
• As noted above, theuser device100 may store a number of certificates. In various embodiments, background updating of thestatus indicator45 for a certificate is only carried out for a single certificate, namely, the certificate designated as the one to be used in authenticating a user to the device. In further embodiments, theuser device100 may carry out the background update process for more than one certificate using the same or a different update schedule; for example, while thestatus indicator45 for theauthentication certificate35 is updated hourly, the status indicator for a sender's public key certificate stored at theuser device100 and used to verify the authenticity of a signed message received at theuser device100 may be updated only daily, while the status indicator for a further, private key certificate used by the user to digitally sign his or her own messages to be sent from theuser device100 may be updated only weekly. If thecertificate35 is a certificate in a chain of certificates, then theuser device100 may store the certificates preceding thecertificate35 in its chain; thus, in addition to carrying out the background update process to update thestatus indicator45 for thecertificate35, the user device may carry out the background update process and update the status indicators corresponding to each of the certificates preceding thecertificate35 in the chain as well. If a status indicator at theuser device100 for each of the certificates in the chain indicates that the certificate is “valid”, then provided the status of thecertificate35 itself permits the user to access some or all of the functions and data on theuser device100, the user will be provided such access. If the status indicator for one of the certificates in the chain, besides thecertificate35 itself, indicates that the certificate in the chain is “revoked”, then the user may be denied access to the functions or data on theuser device100. As noted above, the determination of whether each of the certificates in the chain is valid may be made in the same manner as the determination of the validity of thecertificate35. The determination of whether each of the certificates in the chain is valid may be carried out according to different criteria; for example, thecertificate35 may be determined to be valid if it is at least one of (i) on hold or not revoked, (ii) not expired, and (iii) trusted, whereas the other certificates in the chain may be deemed to be valid if they are at least (i) not revoked and (ii) not explicitly untrusted. Any combination of these criteria may be applied in variations of the embodiments described herein.
• In yet a further embodiment, each time the validity of the certificate is checked at359, the age of thestatus indicator45 is also verified to ensure that it has not aged beyond a predetermined threshold, for example one week. If thestatus indicator45 comprises a timestamp that is older than a predetermined threshold, then the certificate may be deemed invalid even though the certificate is, otherwise, unexpired and not revoked, according to thestatus indicator45.
• Optionally, the above system and method for authenticating a user with reference to thestatus indicator45 may be employed only when theuser device100 is unable to connect to a wireless network, either because it is outside of radio coverage or the radio in the device is turned off. If theuser device100 is able to connect to a wireless network, then upon user request for access, theuser device100 attempts to obtain updated status information from a certificate status source such as theresponder210 or theproxy server200. In yet another embodiment, the ability to use the locally cached certificate status in thestatus indicator45 is reserved only for thecertificate35 designated as the certificate for use in authenticating a user to theuser device100; for all other certificates, such as those used for signing messages, theuser device100 must obtain updated status information from a certificate status source such as theresponder210 or theproxy server200.
• Thus, the foregoing embodiments provide a method for managing secure access to a wireless communication device, the method comprising receiving a request to authenticate a security token; determining, using authentication certificate status information, whether an authentication certificate is revoked, wherein the authentication certificate comprises public key data and wherein both the authentication certificate and the authentication certificate status information are locally stored at the wireless communication device; authenticating the security token using the locally stored authentication certificate if the locally stored authentication certificate is determined to be not revoked; and requesting authentication certificate status information from a remotely located certificate status source via a wireless communication link, wherein the act of requesting authentication certificate status information is automatically performed periodically according to a predetermined time interval. The foregoing embodiments further provide the above method, further comprising decreasing the time interval if the wireless communication link fails, and still further comprising repeatedly increasing the time interval up to a maximum if the wireless communication link fails after decreasing the time interval. Repeatedly increasing the time interval may comprise doubling the time interval. Further, if the wireless communication link fails after repeatedly increasing the time interval, the embodiments may further comprise resetting the time interval to its original predetermined value. The embodiments may also provide for erasing user data from the wireless communication device, if the authentication certificate is determined to be revoked.
• The foregoing embodiments further provide the above method, further comprising that if the authentication certificate is determined to be on hold, requesting authentication certificate status information from the remotely located certificate status source via the wireless communication link, in response to a user-initiated request for status update, or still further comprising granting access to user data and functions on the wireless communication device after authenticating the security token using the locally stored authentication certificate if the locally stored authentication certificate is determined to be not revoked. The foregoing embodiments may also provide that the act of requesting authentication certificate status information from a remotely located certificate status source is not automatically performed in response to receiving the request to authenticate the security token, or that granting access to user data and functions comprises granting access to a subset of user data and functions on the wireless communication device if the locally stored authentication certificate is determined to be on hold. Still further, the foregoing embodiments may further comprise, if the locally stored authentication certificate is determined to be revoked once access is granted to the user data and functions on the wireless communication device, terminating said access; or may further comprise the act of verifying a user-entered password, and wherein the act of granting access to user data and functions comprises granting said access if the user-entered password is verified.
• As another example, the systems and methods disclosed herein may be used with many different computers and devices, such as a further wirelessmobile communications device100 shown inFIG. 5. With reference toFIG. 5, theuser device100 is a dual-mode mobile device and includes atransceiver411, amicroprocessor438, adisplay422,non-volatile memory424, random access memory (RAM)426, one or more auxiliary input/output (I/O)devices428, aserial port430, akeyboard432, aspeaker434, amicrophone436, a short-rangewireless communications sub-system440, andother device sub-systems442.
• Theuser device100 may be a two-way communication device having voice and data communication capabilities. Thus, for example, theuser device100 may communicate over a voice network, such as any of the analog or digital cellular networks, and may also communicate over a data network. These voice anddata networks419 may be separate communication networks using separate infrastructure, such as base stations, network controllers, etc., or they may be integrated into a single wireless network.
• Thetransceiver411 includes areceiver412, atransmitter414,antennas416 and418, one or morelocal oscillators413, and a digital signal processor (DSP)420. Theantennas416 and418 may be antenna elements of a multiple-element antenna, and may be embedded antennas. However, the systems and methods described herein are in no way restricted to a particular type of antenna, or even to wireless communication devices. In one embodiment, theDSP420 is used to send and receive signals to and from theantennas416 and418, and also provides control information to thereceiver412 and thetransmitter414. If the voice and data communications occur at a single frequency, or closely-spaced sets of frequencies, then a singlelocal oscillator413 may be used in conjunction with thereceiver412 and thetransmitter414. Alternatively, if different frequencies are utilized for voice communications versus data communications for example, then a plurality oflocal oscillators413 can be used to generate a plurality of frequencies corresponding to the voice anddata networks419. Information, which includes both voice and data information, is communicated to and from thetransceiver411 via a link between theDSP420 and themicroprocessor438.
• The detailed design of thetransceiver411, such as frequency band, component selection, power level, etc., will be dependent upon the voice anddata networks419 in which theuser device100 is intended to operate. The voice anddata networks419 may be separate voice networks and separate data networks, or may comprise integrated voice and data networks. It will be appreciated by those skilled in the art that these embodiments may be implemented on a variety of voice anddata networks419, including, but not limited to, 2 G, 2.5 G, 3 G, 4 G, and other voice and data networks, such as GSM, CDMA2000, GPRS, EDGE, W-CDMA (UMTS), FOMA, EV-DO, TD-SCDMA, HSPA, HSOPA, and the like.
• Depending upon the type of network ornetworks419, the access requirements for theuser device100 may also vary. For example, in GPRS data networks, network access is associated with a subscriber or user of a mobile device. A GPRS device typically requires a subscriber identity module (“SIM”), which is required in order to operate a mobile device on a GPRS network. Local or non-network communication functions (if any) may be operable, without the SIM device, but a mobile device will be unable to carry out any functions involving communications over the voice anddata networks419, other than any legally required operations, such as ‘911’ emergency calling.
• After any required network registration or activation procedures have been completed, theuser device100 may then send and receive communication signals, including both voice and data signals, over the voice and networks419. Signals received by theantenna416 from the voice anddata networks419 are routed to thereceiver412, which provides for signal amplification, frequency down conversion, filtering, channel selection, etc., and may also provide analog to digital conversion. Analog to digital conversion of the received signal allows more complex communication functions, such as digital demodulation and decoding to be performed using theDSP420. In a similar manner, signals to be transmitted to the voice anddata networks419 are processed, including modulation and encoding, for example, by theDSP420 and are then provided to thetransmitter414 for digital to analog conversion, frequency up conversion, filtering, amplification and transmission to the voice anddata networks419 via theantenna418.
• In addition to processing the communication signals, theDSP420 also provides for transceiver control. For example, the gain levels applied to communication signals in thereceiver412 and thetransmitter414 may be adaptively controlled through automatic gain control algorithms implemented in theDSP420. Other transceiver control algorithms could also be implemented in theDSP420 in order to provide more sophisticated control of thetransceiver411.
• Themicroprocessor438 manages and controls the overall operation of theuser device100. Many types of microprocessors or microcontrollers could be used here, or, alternatively, asingle DSP420 could be used to carry out the functions of themicroprocessor438. Low-level communication functions, including at least data and voice communications, are performed through theDSP420 in thetransceiver411. Other, high-level communication applications, such as avoice communication application424A, and adata communication application424B may be stored in thenon-volatile memory424 for execution by themicroprocessor438. For example, thevoice communication module424A may provide a high-level user interface operable to transmit and receive voice calls between theuser device100 and a plurality of other voice or dual-mode devices via the voice anddata networks419. Similarly, thedata communication module424B may provide a high-level user interface operable for sending and receiving data, such as e-mail messages, files, organizer information, short text messages, etc., between theuser device100 and a plurality of other data devices via the voice anddata networks419. Themicroprocessor438 also interacts with other device subsystems, such as thedisplay422, theRAM426, the auxiliary input/output (I/O)subsystems428, theserial port430, thekeyboard432, thespeaker434, themicrophone436, the short-range communications subsystem440 and any other device subsystems generally designated as442.
• Some of the subsystems shown inFIG. 5 perform communication-related functions, whereas other subsystems may provide “resident” or on-device functions. Notably, some subsystems, such as thekeyboard432 and thedisplay422 may be used for both communication-related functions, such as entering a text message for transmission over a data communication network, and device-resident functions such as a calculator or task list or other PDA type functions.
• Operating system software used by themicroprocessor438 may be stored in a persistent store such asnon-volatile memory424. Thenon-volatile memory424 may be implemented, for example, as a Flash memory component, or as battery backed-up RAM. In addition to the operating system, which controls low-level functions of the mobile device410, thenon-volatile memory424 includes a plurality ofsoftware modules424A-424N that can be executed by the microprocessor438 (and/or the DSP420), including avoice communication module424A, adata communication module424B, and a plurality of otheroperational modules424N for carrying out a plurality of other functions. These modules are executed by themicroprocessor438 and provide a high-level interface between a user and theuser device100. This interface typically includes a graphical component provided through thedisplay422, and an input/output component provided through the auxiliary I/O428,keyboard432,speaker434, andmicrophone436. The operating system, specific device applications or modules, or parts thereof, may be temporarily loaded into a volatile store, such asRAM426 for faster operation. Moreover, received communication signals may also be temporarily stored toRAM426, before permanently writing them to a file system located in a persistent store such as theFlash memory424.
• Thenon-volatile memory424 may provide a file system to facilitate storage of PIM data items on the device. The PIM application may include the ability to send and receive data items, either by itself, or in conjunction with the voice anddata communication modules424A,424B, via the voice anddata networks419. The PIM data items may be seamlessly integrated, synchronized and updated, via the voice anddata networks419, with a corresponding set of data items stored or associated with a host computer system, thereby creating a mirrored system for data items associated with a particular user.
• Context objects representing at least partially decoded data items, as well as fully decoded data items, may be stored on theuser device100 in a volatile and non-persistent store such as theRAM426. Such information may instead be stored in thenon-volatile memory424, for example, when storage intervals are relatively short, such that the information is removed from memory soon after it is stored. However, in one embodiment, this information is stored in theRAM426 or another volatile and non-persistent store to ensure that the information is erased from memory when theuser device100 loses power. This prevents an unauthorized party from obtaining any stored decoded or partially decoded information by removing a memory chip from theuser device100, for example.
• Theuser device100 may be manually synchronized with a host system by placing thedevice100 in an interface cradle, which couples theserial port430 of theuser device100 to the serial port of a computer system or device. Theserial port430 may also be used to enable a user to set preferences through an external device or software application, or to download other application modules324N for installation. This wired download path may be used to load an encryption key onto the device, which is a more secure method than exchanging encryption information via thewireless network419.
• A short-range communications subsystem440 may also be included in theuser device100. Thesubsystem440 may include an infrared device and associated circuits and components, or a short-range RF communication module such as a Bluetooth® module or an 802.11 module, for example, to provide for communication with similarly-enabled systems and devices.
• The systems and methods disclosed herein are presented only by way of example and are not meant to limit the scope of the invention. Other variations of the systems and methods described above will be apparent to those skilled in the art and as such are considered to be within the scope of the invention. For example, it should be understood that steps and the order of the steps in the processing described herein may be altered, modified and/or augmented, or that said steps may be carried out by software and/or hardware modules designed for such purpose, and still achieve the desired outcome.
• The systems' and methods' data may be stored in one or more data stores. The data stores can be of many different types of storage devices and programming constructs, such as RAM, ROM, Flash memory, programming data structures, programming variables, etc. It is noted that data structures describe formats for use in organizing and storing data in databases, programs, memory, or other computer-readable media for use by a computer program.
• Code adapted to provide the systems and methods described above may be provided on many different types of computer-readable media including computer storage mechanisms (e.g., CD-ROM, diskette, RAM, flash memory, computer's hard drive, etc.) that contain instructions for use in execution by a processor to perform the methods' operations and implement the systems described herein.
• The computer components, software modules, functions and data structures described herein may be connected directly or indirectly to each other in order to allow the flow of data needed for their operations. It is also noted that a module or processor includes but is not limited to a unit of code that performs a software operation, and can be implemented for example as a subroutine unit of code, or as a software function unit of code, or as an object (as in an object-oriented paradigm), or as an applet, or in a computer script language, or as another type of computer code.
• Various embodiments of the present invention having been thus described in detail by way of example, it will be apparent to those skilled in the art that variations and modifications may be made without departing from the invention. The invention includes all such variations and modifications as fall within the scope of the appended claims.
• A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by any one of the patent document or patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyrights whatsoever.

Claims (25)

1. A method for authenticating a user to a user device, the method comprising:

verifying, using authentication information stored at a user device, data received in association with a request for access to the user device and checking a status indicator stored at the user device and associated with the authentication information to determine whether the authentication information is valid;

allowing access to the user device if the data received in association with the request for access is verified and the status indicator indicates that the authentication information is valid; and

updating the status indicator on an intermittent basis when the user device is in communication with an authentication information status source.

2. The method ofclaim 1, wherein updating the status indicator is repeated at a first predetermined time interval, and further comprises:

if the user device is in communication with a network providing access to the authentication information status source,

transmitting a request for status information for the authentication information to the authentication information status source;

if a response to the request comprising status information is received, updating the status indicator with the received status information.

3. The method ofclaim 2, wherein updating the status indicator further comprises:

if a response to the request is not received, repeating the act of updating the status indicator after a second predetermined time interval shorter than the first predetermined time interval.

4. The method ofclaim 3, wherein updating the status indicator further comprises:

if a response to the repeated act of updating the status indicator is not received, further repeating the updating of the status indicator after a further predetermined time interval, wherein the further predetermined time interval is greater than the second predetermined time interval.

5. The method ofclaim 3, wherein if a response to the request is received in response to the repeated act of updating the status indicator, further repeating the updating of the status indicator at the first predetermined time interval.

6. The method ofclaim 4, wherein the further predetermined time interval is at least twice the duration of a previous predetermined time interval.

7. The method ofclaim 3, further comprising:

if the user device is not in communication with a network providing access to the authentication information status source,

intermittently attempting to transmit a request for status information for the authentication information to the authentication information status source at increasing time intervals until a response to the request is received.

8. The method ofclaim 1, wherein the authentication information comprises public key data, and wherein the act of verifying data received in association with a request for access to the user device further comprises:

providing an authentication token storing private key data;

transmitting a challenge to the authentication token;

receiving from the authentication token a response comprising the challenge signed using the private key data; and

verifying the response using the public key data, such that the user is authenticated if the response is verified and the status indicator indicates that the certificate comprising the public key data is valid.

9. The method ofclaim 8, wherein transmitting to and receiving from the authentication token are executed using an authentication token access device in communication with the user device and the authentication token, wherein the authentication token access device is separate from the user device.

10. The method ofclaim 9, wherein allowing access to the user device further comprises allowing said access if a user-entered password is also verified.

11. The method ofclaim 2, wherein if the status indicator indicates that the authentication information is not valid, further comprising denying the user access to the user device.

12. The method ofclaim 11, wherein the authentication information is valid if it is at least one of: not expired; either on hold or not revoked; or trusted.

13. The method ofclaim 12, wherein the authentication information comprises a certificate and wherein the status indicator comprises one of: a subset of a Certificate Revocation List and a response from a certificate status source.

14. The method ofclaim 12, wherein the status indicator comprises:

a timestamp indicating a latest time at which the status indicator had been refreshed, an identifier of an authentication information status source, and

status information associated with the authentication information.

15. A computer-readable medium comprising code executable by a computing device for causing said computing device to:

verify, using authentication information stored at a user device, data received in association with a request for access to the user device and checking a status indicator stored at the user device and associated with the authentication information to determine whether the authentication information is valid;

allow access to the user device if the data received in association with the request for access is verified and the status indicator indicates that the authentication information is valid; and

update the status indicator on an intermittent basis when the user device is in communication with an authentication information status source.

16. An authentication system for a user device, the authentication system comprising:

a memory storing authentication information for authenticating a user to the user device and for storing a status indicator comprising status information associated with the authentication information;

a status checking module for checking the status indicator stored in association with the authentication information, wherein the user is allowed access to the user device if the user is authenticated wherein the status indicator indicates that the authentication information is valid; and

an updating module for transmitting a request for status information for the authentication information to a authentication information status source periodically at a first predetermined time interval, receiving a response comprising status information in response to the request, and updating the stored status indicator with the received status information.

17. The authentication system ofclaim 20, wherein the updating module is configured to transmit a further request for status information at a further predetermined time interval if a response to a previous request is not received, wherein the further predetermined time interval is less than the first predetermined time interval.

18. The authentication system ofclaim 21, wherein a second further predetermined time interval is twice the duration of a first further predetermined time interval.

19. The authentication system ofclaim 20,

wherein the authentication information is a certificate comprising public key data, and

further comprising an authentication module, wherein the authentication module is configured to:

transmit a challenge to an authentication token,

receive from the authentication token a response comprising the challenge signed using private key data stored at the authentication token, and

verify the response using the public key data, such that the user is authenticated if the response is verified and the status indicator indicates that the certificate is valid.

20. The authentication system ofclaim 20, wherein the authentication module is configured to lock the user out of the user device if the stored status indicator indicates that the certificate used to authenticate the user is not valid.

21. The authentication system ofclaim 20, wherein the authentication module is configured to issue a user-invoked request for status information for the certificate to the certificate status source.

22. The authentication system ofclaim 20, wherein the certificate is valid if it is at least one of: not expired; either on hold or not revoked; or trusted.

23. The authentication system ofclaim 23, wherein the authentication module is further configured to verify a user-entered password, such that the user is authenticated if the response is verified, the status indicator indicates that the certificate is valid, and the user-entered password is also verified.

24. The authentication system ofclaim 20 wherein the authentication system is resident on a wireless communication device.

25. A method for managing secure access to a wireless communication device, the method comprising:

receiving a request to authenticate a security token;

determining, using authentication certificate status information, whether an authentication certificate is revoked, wherein the authentication certificate comprises public key data and wherein both the authentication certificate and the authentication certificate status information are locally stored at the wireless communication device;

authenticating the security token using the locally stored authentication certificate if the locally stored authentication certificate is determined to be not revoked; and

requesting authentication certificate status information from a remotely located certificate status source via a wireless communication link,

wherein the act of requesting authentication certificate status information is automatically performed periodically according to a predetermined time interval.

Images