We've been doing ATTLS encrypted receive order's from IBM now for almost a year. I don’t know how anyone can tamper with that? As for connecting our mainframe systems to the "outside" world, we open a firewall connection as needed, and the connection to IBM can only be established FROM our systems. Cannot initiate the connection from the outside world coming in.
I feel pretty safe on both counts. _________________________________________________________________ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, May 20, 2015 10:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS Platform Software Products on ... Tape? On Mon, 11 May 2015 10:36:56 -0400, John Eells wrote: > >If you are still using tape for z/OS platform software delivery (that >is, any product that runs on z/OS, not just z/OS itself), I'd like to >hear from you to understand: > >- Why you choose tape for software delivery > Some customers are fearful of network delivery. I see two areas of concern: o Merely connecting one's core IS engine to the Internet opens an avenue for tampering. I have little to say on this. o The installation package itself may have been corrupted en route. In an SMP/E FROMNETWORK package a strong checksum of each component is compared to a value in GIMPAF.XML, and a checksum of GIMPAF.XML itself is compared to a value in the CLIENT data set. But how is the CLIENT data set itself transmitted? if it's via a channel comparable to that which carries the payload, then if Eve can counterfeit the latter she can as easily counterfeit the former. RECEIVE FROMNTS is worse. There is no CLIENT data set to carry the checksum. GIMPAF.XML has a suffix which contains a checksum of the preceding code, but this appears not to be verified: I can intentionally corrupt it and SMP/E reports no error. But verifying it would help little; it could be counterfeited as easily as any other part of the package. I discover, with some reverse engineering, that I can verify the checksum of GIMPAF.XML with the script: #! /bin/sh -x # Doc: Verify SHA-1 hash for GIMPAF.XML SMPCPATH=/usr/lpp/smp/classes # (Customize.) SMPJHOME=/usr/lpp/java/J6.0.1 # (Customize.) PATH=${PATH:+$PATH:}$SMPJHOME/bin export PATH echo "msgDigest file=\"GIMPAF.XML\" \ startDelim=\"<PKGDEF\" endDelim=\"</PKGDEF>\" terminate" | java -cp "$SMPCPATH" com.ibm.smp.GIMJVCLT exit # ############################ Could that checksum be transferred via an independent secure channel and be verified, even by visual inspection? -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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...@listserv.ua.edu with the message: INFO IBM-MAIN
