Encryption
Does anyone know if ICSF requires specialized hardware to run? Thanks, John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Encryption
Does anyone know of a method/product that would encrypt VSAM data on disk. We are testing the FDR produuct for off-site tapes and based on my experience with Innovation I don't expect any issues. I've been asked about encrypting CICS VSAM data. My response was that the application can make ICSF calls. I don't know of a product we can put in that would handle this. I'm trying to get a handle on the "why would you want this?" with RACF and proper degauzing for drives EMC/HDS/IBM replaces in place. I did search the archives and also got input from the WSC. Any insight from this list would be appreciated. Thanks! Rob _ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Encryption
Certainly you can encrypt VSAM data. What you'd be doing is protecting against the possibility that someone forklifts your IBM, EMC, and/or Hitachi DASD out of your data center. Make sure your security guards serve coffee and donuts to make the thieves more comfortable while they're doing that, OK? :-) Are those data copied anywhere? Like somebody's notebook computer (which will be stolen) or a distributed server (which will be infected by a worm that'll broadcast the info somewhere else, a la CardSystems)? Those are more urgent "worry points." Quite honestly a lot of businesses are going to have to consider their entire data handling strategies (or lack thereof) to solve this problem. And a gigantic part of the answer will be data recentralization. I would point you to two IBM statements of direction, by the way, from July 27th. IBM said two things publicly: (1) IBM will ship a new z/OS product in 2005 for encryption, and it will use ICSF (and thus hardware crypto assist); (2) IBM plans to incorporate encryption capabilities directly into its TotalStorage products. (Insert standard disclaimers here.) I can think of another possibility. If you were to move the data into DB2 you've got two options: DB2's own encryption (which is excellent for field-level) and the DB2/IMS Encryption Tool (which is excellent for row-level and table-level). There's a great article in the August z/OS "Hot Topics" newsletter, published online by IBM, which discusses DB2 encryption. To get VSAM into DB2 without changing your application code you can use something called VSAM Transparency. That recipe is another way to do this, and it will be of primary interest to those shops with a direction to move data into DB2 (to better support continuous online operations, for example, or to provide improved access via things like JDBC). Sometimes you can do very well from a workload point of view if you're able to take advantage of things like DB2 V8's materialized query tables. I posted a pretty complete list of encryption products to IBM-MAIN a few weeks ago, so be sure to look at that in the archives. Hope that helps. - - - - - Timothy F. Sipples Consulting Enterprise Software Architect IBM Americas zSeries/z9 Software NEW Phone: +1 312 529 1612 E-Mail: [EMAIL PROTECTED] (PGP key available.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
ABARS encryption
With the announcement of encryption to DFDSS, will ABARS take advantage of this to encrypt its output? This would include encrypting input from DASD and TAPE. Has anyone done this process successfully yet? Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
File encryption
Hi folks To meet certain credit-card industry governing body requirements, I've been told we have to encrypt credit card numbers in any file that is permanently stored on disk or tape. It doesn't have to be the whole file (and I've argued that would be wasteful anyway), but the fields holding card numbers. Does anyone know of any kind of middleware or perhaps exit-driven software or something that can sit in between our (home-grown) batch and CICS applications and encrypt/decrypt, preferably in a 'just in time' manner? I've only managed so far to find references to IBM's "Encryption Facility" which doesn't look quite like what I'm after, and something called MegaCryption which is marketed here in Europe by a reseller (Software Europe Ltd) Thanks in advance Brian This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction NetworkServices. Any unauthorized review, use, disclosure or distribution isprohibited. If you are not the intended recipient, please contact thesender by reply e-mail and destroy all copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Encryption & SMS
Hi, I received a note mentioning a vendor is developing an encryptrion product. They mentioned in the note: " The OPEN intercept will still need to check the SMS ACS to determine which encryption method to use." My question is what is the diffenece between an encryption routine for SMS -vs- non-SMS. Is this product specific or does it have to do with SMS itself ? TIA Dean Dean Montevago Sr. Systems Specialist Visiting Nurse Service of New York (212) 609 - 5596 [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Tape Encryption
All, I need some information about 'Tape Encryption'. Maybe your company has used the s/w to encrypt the data in tape in mainframe. My company need this information... Thanks for your help. Regards. Albertus SD __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
VTAM encryption
Dear listers I am interested in implementing some kind of session level encryption for SNA data (LU 6.2 \ Enterprise Extender) but do not have a crypto processor. Is it possible to do Session level encryption. IPSEC still far away for us. regards Munif -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
More Encryption
Hi, Does any know if IBM sells hardware that you can use at the tape drive for compression/encryption ? I found a few vendors that make such equipment but they don't support Escon. TIA Dean Dean Montevago Sr. Systems Specialist Visiting Nurse Service of New York phone: (212) 609 - 5596 email: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Data Encryption
Is anyone out there doing data encryption to tape? If so how hard is it to set up. We have a Z/os 1.4 system on a z800 series box with data encryption cards. I was wondering if we need anything else to do the data encryption. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
TAPE Encryption
When you run tape Encryption on a stacked tape do you encrypt all files that are stacked on a tape or just one file on the stacked tape? For example, I have a batch backup job that places 35 dumped volumes on one tape. I have looked at the doc and it seems I could place the encryption on the first file only and the whole tape will be encrypted. Or does it not take any more time or resources to have encryption happen for each volume on the stacked tape? I have been asked to place encrption on each file via Dataclas/ACS routines on a stacked tape. I am just trying to get a handle of what the performance trade offs are. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encryption
Needs hardware on the Z800. Will run on a Z890 using a GP engine. Not sure on the Z9xx's -Original Message- From: John Abernethy [mailto:[EMAIL PROTECTED] Sent: Monday, June 06, 2005 3:15 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Encryption Does anyone know if ICSF requires specialized hardware to run? Thanks, John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encryption
In a recent note, John Abernethy said: > Date: Mon, 6 Jun 2005 18:15:15 -0400 > > Does anyone know if ICSF requires specialized > hardware to run? > Yes, but the hardware is included in the base price of many high-end systems. But the hardware requires FE action (no charge) to activate. -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encryption
In a message dated 6/6/2005 5:15:47 P.M. Central Standard Time, [EMAIL PROTECTED] writes: Does anyone know if ICSF requires specialized hardware to run? What type machine? On G5's it's a seperately orderable feature(Cryptographic coprocessor) as is the enabling uCode. No charge, but adds to maint agreement(sometimes). The uCode diskette comes from France and takes two weeks to be processed. The local branch tried to charge us lots, but ended up paying $100 for paperwork. Most folks order with and enable as the need arises. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encryption
John Abernethy wrote: Does anyone know if ICSF requires specialized hardware to run? On all machines before the z990 and z890, in order to run ICSF you need to have the CCFs (Cryptographic Coprocessor Feature) activated, a master key properly set and a CKDS (Cryptographic Key Data Set) allocated. On the z990 and z890, the minimum you need to be able to run ICSF is to have CPACF (CP Assist for Cryptographic Functions), a feature that comes with every processor, activated. Activation of the CCFs requires a Hardware Enablement Diskette (orderable as a feature) which needs to be loaded by an IBM CE over a POR (Power-On Reset). Activation of CPACF also requires a feature to be ordered but does not require a POR. -- Ulrich Boche SVA GmbH, Germany IBM Premier Business Partner -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encryption
Ed, The machine is a z800. They want to encrypt things on a PC type machine and send it to the MAINFRAME. Decrypt it and process it and then save it on a file on the MAINFRAME in encrypted format. At least that is what I understand. The powers to be change their ideas from minute to minute and listen to no one with the knowledge(Which obviously is not me - maybe that means they'll at least listen)(being sarcastic sorry.) They are hoping to be able to encrypt/decrypt with only software. That is why I am asking about the hardware requirement(no money for the MAINFRAME - we have traversed to the dark side and I don't know when we will be back.) Thanks, John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encryption
I feel your pain. We've also been required to do more encryption with our vendors. We currently have PGP/GPG (the freeware copy) and bTrade (from Citigroup) loaded on our ftp server. This solution has been working ok so far. We'll be upgrading to a Z890 next year so that'll take care of ICSF. -Original Message- From: John Abernethy [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 07, 2005 7:27 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Encryption Ed, The machine is a z800. They want to encrypt things on a PC type machine and send it to the MAINFRAME. Decrypt it and process it and then save it on a file on the MAINFRAME in encrypted format. At least that is what I understand. The powers to be change their ideas from minute to minute and listen to no one with the knowledge(Which obviously is not me - maybe that means they'll at least listen)(being sarcastic sorry.) They are hoping to be able to encrypt/decrypt with only software. That is why I am asking about the hardware requirement(no money for the MAINFRAME - we have traversed to the dark side and I don't know when we will be back.) Thanks, John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encryption
In a message dated 6/7/2005 9:27:56 A.M. Central Standard Time, [EMAIL PROTECTED] writes: The machine is a z800. They want to encrypt things on a PC type machine and send it to the MAINFRAME. Decrypt it and process it and then save it on a file on the MAINFRAME in encrypted format. At least that is what I understand. The powers to be change their ideas from minute to minute and listen to no one with the knowledge(Which obviously is not me - maybe that means they'll at least listen)(being sarcastic sorry.) >> Probably be easier and safer to just put on z/FS on the PC side and see if can figure out a way to read it on z/OS. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encryption
John Abernethy wrote: Ed, The machine is a z800. They want to encrypt things on a PC type machine and send it to the MAINFRAME. Decrypt it and process it and then save it on a file on the MAINFRAME in encrypted format. At least that is what I understand. The powers to be change their ideas from minute to minute and listen to no one with the knowledge(Which obviously is not me - maybe that means they'll at least listen)(being sarcastic sorry.) They are hoping to be able to encrypt/decrypt with only software. That is why I am asking about the hardware requirement(no money for the MAINFRAME - we have traversed to the dark side and I don't know when we will be back.) Thanks, John In your case, the best solution would probably be to get or buy a product that supports encryption/decryption on both Windows and z/OS. One example that comes to mind is SecureZIP from PKWARE but there might be others. I think it would be a good idea to think about the key management and, if possible, select a product that doesn't require you to send passwords or keys around all the time. On the z800, the CCFs are a chargeable feature that will cost you somewhere between USD 3000 - 5000. ICSF is just a toolbox, so then you will still need to do the programming and testing on both platforms. I wouldn't want to do that. -- Ulrich Boche SVA GmbH, Germany IBM Premier Business Partner -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encryption
on 6/8/05 1:56 PM, Ulrich Boche at [EMAIL PROTECTED] wrote: >> > > In your case, the best solution would probably be to get or buy a > product that supports encryption/decryption on both Windows and z/OS. > One example that comes to mind is SecureZIP from PKWARE but there might > be others. I think it would be a good idea to think about the key > management and, if possible, select a product that doesn't require you > to send passwords or keys around all the time. > > On the z800, the CCFs are a chargeable feature that will cost you > somewhere between USD 3000 - 5000. ICSF is just a toolbox, so then you > will still need to do the programming and testing on both platforms. I > wouldn't want to do that. This information is old but beware of PKWARE their dependance and licensing on CPU serial numers is a PITA and last I heard they do not have tech support after hours. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encryption
There's a pretty good technical introduction to ICSF published in z/Journal last year: http://www.zjournal.com/PDF/sarasin-may.pdf Note that, since that article, the z890 was introduced, and that model also has the hardware to support ICSF. I understand that the 990 and 890 have special, new crypto-related instructions -- in addition to the PCI cards and CP Assist features -- that may offer some benefits for certain encryption algorithms and software. There's some more information here: http://www.research.ibm.com/journal/rd/483/slegel.html "Clear key" DES and Triple DES (3DES) benefit from the "on board" hardware (incl. CP Assist), while the various PCI cards can handle more algorithms. Choose your encryption algorithms carefully, depending on what you're trying to accomplish. Generally the PCI cards are best suited for network-related encryption (MQ, HTTPS) and the on boards for storage-related encryption (tape, disk). None of this will be "free" -- there will be CP MIPS -- but the three levels of extra hardware assist can help, sometimes a lot. The analogy to ICSF in the Linux world is OpenSSL. If you've got the right kernel and OpenSSL version, and your Linux software is using OpenSSL, it should exploit the hardware appropriately. Not sure about TPF, VSE, and VM, but I think all of those OSes will exploit the hardware, too, in their own ways. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encryption
In a recent note, Timothy Sipples said: > Date: Fri, 10 Jun 2005 09:02:08 -0500 > > The analogy to ICSF in the Linux world is OpenSSL. If you've got the right > kernel and OpenSSL version, and your Linux software is using OpenSSL, it > should exploit the hardware appropriately. > Linux? Interesting. I had thought the interfaces to the encryption hardware were Trade Secret? Has IBM opened the specifications? Or have they provided a closed-source driver (allowed by GPL) with open specifications at a higher layer? In somewhat related business news, IBM has unlocked the cell: http://news.google.com/news?q=ibm+cell Who knows? If there's an open interface to the crypto hardware, might the ETR be next? -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encryption
Linux? Interesting. I had thought the interfaces to the encryption hardware were Trade Secret? The new instructions which invoke the z890/z990 cryptographic co-processor are documented in the latest PoPs. -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encryption
In a recent note, Bruce Black said: > Date: Fri, 10 Jun 2005 10:49:53 -0400 > > The new instructions which invoke the z890/z990 cryptographic > co-processor are documented in the latest PoPs. > Ummm. The best I can find is: Linkname: CONTENTS "z/Architecture Principles of Operation" IBM Library Server URL: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003 Title: z/Architecture Principles of Operation Document Number: SA22-7832-03 Build Date: 05/04/04 12:13:20 Build Version: 1.3.1 of BUILD/VM Version: UG03935 DropDate: Thursday August 8, 2003 Book Path: /home/webapps/epubs/htdocs/book/dz9zr003.boo with: # 2.3.7 "z/Architecture Principles of Operation" ___ 2.3.7 Cryptographic Facility Depending on the model, an integrated cryptographic facility may be provided as an extension of the CPU. When the cryptographic facility is provided on a CPU, it functions as an integral part of that CPU. A summary of the benefits of the cryptographic facility is given on page 1.3; the facility is otherwise not described. And, irritatingly the "Hardware" link on: Linkname: IBM: z/OS Internet Library - Technical documentation and literature for the z/OS platform URL: http://www-1.ibm.com/servers/eserver/zseries/zos/bkserv/ ... takes me to S/390 hardware. -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encryption
-Original Message- From: "Paul Gilmartin" <[EMAIL PROTECTED]> Sent: 6/11/2005 10:48 AM To: "IBM-MAIN@BAMA.UA.EDU" Subject: Re: Encryption In a recent note, Bruce Black said: > Date: Fri, 10 Jun 2005 10:49:53 -0400 > > The new instructions which invoke the z890/z990 cryptographic > co-processor are documented in the latest PoPs. > Ummm. The best I can find is: Linkname: CONTENTS "z/Architecture Principles of Operation" IBM Library Server URL: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003 Title: z/Architecture Principles of Operation Document Number: SA22-7832-03 Build Date: 05/04/04 12:13:20 Build Version: 1.3.1 of BUILD/VM Version: UG03935 DropDate: Thursday August 8, 2003 Book Path: /home/webapps/epubs/htdocs/book/dz9zr003.boo with: # 2.3.7 "z/Architecture Principles of Operation" ___ 2.3.7 Cryptographic Facility Depending on the model, an integrated cryptographic facility may be provided as an extension of the CPU. When the cryptographic facility is provided on a CPU, it functions as an integral part of that CPU. A summary of the benefits of the cryptographic facility is given on page 1.3; the facility is otherwise not described. And, irritatingly the "Hardware" link on: Linkname: IBM: z/OS Internet Library - Technical documentation and literature for the z/OS platform URL: http://www-1.ibm.com/servers/eserver/zseries/zos/bkserv/ ... takes me to S/390 hardware. -- gil -- StorageTek INFORMATION made POWERFUL ==== The original encryption instructions for the ICRF were supervisor state only. They provided single cipher, chained cipher, and various PIN and message authentication verification. IBM chose not to document the instructions for various reasons, including reserving the freedom to change the specifications. Only the software ICSF used the machine instructions, so changing the ICRF specifications would only affect the software in the ICSF. I wrote ICRF emulation code for the Amdahl 5990 using the IBM internal documentation (TIDA) that Amdahl had to buy from IBM. The entire ICRF hardware is somewhat daunting with very complex algorithms. The ciphering instructions have been copied to new opcodes and made available for problem state. The original opcodes for the supervisor state instructions will likely go away after a time and the opcodes will be recycled for something else. Opcode real estate is still very valuable, so it will make sense to reuse the obsolete undocumented opcodes for newer features. btw: The original chained ciphering was the first instruction that I noticed that had the "come up for air" condition code that ends the operation early. It was condition code 2. Now, IBM seems to have standardized on using condition code 3 for "come up for air" early end. Much better IMHO. Jeffrey D. Smith Farsight Systems Corporation 24 BURLINGTON DR LONGMONT, CO 80501 303-774-9381 http://www.farsight-systems.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encryption
The Linux cryptographic driver is called z90crypt, and the source code for that driver has been available, open source, in the Linux kernel for a number of years now. Just look for z90crypt source at your favorite kernel source download site. The IBM download site is located here: http://www.ibm.com/developerworks/linux/linux390 The z90crypt driver is loadable via modprobe, or you can compile it into the kernel. You can do a cat /proc/driver/z90crypt to see status of the driver and underlying hardware. The various bits that sit on top of z90crypt (libica, openCryptoki) are also available in open source form. (OpenSSL can use these libraries.) See: http://sourceforge.net/projects/opencryptoki You may also want to look at the manual entitled "Linux on zSeries Device Drivers and Installation Commands" which has a little more detail on z90crypt. I can't say I've looked at the z90crypt code at all, but hopefully this info will give you some assistance. - - - - - Timothy F. Sipples Senior Software Architect, Enterprise Transformation IBM Americas zSeries Software Phone: (312) 245-4003 E-Mail: [EMAIL PROTECTED] (PGP key available.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
DFHSM Encryption
Is anyone aware of a method to encrypt DFHSM Backups, Dumps and ML2 data at time of creation? An after-the-fact copy of the data is not an acceptable option! I have RTFM'ed and can find no indication of DFHSM/ICSF (or any other) encryption support. THanks in advance, -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encryption
Surfer SIC wrote: Does anyone know of a method/product that would encrypt VSAM data on disk. We are testing the FDR produuct for off-site tapes and based on my experience with Innovation I don't expect any issues. I've been asked about encrypting CICS VSAM data. My response was that the application can make ICSF calls. I don't know of a product we can put in that would handle this. I'm trying to get a handle on the "why would you want this?" with RACF and proper degauzing for drives EMC/HDS/IBM replaces in place. I did search the archives and also got input from the WSC. Any insight from this list would be appreciated. Encrypting VSAM file differs from encrypting tapes. The main difference is the program used to read/write. It is "backup+encrypt" in FDR case. In VSAM case it is CICS/application. In this case it is reasonable to encrypt *fields*, not *records*. IMHO encrypting records could lead to problem with KSDS key (of course not all VSAM is KSDS). So first - what are your needs Second - what are your apps using the data Third what are the possibilities. HTH -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encryption
Shouldn't first be What are your business goals? What threat are you trying to protect against? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of R.S. Sent: Wednesday, August 31, 2005 8:25 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Encryption Surfer SIC wrote: > Does anyone know of a method/product that would encrypt VSAM data on > disk. We are testing the FDR produuct for off-site tapes and based on my So first - what are your needs Second - what are your apps using the data Third what are the possibilities. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encryption
The business goal? The description I've received is "a company wide committee is setting the requirements - then telling the data center they have to find answers." So I can't state a real business goal. SOX etc. is probably driving this, whether it should be or not. It is financial data. I am doing my best to refrain from editorializing about committees and such. Rob _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encryption
Surfer SIC wrote: The business goal? The description I've received is "a company wide committee is setting the requirements - then telling the data center they have to find answers." So I can't state a real business goal. SOX etc. is probably driving this, whether it should be or not. It is financial data. I am doing my best to refrain from editorializing about committees and such. Business goal sounds too general and too 'political' for me. Let's go simpler: *what data* do you want to encrypt ? Your target is not VSAM file (as structure of CIs, index set, CAs, etc.) itself. It contains records, records contain fields, probably only some of them need to be encrypted. For example your record contain customer id (*) and custmer PIN (for VISA card). Id need not to be encrypted, while PIN have to be. (*) It should be rather card no, but it's only example. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encryption
Certainly you can encrypt VSAM data. What you'd be doing is protecting against the possibility that someone forklifts your IBM, EMC, and/or Hitachi DASD out of your data center. Make sure your security guards serve coffee and donuts to make the thieves more comfortable while they're doing that, OK? :-) Encryption is most often used for data going offsite. But so many installations are using remote mirroring (PPRC, SRDF, XRC, etc) that a lot of "live" data is also going offsite. It would still require someone to have access to the remote control unit (logical or physical access) but there is a good chance that access is not controlled as strictly as at your home data center. If it is at a commercial DR site, with other clients coming in all the time to run tests, can the DR vendor guarantee that no other customer can access your data? So remote mirroring is a good argument for encrypting important data on disk. One term I have heard lately: encrypting "data at rest", meaning that data on disk or tape is encrpypted, and only decrypted when it is in use by a program. -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encryption
Bruce Black wrote: [...] Encryption is most often used for data going offsite. But so many installations are using remote mirroring (PPRC, SRDF, XRC, etc) that a lot of "live" data is also going offsite. It would still require someone to have access to the remote control unit (logical or physical access) but there is a good chance that access is not controlled as strictly as at your home data center. If it is at a commercial DR site, with other clients coming in all the time to run tests, can the DR vendor guarantee that no other customer can access your data? So remote mirroring is a good argument for encrypting important data on disk. One term I have heard lately: encrypting "data at rest", meaning that data on disk or tape is encrpypted, and only decrypted when it is in use by a program. IMHO encrypting "data at rest" is 1. overkill 2. waste of resources - definitely not all of the data need to be encrypted 3. rarely used. Instead of encryption, "traditional protection means are taken, like physical security of devices and Resource Access Control (Facility). Probably more popular approach is to encrypt *some* data, the most sensitive, like PINs, passwords, etc. Probably some of them can be encrypted using one-way methods. Data format (VSAM, DB2 table, PS file) has very little to do with, since "encrypted" records do not differ from "unencrypted" ones - in terms of access method, etc. IMHO such encryption is quite common in banks, card systems, and others. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encryption
Easy to see why it would be wanted. The problem is that encryption at that level would most likely require massive application changes. Even so, AFAIK, data encryption / decryption is the easy part. The hard part is managing all those keys. The keys themselves cannot flow in the open. They, too, have to be encrypted. As do those keys, etc etc etc. If the keys to a file are well known, then what's the point? So, we get down to basics: if all access to the file is properly controlled, they why bother with encryption? Encryption comes into play when physical control is not possible: on a tape, PC, or network. But then the key management issue rears its ugly head. HTH and good luck. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Surfer SIC Sent: Wednesday, August 31, 2005 10:15 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Encryption Does anyone know of a method/product that would encrypt VSAM data on disk. We are testing the FDR produuct for off-site tapes and based on my experience with Innovation I don't expect any issues. I've been asked about encrypting CICS VSAM data. My response was that the application can make ICSF calls. I don't know of a product we can put in that would handle this. I'm trying to get a handle on the "why would you want this?" with RACF and proper degauzing for drives EMC/HDS/IBM replaces in place. I did search the archives and also got input from the WSC. Any insight from this list would be appreciated. Thanks! Rob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ABARS encryption
On Wed, 7 Dec 2005 09:50:00 -0600, Frank Rodriguez <[EMAIL PROTECTED]> wrote: >With the announcement of encryption to DFDSS, will ABARS take advantage of >this to encrypt its output? This would include encrypting input from DASD >and TAPE. >Has anyone done this process successfully yet? >Thanks > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO >Search the archives at http://bama.ua.edu/archives/ibm-main.html It looks like APAR OA13453 provides this support. We do not use DFSMShsm or ABARS, though. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ABARS encryption
Nope. That is for DFSMShsm full volume dumps which are not the same as ABARS even if they do both run thru DFSMShsm. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of DeFabritus, Peter [NCSUS Non-J&J] Sent: Wednesday, December 07, 2005 11:34 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: ABARS encryption On Wed, 7 Dec 2005 09:50:00 -0600, Frank Rodriguez <[EMAIL PROTECTED]> wrote: >With the announcement of encryption to DFDSS, will ABARS take advantage >of this to encrypt its output? This would include encrypting input from >DASD and TAPE. >Has anyone done this process successfully yet? >Thanks > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, send >email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO >Search the archives at http://bama.ua.edu/archives/ibm-main.html It looks like APAR OA13453 provides this support. We do not use DFSMShsm or ABARS, though. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Encryption Best practices.
Cross posted to MVS and RACF. Can anyone point me to some authority that rates tools such as password protected PKzip files as to strength and acceptability for personal data? Thanks, and the best of the season to all. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Clear key encryption
Hello all. I was wondering if anyone could explain to me what Clear Key Encryption VS None clear Encryption is. I looked in the archives, but only found a reference that clear key could run on the T-REX. I thought that clear key encryption was purely SSL and the other was DES/3DES where the 3des keys are encrypted by the master. The reason I am asking is because we will be encrypting our data for offsite export. I don't believe that ssl would be a good way to do it. Thanks in advance. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: File encryption
I wrote a callable routine that uses ICSF services to encrypt/decrypt data passed to it. If enough people express a desire for it, I can request that it be added to the CBT tape. Mark Jacobs Time Customer Service Inc. Tampa, FL Time Inc -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Perryman, Brian Sent: Thursday, February 09, 2006 8:29 AM To: IBM-MAIN@BAMA.UA.EDU Subject: File encryption Hi folks To meet certain credit-card industry governing body requirements, I've been told we have to encrypt credit card numbers in any file that is permanently stored on disk or tape. It doesn't have to be the whole file (and I've argued that would be wasteful anyway), but the fields holding card numbers. Does anyone know of any kind of middleware or perhaps exit-driven software or something that can sit in between our (home-grown) batch and CICS applications and encrypt/decrypt, preferably in a 'just in time' manner? I've only managed so far to find references to IBM's "Encryption Facility" which doesn't look quite like what I'm after, and something called MegaCryption which is marketed here in Europe by a reseller (Software Europe Ltd) Thanks in advance Brian This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction NetworkServices. Any unauthorized review, use, disclosure or distribution isprohibited. If you are not the intended recipient, please contact thesender by reply e-mail and destroy all copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: File encryption
In a recent note, Mark Jacobs said: > Date: Thu, 9 Feb 2006 08:53:17 -0500 > > I wrote a callable routine that uses ICSF services to encrypt/decrypt > data passed to it. If enough people express a desire for it, I can > request that it be added to the CBT tape. > I had thought that CSNBENC was a callable routine that uses ICSF services to encrypt data passed to it. -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: File encryption
Yes. What I thought Bryan wanted was a program that would use ICSF services to encrypt/decrypt data passed to it. That is the program I was offering to the CBT tape. Mark Jacobs -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin Sent: Thursday, February 09, 2006 9:11 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: File encryption In a recent note, Mark Jacobs said: > Date: Thu, 9 Feb 2006 08:53:17 -0500 > > I wrote a callable routine that uses ICSF services to encrypt/decrypt > data passed to it. If enough people express a desire for it, I can > request that it be added to the CBT tape. > I had thought that CSNBENC was a callable routine that uses ICSF services to encrypt data passed to it. -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: File encryption
Indeed. Well, I think so anyway..(!) We've not done anything with CSF at the moment (nor do we have a crypto-coprocessor) so this is all new to us. We're after something that is as transparent as possible and involves the least amount of program re-engineering, though.. Brian - This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction NetworkServices. Any unauthorized review, use, disclosure or distribution isprohibited. If you are not the intended recipient, please contact thesender by reply e-mail and destroy all copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: File encryption
Well both IBM's product and MegaCryption work on a file by file basis. They don't do anything for fields within records. What model mainframe do you have? You might have the crypto-coprocessors available and not even know it. Mark Jacobs -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Perryman, Brian Sent: Thursday, February 09, 2006 9:21 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: File encryption Indeed. Well, I think so anyway..(!) We've not done anything with CSF at the moment (nor do we have a crypto-coprocessor) so this is all new to us. We're after something that is as transparent as possible and involves the least amount of program re-engineering, though.. Brian - This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction NetworkServices. Any unauthorized review, use, disclosure or distribution isprohibited. If you are not the intended recipient, please contact thesender by reply e-mail and destroy all copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: File encryption
Nope, it's a 7060-H30, we definitely don't have a crypto on it. We're going to z890 late this year/early next and we'll be specifying crypto options on that. It sounds like I might be in for a disappointment with MegaCryption then.. I was getting the impression from their brochure that it would do field-level. :-( Brian -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Mark Jacobs Sent: 09 February 2006 14:25 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: File encryption Well both IBM's product and MegaCryption work on a file by file basis. They don't do anything for fields within records. What model mainframe do you have? You might have the crypto-coprocessors available and not even know it. Mark Jacobs - This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction NetworkServices. Any unauthorized review, use, disclosure or distribution isprohibited. If you are not the intended recipient, please contact thesender by reply e-mail and destroy all copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: File encryption
You might be right. I haven't looked at the doc in a while. Depending on how much data you are encrypting you might be taking a performance hit since the encryption and decryption has to be done in software without hardware assists. Mark Jacobs -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Perryman, Brian Sent: Thursday, February 09, 2006 9:30 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: File encryption Nope, it's a 7060-H30, we definitely don't have a crypto on it. We're going to z890 late this year/early next and we'll be specifying crypto options on that. It sounds like I might be in for a disappointment with MegaCryption then.. I was getting the impression from their brochure that it would do field-level. :-( Brian -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Mark Jacobs Sent: 09 February 2006 14:25 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: File encryption Well both IBM's product and MegaCryption work on a file by file basis. They don't do anything for fields within records. What model mainframe do you have? You might have the crypto-coprocessors available and not even know it. Mark Jacobs - This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction NetworkServices. Any unauthorized review, use, disclosure or distribution isprohibited. If you are not the intended recipient, please contact thesender by reply e-mail and destroy all copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: File encryption
On 2/9/06, Perryman, Brian <[EMAIL PROTECTED]> wrote: > > Nope, it's a 7060-H30, we definitely don't have a crypto on it. We're > going to z890 late this year/early next and we'll be specifying crypto > options on that. > > It sounds like I might be in for a disappointment with MegaCryption then.. > I was getting the impression from their brochure that it would do > field-level. :-( > > Brian > > -Original Message- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] > Behalf Of Mark Jacobs > Sent: 09 February 2006 14:25 > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: File encryption > > > Well both IBM's product and MegaCryption work on a file by file basis. > They don't do anything for fields within records. > > What model mainframe do you have? You might have the crypto-coprocessors > available and not even know it. > > Mark Jacobs > > - > This e-mail message is for the sole use of the intended recipient(s)and > may > contain confidential and privileged information of Transaction > NetworkServices. > Any unauthorized review, use, disclosure or distribution isprohibited. If > you > are not the intended recipient, please contact thesender by reply e-mail > and > destroy all copies of the original message. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: File encryption
Brian, I presume you're putting the bookshop in Devon on hold then. Jim McAlpine On 2/9/06, Perryman, Brian <[EMAIL PROTECTED]> wrote: > > Nope, it's a 7060-H30, we definitely don't have a crypto on it. We're > going to z890 late this year/early next and we'll be specifying crypto > options on that. > > It sounds like I might be in for a disappointment with MegaCryption then.. > I was getting the impression from their brochure that it would do > field-level. :-( > > Brian > > -Original Message- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] > Behalf Of Mark Jacobs > Sent: 09 February 2006 14:25 > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: File encryption > > > Well both IBM's product and MegaCryption work on a file by file basis. > They don't do anything for fields within records. > > What model mainframe do you have? You might have the crypto-coprocessors > available and not even know it. > > Mark Jacobs > > - > This e-mail message is for the sole use of the intended recipient(s)and > may > contain confidential and privileged information of Transaction > NetworkServices. > Any unauthorized review, use, disclosure or distribution isprohibited. If > you > are not the intended recipient, please contact thesender by reply e-mail > and > destroy all copies of the original message. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: File encryption
:-) -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Jim McAlpine Sent: 09 February 2006 15:28 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: File encryption Brian, I presume you're putting the bookshop in Devon on hold then. Jim McAlpine This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction NetworkServices. Any unauthorized review, use, disclosure or distribution isprohibited. If you are not the intended recipient, please contact thesender by reply e-mail and destroy all copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: File encryption
On a more serious and topical note though, it seems like you've had a reprieve since you wrote about your probable forced retirement 3 years ago. What's the situation now. We all like to know about projects to "get off the mainframe" that don't happen. Jim McAlpine On 2/9/06, Perryman, Brian <[EMAIL PROTECTED]> wrote: > > :-) > > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] > Behalf Of Jim McAlpine > Sent: 09 February 2006 15:28 > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: File encryption > > > Brian, I presume you're putting the bookshop in Devon on hold then. > > Jim McAlpine > This e-mail message is for the sole use of the intended recipient(s)and > may > contain confidential and privileged information of Transaction > NetworkServices. > Any unauthorized review, use, disclosure or distribution isprohibited. If > you > are not the intended recipient, please contact thesender by reply e-mail > and > destroy all copies of the original message. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: File encryption
I've already place a basic module on the CBT tape. File 529. It uses AES and the ICSF subroutines. I never tried it without Crypto hardware, but maybe it would work, since AES keys are processed as clear keys. This changes with the Z9 machine. On Thu, 9 Feb 2006 09:34:39 -0500, Mark Jacobs <[EMAIL PROTECTED]> wrote: >You might be right. I haven't looked at the doc in a while. Depending on >how much data you are encrypting you might be taking a performance hit >since the encryption and decryption has to be done in software without >hardware assists. > >Mark Jacobs > >-Original Message- >From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On >Behalf Of Perryman, Brian >Sent: Thursday, February 09, 2006 9:30 AM >To: IBM-MAIN@BAMA.UA.EDU >Subject: Re: File encryption > >Nope, it's a 7060-H30, we definitely don't have a crypto on it. We're >going to z890 late this year/early next and we'll be specifying crypto >options on that. > >It sounds like I might be in for a disappointment with MegaCryption >then.. I was getting the impression from their brochure that it would do >field-level. :-( > >Brian > >-Original Message- >From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] >Behalf Of Mark Jacobs >Sent: 09 February 2006 14:25 >To: IBM-MAIN@BAMA.UA.EDU >Subject: Re: File encryption > > >Well both IBM's product and MegaCryption work on a file by file basis. >They don't do anything for fields within records. > >What model mainframe do you have? You might have the crypto-coprocessors >available and not even know it. > >Mark Jacobs -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: File encryption
Brian, Our CopyCrypt product does not encrypt at the field level but we can definitely be very selective on tape files that need to be encrypted. We support IBM co-processors and ICSF so the keys are secured. This product can also use passwords (clear key) to encrypt tape files. A free utility can be used to decrypt the file to disk or tape for B2B applications. We also support disk to tape encryption. Visit our web site for more information: www.opentechsystems.com . Don Bolton Dir Technical Services OpenTech Systems, Inc. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Perryman, Brian Sent: Thursday, February 09, 2006 7:29 AM To: IBM-MAIN@BAMA.UA.EDU Subject: File encryption Hi folks To meet certain credit-card industry governing body requirements, I've been told we have to encrypt credit card numbers in any file that is permanently stored on disk or tape. It doesn't have to be the whole file (and I've argued that would be wasteful anyway), but the fields holding card numbers. Does anyone know of any kind of middleware or perhaps exit-driven software or something that can sit in between our (home-grown) batch and CICS applications and encrypt/decrypt, preferably in a 'just in time' manner? I've only managed so far to find references to IBM's "Encryption Facility" which doesn't look quite like what I'm after, and something called MegaCryption which is marketed here in Europe by a reseller (Software Europe Ltd) Thanks in advance Brian This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction NetworkServices. Any unauthorized review, use, disclosure or distribution isprohibited. If you are not the intended recipient, please contact thesender by reply e-mail and destroy all copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: File encryption
Brian, One thing that we're all assuming is that you're talking about VSAM. Is that correct? If it's DB2 (or even IMS), there are some pretty easy ways to get encryption. DB2 V8 has a new ENCRYPT word in its SQL vocabulary for column-level encryption. There's also something called IBM Data Encryption for IMS and DB2 Databases, a utility which encrypts at the table level (and, thus, doesn't require changing any application code). It works with DB2 V7 and V8. I suppose it would be possible to combine VSAM Transparency with Data Encryption for IMS and DB2 Databases to provide encryption for a VSAM-based application without application code changes. The data actually end up in DB2 (encrypted), but your applications still think the data are in VSAM. If we're talking about VSAM (and remaining in VSAM), as we're assuming, then I would echo the earlier comments that recommend using ICSF interfaces absent a compelling reason. There are at least two reasons. First, ICSF will try to use underlying hardware crypto assist if it can, and that'll help as you change your model over to the z890. (Just choose your algorithm carefully. I would recommend clear key 3DES.) Second, ICSF manages your encryption keys. Lose the keys and you lose your data, so the keys are very important. ICSF has a long and distinguished history of managing encryption keys safely and securely, including through DR episodes. You can verify the use of the crypto assist hardware when you run the usual assortment of activity reports (e.g. RMF) or look at monitoring tools (e.g. OMEGAMON). There is an IBM statement of direction concerning the addition of cryptographic features in its TotalStorage products at some point in 2006. There may or may not be statements along those lines from other storage vendors. The hardware direction may or may not be relevant to you. (I tend to think it'll be quite useful but that crypto hardware-boosted software encryption will still be essential. And there will be some shops that want encryption over the FICON or ESCON cables.) The IBM Encryption Facility for z/OS is really geared toward tape, although it can encrypt sequential files on disk if you wish. Its primary mission is to help protect backup/archive tapes as well as tapes for partner exchange. I've posted a list of tape encryption products in the past -- check the archives -- and there are a couple others that have been mentioned since (specifically a CA-BrightStor product and the one from OpenTech). My personal opinion is that any software tape encryption product should have two basic features: support for the crypto-assist hardware (for performance reasons) and use of ICSF facilities for key management (for reliable data recoverability). Your question is good evidence that every organization will be touched by privacy protection concerns either before data loss or, in some cases, after. Since it's already happened I'm predicting that there will be some number of future corporate collapses caused by leakage of private information. I'm glad to hear your company is working ahead of the problem proactively. It's something I'm warning all clients about. - - - - - Timothy F. Sipples Consulting Enterprise Software Architect, z9/zSeries IBM Japan, Ltd. E-Mail: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: File encryption
Hi Timothy Yes, it's curently VSAM and QSAM, we don't have any databases. But the PCI-S standard to which we're having to comply (see the relevant VISA web sites for more details) specifies that ANY data file stored permanently on disk must have cardholder information encrypted so, basically, any access method is affected. Of course there are many ways in which the original problem of cardnumber theft could have been avoided right back at the original application design phases (for instance, by not using the actual card numbers in application processing, but using it instead right at the transaction acquisition stage as a look-up to some sort of 'account' number/key, which is passed throughout processing instead but means nothing to unauthorised viewers if the transaction file should fall into the wrong hands) but these sort of things are way too late now and we have to live with the sledgehammer to crack a nut policies. Brian - -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Encryption Facility Client
I think IBM dropped the ball, here! The intent was to allow you to encrypt removable media (AKA Tape) and pass it to a partner, who can (in turn) decrypt it. But, I wonder about IBM's true commitment. The JAVA-based Encryption Facility Client is an 'as-is, unwarranted product'! So, you are truly only safe on z/OS to z/OS media transfers. That's not what the announcement letter said! - -teD I’m an enthusiastic proselytiser of the universal panacea I believe in! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encryption & SMS
I waiting toi here back from IBM on the cost of : IBM DFSMSdss Encryption feature -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Dean Montevago Sent: Monday, March 13, 2006 8:42 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Encryption & SMS Hi, I received a note mentioning a vendor is developing an encryptrion product. They mentioned in the note: " The OPEN intercept will still need to check the SMS ACS to determine which encryption method to use." My question is what is the diffenece between an encryption routine for SMS -vs- non-SMS. Is this product specific or does it have to do with SMS itself ? TIA Dean Dean Montevago Sr. Systems Specialist Visiting Nurse Service of New York (212) 609 - 5596 [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encryption & SMS
Dean, I believe the product you are talking about is CA's new BrightStor Tape Encryption product, which is currently in Beta and will go GA next month (Osvaldo Ridner gave a presentation on it at Share last week as well). This new product will allow any tape file to be encrypted and decrypted as it is being accessed by any application. The encryption method used (if any) is based on specific values being put into the "descriptor field" of the SMS dataclass. Since any dataset (including non-SMS managed tape) can be assigned an SMS dataclass, we chose this. The file itself does not have to reside upon an SMS-managed tape, but an SMS dataclass with a specific keyword in the descriptor field does need to be assigned. This can be via ACS rules (for those sites that want to encrypt all tape datasets for example) or via JCL with the DATACLAS parameter (if you want to only encrypt very specific files). This encryption eliminates the need to copy a tape dataset from one tape to another to encrypt and to re-copy to decrypt. The encryption is performed as the tape is originally being created or read, by any application. Russell Witt CA-1 Level-2 Support Manager -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Dean Montevago Sent: Monday, March 13, 2006 7:42 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Encryption & SMS Hi, I received a note mentioning a vendor is developing an encryptrion product. They mentioned in the note: " The OPEN intercept will still need to check the SMS ACS to determine which encryption method to use." My question is what is the diffenece between an encryption routine for SMS -vs- non-SMS. Is this product specific or does it have to do with SMS itself ? TIA Dean Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Tape Encryption
In the IBM-MAIN archives (from about August or September, 2005) there should be a list of tape encryption products posted. (Search on "tape encryption" and it should be pretty easy to spot.) There were also some follow-up posts noting CA-BrightStor and OpenTech as additional vendors in that same category. I tried to include some commentary in those messages about general principles for tape encryption, so that might be helpful, too. There will be more products in 2006, so I might need to update the list again later this year. But 2005 was a very big year for tape encryption due to some urgent needs, particularly in the financial services industry. - - - - - Timothy F. Sipples Consulting Enterprise Software Architect, z9/zSeries IBM Japan, Ltd. E-Mail: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Encryption, compression, etc.
I'm looking for some solution for file exchange between z/OS and Windows/Linux platform. The only requirement is to encrypt the file (PS dataset) on z/OS side and decrypt it on distributed side and vice versa. Nice to have: - hash calculation - compression - exploitation of CPACF or CryptoExpress or zIIP hardware (to reduce cost of CPU) Any clues and suggestions including both home-grown (DIY) solutions and commercial products are welcome. -- Radoslaw Skorupka Lodz, Poland P.S. If one feels uncomfortable with "advertising" commercial products, please write to me directly. -- 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 authorised 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. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, e-mail: i...@brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2011 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.346.696 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
DFSMSrmm Tape encryption
Hi team, I mean, we are evaluating the way to encrypt the data saved into cartridges or tapes. Is there some way to activate the tape encryption with RMM? Is it a software or Hardware functionality? Which is the easiest way to start encrypting our tapes? Best regards, Enrique Montero. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encryption software?
This topic is getting bounced around here and on the RACF-L as well, yet responses are scarce and sporadic. We in the hinterlands are looking for experiences with any of the major encrypting products to help in selecting one, without being hounded by vendors. Our site has mentioned TKLM and it looks like a nightmare, plus it doesn't cover all our media. We have FDR, so FDRCRYPT is a possibility. We have CA products, OpenTech products, and MegaCryption looks interesting. Bottom line...many of us are soliciting opinions from those who have run that gauntlet already. TIA...rave mode set to off. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encryption software?
We use opentech, fdr, and megacrypt. We have icsf and MF encryption cards. All products that I mentioned are using the encryption cards for encrypting our tape backups. They have been working that for a few years now and we haven't had any issues. We use opentech for DR and have not had any issues testing. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Daniel McLaughlin Sent: Thursday, March 18, 2010 7:51 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Encryption software? This topic is getting bounced around here and on the RACF-L as well, yet responses are scarce and sporadic. We in the hinterlands are looking for experiences with any of the major encrypting products to help in selecting one, without being hounded by vendors. Our site has mentioned TKLM and it looks like a nightmare, plus it doesn't cover all our media. We have FDR, so FDRCRYPT is a possibility. We have CA products, OpenTech products, and MegaCryption looks interesting. Bottom line...many of us are soliciting opinions from those who have run that gauntlet already. TIA...rave mode set to off. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html == This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encryption software?
What is it that you want to encrypt? TKLM is IBMs recommended (cost) replacement for EKM (free). I believe that it is nothing more than a key manager and serves up keys to whatever hardware that requests them. In our environment our Java EKM serves up keys and utilizes RACF as the backend keystore. Our tape library, VTS and tape drives are configured to request keys from the EKM and encrypt the data accordingly. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Daniel McLaughlin Sent: Thursday, March 18, 2010 8:51 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Encryption software? This topic is getting bounced around here and on the RACF-L as well, yet responses are scarce and sporadic. We in the hinterlands are looking for experiences with any of the major encrypting products to help in selecting one, without being hounded by vendors. Our site has mentioned TKLM and it looks like a nightmare, plus it doesn't cover all our media. We have FDR, so FDRCRYPT is a possibility. We have CA products, OpenTech products, and MegaCryption looks interesting. Bottom line...many of us are soliciting opinions from those who have run that gauntlet already. TIA...rave mode set to off. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encryption software?
>This topic is getting bounced around here and on the RACF-L as well, yet >responses are scarce and sporadic. We in the hinterlands are looking for >experiences with any of the major encrypting products to help in selecting >one, without being hounded by vendors. Our site has mentioned TKLM and it >looks like a nightmare, plus it doesn't cover all our media. We have FDR, so >FDRCRYPT is a possibility. We have CA products, OpenTech products, and >MegaCryption looks interesting. >Bottom line...many of us are soliciting opinions from those who have run >that gauntlet already. Would have responded sooner except was out at SHARE in Seattle. A very, very, very beneficial trip. It was great. A consideration might be to ask if any product meets US Gov't FIPS 140-2 requirement. There was a strategic decision made by the FDR folks, not to pursue it back when. Back a few years ago I had a discussion with them about the need for it. What happened was they partnered with the MegaCryption folks to offer their product for encryption in the places where it was mandated. IBM stresses the use of the TS encrypting cartridge drives for their offering. Sure this is good but encryption is needed for more than dumps. My contention is every file one sends out for Data Exchanges should be encrypted just in case their is PII (Personally Identifiable Information - used to be Privacy Data). OK, that means who gets your encrypted file needs to have your encryption product to decrypted. IBM markets the software IBM Encryption Facility (EF) which has its own format but also it supports OpenPGP along with GPG as we learned. They also have a free JAVA Client to give out in case the exchange partner does not have OpenPGP or GPG. It is my understanding MegaCryption also has the same kind of offering. Thus even if you have them snazzy encrypting cartridge drives it does not lessen the need for some file encryption software. Just as some food for thought. Say today you FTP a file from your z10 z/OS to a Windows platform. Hey it arrives in ASCII ready to process. OK, encrypt your EBCIDIC file and send it to them as BINARY file, they decrypt the file and look at the data as hosed. In their world, so what is a Codepage Been doing it now for 4+ years and there are other subtle challenges and obstacles. It is not as simple as it looks as my technical team found out the hard way. If anyone wants to carry on a dialog offline, contact me. Setting up Data Exchanges where all are sent encrypted and received encrypted have many implications; like key management, platform types, codepages, data exchange hubs, etc. jim -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encryption software?
I am beginning to think that the silence of major players is meaningful. I can report one horror story: pay close attention to your key manangment process. The whole process to include entry, change, and propagation to a recovery site. That whole sand box looks to be very fragile by design. And, without keys, the data is unrecoverable. I'm really worried that there are a lot of worthless backups out there that won't be discovered until it is way too late. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Daniel McLaughlin Sent: Thursday, March 18, 2010 7:51 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Encryption software? This topic is getting bounced around here and on the RACF-L as well, yet responses are scarce and sporadic. We in the hinterlands are looking for experiences with any of the major encrypting products to help in selecting one, without being hounded by vendors. Our site has mentioned TKLM and it looks like a nightmare, plus it doesn't cover all our media. We have FDR, so FDRCRYPT is a possibility. We have CA products, OpenTech products, and MegaCryption looks interesting. Bottom line...many of us are soliciting opinions from those who have run that gauntlet already. TIA...rave mode set to off. NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encryption software?
Hal Merritt wrote: >I am beginning to think that the silence of major players is meaningful. >I can report one horror story: pay close attention to your key manangment >process. The whole process to include entry, change, and propagation to a >recovery site. That whole sand box looks to be very fragile by design. And, >without keys, the data is unrecoverable. >I'm really worried that there are a lot of worthless backups out there that >won't be discovered until it is way too late. Indeed. "Encryption is easy, key management is hard". That's why the Voltage solutions all use keynames (identities) defined *by the user* (they look like email addresses, and actually are for Voltage SecureMail, but need not be for Voltage SecureData). Keys are generated based on a Master Secret and that identity *on the fly*. Thus keys need not be backed up, and key servers replicated with the same Master Secret will generate the same key for the same identity. Our customers love this flexibility: no constant key server backups, easy failover and geographic replication, and applications can share keys by using the same identity, without having to pass keys themselves around. ...phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encryption software?
I'm not trying to be a jerk here, but does this mean that all someone needs is your product and knowledge of the id used, in order to generate the key(s) to decrypt data encrypted with that id??? I am probably missing something here, but it sounds like there is something intrinsically wrong with that premise. All the best, Scott T. Harder Mainframe Services, Inc. Naples, FL > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Phil Smith III > Sent: Tuesday, March 23, 2010 12:01 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: Encryption software? > > Hal Merritt wrote: > >I am beginning to think that the silence of major players is meaningful. > > >I can report one horror story: pay close attention to your key manangment > process. The whole process to include entry, change, and propagation to a > recovery site. That whole sand box looks to be very fragile by design. > And, without keys, the data is unrecoverable. > > >I'm really worried that there are a lot of worthless backups out there > that won't be discovered until it is way too late. > > Indeed. "Encryption is easy, key management is hard". That's why the > Voltage solutions all use keynames (identities) defined *by the user* > (they look like email addresses, and actually are for Voltage SecureMail, > but need not be for Voltage SecureData). Keys are generated based on a > Master Secret and that identity *on the fly*. Thus keys need not be backed > up, and key servers replicated with the same Master Secret will generate > the same key for the same identity. > > Our customers love this flexibility: no constant key server backups, easy > failover and geographic replication, and applications can share keys by > using the same identity, without having to pass keys themselves around. > > ...phsiii > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encryption software?
We heard via the rumor mill a last summer that EKM support is going away and that we will have to migrate to TKLM or a competitive product in the future. The spectre of this occurring quickly was raised and then dismissed by our IBM team. We are among customers who use EKM for backend tape encryption and are not keen on moving to TKLM since EKM has been free with z/OS and TKLM is priced, requires DB2, etc. My current understanding is that EKM will continue to be shipped with z/OS but I don't know for how long. I have not seen an IBM Statement of Direction or announcement yet that actually confirms that EKM will be withdrawn. http://www-03.ibm.com/systems/z/os/zos/zos_sods.html Like other customers I need sufficient lead time to budget when a free part is replaced with a non-free one even if the current part has some gaps in it's functionality. EKM is not as robust a key manger as IBM TKLM or CA-EKM but it's working today and free. We structure our DR process to insure we have the key data sets we need at DR to recover and resume operation. EKM is a little quirky but it works for now meeting our minimum requirements and it is free. Best Regards, Sam Knutson, GEICO System z HW/SW/Automation Team Leader mailto:sknut...@geico.com (office) 301.986.3574 (cell) 301.996.1318 "Think big, act bold, start simple, grow fast..." This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encryption software?
On 03/23/10 12:50, Knutson, Sam wrote: We heard via the rumor mill a last summer that EKM support is going away and that we will have to migrate to TKLM or a competitive product in the future. The spectre of this occurring quickly was raised and then dismissed by our IBM team. We are among customers who use EKM for backend tape encryption and are not keen on moving to TKLM since EKM has been free with z/OS and TKLM is priced, requires DB2, etc. My current understanding is that EKM will continue to be shipped with z/OS but I don't know for how long. I have not seen an IBM Statement of Direction or announcement yet that actually confirms that EKM will be withdrawn. http://www-03.ibm.com/systems/z/os/zos/zos_sods.html Like other customers I need sufficient lead time to budget when a free part is replaced with a non-free one even if the current part has some gaps in it's functionality. EKM is not as robust a key manger as IBM TKLM or CA-EKM but it's working today and free. We structure our DR process to insure we have the key data sets we need at DR to recover and resume operation. EKM is a little quirky but it works for now meeting our minimum requirements and it is free. Best Regards, Sam Knutson, GEICO System z HW/SW/Automation Team Leader mailto:sknut...@geico.com (office) 301.986.3574 (cell) 301.996.1318 "Think big, act bold, start simple, grow fast..." I'm in the same boat as Sam. We use EKM in our Tape Encryption process, which does have its quirks, but once it is configured it is pretty stable. I'd like to move to TKLM but since EKM is free its been a hard sell. -- Mark Jacobs Time Customer Service Tampa, FL Klein Bottle for rent -- inquire within. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encryption software?
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Knutson, Sam Sent: Tuesday, March 23, 2010 11:50 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Encryption software? We heard via the rumor mill a last summer that EKM support is going away and that we will have to migrate to TKLM or a competitive product in the future. The spectre of this occurring quickly was raised and then dismissed by our IBM team. We are among customers who use EKM for backend tape encryption and are not keen on moving to TKLM since EKM has been free with z/OS and TKLM is priced, requires DB2, etc. We structure our DR process to insure we have the key data sets we need at DR to recover and resume operation. Maybe a few of us are missing something here. If you go to a D/R site to test, your stand alone system start-up on tape can't be encrypted or you can't install that system, right? So, once the system is installed, you have specifically not backed up your certificate file/database so that the rest of the tapes are un-usable. Is that also correct? Now you need a way to get that information into your system, using some special knowledge (such as the password, or key code) that allows this repository to be installed making your cert file/database available. Is this also correct? I'm asking, because the product I work on only does encryption for data in flight. Data encrypted on DASD or tape is another animal entirely. Hence the silence from here. So wouldn't encrypted 'data at rest' be a "DFSMS" issue (or some third party that is somehow invoked to do this)? Which would be handled by the file / database situation to which I referred above. Now, because of export laws (being that encryption things are munitions as far as the US Gov't is concerned), as I understand the rules, we can't talk about particulars publicly. Which may also be another reason for the silence. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those held by poster's employer -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encryption software?
Same here. Having a hard time swallowing a license fee for something that was/is free today. Don't want to put words into IBM's mouth, but since we had to pay for the encryption feature on the tape drives, and are now locked into it(lots of physical tapes encrypted), to start charging to supply those keys to new tapes doesn't seem quite right, since we are now locked in. _ Dave Jousma Assistant Vice President, Mainframe Services david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB1G p 616.653.8429 f 616.653.8497 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Jacobs Sent: Tuesday, March 23, 2010 12:57 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Encryption software? On 03/23/10 12:50, Knutson, Sam wrote: > We heard via the rumor mill a last summer that EKM support is going away > and that we will have to migrate to TKLM or a competitive product in the > future. > The spectre of this occurring quickly was raised and then dismissed by > our IBM team. We are among customers who use EKM for backend tape > encryption and are not keen on moving to TKLM since EKM has been free > with z/OS and TKLM is priced, requires DB2, etc. > > My current understanding is that EKM will continue to be shipped with > z/OS but I don't know for how long. > > I have not seen an IBM Statement of Direction or announcement yet that > actually confirms that EKM will be withdrawn. > > http://www-03.ibm.com/systems/z/os/zos/zos_sods.html > > Like other customers I need sufficient lead time to budget when a free > part is replaced with a non-free one even if the current part has some > gaps in it's functionality. EKM is not as robust a key manger as IBM > TKLM or CA-EKM but it's working today and free. > > We structure our DR process to insure we have the key data sets we need > at DR to recover and resume operation. > > EKM is a little quirky but it works for now meeting our minimum > requirements and it is free. > > > This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encryption software?
On 03/23/10 13:14, Jousma, David wrote: Same here. Having a hard time swallowing a license fee for something that was/is free today. Don't want to put words into IBM's mouth, but since we had to pay for the encryption feature on the tape drives, and are now locked into it(lots of physical tapes encrypted), to start charging to supply those keys to new tapes doesn't seem quite right, since we are now locked in. _ Dave Jousma Assistant Vice President, Mainframe Services david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB1G p 616.653.8429 f 616.653.8497 From what I remember TKLM was primarily designed for IBM's encrypting DASD product. Since it can serve keys to tape drives as easily as it can to DASD, IBM started pushing the migration off of free EKM to the new priced product. I can't speak for IBM but it would be nice if they allowed users of their tape encrypting solution to use TKLM for free as a drop in replacement for EKM, while keeping their pricing structure for users of their encrypting DASD product. -- Mark Jacobs Time Customer Service Tampa, FL Klein Bottle for rent -- inquire within. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encryption software?
We run EKM on three LPARs and a geographically distant AIX box. At our annual D/R test, we establish a secure network link from the floor restoration system's E05's to the AIX box to do the initial system restores. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Thompson, Steve Sent: Tuesday, March 23, 2010 1:11 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Encryption software? -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Knutson, Sam Sent: Tuesday, March 23, 2010 11:50 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Encryption software? We heard via the rumor mill a last summer that EKM support is going away and that we will have to migrate to TKLM or a competitive product in the future. The spectre of this occurring quickly was raised and then dismissed by our IBM team. We are among customers who use EKM for backend tape encryption and are not keen on moving to TKLM since EKM has been free with z/OS and TKLM is priced, requires DB2, etc. We structure our DR process to insure we have the key data sets we need at DR to recover and resume operation. Maybe a few of us are missing something here. If you go to a D/R site to test, your stand alone system start-up on tape can't be encrypted or you can't install that system, right? So, once the system is installed, you have specifically not backed up your certificate file/database so that the rest of the tapes are un-usable. Is that also correct? Now you need a way to get that information into your system, using some special knowledge (such as the password, or key code) that allows this repository to be installed making your cert file/database available. Is this also correct? I'm asking, because the product I work on only does encryption for data in flight. Data encrypted on DASD or tape is another animal entirely. Hence the silence from here. So wouldn't encrypted 'data at rest' be a "DFSMS" issue (or some third party that is somehow invoked to do this)? Which would be handled by the file / database situation to which I referred above. Now, because of export laws (being that encryption things are munitions as far as the US Gov't is concerned), as I understand the rules, we can't talk about particulars publicly. Which may also be another reason for the silence. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those held by poster's employer -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encryption software?
Scott T. Harder wrote: >I'm not trying to be a jerk here, but does this mean that all someone needs >is your product and knowledge of the id used, in order to generate the >key(s) to decrypt data encrypted with that id??? >I am probably missing something here, but it sounds like there is something >intrinsically wrong with that premise. You aren't being a jerk, you're asking a great question, because I failed to explain how key access is controlled. Any key server has some sort of authentication: ours ships with several (password-based, user/password, LDAP, Active Directory, etc.), and is built so it's trivial to add more -- based on phase of the moon or stock prices or whatever you can program. So no, knowing the identity used doesn't help a cracker break into Voltage SecureData, any more than knowing the key name helps with any other key management system. Knowing the identity and even the key generation algorithm wouldn't help you create keys on your own, either. Remember, there's root key material configured in the key server (as is something similar in all key servers, whether it's explicit or just entropy). This root key material is what needs to be backed up with Voltage SecureData: when you instantiate a key server, you create a one-time backup (or hopefully several copies of it!) and put THAT in your safe. Then you can ALWAYS recreate a key server and your keys, by firing up a hot/warm/cold spare and restoring that configuration. Hey presto, it can serve the keys you need. With most key servers you have to back up keys constantly -- which means those key backups are now a target. They also generate the key names with the keys, so the data flow is all from the key server to the application. And now there are TWO critical, dynamic pieces of data to back up: the key AND the key name. If you lose either, your data is gone. Most key servers pre-generate groups of keys, so they can do a backup before the keys are needed -- but the key name must still be matched to the data (and they better generate ENOUGH keys for a day's requirements, eh?). If the data store is DB2 or equivalent, that's not too bad: you add a column containing the key name used to encrypt a given row, and in a DR scenario, you restore your encrypted database and your key database and life goes on. It's a bit harder with most other datastores, as you have to store the key name somewhere. (Oh, and you DID take as much care backing up the key database as you do the data, right? And yo! u protected the key database somehow, presumably NOT storing it with the data backups? So you have two sets of daily data that must be kept separate: key and data backups. Hmm.) With Voltage SecureData, your daily backups are just as they were before encryption: data. Your key server-related backups (the configuration) are infrequent, and are thus easy to manage. These configurations (we call them "districts") are small and easy to back up, and the key server can support an essentially unlimited number of them (presumably limited only by disk space). To (perhaps) anticipate your follow-on question, the next nightmare of encryption is rolling keys. Rolling keys means changing keys periodically as required by many regulations (PCI et al). You can roll keys within a district, so most customers do not tend to have many separate districts, just generations of keys within a district. With Voltage SecureData, an identity can be "fully qualified", specifying more than just an email address, but it's all human-readable and thus easy to specify in an application. There are thus several ways to roll keys, depending on how your applications want to work. You can roll the identity -- payroll2...@company.com rolled to payroll2...@company.com; payr...@company.com#1255619218 rolled to payr...@company.com#13921939133 (that's a "serial number" in the district); varying the timestamp in the key (payr...@company.com:09072000Z rolled to payr...@company.com:10072001Z; or even changing the root key material. And of course combinations of these also work. Various of our customers have chosen different schemes based on their needs. We also offer what we called Embedded Format-Preserving Encryption, or EFPE. This violates the basic tenet of FPE by producing output that isn't quite the same format, but is the same length, by using a larger output alphabet than input. So a 9-digit SSN might encrypt as 13A4498B2 instead of all numeric. Now, in some cases, that's impossible due to storage schemes (SSN as 5-byte packed decimal, for example), but a surprising number of customers have embraced it because it makes key rollover trivial: the extra addressability offered by the extended alphabet allows storing a "key number" in the data. So if today your social encrypts to 13A4498B2, tomorrow
Re: Encryption software?
Phil, Thanks very much for the detailed explanation. Impressive. My interest is based on my involvement, not too long ago, with a commercial z/OS crypto product where I had been looking at creating a key server to be stored on z/OS (for all the usual and (I feel) proper reasons... RAS, etc.), providing the kind of unique and value-add management features such that you have described with your product; but also wanted to stay inside the lines with our crayon when it came to compatibility with existing key management methodologies (ICSF); and use those for all that is the best of the breed (no need to re-invent the wheel, right?). This, for both symmetric and asymmetric keys, as well. Not a simple project and mine never got off the ground (won't go into it); but I admire someone (an entire team, I'm sure) that was able to take this on and have some level of success. All the best, Scott T. harder Mainframe Services, Inc. Naples, FL > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Phil Smith III > Sent: Tuesday, March 23, 2010 11:50 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: Encryption software? > > Scott T. Harder wrote: > >I'm not trying to be a jerk here, but does this mean that all someone > needs > >is your product and knowledge of the id used, in order to generate the > >key(s) to decrypt data encrypted with that id??? > > >I am probably missing something here, but it sounds like there is > something > >intrinsically wrong with that premise. > > You aren't being a jerk, you're asking a great question, because I failed > to explain how key access is controlled. Any key server has some sort of > authentication: ours ships with several (password-based, user/password, > LDAP, Active Directory, etc.), and is built so it's trivial to add more -- > based on phase of the moon or stock prices or whatever you can program. So > no, knowing the identity used doesn't help a cracker break into Voltage > SecureData, any more than knowing the key name helps with any other key > management system. > > Knowing the identity and even the key generation algorithm wouldn't help > you create keys on your own, either. Remember, there's root key material > configured in the key server (as is something similar in all key servers, > whether it's explicit or just entropy). This root key material is what > needs to be backed up with Voltage SecureData: when you instantiate a key > server, you create a one-time backup (or hopefully several copies of it!) > and put THAT in your safe. Then you can ALWAYS recreate a key server and > your keys, by firing up a hot/warm/cold spare and restoring that > configuration. Hey presto, it can serve the keys you need. > > With most key servers you have to back up keys constantly -- which means > those key backups are now a target. They also generate the key names with > the keys, so the data flow is all from the key server to the application. > And now there are TWO critical, dynamic pieces of data to back up: the key > AND the key name. If you lose either, your data is gone. Most key servers > pre-generate groups of keys, so they can do a backup before the keys are > needed -- but the key name must still be matched to the data (and they > better generate ENOUGH keys for a day's requirements, eh?). If the data > store is DB2 or equivalent, that's not too bad: you add a column > containing the key name used to encrypt a given row, and in a DR scenario, > you restore your encrypted database and your key database and life goes > on. It's a bit harder with most other datastores, as you have to store the > key name somewhere. (Oh, and you DID take as much care backing up the key > database as you do the data, right? And yo! > u protected the key database somehow, presumably NOT storing it with the > data backups? So you have two sets of daily data that must be kept > separate: key and data backups. Hmm.) > > With Voltage SecureData, your daily backups are just as they were before > encryption: data. Your key server-related backups (the configuration) are > infrequent, and are thus easy to manage. These configurations (we call > them "districts") are small and easy to back up, and the key server can > support an essentially unlimited number of them (presumably limited only > by disk space). > > To (perhaps) anticipate your follow-on question, the next nightmare of > encryption is rolling keys. Rolling keys means changing keys periodically > as required by many regulations (PCI et al). You can roll keys within a > district, so most customers do not tend to have many separate districts, > just generations of keys within a distri
Re: Encryption software?
Scott T. Harder wrote: >My interest is based on my involvement, not too long ago, with a commercial >z/OS crypto product where I had been looking at creating a key server to be >stored on z/OS (for all the usual and (I feel) proper reasons... RAS, etc.), >providing the kind of unique and value-add management features such that you >have described with your product; but also wanted to stay inside the lines >with our crayon when it came to compatibility with existing key management >methodologies (ICSF); and use those for all that is the best of the breed >(no need to re-invent the wheel, right?). This, for both symmetric and >asymmetric keys, as well. Not a simple project and mine never got off the >ground (won't go into it); but I admire someone (an entire team, I'm sure) >that was able to take this on and have some level of success. Sounds like an interesting project, but, as (I hope) I've shown, a tough nut to crack. Voltage has been doing this for eight years, has over 800 customers, so I think we've pretty well got the entire shell removed :-) One more feature of Format-Preserving Encryption that I should have mentioned: since it's using the same character set, you can encrypt on z/OS and decrypt on an ASCII machine (and vice versa). That's another bugaboo of many encryption schemes: having to either decrypt before sending over the network, or change processes to send as binary so the data isn't destroyed by the EBCDIC-ASCII translation process. Cheers, -- ...phsiii Phil Smith III p...@voltage.com Voltage Security, Inc. www.voltage.com (703) 476-4511 (home office) (703) 568-6662 (cell) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTAM encryption
Munif, Session level encryption requires the crypto processor. Regards, Rob Schramm Sirius Computer Solutions -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Triple DES encryption
Is anyone aware of any callable services on z/os for Triple DES encryption without having any cryptographic hardware installed? I've tried the CSNBENC routine of ICSF, however, it returns with RC=12 indicating that it doesn't have the necessary hardware. Thanks from the bottom side of the planet, tom Sydney -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Triple DES encryption
Tom Rusnak wrote: > Is anyone aware of any callable services on z/os for Triple DES encryption > without having any cryptographic hardware installed? > I've tried the CSNBENC routine of ICSF, however, it returns with RC=12 > indicating that it doesn't have the necessary hardware. > Thanks from the bottom side of the planet, Yes, CPACF will do TDES. It will also do AES. You want to look at the KM and KMC instructions. Note that cryptographic functions available depend on the hardware level -- for example, z9 does not do AES-256. -- ...phsiii Phil Smith III p...@voltage.com Voltage Security, Inc. www.voltage.com (703) 476-4511 (home office) (703) 568-6662 (cell) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
TS3500 and encryption
I have a TS3500 that is to be setup as in library-managed and not system- managed for encryption. In the process I came across this statement in the EKM manual for setting up the encryption. Configure 3592 E05, E06, or EU6 tape drives for Encryption. a. If 3592 E05, E06, or EU6 tape drives are installed in an Enterprise System and connected to a 3592 C06 or J70, you must use system-managed encryption only. We have the 3592 E06 with the 3592 C06. This is the only place that I found this. Would it be true if the TS3500 is setup as Library-managed and you are running z/OS that you are not doing any tape encryption? If yes can I just have one or 2 drives System-managed using encryption? Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Encryption Software products
Hi everyone, One of our smaller clients, running on a Z9-BC, encryption requirements is for encryption of data at rest, encryption of tape data, support the OpenPGP format and usage of digital certificates. IBM's Encryption Facility for z/OS V1.2 has all of the required functionality but a crypto card is required to use digital certificates, making it a very expensive option. On to my question then. I'm looking for advice, experiences and recommendations of mainframe encryption software that will address the clients encryption requirements without any need for crypto hardware. Kind Regards, Meganen Naidoo Solutions Architect -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Data Encryption
Ward, Mike S wrote: Is anyone out there doing data encryption to tape? If so how hard is it to set up. We have a Z/os 1.4 system on a z800 series box with data encryption cards. I was wondering if we need anything else to do the data encryption. Way to check the archives, Bro! A comprehensive IBM-Main discussion on this topic started May 5 with this post: http://bama.ua.edu/cgi-bin/wa?A2=ind0505&L=ibm-main&P=38937 Unfortunately, the original poster (Dean Montevago) misspelled "Encrypting" as 'Encryting". So maybe you have an excuse for not finding it after all. :-) -- - | Edward E. Jaffe|| | Mgr, Research & Development| [EMAIL PROTECTED]| | Phoenix Software International | Tel: (310) 338-0400 x318 | | 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801| | Los Angeles, CA 90045 | http://www.phoenixsoftware.com | - -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Data Encryption
Thanks. Using I didn't know about the listserv utility at bama.ua.edu. It was great reading the thread using that utility. Now that I know about it, I'll use it more often. Thanks for pointing it out using the url... -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward E. Jaffe Sent: Thursday, May 19, 2005 5:21 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Data Encryption Ward, Mike S wrote: >Is anyone out there doing data encryption to tape? If so how hard is it >to set up. We have a Z/os 1.4 system on a z800 series box with data >encryption cards. I was wondering if we need anything else to do the >data encryption. > > Way to check the archives, Bro! A comprehensive IBM-Main discussion on this topic started May 5 with this post: http://bama.ua.edu/cgi-bin/wa?A2=ind0505&L=ibm-main&P=38937 Unfortunately, the original poster (Dean Montevago) misspelled "Encrypting" as 'Encryting". So maybe you have an excuse for not finding it after all. :-) -- - | Edward E. Jaffe|| | Mgr, Research & Development| [EMAIL PROTECTED]| | Phoenix Software International | Tel: (310) 338-0400 x318 | | 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801| | Los Angeles, CA 90045 | http://www.phoenixsoftware.com | - -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Data Encryption
Thanks for pointing that out Ed.. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Edward E. Jaffe Sent: Thursday, May 19, 2005 6:21 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Data Encryption Ward, Mike S wrote: >Is anyone out there doing data encryption to tape? If so how hard is it >to set up. We have a Z/os 1.4 system on a z800 series box with data >encryption cards. I was wondering if we need anything else to do the >data encryption. > > Way to check the archives, Bro! A comprehensive IBM-Main discussion on this topic started May 5 with this post: http://bama.ua.edu/cgi-bin/wa?A2=ind0505&L=ibm-main&P=38937 Unfortunately, the original poster (Dean Montevago) misspelled "Encrypting" as 'Encryting". So maybe you have an excuse for not finding it after all. :-) -- - | Edward E. Jaffe|| | Mgr, Research & Development| [EMAIL PROTECTED]| | Phoenix Software International | Tel: (310) 338-0400 x318 | | 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801| | Los Angeles, CA 90045 | http://www.phoenixsoftware.com | - -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TAPE Encryption
Lizette Koehler wrote: > When you run tape Encryption on a stacked tape do you encrypt all files that > are stacked on a tape or just one file on the stacked tape? > > For example, I have a batch backup job that places 35 dumped volumes on one > tape. I have looked at the doc and it seems I could place the encryption on > the first file only and the whole tape will be encrypted. > > Or does it not take any more time or resources to have encryption happen for > each volume on the stacked tape? > > I have been asked to place encrption on each file via Dataclas/ACS routines > on a stacked tape. I am just trying to get a handle of what the performance > trade offs are. > > Lizette > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > AFAIK, once a tape has been written in EEFMT2 format the entire tape is encrypted, In other words it isn't on a file by file basis. -- Mark Jacobs Time Customer Service Tampa, FL Delenn, I have been working up a good mad all day and I am NOT about to let you ruin it by agreeing with me! Captain John Sheridan - Babylon 5 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TAPE Encryption
Mark, I agree with your statement. My concern is that some want to set up the ACS code to be generic, IF (&DSN=PROD.**) Then DATACLAS=ENCRYPT. I want to update the JCL on just the first file to include the DATACLAS=ENCRYPT. So I am trying to figure it out the price of doing all the files individually on a stacked tape. Would iit slow down the process, and if it does, how can I calculate it? I know there is a some XX seconds it takes to do the encryption. If I have 35 files being encrypted on the tape, then I expect the answer should be 35 times XX seconds in delay of the job finishing. I am also told that if I use OPENTECH or COPYCAT to copy these stacked volumes to an offsite tape, then I do not need to encrypt the offsite tape as the files being copied are encrypted to start with. So the offsite tape becomes encrypted by default. Or did I get that wrong? Lizette > >Lizette Koehler wrote: >> When you run tape Encryption on a stacked tape do you encrypt all files that >> are stacked on a tape or just one file on the stacked tape? >> >> For example, I have a batch backup job that places 35 dumped volumes on one >> tape. I have looked at the doc and it seems I could place the encryption on >> the first file only and the whole tape will be encrypted. >> >> Or does it not take any more time or resources to have encryption happen for >> each volume on the stacked tape? >> >> I have been asked to place encrption on each file via Dataclas/ACS routines >> on a stacked tape. I am just trying to get a handle of what the performance >> trade offs are. >> >> >AFAIK, once a tape has been written in EEFMT2 format the entire tape is >encrypted, In other words it isn't on a file by file basis. > >-- > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TAPE Encryption
Lizette Koehler wrote: > Mark, > > I agree with your statement. My concern is that some want to set up the ACS > code to be generic, > > IF (&DSN=PROD.**) Then DATACLAS=ENCRYPT. > > I want to update the JCL on just the first file to include the > DATACLAS=ENCRYPT. > > So I am trying to figure it out the price of doing all the files individually > on a stacked tape. Would iit slow down the process, and if it does, how can > I calculate it? I know there is a some XX seconds it takes to do the > encryption. If I have 35 files being encrypted on the tape, then I expect > the answer should be 35 times XX seconds in delay of the job finishing. > > I am also told that if I use OPENTECH or COPYCAT to copy these stacked > volumes to an offsite tape, then I do not need to encrypt the offsite tape as > the files being copied are encrypted to start with. So the offsite tape > becomes encrypted by default. Or did I get that wrong? > > Lizette > > > > The delay when using encrypted tapes is the time spent communicating with the EKM when the tape is first mounted. There should be no additional overhead encrypting the entire tape once the initial handshaking is performed. During the tape copy process if the output tape is written in EEFMT2 then the data is encrypted, if not no. The tape drive returns to the copy program unencrypted data. Mark Jacobs >> Lizette Koehler wrote: >> >>> When you run tape Encryption on a stacked tape do you encrypt all files >>> that are stacked on a tape or just one file on the stacked tape? >>> >>> For example, I have a batch backup job that places 35 dumped volumes on one >>> tape. I have looked at the doc and it seems I could place the encryption >>> on the first file only and the whole tape will be encrypted. >>> >>> Or does it not take any more time or resources to have encryption happen >>> for each volume on the stacked tape? >>> >>> I have been asked to place encrption on each file via Dataclas/ACS routines >>> on a stacked tape. I am just trying to get a handle of what the >>> performance trade offs are. >>> >>> > > >>> >>> >> AFAIK, once a tape has been written in EEFMT2 format the entire tape is >> encrypted, In other words it isn't on a file by file basis. >> >> -- >> >> > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > -- Mark Jacobs Time Customer Service Tampa, FL Delenn, I have been working up a good mad all day and I am NOT about to let you ruin it by agreeing with me! Captain John Sheridan - Babylon 5 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TAPE Encryption
Lizette, To get a correct answer you need to provide details of what kind of encryption you are doing. Are you using encryption in the tape hardware (for example IBM TS1120 which are encryption enabled), or are you encrypting using s/w on the host system? Outboard encryption in the IBM tape hardware is complete volume and is almost no different performance than not encrypting. Using s/w - well that is a different story and would depen d on the s/w you are using. Mike Wood RMM Development On Tue, 14 Jul 2009 12:33:04 -0400, Lizette Koehler wrote: >When you run tape Encryption on a stacked tape do you encrypt all files that are stacked on a tape or just one file on the stacked tape? > >For example, I have a batch backup job that places 35 dumped volumes on one tape. I have looked at the doc and it seems I could place the encryption on the first file only and the whole tape will be encrypted. > >Or does it not take any more time or resources to have encryption happen for each volume on the stacked tape? > >I have been asked to place encrption on each file via Dataclas/ACS routines on a stacked tape. I am just trying to get a handle of what the performance trade offs are. > >Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TAPE Encryption
We are fairly basic. A TS3500 Library with TS1120 E05 drives. It is ficon attached. Lizette > > Lizette, To get a correct answer you need to provide details of what kind of > encryption you are doing. > Are you using encryption in the tape hardware (for example IBM TS1120 which > are encryption enabled), or are you encrypting using s/w on the host system? > > Outboard encryption in the IBM tape hardware is complete volume and is > almost no different performance than not encrypting. Using s/w - well that is > a different story and would depen d on the s/w you are using. > > Mike Wood RMM Development > > On Tue, 14 Jul 2009 12:33:04 -0400, Lizette Koehler > wrote: > > >When you run tape Encryption on a stacked tape do you encrypt all files > that are stacked on a tape or just one file on the stacked tape? > > > >For example, I have a batch backup job that places 35 dumped volumes on > one tape. I have looked at the doc and it seems I could place the encryption > on the first file only and the whole tape will be encrypted. > > > >Or does it not take any more time or resources to have encryption happen > for each volume on the stacked tape? > > > >I have been asked to place encrption on each file via Dataclas/ACS routines > on a stacked tape. I am just trying to get a handle of what the performance > trade offs are. > > > >Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TAPE Encryption
Lizette, Based on your other posts, I believe you are using the IBM TS1120/TS1130 encryption devices. In that case, as Mike Wood indicated, whatever file-1 is the rest of the tape will be the same. So, if file-1 is encrypted all the other files will be encrypted (no way to turn it off). Or, if file-1 is not encrypted; then no-encryption even if the dataclass asks for it to be encrypted. Of course, no such limitation exists with CA Tape Encryption ;) And, from everything I have heard there is very little clock-time delay when writing to one of these devices with encryption enabled. However, I have not been able to test their performance, so there might be some. And lastly, I believe you got the information on the OPENTECH or Copycat product incorrect. Whenever an encrypted tape is read on a TS1120/TS1130 device; if the key is available it will be decrypted. And if the key is not available it will not be read. In other words, there is no way to read the data in its encrypted form. So if you use any type of tape copy utility to copy from one tape to another; you will decrypt the data as you read it and the (hopefully) re-encrypt it as it is be written. Of course, if the ACS rules are based on DSN it will probably still be encrypted (unless you renamed the copy). But if your ACS rules are based on jobname and/or program-name; then it is very possible the copy will not be encrypted. Russell Witt CA 1 L2 Support Manager -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]on Behalf Of Lizette Koehler Sent: Tuesday, July 14, 2009 11:52 AM To: IBM-MAIN@bama.ua.edu Subject: Re: TAPE Encryption Mark, I agree with your statement. My concern is that some want to set up the ACS code to be generic, IF (&DSN=PROD.**) Then DATACLAS=ENCRYPT. I want to update the JCL on just the first file to include the DATACLAS=ENCRYPT. So I am trying to figure it out the price of doing all the files individually on a stacked tape. Would iit slow down the process, and if it does, how can I calculate it? I know there is a some XX seconds it takes to do the encryption. If I have 35 files being encrypted on the tape, then I expect the answer should be 35 times XX seconds in delay of the job finishing. I am also told that if I use OPENTECH or COPYCAT to copy these stacked volumes to an offsite tape, then I do not need to encrypt the offsite tape as the files being copied are encrypted to start with. So the offsite tape becomes encrypted by default. Or did I get that wrong? Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Mainframe tape encryption
Hi all, Anyone using mainframe tape encryption to selectively encrypt DSN's on tape volumes or entire volumes? Successes? Issues? Bob Robert B. Fake InfoSec, Inc. <http://infosecinc.com/PSU%20Form.html> (click here for info on the InfoSec PSU program!) 703-825-1202 (o) 571-241-5492 (c) 949-203-0406 (efax) <mailto:rf...@infosecinc.com> rf...@infosecinc.com Visit us at <http://www.infosecinc.com/> www.infosecinc.com Click here for the <http://www.facebook.com/pages/Centreville-VA/InfoSec-Inc/43693760902?ref=s> InfoSec, Inc. Face book page The information contained in this e-mail message may be proprietary and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Encryption software?
May I suggest you cross-post this over at RACF-L? You'll get some good information on the security-side of the implementation. Hope this helps. Many thanks. Doc Farmer Senior Security Specialist InfoSec, Inc. dfar...@infosecinc.com http://www.InfoSecInc.com http://www.linkedin.com/in/docfarmer -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of O'Brien, David W. (NIH/CIT) [C] Sent: Wednesday, January 21, 2009 10:34 To: IBM-MAIN@bama.ua.edu Subject: Encryption software? I would like to solicit opinions about Mainframe data encryption. What are you using? Ease of implementation and maintenance of keys? We currently use FDR to create our off-site DR volume backups. Is anyone using FDRCRYPT? FDRCRYPT would seem to be a natural extension for us. All thoughts and suggestions are welcome. Regards, Dave O'Brien -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Encryption performance issues?
I'm trying to find docs comparing the performance on a z9 of none vs software vs hardware support for encryption of Tn3270 connections. I've seen quite a bit of performance doc about functions that get offloaded to crypto coprocessors, but that is a trivial amount of work for long lasting connections like Tn3270. The steady-state encryption and hashing of SSL / TLS connections gets given to CPACF, and (as I understand it) that is synchronous processing - while the CP is doing CPACF stuff it is not doing "normal" processing. That tells me that encryption could make a significant impact on a heavily loaded processor - even with the encryption handled by CPACF. I've seen doc showing how CPACF throughput is effected on a single CP based on the size of data blocks being processed, but no comparison with throughput when no encryption was being done, or when the encryption/hashing was done in software. Has anybody seen such a report? Thanks. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Tape encryption solution
Take a look at http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/TD101250 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DFHSM Encryption
Encrypt the data when the files are first written . -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Staller, Allan Sent: Tuesday, August 02, 2005 12:45 PM To: IBM-MAIN@BAMA.UA.EDU Subject: DFHSM Encryption Is anyone aware of a method to encrypt DFHSM Backups, Dumps and ML2 data at time of creation? An after-the-fact copy of the data is not an acceptable option! I have RTFM'ed and can find no indication of DFHSM/ICSF (or any other) encryption support. THanks in advance, -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DFHSM Encryption
Encrypt the data when the files are first written That's the idea, but how? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DFHSM Encryption
I'm back from wherever . I meant encrypt the files from the application. HSM and DSS don't quite do the encryption yet, looks like they are close. And Innovation does it now. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Staller, Allan Sent: Tuesday, August 02, 2005 1:42 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: DFHSM Encryption Encrypt the data when the files are first written That's the idea, but how? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Resource cost of encryption
Hi, All, Have any of you implemented SSL over TCPIP (z/OS 1.5 or thereabouts) without using an ICSF, and obtained any measurements of the additional resources consumed by computing encryption on "standard" CPU engines? TIA, -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Clear key encryption
What do you mean with "None clear encryption"? Are you talking about ICSF? 2006/1/18, Ward, Mike S <[EMAIL PROTECTED]>: > > Hello all. I was wondering if anyone could explain to me what Clear Key > Encryption VS None clear Encryption is. I looked in the archives, but > only found a reference that clear key could run on the T-REX. I thought > that clear key encryption was purely SSL and the other was DES/3DES > where the 3des keys are encrypted by the master. The reason I am asking > is because we will be encrypting our data for offsite export. I don't > believe that ssl would be a good way to do it. > > Thanks in advance. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Clear key encryption
Sorry, I guess I meant secure key. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Víctor de la Fuente Sent: Wednesday, January 18, 2006 3:43 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Clear key encryption What do you mean with "None clear encryption"? Are you talking about ICSF? 2006/1/18, Ward, Mike S <[EMAIL PROTECTED]>: > > Hello all. I was wondering if anyone could explain to me what Clear Key > Encryption VS None clear Encryption is. I looked in the archives, but > only found a reference that clear key could run on the T-REX. I thought > that clear key encryption was purely SSL and the other was DES/3DES > where the 3des keys are encrypted by the master. The reason I am asking > is because we will be encrypting our data for offsite export. I don't > believe that ssl would be a good way to do it. > > Thanks in advance. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Clear key encryption
You are touching on the real issue of encryption: key management. Some suggest that encryption keys are more sensitive and valuable than the data they protect. And a lot harder to manage. AFAIK, 'clear key encryption' means that secret encryption keys flow over networks 'in the clear'. This can be a reasonable level of security for many shops. Compare to a hardware/software configuration where at no time does any secret encryption key flow over any network the open. That is, these secret keys are first themselves encrypted before flowing. Like the Trusted Key Entry feature of some flavors of Z processors. You can do a fair job of keeping your secret key secret by using TLS/SSL. But you still have all those nasty Windows issues to consider. Or perhaps you have some old coax 3270 devices. These are generally considered to be secure enough for many kinds of operational keys. Perhaps even your master key. HTH and good luck. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ward, Mike S Sent: Wednesday, January 18, 2006 2:30 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Clear key encryption Hello all. I was wondering if anyone could explain to me what Clear Key Encryption VS None clear Encryption is. I looked in the archives, but only found a reference that clear key could run on the T-REX. I thought that clear key encryption was purely SSL and the other was DES/3DES where the 3des keys are encrypted by the master. The reason I am asking is because we will be encrypting our data for offsite export. I don't believe that ssl would be a good way to do it. Thanks in advance. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
