ADSM-L

Re: Encryption

1994-11-10 10:03:44
Subject: Re: Encryption
From: "David G. Kalenderian" <[email protected]>
Date: Thu, 10 Nov 1994 10:03:44 EST
Paul,

After discussing these questions with other members of our Systems
Programming Group, here's the consensus.

We at MIT would vote to expedite encryption of data sent over the network.
At MIT, encryption of data during transmission is top priority. Spend a
man-week or man-month to implement a solution that only encrypts data
during transmission and is transparent to the end user. Encryption of
data on the physical media is important, but we can wait for a later release.

** For a future release **
>Questions:
>
>1.  Should ADSM allow for keys to be changed on a time basis?

Ideally, yes.
The alternative is keeping the same key indefinitely, which may
increase the risk of compromising security.

>2.  Should ADSM administrators set the keys and provide to end users, end
>    users only set the keys, a combination of above under admin control, etc?

A combination of above under admin control:
For some customers, it might be preferable to have the administrators
provide the keys. However, this means that the administrator can decrypt
end users' data, which won't be acceptable to some customers (possibly
including MIT).  In this case the customer would want the option of
having the end users set the key.

Key management should not be integrated into ADSM.
Instead, an external key management package (KMP) should be allowed for,
with interfaces between ADSM and the package provided.
This approach is modeled after the ACI exits that IBM places in VM, enabling
the use of an external security package such as RACF.
The benefits of this approach are:
a) You can avoid re-inventing the wheel; KMP's are needed in various products.
b) You allow different KMP's to be used (MIT might like to use the KMP that
   Athena provides via its Kerberos software).

>3.  If keys are allowed to be changed, then is the user/site willing to
>    sign up for prompting the end user to enter key-1, key-2, ... key-n
>    for all files to be restored?

Probably not.
The user will want to remember just one key to recall files, even though
the key will be needed to be changed occasionally. This may imply the
re-encryption of stored files.

>4.  Is encryption just needed for transmission and not storage?  ie:
>    encrypt the data over the wire with the session key, but decrypt it before
>    it is stored since the physical media is protected?  Are sites willing
>    to take the performance penalty for the dual encryption?

The option for encrypting stored data is needed in some cases.
I would let the users set their own keys. If an administrator wants to
keep a copy of the key (to allow restoral of data in the user's absence),
I would let each shop work a way of keeping track of this outside of ADSM.
Transmission keys and media-encryption keys should be different.
(This would mean that there is double encryption if a user chooses
to use encryption for media storage of data.)  A different
transmission key is negotiated between the client and server for each
session.

MIT's top priorities are:
1) Avoiding the transmission of unencrypted data.
2) Avoiding the transmission of unencrypted data.
3) Avoiding the transmission of unencrypted data.
4) Obtaining flexibility in key management (probably implying exits).

Dave Kalenderian
Systems Programming Group
M.I.T.
<Prev in Thread] Current Thread [Next in Thread>