• No results found

SECURITY QUESTIONS AND SOLUTIONS

In document PKZIP /SecureZIP for z/os (Page 154-160)

Access x.509 Public and Private Key Certificates

5 SECURITY QUESTIONS AND SOLUTIONS

This chapter contains answers to questions a system administrator is likely to have about integrating SecureZIPz into the operating environment.

Which encryption settings should be chosen?

Various external factors such as legislative requirements or corporate policy may influence your decision to select an algorithm or mode of encryption. However, when operating within those requirements, the following SecureZipz information may be of value.

 NIST has instructional information regarding password vs. certificate-based (PKI) encryption. In general, Certificate-based encryption is accepted to be more secure than Password-based encryption.

 Support is provided for a 56-bit key length for the DES encryption algorithm and for the older 96-bit “Standard” PKZIP for z/OS ENCRYPTION_METHOD, but key lengths for newer algorithms are supported at a minimum of 128 bits.

 PKWARE provides interoperability between z/OS, OS400, iSeries, UNIX and Windows for all algorithms provided with ENCRYPTION_METHOD with its product set at release 8.0 and above. This includes more advanced algorithms with minimum key lengths of 128 bits.

Older releases of PKZIP for z/OS products support “Standard” 96-bit encryption for wider cross-platform compatibility when required.

 When RECIPIENT PKI exchanges are required, then ENCRYPTION_METHOD must specify an algorithm other than STANDARD.

 Password-based AES encryption is supported by PKWARE products at release 5.5 or higher.

 BSAFE_AES and AES password-based encryption are 100% compatible, whether or not an IBM ICSF Hardware-based encryption facility is used. Archives created with PKZIP

for zSeries Release 5.5 can be bi-directionally exchanged with SecureZipz products

using the BSAFE AES algorithms.

 The highest level of performance may be achieved by selecting an algorithm that can be serviced by a hardware-based ENCRYPTION_FACILITY. The use of VERBOSE and SHOW_SETTINGS in a sample PKZIP run will report which facilities are available for

each algorithm. In addition, the utility PKCRYUTL (with sample JCL in INSTLIB) can be used to assess the relative performance of each on a specific system.

The IBM Cryptographic Facilities Integration feature of SecureZIP for z/OS enables the use of a system’s activated IBM Cryptographic Hardware feature through published ICSF APIs to achieve the best cryptographic service performance available for data encryption/decryption and digital signature processing.

How is encryption activated?

Encryption is activated through the use of the PASSWORD (and/or RECIPIENT for SecureZIP) commands. If a value is present for either setting, whether through explicit commands or default settings, then encryption will be attempted in accordance with other applicable settings (such as ENCRYPTION_METHOD).

However, if ENCRYPTION_METHOD=NONE is specified, then encryption will be bypassed. Note that certificate-based encryption for recipients is supported only by SecureZIP for

z/OS, not by PKZIP for z/OS. This mode of encryption requires that one of the strong

ENCRYPTION_METHODs (minimum 128-bit) be selected.

How is ICSF hardware acceleration activated?

SecureZIP only

ICSF hardware acceleration is discussed in chapter 7, on Cryptographic Facilities. The

SecureZIP FACILITY_ENCRYPTDATA, FACILITY_HASH and FACILITY_RANDOM settings permit the use of actively enabled ICSF APIs for IBMHARDWARE and IBMSOFTWARE.

What is the difference between an Encryption Method and an

algorithm?

An encryption algorithm is the fundamental component of a SecureZIP Encryption Method. The name of the algorithm (such as DES, 3DES, AES) is included in the Method name for ease of reference. However, the Method applies additional security mechanisms to the base

algorithm processing. One such mechanism is “Cipher Block Chaining” with random data that is unique for each file encryption process. The use of Cipher Block Chaining ensures that the resulting cipher text for two different ZIP runs of the same data and password will be

different.

How many recipients can be specified?

SecureZIP only

The ZIP file format specification allows for a maximum recipient-list size of 3,275. This size can be restricted further by other file attributes associated with the data, and by run-time capacity limitations (such as virtual storage). (Note: Approximately 20 bytes is required for each recipient within the ZIP archive central directory record for each file. This area is limited to 64K in size).

What virtual storage is required for certificate-based encryption?

SecureZIP only

When using recipient-based encryption, plan on an initial increase of 4MB of 31-bit storage for up to 15 recipients. LDAP will require an additional 1MB for every 27 recipients above 15. File- based and local certificate store will require an additional 1MB for every 41 recipients above 15.

How does ENCRYPTION_METHOD affect certificate-based encryption?

SecureZIP only

Public/private Key encryption using BSAFE(R) is used to digitally envelope the master session Key information. Once the master session Key is determined, an independent file session Key is derived (which is unique for each file) to encrypt the file data with a symmetric algorithm specified by ENCRYPTION_METHOD. Several encryption algorithms are supplied with

SecureZip. Any algorithm may be specified for use with PASSWORD. However, an encryption method other than “STANDARD” must be specified for use with RECIPIENTs.

How does SecureZIP activate MASTER_RECIPIENT contingency keys?

SecureZIP only

Note: Beginning with SecureZIP for z/OS 11.0, contingency keys through the use of

Security Server Key Rings is available as a replacement for MASTER_RECIPIENT to provide more advanced control of such keys. See the SecureZIP for z/OS Security Administrator’s

Guide for more information.

To meet corporate security policies, SecureZIP provides the ability to use the

MASTER_RECIPIENT setting to include one or more master recipient contingency key certificate files in a SecureZIP job when an ENCRYPTION_METHOD specification other than “STANDARD” is activated. The setting causes the data to be encrypted for the master recipient(s) in addition to other recipient or password settings, thereby ensuring that the organization can always decrypt its encrypted data.

The primary MASTER_RECIPIENT can be set directly in the defaults module, or indirectly by specifying MASTER_RECIPIENT in a command stream referenced by SECUREZIP_CONFIG. This default-module-only setting specifies a PDS[E] member that contains SecureZIP certificate

store configuration commands to be automatically included in the processing stream. The configuration command values from this member will be included at the start of command input processing prior to //SYSIN statements being read. The data set(member) will be converted into an "INCLUDE_CMD=(pds[e](member)" command internally and will be echoed to the message log in accordance with the ECHO setting. The primary MASTER_RECIPIENT will be reported in the SHOW_SETTINGS report.

Supplemental -MASTER_RECIPIENT commands may be provided via the primary SYSIN input stream, or indirectly from either the SECUREZIP_CONFIG or INCLUDE_CMD specifications. They will be internally converted to RECIPIENT commands for processing.

MASTER_RECIPIENT settings are cumulative. Therefore a setting in the defaults module cannot be overridden or eliminated from an execution.

How does MASTER_RECIPIENT affect activation?

When SecureZIP is being used to encrypt data, either with RECIPIENT or PASSWORD (unless ENCRYPTION_METHOD=STANDARD), a recipient specified by MASTER_RECIPIENT is

automatically included. However, a MASTER_RECIPIENT setting does not cause encryption to take place.

How do I copy a local certificate store?

Copying a Local Certificate Store:

1. Generate a set of backup/restore jobs - CS.1.8.3

- Generate both a Backup and Restore job 2. Run the backup

3. Copy the Restore job to another file, and edit.

- In the UNZIP step, insert an UNZIPPED_DSN command.. Example: -UNZIPPED_DSN(SECZIP.CWB.CS1,SECZIP.CWB.CS2)

- Mass change all HLQ’s in the IDCAMS step from the old HLQ to the new one… in this example, SECZIP.CWB.CS1 -> SECZIP.CWB.CS2. Be sure you don’t

accidentally

change the –ARCHIVE command in the UNZIP step 4. Run the modified Restore job

5. Call up the ZIP panels

6. Option C (config); press ENTER to get the second screen - Certificate Store Settings 7. On the DB Profile line, enter a / to edit the member

8. Once in the member, change all references to the old Cert Store to the new one.

9. Create a new member -- Command create newmem c99999 on the first line

10. Exit without saving the changed member under the old member name (CANCEL command and confirm no save).

How do I remove a local certificate store?

SecureZIP only

When a local certificate store is no longer required, the associated unused components may be deleted. However, be aware that distributed profiles may still reference these data sets. It is highly recommended that a backup of these components be made before deleting them. An IDCAMS DELETE may be done for:

hlq.CERTSTOR.DBX hlq.CERTSTOR.PRIVATE hlq.CERTSTOR.PUBLIC hlq.CERTSTOR.P7CA hlq.CERTSTOR.P7ROOT hlq.CERTSTOR.P7CRL

Note: The delete for the DBX cluster will automatically delete the alternate index and path components.

Scan PARMLIB and JCL libraries for configuration profile references to the deleted components. Perform cleanup as needed.

How can the contents of an x.509 certificate file be determined?

SecureZIP only

The PKSCNPRT member located under the INSTLIB dataset is designed to read and report on an end-entity X.509 certificate files. This job works with public key files in CER format (either DER or Base64 encoded), and private key files in PFX or P12 format (either DER or Base64 encoded). See the following sample job:

********************************* Top of Data *********************** //SCANCERT JOB (8900),PKWARE,MSGCLASS=H,

// CLASS=B,REGION=8M,NOTIFY=&SYSUID

// JCLLIB ORDER=PKWARE.MVS.INSTLIB <== VERIFY //JOBLIB DD DSN=PKWARE.MVS.LOAD,DISP=SHR <== VERIFY //***

//* BEFORE RUNNING THIS JOB, EDIT THE FOLLOWING ITEMS: //*

//* 1. TAILOR THE JOB CARD TO FIT YOUR INSTALLATION STANDARDS. //* 2. IF NECESSARY, CHANGE HIGH-LEVEL QUALIFIERS FOR THE LOAD //* LIBRARY AND FILES FROM "PKWARE.MVS" TO FIT THE PRODUCT //* INSTALLATION SUPPORT FILES ON YOUR SYSTEM.

//* 3. CHANGE THE SECOND PARAMETER OF THE %RMCRTPRT STATEMENT TO //* MATCH YOUR INSTALLED SECUREZIP LOAD LIBRARY.

//* 4. THE 3RD PARAMETER, IF PROVIDED IS THE PASSWORD OF THE P12/PFX //* PRIVATE-KEY CERTIFICATE FILE. "*" MAY BE USED TO

//* INDICATE THAT THE FILE IS FOR A PUBLIC-KEY CERTIFICATE FILE. //* NOTE: THE PASSWORD IS CASE-SENSITIVE AND MUST BE BRACKETED BY //* DOUBLE QUOTES. I.E. "your password goes here"

//***

//LISTCER EXEC PKISPF

//PKSCNPRT DD SYSOUT=* <= OUTPUT LIST //ISPF.SYSTSIN DD *

ISPSTART CMD(RMCRTPRT DD:SCANIN PKWARE.MVS.LOAD "PKWARE" //* ******************************** Bottom of Data *********************

The following is the resulting output of the job above, detailing the end-entity certificate information.

********************************* TOP OF DATA ************************** PKSCANCRT scan(0) file is: dd:SCANIN

PKSCANCRT Private Cert will be processed (6) PKSCANCRT --file #1 found (2106) dd:SCANIN Type=1 --- Certificate 1 --- PKWARE Test3 Subject: CN=PKWARE Test3 [email protected] Issuer: C=US S=Wisconsin L=Milwaukee O=PKWARE, Inc.

OU=PKWARE, Inc. -- for test and evaluation purposes only CN=PKWARE Test Intermediate Cert

[email protected] SerialNumber: 03 NotBefore: Mon Dec 20 09:06:09 2004 NotAfter: Fri Dec 13 09:06:09 2024 KeyUsage: E0 00

SHA-1 Hash of Certificate(Thumbprint):

7B 88 01 52 1B FF 0B B1 2E 42 32 40 03 75 05 0E 60 EE 52 97 Public Key Hash:

A7 C6 BB 45 BF 22 98 47 B7 3A FA 74 7C 00 37 8E 91 20 2C 31 End Entity RMCRTPRT - RMCRTPRT - Certificate Details RMCRTPRT - =================== RMCRTPRT - CN= RMCRTPRT - Email= RMCRTPRT - FN= RMCRTPRT - Issuer= RMCRTPRT - Valid Dates= RMCRTPRT - SerialNumber= RMCRTPRT - Usage= RMCRTPRT - Trust= RMCRTPRT - Revoke= RMCRTPRT - ******************************** BOTTOM OF DATA *************************

You may also report on an intermediate CA, trust root CA, and/or a CRL by selecting option 3 (“x.509 Certificate Utilities”) from the SecureZIP Certificate Store Administration panel. Here you will enter the certificate source file in question and select option 2 (“List

Certificates”). This option displays details about each certificate in the source file in a BROWSE window. From here you can determine the contents.

6

PKWARE PartnerLink: SecureZIP Partner

In document PKZIP /SecureZIP for z/os (Page 154-160)

Related documents