NAME

login − key exchange protocol

DESCRIPTION

The following encrypted key exchange protocol is used between a client such as ­login in security-login(2), and a certificate signing process such as logind(8), to justify the latter’s issuing a certificate that can later be presented to an Inferno service to establish credentials.

A shared secret must previously be agreed between user and certifying authority (CA).  It is used by the protocol to establish a secure channel between user and CA. 

In the description below:

­ivec is an 8 byte random number (‘initialisation vector’) chosen for this conversation. 

­sha is the 20 byte secure hash (SHA-1) of the password

­key is an 8 byte secret formed as follows:

key[0] = ivec[0]^sha[0]^sha[8]^sha[16]
key[1] = ivec[1]^sha[1]^sha[9]^sha[17]

... 

key[5] = ivec[5]^sha[5]^sha[13];
key[6] = ivec[6]^sha[6]^sha[14];
key[7] = ivec[7]^sha[7]^sha[15];

­alpha is a Diffie-Hellman base used system wide

­p is a Diffie-Hellman modulus used system wide

­key(m) is ­m encrypted using the RC4 algorithm with key.

­Rx is a random number of the same order as p.

­secret is the Diffie-Hellman secret alpha∗∗(r0∗r1) mod p.

The protocol follows.  “user→CA xxx” means that the user sends the message “xxx” to the certifying authority.  Any party can send an error instead of a message at any point to terminate the protocol. 

user→CAname
CA→userACK
user→CAivec
CA→userkey(alpha∗∗r0 mod p), alpha, p
user→CAalpha∗∗r1 mod p
CA→userCA’s public key, SHA(CA’s public key + secret)
user→CAuser’s public key, SHA(user’s public key + secret)
CA→useruser’s public key certificate

The complexity of this protocol is intended to shield the password.  To start a clear text attack against the password, one needs to first attack the Diffie-Hellman exponential to determine alpha∗∗r0 mod p. A possible weakness is that the encrypted quantity is base64 encoded, constraining the possible values of each byte. This could aid a brute force attack.

­Alpha and ­p are sent unprotected, though the user code does a few sanity checks on the values it receives.  This is another likely point of attack.  We should like to know about any. 

The role of ­ivec is to foil any replay attacks by someone spoofing the CA though this is probably overkill. 

SEE ALSO

security-intro(2), security-login(2), logind(8), signer(8)
 

Plan 9  —  June 19, 2000