In today’s instalment of business ideas that can be created using IP nChain has developed, I will detail how a smart-card application can both help secure a Bitcoin wallet and allow pseudonymous (private) and secure system authentication.
We (nChain) have been awarded or granted a patent [3] on the use of ECDSA as a means to securely share and create keys. The mechanism can be used to create a system that allows uses to authenticate to computers or to create a wallet-key store that can work with a smart card and a mobile phone to allow a single-use Bitcoin key that always updates the address.
The existence of Java Smart Cards that have biometrics is not new; such cards are starting to be rolled out into common use.
A wallet can be used as an application on a smart phone. The data used in the process below can be saved publicly without any loss of security, written onto the blockchain, or backed up otherwise that allows recovery if it is ever lost.
A biometric smart card can be issued where the ECDSA key for the base part of the exchange remains unpublished and not publicly available on the blockchain. The associated address can even be attested on a PKI (Public Key Infrastructure) where the Bitcoin address (and not the Public Key) is recorded by a CA (Certification Authority). Doing so will even allow for a complete AML/KYC-based identity system, and an identity biometric card (such as the UK residency cards or passport) will allow the use of a Java ECDSA process.
Such a process solves all of the issues with PKI and privacy.
If we take the example in the patent, we now replace the laptop with a smart card.
We end with a system that allows keys to be signed on the device (such as a phone). Here, the key is stored as a joint process:
P0 = secret (smart card) X G (G is the ECDSA cure operator)
Pi = secret (wallet value) X G
The “coin help” on the blockchain is a c composite; that is, the wallet value plus the smart-card secret, and the user can have a backup for the wallet.
The app on the phone sends the coin secret (wallet value) to the smart card with the transaction hash. To do so, the app constructs the hash of the transaction (the phone has the “smarts” that allow the transaction to be constructed) and secret (wallet value) to the smart card.
The smart card signs the hash using the composite key:
- S = secret (wallet value) + secret (smart card)
Then the app on the user’s wallet sends the following to the smart card:
- Si = secret (smart card)
- H = hash (transaction to be signed)
The smart card now computes the value for the Bitcoin address associated with the composite key, (P0+Pi). The card returns the signature as:
- (R,S) i— a composite ECDSA signature for the address (P0+Pi).
The app sets the change (if any) to a new address, P(i+1).
The address for P(coin+1) is derived on the smart card and returned to the app. In order to do so, a new secret is generated on the app and sent to the smart card:
- P0 = secret (smart card) X G (G is the ECDSA cure operator)
- P(i+1) = secret (wallet value + 1) X G
- P(coin+1) = P0 + P(i+1)
The phone app never needs to send the secret to the card, it sends the public key. If it is known — one possible means to do so — by the card holder (such as when not only a hashed address but a key is used), the app can do the calculation.
Using the smart card and the app, you can now have a secure wallet that requires the card to sign, which can also be made to enhance wallets such as Handcash or Centbee. Every time a message is signed, a new key is generated securely.
Using the card, a separate wallet can be created for each device and for multiple reasons. It allows all that people seek from a clumsy and antiquated hardware device such as Ledger and with far more flexibility. The process ensures that you only use keys once; and more, it can allow you to attest to a key later whilst maintaining complete privacy.
Each coin is sent as it is spent to a new address. Each is used once and only once, and the card only has to complete a simple operation, as most of the transaction construction is completed by the phone or app device.
A backup of the smart card can be created and stored in a safe allowing recovery, and, together, the card and app work only when the user’s biometrics are there to sign, such as the user’s fingerprint. The one card can be used over and over, never exposing the key as the registered key on the smart card is never used to send and receive Bitcoins.
More, the card can be used with the process detailed below to encrypt files securely (see also the last post) and to even authenticate to a computer and secure a VPN to a remote system.
Personal-device security — details of the base invention
The present 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 the nChain patent entitled ‘Determining a common secret for two nodes.’
Description of the problem
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. But short codes such as the typically 4–8-long-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 such a method, though, 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) [1].
The present method overcomes problems of such nature by enabling the personal device to calculate the secret based on transmission of only non-secret information by an authenticated user.
Glossary
DCS — patent entitled ‘Determining a Common Secret for two nodes’
PED — the Personal Electronic Device to be encrypted (e.g. a laptop, PC, etc.)
Keyring — the device containing the user’s master key (e.g. smartphone, USB key, etc.)
User — authorised user of the PED and owner of the Keyring
The Software — when capitalised, ‘Software’ refers to the application running on the PED that performs the elliptic-curve calculations and communicates with the Keyring.
The App — when capitalised, ‘App’ refers to the application running on the Keyring that performs the elliptic-curve calculations and communicates with the PED.
ECC — ‘Elliptic Curve Cryptography.’
Session — The period of time when the PED is unencrypted and in use by the User. A session begins with User Authentication, followed by PED Decryption, and ends with PED Encryption.
Cycle — A full round of Encryption and Decryption events (between which the PED is idle)
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 itself never passed between user and device. Instead, the key is recalculated when needed after authenticating the User’s Keyring. 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 nChains patent ‘Determining a common secret for two nodes’ (henceforth abbreviated to DCS —’ Determining a Common Secret’).
Exclusions
1. The actual encryption/decryption process employs existing standards and is not described here.
2. Protocols for handling interruptions to the communications (e.g. disconnected cable) are not described here.
Technical Description
In the following description, reference is made to the DCS. For consistency, the same terminology is used here as in the DCS, which is as follows:
- PED (‘Server’) Master Private Key = VMS (kept secret by the PED)
- PED (‘Server’) Master Public Key = PMS (non-secret)
- Keyring (‘Client’) Master Private Key = VMC (kept secret by the Keyring)
- Keyring (‘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 Keyring is a smartphone running the App.
Initialisation (refer to DCS ‘registration’)
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’ meaning 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 be kept secure).
1) The laptop and smartphone are connected. The connection is made 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.
a. 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 into the laptop with the 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. The 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)[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.
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 the secret, as in DCS, but in the present invention only the Software is required to derive the 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 the 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 [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 the 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. The connection 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: the 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. The 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 a 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 so 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 the 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 Keyring 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 such a case, the Keyring 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 — as 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).
References
[2] http://en.wikipedia.org/wiki/Salt_(cryptography)
[3] Personal Device Security Using Elliptic Curve Cryptography for Secret Sharing: http://patentimages.storage.googleapis.com/4c/c5/d2/48ad44c210de89/EP3257006B1.pdf
Footnotes
[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.
