Yes, that’s how it works. The math needed to encrypt and decrypt using the public and private keys is performed on the crypto card.
The data being protected by that encrypted message is the symmetric key used to encrypt the application data. That encryption is done on the CPU, not the cryptos, but I think only for protected or clear keys, not encrypted keys. Those private keys may themselves be encrypted by the master key. However, domains selected to be APVIRT cryptos are clear key only since multiple guests share them. APDEDICATED crypto domains are given to specific users and those are fully functional, including having encrypted keys. Each domain on a crypto can have a unique master key. For redundancy, it is intended that the same domain on multiple cryptos will have the same master key. When z/OS isn’t on the CPC, encrypted keys can only be used when the crypto is in EP11 mode. TKE and Linux EP11 daemon work together to load the master keys. For APVIRT, the cryptos can be either accelerators or coprocessors. Choose one. I, too, have been researching the details of encrypted file systems on Linux. I know what I want Linux to do, but I don’t yet know if he will do it. Regards, Alan Altmark IBM > On Jan 11, 2020, at 1:41 PM, VANDER WOUDE, PETER <[email protected]> wrote: > > Configuring and having available a crypto facility engine as an accelerator is primarily for use in the speeding up of the SSL initial negotiation, as that is using RSA public/private keys for handshake, which then results in a symmetric key for a cipher have both agreed upon. This handshaking is one of the more expensive (cpu wise) of SSL handling, and using the accelerator helps speed that up, especially as RSA key lengths get larger. > > Note: My knowledge of this comes from my work on z/OS and studying of how the crypto engines in accelerator or co-processor mode work. Not sure if the usage on the Linux on Z builds operates the same way. > > Regards, > Peter > > > -----Original Message----- > From: Linux on 390 Port <[email protected]> On Behalf Of Rick Troth > Sent: Friday, January 10, 2020 8:52 PM > To: [email protected] > Subject: Re: Pervasive disk encryption questions > > CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. > > My understanding of the cards is that they're more of a trust anchor than an accelerator. What I mean is ... differentiate symmetric crypto from asymmetric crypto. Symmetric crypto (think AES) is handled by the main processor, right? (This is where Brian or Alan will chime in, and please do.) So why shuttle the work to a co-processor? Symmetric crypto is faster (much!) than asymmetric. > > Who uses AES as a master key? The concept of "master" should be asymmetric, not symmetric. Symmetric keys are the kind you create for a session and then discard. But ... this is pervasive ... okay ... keys ... and store them. Where? On the card? Okay, but still, doesn't mean the *processing* of symmetric gets done there. > > Last I knew (haven't read the PoOp for z15), the CPU didn't have asymmetric instructions (think RSA). Asymmetric crypto is slower (much!) than symmetric, so one could conceivably shuttle that work to a daughter card and get a win (or at least parity!). > > But there's another point: "trust" is all about asymmetric keys, where you have a PUBLIC half and a PRIVATE half to the pair. So the card can hold the private half (and prove itself against the public half, like for an SSL cert) or can hold the public half (and serve to confirm a third party, like a remote web site SSL cert). > > Not sure I'm splainin it well. Solly. > > But this could be old news. IBMers? What's new? > > -- R; <>< > > >> On 1/10/20 8:24 PM, marcy cortes wrote: >> Cross posted to Linux-390 and IBMVM >> >> >> First, my understand of virtualizing crypto is that if any of the >> cards are defined as accelerators then CRYPTO APVIRT in the directory will give linux >> an accelerator. If you want linux to have a coprocessor, you’d have to >> dedicate one. If you want a lot of servers to have coprocessors (more >> than the HW cards to dedicate), you’d get rid of the accelerators and >> make them all coprocessors. Is my understanding correct? >> >> And to do the AES master key load, it has generally been done from z/OS >> here. It looks like for my z/vm only boxes TKE is required, but I could >> use the CCA package to generate some for a test only scenario. >> >> If I do want to try that CCA key load on a non prod box, I’m thinking >> I would have to dedicate all of the coprocessors to a Linux guest and >> create them there. Then undedicate and then any guest with an APVIRT >> would find valid master keys and would then be able to “zkey generate” >> a secure key for use in each disk. >> >> Am I on the right track? >> >> Marcy >> > > -- > -- R; <>< > > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit > https://urldefense.proofpoint.com/v2/url?u=https-3A__nam05.safelinks.protection.outlook.com_-3Furl-3Dhttp-253A-252F-252Fwww2.marist.edu-252Fhtbin-252Fwlvindex-253FLINUX-2D390-26amp-3Bdata-3D02-257C01-257Cpwoude-2540HARRISTEETER.COM-257C1346250474f843a2aceb08d796398ae7-257C95fcefa54abb413594fc717122fd83d5-257C0-257C0-257C637143046209518057-26amp-3Bsdata-3DYWO7eRzQPGxXKYWn7u-252BJrl35XCQtMhpbyyg4wgrBykQ-253D-26amp-3Breserved-3D0&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=XX3LPhXj6Fv4hkzdpbonTd1gcy88ea-vqLQGEWWoD4M&m=WP6gP2uPQgO6_8LSt1BdGIkdaW6sqBonnB6goJdCRGQ&s=jbh9FzKDyuBodscWs2mHbs9pYgBjQZSBr5NdDePezvI&e= > > ________________________________ > > CONFIDENTIALITY NOTICE: This e-mail message and all attachments may contain legally privileged and confidential information intended solely for the use of the addressee. If the reader of this message is not the intended recipient, any reading, dissemination, distribution, copying, or other use of this message or its attachments is prohibited. If you have received this communication in error, please notify the sender immediately by telephone at 704.844.3100 and delete this message and all copies and backups thereof. Thank you. > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO LINUX-390 or visit > https://urldefense.proofpoint.com/v2/url?u=http-3A__www2.marist.edu_htbin_wlvindex-3FLINUX-2D390&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=XX3LPhXj6Fv4hkzdpbonTd1gcy88ea-vqLQGEWWoD4M&m=WP6gP2uPQgO6_8LSt1BdGIkdaW6sqBonnB6goJdCRGQ&s=Zc72p_fVSQguztYTMb4Y49ZP4kc5NzPGRhpSMo5SOCE&e= > ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
