Re: How should I send file to another sysplex securely.
There are many ways to skin a cat. You can rely on industry standards like certificates and CA's. You can also use your own methods. You can use both. Yes, double security. What I could do: 1. Establish some secure file transfer. It can be FTPS, sftp, commercial MFT applications like Sterling Connect, MQ MFT, etc. 2. Just to sleep better I would also encipher the dataset before it is sent. Again, it can be done using commercial tools like Encryption Facility or Megacryption or other. Of course it is feasible to encrypt dataset using your own tools. Why two methods? Well, both are safe ...until someone made a mistake. Assuming some separation of duties it would be more idiotproof and proof of malicious insider. -- Radoslaw Skorupka Lodz, Poland W dniu 22.07.2021 o 16:07, Colin Paice pisze: I was wondering the best way customers send sensitive data between z/OS images. I was thinking about exporting one's private certificates. 1. I can create a dataset of the private certificates on system 1 and have it encrypted. I can send it to the other system. How can I decrypt it on the remote system as it needs shared certificates? It seems a chicken and egg problem 2. I can put a password on the file through JCL and use FTPS to send it. This could easily be broken This is hypothetical, but I would be interested in how to do it. Colin Paice -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How should I send file to another sysplex securely.
On 7/22/21 6:21 PM, Charles Mills wrote: Agreed. By "roll your own" I was referring to 1) Create an asymmetric public + private key pair on the destination system. 2) Transfer the destination system's public key to the source system. 3) Create a symmetric key on the source system. Etc. If that's "roll your own" cryptography, then how do you use Pervasive Encryption without "rolling your own" cryptography? You must have keying material, and I'd be flabbergasted if IBM shipped said keying material with the system. You have to transfer that keying material between systems you want to communicate. How do you avoid "rolling your own" cryptography when you make the investment and create the aforementioned SFTP server? -- Grant. . . . unix || die -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How should I send file to another sysplex securely.
On 7/22/21 6:17 PM, Mike Schwab wrote: Since a lot of chips a manufactured in China, a device could be sending ... your data, Theoretically yes. I'm not going to speculate on the probability that such is happening. Though Hanlon's Razor comes to mind. But for it to be sending your data it would have to ... actually send the data. And in doing so would present symptoms of sending data. These symptoms can be detected. As such it's quite possible to detect if this is happening. I say possible, because not everybody is looking for such data. -- Grant. . . . unix || die -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How should I send file to another sysplex securely.
On 7/22/21 6:09 PM, Charles Mills wrote: Guys, this is the problem with inventing your own solution. You didn't elucidate what the (or a) problem is. Public keys are, well, public. Yes, that's the very nature of a /public/ key. The new fashion in fact is to NOT trust internal networks. You really don't know how far an intruder may have intruded, so you should assume every communication channel is insecure. *HEAVYsigh* Yes. Zero Trust *is* /a/ thing. But I think it's *MUCH* /more/ of a buzz word trying to sell snake oil than it is a real problem. As Bruce Schneier is famous for saying "Trust the Math". If I compare (a cryptographic hash of) the public key on SYS1 and SYS2 and they are the same, combined with the fact that SYS1's corresponding key can decrypt what SYS2 encrypts with it's copy of SYS1's public key, then I think the math dictates that SYS1 and SYS2 are actually talking to each other, no matter how (in)secure the intervening network(s) are. And if a malicious actor can intercept data flowing across a HyperSocket between two LPARs and perform a full in the middle attack, ... you've got MUCH bigger problems. In the new era of cloud and partners and bring your own device, exactly what is an internal and what is an external network? The two CECs sitting next to each other in the same room with cables running directly between them seems to definitely qualify as "internal" to me. You can "what if" yourself to death. Or you can "trust the math". Verify (a hash of) the public key on the source and destination system. If the key is the same, you are quite likely safe to move data across the wire. If someone can spoof the output from the commands to display (the hash of) the public key and your terminal as an active in the middle attack ... you have bigger problems. I'm not even sure that IBM can help you. This new paradigm is called "Zero Trust." https://csrc.nist.gov/publications/detail/sp/800-207/final. I have a presentation on Zero Trust coming up courtesy of New Era, but we don't have a date yet. A good month or so out. I'm intrigued. But obviously I'm a tad bit skeptical. -- Grant. . . . unix || die -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How should I send file to another sysplex securely.
Agreed. By "roll your own" I was referring to >1) Create an asymmetric public + private key pair on the destination >system. >2) Transfer the destination system's public key to the source system. >3) Create a symmetric key on the source system. Etc. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Grant Taylor Sent: Thursday, July 22, 2021 4:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How should I send file to another sysplex securely. On 7/22/21 2:58 PM, Charles Mills wrote: > I would say in no event does the OP want to "roll his own" or "cobble > something together out of bits and pieces." I think we have different ideas of what "roll your own" means. Personally, I don't believe that running some standard commands (at least from a unix perspective), transferring two files, and running some closely related commands to be "rolling your own". At least not any more than creating JCL is "roll your own". > This problem is what FTP does for a living. Agreed. > An investment in secure FTP is an investment in the future, not just > this one problem. Yes. Though, sometimes such an /investment/ means a LOT more work, especially if something is going to be persistent and need to adhere to corporate security policies / scans / etc. Often, especially for one off cases, doing a little bit more work manually is the simpler and faster of the solutions. > Oh! In Step 3 below, add to the sentence "... using a secure > cryptographic-quality random-number generator." Agreed. I expect that any contemporary / patched operating system to sufficiently address this concern. Especially when following vendor best practices regarding cryptographic utilities that they provide. > Again, you don't want to roll your own on this. Wy too many traps > for the unwary. See above. There is a big difference in putting some commands in JCL vs coding your own cryptographic algorithms, including the math and keying algorithms. There is an apt saying for that "friends don't let friends create their own cryptographic algorithms". Friends help friends use well established cryptographic algorithms in the proper way. -- Grant. . . . unix || die -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How should I send file to another sysplex securely.
Since a lot of chips a manufactured in China, a device could be sending China your data, which is why Huawei is being banned from communications networks. On Thu, Jul 22, 2021 at 7:09 PM Charles Mills wrote: > > Guys, this is the problem with inventing your own solution. > > Public keys are, well, public. You can transfer them over an insecure medium. > You can put them on your Web site. You can announce them over the PA. The TLS > protocol transfers public keys over the communication link before it is > trusted. > > > If the OP can't safely get a public [key] copied between LPARs / CECs in a > > trusted network > > The new fashion in fact is to NOT trust internal networks. You really don't > know how far an intruder may have intruded, so you should assume every > communication channel is insecure. In the new era of cloud and partners and > bring your own device, exactly what is an internal and what is an external > network? (This new paradigm is called "Zero Trust." > https://csrc.nist.gov/publications/detail/sp/800-207/final. I have a > presentation on Zero Trust coming up courtesy of New Era, but we don't have a > date yet. A good month or so out.) > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Grant Taylor > Sent: Thursday, July 22, 2021 4:48 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: How should I send file to another sysplex securely. > > On 7/22/21 3:17 PM, Paul Gilmartin wrote: > > It lacks authentication and does not prevent MITM attacks: > > I think we might be talking about two slightly, but distinctly, > different scenarios. > > I took the OP's statement to be talking about needing to move data from > one LPAR / CEC on the left side of the room to another LPAR / CEC on the > right side of the room. Wherein the room and the network are trusted; a > la. internal company network. > > What's more is I was anticipating the OP to be performing all of the > steps. As such, the OP could validate that the public key copied from > the destination system to the source system was in fact one in the same. > Be it byte for byte comparison of hex output, or comparison of > cryptographic hashes, or even IND$FILE transfers from the destination > system to the source system via the common workstation / terminal emulator. > > Aside: If the OP needs to do the transfer in conjunction with a fellow > SYSOP from elsewhere in the world, they can get on the phone with each > other (or use some other out of band communications method that they > trust) to confirm public key. > > Further aside: If the OP can't safely get a public copied between LPARs > / CECs in a trusted network, then s/he has bigger problems. If > interlopers are messing with such a transfer, ... that's a *LOT* bigger > problem. Problems big enough that asking for help on a mailing list is > quite likely not sufficient. > > > > -- > Grant. . . . > unix || die > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How should I send file to another sysplex securely.
Guys, this is the problem with inventing your own solution. Public keys are, well, public. You can transfer them over an insecure medium. You can put them on your Web site. You can announce them over the PA. The TLS protocol transfers public keys over the communication link before it is trusted. > If the OP can't safely get a public [key] copied between LPARs / CECs in a > trusted network The new fashion in fact is to NOT trust internal networks. You really don't know how far an intruder may have intruded, so you should assume every communication channel is insecure. In the new era of cloud and partners and bring your own device, exactly what is an internal and what is an external network? (This new paradigm is called "Zero Trust." https://csrc.nist.gov/publications/detail/sp/800-207/final. I have a presentation on Zero Trust coming up courtesy of New Era, but we don't have a date yet. A good month or so out.) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Grant Taylor Sent: Thursday, July 22, 2021 4:48 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How should I send file to another sysplex securely. On 7/22/21 3:17 PM, Paul Gilmartin wrote: > It lacks authentication and does not prevent MITM attacks: I think we might be talking about two slightly, but distinctly, different scenarios. I took the OP's statement to be talking about needing to move data from one LPAR / CEC on the left side of the room to another LPAR / CEC on the right side of the room. Wherein the room and the network are trusted; a la. internal company network. What's more is I was anticipating the OP to be performing all of the steps. As such, the OP could validate that the public key copied from the destination system to the source system was in fact one in the same. Be it byte for byte comparison of hex output, or comparison of cryptographic hashes, or even IND$FILE transfers from the destination system to the source system via the common workstation / terminal emulator. Aside: If the OP needs to do the transfer in conjunction with a fellow SYSOP from elsewhere in the world, they can get on the phone with each other (or use some other out of band communications method that they trust) to confirm public key. Further aside: If the OP can't safely get a public copied between LPARs / CECs in a trusted network, then s/he has bigger problems. If interlopers are messing with such a transfer, ... that's a *LOT* bigger problem. Problems big enough that asking for help on a mailing list is quite likely not sufficient. -- Grant. . . . unix || die -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How should I send file to another sysplex securely.
On 7/22/21 5:42 PM, Lennie Dymoke-Bradshaw wrote: There is a document by Philippe Richard of IBM France which documents this problem and demonstrates how to resolve it using a set of REXX routines written by Eysha Powers. It is entitled "Transporting AES encrypted data keys from one z/OS host to another". As far as I can see it has no manual number. This looks like it (at a quick glance). https://www.ibm.com/support/pages/system/files/inline-files/Transporting_AES_DATA_keys_new.pdf $ReadingList++ -- Grant. . . . unix || die -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How should I send file to another sysplex securely.
On 7/22/21 2:58 PM, Charles Mills wrote: I would say in no event does the OP want to "roll his own" or "cobble something together out of bits and pieces." I think we have different ideas of what "roll your own" means. Personally, I don't believe that running some standard commands (at least from a unix perspective), transferring two files, and running some closely related commands to be "rolling your own". At least not any more than creating JCL is "roll your own". This problem is what FTP does for a living. Agreed. An investment in secure FTP is an investment in the future, not just this one problem. Yes. Though, sometimes such an /investment/ means a LOT more work, especially if something is going to be persistent and need to adhere to corporate security policies / scans / etc. Often, especially for one off cases, doing a little bit more work manually is the simpler and faster of the solutions. Oh! In Step 3 below, add to the sentence "... using a secure cryptographic-quality random-number generator." Agreed. I expect that any contemporary / patched operating system to sufficiently address this concern. Especially when following vendor best practices regarding cryptographic utilities that they provide. Again, you don't want to roll your own on this. Wy too many traps for the unwary. See above. There is a big difference in putting some commands in JCL vs coding your own cryptographic algorithms, including the math and keying algorithms. There is an apt saying for that "friends don't let friends create their own cryptographic algorithms". Friends help friends use well established cryptographic algorithms in the proper way. -- Grant. . . . unix || die -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How should I send file to another sysplex securely.
On 7/22/21 3:17 PM, Paul Gilmartin wrote: It lacks authentication and does not prevent MITM attacks: I think we might be talking about two slightly, but distinctly, different scenarios. I took the OP's statement to be talking about needing to move data from one LPAR / CEC on the left side of the room to another LPAR / CEC on the right side of the room. Wherein the room and the network are trusted; a la. internal company network. What's more is I was anticipating the OP to be performing all of the steps. As such, the OP could validate that the public key copied from the destination system to the source system was in fact one in the same. Be it byte for byte comparison of hex output, or comparison of cryptographic hashes, or even IND$FILE transfers from the destination system to the source system via the common workstation / terminal emulator. Aside: If the OP needs to do the transfer in conjunction with a fellow SYSOP from elsewhere in the world, they can get on the phone with each other (or use some other out of band communications method that they trust) to confirm public key. Further aside: If the OP can't safely get a public copied between LPARs / CECs in a trusted network, then s/he has bigger problems. If interlopers are messing with such a transfer, ... that's a *LOT* bigger problem. Problems big enough that asking for help on a mailing list is quite likely not sufficient. -- Grant. . . . unix || die -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How should I send file to another sysplex securely.
Colin, There is a document by Philippe Richard of IBM France which documents this problem and demonstrates how to resolve it using a set of REXX routines written by Eysha Powers. It is entitled "Transporting AES encrypted data keys from one z/OS host to another". As far as I can see it has no manual number. If you cannot find it from Philippe Richard, then I can send you a copy. The method makes use of standard ICSF calls to use EC keys to have the same AES data key installed into two distinct z/OS systems in a secure manner. Once that key is installed in both systems, the data can be securely transferred in either direction. Lennie Dymoke-Bradshaw https://rsclweb.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Colin Paice Sent: 22 July 2021 15:08 To: IBM-MAIN@LISTSERV.UA.EDU Subject: How should I send file to another sysplex securely. I was wondering the best way customers send sensitive data between z/OS images. I was thinking about exporting one's private certificates. 1. I can create a dataset of the private certificates on system 1 and have it encrypted. I can send it to the other system. How can I decrypt it on the remote system as it needs shared certificates? It seems a chicken and egg problem 2. I can put a password on the file through JCL and use FTPS to send it. This could easily be broken This is hypothetical, but I would be interested in how to do it. Colin Paice -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How should I send file to another sysplex securely.
@Gil, works better than that. Watch my presentation referenced earlier. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, July 22, 2021 2:18 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How should I send file to another sysplex securely. On Thu, 22 Jul 2021 14:05:31 -0600, Grant Taylor wrote: >On 7/22/21 12:49 PM, Mike Hochee wrote: >>... >There is also a hybrid approach in which a symmetric key is used to >encrypt / decrypt the data and asymmetric keys to protect the first key. > -- My understanding is that symmetric encryption is multiple orders >of magnitude faster than asymmetric encryption. > This is routinely, almost universally, done for asymmetric encryption. It lacks authentication and does not prevent MITM attacks: o An intruder can masquerade as the sender and supply forged data. o An intruder can masquerade as the recipient and intercept sensitive data. o Or both, if you're lucky. I believe (I'm mostly guessing) that a Certificate Authority provides authentication in a repository of public keys but, "Quis custodiet ipsos custodes?" Computers come with a table of recognized CAs and their public keys embedded in the OS. This amounts to making the computer vendors the ultimate Certificate authorities. https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf Or, the CAs could announce their public keys on NewsMax or Twitter. >1) Create an asymmetric public + private key pair on the destination >system. >2) Transfer the destination system's public key to the source system. >3) Create a symmetric key on the source system. >4) Use the source system's symmetric key to encrypt the data. >5) Use the destination system's asymmetric public key to encrypt the >source system's symmetric key. >6) Transfer both the encrypted data and the encrypted symmetric key >from the source system to the destination system. >7) Use the destination system's asymmetric private key to decrypt the >source system's symmetric key. >8) Use the decrypted source system's symmetric key to decrypt the data. >... >n) PROFIT!!! > >The data and the symmetric key protecting it are only unencrypted on the >source and destination system. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How should I send file to another sysplex securely.
On Thu, 22 Jul 2021 14:05:31 -0600, Grant Taylor wrote: >On 7/22/21 12:49 PM, Mike Hochee wrote: >>... >There is also a hybrid approach in which a symmetric key is used to >encrypt / decrypt the data and asymmetric keys to protect the first key. > -- My understanding is that symmetric encryption is multiple orders >of magnitude faster than asymmetric encryption. > This is routinely, almost universally, done for asymmetric encryption. It lacks authentication and does not prevent MITM attacks: o An intruder can masquerade as the sender and supply forged data. o An intruder can masquerade as the recipient and intercept sensitive data. o Or both, if you're lucky. I believe (I'm mostly guessing) that a Certificate Authority provides authentication in a repository of public keys but, "Quis custodiet ipsos custodes?" Computers come with a table of recognized CAs and their public keys embedded in the OS. This amounts to making the computer vendors the ultimate Certificate authorities. https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf Or, the CAs could announce their public keys on NewsMax or Twitter. >1) Create an asymmetric public + private key pair on the destination >system. >2) Transfer the destination system's public key to the source system. >3) Create a symmetric key on the source system. >4) Use the source system's symmetric key to encrypt the data. >5) Use the destination system's asymmetric public key to encrypt the >source system's symmetric key. >6) Transfer both the encrypted data and the encrypted symmetric key >from the source system to the destination system. >7) Use the destination system's asymmetric private key to decrypt the >source system's symmetric key. >8) Use the decrypted source system's symmetric key to decrypt the data. >... >n) PROFIT!!! > >The data and the symmetric key protecting it are only unencrypted on the >source and destination system. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How should I send file to another sysplex securely.
@Mike, thanks for the kind words.
@Grant, yes, exactly, "pure" public key is way too slow to use for a
significant file. The only practical approach is what you call "hybrid."
I would say in no event does the OP want to "roll his own" or "cobble something
together out of bits and pieces."
This problem is what FTP does for a living. Either SFTP ("SSH FTP") which I am
not real familiar with but I know works like a champ, or FTPS (FTP over TLS)
which I am very familiar with. The two are totally different options; they do
not interoperate. A client for one does not talk to a server for the other.
You need a secure (SFTP or FTPS) server at one end (sending or receiving, your
choice) and some configuration at the other end. An investment in secure FTP is
an investment in the future, not just this one problem.
You should be able to find lots of SHARE sessions and so forth on "how to
install and configure and use a secure FTP server." There is help on this forum
if necessary.
Oh! In Step 3 below, add to the sentence "... using a secure
cryptographic-quality random-number generator." Again, you don't want to roll
your own on this. Wy too many traps for the unwary.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Grant Taylor
Sent: Thursday, July 22, 2021 1:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How should I send file to another sysplex securely.
On 7/22/21 12:49 PM, Mike Hochee wrote:
> With private key (aka symmetric ) the same key is used to encrypt and
> decrypt, and the key must be securely shared among business partners
> (a vulnerability). Pervasive or z/OS data set encryption uses private
> key encryption.
>
> With public key model (aka asymmetric) a key pair is generated
> and the keys are mathematically related, this enables the secure
> sharing of a public key with another organization. Public key
> cryptography is quite elegant IMO and solves your chicken/egg
> issue.
There is also a hybrid approach in which a symmetric key is used to
encrypt / decrypt the data and asymmetric keys to protect the first key.
-- My understanding is that symmetric encryption is multiple orders
of magnitude faster than asymmetric encryption.
1) Create an asymmetric public + private key pair on the destination
system.
2) Transfer the destination system's public key to the source system.
3) Create a symmetric key on the source system.
4) Use the source system's symmetric key to encrypt the data.
5) Use the destination system's asymmetric public key to encrypt the
source system's symmetric key.
6) Transfer both the encrypted data and the encrypted symmetric key
from the source system to the destination system.
7) Use the destination system's asymmetric private key to decrypt the
source system's symmetric key.
8) Use the decrypted source system's symmetric key to decrypt the data.
...
n) PROFIT!!!
The data and the symmetric key protecting it are only unencrypted on the
source and destination system.
--
Grant. . . .
unix || die
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How should I send file to another sysplex securely.
On 7/22/21 12:49 PM, Mike Hochee wrote: With private key (aka symmetric ) the same key is used to encrypt and decrypt, and the key must be securely shared among business partners (a vulnerability). Pervasive or z/OS data set encryption uses private key encryption. With public key model (aka asymmetric) a key pair is generated and the keys are mathematically related, this enables the secure sharing of a public key with another organization. Public key cryptography is quite elegant IMO and solves your chicken/egg issue. There is also a hybrid approach in which a symmetric key is used to encrypt / decrypt the data and asymmetric keys to protect the first key. -- My understanding is that symmetric encryption is multiple orders of magnitude faster than asymmetric encryption. 1) Create an asymmetric public + private key pair on the destination system. 2) Transfer the destination system's public key to the source system. 3) Create a symmetric key on the source system. 4) Use the source system's symmetric key to encrypt the data. 5) Use the destination system's asymmetric public key to encrypt the source system's symmetric key. 6) Transfer both the encrypted data and the encrypted symmetric key from the source system to the destination system. 7) Use the destination system's asymmetric private key to decrypt the source system's symmetric key. 8) Use the decrypted source system's symmetric key to decrypt the data. ... n) PROFIT!!! The data and the symmetric key protecting it are only unencrypted on the source and destination system. -- Grant. . . . unix || die -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How should I send file to another sysplex securely.
Hi Colin, Best way probably varies depending on the use case, but basically you have two choices; public or private key cryptography. With private key (aka symmetric ) the same key is used to encrypt and decrypt, and the key must be securely shared among business partners (a vulnerability). Pervasive or z/OS data set encryption uses private key encryption. With public key model (aka asymmetric) a key pair is generated and the keys are mathematically related, this enables the secure sharing of a public key with another organization. Public key cryptography is quite elegant IMO and solves your chicken/egg issue. There are many more moving parts (see the latest draft of RFC 4880 for a look under the OPGP hood) , but most implementations do a good job of hiding extraneous stuff. OpenPGP and OpenSSL are crypto systems based on the public key model. Secure email systems are typically use one of these. A decent public key intro lives here https://en.wikipedia.org/wiki/Public-key_cryptography . Charles Mills gave an xlnt presentation which included coverage of the public key model in Oct 2020... https://www.newera-info.com/CM1.html HTH, Mike -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Colin Paice Sent: Thursday, July 22, 2021 10:08 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: How should I send file to another sysplex securely. Caution! This message was sent from outside your organization. I was wondering the best way customers send sensitive data between z/OS images. I was thinking about exporting one's private certificates. 1. I can create a dataset of the private certificates on system 1 and have it encrypted. I can send it to the other system. How can I decrypt it on the remote system as it needs shared certificates? It seems a chicken and egg problem 2. I can put a password on the file through JCL and use FTPS to send it. This could easily be broken This is hypothetical, but I would be interested in how to do it. Colin Paice -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: How should I send file to another sysplex securely.
On Thu, 22 Jul 2021 14:19:41 +, Horne, Jim wrote: >Why wouldn't you just write a batch job to invoke SFTP? It is z/OS to z/OS >and can handle almost all files, as far as I know > Like most of the suggestions so far, this begs the question of transferring the key. For "almost all files" you need either Dovetailed of flattening with TSO TRANSMIT. Does sftp support anything similar to Diffie-Hellman key exchange? That would still leave the problem of authentication. o Sneakernet? o Cloud? Still the authentication question. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: How should I send file to another sysplex securely.
Why wouldn't you just write a batch job to invoke SFTP? It is z/OS to z/OS and can handle almost all files, as far as I know Jim Horne -Original Message- How about using sftp - of course you would need to copy the file to an omvs file to do it, or get the Dovetail enhanced sftp which supports z/OS datasets. NOTICE: All information in and attached to the e-mails below may be proprietary, confidential, privileged and otherwise protected from improper or erroneous disclosure. If you are not the sender's intended recipient, you are not authorized to intercept, read, print, retain, copy, forward, or disseminate this message. If you have erroneously received this communication, please notify the sender immediately by phone (704-758-1000) or by e-mail and destroy all copies of this message electronic, paper, or otherwise. By transmitting documents via this email: Users, Customers, Suppliers and Vendors collectively acknowledge and agree the transmittal of information via email is voluntary, is offered as a convenience, and is not a secured method of communication; Not to transmit any payment information E.G. credit card, debit card, checking account, wire transfer information, passwords, or sensitive and personal information E.G. Driver's license, DOB, social security, or any other information the user wishes to remain confidential; To transmit only non-confidential information such as plans, pictures and drawings and to assume all risk and liability for and indemnify Lowe's from any claims, losses or damages that may arise from the transmittal of documents or including non-confidential information in the body of an email transmittal. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How should I send file to another sysplex securely.
encrypt and send over NJE using xmit? ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Continuous Monitoring for z/OS, x/Linux & IBM I **| z/VM coming soon * On Thu, Jul 22, 2021 at 5:08 PM Colin Paice wrote: > I was wondering the best way customers send sensitive data between z/OS > images. > I was thinking about exporting one's private certificates. > >1. I can create a dataset of the private certificates on system 1 and >have it encrypted. I can send it to the other system. How can I > decrypt >it on the remote system as it needs shared certificates? It seems a >chicken and egg problem >2. I can put a password on the file through JCL and use FTPS to send >it. This could easily be broken > > This is hypothetical, but I would be interested in how to do it. > > Colin Paice > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How should I send file to another sysplex securely.
How about using sftp - of course you would need to copy the file to an omvs file to do it, or get the Dovetail enhanced sftp which supports z/OS datasets. Lionel B. Dyck <>< Website: https://www.lbdsoftware.com Github: https://github.com/lbdyck “Worry more about your character than your reputation. Character is what you are, reputation merely what others think you are.” - - - John Wooden -Original Message- From: IBM Mainframe Discussion List On Behalf Of Colin Paice Sent: Thursday, July 22, 2021 9:08 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: How should I send file to another sysplex securely. I was wondering the best way customers send sensitive data between z/OS images. I was thinking about exporting one's private certificates. 1. I can create a dataset of the private certificates on system 1 and have it encrypted. I can send it to the other system. How can I decrypt it on the remote system as it needs shared certificates? It seems a chicken and egg problem 2. I can put a password on the file through JCL and use FTPS to send it. This could easily be broken This is hypothetical, but I would be interested in how to do it. Colin Paice -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
How should I send file to another sysplex securely.
I was wondering the best way customers send sensitive data between z/OS images. I was thinking about exporting one's private certificates. 1. I can create a dataset of the private certificates on system 1 and have it encrypted. I can send it to the other system. How can I decrypt it on the remote system as it needs shared certificates? It seems a chicken and egg problem 2. I can put a password on the file through JCL and use FTPS to send it. This could easily be broken This is hypothetical, but I would be interested in how to do it. Colin Paice -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
