/sys/doc/ Documentation archive

Security in Inferno

Summary

Inferno uses encryption for:

The encryption algorithms used and/or provided by Inferno are:

Our Elgamal signatures use keys with moduli up to 4096 bits. The default size is 512 bits. Tools provided with inferno depend on these signatures for authentication. Library interfaces are provided for Limbo programs to sign and verify signatures. There are no tools or library interfaces for using Elgamal for encrypting.

The system is not tied to Elgamal. All keys and exchanges are parameterized to use any signature algorithm. We include only Elgamal for licensing reasons.

Conversations between Inferno instances can be encrypted using 56-bit DES keys or unlimited length RC4 keys. Because of US State Department restrictions, the internet release is limited to 40-bit RC4 keys and does not contain the DES interface.

Our Diffie-Hellman key exchange also uses moduli of up to 4096 bits. Once again the default is 512 bits.

Mutual Authentication

Authentication is performed using public key cryptography. Parties register by having their public keys signed by a certifying authority (CA). The signature is an Elgamal signature of the a secure hash (SHA or MD5) of the name of the party, his public key, and an expiration time. The signature (wich contains the name of the signer) along with the signed information is termed a certificate.

When parties communicate, they use the Station to Station protocol to establish identities of the two parties and a mutually known secret. The STS protocol uses Diffie Hellman (DH) to agree on a number bounded by the DH modulus. This number can be known only to both parties. The DH protocol is secured against third party attacks by having the parties exchange certificates and then digitally signing key parts of the protocol. In the following 'R' is the caller and 'E' is the callee.

	R->E	alpha**r0 mod p, caller's cert
	E->R	alpha**r1 mod p, callee's cert
	R->E	sign(caller's public key, alpha**r0 mod p, alpha**r1 mod p)
	E->R	sign(callee's public key, alpha**r1 mod p, alpha**r0 mod p)

The DH constants 'alpha' and 'p' are obtained from the CA along with the certificate. Both caller's and callee's certificate must come from the same CA.

The random number, 'alpha**(r0*r1) mod p', can then be used either to digest or encrypt a conversation between the parties.

Line Security

A network conversation can be secured against modification alone or against both modification and snooping. To secure against modification, we append a secure MD5 or SHA hash (called a digest),

	hash(secret, message, messageid)

to each message. 'Messageid' starts at 0 and is incremented by one for each message sent.

To secure against snooping, we encrypt the complete conversation using either RC4 or DES. We support both DES chain block coding and electronic code book. Messages are rounded up to 8 byte blocks in the case of DESECB encoding.

We use the same encapsulation format as Netscape's Secure Sockets Layer. It is possible to encapsulate any message stream an arbitrary number of times using different algorithms to achieve whatever secrecy you wish.

Certificate/Key Management

Certificates are passed between CA's and users using an encrypted key exchange protocol. Users first have to establish a password, P, with a CA. They can then get certificates for their public keys using the following protocol.

	U->CA	name, initialization vector
	CA->U	RC4(P ^ initialization vector, alpha**r0 mod p), alpha, p
	U->CA	alpha**r1 mod p

<turn on SHA digesting using alpha**(r0*r1) mod p as a secret>

	CA->U	signer's public key
	U->CA	user's public key
	CA->U	user's certificate

Certificates can be ephemeral, lasting until the next reboot, or can be stored in a file in a directory, usually /usr/username/keyring. The current practice is for server programs use the certificate in the file /usr/username/keyring/default and for clients to use the certificate in /usr/username/keyring/destination-name.