LOGIN(6)LOGIN(6)NAMElogin - 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 chan‐
nel 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→CA name
CA→user ACK
user→CA ivec
CA→user key(alpha**r0 mod p), alpha, p
user→CA alpha**r1 mod p
CA→user CA's public key, SHA(CA's public key + secret)
user→CA user's public key, SHA(user's public key + secret)
CA→user user'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 san‐
ity 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 ALSOsecurity-intro(2), security-login(2), logind(8), signer(8)LOGIN(6)