Passwords may be used to secure computer systems and individual devices within a computer system from unauthorized access. A user may be required to remember multiple passwords to access and use a computer system.
In the following detailed description, reference is made to the accompanying drawings which form a part hereof, and in which is shown by way of illustration specific examples in which the disclosure may be practiced. It is to be understood that other examples may be utilized and structural or logical changes may be made without departing from the scope of the present disclosure. The following detailed description, therefore, is not to be taken in a limiting sense, and the scope of the present disclosure is defined by the appended claims. It is to be understood that features of the various examples described herein may be combined, in part or whole, with each other, unless specifically noted otherwise.
In a computer system including multiple machine-readable storage devices (e.g., memory or storage devices such as non-volatile dual in-line memory modules (NV-DIMMs), hard disk drives (HDDs), solid state drives (SSDs), flash memory cards (e.g., secure digital (SD) cards) and the like), each machine-readable storage device may require a separate passphrase (e.g., password or other string of characters and/or numbers) to be unlocked for read and/or write access at boot time to enable normal operation. Remembering and providing multiple passphrases when booting a computer system, however, may be difficult and inconvenient for a user.
Accordingly, as described herein, platform firmware (e.g., basic input/output system (BIOS) or unified extensible firmware interface (UEFI)) is used to transparently and securely unlock a plurality of machine-readable storage devices for read and/or write access at boot time in response to receiving a single user token (e.g., password, passphrase, digital certificate, biometric token, etc.). The user token is used to derive a key, which is used to decrypt a passphrase for each of the plurality of machine-readable storage devices. The decrypted passphrase for each of the plurality of machine-readable storage devices is then used to unlock the corresponding machine-readable storage device. In this way, multiple machine-readable storage devices may be securely unlocked at boot time using a single user token.
Platform firmware 104a may be based on BIOS, UEFI, or another suitable platform firmware architecture used to perform hardware initialization at boot time of system 100a. Platform firmware 104a includes a machine-readable storage medium 106 (e.g., a platform firmware storage area) storing a plurality of encrypted passphrases MP1 to MPN. Each passphrase MP1 to MPN corresponds to a machine-readable storage device 1121 to 112N, respectively. Machine-readable storage medium 106 may also store identifying information (e.g., serial numbers) for each machine-readable storage device 1121 to 112N associated with the encrypted passphrase for each machine-readable storage device 1121 to 112N, respectively, so that each passphrase may be reconciled with their respective device. In one example, each passphrase MP1 to MPN is encrypted using a key PWDK as indicated at 108 using symmetric encryption. In another example, each passphrase MP1 to MPN is encrypted using a public encryption key using asymmetric encryption. In this case, the private decryption key is encrypted using key PWDK 108 and stored in machine-readable storage medium 106. In either case, key PWDK 108 is not stored in machine-readable storage medium 106, but rather derived from the user token received on communication path 102.
At boot time, platform firmware 104a requests the user to provide their user token (e.g., password, passphrase, digital certificate, biometric token such as a fingerprint, etc.). At other times, such as on resumes from suspend and/or hibernate, platform firmware 104a may or may not request the user to again provide their user token depending on the configuration of platform firmware 104a. Using the user token, platform firmware 104a derives a key. In one example, platform firmware 104a derives the key by using a hash function. In other examples, any suitable method may be used to derive the key from the user token.
In response to a valid user token being provided and therefrom a valid key being derived (i.e., the derived key provides key PWDK 108), platform firmware 104a decrypts the encrypted passphrases MP1 to MPN stored in machine-readable storage medium 106 directly using key PWDK 108 (i.e., for symmetric encryption) or decrypts the encrypted private decryption key using key PWDK 108 and then decrypts the encrypted passphrases MP1 to MPN using the private decryption key (i.e., for asymmetric encryption). In response to an invalid user token being provided and therefrom an invalid key being derived (i.e., the derived key does not provide key PWDK 108), platform firmware 104a will be unable to decrypt the encrypted passphrases MP1 to MPN.
Once platform firmware 104a decrypts the encrypted passphrases MP1 to MPN, platform firmware 104a transmits each decrypted passphrase MP1 to MPN to the corresponding machine-readable storage device 1121 to 112N through communication paths 1101 to 110N, respectively. In response to receiving a valid passphrase, each machine-readable storage device 1121 to 112N is unlocked for read and/or write access. In one example, the same user token is used to unlock machine-readable storage devices 1121 to 112N and an operating system of system 100a at boot time.
In one example when using symmetric encryption, machine-readable storage medium 106 may store a plurality of encrypted passphrases for each machine-readable storage device 1121 to 112N, respectively. In this example, each of the plurality of encrypted passphrases for each machine-readable storage device 1121 to 112N corresponds to a different user token. Each valid user token is used to derive a corresponding key to decrypt the corresponding encrypted passphrases. In another example when using asymmetric encryption, multiple users may have access to the private decryption key by storing a different copy of the private decryption key in machine-readable storage medium 106 for each user, with each user's private decryption key encrypted with a different key PWDK 108 derived from the user's token. Therefore, platform firmware 104a may unlock machine-readable storage devices 1121 to 112N for read and/or write access by receiving any one of a plurality of valid user tokens.
Platform firmware 104b may be based on BIOS, UEFI, or another suitable platform firmware architecture used to perform hardware initialization at boot time of system 100b. Key management service 116 includes a machine-readable storage medium 118 storing a plurality of encrypted passphrases MP1 to MPN. Each passphrase MP1 to MPN corresponds to a machine-readable storage device 1121 to 112N, respectively. Machine-readable storage medium 118 may also store identifying information (e.g., serial numbers) for each machine-readable storage device 1121 to 112N associated with the encrypted passphrase for each machine-readable storage device 1121 to 112N, respectively, so that each passphrase may be reconciled with their respective device. In one example, each passphrase MP1 to MPN is encrypted using a key PWDK as indicated at 120 using symmetric encryption. In another example, each passphrase MP1 to MPN is encrypted using a public encryption key using asymmetric encryption. In this case, the private decryption key is encrypted using key PWDK 120 and stored in machine-readable storage medium 118. In either case, key PWDK 120 is not stored in machine-readable storage medium 118, but rather derived from the user token received on communication path 102.
At boot time, platform firmware 104b requests the user to provide their user token (e.g., password, passphrase, digital certificate, biometric token such as fingerprint, etc.). At other times, such as on resumes from suspend and/or hibernate, platform firmware 104b may or may not request the user to again provide their user token depending on the configuration of platform firmware 104b. In one example, using the user token, platform firmware 104b derives a key and transmits the key to key management service 116 through communication path 114. In another example, platform firmware 104b transmits the user token to key management service 116 through communication path 114 and key management service 116 derives a key. Platform firmware 104b or key management service 116 may derive the key by using a hash function. In other examples, any suitable method may be used to derive the key from the user token.
In response to a valid user token being provided and therefrom a valid key being derived (i.e., the derived key provides key PWDK 120), in one example, key management service 116 decrypts the encrypted passphrases MP1 to MPN stored in machine-readable storage medium 118 directly using key PWDK 120 (i.e., for symmetric encryption) or decrypts the encrypted private decryption key using key PWDK 120 and then decrypts the encrypted passphrases MP1 to MPN using the private decryption key (i.e., for asymmetric encryption). Key management service 116 then transmits the decrypted passphrases MP1 to MPN to platform firmware 104b through communication path 122. In another example, key management service 116 transmits the encrypted passphrases MP1 to MPN to platform firmware 104b through communication path 122 and platform firmware 104b decrypts the encrypted passphrases MP1 to MPN using key PWDK 120. In response to an invalid user token being provided and therefrom an invalid key being derived (i.e., the derived key does not provide key PWDK 120), platform firmware 104b and/or key management service 116 will be unable to decrypt the encrypted passphrases MP1 to MPN.
Once platform firmware 104b or key management service 116 decrypts the encrypted passphrases MP1 to MPN, platform firmware 104b transmits each decrypted passphrase MP1 to MPN to the corresponding machine-readable storage device 1121 to 112N through communication paths 1101 to 110N, respectively. In response to receiving a valid passphrase, each machine-readable storage device 1121 to 112N is unlocked for read and/or write access. In one example, the same user token is used to unlock machine-readable storage devices 1121 to 112N and an operating system of system 100b at boot time.
In one example when using symmetric encryption, machine-readable storage medium 118 may store a plurality of encrypted passphrases for each machine-readable storage device 1121 to 112N, respectively. In this example, each of the plurality of encrypted passphrases for each machine-readable storage device 1121 to 112N corresponds to a different user token. Each valid user token is used to derive a corresponding key to decrypt the corresponding encrypted passphrases. In another example when using asymmetric encryption, multiple users may have access to the private decryption key by storing a different copy of the private decryption key in machine-readable storage medium 118 for each user, with each user's private decryption key encrypted with a different key PWDK 120 derived from the user's token. Therefore, platform firmware 104b may unlock machine-readable storage devices 1121 to 112N for read and/or write access by receiving any one of a plurality of valid user tokens.
Processor 202 includes one or more central processing units (CPUs), microprocessors, and/or other suitable hardware devices for retrieval and execution of instructions stored in machine-readable storage medium 206. Machine-readable storage medium 206 may store data 208 including an encrypted passphrase for each of a plurality of machine-readable storage devices, such as machine-readable storage devices 1121 to 112N previously described and illustrated with reference to
Processor 202 may fetch, decode, and execute instructions 210-216 to unlock the plurality of machine-readable storage devices. Processor 202 may fetch, decode, and execute instructions 210 to receive a user token. In one example, the user token includes a password, a passphrase, a digital certificate, or a biometric token. Processor 202 may fetch, decode, and execute instructions 212 to derive a key from the user token. In one example, the key may be derived from the user token by using a hash function. Processor 202 may fetch, decode, and execute instructions 214 to decrypt the encrypted passphrase for each machine-readable storage device using the key. Processor 202 may fetch, decode, and execute instructions 216 to unlock each of the plurality of machine-readable storage devices using the decrypted passphrase corresponding to each machine-readable storage device. In one example, each machine-readable storage device includes a NV-DIMM, a HDD, a SSD, or a flash memory card.
As an alternative or in addition to retrieving and executing instructions, processor 202 may include one or more electronic circuits comprising a number of electronic components for performing the functionality of one or more of the instructions in machine-readable storage medium 206. With respect to the executable instruction representations (e.g., boxes) described and illustrated herein, it should be understood that part or all of the executable instructions and/or electronic circuits included within one box may, in alternate examples, be included in a different box illustrated in the figures or in a different box not shown.
Machine-readable storage medium 206 is a non-transitory storage medium and may be any suitable electronic, magnetic, optical, or other physical storage device that stores executable instructions. Thus, machine-readable storage medium 206 may be, for example, random access memory (RAM), an electrically-erasable programmable read-only memory (EEPROM), a storage drive, an optical disc, and the like. Machine-readable storage medium 206 may be disposed within system 200, as illustrated in
Although specific examples have been illustrated and described herein, a variety of alternate and/or equivalent implementations may be substituted for the specific examples shown and described without departing from the scope of the present disclosure. This application is intended to cover any adaptations or variations of the specific examples discussed herein. Therefore, it is intended that this disclosure be limited only by the claims and the equivalents thereof.
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/US2016/044710 | 7/29/2016 | WO | 00 |