The last week, another of the patent applications related to my papers received a grant. This research proposes a methodology to encrypt the content of a device (for instance, a laptop) without storing any keys on the device itself. The keys, or rather a piece of information (the message) needed to compute keys, are stored in another device (the smartphone). A new message is generated every time the content of the laptop is encrypted, so that every set of keys is used only once.
The patented invention describes a new method to securely encrypt data on any personal electronic device including (but not limited to) PCs, laptop computers, and tablets. The method employs the technique for sharing a secret value between two nodes as described in our patent entitled ‘Determining a common secret for two nodes’.
The concept is that we can allow a trusted device (or even a set of devices) that are trusted and authenticated (such as a mobile phone with biometrics) to act as an authentication and a key-management system. This can be directly integrated into a Bitcoin wallet, and the same keys can be used as a secure method both to authenticate to servers and devices, and as a means to incentivise security in the habits of people generally.
Data encryption on personal devices such as laptops or PCs is intended to protect the hard-disk data in the event that the device is lost or stolen. Existing methods suffer from a variety of drawbacks. For example, to decrypt the hard disk the user might need to enter a secret such as a PIN or passphrase. However, short codes such as the typically 4–8-character PINs can easily be broken by a hacker who has physical possession of the device and plenty of time to try common combinations.
Passphrases are much more secure, but these depend on the user memorising a lengthy set of code words or a long sentence.
A much more secure process involves the use of a cryptographic key, for instance by plugging in a USB drive. Even this method, however, has security vulnerabilities. Despite the direct physical connection between the USB drive and the device, the transmitted secret can still be intercepted due to the electromagnetic signals generated during transmission (e.g. via power analysis) [Ref. 1].
The present method overcomes this problem by enabling the personal device to calculate the secret based on transmission of only non-secret information by an authenticated user.
The key elements of the invention are as follows:
1. The encryption/decryption key is a full-strength cryptographic key (e.g. AES256) that is never passed between user and device. Instead, the key is recalculated when needed after authenticating the user’s key ring. The encryption key is used for only one encryption/decryption cycle. A new key is calculated for each cycle.
2. The method uses the secret-key-sharing protocol described in our paper ‘Determining a common secret for two nodes’ (henceforth abbreviated to DCS — Determining a Common Secret).
Exclusions
- The actual encryption/decryption process employs existing standards and is not described in this post.
- Protocols for handling interruptions to the communications (e.g. disconnected cable) are not described in this post.
Technical Description
In the following description reference is made to the DCS. For consistency, the same terminology is used here as in the DCS, as follows:
- PED (‘Server’) Master Private key = VMS (kept secret by the PED)
- PED (‘Server’) Master Public key = PMS (non-secret)
- Key-ring (‘Client’) Master Private key = VMC (kept secret by the Key-ring)
- Key-ring (‘Client’) Master Public key = PMC (non-secret)
The description is by way of an example assuming that the PED is a laptop running the software, and the Key-ring is a smartphone running the app.
Initialisation (refer to DCS ‘registration’ for more details)
The initialisation phase begins with a fully unencrypted laptop onto which the software has been downloaded and installed (into a partition that will remain unencrypted). The compatible smartphone-app version of the software has been installed on the smartphone; by ‘compatible’ we mean the same ECC standard (for example secp256k1) with a common set of parameters including the generator G is used on both devices, and the software on each device uses a common protocol as described herein. The ECC parameters are permanently stored on each device (these need not to be kept secure).
1. The laptop and smartphone are connected. This is done either by a cable or by a wireless protocol such as Bluetooth. The laptop software (= the Software) establishes contact with the smartphone app (= the App) and verifies by exchange of appropriate signals that the software versions are compatible and in sync.
— Note: All existing security measures are assumed to be in effect. I.e., the smartphone has been unlocked by the user’s security code and the user has logged in to the laptop with password in the usual way.
2. The laptop software and the smartphone app both independently generate their own public/private key pairs based on G. This initial generation of keys are the master keys. The private keys (VMS and VMC) are each kept secure on the relevant owning device. The public keys (PMS and PMC) are each transmitted to the other device. Each device permanently saves the three master keys (their own private/public keys + other device’s public key).
3. The laptop creates a new message ‘Mn’ (n = new) and uses a standard algorithm to create a hash of the message resulting in a 256-bit integer:
- Message = Mn (Hash160 of a randomly generated number)[A.1]
- Message Hash = SHA-256(Mn)
Initialisation continues through to the end of the first encryption phase. From then on each session is composed of a decryption phase at the beginning and an encryption phase at the end.
[A.1] The choice of message is arbitrary for the purposes of generating the encryption key but needs to be new for each cycle. The message is reduced to 160 bits by hashing in order to keep the message length short.
Encryption
4. The laptop software uses Mn to recalculate its own next generation private/public key pair and the smartphone’s new public key:
- Laptop’s new Private key = VnS = VMS + SHA-256(Mn)
- Laptop’s new Public key = PnS = PMS + SHA-256(Mn) X G
- Smartphone’s new Public key = PnC = PMC + SHA-256(Mn) X G
5. The Software can now calculate a (new) secret Sn:
- Software calculates Sn = VnS X PnC
(Note: the App could also calculate this secret, as in DCS. However, in the present invention only the Software is required to derive this value).
6. In the present example, the secret Sn is not used as the encryption key, although in some variations it could be (see variation 1). In the present example, the laptop’s serial number is encoded within the encryption key to ensure that it is specific only to this laptop. The encryption key E is calculated as follows:
- E = SHA256(SHA256(salt + Sn) + serial-number)
Where
- Salt = Mn (for explanation of cryptographic salt see [Ref. 2])
7. As part of the log-off and shut-down processes, the Software encrypts the disk. The encryption key E is not stored anywhere, and message Mn is not stored on the laptop. The message Mn is securely stored on the smartphone for use in the next session to decrypt the hard drive.
Decryption
8. The laptop and smartphone are connected. This is done either by a cable or by a wireless protocol such as Bluetooth. The laptop software establishes contact with the smartphone app and verifies by exchange of appropriate signals that the software versions are compatible and in sync.
(Note: this step is identical to step 1 in the initialisation phase.)
9. For app authentication the laptop creates a new message ‘Mn’. Mn will be used for authentication in the current decryption phase and will also be used for encryption in the subsequent encryption phase. This value is newly created and different to the previously created message that was stored on the smartphone at the end of the encryption phase. To distinguish the two, the previously stored message will be referred to as Mo (o = ‘old’). The laptop sends Mn to the smartphone and uses a standard algorithm to create a hash of the message resulting in a 256-bit integer:
- Message = Mn (Hash160 of a randomly generated number)
- Message Hash = SHA-256(Mn)
10. The smartphone app first calculates a new generation of private/public key pair based on the value of Mn (refer to DCS for details):
- Smartphone’s new Private key = VnC = VMC + SHA-256(Mn)
- Smartphone’s new Public key = PnC = PMC + SHA-256(Mn) X G
11. The App then signs Mn with its new private key and sends back to the laptop software:
- Signed message = Sig-VnC <Mn>
12. As in DCS, the Software authenticates the App by verifying the signed message. It does this by independently calculating the App’s new public key (PnC) using the formula in (10) and then performing a standard ECDSA check between Sig-VnC <Mn> and PnC.
13. Having established the App’s credentials, the Software now sends a request to the App for the ‘old’ message Mo that was securely stored exclusively on the smartphone during the previous encryption phase. For added security, the App signs Mo with its new generation of private key and sends the signed message back to the Software: Sig-VnC <Mo>. The Software can verify the signature and retrieve Mo in the usual way.
14. The message Mo is associated with the laptop’s and smartphone’s previous generation of public/private key pairs — i.e. the keys that were generated in the previous encryption cycle. The laptop is able to now recalculate those keys and hence also recalculate the secret S and the Encryption key.
15. The recalculated encryption key is used to decrypt the disk and the user may now operate the laptop as usual. The newly created message Mn is retained in memory for the duration of the session, which will end with an encryption phase when the user logs off, restarts, or shuts down (etc.).
Variation 1: Encryption Key = Secret Key S
In some scenarios it may not be necessary or feasible to embed the serial number into the encryption key — for example, where the PED is a device type that does not have an accessible serial number. In such cases the secret Sn itself can be used as the encryption key.
Variation 2: Folder/File encryption
A variation is the encryption of individual files or folders. The PED and Key-ring applications can be designed to prompt the user for which files/folders to encrypt. For each individual file/folder a new salt (message Mn) will be generated from which a file/folder-specific encryption key will be derived. In this case, the Key-ring application will securely store a table linking the unique file/folder ID to the associated message. As for disk encryption, the encryption key is valid for only one cycle, so a new encryption key is calculated for every new cycle (i.e. the relevant stored message Mn is replaced on the table after each session in which the file/folder has been accessed).