In today's world with more and more emphasis being placed on security, we know there has been the need to verify to a higher degree software that is being sent from a vendor to a client.
Common concerns that face enterprises are, how do we know for certain who produced that software we are running? And how do I know that the nothing happened in transit, from that vendor to me? Well, that is where a function we're calling Package Signing comes into play. Once the software vendor has signed the package that is being sent to the client, the client can then verify the signature and the contents of that file.

For z/OS packages, we need to understand how they are signed, and how to verify them once they are acquired. For that, we are relying on new functions in SMP/E and z/OSMF Software Management, which have been provided on all supported levels of z/OS. The PTFs for this support can be found with the SMP/E FIXCAT of  IBM.DrivingSystem-RequiredService.

First - what support is there today for verifying packages?
When creating software packages, vendors usually use the SMP/E GIMZIP utility. Customers then would use the SMP/E GIMUNZIP utility. Before the Package Signing support - and this is important - and continuing with the Package Signing support, the packages produced by GIMZIP will still contain a SHA-1 hash value for each file and for the package. If you wanted to continue to only use this existing (SHA-1 hash) support, no problem. Just keep doing what you are doing today with no changes.

Then - what is the new Package Signing support doing?
The new Package Signing support actually encompasses not only SMP/E's GIMZIP and GIMUNZIP, but it also includes support in z/OSMF Software Management. Let's look at the SMP/E support first.

When a software vendor signs the package using GIMZIP with the Package Signing support, a new and separate file will be produced (GIMPAF2.XML). This new and separate file will contain a SHA-256 hash for each file, and a SHA-256 with RSA signature for the package. Also included in this new file will be the path used for signing certificate used, which the client will use for signature verification. So, when using this new file, GIMPAF2.XML, a client can know for certain who  sent the package, and that the contents were not tampered.

What signing certificate will IBM use to sign our GIMZIP packages?
One you probably know, and which is delivered in RACF today: it is issued by the IBM z/OS Certificate Authority,  STG Code Signing Certificate Authority - G2. IBM will sign our software deliverables with an X.509 certificate, which means there is a key pair (private and public) associated with that certificate. GIMZIP will use the private key to sign; clients will use the public key to GIMUNZIP.

For other vendors that sign packages, check with them on which certificate to use.

How does my enterprise store the certificate to use for GIMUNZIP?
It really is quite simple, the client just needs to connect the IBM CA root certificate to a keyring, and store that keyring in your RACF (or other ESM) data base. This is a one time activity. Here's three command samples, for RACF:
> RACDCERT ID(mwalle) ADDRING(IBM.GIMZIP.Signature.Verification)

> RACDCERT ID(mwalle) CONNECT(LABEL('STG Code Signing CA - G2') RING(IBM.GIMZIP.Signature.Verification) USAGE(CERTAUTH) )

> RACDCERT ID(mwalle) LISTRING()   (because I always like to verify RACF)*

RACF work is done! What's next?
After you've got the keyring set up, you will indicate during package acquisition what keyring you would like to use for Package Verification.

Verification with z/OSMF Software Management, on an Add of a Portable Software Instance
This is very simple - just click on the screen you'd like to verify the incoming portable software instance, and what keyring to use. It could not be any easier. (Note: in this case, z/OSMF Software Management does not need you to also  put it on <CLIENT> . Sweet!)

Telling z/OSMF to verify the incoming portable software instance

Verification with a batch job for RECEIVE ORDER, RECEIVE FROMNET, or GIMGTPKG
Add the keyring name to your <CLIENT> information. Here's an example of what that could look like, with the one new line of signaturekeyring:

<CLIENT debug="YES"
javahome="/usr/lpp/java/J8.0/"
classpath="/usr/lpp/smp/classes/"
downloadmethod="https"
downloadkeyring="*AUTH*/*"
javadebugoptions="-Dcom.ibm.smp.debug=severe"
signaturekeyring="MWALLE/IBM.GIMZIP.Signature.Verification">

</CLIENT>

Is it ok to always specify signaturekeyring , even if the package is not signed? Yes.

Verification with a batch job for GIMUNZIP
If you wish to use GIMUNZIP directly from a batch job for a signed package, remember you sill need that <CLIENT> information as described above. But you'll need to also do one more thing: indicate to GIMUNZIP that you want to verify the signature. You do that with a PARM=, such as:

//STEP1 EXEC PGM=GIMUNZIP,PARM="VERIFYSIG=YES"
- - - - - - - - - - - - - - - - - - - - -
//SMPCLNT DD *
<CLIENT
javahome="/usr/lpp/java/J8.0"
signaturekeyring="MWALLE/IBM.GIMZIP.Signature.Verification"
>
</CLIENT>
/*

Finally - what packages will IBM sign, and when might I expect to see them?
IBM has announced intentions to sign the following software deliverables:
z/OSMF portable software instances (ServerPac), physical and electronic. Planned for the first rollout, for both z/OS V2.5 and 3.1 orders. [New news! Available on May 15, 2023!]
CBPDO, physical and electronic. Planned for the first rollout, for both z/OS V2.5 and 3.1 orders.   [New news! Available on May 15, 2023!]
SMP/E RECEIVE ORDER for PTFS and HOLDDATA, which are all electronic. Planned for a subsequent rollout.
Shopz electronic PTF orders (which I personally do NOT RECOMMEND) Planned for a subsequent rollout.
Keep an eye on IBM announcements for specific availability dates.

Marna's Musings

Search This Blog

Can I have your autograph please?

Comments

Post a Comment