Limbo Keyring Modules — Inferno 1.1ed

The Keyring module relates to security and encryption related functions. The modules are as follows:

Keyring Modules


auth	authenticate a connection
readauthinfo
writeauthinfo
certtostr	encryption key conversion functions
pktostr, sktostr,
strtocert, strtopk, strtosk
gensk	generate keys
genSKfromPK, sktopk,
dhparams
getstring	delimited I/O
putstring, getbytearray,
putbytearray, puterror
ipint	infinite precision integer utility functions
login	get an Authinfo adt from a certificate authority
getauthinfo
sign	cryptographic digests and digital signatures
sha, md5, sign, verify

Synopsis

include "keyring.m"
keyring:= load Keyring Keyring->PATH;
SigAlg: adt
{
  name:  string;
};
PK: adt
{
  sa:    ref SigAlg;
  owner: string;
};
SK: adt
{
  sa:     ref SigAlg;
  owner:  string;
};
Certificate: adt
{
  sa:     ref SigAlg;
  ha:     string;
  signer: string;
  exp:    int;
};
DigestState: adt
{
  x:      int;
};
Authinfo: adt
{
  mysk:  ref SK;
  mypk:  ref PK;
  cert:  ref Certificate;
  spk:   ref PK;
  alpha: ref IPint;
  p:     ref IPint;
};

Description

The Keyring module contains the types and functions that are necessary to provide secure communications in Inferno. The functions:

Perform infinite precision modular arithmetic (see ipint).

Compute cryptographically secure digests (see sign).

Generate public/private key pairs and transform them to and from text format (see gensk).

Create and verify cryptographic signatures using the public keys (see auth).

Authenticate the parties on a connection (see auth).

Read and write files containing the information needed to authenticate the parties on a connection.

Send Limbo byte arrays and strings across a connection

High Precision Arithmetic

The IPint adt provides certain cryptographic functions so that various popular public key algorithms can be implemented directly in Limbo. The current implementation limits the maximum integer to 2³¹⁹²-1.

An IPint can be converted into two external formats: an array of bytes (in which the first byte is the highest order byte of the integer) that is useful when communicating with the kernel's internal ssl device (#D) (see ssl ); and a MIME base 64 format that allows an IPint to be stored in files or transmitted across networks in text form.

Public Key Cryptography

Inferno relies on public key cryptography for digital signatures. Each Inferno user can generate a pair of matched keys, one public and one private. The private key is used to digitally sign data, the public one to verify the signature. Public key algorithms have been chosen to make it difficult to spoof a signature or guess the private key.

For public keys algorithms to work, there must be a way to distribute the public keys. That is, in order to verify that X signed something, we have to know X's public key. To simplify the problem, a trust hierarchy is set up that requires users to know only the public keys of the certifying authorities (CA) contained in the SIGNER variable. After generating a public key, one can have the concatenation of one's name, a key expiration date, and a key signed by the certifying authority. This information, together with the name of the SIGNER and the signature, is called a certificate.

At the beginning of a conversation, the parties exchange certificates. They then use the SIGNER's public key to verify each other's public keys. The CA's public key, a system-wide Diffie-Hellman base and modulus, one's private key, one's public key and certificate are kept in an abstract data type called Keyring->Authinfo. An Authinfo adt is read from a file using the Keyring->readauthinfo function or written to a file using Keyring->writeauthinfo function. See auth.

Authinfo adts are normally created during login and registration.

Authentication

Two parties conversing on a network connection authenticate each other's identity using the keyring->auth function. See auth. Keyring->auth uses the Keyring->Authinfo information to perform a Station-to-Station (STS) authentication protocol. STS authenticates a party's identity to the other and establishes a random bit string known only to the two parties. This bit string is used as a key either to encrypt or to authenticate subsequent messages sent between the two parties.

Secure Communications

After exchanging secrets, communicating parties can encode the conversation to guarantee varying levels of security:

none

messages cannot be forged

messages cannot be intercepted

Encoding uses the same line formats as defined by the Secure Sockets Layer. See

ssl

Limbo Modules

Login and Registration

The Inferno authentication procedure requires that both parties have a Keyring->Authinfo adt containing a locally generated public/private key pair, the public key of a commonly trusted CA, and a signed certificate from the CA binding the party's identity to his/her public key. This Authinfo adt is normally kept in a file. However, at some point it has to be generated and conveyed securely between the user's machine and the CA. There are two ways to do this, the login and registration procedures.

Both login and registration require an out-of-band channel between the CA and the user.

The login procedures are used by typed commands and by programs using the Tk GUI. The login procedure is based on the CA and the user having established a common secret or password. This is done off line either by mail or telephone. This secret is then used to provide a secure path between CA and user machine to transfer the certificate and CA public key. See Limbo Math Modules .

The registration procedure is built into the Mux interface and is intended for the set top box environment. When the set top box is first turned on, it creates a public/private key pair and dials the service provider's CA to get a key signed. The CA returns its public key and a signed certificate, blinded by a random bit string known only to the CA. A hash of the information is then displayed on the user screen. The user must then telephone the CA and compare this hashed foot print with the one at the CA. If they match and the user proves that he is a customer, the CA makes the blinding string publicly known.

Data Types


SigAlg	The SigAlg adt contains a single string that specifies the algorithm used for digital signatures. The allowable values are MD5 and SHA, which specify which one-way hash function is used to produce a digital signature, or message digest. In general, a one-way hash function converts an arbitrary length message to a unique fixed-length message digest. MD5 produces a 128-bit; SHA produces a 160-bit hash.
PK and SK	The PK adt contains the data necessary to construct a public key; the SK adt contains the data necessary to construct a secret key. Both keys are built from the combination of a specified signature algorithm and a string representing the name of owner of the key.
Certificate	The Certificate adt contains a digital signature with the certification of the trusted authority (CA).
DigestState	The DigestState adt contains the state of partially completed hash functions during processing.
Authinfo	The Authinfo adt contains an individual user's private and public key, the signer's certificate and the signer's public key, and the Diffie-Hellman parameters.

Museum