Customer is Using CPACF (Crypto) purchased Crypto Express

[Arye Shemer]

Hello,

Customer is currently using CPACF to encrypt his data before writing to
disks.

Customer intent to purchased Crypto Express and want to use it to continue
to encrypt the data before writing to the disks,

Are there any compatibility issues ?

Are there any know documents which deals/explain with issues involved ?

Thanks,

Arye Shemer.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Tony Thigpen]

For encrypting "data at rest", the CPACF is really all he needs. The
Crypto Express is intended to speed up key negotiations between sites,
something not needed for his intended plans.

Tony Thigpen

Post by Arye Shemer
Hello,
Customer is currently using CPACF to encrypt his data before writing to
disks.
Customer intent to purchased Crypto Express and want to use it to continue
to encrypt the data before writing to the disks,
Are there any compatibility issues ?
Are there any know documents which deals/explain with issues involved ?
Thanks,
Arye Shemer.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Mark Jacobs - Listserv]

Encryption/decryption without a CryptoExpress only supports clear keys,
not protected or secured encryption keys. Might be enough for the OP,
but wouldn't fly in my environment.

June 12, 2017 at 7:22 AM
For encrypting "data at rest", the CPACF is really all he needs. The
Crypto Express is intended to speed up key negotiations between sites,
something not needed for his intended plans.
Tony Thigpen
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
Please be alert for any emails that may ask you for login information
or directs you to login via a link. If you believe this message is a
phish or aren't sure whether this message is trustworthy, please send

--
Mark Jacobs
Time Customer Service
Global Technology Services

The standard you walk past is the standard you accept.
Lt. Gen. David Morrison


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Tony Thigpen]

We are talking about encrypting "Data at Rest". There is *no* key
exchange involved. The only purpose for encrypting keys is so you can
send them to someone else.

Tony Thigpen

Post by Mark Jacobs - Listserv
Encryption/decryption without a CryptoExpress only supports clear keys,
not protected or secured encryption keys. Might be enough for the OP,
but wouldn't fly in my environment.

June 12, 2017 at 7:22 AM
For encrypting "data at rest", the CPACF is really all he needs. The
Crypto Express is intended to speed up key negotiations between sites,
something not needed for his intended plans.
Tony Thigpen
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
Please be alert for any emails that may ask you for login information
or directs you to login via a link. If you believe this message is a
phish or aren't sure whether this message is trustworthy, please send

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Mark Jacobs - Listserv]

Has nothing to do with key exchange. The DEK used to encrypt the data
will be in clear text rather than the DEK being encrypted by the KEK. (
ICSF Master Key ).

Mark Jacobs

June 12, 2017 at 8:12 AM
We are talking about encrypting "Data at Rest". There is *no* key
exchange involved. The only purpose for encrypting keys is so you can
send them to someone else.
Tony Thigpen
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
June 12, 2017 at 8:01 AM
Encryption/decryption without a CryptoExpress only supports clear
keys, not protected or secured encryption keys. Might be enough for
the OP, but wouldn't fly in my environment.
June 12, 2017 at 7:22 AM
For encrypting "data at rest", the CPACF is really all he needs. The
Crypto Express is intended to speed up key negotiations between sites,
something not needed for his intended plans.
Tony Thigpen
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
Please be alert for any emails that may ask you for login information
or directs you to login via a link. If you believe this message is a
phish or aren't sure whether this message is trustworthy, please send

--
Mark Jacobs
Time Customer Service
Global Technology Services

The standard you walk past is the standard you accept.
Lt. Gen. David Morrison


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[R.S.]

Post by Tony Thigpen
We are talking about encrypting "Data at Rest". There is *no* key
exchange involved. The only purpose for encrypting keys is so you can
send them to someone else.

No. The purpose of encrypting keys is something called "secure key
cryptography", as opposed to "clear key cryptography" and it is NOT
related to kye exchange.
In short words:
Secure key cryptography (SKC) means the key is not available even for
people with administration authorities, cannot be dumped with memory,
etc. The key resides in clear form only inside secure (tamper-proof)
crypto device.
Clear key cryptography (CKC) means a person with authorities and
knowledge can obtain the key value.

Crypto cards are required for SKC, but it is slower than CPACF.
CPACF support CKC and something called "Protected Key Cryptography" - in
such mode the key is masked, so even authorized insider is not able to
obtain the key value, but it is not certified as SKC (but runs at the
speed of CPACF).


Now key echange. In any mode it is possible to exchange keys securely or
not securely.
--
Radoslaw Skorupka
Lodz, Poland




======================================================================


--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: ***@mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Ernest Nachtigall]

Post by Arye Shemer
Hello,
Customer is currently using CPACF to encrypt his data before writing to
disks.
Customer intent to purchased Crypto Express and want to use it to continue
to encrypt the data before writing to the disks,
Are there any compatibility issues ?
Are there any know documents which deals/explain with issues involved ?
Thanks,
Arye Shemer.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

CPACF is best for bulk encryption. Thousands of times faster than Crypto Express (for bulk and Clear Key). If security of encryption keys is an issue, consider using Protected Key (secure keys running on CPACF - requires RACF/SAF definition).

[Phil Smith]

There are several things intertwined here.


* CPACF is the "crypto on the chip" - z Systems instructions that do AES et al.

* CEX is the z HSM.

* ICSF is, of course, the z/OS service that talks to both (though you can do CPACF operations directly as well).

With just CPACF, you're forced to use what's called Clear Key operation: keys are stored (somewhere, somehow-perhaps in CKDS), are fetched, and are passed to CPACF to do operations.

With CEX in the mix, you add two more options: Secure Key and Protected Key.

Secure Key means that keys are generated by the CEX, wrapped (encrypted) using keys known only to the CEX, and then passed to z/OS, which stores them (usually in CKDS). When an operation is performed, that wrapped key and the data are passed to the CEX, which unwraps the key, does the operation, and returns the result. Very secure, if relatively slow.

Protected Key means that keys are generated by the CEX, wrapped, and stored in CKDS, like Secure Key. BUT when an operation is needed, an ICSF call takes that wrapped key and passes it to the CEX, where it is unwrapped, rewrapped using an ephemeral key generated just for the current IPL, and that key is returned. That ephemeral key is also passed to the firmware, so it's available to CPACF. Then the actual operation is performed by passing the rewrapped key: CPACF unwraps it using that ephemeral key, does the operation, returns the result. And ICSF remembers that it's done this, so the next operation using that key doesn't talk to the HSM at all. This gets you almost all of the performance and pretty well all of the security of Secure Key (arguably the firmware is slightly less secure than the tamper-resistant HSM, but the memory used in the firmware to hold that key is protected-it's apparently not even visible in HMC dumps).

So your customer can switch to using Protected Key, at least in theory. How hard this is will depend on how keys are generated and managed now, as well as whether they're using ICSF or 'raw' CPACF now, as well as whether they're up for reprotecting all of their existing data with the new key.

Does this help?
--
...phsiii

Phil Smith III
Senior Architect & Product Manager, Mainframe & Enterprise
Distinguished Technologist
HPE Data Security

***@hpe.com<mailto:***@hpe.com>
T 703-476-4511
M 703-568-6662
Hewlett Packard Enterprise
Herndon, VA


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Arye Shemer]

Thank you all for your contribution and time.
It sure gave me a lot to think of.

thanks,

Arye.

Post by Phil Smith
There are several things intertwined here.
* CPACF is the "crypto on the chip" - z Systems instructions that do AES et al.
* CEX is the z HSM.
* ICSF is, of course, the z/OS service that talks to both (though
you can do CPACF operations directly as well).
keys are stored (somewhere, somehow-perhaps in CKDS), are fetched, and are
passed to CPACF to do operations.
With CEX in the mix, you add two more options: Secure Key and Protected Key.
Secure Key means that keys are generated by the CEX, wrapped (encrypted)
using keys known only to the CEX, and then passed to z/OS, which stores
them (usually in CKDS). When an operation is performed, that wrapped key
and the data are passed to the CEX, which unwraps the key, does the
operation, and returns the result. Very secure, if relatively slow.
Protected Key means that keys are generated by the CEX, wrapped, and
stored in CKDS, like Secure Key. BUT when an operation is needed, an ICSF
call takes that wrapped key and passes it to the CEX, where it is
unwrapped, rewrapped using an ephemeral key generated just for the current
IPL, and that key is returned. That ephemeral key is also passed to the
firmware, so it's available to CPACF. Then the actual operation is
performed by passing the rewrapped key: CPACF unwraps it using that
ephemeral key, does the operation, returns the result. And ICSF remembers
that it's done this, so the next operation using that key doesn't talk to
the HSM at all. This gets you almost all of the performance and pretty well
all of the security of Secure Key (arguably the firmware is slightly less
secure than the tamper-resistant HSM, but the memory used in the firmware
to hold that key is protected-it's apparently not even visible in HMC
dumps).
So your customer can switch to using Protected Key, at least in theory.
How hard this is will depend on how keys are generated and managed now, as
well as whether they're using ICSF or 'raw' CPACF now, as well as whether
they're up for reprotecting all of their existing data with the new key.
Does this help?
--
...phsiii
Phil Smith III
Senior Architect & Product Manager, Mainframe & Enterprise
Distinguished Technologist
HPE Data Security
T 703-476-4511
M 703-568-6662
Hewlett Packard Enterprise
Herndon, VA
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Todd Arnold]

Since I design some of this stuff, I can help clarify - but others have already done a pretty good job of explaining the various alternatives.

What I'd like to ask is what you are actually trying to do? What is the reason for installing the Crypto Express and trying to use it instead of or in addition to the CPACF? The reason I'd expect is that you want additional security for your keys, but I don't think you've confirmed that.

If you use ICSF as the interface, it automatically selects the most appropriate crypto to use - for example, if you are doing clear-key encryption, it will automatically use CPACF because it knows that will be faster than the CEX, but if you want to do PIN block translation it knows it has to use the CEX because the relevant standards mandate that keys can't be in the clear and that the entire translation operation has to be done atomically.

Most people find that CEX performance is not good enough for disk encryption applications, so they either use clear-key CPACF or protected-key CPACF, depending on their security requirements on the keys. Performance for protected-key operations is only slightly less than for clear-key ones with CPACF - you can see some performance information in this paper: https://public.dhe.ibm.com/common/ssi/ecm/zs/en/zsw03283usen/ZSW03283USEN.PDF

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Todd Arnold]

Post by Phil Smith
(arguably the firmware is slightly less secure than the tamper-resistant HSM, but the memory
used in the firmware to hold that key is protected-it's apparently not even visible in HMC dumps)

That is correct. The memory where the key is held is associated with the CPACF hardware and its operation. That memory is part of the internal z hardware and is completely separate from any memory that the applications or operating system can see or use.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Arye Shemer]

Hello Todd,
I'll try answer your questions as best I can.
1. I am talking about z/VM z/VSE customer who is using currently CPACF to
encrypt data going to the disk and (I am not sure)
some software using CPACF for SSL.
2. Customer predict workload increase and expect to get more performance
using the Crypto Express especially in the growing SSL
demand
3. Customer is currently using CPACF with key length of 128 bits for clear
key encryption and (by internal demand) expect to move to 256 bits with the
Crypto Express
4. As far as I know there are no immediate requirements for high secured
key protection (which provided of course
by the Crypto Express)
5. The Crypto Express is offered to the customer for marketing reasons (Can
not elaborate and have to leave it vague)

Thanks for your interests and suggestions,

Arye.

Post by Phil Smith

Post by Phil Smith
(arguably the firmware is slightly less secure than the tamper-resistant

HSM, but the memory

Post by Phil Smith
used in the firmware to hold that key is protected-it's apparently not

even visible in HMC dumps)
That is correct. The memory where the key is held is associated with the
CPACF hardware and its operation. That memory is part of the internal z
hardware and is completely separate from any memory that the applications
or operating system can see or use.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Kirk Wolf]

"SSL" (or TLS) is a client-server secure connection protocol, not a
file/disk encryption protocol.

It involves both:
a) key exchange (handshake) which uses asymmetric key operations
(handshake happens once or periodically for long sessions)

b) symmetric ciphers using a shared session key negotiated by (a)
(ciphers are used for encrypting each block of data)

Crypto Express is the best for (a), but not for (b).
CPACF is best for (b), but doesn't do (a).

CPACF does either clear-key or wrapped-key symmetric ciphers.

S/MIME, which is similar to SSL would be commonly used for file encryption,
as would CMS or PGP.
For any of these, the actual cipher (AES) would be best done with CPACF on
z.

FWIW, you can use CPACF Ciphers via ICSF calls or direct use of the CPACF
instructions.



Kirk Wolf
Dovetailed Technologies
http://dovetail.com

Post by Arye Shemer
Hello Todd,
I'll try answer your questions as best I can.
1. I am talking about z/VM z/VSE customer who is using currently CPACF to
encrypt data going to the disk and (I am not sure)
some software using CPACF for SSL.
2. Customer predict workload increase and expect to get more performance
using the Crypto Express especially in the growing SSL
demand
3. Customer is currently using CPACF with key length of 128 bits for clear
key encryption and (by internal demand) expect to move to 256 bits with the
Crypto Express
4. As far as I know there are no immediate requirements for high secured
key protection (which provided of course
by the Crypto Express)
5. The Crypto Express is offered to the customer for marketing reasons (Can
not elaborate and have to leave it vague)
Thanks for your interests and suggestions,
Arye.

Post by Phil Smith

Post by Phil Smith
(arguably the firmware is slightly less secure than the

tamper-resistant

Post by Phil Smith
HSM, but the memory

Post by Phil Smith
used in the firmware to hold that key is protected-it's apparently not

even visible in HMC dumps)
That is correct. The memory where the key is held is associated with the
CPACF hardware and its operation. That memory is part of the internal z
hardware and is completely separate from any memory that the applications
or operating system can see or use.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Phil Smith]

Post by Arye Shemer
I'll try answer your questions as best I can.
1. I am talking about z/VM z/VSE customer who is using currently CPACF to
encrypt data going to the disk and (I am not sure)
some software using CPACF for SSL.
2. Customer predict workload increase and expect to get more performance
using the Crypto Express especially in the growing SSL
demand

For SSL, yes; for basic encryption, no. It will almost certainly be slower. If the blocks are big enough it's possible it might be faster, but I wouldn't bet on it (well, I guess it depends how bad their software encryption implementation is).

Post by Arye Shemer
3. Customer is currently using CPACF with key length of 128 bits for clear
key encryption and (by internal demand) expect to move to 256 bits with the
Crypto Express

Again, if this is for basic AES/DES and the existing implementation isn't too horrible, don't bet on better performance.

Post by Arye Shemer
4. As far as I know there are no immediate requirements for high secured
key protection (which provided of course
by the Crypto Express)
5. The Crypto Express is offered to the customer for marketing reasons (Can
not elaborate and have to leave it vague)

Um. OK. Not sure what that means, but I guess that's the point!
--

...phsiii

Phil Smith III
Senior Architect & Product Manager, Mainframe & Enterprise
Distinguished Technologist
HPE Data Security

***@hpe.com<mailto:***@hpe.com>
T 703-476-4511
M 703-568-6662
Hewlett Packard Enterprise
Herndon, VA


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Greg Boyd]

I'm a little late chiming in and I must confess I don't have as much experience with crypto on z/VSE. z/VSE may have changed, but in the past it has not provided a facility like ICSF which provides the interface to the CEX cards.

Going back to the original post, I suspect that the customer is using locally written assembler code to invoke the crypto instructions on the CPACF to encrypt the data before writing it to disk.

How does the customer expect to drive work to the CEX card? Is there a product that they plan on using?

z/VSE can use Total Storage devices which can provide encryption, but the encryption is done on the device, not on the CPACF hardware. In this case, the Crypto Express card can be used to protect (encrypt) the symmetric key, using public key APIs, and then that symmetric key is used in the device to encrypt or decrypt the data depending on whether it's a write or read operation.

In addition, z/VSE supports the Encryption Facility for z/VSE (a z/VSE implementation of the Encryption Facility for z/OS). It can also provide similar support, using a public key to wrap the symmetric key that is then used to protect the data within the file. As with the TotalStorage hardware, the CEX can
perform these public key operations, but the encryption of the data is done elsewhere (not on the card).

But to use the CEX card to actually encrypt/decrypt the data a rest, would a) probably not provide acceptable performance and b) require another product to invoke the APIs that would be executed on the cards.

So, why is the customer considering installing the CEX card? Is it to provide more security for their data at rest? If so, what product do they expect to use to perform the encryption. Bottom line, the CPACF and CEX are compatible, and in fact you must have the CPACF enabled to use the CEX cards, but using
the cards requires software that will leverage the cards.

Or is it for SSL operations? The card can provide a significant performance boost for SSL operations and the real benefit is for authenticating the network communication sessions. In this case, these public key operations are done on the CEX card instead of using software routines (MVC, SLL, Multiple instructions, etc.).

Along those lines, I want to clarify Todd Arnold's comments:
"If you use ICSF as the interface, it automatically selects the most appropriate crypto to use - for example, if you are doing clear-key encryption, it will automatically use CPACF because it knows that will be faster than the CEX ..."

Actually, the specific API that you implement in your code, not ICSF, determines which device will perform the work. For example, CSNBSAE is the Symmetric Algorithm Encipher API and is a secure key API. When you invoke that API, ICSF will always route the work to a CEX card (and there better be a
card available to service that request or the API will fail). On the other hand, if you invoke CSNBSYE, the Symmetric Key Encipher API, then ICSF will use the assembler instructions on the CPACF to perform that operation. So ICSF is not deciding where the operation is performed, your choice of APIs is.

I hope that helps.
Greg Boyd
Mainframe Crypto
www.mainframecrypto.com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Todd Arnold]

So, the discussion about ICSF is not meaningful - ICSF runs on z/OS, and you're not using z/OS in this case.

In general, the choice between CPACF and CEX is fairly straightforward.

- If the function(s) you need can be done with CPACF, then use CPACF.
It is faster than CEX for everything it does, but it can only do a small
number of things.

- If you need "secure keys" - keys that are protected by hardware that
cannot be subverted, even by the highest-technology methods - then
use CEX. (but if you need a lower level of security, consider CPACF
Protected Key mode.)

- If you need the functions that are available only on CEX, then use CEX.
Some typical examples are public-key cryptography (CPACF only does
symmetric key crypto and hashing) and the wide array of specialized
functions required in banking and payment card systems.

Sometimes, this means using both CEX and CPACF. SSL/TLS is a good example - this is typically done by using CEX for the public-key operations involved in setting up the session, then using CPACF for the symmetric-key operations used to encrypt/decrypt the session traffic. Often, the SSL/TLS software is designed to do this automatically.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Greg Dyck]

Post by Todd Arnold
- If you need "secure keys" - keys that are protected by hardware that
cannot be subverted, even by the highest-technology methods - then
use CEX. (but if you need a lower level of security, consider CPACF
Protected Key mode.)

I would note that CPACF protected keys are *very* secure, as they are
good only on the system that generates them for the life of that IPL.
While not impregnable like secure keys, they usually end up on the plus
side of scales when you consider the possibility of breaking the
encryption of a CPACF encrypted key vs the significant reduction in
elapsed time over the CEX when processing large amounts of data.

ICSF *can* convert a secure key to a CPACF protected key for use by the
cipher instructions if the appropriate options and security profiles are
established.

Regards,
Greg

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Joerg Schmidbauer]

Todd pointed me to this topic, because it's a z/VSE related question, not z/OS.
From my point of view Tony and Todd explained everything correctly.
Just one additional info:
There is an optional feature "Encryption Facility for z/VSE" that allows encrypting
data at rest (Librarian members, VSAM files, backup tapes, real tapes and vtapes).
It's functionality and usage is described in the z/VSE Administration Guide:
https://www.ibm.com/systems/z/os/zvse/documentation/#vse
It uses CPACF and crypto cards transparently. CPACF is used for encrypting the
data. A crypto card is needed only when using public-key encryption (refer to the book)
with an RSA key greater than 1024 bits. The other option is "password-based"
encryption, where the symmetric key gets derived from a password/passphrase.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Tony Thigpen]

The "Encryption Facility for z/VSE" product is used to transport data
between VSE and z/OS or other platform that would accept data encrypted
by ""Encryption Facility for z/OS".

It does *not* support "data at rest". It does allow you to copy and
encrypt a file, but the whole file has to be decrypted and restored
before it can be used by the system. That is not "data at rest"

There is only one "data at rest" product for VSE. Dino/Protect.

I developed Dino/Protect back in 2007. http://www.dinoprotect.com

But, here is the real crux of the matter. While I sold about a dozen
copies of the back-up encryption piece, nobody in the VSE community
though "data at rest" was needed. All they want is encrypted backups.
And, since then, encrypted tape drives have been developed by IBM so
everybody is going that route.

So, it's available, but nobody came to the party.

For those that are wondering about the key, the root for the key is a
random string somewhere in the middle of the software. The root is
manipulated, then ORed, then encrypted, then manipulated again prior to
actually being used as the key to call CPACF. (The manipulation and
encryption is also done by the CPACF.) And, while it's just 128 AES, I
could easily support any key length supported by CPACF.

The software even supports encrypting just specific fields, of any
length, within the record. It also has program controls so that an
IDCAMS EXPORT does not decrypt the data during backups.

But, again, nobody came to the party. :-(

Tony Thigpen

Post by Joerg Schmidbauer
Todd pointed me to this topic, because it's a z/VSE related question, not z/OS.

Post by Joerg Schmidbauer
From my point of view Tony and Todd explained everything correctly.

There is an optional feature "Encryption Facility for z/VSE" that allows encrypting
data at rest (Librarian members, VSAM files, backup tapes, real tapes and vtapes).
https://www.ibm.com/systems/z/os/zvse/documentation/#vse
It uses CPACF and crypto cards transparently. CPACF is used for encrypting the
data. A crypto card is needed only when using public-key encryption (refer to the book)
with an RSA key greater than 1024 bits. The other option is "password-based"
encryption, where the symmetric key gets derived from a password/passphrase.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Todd Arnold]

Right - the CPACF Protected Keys are *very* secure and we were very happy with our ability to add that feature. Unfortunately, for some applications (such as payment card systems), the standards require a "Secure Cryptographic Device" (SCD) like an HSM that has advanced active tamper detection and response - so you have no choice in those cases.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN