Implementing enhanced computer security standard for secure cryptographic key storage using a software-based keystore

A client device that is not originally compliant with a particular security standard (e.g., FIPS) is brought into compliance through the addition of a standard-compliant software-based cryptographic library. In order to adapt the cryptographic library to integrate with the hardware-backed keystore, a non-hardware-backed software keystore is used to store keys used by the cryptographic library. Additionally, in order to provide appropriate security for the software keystore, the software keystore (and/or the keypairs within the software keystore) is protected by a password, and the password is in turn protected by the hardware-backed keystore. Thus, to obtain the password needed to obtain a keypair from the software keystore that is in turn needed to use the cryptographic library, a user must authenticate with the operating system, e.g., by providing biometric credentials.

FIELD OF ART

The present invention generally relates to the field of software systems, and more particularly, to implementation of cryptographic standards on devices not natively complying with those standards.

BACKGROUND

There exist a number of security standards for safely implementing certain types of cryptographic or other security operations. Such standards include the Federal Information Processing Standards (FIPS), and the Federal Risk and Authorization Management Program (FedRAMP). Certain entities, such as the federal government of the United States, may require that organizations comply with these standards in order to exchange data with those entities. Thus, in such instances compliance with the standard in question is beneficial from the perspective both of security and of qualifying for interoperation with such entities.

Some commercially-available devices satisfy the standard(s) in question without additional modification due to the hardware and software that they possess. However, others may fail to satisfy the standards. For example, certain smartphone devices—such as many models using the Android™ operating system—fail to satisfy the FIPS standard, even when they have features such as hardware-backed keystores that provide hardware support for secure storage of digital keys.

SUMMARY

A client device that is not originally compliant with a particular security standard (e.g., FIPS) is brought into compliance through the addition of a standard-compliant software-based cryptographic library. In order to adapt the cryptographic library to integrate with the hardware-backed keystore, a non-hardware-backed software keystore is used to store keys used by the cryptographic library. Additionally, in order to provide appropriate security for the software keystore, the software keystore (and/or the keypairs within the software keystore) is protected by a password, and the password is in turn protected by the hardware-backed keystore. Thus, to obtain the password needed to obtain a keypair from the software keystore that is in turn needed to use the cryptographic library, a user must authenticate with the operating system, e.g., by providing biometric credentials.

The keypairs can then be used for cryptographic operations. For example, in the context of a client device obtaining access to a resource protected by an authentication flow, the commencement of the authentication flow causes the client device to perform the above-described operations to unlock a keypair from the software keystore. With the keypair unlocked, the standard-compliant library can use the keypair to perform cryptographic operations such as signing/verifying, and encrypting/decrypting, as needed within the authentication flow in order to be authenticated and granted access to the resource.

DETAILED DESCRIPTION

FIG.1illustrates one embodiment of a computing environment in which users use client computing devices to obtain access to authenticated resources over a network, according to some embodiments. The users are affiliated with an organization (e.g., employees or volunteers of the organization) and may access the resources on behalf of the organization. The users may have multiple accounts on different systems, and the resources that the users access may be owned and/or administered by different independent entities, such that the users may have a number of different identities—and corresponding credentials—across the different systems. The different accounts may provide the users with access to different resources, such as (for example) applications (e.g., email applications, timekeeping applications, spreadsheet applications, etc.), databases, file systems, or the like. Such applications could be, for example, entirely web-based and accessible through a web browser, or could be accessible through a native application installed on the user's client device and communicating with a remote application server. Since each application or other resource could be from a different provider each of which could have a different identity for a user—a single user will typically have many different identities and associated credentials corresponding to the different resources that the user uses. However, for purposes of the invention, a user need only have a single account with a single corresponding identity.

The organization120is an entity, such as a business, a school, a governmental agency, or the like, that has a number of affiliated users131, such as employees or volunteers. One or more client devices121(such as client device121are registered to the users131by the organization120(or, in some embodiments, inferred from observation of past successful login patterns), and the users use the client devices to access resources associated with the organization. Although for simplicityFIG.1illustrates only a single user131and client device121, there may be any number of either.

The resource server130provides access to a resource, such as a web-based application (e.g., MICROSOFT OFFICE 365™), a service, a database, a document, or the like. The resource server130may be on a server separate from the system of the organization120(as illustrated inFIG.1), or it may be part of the organization120. The resource server130requires authentication of users before the users may gain access to some or all of its resources.

Physically, the organization120is made up of a number of computing systems, including the various client devices121; one or more internal networks that connects the computing systems, including routers or other networking devices that define the boundary between the organization and external networks; and the like.

The network140may be any suitable communications network for data transmission. In an embodiment such as that illustrated inFIG.1, the network140uses standard communications technologies and/or protocols and can include the Internet. In another embodiment, the entities use custom and/or dedicated data communications technologies.

The client device121can be any device lacking out-of-the-box compliance with a particular security standard (e.g., FIPS). This could include certain models of smartphones, tablets, laptops, desktops, and the like.

The client device has a number of components that interoperate to securely obtain access to cryptographic keys, including an operating system authenticator122, an operating system keystore128, a software keystore126, authentication software124, and a standards-compliant cryptographic library125. These components are now described in additional detail.

The operating system authenticator122is part of the operating system of the client device121and provides authentication of the identity of the user. In some embodiments, the authenticator122authenticates the user using biometrics (e.g., analysis of fingerprints, facial recognition, or voice recognition), passwords, and/or one-time passwords (OTPs), or the like.

The operating system keystore128is established by the operating system of the client device121and uses hardware support of the client device. That is, the keystore128is hardware-backed, so that keys stored within the keystore128are not directly accessible from outside the keystore128, and even if the client device data is cloned, the keys in the keystore128will still not leave the device.

The software keystore126, in contrast to the operating system keystore128, is not hardware-backed. In some embodiments, the software keystore126is implemented as a file within the file system of the operating system. In some embodiments, the individual keypairs within the software keystore126are each stored in encrypted form, protected by a corresponding password for that keypair. In some embodiments, the file implementing the software keystore126is instead or additionally encrypted as a whole according to a password so that its contents are unobtainable without the password. In some embodiments (e.g., such as those in which the operating system is a version of Android™), the software keystore126is implemented as a Java™ KeyStore object that is serialized to and from disk.

The standards-compliant cryptographic library125implements the security standard(s) of the embodiments in question (e.g., FIPS). The library125is implemented in software and uses the keys stored in the software keystore126, which must therefore be unlocked/unencrypted using the password in order for the keys to be available to the library125. In one embodiment, SafeLogic™ CryptoComply™, which satisfies the FIPS 140 standard, is used to implement the library125, though different implementations may be used in different embodiments. In some embodiments, a multi-tenant authentication server provides identity/authentication services to multiple tenant organizations (including the organization120), and each tenant organization may use its own implementation of the library125, authored either by itself or by a third party.

Authentication software124on the client device(s)121facilitates the process of securely obtaining cryptographic keypairs from storage by controlling interactions among the other components of the client device121. In some embodiments, the authentication software124is part of a locally-installed application, such as Okta™ Verify™ from Okta™, Inc. In such embodiments, the authenticator application may have a graphical user interface that the user131uses to specify data used to authenticate the user to an authentication system. In other embodiments, the authentication software124is implemented as a plugin for another application. The authentication software124may additionally use the standards-compliant cryptographic library125to perform cryptographic operations as part of an authentication process, once the necessary cryptographic keypair has been retrieved from the software keystore126.

FIG.2illustrates interactions between the components of the client device121when securely obtaining a keypair from the software keystore126as directed by the authentication software124, according to one embodiment.

At the start of the interactions, the software keystore126stores an authentication key127, among other keypairs. Since the keys/keypairs and/or the software keystore126itself have been password-protected (encrypted), the authentication key127is not available until the password has been supplied and the authentication key127accordingly unlocked. An encrypted form of the password for the software keystore126is stored in a database205(e.g., a SQLite database) within the operating system filesystem. In one embodiment, the database205stores, for each of the keypairs that are protected within the software keystore126: a software keystore key reference (a key alias), an encrypted form of a password required to fetch the key alias from the software keystore126, and a hardware keystore key alias for decrypting the encrypted password. Similarly, the hardware-backed operating system keystore128stores secure decryption key129. In embodiments in which symmetric key encryption is used for encrypting the password, the decryption key129can be the symmetric key itself as used for password encryption, since symmetric keys are readily invertible; in embodiments in which asymmetric key encryption is used, the decryption key129is the inverse (e.g., the private key) of the key used for encryption. The authentication software124needs to obtain a keypair corresponding to a user131and/or the user's device121in order to conduct cryptographic operations on behalf of the user. For example, the sequence of interactions ofFIG.2could have been triggered by the user131requesting access to a resource on the resource server130, leading to an authentication flow (e.g., via a security protocol such as OAuth) in which the authentication software124will need to conduct cryptographic operations on behalf of the user, using the standards-compliant cryptographic library125.

The authentication software124requests205the encrypted form of the password for the software keystore126from the database205(e.g., by specifying an ID of the user/device corresponding to the keypair), which provides it in step210. The database205may also provide a reference (key alias) to the secure decryption key stored in the operating system keystore128in order to indicate which specific keypair/key is to be used to decrypt the password, and a reference to the keypair in the software keystore126to be decrypted.

The authentication software124requests215the decrypted form of the password from the hardware-backed keystore128(e.g., by specifying the reference to the secure decryption key). Assuming that the user131has not yet been authenticated by the operating system authenticator122, the operating system keystore128reports220that obtaining the decrypted key has failed.

The authentication software124, upon receipt of the failure report220, accordingly prompts225the user for verification, e.g., using a system call of the operating system to request biometric credentials. The user provides230the credentials (e.g., by scanning the user's fingerprint).

The authentication software124then again requests235the decrypted form of the password. Assuming that the credentials provided in step230were legitimate and that the operating system used them to successfully authenticate the user, the OS keystore128this time decrypts the encrypted password for the software keystore126and returns240the decrypted password to the authentication software124. The request235may include the reference to the secure decryption key so that the operating system keystore128can determine which key to use to decrypt the password.

The authentication software124requests245a keypair for the user131from the software keystore126, using the password to decrypt the software keystore126so that the keypair is no longer encrypted. The software keystore accordingly returns250the requested keypair in unencrypted form.

With the keypair for the user obtained at step250, the authentication software124can use it to perform any needed cryptographic operations. For example, the standards-compliant cryptographic library125can be called by the authentication software124to perform digital signature operations (using the obtained keypair) as part of an OAuth flow for accessing a resource.

Note that although the interactions ofFIG.2were described as occurring in a particular order, variations are possible in different embodiments, such as alteration of the order, performing operations in parallel rather than strictly sequentially, and the like.

Further note that although the above examples have described the inventive operations within the context of the client device121of an organization obtaining access to a resource on a resource server130, the inventive operations may also be used in other contexts. More generally, the inventive operations may be used in any context in which a non-standard-compliant client device having a hardware-backed keystore is desired to achieve compliance with the standard.

FIG.3is a high-level block diagram illustrating physical components of a computer300used as part or all of (for example) the client device121ofFIG.1, according to one embodiment. Illustrated are at least one processor302coupled to a chipset304. Also coupled to the chipset304are a memory306, a storage device308, a graphics adapter312, and a network adapter316. A display318is coupled to the graphics adapter312. In one embodiment, the functionality of the chipset304is provided by a memory controller hub320and an I/O controller hub322. In another embodiment, the memory306is coupled directly to the processor302instead of the chipset304.

The storage device308is any non-transitory computer-readable storage medium, such as a hard drive, compact disk read-only memory (CD-ROM), DVD, or a solid-state memory device. The memory306holds instructions and data used by the processor302. The graphics adapter312displays images and other information on the display318. The network adapter316couples the computer300to a local or wide area network.

As is known in the art, a computer300can have different and/or other components than those shown inFIG.3. In addition, the computer300can lack certain illustrated components. In one embodiment, a computer300acting as a server may lack a graphics adapter312, and/or display318, as well as a keyboard310or pointing device314. Moreover, the storage device308can be local and/or remote from the computer300(such as embodied within a storage area network (SAN)).

As is known in the art, the computer300is adapted to execute computer program modules for providing functionality described herein. As used herein, the term “module” refers to computer program logic utilized to provide the specified functionality. Thus, a module can be implemented in hardware, firmware, and/or software. In one embodiment, program modules are stored on the storage device308, loaded into the memory306, and executed by the processor302.

Other Considerations