Kelly,
    I'm using TS1120 drives and wrestled with the same issues.  I ended
up using system encryption with the EKM because:

1. It provides the greatest level of granularity - Individual tape
drives and volumes may be designated for encryption
2. TSM is oblivious to this type of encryption thus limiting any
incompatabilities and avoiding the situatiion you describe.
3. Management of the encryption keys can be performed by our security
group with minimal interaction with TSM
4. Other applications can use the encrypted tape drives (with
appropriate library partitioning).
5. It simplifies any data sharing with partners - we can create a tape
with a unique key for that business partner or read a tape from a
business partner with their key.  All without regard to TSM.

I currently have one library manager with two library clients at a
single site with a 700TB TS3500 library.
I am expanding to two sites each with a TSM library manager, 8 TSM
library clients, a couple of LAN-Free clients and NDMP backups with a
1.2PB TS3500 library at each site.

I need to be able to recover one site to the other.  Using System level
encryption, I have synchronized keys at both sites, thus greatly
simplyfying recovery efforts.  The synchronized keys also provide a
means of failover protection in that the encryption key may be provided
from any of four key managers - two located at each site to either
library.

TSM database backup will be done direct to tape for offsite and a second
copy to another server for onsite recovery.  The encryption keys are
stored on alternate media which is refreshed whenever there is a key
change.


Cheers,
Neil Strand
Legg Mason
Storage Engineer
(410) 580-7491


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Kelly Lipp
Sent: Monday, August 13, 2007 4:20 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] LTO4 and TSM Encryption of Storage Pool Volumes and DB
Backup Tapes

Folks,

I'm trying to plug the hole in the system here.  With TSM V5.3.5.2 and
5.4.0.2 LTO4 drives and their encryption functionality can finally be
exploited at the application level.  Within TSM, we use device classes
to enable this.  So I'm thinking one could have one device class
supporting encryption and another not (both in the same library) and
have pools associated with these device classes, blah, blah, blah.  You
get the idea.  Cool, cool.

OK, so now all the encryption keys are stored in the TSM database.  The
problem is I now create an un-encrypted db backup tape to send offsite
with my encrypted volumes and I've a whee bit of a problem.

How are others rectifying this: use System level or library level
instead of or in addition to Application Managed with TSM?  Keep the
backup tape and the storage pool volumes separate (that's gotta be a bad
idea from the get go)?  Other ideas?

Unless I'm missing something, this just can't work well at all.  Perhaps
a switch on the backup db command... (but then who would manage that
key?)

The genesis of this is my attempt to get my hands around AME, SME and
LME.  Whew: you want a headache just start reading about all of that.
And if that's not enough, IBM's Encryption Key Management Java
application is real fun.  The more I read the more I like client side
encryption.  But everyone is screaming to encrypt everything.

Share your thoughts.  I intend to write a short white paper on all of
this once I get my head around it all.

Kelly J. Lipp
VP Manufacturing & CTO
STORServer, Inc.
485-B Elkton Drive
Colorado Springs, CO 80907
719-266-8777
lipp AT storserver DOT com


IMPORTANT:  E-mail sent through the Internet is not secure. Legg Mason 
therefore recommends that you do not send any confidential or sensitive 
information to us via electronic mail, including social security numbers, 
account numbers, or personal identification numbers. Delivery, and or timely 
delivery of Internet mail is not guaranteed. Legg Mason therefore recommends 
that you do not send time sensitive 
or action-oriented messages to us via electronic mail.

This message is intended for the addressee only and may contain privileged or 
confidential information. Unless you are the intended recipient, you may not 
use, copy or disclose to anyone any information contained in this message. If 
you have received this message in error, please notify the author by replying 
to this message and then kindly delete the message. Thank you.