WP #0042 Secret Value Distribution v2

Uploaded by

Description:

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. So instead of exchanging new public keys each time, a single number is shared.

Copyright:

Available Formats

WP #0042 Secret Value Distribution v2

Uploaded by

Description:

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. So instead of exchanging new public keys each time, a single number is shared.

SECRET VALUE DISTRIBUTION

nCrypt Catalogue Reference: WP #0042

CopyrightInformation in this document is subject to change without notice, and is furnished under a licenseagreement or 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, ortransmitted in any form or any means electronic or mechanical, including photocopying and recording forany purpose other than the purchaser’s personal use without the written permission of nCrypt HoldingsLtd.

The names of actual companies and products mentioned in this document may be trademarks of theirrespective owners.

nCrypt Holdings Ltd.accepts no responsibility or liability for any errors or inaccuracies that may appear inthis documentation.

nCrypt Catalogue Reference: WP #0042

Secret Value Distribution White Paper [insert logo here]

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

nCrypt Catalogue Reference: WP #0042

Secret Value Distribution White Paper [insert logo here]

Executive SummaryThe present invention describes a method to utilise the private key stored within a cryptocurrency walletfor the generation and management of any type of secret values including (but not limited to): secret keysfor cryptocurrency transactions; shared secrets for data and message encryption; 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 withfunds and assets that can be exchanged for value. Accordingly, it is expected that the owner would act in amanner to ensure the integrity of the keys with more care than they could be expected to expressdefending 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 thedeterministic creation of any number of generations of offspring secret keys for multiple purposes whileensuring the same level of security for all the secret keys generated. An immediate benefit is the elimination of the need for multiple secrets (such as passwords) since thesecrets are deterministic and can be regenerated from the master key. By the addition of extensions to thetechnique (as described herein) further benefits can be realized through the establishment of a hierarchy ofsecret keys linked by function.The protocol explained below is based on sharing a secret between two parties but is easily extensible forsharing the secret across multiple participants.

nCrypt Catalogue Reference: WP #0042

Secret Value Distribution White Paper [insert logo here]

Functional SpecificationA fundamental problem in cryptographic systems is the establishment of a shared secret between partiesacross an insecure network. For example, in symmetric key cryptography 1, such as is used by AES 2, asingle secret key is shared by two parties. It has the disadvantage that the secret key must somehow firstbe securely transmitted between the two parties. As the transmission of keys is usually done electronicallyover communications systems such as the internet, the sharing step is a potentially catastrophicvulnerability. As the symmetric key protocol is simple and widely used there is a need for an ability to sharea secret key securely across an insecure network.Existing protocols such as the Diffie-Hellman Key Exchange 3 and the Three Pass Protocol 4 enable thesecure sharing of a secret across insecure networks, however these methods are computationallyexpensive in cases where new secrets are be continuously generated and shared. The present invention isan efficient and less costly method for secure secret sharing. Furthermore, the technique described allowsthe 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. 2. ECC is used to generate pairs of cryptographic keys for asymmetric cryptography 7, in which one key is made publicly available and the other is kept secret. The present invention 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.

nCrypt Catalogue Reference: WP #0042

Secret Value Distribution White Paper [insert logo here]

Technical SpecificationFor clarity, the following description employs an example whereby the two parties involved in the secretsharing are an internet-based service provider of some kind (henceforth the Server) and a client of theServer (henceforth the Client). The method described is generalizable for any two parties (for example seevariation V2).It is assumed that each party has the capacity to perform ECC operations. In practice ‘naïve’ Clients may beusing software provided by the Server for the purpose, or provided by a third party provider ofcryptographic services (for example, a bitcoin eWallet).

Phase I: Registration1) 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 PRIVATE 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 ServerNote that in ECC the public key is derived from the private key by using elliptic curve point multiplication asfollows: PMS = VMS X GThe private key is a random integer within the allowable range specified by the ECC system.3) Client generates public/private key pair using secp256k1: Client Private key 1 = VMC (Kept secret by the Client) Client Public key 1 = PMC (This is the Client’s master key)Again: PMC = VMC X G4) Client registers their master public key (PMC) 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, PMS.

nCrypt Catalogue Reference: WP #0042

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

Phase II: Session Initiation

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: Message =M (UnixTime + Nonce)1 Message Hash = SHA-256(M) 86) Client calculates a secondary private key as follows: Client’s Private key #2 = V2C = VMC + SHA-256(M) Scalar additionNote that in this case the secondary private key is not a random number but is deterministically derivedfrom the master public key. Using this method, its paired public key (P2C) is derivable from the Client masterkey (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 = PMC by definition)(Note that the ‘+’ operator refers to elliptic curve point addition.)Thus, although the Client’s secondary private key (V2C) remains secret, the secondary public key is easilyderivable given knowledge of the master key and the message M.7) Client signs the message M with V2C and sends this to the Server Signed message = Sig-V2C <M> ECDSA 9This step represents the only transmission required to both establish a shared secret and initiate a securedcommunication session between the Client and the Server. The Server will be using the received messageM to generate their own secondary public/private key pair. This fact allows the Client to immediatelycalculate the Server’s secondary public key:8) Client calculates Server’s secondary public key (P2S) using the same technique as in step (6): P2S = PMS + SHA-256(M) X G9) Server receives Client message and independently calculates the hash of M = SHA-256(M)

10) Server calculates Client’s secondary public key (P2C) as per the formula in step (6).

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

nCrypt Catalogue Reference: WP #0042

Secret Value Distribution White Paper [insert logo here]

11) Server validates the Client’s signature (Sig-V2C) against the calculated P2C 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).

The shared secret S is in the form of an elliptic curve point, (xS, yS). This can be converted into any standardkey format using standard publicly known operations as agreed by both parties. For example, the xS value isa 256-bit integer that could itself be used as a key for AES256 encryption. It could also be converted into a160-bit integer using RIPEMD160 10 for any applications requiring this length key. Note that once theshared secret S has been calculated the secondary private keys (V2C and V2S) do not need to be kept andneed never be stored (although, depending on the particular application, they could be stored providedthey are kept as secure as the master private keys). Furthermore, the shared secret itself need exist only forthe duration of a communications session and can be discarded immediately following a session withoutever 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 single-purpose usages. Alternatively, the same shared secret can be re-used. In the latter case, for security, theactual secret will not be stored as it is recalculable from the publicly known information and the existingsecretly kept private keys (for example, see embodiment 2).

nCrypt Catalogue Reference: WP #0042

Secret Value Distribution White Paper [insert logo here]

Variations

V1: Hierarchy of Hashes.

Instead of repeating phase II to generate successive single-purpose keys, by prior agreement between theparties, the previously used Message Hash (SHA-256(M)) can be rehashed repeatedly by both parties toestablish 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 forfurther protocol-establishment transmissions. The second generation shared secret (S’) can be computedas follows.V1.i Both parties calculate a second generation of the Hash: M’ = SHA-256(M) Hash’ = SHA-256(SHA-256(M))V1.ii Client calculates another generation of the Server’s public key: P2S’ = PMS + Hash’ X GV1.iii Server calculates another generation of the Client’s public key: P2C’ = PMC + Hash’ X GV1.iv Both parties calculate a second generation of their own private keys: V2C’ = VMC + SHA-256(M’) V2S’ = VMS + SHA-256(M’)V1.v. 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. Thistechnique requires that both the Server and the Client keep track of the original Message or the originallycalculated hash, (SHA-256(M)), and to which party it relates. As this is publicly known information there areno security issues regarding the retention of this information. Accordingly, this information might be kepton ‘hash tables’ (linking hash values to public keys) and distributed freely across the network (for exampleusing Torrent). Note that if any individual shared secret in the hierarchy is ever compromised this does notaffect 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 becreated. Tree branching can be accomplished in several ways, three of which are described here. (i) 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):

nCrypt Catalogue Reference: WP #0042

Secret Value Distribution White Paper [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 V2C’ 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) 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 – 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. (iv) 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., all linked to a single securely maintained master key (seeFigure 2). Each of these can be used to create a shared secret with another party.

V2: Peer-to-Peer Secret Sharing

The present invention can be used between two peers rather than between a Server and a Client. In theexample described in the Technical Description, the Server acts as a party trusted by the Client. The Servermust authenticate the credentials of the Client in order to allow the Client access to their system. TheServer does this by validating the Client’s signed message. In a peer-to-peer scenario each peer mustestablish trust with each other – i.e. the ‘Client’ must also authenticate the credentials of the ‘Server’. Thiscan be done by a two-way process, in which both parties perform the message signing and verificationsteps (step (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 usestheir calculated secondary private key V2S to sign the same message and send it back to the Client:V2.i Signed message = Sig-V2S <M> ECDSA 9The Client then validates the Server’s signature against the Server’s secondary public key P2S, which theyhad calculated in step (8).

nCrypt Catalogue Reference: WP #0042

Secret Value Distribution White Paper [insert logo here]

Embodiment ExamplesElectronic Resource RentalClient wishes to use remote supercomputer facilities for processing large amounts of confidential data. TheServer 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 theClient for performing background processes such as establishing secure connections using AES encryption.The Message signed by the Client is composed 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. Forexample, the UnixTime may be required to be within a set period (e.g. 300 seconds) of the receipt of themessage transmission at the Server, else the exchange will not be accepted. This will ensure that thesession key can never be reproduced at a later time and is unique to the session being established. Theprotocol is used to establish an AES encryption/decryption key for the duration of the session. The key isused for all communications between the Client and the Server for the duration of the session. This allowsthe Client to encrypt code and/or large amounts of data, send these to the Server for processing, andreceive encrypted results back from the Server.

Password ReplacementAs secp256k1 is a commonly used standard for elliptic curve cryptography, an individual may register theirpublic key at several institutions willing to use the same protocol. Each time the Client wishes to log intoone of the websites of a participating institution they do not need to use a password. The protocol replacesthe 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-basedservices. Once the registration phase has been completed the calculable shared secret can be used and re-used in place of a password. This technique lifts a significant security burden from the institution: they nolonger need to keep a password file (secret record of passwords or password hashes) as the shared secretcan be recalculated from non-secret information. Rather, the institution need only keep their own masterprivate 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.

Personal Device Security

3(a) The technique can be used to protect data on personal electronic devices, for example by encryptingthe hard drive of a laptop. Purpose-built software stored on the device can act as the Server with its ownMaster keys as well as perform the ECC and hashing 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 takingthe Client’s master public key as a direct input from the client. The Client will be responsible for maintainingthe security of their master private key and also a secret message M (these need to be stored off the deviceand could be stored by the Client on an alternative device such as their smart phone or even on paper keptin their wallet).

nCrypt Catalogue Reference: WP #0042

Secret Value Distribution White Paper [insert logo here]

The ‘encryption phase’, performed by the purpose built software, consists of steps (5) and (9) – (13), alongwith an additional step to encrypt the hard drive using the calculated secret S. For step (5) the softwareprompts the Client to enter the Client’s Master private key VMC along with a message M, from which itverifies that the current device operator is the owner of the registered public key PMC (i.e. it performs theequivalent of the signing and signature validation functions). Following this validation, the secret key S iscalculated and used as an AES256 key to encrypt the hard drive. The secret key S and the message M are notstored on the device. Thus, if the device or its hard drive is lost or stolen the data is not accessible to anattacker.The ‘decryption phase’ is almost identical to the encryption phase, except that the recalculated secret key Sis 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)’ ofthe encryption phase the Client only enters the private key for user validation, and then instructs thesoftware as to which file(s) are to be encrypted. The Software then creates message M by hashing thetarget file and using it in the protocol to create the secret S. The file itself is encrypted using S and themessage M is displayed to the Client. The client is then responsible for taking down the message andkeeping it secure off the device. The message M is not stored on the device, but the software will perform ahash of M (i.e. a hash of the hashed file) and will store this along with the file name in a hash table, so thatit can locate the file to be decrypted. For the decryption phase the Client provides the saved message M inthe protocol to the software to enable the software to locate the encrypted file (by hashing M and lookingup the hash table) and then recalculate S to decrypt the file.