Patent Application
20130219166
To gain access to the ever-growing number of websites that are available to users of communication devices, users often need to establish unique user IDs and passwords for each service that is to be provided. For instance, in many e-commerce environments, an active computer user may have several different accounts with different on-line vendors. For example, a user can have one account with an on-line bank, another account with an on-line travel agent, and further accounts with other service providers, such as a bill paying service, on-line retailer, on-line auction site, and so on. In order to ensure maximum security, a user should select different user ID names and passwords for each different account. In this manner, each separate account is protected in the event that the user ID and password for one account is discovered by an unauthorized third party.
However, maintaining different user identifiers and passwords can become difficult and cumbersome for users who interact with several different on-line sites. Without a convenient system for managing these different passwords and access codes, users may simply adopt a single user ID and password for all of their different accounts and applications. This severely compromises the security of these accounts, since a person who breaks the password for one account can then often access the user's other accounts.
Password managers are often used to address this problem by storing the user's various account credentials. Because of the valuable information they store, password managers can be attractive targets for attackers. To address this security concern, password managers often employ a master password, which is used to protect all the account credentials. The master password is used to derive a key which is used to encrypt the password manager's store.
The design of a password manager involves a tradeoff between security and usability. Prompting a user to enter his master password every time credentials are needed for a particular account would amount to an unpleasant user experience, particularly for password managers used on smartphones, where entering passwords can be burdensome. For this reason the user is generally asked only once for the master password. From that point on the password is kept in the clear in the device's main memory. As a consequence, however, if the device is stolen or lost, a malicious party that misappropriated the device can extract the password by taking a snapshot of the device's main memory. Once the master password is obtained, the malicious party can decrypt the password manager's store and obtain all the account credentials stored in it.
One way to address this problem is make the master password the same as the login password for the device itself. If the device is configured to enter a sleep mode after short period of inactivity, the password store will be encrypted and the master password will be securely deleted from main memory. When the device wakes up, the user once again provides the login password, thereby also providing the master password, which can be used to decrypt the password store. In this way the master password is only in the clear when the device is in an active state. If the period of inactivity that needs to elapse before the device goes to sleep is kept relatively short, the likelihood of the master password being misappropriated can be significantly reduced. However, even if the master password is not in the clear, it can potentially still be obtained by an attacker in other ways. For instance a simple dictionary attack can sometimes succeed since users often choose passwords that are valid, or close to valid, dictionary words.
As detailed below, an identity management system is provided which employs secure, tamper-resistant hardware. The secure hardware is leveraged for encryption of the account credentials as well as for secure authentication of a user to a server. Instead of a password, the identity management system makes use of digital certificates for client authentication. Significantly, the system only exposes account credentials in the clear a single time, which is when the user is initially requested to provide his or her credentials for a specific account.
The server 240 may be implemented by one or more computing devices arranged to provide the functionality described herein. For example, the server 240 can be implemented as an application instantiated on a suitable processing device, for example on a web server, a network server, at a mobile switching center (MSC), on a base station controller (BSC), or on any other suitable node of the communications network 250. The server 240 can receive from the client devices 210, 220 and 230 requests for access to any of myriad of different services that may be offered by server 240. Such services may involve, by way of illustration only and not as a limitation on the subject matter disclosed herein, computation, software, data access and data storage. Services enabled by the aforementioned products, services and solutions may include, for instance, shopping, banking, selling and collaborating as well as communication and entertainment services.
Client devices 210, 220 and 230 may be any network-enabled device that can communicate with the server 240 over communication network 250. For example, client devices 210, 220 and 230 may be, without limitation, a PC, laptop, netbook, tablet, television, gaming device, landline or wireless telephone, smart phone, media device, alarm clock, kitchen appliance or other dedicated appliance. In
In some examples the mobile device 210 is a mobile communications device such as a wireless telephone that also contains other functions, such as PDA and/or music player functions. To that end the device may support any of a variety of applications, such as a telephone application, a video conferencing application, an e-mail application, an instant messaging application, a blogging application, a digital camera application, a digital video camera application, a web browsing application, a digital music player application, and/or a digital video player application. In some implementations the mobile device 210 may correspond to a mobile device of the type that will be described below in connection with
The client device 400 also can include a communications interface 410 for communicating over communication network 250. In the event that the client device 400 wirelessly communicates over communication network 250, communications interface 410 may comprise a transceiver having one or more wireless transmitters and receivers that can modulate and demodulate signals to convert signals from one form to another, and can transmit and/or receive such signals over one or more various wireless communication networks. In illustration, the communications interface 410, and in particular the transceiver, can be configured to communicate data via IEEE 802 wireless communications, for example, 802.11 and 802.16 (WiMax), WPA, or WPA2. In another example, the transceiver can communicate data via GSM, TDMA, CDMA, WCDMA, OFDM, or direct wireless communication. Further, the transceiver also can be configured to communicate over a wireless communication link using any of a myriad of communications protocols, for example, TCP/IP. In operation, the transceiver can transmit requests generated by the mobile station and receive responses from the location-based services server.
The client device 400 also can include a user interface 420 comprising one or more tactile input devices 425 and a display 430. The tactile input devices 425 can comprise one or more buttons, keys, soft keys, sensors, or any other devices suitable for receiving a tactile user input. The display 430 can be a liquid crystal display (LCD), a liquid crystal on silicon (LCOS) display, a cathode ray tube (CRT), a plasma display, or any other suitable display. In one arrangement, the display 430 can comprise a touch screen that can receive tactile and/or stylus inputs and communicate such inputs to the processor 405. The tactile input devices 425 and/or display 430 can receive user inputs to establish user preferences, receive user selections, or perform any other suitable electronic device functions and allows a user to interact with applications 450 maintained in the data storage 415, including applications that are usable to permit the user to access a user account maintained on or in association with server 240, as described in greater detail below.
The user interface 420 further can include an audio processor 435 connected to an input audio transducer 440 (e.g. microphone) and an output audio transducer 445 (e.g. loudspeaker). The audio processor 435 can be integrated with the processor 405 or provided as a separate component that is communicatively linked to the processor 405. The audio processor 435 can comprise a CPU, a DSP, an ASIC, a PLD, a plurality of discrete components that cooperate to process audio data, and/or any other suitable audio processing device.
The audio processor 435 can receive output audio signals from the processor 405 and communicate such signals to the output audio transducer 445. Similarly, the audio processor 435 can receive input audio signals from the input audio transducer 440 and communicate such signals to the processor 405. In one arrangement, speech recognition can be implemented to process such signals. For example, the audio processor 435 can execute a speech recognition application to process audio signals containing user inputs that are received from the user.
Further, additional devices (not show) can be components of the user interface 420. For instance, the user interface 420 also can include a headset, a speakerphone, or other device(s) communicatively linked to the client device 400 via the transceiver 410, a second transceiver, and/or the communications port.
The data storage 415 can include one or more storage devices, each of which can include, but is not limited to, a magnetic storage medium, an electronic storage medium, an optical storage medium, a magneto-optical storage medium, and/or any other storage medium suitable for storing digital information. In one arrangement, the data storage 415 can be integrated into the processor 405, though this need not be the case.
The operating system 426 (e.g., Darwin, RTXC, LINUX, UNIX, OS X, Microsoft WINDOWS, Android or an embedded operating system such as VxWorks) may be contained in the data storage 415. The operating system 426 includes various software components and/or drivers for controlling and managing general system tasks (e.g., memory management, storage device control, power management, etc.) and facilitates communication between various hardware and software components.
Applications 450 such as one or more of the applications mentioned herein may also be contained in data storage 415. In addition, the data storage 415 may also contain a hardware-based identity manager (HIM) 440. The processor 405 can execute the applications 450, HIM 440 and operating system 426 to implement the processes and methods respectively allocated to them. For example, HIM 440 may be used instead of a password manager to authenticate the client device 400 to a server, such as server 240 in
One example of the secure hardware module 460 is shown in
In
As a preliminary matter, when first establishing an account with a server (e.g., server 240), a user of client device 400 generally authenticates him or herself with a username and password. In response, the server generates a digital certificate linked to the client device and an associated private key 580. The server sends the digital certificate and private key to the client device, effectively exchanging the private key for the password supplied by the user.
The receipt of the private key 580 by the client device represents the only time that the private key is maintained on the client device in the clear. As shown by the process flow indicated by the arrow in
Also shown in the memory 560 of the secure module 460 is a secure key 482. Secure key 582 is a key such as an Advanced Encryption Standard (AES) key that may be randomly generated by the HIM 440 when initializing the secure module 460. The secure key 582 is maintained in the secure module 460 at all times and thus is not even accessible to an administrator or root user of the operating system 426. The processor 551 in the secure module 460 encrypts the private key 580 using the secure key 582 to produce an encrypted private key 584 and transfers the encrypted private key to the HIM 440. The private key 580 then may be deleted from the memory of the secure module 460. Accordingly, the client device 400 only maintains the private key 480 in encrypted form and, as shown below, only decrypts it when necessary in the secure module 460 so that it is at no times accessible to an individual.
Once the HIM 440 has stored the encrypted private key along with its associated digital certificate, the client device 400 has the credentials it needs to subsequently access the server 240 without use of a password.
The process by which the client device establishes communication with the server using the certificate and private key as authentication credentials involves establishing a secure connection in which two-way authentication is employed. In two-way authentication the server authenticates itself to the client device and the client device authenticates itself to the server. Although a wide variety of secure protocols may be employed, the Transport Layer Security (TLS) protocol will be illustrated by way of example. The TLS protocol is a commonly used protocol for managing the security of message transmission over the Internet and other communication networks.
The TLS protocol uses a combination of public-key and symmetric key encryption. The TLS protocol includes a TLS handshake protocol to exchange a series of messages between the server and the client when they first establish a TLS connection. The TLS handshake allows the server to authenticate itself to the client and the client to authenticate itself to the server using public-key techniques, and then allows the client and the server to cooperate in the creation of symmetric keys used for encryption, decryption, and tamper detection during the ensuing TLS session. Once the TLS handshake has been completed the client device and server will have established an encryption algorithm and exchanged cryptographic keys which can be used to encrypt and decrypt data during a communication session.
One illustrative example of the TLS message exchange process between a client device and server is shown in
As shown in
Server 604 responds with a ServerHello 608, containing the chosen protocol version, a random message such as a random number, cipher suite, and compression method from choices offered by client device 602. Server 604 also sends its digital certificate 610. The server's digital certificate 610 may include the server's name, a trusted certificate authority (CA), and the server's public encryption key. Server 604 also requests, for example by use of a CertificateRequest 612, a certificate from client device 602 so that the connection can be mutually authenticated. The CertificateRequest 612 also requests that client device 602 return a digitally signed random message, and in particular a digitally signed copy of the random number sent to the client device in ServerHello 608. The random message is to be signed using the client device's private key 580, and in particular a private key associated with the appropriate account on server 604. Server 604 sends a ServerHelloDone message 614, indicating that it has completed the handshake negotiation. In response, client device 602 sends a client certificate and the digitally signed random message 616 to server 604.
In order to sign the random message from the server, the client device 602 decrypts its private key within its secure module 460 and uses the private key to sign the message, also within the secure module. Additional details concerning the manner in which client device 602 decrypts its signed key and signs the random message from the server will be discussed below, after completing the discussion of the illustrative TLS message exchange process.
After server 604 has authenticated client device 602 and client device 602 has authenticated server 604 in the manner described above, the TLS message exchange process continues with a TLS negotiation 618 between client device 602 and server 604. This process may involve client device 602 sending a ClientKeyExchange message, which may contain a PreMasterSecret and a public key, and client device 602 and server 604 use the PreMasterSecret to compute a common secret, called the “master secret.” All other key data is derived from this master secret (and client- and server-generated random values), which is passed through a “pseudorandom function.” The client device then sends a ChangeCipherSpec message, essentially telling the Server, “Everything I tell you from now on will be encrypted.”
The manner in which client device 602 signs the random message received from server 604 will be illustrated with reference to the client architecture 200 discussed above in connection with
Next, at step 704.1, the secure module 460 decrypts the encrypted private key using the secure key 482 stored in its secure memory. The secure module 460 then uses the decrypted private key to sign the random message, at step 704.2. The secure module 460 provides the signed random message to HIM 440 (typically via operating system 426). Thus, at no time is the encrypted private key available in decrypted form outside of the secure module 460. HIM 440, in turn, passes the signed random message to the appropriate application, at step 706. Finally, at step 707, the application sends the signing random message, along with the associated digital certificate, to the server, thereby providing the server with the authentication credentials needed to access the client account associated with the server.
As
In the examples described above the HIM is implemented on the client device that is to access the user account on the server. However, in some implementations a client device equipped with a HIM can be used by a second client device so that the second client device can access the user account on the server. Referring now to
After receiving the random message from the second client device 820, the first client device 810 signs the message in the manner described above and then passes the signed message back to the second client device 820, at step 803. The first client device 810 may also optionally send the appropriate digital certificate to the second client device 820. The second client device 820, in turn, sends the signed message and the digital certificate (which it obtained from the first client device 810 or which it stores locally) to the server 830, at step 804. In this way the second client device 820 provides the necessary authorization credentials used to access the user account on the server 830.
The processes described above, including but not limited to those shown in
Although various embodiments are specifically illustrated and described herein, it will be appreciated that modifications and variations of the present invention are covered by the above teachings and are within the purview of the appended claims without departing from the spirit and intended scope of the invention.
