Anda di halaman 1dari 15

SECRET VALUE DISTRIBUTION

WHITE PAPER

nCrypt Catalogue Reference: WP #0042


Secret Value Distribution White Paper [insert logo here]

Copyright
Information in this document is subject to change without notice, and is furnished under a license
agreement 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, or
transmitted in any form or any means electronic or mechanical, including 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.

Page 1 COMMERCIAL IN CONFIDENCE © nCrypt Holdings Ltd.

nCrypt Catalogue Reference: WP #0042


Secret Value Distribution White Paper [insert logo here]

Contents
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 COMMERCIAL IN CONFIDENCE © nCrypt Holdings Ltd.

nCrypt Catalogue Reference: WP #0042


Secret Value Distribution White Paper [insert logo here]

Abstract
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.

Page 3 COMMERCIAL IN CONFIDENCE © nCrypt Holdings Ltd.

nCrypt Catalogue Reference: WP #0042


Secret Value Distribution White Paper [insert logo here]

Executive Summary
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 ‘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 of 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 COMMERCIAL IN CONFIDENCE © nCrypt Holdings Ltd.

nCrypt Catalogue Reference: WP #0042


Secret Value Distribution White Paper [insert logo here]

Functional Specification
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, such as is used by AES 2, a
single secret key is shared by two parties. It has the disadvantage that the secret key must somehow first
be securely transmitted between the two parties. As the transmission 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 enable the
secure sharing of a secret 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 costly 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.
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.

Page 5 COMMERCIAL IN CONFIDENCE © nCrypt Holdings Ltd.

nCrypt Catalogue Reference: WP #0042


Secret Value Distribution White Paper [insert logo here]

Technical Specification
For clarity, the following description employs an example whereby the two parties involved 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).

Phase I: Registration
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 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 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 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 G
4) 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.

Page 6 COMMERCIAL IN CONFIDENCE © nCrypt Holdings Ltd.

nCrypt Catalogue Reference: WP #0042


Secret Value Distribution White Paper [insert logo here]

The registration phase occurs once only as an initial set-up. Henceforward the master keys will be reused in
a 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) 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 case 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 (P2C) 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 = 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 easily
derivable 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 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 Server. 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 (P2S) 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 (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).

Page 7 COMMERCIAL IN CONFIDENCE © nCrypt Holdings Ltd.

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).

12) Server calculates a secondary private key as follows:


V2S = VMS + SHA-256(M)
It can be verified that V2S is paired with P2S using the same technique as in step (6). Note that the Server’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 = V2S X (V2C X G)
= (V2S X V2C) X G
(ii) V2C X P2S = 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, (xS, yS). This can be converted into any standard
key format using standard publicly known operations as agreed by both parties. For example, the xS value is
a 256-bit integer that could itself be used as a key for AES256 encryption. It could also be converted into a
160-bit integer using RIPEMD160 10 for any applications requiring this length key. Note that once the
shared secret S has been calculated the secondary private keys (V2C 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 single-
purpose 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 COMMERCIAL IN CONFIDENCE © nCrypt Holdings Ltd.

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 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 transmissions. The second generation shared secret (S’) can be computed
as 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 G
V1.iii Server calculates another generation of the Client’s public key:
P2C’ = PMC + Hash’ X G
V1.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. 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 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):

Page 9 COMMERCIAL IN CONFIDENCE © nCrypt Holdings Ltd.

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 (see
Figure 2). Each of these can be used to create a shared secret with another party.

Page 10 COMMERCIAL IN CONFIDENCE © nCrypt Holdings Ltd.

nCrypt Catalogue Reference: WP #0042


Secret Value Distribution White Paper [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.

V2: Peer-to-Peer Secret Sharing

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, the 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 – 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) – (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 V2S to sign the same message and send it back to the Client:
V2.i Signed message = Sig-V2S <M> ECDSA 9
The Client then validates the Server’s signature against the Server’s secondary public key P2S, which they
had calculated in step (8).

Page 11 COMMERCIAL IN CONFIDENCE © nCrypt Holdings Ltd.

nCrypt Catalogue Reference: WP #0042


Secret Value Distribution White Paper [insert logo here]

Embodiment Examples
Electronic Resource Rental
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 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. 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.

Password Replacement
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 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 no
longer need to keep a password file (secret record of passwords 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.

Personal Device Security


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 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 taking
the Client’s master public key as a direct input from the client. The Client will be responsible 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 COMMERCIAL IN CONFIDENCE © nCrypt Holdings Ltd.

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), 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 Client’s Master private key VMC along with a message M, from which it
verifies that the current device operator is the owner of the registered public key PMC (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 AES256 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) 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 COMMERCIAL IN CONFIDENCE © nCrypt Holdings Ltd.

nCrypt Catalogue Reference: WP #0042


Secret Value Distribution White Paper [insert logo here]

References
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/asymmetric-
cryptography
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;
http://cs.ucsb.edu/~koc/ccs130h/notes/ecdsa-cert.pdf
10. RIPEMD160 algorithm: http://homes.esat.kuleuven.be/~bosselae/ripemd160.html

Page 14 COMMERCIAL IN CONFIDENCE © nCrypt Holdings Ltd.

nCrypt Catalogue Reference: WP #0042