Re: Digitally signed product software packages from IBM

[Mark Jacobs]

Take a look at validated boot/IPL for z/OS on a z16. PTFs are just starting to 
come out.

Mark Jacobs 


Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com


--- Original Message ---
On Thursday, May 25th, 2023 at 7:34 PM, Andrew Rowley 
 wrote:


> On 26/05/2023 4:28 am, Kurt J. Quackenbush wrote:
> 
> > Glad to hear it works great and "management will love it." If you find 
> > value in this capability I encourage you to reach out to your other 
> > software providers and request they also start signing their packages. I 
> > know one in particular is already working on it, but not sure about the 
> > many others.
> 
> What about non-SMP/E delivered software?
> 
> What would be nice to see is a function where e.g. APF and linklist
> libraries at least were required to be signed. I know there was a
> discussion some time back on the difficulties with load modules due to
> reblocking etc.
> 
> However, we can also sign things on z/OS e.g. SMF data. So you could
> have a local signing key usable for functions like the binder and
> IEBCOPY, and under certain conditions e.g.
> - all input is signed
> - IEBCOPY etc. is APF authorized
> the reblocked module is signed with the local key, maintaining a chain
> of signatures that can be validated back to the original package.
> 
> Other components (panels etc.) would be much easier to validate a
> signature. So it would be nice to be able to look at everything and see
> that it is either unchanged from a vendor, or something modified locally.
> 
> --
> Andrew Rowley
> Black Hill Software
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Digitally signed product software packages from IBM

[Andrew Rowley]

On 26/05/2023 4:28 am, Kurt J. Quackenbush wrote:

Glad to hear it works great and "management will love it."  If you find value 
in this capability I encourage you to reach out to your other software providers and 
request they also start signing their packages.  I know one in particular is already 
working on it, but not sure about the many others.

What about non-SMP/E delivered software?

What would be nice to see is a function where e.g. APF and linklist 
libraries at least were required to be signed. I know there was a 
discussion some time back on the difficulties with load modules due to 
reblocking etc.


However, we can also sign things on z/OS e.g. SMF data. So you could 
have a local signing key usable for functions like the binder and 
IEBCOPY, and under certain conditions e.g.

- all input is signed
- IEBCOPY etc. is APF authorized
the reblocked module is signed with the local key, maintaining a chain 
of signatures that can be validated back to the original package.


Other components (panels etc.) would be much easier to validate a 
signature. So it would be nice to be able to look at everything and see 
that it is either unchanged from a vendor, or something modified locally.


--
Andrew Rowley
Black Hill Software

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

Re: Digitally signed product software packages from IBM

[Mark Jacobs]

I like the SAF checks for audit reasons as well as enforcement of corporate 
policies. If someone needs to receive something unsigned they can get temporary 
access to do so without needing to edit anything in their receive job.

Mark Jacobs 

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com


--- Original Message ---
On Thursday, May 25th, 2023 at 2:28 PM, Kurt J. Quackenbush  
wrote:


> > We just got it configured and tested with my standard throwaway ShopZ 
> > order, Device Support Facilities. It works great, I'm sure management will 
> > love it.
> 
> 
> Glad to hear it works great and "management will love it." If you find value 
> in this capability I encourage you to reach out to your other software 
> providers and request they also start signing their packages. I know one in 
> particular is already working on it, but not sure about the many others.
> 
> > 1) Is there anything on the radar to have SMP/e enforce package signature 
> > validation if the package is signed?
> > 2) Ditto to have the ability for SMP/e not receive unsigned 
> > packages/products?
> > 
> > Using GIM facility classes to manage it would work for me.
> 
> 
> Yes, something in this space is on our radar. Since you mention a rather 
> specific implementation direction, can you provide more feedback? 
> Specifically, do you prefer SMP/E options which can be set/enforced at an 
> administrator level, perhaps using a new SAF resource check as you suggested? 
> Or, are new options in the CLIENT XML, probably specified by each SMP/E user, 
> sufficient? Just looking for opinions (which this group of listeners are 
> never shy about sharing).
> 
> Kurt Quackenbush
> IBM | z/OS SMP/E and z/OSMF Software Management | ku...@us.ibm.com
> 
> Chuck Norris never uses CHECK when he applies PTFs.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Digitally signed product software packages from IBM

[Kurt J. Quackenbush]

> We just got it configured and tested with my standard throwaway ShopZ order, 
> Device Support Facilities. It works great, I'm sure management will love it.

Glad to hear it works great and "management will love it."  If you find value 
in this capability I encourage you to reach out to your other software 
providers and request they also start signing their packages.  I know one in 
particular is already working on it, but not sure about the many others.

> 1) Is there anything on the radar to have SMP/e enforce package signature 
> validation if the package is signed?
> 2) Ditto to have the ability for SMP/e not receive unsigned packages/products?
> 
> Using GIM facility classes to manage it would work for me.

Yes, something in this space is on our radar.  Since you mention a rather 
specific implementation direction, can you provide more feedback?  
Specifically, do you prefer SMP/E options which can be set/enforced at an 
administrator level, perhaps using a new SAF resource check as you suggested?  
Or, are new options in the CLIENT XML, probably specified by each SMP/E user, 
sufficient?  Just looking for opinions (which this group of listeners are never 
shy about sharing).
 
Kurt Quackenbush
IBM  |  z/OS SMP/E and z/OSMF Software Management  |  ku...@us.ibm.com

Chuck Norris never uses CHECK when he applies PTFs.

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

Re: Digitally signed product software packages from IBM

[Mark Jacobs]

We just got it configured and tested with my standard throwaway ShopZ order, 
Device Support Facilities. It works great, I'm sure management will love it.

Questions:

1) Is there anything on the radar to have SMP/e enforce package signature 
validation if the package is signed?
2) Ditto to have the ability for SMP/e not receive unsigned packages/products?

Using GIM facility classes to manage it would work for me.

Mark Jacobs 

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com


--- Original Message ---
On Tuesday, May 16th, 2023 at 4:30 PM, Charles Mills  wrote:


> > If the signature is stored alongside the GIMZIP they could simply alter 
> > both.
> 
> 
> Yep, they could, but they would have about a one in a zillion chance of doing 
> so successfully. You would need the private key of the signer to get it 
> right. The digital signature is a hash of the software, encrypted with the 
> signer's private key. The hash algorithms are such that it is nearly 
> impossible to change the software but keep the same hash, and with a 
> different hash you need to have that private key to be able to make a 
> signature that will decrypt with the relevant well-known public key.
> 
> > which you trust more, DigiCert or your RACF
> 
> 
> The trustworthiness of CAs is one of the weakest parts of PKI and TLS. 
> Nothing against DigiCert -- they are fine folks, and I am sure have a robust 
> security program -- but CA's have been hacked with malicious effect.
> 
> https://en.wikipedia.org/wiki/DigiNotar#Issuance_of_fraudulent_certificates
> 
> Charles
> 
> On Tue, 16 May 2023 13:31:39 -0500, Paul Gilmartin paulgboul...@aol.com wrote:
> 
> > On Tue, 16 May 2023 13:04:44 -0500, Charles Mills wrote:
> > 
> > > Correct me if I am wrong, but my impression is that signing the package 
> > > protects (among other things) against the scenario in which one of your 
> > > associates, who let us assume is a bad guy, makes a zap-type modification 
> > > to the package after you download it and before you install it, thereby 
> > > compromising the integrity of your z/OS. Obviously, security for the 
> > > download will not protect against that, but package signing will.
> > 
> > OK. Verifying the signature at the point of RECEIVE FROMNTS protects against
> > (fe)malefactors' compromising the GIMZIP between download and RECEIVE.
> > If the signature is stored alongside the GIMZIP they could simply alter 
> > both.
> > 
> > And the SMPPTS must be protected until APPLY/ACCEPT, and the Target and
> > DLIBs indefinitely.
> > 
> > Some of this depends on which you trust more, DigiCert or your RACF 
> > configuration.
> > SMPNTS is a zFS hierarchy. How vulnerable is that?
> > 
> > --
> > gil
> > 
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Digitally signed product software packages from IBM

[Marna WALLE]

Only fyi:  I mentioned my prior blog post, the signing mechanism and the 
technology used, with some helpful RACF commands to set up for verification:

https://www.marnasmusings.com/2023/04/can-i-have-your-autograph-please.html

-Marna WALLE
z/OS System Install and Upgrade
IBM Poughkeepsie

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

Re: Digitally signed product software packages from IBM

[Charles Mills]

>If the signature is stored alongside the GIMZIP they could simply alter both.

Yep, they could, but they would have about a one in a zillion chance of doing 
so successfully. You would need the private key of the signer to get it right. 
The digital signature is a hash of the software, encrypted with the signer's 
private key. The hash algorithms are such that it is nearly impossible to 
change the software but keep the same hash, and with a different hash you need 
to have that private key to be able to make a signature that will decrypt with 
the relevant well-known public key.

> which you trust more, DigiCert or your RACF

The trustworthiness of CAs is one of the weakest parts of PKI and TLS. Nothing 
against DigiCert -- they are fine folks, and I am sure have a robust security 
program -- but CA's *have* been hacked with malicious effect.

https://en.wikipedia.org/wiki/DigiNotar#Issuance_of_fraudulent_certificates 

Charles

On Tue, 16 May 2023 13:31:39 -0500, Paul Gilmartin  wrote:

>On Tue, 16 May 2023 13:04:44 -0500, Charles Mills wrote:
>
>>Correct me if I am wrong, but my impression is that signing the package 
>>protects (among other things) against the scenario in which one of your 
>>associates, who let us assume is a bad guy, makes a zap-type modification to 
>>the package after you download it and before you install it, thereby 
>>compromising the integrity of your z/OS. Obviously, security for the download 
>>will not protect against that, but package signing will.
>>
>OK.  Verifying the signature at the point of RECEIVE FROMNTS protects against
>(fe)malefactors' compromising the GIMZIP between download and RECEIVE.
>If the signature is stored alongside the GIMZIP they could simply alter both.
>
>And the SMPPTS must be protected until APPLY/ACCEPT, and  the Target and
>DLIBs indefinitely.
>
>Some of this depends on which you trust more, DigiCert or your RACF 
>configuration.
>SMPNTS is a zFS hierarchy.  How vulnerable is that?
>
>-- 
>gil
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Digitally signed product software packages from IBM

[Paul Gilmartin]

On Tue, 16 May 2023 13:04:44 -0500, Charles Mills wrote:

>Correct me if I am wrong, but my impression is that signing the package 
>protects (among other things) against the scenario in which one of your 
>associates, who let us assume is a bad guy, makes a zap-type modification to 
>the package after you download it and before you install it, thereby 
>compromising the integrity of your z/OS. Obviously, security for the download 
>will not protect against that, but package signing will.
>
OK.  Verifying the signature at the point of RECEIVE FROMNTS protects against
(fe)malefactors' compromising the GIMZIP between download and RECEIVE.
If the signature is stored alongside the GIMZIP they could simply alter both.

And the SMPPTS must be protected until APPLY/ACCEPT, and  the Target and
DLIBs indefinitely.

Some of this depends on which you trust more, DigiCert or your RACF 
configuration.
SMPNTS is a zFS hierarchy.  How vulnerable is that?

-- 
gil

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

Re: Digitally signed product software packages from IBM

[Charles Mills]

Correct me if I am wrong, but my impression is that signing the package 
protects (among other things) against the scenario in which one of your 
associates, who let us assume is a bad guy, makes a zap-type modification to 
the package after you download it and before you install it, thereby 
compromising the integrity of your z/OS. Obviously, security for the download 
will not protect against that, but package signing will.

Charles 
On Tue, 16 May 2023 17:57:23 +, Kurt J. Quackenbush  
wrote:

>>> IBM packages for PTFs and HOLDDATA are currently not yet being signed, but 
>>> they will be later this year.  Stay tuned.
>>>
>> At e.g. , I 
>> see:
>> "Verified by DigiCert."  Is that adequate?
>
>Securing the download may very well be adequate for many.  Digitally signing 
>the actual files that are downloaded (the package) is an additional 
>protection.  Signing a GIMZIP package, and then verifying the signature of 
>that package, increases confidence in the authenticity (who produced it?) and 
>the integrity (has it changed in transit?) of the package.

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

Re: Digitally signed product software packages from IBM

[Kurt J. Quackenbush]

>> IBM packages for PTFs and HOLDDATA are currently not yet being signed, but 
>> they will be later this year.  Stay tuned.
>>
> At e.g. , I 
> see:
> "Verified by DigiCert."  Is that adequate?

Securing the download may very well be adequate for many.  Digitally signing 
the actual files that are downloaded (the package) is an additional protection. 
 Signing a GIMZIP package, and then verifying the signature of that package, 
increases confidence in the authenticity (who produced it?) and the integrity 
(has it changed in transit?) of the package.

Kurt Quackenbush
IBM  |  z/OS SMP/E and z/OSMF Software Management  |  ku...@us.ibm.com

Chuck Norris never uses CHECK when he applies PTFs.


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

Re: Digitally signed product software packages from IBM

[Kurt J. Quackenbush]

> Y'all should *also* sign bundled (in one file) packages with PGP and PKI, as 
> those are recognized standards which most customers have already in-hand.

GIMZIP package signing is implemented using public/private key technology (aka, 
PKI); a private key is used to generate a digital signature for package files, 
and the corresponding public key is used to verify the signatures. The key pair 
is associated with an X.509 certificate and SMP/E uses this certificate, and 
its associated key pair, for the signing and signature verification operations.

Kurt Quackenbush
IBM  |  z/OS SMP/E and z/OSMF Software Management

Chuck Norris never uses CHECK when he applies PTFs.


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

Re: Digitally signed product software packages from IBM

[Paul Gilmartin]

On Tue, 16 May 2023 15:38:36 +, Kurt J. Quackenbush wrote:

>... if you want to exploit the new capability and verify the digital 
> signatures check out the information here:
>https://www.ibm.com/docs/en/zos/2.5.0?topic=guide-preparing-verify-signatures-gimzip-packages
>
>You can also read Marna's latest blog on this topic here:  
>https://www.marnasmusings.com/2023/05/sign-of-times.html
>
>IBM packages for PTFs and HOLDDATA are currently not yet being signed, but 
>they will be later this year.  Stay tuned.
>
At e.g. , I see:
"Veriried by DigiCert."  Is that adequate?

Compare and contrast certificates and signatures.

-- 
gil

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

Re: Digitally signed product software packages from IBM

[Rick Troth]

This is great! Thanks!

I don't know anything about GIMZIP, but suspect it does its own thing. 
(And not clear from Marna's blog that it uses standards.) That's fine.


Y'all should *also* sign bundled (in one file) packages with PGP and 
PKI, as those are recognized standards which most customers have already 
in-hand.
Increasing numbers of software vendors are signing their downloadable 
wares with PGP. Others are using PKI. Two different trust models; 
neither is perfect. (So nothing wrong with also doing GIMZIP signing.)


-- Rick; <><


On 5/16/23 11:38, Kurt J. Quackenbush wrote:

As of today, all IBM product orders initiated from Shopz will be digitally 
signed using SMP/E's GIMZIP package signing capability.  This includes both 
Portable Software Instance (ServerPac) and CBPDO orders.  The signed packages 
are completely compatible with exiting acquisition and download processes, so 
no changes are required on the consumer's end, but if you want to exploit the 
new capability and verify the digital signatures check out the information here:
https://www.ibm.com/docs/en/zos/2.5.0?topic=guide-preparing-verify-signatures-gimzip-packages

You can also read Marna's latest blog on this topic here:  
https://www.marnasmusings.com/2023/05/sign-of-times.html

IBM packages for PTFs and HOLDDATA are currently not yet being signed, but they 
will be later this year.  Stay tuned.

Kurt Quackenbush
IBM  |  z/OS SMP/E and z/OSMF Software Management  |  
ku...@us.ibm.com

Chuck Norris never uses CHECK when he applies PTFs.




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


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