Proposal for a UF PEM Gateway
Divya Kapur and R. Newman-Wolfe
Abstract
This document lists the requirements and a brief implementation approach
for a PEM gateway for the University of Florida.
The gateway is intended to provide for encryption and authentication of
email, for distribution of public keys, and for voluntary escrowing of
private keys of UF staff, faculty and students.
The relevant tool to be used (RSAREF) is also discussed.
While the descriptions are comprehensive for these services, within
the context of a scope of work for one summer of activity only some
portion of the total system can be completed.
This document is intended to serve as a starting point, both to guide
later development and to allow selection of the initial work to be
completed in the summer of 1995.
Introduction
UFRFC 7 explains the need for the encryption and authentication of email.
Several options are available for the encryption and authentication of email,
but it is not feasible for all users independently to recollect the public
key of every local and external person with whom they correspond.
Although electronic key rings exist, it is neither efficient nor
generally desirable for each user to keep a copy of the public key of
each correspondent.
An external user would find it convenient to send mail to anyone inside
UF using a single key.
A server in this case would route the mail to the correct user encrypted
with his own personal key.
Those attempting to establish communications with a UF
person are likely to find it easier to obtain the UF public key than
the public key of an individual.
This is of importance both to those sending confidential email to
the UF person and for a UF person sealing email to someone else.
Finally, for integrity and authenticity of official UF documents,
the UF public key should be used, and a gateway can provide a
convenient way for authorized people to sign and seal documents.
Thus a PEM gateway server is needed.
Objectives
We assume that the UF public key will be widely and accurately available
to intended correspondents, both on and off campus.
Ultimately, the functions of this gateway will be to:
- accept incoming mail destined for UF person A encrypted with
the UF public key, decrypt the mail, reencrypt the mail using
person A's public key, and forward the mail to person A;
- accept incoming mail from person B destined for UF person A and
sealed with person B's private key, authenticate the seal and
perform integrity checks as indicated, reseal the mail using
UF's private key, and forward the mail to person A, who may then
verify the mail using UF's public key;
- accept outgoing mail to person B from UF person A encrypted with
UF's public key, decrypt the mail, reencrypt the mail using
person B's public key, and forward the mail to person B;
- accept outgoing mail from UF person A and
sealed with person A's private key, authenticate the seal
(including the identity of person A) and perform integrity checks
as indicated, add a line stating that the mail has been verified
by the UF PEM gateway with the originator's identity, reseal the
mail (including the addendum) using UF's private key,
and forward the mail to its destination, where it may then be
verified using UF's public key.
In addition the gateway should maintain a key cache for UF people
and some frequently accessed outside locations.
We anticipate key pair generation to be performed locally in a distributed
fashion, and there must be some other procedures in place that allow
reliable and secure registration of the public key for individuals.
The distribution of UF personnel public keys we expect to be handled
through Ph.
To obtain public keys for external users and sites, the gateway eventually
should be able to access remote key servers, but initially we expect these
keys to be entered by the gateway administrator.
In addition, it is desirable that the gateway provide a private key
escrow service, available to UF personnel on a volunteer basis.
Approach
Several cryptographic options are available for this purpose, among them
PGP and RIPEM.
Unfortunately, PGP currently does not have an API available for coding
applications such as the one proposed herein.
Mail Handling
Incoming mail would be encrypted using UF's public key which is assumed to
be universally known.
Incoming mail will also include an "id" field that tells the gateway
to whom the mail ultimately is to be delivered.
The server given this information, decrypts the mail using UF's key,
re-encrypts it using the individual's public key (obtained from the key cache)
and re-transmits the message to the ultimate recipient.
An outgoing message is handled in the reverse fashion;
it is decrypted using the user's private key and re-encrypted using
UF's public key before being sent out to the outside world.
The above two procedures ensure the privacy of email. To check the integrity,
a block containing the following is used by the user for outgoing mail:
IDi, Text, Seal(Text, ki),
where IDi is the identity of the originator, Text is the body of the message,
ki is the private key of the originator, and Seal(Text, ki) is a
cryptographic seal on the text using ki.
The text is sealed using a sealing function indicated in the PEM message,
and anyone can verify that the text came from IDi by "opening" it using
the user's public key.
The server verifies the message for integrity and resends the following:
IDi, Text, Seal(IDi, Text, k-UF),
where k-UF is the UF private key.
An incoming sealed message is opened using the relevant external public
key from the key cache, verified and re-sealed using UF's private key
in a similar manner.
Private Key Escrowing
The escrow mechanism will be made available to prevent loss of information
on the untimely death or illness of an individual.
A secure group of users is pre-determined (depending perhaps on the
individual whose key is escrowed) and encrypted data will be decrypted
only when an appropriate subset of the escrow group all give their permission.
For example, the escrow set for a faculty member might include four classes:
departmental (the chair, associate chair, administrative assistant),
college level (each dean), and university-wide (the president, the provost,
and other designated high-level administrators), and a group of faculty
elected by the faculty as a whole.
If professor X becomes deranged and is unwilling or incapable of decrypting
documents of importance to the University, one member of each of these
groups could indicate their permission by entering their own password into
a program run by the server.
The program would then verify the group memberships (based on their
identities as known at the time from their passwords and verified by
checking the password in the standard fashion), and if the conditions were
met, the program would then used stored encrypted information and the
password of each of the granting members to decrypt the escrowed private
key, and decrypt the desired document list (also entered into the program
and displayed to the granting members).
The document is decrypted and made available without revealing the escrowed
private key or the password (of the deranged professor or of the granting
members).
The entire process must be repeated for each document list.
Key Distribution
For local key generation the user requests a key pair from a key generation
program.
The key generator generates both public and private keys, and asks the
user for a password with which to encrypt the private key for storage.
The public key is distributed via Ph (Fig 1) and the encrypted private
key is stored on the server's key cache (as well as locally for the user).
Any other local user can find the user's public key using Ph, and
either use it to encrypt a message or validate a seal.
Users can decrypt messages encrypted with their public keys, or seal
messages they originate, by supplying their password, which used locally to
decrypt their encrypted private key.
External Code Used
RSAREF is a cryptographic toolkit for PEM.
The package includes the following routines which will be used for the
purposes outlined above:
- R_SealPEMBlock
- computes a digital signature and encrypts a message
- R_OpenPEMBlock
- decrypts an encrypted message and verifies a digital signature
- R_GeneratePEMKeys
- generates an RSA public/private key pair
References
UFRFC 7 , PEM Working Group, 1994.
RSAREF documentation (~divya/SECURITY/RSA/doc/rsaref.txt)
This document is
copyright 1995
by Richard E. Newman-Wolfe and Divya Kapur.
Send comments to nemo@cis.ufl.edu or divya@cis.ufl.edu