[Top] [Prev] [Next]


Login - introduction to the Login module


include "security.m";
login:= load Login Login->PATH;


The login module provides routines to communicate with a Certifying Authority (CA) in order to create a Keyring->Authinfo adt. (See Limbo Keyring Modules). It does this assuming a secret, a password, has already been established between the user and the CA.

The password is used by the encrypted key exchange protocol defined below to establish a secure channel between the user and CA. The description uses the following notation:

an 8 - byte random number chosen for this conversation


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


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];


a Diffie-Hellman base used system wide


a Diffie-Hellman modulus used system wide

key (m)

m encrypted using the RC4 algorithm with key


a random number of the same order as p.


the Diffie-Hellman secret alpha**(r0*r1) mod p

In the following protocol, the notation "user->CA xxx" means that a user sends the message "xxx" to the certifying authority. At any point in the exchange, either party can send an error instead of a message 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 base 64 encoded, constraining the possible values of each byte. This could aid a brute force attack.

The values alpha and p are sent unprotected, though the user code does a few sanity checks on the values it receives. This is another potential point of attack.

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

See Also

B. Schneier, Applied Cryptography, 1996, J. Wiley & Sons, Inc.

[Top] [Prev] [Next]

Copyright © 1996,Lucent Technologies, Inc. All rights reserved.