SMF Digital Signatures in z/OS 2.
Senior Software Engineer at IBM
NY Metro NaSPA Meeting - October 28th 2015
Agenda
• What is a digital signature?
• How digital signatures enhance SMF data
• Configuration and Usage
3
What is a Asymmetric Cryptography
• Also known as Public-Key Cryptography
• Used for message encryption (i.e. to transmit a key for symmetric
encryption) or for message signatures
• Utilizes very large random numbers – Strength lies in the inability to
factor these very large numbers
• The term "asymmetric" comes from the use of different keys, a public
key and private key, to perform these opposite functions
4
What is a Digital Signature?
• A way to ensure the source and validity of data
• The signer will first hash the data and then encrypt the hash with
their private key – The encrypted hash is the signature
• The consumer of the data can hash the same data and decrypt the
signature, using the public key, to obtain the signer's hash
• The hashes will then be compared – When these values match then
the data contents and source are verified
5
Storing SMF Digital Signatures
• Digital Signatures are stored in SMF2 records
• Subtype 1 provides a grouped signatures
• Subtype 2 provides interval based signatures
• Data must be validated on interval boundaries
• New data included in these records includes counts of records
included, start and end times of the data included and the hashing
and signature methods
• SMF2 records today are generated by IFASMFDL and IFASMFDP and is
ignored by these utilities by default
6
Storing SMF Digital Signatures (cont)
• Looking at a data set dumped from a logstream the SMF Type 2
records will be integrated into the data
Record #1
Record #2
SMF Dump Data Set
SMF Type 2 Record
Record #3
7
When SMF Signs Records
• The SMF data is signed on the way to System Logger
• This function is only available when using SMF Logstream Recording!
• As each block of records is written to the logstream
• Each record is individually hashed
● Running hash maintained per unique SMF type/subtype
• Periodically, the hash will be encrypted and the digital signature data
will be recorded to the logstream as a group signature record
• On the global interval a signature is created for all data hashed since
the previous interval and recorded to the logstream as an interval
signature record
• These operations are performed with the private key
8
When SMF Moves Signature Records
• IFASMFDL and IFASMFDP understand signature records
• Both utilities can optionally carry them to an OUTDD data set with the
records of an associated SMF type/subtype
• OUTDD data sets can be independently verified
IFASMFDP or IFASMFDL SYSIN OUTDD1
OUTDD(OUTDD1,TYPE(23))
OUTDD(OUTDD2,TYPE(30))
OUTDD2
9
When SMF Verifies Records
• IFASMFDP can verify a set of SMF records has not been tampered with
when signature records are available.
• The Signature Records must have been carried through successive IFASMFDL and
IFASMFDP passes over the data
IFASMFDP Verification
INDD1
Report
10
Setup Steps
• The first step is create a public/private key pair via ICSF
• SMF does not care about the type of key (clear or secure) as long as the
available hardware can support it
• Scope of the key usage can be per enterprise, sysplex, system or
logstream
• SMF needs the token name to perform the PKCS#11 functions via
ICSF as well as the type of encryption – For example RSA or Elliptical
Curve
• The SMF address space and any invokers of IFASMFDP will need
access to ICSF, PKCS#11 and the appropriate key
• See SAF resources CRYPTOZ, CSFSERV and CSFKEYS
11
Setup Steps – cont.
• Update the SMF configuration to sign record
• New option RECSIGN can be specified globally or per
LSNAME
• The logstream must be defined with a MAXBUFSIZE of 65532
• Default is NORECSIGN
• Sub-options include HASH, TOKENNAME, SIGNATURE
RECSIGN(HASH(SHA512),SIGNATURE(RSA),
TOKENNAME(TAMPER#RESISTANT#SMF#TOKEN#NAME1))
• These options are dynamic however changing these options
requires some operational coordination
• Data can only be verified with a single set of parameters, new and old data must
be segregated
12
Setup Steps – IFASMFDL
• IFASMFDL can carry signature data with the SMF records
• By default IFASMFDL will drop signature records
• The NOSIGSTRIP option can be used to have signature records written to
OUTDD data sets
• IFASMFDL will carry signature records transparently
• If there are multiple OUTDD statements for different types and
subtypes IFASMFDL will carry the correct signature records to each
OUTDD
• When signature records are carried the IFASMFDL output reports a
TYPE2 record as written for each signature record
13
Setup Steps – IFASMFDP
• IFASMFDP can carry signature records and perform validation
• New IFASMFDP parameters NOSIGSTRIP and SIGVALIDATE
• NOSIGSTRIP behaves the same as with IFASMFDL
• SIGVALIDATE indicates that signature validation is to be performed,
Suboptions include TOKENNAME and HASH
SIGVALIDATE(HASH(SHA512),
TOKENNAME(TAMPER#RESISTANT#SMF#TOKEN#NAME1))
• Default: NOSIGVALIDATE (don't perform validation)
14
Setup Steps – IFASMFDP
• The relationship between PARMLIB member SMFPRMxx and the
IFASMFDP options
• The TOKENNAME and HASH values must match between SMFPRMxx
and IFASMFDP
• The TOKENNAME is associated with the public/private pair of keys
• IFASMFDP only needs to access the public key
SYS1.PARMLIB(SMFPRMxx)
LSNAME(IFASMF.xxx,TYPE(xx:yy),
RECSIGN(TOKENNAME(< 32 Char Token Name>),
SIGNATURE(yyyy),
HASH(xxx))
IFASMFDP SYSIN
SIGVALIDATE(TOKENNAME(<32 Char Token Name>),HASH(xxx))
15
IFASMFDP SIGVALIDATE Considerations
• The behavior for DATE, START and END are slightly different. Align
each with an interval to ensure complete intervals of records can be
validated.
• Records must retain the same order and contents as they where
originally written for signature verification to succeed
• IFASMFDP ends processing after the first failure is detected
16
Configuration Changes
• Encryption options can be changed dynamically
• This is not advised as it creates operational problems
• IFASMFDP needs to be told the encryption parameters and can not validate a
data set with a mix of parameters for a single SMF type/subtype from a given
SID
• If options must be changed create a new logstream with the new
options
• Temporarily run with both logstreams then turn off the old logstream
• Now there is a clean break between data signed with the old and new
parameters
17
Configuration Changes (cont)
• New SMFPRMxx setting RECSIGN with options HASH, TOKENNAME,
SIGNATURE apply at specific times
• Records written before the first global interval of IPL are signed immediately
• Records written before the first global interval of a logstream which has not
been previously been signing are signed immediately
• Records will not be signed until the global interval after a SET SMF or SETSMF
command is processed for logstreams which had previously been signing
18
IFASMFDP Record Validation Report
• Report line generated for each SMF type and subtype processed for each SID
seen
• Includes time span and counts for records that were verified
• Counts include records processed, groups processed and intervals processed
• A group is a subset of records that were signed together
• An interval is the signature generated on the SMF configured interval time
• Provides information about failures
• A signature failure is the highest level failure
• Additional checking is performed to see if the error could be due to a missing
or added record or an entire missing interval of records
• Manual examination will be required to determine the root-cause of the
error
19
Dissecting an IFASMFDP SIGVALIDATE Report
RECORD VALIDATION REPORT FOR SY1
RECORD RECORD VALIDATION VALIDATION START VALIDATION END RECORDS GROUPS INTERVALS
TYPE SUBTYPE FAILURE DATE-TIME DATE-TIME VALIDATED VALIDATED VALIDATED
128 * N 10/23/2014-11:00:00 10/23/2014-13:00:00 60 10 2
145 1 N 10/23/2014-11:00:00 10/23/2014-13:00:00 3 3 2
160 * N 10/23/2014-11:00:00 10/23/2014-13:00:00 10 2 2
VALIDATION SUCCEEDED
Time range that was validated, Count of records and intervals validated
11AM to 1PM, broken into two 60
minutes intervals
Indicates successful validation of this record type and subtype
When all data validates the report ends with this message. On a failure this would provide additional information
20
Validation Reports – When it fails
• The report will end with VALIDATION FAILED status
• Only a single error is reported per IFASMFDP run
• IFA742I reports details about the failure
21
Validation Reports – IFA742I Reasons
• CRYPTOGRAPHY FAILURE - ICSF RC/RSN=<rc>/<rsn>
• ICSF is inactive or other ICSF high level error
• Check Cryptographic Services ICSF Application Programmer's Guide
• INCONSISTENT RECORDS - RECORDS DO NOT MATCH EXPECTED COUNTS
• Potential inserted or deleted record
• INCONSISTENT RECORDS - RECORDS DO NOT MATCH EXPECTED TIMES
• Interval record does not have the correct time relative to previous
Interval record
• A record does not have a consistent time relative to other records in the
group
• INCONSISTENT RECORDS - FIRST FLAG DOES NOT MATCH
• Group records set a first flag for the first group in each interval
• Interval record set a first flag for the first interval written
• Altered, inserted or deleted signature data
22
Validation Reports – IFA742I Reasons (cont)
• RECORD AND SUPPLIED CRYPTO OPTIONS DO NOT MATCH
• When signature record contains different SIGVALIDATE options than
IFASMFDP parameter
• MISSING RECORDS - STARTING INTERVAL
• Started validation without initializing interval signature record and
failed
• Change your START time or possible deletion of records prior to
validating the first interval record
• MISSING RECORDS - ENDING INTERVAL
• When last interval record time does not match IFASMFDP ENDTIME
parameter
• Change END time or possible deletion of trailing records
• INCOMPLETE VALIDATION - ENDED WITH PARTIAL INTERVAL
• Outstanding records were not validated, missing an interval record
23
IFASMFDL and IFASMFDP Exits
• The IFASMFDL and IFASMFDP provide an exit interface to intercept
records that are processed
• This is the USER2 exit that can be specified on the SYSIN statement
• This exit will get control for signature records that will be written to the output
data set
• The SIGSTRIP option will cause these records to not be written but also will not
provide them to the USER2 exit
24
Toleration Support
• Without enabling the new options nothing changes
• Signatures can be turned on however validation processing is not
required – It is performed as needed
• At any point signatures can be stripped by IFASMFDL and IFASMFDP
to provide an output data set with NO signature records
• Coexistence APAR OA47012 will provide toleration support to accept
and ignore the new SMFPRMxx keywords on z/OS V1R13 and V2R1
systems
25
Appendix
• z/OS MVS System Management Facilities (SMF) – SA38-0667
• Z/OS MVS Initialization and Tuning Reference – SA32-0991
• z/OS Cryptographic Services ICSF Administrator's Guide - SA22-7521
26
Thank You!
10/27/2015 27
