A Randomized Identity Scheme For Distributed Environments


In a distributed environment, the need to publish identities for communication and the privacy of such identities are mostly conflicting in nature. The use of static asymmetric cryoptographic keys to provide anonymous identity is not enough when an adversary has the capability of caching published identities and to map these pseudo-anonymous asymmetrically keyed static identities to actual persons after the fact or even in real time. A randomized identity scheme is needed to create a per-session unique identity that cannot be easily traced to a static root identity even if the adversary were to cache all published session identities.

One method of identifying a static asymmetric identity key to a person is to have the person input his actual Persoally Identifiable Information with his root identity public key. One example is the purchase of Bitcoins using a person's Bitcoin Public Key and the person's actual PIIs for online bank payments to transfer real world currencies to a Bitcoin seller in return for his exchanged Bitcoins associated to his public key. The Bitcoin seller may decide to quietly record the person's PIIs and his related Bitcoin public key (which is once thought to provide strong pseudo-anonymity in a Bitcoin transaction).

The scheme uses a proof-of-decryption ability of the holder of the static root identity key (RSA key) and the security provided to protect this Root Identity key from compromise as the security factor in the scheme. If the Root Identity key is compromised, an adversary capable of observing the network and caching all the traffic transmitting within the network would be able to more accurately pin the pseudo-anonymous identity provided by the Distributed Environment Randomized Identity Scheme (DERIS). In the event where PIIs have to be disclosed and tagged to a Root Identity key, the most that a person compromises is a single session's worth of identity. A reset of session using a new uniquely generated Session Identity would disassociate the holder of the old session identity and this also forces a rekeying of session secrets which increases operational security by the means of constant renewal of session secrets and session identities.

The DERIS scheme requires the user to generate a root identity key in the form of an RSA keypair with a strong key length and strong randomness. This Root Ydentity key's encryption and decryption capability would be the basis of the security of the entire DERIS scheme. The user may use any means available to publish the Root Identity public key and even with the user's actual PIIs together with the root identity public key in a worst case scenario. It is best not to publish PIIs with the root identity public key if possible (and only to be published if necessary).

The unique Session Identity would be generated by having the user generate a 512-bit random and a obtaining a SHA-512 hash of the root identity public key and hashing both the 512-bit random with the SHA-512 hash of the root identity public key. This unqiue session identity includes the hash of the root identity public key as a "binding" factor to bind the root identity public key into the session identity so that in the instance that someone may generate the same 512-bit random, the SHA-512 hash of the root identity public key would ensure lesser chance of collision. The 512-bit random would be concatenated in front of the SHA-512 root identity public key before the final SHA-512 hash to generate the Session Identity. The creation of the session identity can be expressed as:


    SESSID <--- SHA-512( RANDOM( 512-bit ) || SHA-512 ( Root Identity Public Key ) )


The Session Identity would be published on a distributed directory for distributed session peers to lookup for communication. Two or more users wanting to contact each other would generate a session ECC-based DH(E) or traditional DH(E) keypair, generate a random 128-bit nonce and encrypt their session DH(E) public key, their own Root Identity public key and the Session Identity of the receipient into the encrypted Session Initiation Request blob would be broadcast over the network with the Root Identity public key of the recipient. Noting that asymmetric encryption have a finite space for plaintext, the combination of the random nonce, session DH(E) public key, sender's Root Identity public key and the Session Identity of the recipient as the encrypted plaintext (in sequence via concatenation) must be within the limits of the asymmetric RSA encryption or the RSA encryption may wrap a random symmetric key and nonce that would be used to encrypt the Session Initation Request blob. It can be expressed when the plaintext data for the Session Initiation Request is capable of fitting into a single RSA encryption block as:


    SessionInitiationRequest <--- RSAEncrypt( Recipient Root Identity Public Key, ( RANDOM (128-bit) || Sender Session DH Public Key || Requestor Root Identity Public Key || Recipient Session Identity) )


In the case where a symmetric key is used to encrypt the Session Initiation Request in the event the RSA encryption space is too small, it can be expressed as:


    SymmetricRequest <--- SymmetricEncrypt(SymmetricRequestKey, ( RANDOM(128-bit) || Sender Session DH Public Key || Requestor Root Identity Public Key || Recipient Session Identity) )

    SessionInitiationRequest <--- RSAEncrypt( Recipient Root Identity Public Key, SymmetricRequestKey)


Users on the distributed network upon receiving the Session Initiation Request blob through the broadcast would use their own Root Identity private key to decrypt the blob (and use the Symmetric Request key if needed) and look for their Recipient Session Identity to assert whether this request for session initiation is for them. If a user asserts that the request for initiation is for them, they would generate their own Session DH Public Key and repeat the received 128-bit nonce as a proof of being the authentic owner(s) of the Root Identity key(s). The 128-bit nonce must be placed in front of the recipient's selected session DH public key via concatenation. It should be noted that every recipient must be given a unique nonce and the nonce must never be shared in any case. The recipient's respond to the sender's request caled the Session Initiation Response can be expressed in:


    SessionInitiationResponse <--- RSAEncrypt( Sender Root Identity Public Key, ( RANDOM (128-bit) || Recipient Session DH Public Key) )


In the case where a symmetric key is used to encrypt the Session Initiation Response in the event the RSA encryption space is too small, it can be expressed as:


    SymmetricRequest <--- SymmetricEncrypt(SymmetricRequestKey, ( RANDOM(128-bit) || Recipient Session DH Public Key) )

    SessionInitiationRequest <--- RSAEncrypt( Recipient Root Identity Public Key, SymmetricRequestKey)


The sender upon receiving the Session Initiation Response would use the user's Root Identity private key to decrypt the blob (and use the Symmetric Request key if needed) and look for the shared 128-bit random nonce being correctly displayed in the received response.

The negotiation of a Session DH Key Exchange provides forward secrecy for encrypted messages that would be sent later in the session. The use of RSA to encrypt the Session Initiation Request and Response blobs ensures that only the true holder of the Root Identity key would be able to decrypt the initiation requests and response. The 128-bit random nonce acts as a challenge-response between the sender(s) and recipient(s). Due to none of the Root Public Key information and the Session information were ever displayed in plaintext view and everything are encrypted via RSA (and symmetric encryption if needed), only the compromise of either side's Root Identity private keys would be capable of revealing the critical information which would bind the Root Identity key to it's current Session Identity.

Albeit all the security, if either side decides to betray and exflitrate the information, it would be beyond the scope of the DERIS protocol to counteract such a triatorous action by the other side(s).


Publication Info
Written On: 29 Jul 2016
Published On: 29 Jul 2016
Author: Thotheolh


CONTACT