Requirements for encrypting tape drives for z/VM

[Jack Slavick]

We are currently exploring the possibility of encrypting all off-site
backups. With only S/W products and the crypto engines currently
available, it looks like encryption in the hardware will be our only
viable option. So...we don't require it now but will in the not so
distant future.

Jack

Jack H. Slavick
Acxiom Corporation
(312) 985 - 2827
>>> ***@us.ibm.com 03/08/06 3:11 PM >>>
[Cross-posted to VMESA-L and LINUX-390]

Hi, Everyone. The VM Development team needs your help once again.

Back in July of last year, IBM published a Statement of Direction for
encrypting tape drives (Announcement 105-241). We would like to know:

- If you currently backup or archive z/VM data, does your business
require
that you encrypt said backups/archives? If so, what are you using?
- If you are not *currently* required to encrypt them, do you expect
those
requirements to be levied against you? If so, when?

Thanks,
Alan

Alan Altmark
Sr. Software Engineer
IBM z/VM Development

[David Boyes]

> - If you currently backup or archive z/VM data, does your
> business require that you encrypt said backups/archives?

Yes.

> If
> so, what are you using?

Emulated 3490 to inline SCSI encryption device to SCSI 3490-F01 on the
MP3K, emulated 3490 to inline SCSI encryption device to DLT on Flex
boxen.

This (IMHO) is a really good reason to finish the SCSI tape device
support and provide 3420/3480/3490 tape emulation for SCSI/FCP devices
in CP. Encryption devices for SCSI/FCP equipment are commodity items,
and are already in place for the open systems boxes. Why invent another
wheel, especially since you've done it before, and existing solutions
are in place and commercially available that have minimal performance
impact on the zSeries side?

[Leland Lucius]

Quoting Alan Altmark <***@us.ibm.com>:

>
> - If you currently backup or archive z/VM data, does your business require
> that you encrypt said backups/archives? If so, what are you using?
> - If you are not *currently* required to encrypt them, do you expect those
> requirements to be levied against you? If so, when?
>

If you were to backup your (native) z/OS environment using these new fangled
tape drives and then attempt to recover the environment while running under
z/VM (disaster recovery), would that mean you'd need to have z/VM support? Or
is the support just for data written directly by z/VM?

Leland

[Thomas Kern]

--- Alan Altmark <***@us.ibm.com> wrote:
> Hi, Everyone. The VM Development team needs your help once again.
>
> Back in July of last year, IBM published a Statement of Direction for
> encrypting tape drives (Announcement 105-241). We would like to know:
>
> - If you currently backup or archive z/VM data, does your business require
> that you encrypt said backups/archives? If so, what are you using?

All of our backup/archive data should be encrypted as soon as we can find a
mechanism to do it without an offsite contractor or non-mainframe attached
hardware/processes.


> - If you are not *currently* required to encrypt them, do you expect those
> requirements to be levied against you? If so, when?

It will probably be required as soon as we give up trying to encrypt this
information. I estimate less that 12 months before such a requirement surfaces
at some level in the department.

/Thomas Kern
/U.S. Department of Energy
/301-903-2211


__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

[Leland Lucius]

Quoting Alan Altmark <***@us.ibm.com>:

> On Wednesday, 03/08/2006 at 03:53 CST, Leland Lucius <***@homerow.net>
> wrote:
> > If you were to backup your (native) z/OS environment using these new
> fangled
> > tape drives and then attempt to recover the environment while running
> under
> > z/VM (disaster recovery), would that mean you'd need to have z/VM
> support?
>
> Yes.
>
In that case, tape encryption is becoming a requirement where I work, but it
will probably be done on the host until we find out it's gonna chew up too many
resources and then someone will have to open up the wallet for drives. :-)

So...probably...eventually.

(How's that for a solid answer? ;-))

Leland

[O'Brien, Dennis L]

Alan,
We have a requirement that media that leaves Bank premises and contains
customer data must be encrypted with a Bank-approved algorithm. If the
data isn't encrypted, it must be in the custody of a Bank employee while
in transit (i.e. no FedEx). Our largest VM system uses channel-extended
tape drives for DR backups, so it's not affected by this requirement.
We briefly used the encryption feature in VM:Backup for DR backups of a
smaller system, but VM:Backup uses the DES algorithm, which isn't on our
approved list. We had to continue hand-carrying the tapes, so we turned
off the encryption. AES is our preferred encryption algorithm, but
Triple DES and a couple of others are also acceptable.


Dennis O'Brien

"Of all tyrannies, a tyranny exercised for the good of its victims may
be the most oppressive. It may be better to live under robber barons
than omnipotent moral busybodies. The robber baron's cruelty may
sometimes sleep, his cupidity may at some point be satiated; but those
who torment us for our own good will torment us without end, for they do
so with the approval of their own conscience."
-- C.S. Lewis

-----Original Message-----
From: VM/ESA and z/VM Discussions [mailto:VMESA-***@LISTSERV.UARK.EDU] On
Behalf Of Alan Altmark
Sent: Wednesday, March 08, 2006 13:12
To: VMESA-***@LISTSERV.UARK.EDU
Subject: Requirements for encrypting tape drives for z/VM

[Cross-posted to VMESA-L and LINUX-390]

Hi, Everyone. The VM Development team needs your help once again.

Back in July of last year, IBM published a Statement of Direction for
encrypting tape drives (Announcement 105-241). We would like to know:

- If you currently backup or archive z/VM data, does your business
require
that you encrypt said backups/archives? If so, what are you using?
- If you are not *currently* required to encrypt them, do you expect
those
requirements to be levied against you? If so, when?

Thanks,
Alan

Alan Altmark
Sr. Software Engineer
IBM z/VM Development

[Eric Vaughan - illustro Systems]

Dennis:

You could take a look at our solution, which provides an ESCON-attached
network appliance for encrypting tape data and then transporting to an
offsite location, called z/Encrypt (www.zencrypt.com). The product is
agnostic with respect to data sources, and will work for any tape output
regardless of format.

*-------------------------------------------------------------------------*
Eric Vaughan
illustro Systems International, LLC
*** See The Light ***
tel: [phone] * fax: [phone]
www.illustro.com

-----Original Message-----
From: VM/ESA and z/VM Discussions [mailto:VMESA-***@LISTSERV.UARK.EDU] On
Behalf Of <Dennis Schaffer>
Sent: Wednesday, March 08, 2006 5:30 PM
To: VMESA-***@LISTSERV.UARK.EDU
Subject: Re: Requirements for encrypting tape drives for z/VM

Alan,

Our company has a loose-at-this-point "future direction" that any data
leaving the physical premises be encrypted. That is currently implemented
where technology is readily available, such as corporate laptop hard
drives. The requirement will likely harden either when we experience an
incident or when our various auditors require it.

On our mainframe z/OS and z/VM systems, we're trying to identify options to
handle our backup and archival data, primarily taken off-site for disaster
recovery purposes.

Our z/VM data is backed up for DR purposes using z/OS facilities; IBM and
several ISVs have announced tools for that environment, which we're
exploring. My primary VM concern is the archival (VM:Archive) data, which
is backed up on z/VM to 3590 ATLs; to my knowledge, no facility exists for
encrypting that data.

Dennis Schaffer
Mutual of Omaha





"Alan Altmark"
<***@us.
ibm.com> To
Sent by: "VM/ESA VMESA-***@LISTSERV.UARK.EDU
and z/VM cc
Discussions"
<VMESA-***@LISTSERV Subject
.UARK.EDU> Requirements for encrypting tape
drives for z/VM

03/08/2006 03:11
PM


Please respond to
"VM/ESA and z/VM
Discussions"
<VMESA-***@LISTSERV
.UARK.EDU>






[Cross-posted to VMESA-L and LINUX-390]

Hi, Everyone. The VM Development team needs your help once again.

Back in July of last year, IBM published a Statement of Direction for
encrypting tape drives (Announcement 105-241). We would like to know:

- If you currently backup or archive z/VM data, does your business require
that you encrypt said backups/archives? If so, what are you using?
- If you are not *currently* required to encrypt them, do you expect those
requirements to be levied against you? If so, when?

Thanks,
Alan

Alan Altmark
Sr. Software Engineer
IBM z/VM Development

[Gary Eheman]

On Wed, 8 Mar 2006 16:40:54 -0500, David Boyes <***@sinenomine.net> wrote:

I just announced in a presentation at SHARE this week that we should have
encryption support in the emulated tape control units in the next FLEX-ES V7
release (not V6) for emulated tapes on disk. This support is for tapes on
disk only and not SCSI tapes. As mentioned, a hardware encryption device
between the SCSI adapter and a SCSI tape drive is required if you want the
data encrypted on a scsi tape.



>
>> - If you currently backup or archive z/VM data, does your
>> business require that you encrypt said backups/archives?
>
>Yes.
>
>> If
>> so, what are you using?
>
>Emulated 3490 to inline SCSI encryption device to SCSI 3490-F01 on the
>MP3K, emulated 3490 to inline SCSI encryption device to DLT on Flex
>boxen.
>
>This (IMHO) is a really good reason to finish the SCSI tape device
>support and provide 3420/3480/3490 tape emulation for SCSI/FCP devices
>in CP. Encryption devices for SCSI/FCP equipment are commodity items,
>and are already in place for the open systems boxes. Why invent another
>wheel, especially since you've done it before, and existing solutions
>are in place and commercially available that have minimal performance
>impact on the zSeries side?
>========================================================================

--
Gary Eheman
Fundamental Software, Inc

[Alan Ackerman]

Dennis forgot to mention that we discovered that there is currently no way to encrypt DB2/VM
tape backups. Please keep DB2 in mind in your solution. We decided to back up DB2 to disk (SFS)
and then use VM:Backup to back that up. But then we found out CA doesn't support industrial-
strength encryption. Phoo!

If there is an encryption solution, it should either use the hardware encryption facilities of the z9
hardware, or offboard encryption hardware.

There should also be compression. And please remember that you cannot compress encrypted
data -- compression must come first. Tape-drive compression is worthless if the encryption is on
the mainframe.

Alan Ackerman
Alan (dot) Ackerman (at) Bank of America (dot) com

On Wed, 8 Mar 2006 23:06:25 -0800, O'Brien, Dennis L <Dennis.L.O'***@bankofamerica.com>
wrote:

>Alan,
>We have a requirement that media that leaves Bank premises and contains
>customer data must be encrypted with a Bank-approved algorithm. If the
>data isn't encrypted, it must be in the custody of a Bank employee while
>in transit (i.e. no FedEx). Our largest VM system uses channel-extended
>tape drives for DR backups, so it's not affected by this requirement.
>We briefly used the encryption feature in VM:Backup for DR backups of a
>smaller system, but VM:Backup uses the DES algorithm, which isn't on our
>approved list. We had to continue hand-carrying the tapes, so we turned
>off the encryption. AES is our preferred encryption algorithm, but
>Triple DES and a couple of others are also acceptable.
>
>
>Dennis O'Brien
>
>"Of all tyrannies, a tyranny exercised for the good of its victims may
>be the most oppressive. It may be better to live under robber barons
>than omnipotent moral busybodies. The robber baron's cruelty may
>sometimes sleep, his cupidity may at some point be satiated; but those
>who torment us for our own good will torment us without end, for they do
>so with the approval of their own conscience."
> -- C.S. Lewis
>
>-----Original Message-----
>From: VM/ESA and z/VM Discussions [mailto:VMESA-***@LISTSERV.UARK.EDU] On
>Behalf Of Alan Altmark
>Sent: Wednesday, March 08, 2006 13:12
>To: VMESA-***@LISTSERV.UARK.EDU
>Subject: Requirements for encrypting tape drives for z/VM
>
>[Cross-posted to VMESA-L and LINUX-390]
>
>Hi, Everyone. The VM Development team needs your help once again.
>
>Back in July of last year, IBM published a Statement of Direction for
>encrypting tape drives (Announcement 105-241). We would like to know:
>
>- If you currently backup or archive z/VM data, does your business
>require
>that you encrypt said backups/archives? If so, what are you using?
>- If you are not *currently* required to encrypt them, do you expect
>those
>requirements to be levied against you? If so, when?
>
>Thanks,
> Alan
>
>Alan Altmark
>Sr. Software Engineer
>IBM z/VM Development
>===========================================================
==============

[Adam Thornton]

On Mar 10, 2006, at 9:18 AM, Edward M. Martin wrote:

> Hello Alan,
>
> You wrote this.
>
>>> If there is an encryption solution, it should either use the
>>> hardware
>>> encryption facilities of the z9
>>> hardware, or offboard encryption hardware.
>>>
>>> There should also be compression. And please remember that you
>>> cannot
>>> compress encrypted
>>> data -- compression must come first. Tape-drive compression is
> worthless
>>> if the encryption is on
>>> the mainframe.
>
> I think I follow but I want to make sure. I think you mean you
> can compress encrypted data but that the compression ratio would
> not be
> lousy.

Would be lousy: in fact, it should be impossible to compress an
encrypted stream. Specifically, encryption makes your data stream
look like random bits, and random bits don't compress at all. If
they DO compress, they're not random, since compression is nothing
but exploiting regularities in the data stream and expressing the
most common patterns in a coded compact form.

> And if you did encrypt the data first, then you would need to reverse
> the process in the exact order to be able to use that data.

Well, sure, but that's the case with any encryption and compression
scheme: encrypting a compressed stream will yield a different answer
than compressing an encrypted stream. Applying the inverse operations
in the wrong order will yield gibberish.

Adam

[Brian Nielsen]

On Fri, 10 Mar 2006 09:30:08 -0600, Adam Thornton
<***@sinenomine.net> wrote:

>On Mar 10, 2006, at 9:18 AM, Edward M. Martin wrote:
>
>> Hello Alan,
>>
>> You wrote this.
>>
>>>> If there is an encryption solution, it should either use the
>>>> hardware
>>>> encryption facilities of the z9
>>>> hardware, or offboard encryption hardware.
>>>>
>>>> There should also be compression. And please remember that you
>>>> cannot
>>>> compress encrypted
>>>> data -- compression must come first. Tape-drive compression is
>> worthless
>>>> if the encryption is on
>>>> the mainframe.
>>
>> I think I follow but I want to make sure. I think you mean you
>> can compress encrypted data but that the compression ratio would
>> not be
>> lousy.
>
>Would be lousy: in fact, it should be impossible to compress an
>encrypted stream. Specifically, encryption makes your data stream
>look like random bits, and random bits don't compress at all.

Actually, it's usually worse than that - putting encrypted/random data
through a compression algorithm usually results in a larger data stream
than the original data stream.

Brian Nielsen

[Adam Thornton]

On Mar 10, 2006, at 9:47 AM, Brian Nielsen wrote:
> Actually, it's usually worse than that - putting encrypted/random data
>
> through a compression algorithm usually results in a larger data
> stream
>
> than the original data stream.

Well, yeah. A compressed text is essentially a codebook defining a
sequence mapping from the original onto the compressed version, plus
the compressed version. If the entropy of the input stream is very
high, then the overhead of the codebook adds to the size of the
stream, with no reduction for the sequence remapping.

Smart compression algorithms, however, should be able to say, "Wow.
That didn't help at all! Never mind!" and just give you the original
stream in that case.

Adam

[Bob Bolch]

I've been interested in this topic, but I wonder about the usefulness
of an encryption mechanism in a tape drive, if you have to go to a DR
site without the decryption hardware.

My thinking is that you want the keys to be managed by the backup/restore
software, and fed into the drive at the point where the encrypted portion
of the tape starts. Then, if the hardware encryption was NOT available, a
compatible backup or restore could be done by having the backup software use
software encryption/decryption instead.

I suppose that the encrypting tape drive could be designed so that the tapes
were unreadable by non-encrypting drives. The thinking might be that
allowing
a non-encrypting drive to read the encrypted data allows a thief to try
brute
force repetition to find the secret key. This kind of architecture would
prohibit
any software implementations to decode the data even if the key were
available
to the restore software.

Any thoughts on this?

Bob Bolch

[Alan Ackerman]

Any good encryption algorithm will produce text that is 100% "random". If it isn't, that would give
someone a hook to decrypt it. Put it another way, let's say you use a 256 bit encryption key, and
then after encryption you compress the the resulting text to 75%, then in effect you only got 75%
of 256 bits = 192 bits worth of encryption. In fact, as others pointed out, most compression
methods will make encrypted data grow, not shrink.

So plain text -> compression -> encryption -> media will be smaller than the original plain text,
but plain text -> encryption -> compression -> media will be the same size (or larger) than the
plain text.

This phenomenon bit my boss -- when the Bank introduced VPN encryption as a requirement to
get in to the Bank, his modem traffic slowed down significantly. Modern modems compress data
quite a bit -- but he lost all that compression when we went to VPN. (DSL isn't available where he
lives and he refuses to have cable.)

On Fri, 10 Mar 2006 10:18:38 -0500, Edward M. Martin <***@aultman.com> wrote:

>Hello Alan,
>
> You wrote this.
>
>>> If there is an encryption solution, it should either use the hardware
>>> encryption facilities of the z9
>>> hardware, or offboard encryption hardware.
>>>
>>> There should also be compression. And please remember that you cannot
>>> compress encrypted
>>> data -- compression must come first. Tape-drive compression is
>worthless
>>> if the encryption is on
>>> the mainframe.
>
> I think I follow but I want to make sure. I think you mean you
>can compress encrypted data but that the compression ratio would not be
>lousy.
>And if you did encrypt the data first, then you would need to reverse
>the process in the exact order to be able to use that data.
>
>
>Ed Martin
>Aultman Health Foundation
>330-588-4723
>***@aultman.com
>ext. 40441
>===========================================================
=============