ADSM-L

Re: Encryption

1994-11-07 21:35:47
Subject: Re: Encryption
From: Paul Zarnowski <VKM AT CORNELLC.CIT.CORNELL DOT EDU>
Date: Mon, 7 Nov 1994 21:35:47 EST
Paul,

On Mon, 7 Nov 1994 10:05:38 PST Paul L. Bradshaw said:
>We are looking at encryption, but one of the key stumbling blocks is in the
>area of key management.
>
>Questions:
>
>1.  Should ADSM allow for keys to be changed on a time basis?
No.
>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?

In answer to the above two questions, I would argue that the data encryption
keys should be stored on the ADSM server, encrypted with the user's password.
When the user's password is changed (either by the user or by an administrator)
the encryption keys would have to be re-encrypted with the new password.  (*1)
The encryption keys can be passed from the ADSM server to the ADSM client
in an encrypted packet, encrypted with the user's password.  Once the ADSM
client has the data encryption key, they can use it to encrypt data for
transmission to the server (or to decrypt data received from the server).

If you let any person (user or administrator) choose encryption keys for
encrypting stored data, then you must deal with the problem of different data
being encrypted with different encryption keys over time.  This seems to me
to be a problem worth avoiding if at all possible.  As a user, I don't really
want to deal with more keys than I have to.

I think it might be reasonable to let ADSM choose the encryption keys for me,
so that I don't even need to know what they are.  All I would need is the
password for my node.  Using that, if I can retrieve the encryption keys from
the ADSM server, then all I'd need to remember is my password.

Once an encryption key is assigned to my node (or more specifically, to data
which is associated with my node) that key would always be used forever more
to encrypt any additional data.

>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?

I vote no.  This sounds extremely messy, both to implement and from a human
factors point of view.

>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?

First need is for transmission.  However, I don't really relish doing too
much decryption on my ADSM server.  If possible, I would rather encrypt the
data at the client, and leave it encrypted in that same key when storing it
on the server.  This way, all encryption/decryption overhead is borne by the
client, and I get both transmission AND storage encryption.

The control stream (non file data) might need to be encrypted/decrypted by
both client and server, in order to protect filename information which might
also be deemed sensitive data.

>
>There are a lot of questions, and depending on what type of industry your
>company is in will dictate your requirements.  Please let us know what you
>would like in a priority order.  Thanks,
>
>Paul Bradshaw

(*1):  If the data encryption keys are stored on the ADSM server, but
       encrypted with the user's password, I can see a problem since currently
       it is possible to change a user's password without specifying the
       previous password.  This would make it difficult for the ADSM server
       to re-encrypt the data encryption keys, since it would have no way of
       decrypting the data encryption keys without having the old password.

       One way to solve this problem would be to store the data encryption
       keys on the ADSM server twice:  Once encrypted with the user password's
       and once encrypted with a master key, which would be accessible from
       appropriately privileged ADSM administrators.

 Paul Zarnowski
 Cornell University
<Prev in Thread] Current Thread [Next in Thread>