WP #0042 Secret Value Distribution v2

SECRET VALUE DISTRIBUTION WHITE PAPER

nCrypt Catalogue Reference: WP #0042

[insert logo here]

Copyright Information in this document is subject to change without notice, and is furnished under a license agreement or nondisclosure nondisclosure agreement. The information may only be used or copied in accordance with the terms of those agreements. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or any means electronic or mechanical, including photocopying photocopying and recording for any purpose other than the purchaser’s personal use without the written permission of nCrypt Holdings Ltd. The names of actual companies and products mentioned in this document may be trademarks of their respective owners. nCrypt Holdings Ltd.accepts no responsibility or liability for any errors or inaccuracies that may appear in this documentation. documentation.

Page 1

COMMERCIAL IN CONFIDENCE

© nCrypt Holdings Ltd. nCrypt Catalogue Reference: WP #0042

[insert logo here]

Abstract Abstract ......................... ....................................... ........................... .......................... .......................... .......................... ........................... ........................... ........................... ................ 3 Executive Summary ...................... ........... ..................... ..................... ...................... ...................... ...................... ...................... ...................... ...................... .................. ....... 4 Functional Specification ............................................................................................................. 5 Technical Specification ............................................................................................................... 6 Phase I: Registration ..................................................................... ...................................................................................................................................... ................................................................. 6 Phase II: Session Initiation ........................................................................................................... ............................................................................................................................. .................. 7 Variations ............................................................................................................ ....................................................................................................................................................... ........................................... 9 V1: Hierarchy of Hashes. ............................................................................................................................................ 9 Master Key ............................................................... ................................................................. ........................... 11

V2: Peer-to-Peer Secret Sharing .............................................................................................................................. 11

Embodiment Examples ............................................................................................................. 12 Electronic Resource Rental .......................................................................................................... .......................................................................................................................... ................ 12 Password Replacement ............................................................................................................................... ............................................................................................................................... 12 Personal Device Security ............................................................................................................................. ............................................................................................................................. 12

References ............................................................................................................................... 14

Page 2



[insert logo here]

Two parties exchange public keys, then each time they need to share a new secret they first agree to add a shared non-secret number to their original private keys (thus changing their public keys) before performing Elliptic Curve Diffie –Hellman. –Hellman. So instead of exchanging new public keys each time, time, a single number is shared.

Page 3



[insert logo here]

The present invention describes a method to utilise the private key stored within a cryptocurrency wallet for the generation and management of any type of secret values including (but not limited to): secret keys for cryptocurrency transactions; shared secrets for data and message encryption; single-use single- use ‘session keys’ for temporary communication links; and login passwords. Cryptocurrency keys (of the type used, for example, for bitcoin transactions) are normally associated with funds and assets that can be exchanged for value. Accordingly, it is expected that the owner would act in a manner to ensure the integrity of the keys with more care than they could be expected to express defending other secrets such as login passwords to various websites. The present invention describes a method to use these securely kept secret keys as master keys for the deterministic creation of any number of generations of offspring secret keys for multiple purposes while ensuring the same level of security for all the secret keys generated. An immediate benefit is the elimination o f the need for multiple secrets (such as passwords) since the secrets are deterministic and can be regenerated from the master key. By the addition of extensions to the technique (as described herein) further benefits can be realized through the establishment of a hierarchy of secret keys linked by function. The protocol explained below is based on sharing a secret between two parties but is easily extensible for sharing the secret across multiple participants.

Page 4



[insert logo here]

A fundamental problem in cryptographic systems is the establishment of a shared secret between parties across an insecure network. For example, in symmetric key cryptography 1, cryptography 1, such such as is used by AES 2, AES 2, a a single secret key is shared by two t wo parties. It has the disadvantage that the secret key must somehow first be securely transmitted between the two parties. As the tr ansmission of keys is usually done electronically over communications systems such as the internet, the sharing step is a potentially catastrophic vulnerability. As the symmetric key protocol is simple and widely used there is a need for an ability to share a secret key securely across an insecure network. Existing protocols such as the Diffie-Hellman Key Exchange 3 and the Three Pass Protocol 4 4 enable the secure sharing of a secret sec ret across insecure networks, however these methods are computationally expensive in cases where new secrets are be continuously generated and shared. The present invention is an efficient and less c ostly method for secure secret sharing. Furthermore, the technique described allows the generation and convenient management of multiple secure secret keys based on a single master key. The key elements of the invention are as follows: 1. The method utilises Elliptic Curve Cryptography (ECC) 5 and the properties of Elliptic Curve operations. Several standards exist for cryptography using elliptic curves as described by the independent body known as the Standards for Efficient Cryptography Group (SECG) 6. (SECG) 6. 2. ECC is used to generate pairs of cryptographic keys for asymmetric cryptography 7, cryptography 7, in in which one key is made publicly available and the other is kept secret. The present i nvention enables each party to independently calculate the same secret key based on their own asymmetric key pair as generated by an agreed ECC standard such as secp256k1. The security derives from the fact that the shared secret is calculated by each party but never transmitted. 3. The efficiency derives from consolidating several steps into a single step and from using a less computationally expensive calculation to derive new keys. After an initial set-up phase in which master keys are established, each subsequent creation of a new secret key is efficient and repeatable.

Page 5



[insert logo here]

For clarity, the fol lowing description employs an example whereby the two parties invo lved in the secret sharing are an internet-based service provider of some kind (henceforth the Server) and a client of the Server (henceforth the Client). The method described is generalizable for any two parties (for example see variation V2). It is assumed that each party has the capacity to perform ECC operations. In practice ‘naïve’ Clients may be using software provided by the Server for the purpose, or provided by a third party provider of cryptographic services (for example, a bitcoin eWallet).

1) Each party agrees on a standard ECC system such as secp256k1 (as used by the bitcoin system), using a common generator, G. 2) Server generates a public/private key pair using secp256k1 and publishes their public key (for example, by making it visible on their official website): Server Private key 1 = VMS

(Kept secret by the Server)

Server Public key 1 = PMS

(Made publicly known)

Where: V stands for a PRI VATE key (kept secret by the owner of the key) P stands for PUBLIC key (known to all) In the subscript: M indicates the ‘master key’ S indicates that the key belongs to the Server Note that in ECC the public key is derived from the private key by using elliptic curve point multiplication as follows: PMS

=

VMS X G

The private key is a ra ndom integer within the allowable range specified by the ECC system. 3) Client generates public/private key pair using secp256k1: Client Private key key 1 = VMC

(Kept secret by the Client)

Client Public key 1 = PMC

(This is the Client’s master key)

Again: PMC

=

VMC X G

4) Client registers their master public key (P MC) at the Server. This would occur, for example, when the Client signs up with the Server as an ongoing user of their services. The Client also has access to the Server’s publicly available master public key, P MS.

Page 6



[insert logo here]

The registration phase occurs once only o nly as an initial set-up. Henceforward the master keys will be reused in a secure manner to generate single-use symmetric cryptographic keys.

5) Client creates a ‘message’ to send to the server, and uses a standard algorithm to create a hash of the message resulting in a 256-bit integer: (UnixTime + Nonce) 1

Message

=M

Message Hash

= SHA-256(M) 8

6) Client calculates a secondary private key as follows: Client’s Private key #2

= V2C

= VMC + SHA-256(M)

Scalar addition

Note that in this c ase the secondary private key is not a random number but is deterministically derived from the master public key. Using this method, its paired public key (P 2C) is derivable from the Client master key (PMC), as follows: P2C

=

V2C X G

(by definition)

=

(VMC + SHA-256(M) ) X G

(by substitution of V2C)

=

VMC X G + SHA-256(M) X G

(ECC algebra is distributive)

=

PMC + SHA-256(M) X G

(as VMC X G = P MC by definition)

(Note that the ‘+’ operator refers to elliptic curve point addition.) Thus, although although the Client’s secondary private key (V 2C) remains secret, the secondary public key is easily derivable given knowledge of the master key and the message M. 7) Client signs the message M with V 2C and sends this to the Server Signed message

= Sig-V2C

ECDSA 9 ECDSA 9

This step represents the only transmission required to both establish a shared secret and initiate a secured communication session between the Client and the S erver. The Server will be using the received message M to generate their own secondary public/private key pair. This fact allows the Client to immediately calculate the Server’s secondary public key: 8) Client calculates Server’s secondary public key (P 2S) using the same technique as in step (6): P2S

= PMS + SHA-256(M) X G

9) Server receives Client message and independently calculates the hash of M = SHA-256(M) 10) Server calculates Client’s secondary public key (P 2C) as per the formula in step (6).

1

The choice of message is arbit rary for the purposes of generating the shared secret, but the selection of ( UnixTime + Nonce) will be useful for certain planned applications (see embodiment 1).

Page 7



[insert logo here]

11) Server validates the Client’s signature (Sig-V2C) against the calculated P 2C 9. At 9. At this point the Server may also perform further checks based on the content of the message M as per any agreed conditions (for example see embodiment 1). 12) Server calculates a secondary private key as follows: V2S

= VMS + SHA-256(M)

It can be verified that V 2S is paired with P 2S using the same technique as in i n step (6). (6). Note that the Server’s S erver’s secondary private key (V2S) remains secret, known only to the Server 13) Client and Server now have each other’s secondary public keys and can each independently calculate the shared secret S using their own secondary private keys as follows: Server calculates

S

= V2S X P2C

Client calculates

S

= V2C X P2S

The verification that the two calculations result in the same value is as follows: (i) V2S X P2C

(ii) V2C X P2S

=

V2S X (V2C X G)

=

(V2S X V2C) X G

=

V2C X (V2S X G)

=

(V2C X V2S) X G

ECC algebra is commutative, therefore: (V2S X V2C) X G

=

(V2C X V2S) X G

Thus equations (i) and (ii) are equivalent. The shared secret S is in the form of an elliptic curve point, (x S, yS). This can be converted into any standard key format using standard publicly known operations as agreed by both parties. For example, the x S value is a 256-bit integer that could itself be used as a key for AES 256 encryption. It could also be converted into a 160-bit integer using RIPEMD160 10 RIPEMD160 10 for any applications requiring this length key. Note that once the shared secret S has been calculated the secondary private keys (V 2C and V2S) do not need to be kept and need never be stored (although, depending on the particular application, they could be stored provided they are kept as secure as the master private keys). Furthermore, the shared secret itself need exist only for the duration of a communications session and can be discarded immediately following a session without ever storing it (though it can be recalculated at any time). Phase II in this protocol can be repeated many times to generate successive shared secrets for singlepurpose usages. Alternatively, the same shared secret can be re-used. In the latter case, for security, the actual secret will not be stored as it is recalculable from the publicly known information and the existing secretly kept private keys (for example, see embodiment 2).

Page 8



[insert logo here]

Instead of repeating phase II to generate successive single-purpose keys, by prior agreement between the parties, the previously used Message Hash (SHA-256(M)) can be rehashed repeatedly by both parties to establish a hierarchy of hashes. In effect, the hash of a message can be the message for the next generation (M’). Doing this allows successive generations of shared secrets to be calculated without the need for further protocol-establishment protocol-establishment transmissions. transmissions. The second generation shared secret (S’) can be computed compute d as follows. V1.i

Both parties calculate a second generation of the Hash:

V1.ii

M’

=

SHA-256(M)

Hash’

=

SHA-256(SHA-256(M))

Client calculates another generation of the S erver’s public key: P2S’

V1.iii

V1.v.

PMS + Hash’ X G

Server calculates another generation of the Client’s public key: P2C’

V1.iv

=

=

PMC + Hash’ X G

Both parties calculate a second generation of their own private keys: V2C’

=

VMC + SHA-256(M’) SHA-256(M’)

V2S’

=

VMS + SHA-256(M’) SHA-256(M’)

Server and Client each calculate the next generation shared secret: Server calculates

S’

= V2S’ X P2C’

Client calculates

S’

= V2C’ X P2S’

Further generations (S’’, S’’’, etc.) can be calculated in the same way to create a chain hierarchy. This technique requires that both the Server and the Client keep track of the original Message or the originally calculated hash, (SHA-256(M)), and to which party it relates. As this is publicly known information there are no security issues regarding the retention of this information. Accordingly, this information might be kept on ‘hash tables’ (linking hash values to public keys) and distributed freely across the network (for example using Torrent). Note that if any individual shared secret in the hierarchy is ever compromised this does not affect the security of any other secret keys in the hierarchy provided the private keys remain secure. As well as a chain (linear) hierarchy as described above, a hierarchy in the form of a tree structure can be created. Tree branching can be accomplished ac complished in several ways, three of which are described here. (i)

Page 9

Master Key Spawning. First, note that in the chain hierarchy each new ‘link’ (Public/Private key pair) is created by adding a multiply rehashed Message to the original master key. That is (showing only the private key for clarity):



[insert logo here]

(ii) V2C

= VMC + SHA-256(M)

V2C’

= VMC + SHA-256(SHA-256(M))

V2C’’

= VMC + SHA-256(SHA-256(SHA-256(M)))

… and so on. To create a branch any key can be used as a sub-master key. For example V 2C’ can be used as a sub-master key by adding the hash to it as is done for the regular master key: V3C

= V2C’ + SHA-256(M)

V3C’

= V2C’ + SHA-256(SHA-256(M))

This yields a tree as shown in Figure 1. VMC | V2C | V2C’ |_________ |

|

V2C’’

V3C | V3C’

Figure 1: Tree structure using Master Key Spawning method (iii)

(iv)

Logical Association. In this method all the nodes in the tree (public/private key pairs) are generated as a chain (or in any other way – way – see see (iii) below) and the logical relationships between the nodes in the tree is maintained by a table in which each node is simply associated with its parent node using a pointer. Message Multiplicity. New private/public key pairs can be generated by introducing a new message M at any point in the chain or tree. The message itself may be arbitrary or may carry some meaning or function (e.g. it might be related to a ‘real’ bank account number, etc). Of course any new messages must be securely retained.

With a tree structure we can have a host of keys for different purposes such as authentication keys, encryption keys, signing keys, payment keys, etc., a ll linked to a single securely maintained master key (see Figure 2). Each of these can be used to create a shared secret with another party.

Page 10



[insert logo here]

MasterKey

|____________________________________________________ |

|

|

Passwords

Bank Accounts

Bitcoin payments

|_____________

|_____________

|_____________

|

|

|

|

|

|

ABC website

XYZ PIN

Cheque a/c

Savings

Salary

Bitcoin bond interest

Figure 2: Example application for tree structure of secret keys.

The present invention can be used between two peers rather than between a Server and a Client. In the example described in the Technical Description, t he Server acts as a party trusted by the Client. The Server must authenticate the credentials of the Client in order to allow the Client access to their system. The Server does this by validating the Client’s signed message. In a peer -to-peer scenario each peer must establish trust with each other – other – i.e. the ‘Client’ must also authenticate the credentials of the ‘Server’. This can be done by a two-way process, in which both parties perform the message signing and verification steps (step (7) – (7) – (11) in the Technical Description). In the peer-to-peer scenario, after the Client has sent the signed message M to the Server, the Server uses their calculated secondary private key V 2S to sign the same message and send it back to the Client: V2.i

Signed message

= Sig-V2S

ECDSA 9 ECDSA 9

The Client then validates the Server’s signature against the Server’s secondary public key P 2S, which they had calculated in step (8).

Page 11



[insert logo here]

Client wishes to use remote supercomputer facilities for processing large amounts of confidential data. The Server has set up a service to rent out supercomputer CPU time on a per time and/or per CPU cycles basis. The Client registers with the Server by depositing their public key. The Server provides software to the Client for performing background processes such as establishing secure connections using AES encryption. The Message signed by the Client is c omposed of UnixTime concatenated with a Nonce (random number). The allowed value of the UnixTime will be set according to the Client/Server Terms and Conditions. For example, the UnixTime may be required to be within a set period (e.g. 300 seconds) of the receipt of the message transmission at the Server, else the exchange will not be accepted. This will ensure that the session key can never be reproduced at a later time and is unique to the session being established. The protocol is used to establish an AES encryption/decryption key for the duration of the session. The key is used for all communications between the Client and the Server for the duration of the session. This allows the Client to encrypt code and/or large amounts of data, send these to the Server for processing, and receive encrypted results back from the Server.

As secp256k1 is a commonly used standard for elliptic curve cryptography, an individual may register their public key at several institutions willing to use the same protocol. Each time the Client wishes to log into one of the websites of a participating institution they do not need to use a password. The protocol replaces the need for passwords for each institution. All that is required for the Client is the Institution’s Public Key, which is always available, and registration at the institution, which is a normal practice for using web-based services. Once the registration phase has been c ompleted the calculable shared secret can be used and reused in place of a password. This technique lifts a significant security burden from the institution: they no longer need to keep a password file (secret record of passwords pas swords or password hashes) as the shared secret can be recalculated from non-secret information. Rather, the institution need only keep their own master private key secure. Furthermore, the Client does not need to memorise or securely store many passwords (one for each institution) so long as they can keep their private key secure.

3(a) The technique can be used to protect data on personal electronic devices, for example by encrypting the hard drive of a laptop. Purpose-built software stored on the device can act as the Server with its own Master keys as well as perform the ECC and hashi ng functions required by the device’s owner (the Client). The ‘registration phase’ will consist of the software calculating and storing its own master keys and taking the Client’s master public key as a direct input from the client. The Client will be resp onsible for maintaining the security of their master private key and also a secret message M (these need to be stored off the device and could be stored by the Client on an alternative device such as their smart phone or even on paper kept in their wallet).

Page 12



[insert logo here]

The ‘encryption phase’, performed by the purpose built software, consists of steps (5) and (9) – (13), along with an additional step to encrypt the hard drive using the calculated secret S. For step (5) the software prompts the Client to enter the Clien t’s Master private key V MC along with a message M, from which it verifies that the current device operator is the owner of the registered public key P MC (i.e. it performs the equivalent of the signing and signature validation functions). Following this validation, the secret key S is calculated and used as an AES 256 key to encrypt the hard drive. The secret key S and the message M are not stored on the device. Thus, if the device or its hard drive is lost or stolen the data is not accessible to an attacker. The ‘decryption phase’ is almost identical to the encryption phase, except that the recalculated secret key S is used instead to decrypt the hard drive for the session. 3(b) A further variation is the encryption of individual files on the hard drive. In this case, for ‘step (5)’ of the encryption phase the Client only enters the private key for user validation, and then instructs the software as to which file(s) fi le(s) are to be encrypted. The Software then creates message M by hashing the target file and using it in the protocol to create the secret S. The file itself is encrypted using S and the message M is displayed to the Client. The client is then responsible for taking down the message and keeping it secure off the device. The message M is not stored on the device, but the software will perform a hash of M (i.e. a hash of the hashed file) and will store this along with the file name in a hash table, so that it can locate the file to be decrypted. For the decryption phase the Client provides the saved message M in the protocol to the software to enable the software to locate the encrypted file (by hashing M and looking up the hash table) and then recalculate S to decrypt the file.

Page 13



[insert logo here]

1. Symmetric key cryptography: https://en.wikipedia.org/wiki/Symmetric-key_algorithm 2. AES encryption: http://aesencryption.net/ 3. Diffie-Hellman Key exchange: https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange 4. Three Pass Protocol: https://en.wikipedia.org/wiki/Three-pass_protocol 5. Elliptic Curve Cryptography: https://en.wikipedia.org/wiki/Elliptic_curve_cryptography 6. Standards for Efficient Cryptography Group (SECG): http://www.secg.org/ 7. Asymmetric cryptography: http://searchsecurity.techtarget.com/definition/asymmetriccryptography 8. SHA-256 algorithm: http://hash.online-convert.com/sha256-generator 9. Elliptic Curve Digital Signature Algorithm(ECDSA): https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm;; https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm http://cs.ucsb.edu/~koc/ccs130h/notes/ecdsa-cert.pdf 10. RIPEMD160 algorithm: http://homes.esat.kuleuven.be/~bosselae/ripemd160.html

Page 14



WP #0042 Secret Value Distribution v2

Recommend Documents