ADSM-L

Re: Confidentiality of client data

1998-07-08 16:26:45
Subject: Re: Confidentiality of client data
From: Ben Kokenge <ben AT EDMS DOT NET>
Date: Wed, 8 Jul 1998 15:26:45 -0500
Here is what I see when this happens.

If the client encrypts the data before sending, then that client
must have some sort of passwd for a seed value to the encryption.
This passwd is really just like having the current passwd for the
node.  Really what is the difference if they get the encryption
passwd or just the node passwd?  I guess then there are two
passwd to supply.  Now taking this further, you one might think
that the data is protected from the ADSM admin. seeing it.  Again
this is of no consequence, because the ADSM admin. can always
reset a node's passwd.  If the ADSM admin. cannot reset a passwd,
then if a users forgets their passwd, their data is lost forever.  So I
really see no use for encryption because protection is always left to a
passwd to view the data.  Actually encrypting does keep a possible
ether-sniffer from violating LAN connections, but that is pretty remote
and extreme.

That is my take.  I'm out, Ben

Luc Busschots wrote:

> Hello ADSMer's,
>
> One of the major concernes of one of our customers to work with us
>  for his backup is the confidentiality of his data.
> One can indeed imagine a scenario where the systemadministrator gets
>  his hands on all the data that is needed for a full ADSM-Server
>  restore from scratch, and installs it on another Server, then reset
>  the passwords of all the nodes (or the ones he is interested in),
>  and is able to restore the customer's data without anybody knowing
>  or noticing anything.
> To assure him of confidentiality of his data, the only solution I
>  see at this moment is encryption of his data before it is sent by
>  the client to the server. This has to be done with respect to the
>  rules that ADSM Server uses to keep track of the data (e.g. encryp-
>  tion of transmitted data is not a valid option, because then the
>  info like filename, size, creationdate, modified, ownership,.. is
>  also encrypted and ADSM Server can't do anything with it.)
> So here are my questions :
>
> Q1 : Has anybody already written applications for encryption of
>  clientdata, based on the ADSM API's, or knows about programs that
>  can do this ?
>
> Q2 : Talking to IBM about this, we came in contact with Endicott/ibm
>  and found out that there is ADSM-Remote client which is targeting
>  for service providers and this client can just do that.
> On the GUI, you can select your files with B (normal backup) or E
>  (backup encrypted), and it works well,.. but,..has a few disadvan-
>  tages for us
>       - Only available on a few platforms
>       - minimum 100 client licenses
>       - only client polling supported (not server prompted)
>       - only one (weak) encryption algorithm (40bit DES)
> At that time, (8 months ago), there were, and I quote
>  "no current plans for new enhancements to the ADSM-Remote clients"
>  " unless you and other potential customers generate sufficient   "
>  " demand, then that possibility could be revisited               "
>  and
>  "regarding future enhancements, would adding encryption support  "
>  " to ADSM V3 make that a viable solution ?                       "
> At that  time, I wasn't aware of this ADSM-L, and had no idea how
>   to find out if other companies would also like this possibility.
> So, is there some interest out there for this encryption or are we
>   the only one to struggle with this ?
>
> Q3 : If Q1 and Q2 do not provide a solution, any other suggestion ?
>      (Either on encryption or on how to assure the confidentiality)
>   Running a preschedule to encrypt data in a special directory but
>   without changing the creationdate or modified date if the original
>   file is not modified and then get ADSM to backup this directory ?
>   I've tested already a lot of these encryption programs and tried
>   to make them work together with ADSM without loosing all the
>   benefits, advantages and features of ADSM, but sofar no good
>   solution found.
>
> Thanks for your replies,
> Luc
>
> ---------------------------------------------------------------
> Busschots Luc
> B.I.C.S.
> Straatsburgstraat 3 rue de Strasbourg
> 1130  Brussels
> Belgium
>
> E-mail :Luc.Busschots AT Cerix DOT com
> Tel : Int-32-2-702.36.12 *******  Fax : Int-32-2-702.36.00
<Prev in Thread] Current Thread [Next in Thread>