User:Jinbolin/sandbox

= Escrow Free Identity Based Cryptography = A common misconception about Identity Based Cryptographic schemes is idea that Key Escrow is a necessary part of such schemes. Most Identity Based Encryption schemes allow for the trusted third party of the scheme to passively collect and decrypt information protected by the scheme. However there are several Identity Based Key Agreement schemes do not permit passive decryption. Rather they are like more common public key certificate based key agreement schemes that permit the certificate authority (the trusted third party in such systems) to do an active Entity-in-the-Middle attack and recover the information protected by the scheme. This article describes the earliest Identity Based Key Agreement Scheme that does not feature Key Escrow.

Identity Based Cryptography
The basic feature of identity based cryptography is that an entities public key should be a data string containing something commonly known and unchanging about the entity. An email address, name, MAC address or a unique and fixed IP address have all been suggested as possibilities. By being commonly known it is assumed that entity want to communicate with a given entity will know that commonly known data about the entity and can therefore create the public key on its own without having to look up the entity's public key in some sort of online and constantly available directory. Avoiding a directory lookup for every public keys is considered to be a key benefit of Identity Based cryptography.

In order to use a common data string as a public key requires that that data string be first transformed into a mathematical entity such as an integer in a finite group or, most commonly, a point on an elliptic curve expressed over a finite group. This action is generally quite easy for any entity to perform. To generate the private key corresponding to an entity's public key requires the intervention of a trusted third party. The trusted third party for an identity based cryptographic scheme generates a public/private key pair and uses its private key and an entity's public key to create a unique private key for the entity. The trusted third party securely delivers this unique private key to the entity. Once this is done for all entities, the entities can use their public and private key pairs for encryption, signing or key agreement without the need of the trusted third party.

The problem that some people find with this basic identity based cryptography scheme is that the trusted third party knows every entities private key and can therefore do any action (like decryption) that the entity can do. This capability of a trusted third party is often referred to as "key escrow" and is viewed by some as an insecurity in the system. While this key escrow feature is inherent in Identity Based Encryption schemes it is not inherent in Identity Based Key Agreement schemes

The McCullagh and Paulo Barreto Scheme
In 2004, Noel McCullagh and Paulo Barreto published “A New Two-Party Identity-Based Authenticated Key Agreement.”   In that paper the authors describe one key agreement that does not allow the Trusted Third Party (Key Generation Centre) to passively recover the shared key resulting from the key agreement protocol. The scheme does not allow for Key Escrow as is commonly understood. They describe their Escrow Free Identity Based Key Agreement Scheme in section 4 of their paper. An overview of their scheme which highlights the elements that the trusted third party cannot compute follows.

Definitions
E0, E1 - elliptic curves (EC) defined over a finite field

P, Q - elements of E0, E1 respectively of prime order r

G0, G1 - prime-order subgroups of E0, E1 generated by P,Q respectively

G2 - order r subgroup of the multiplicative group over a field


 * - data string concatenation

e - An efficient elliptic curve pairing function e: (G0, G1) → G2 that is bilinear and non-degenerate.

hash - a hash function hash: (data strings) → Z/rZ* (the integers mod r excluding zero)

Notation
Elliptic curve operations in G0 and G1 are written in additive notation. If P and Q are elliptic curve points then P+Q denotes point addition and [x]P denotes scalar multiplication of a point P by a scalar x.

Field operations in G2 are written in multiplicative notation, with a∙b denoting field element multiplication and a+b denoting field addition.

Key Generation Centre Setup
In this key agreement a Key Generation Centre (KGC) is required. The KGC will generate each user’s long-term private key.

The KGC does the following:


 * 1) Generates an integer s from Z/rZ (0 < s < r).
 * 2) Computes a point in G0: [s]P
 * 3) Distributes G0, G1, the pairing e, P, Q, and [s]P to all users.
 * 4) Securely stores the integer (s).

Entity Setup
Given an identity string for entity A equal to IDA the KGC does the following:


 * 1) Computes a = hash(IDA), this hash may contain other known data as well
 * 2) Computes Apub = [a + s]P = aP + sP.  This is entity A's public key.
 * 3) Computes Apriv = [(a +s)-1]Q.  This is entity A's private key
 * 4) The KGC gives Apriv to Entity A by a secure means.

Note that every entity who knows A's identity string IDA and the KGC's public key sP can create:

Apub = [hash(IDA)]P + sP = aP + sP

Key Agreement between Entity A and Entity B
The initiator A does the following:


 * 1) Generates an integer xA in Z/rZ ( 0 < xA < r ).   The KGC does not know xA.
 * 2) Computes b = hash(IDB)
 * 3) Computes Aka = xA(bP + sP)
 * 4) Sends Aka to entity B

The responder B does the following:


 * 1) Generates an integer xB in Z/rZ ( 0 < xB < r ).   The KGC does not know xB.
 * 2) Computes a = hash(IDA)
 * 3) Computes Bka = xB(aP + sP)
 * 4) Sends Bka to entity A

Entity A forms the shared secret by computing (e(Bka,Apriv))xA  The KGC cannot compute this result.

Entity B forms the shared secret by computing (e(Aka,Bpriv))xB   The KGC cannot compute this result.

These values will be equal. To understand this note that:

e(uP, vQ) = e(P,Q)uv This is a property of bilinear pairings functions.

(e(Bka,Apriv))xA = (e(xB(aP + sP), [(a +s)-1]Q))xA =  (e(xB(a + s)P), (a + s)-1Q))xA = e(P,Q)xB(a + s)(a + s)^-1xA  = e(P,Q)xBxA

(e(Aka,Bpriv))xB = (e(xA(bP + sP), [(b +s)-1]Q))xB =  (e(xA(b + s)P), (b + s)-1Q))xB = e(P,Q)xA(b + s)(b + s)^-1xB  = e(P,Q)xAxB =  e(P,Q)xBxA

Despite knowing the private keys for entities A and B, the Key Generation Centre cannot compute the shared secret. That is why this key agreement protocol is "escrow free."

The SM9 Key Agreement Scheme
SM9 is a Chinese national cryptography standard for Identity Based Cryptography issued by the Chinese State Cryptographic Authority in March 2016. It is Chinese Standard GM/T0044-2016 SM9. One of the algorithms in the SM9 standard is an Escrow Free Identity Based Key Agreement algorithm that follows the McCullagh-Barreto method of adding in entity generated random values from both sides of a key exchange in order to prevent the Key Generation Centre from having the ability to passively collect and decrypt traffic from either entity in the key agreement.

Security Considerations
Neither of the Escrow Free Key Agreement schemes described in this article protect against exploitation by a Key Generation Centre capable of doing an Entity-in-the-Middle attack. In this, these schemes are the same as a Public Key Certificate based key agreement. There a Certificate authority can create false public keys and certificates for the communicating entities and do an equivalent Entity-in-the-Middle attack.

In order for these Escrow Free Key Agreements to be secure, users must choice appropriate elliptic curves and elliptic curve pairing functions.