Encryption Facility for z/OS V1.2 OpenPGP Support

To view this page ensure that Adobe Flash Player version 9.0.124 or greater is installed.

Please login or register to make a comment!

ibm.com /redbooks Encryption Facility for z/OS V1.2 OpenPGP Support Patrick Kappeler Saheem Granados Stanley Jon Benjamin Rogers Ken Rogers Richard Schultz Introduction to OpenPGP and review of cryptography concepts Expert guidance to achieve high security and high performance Detailed implementation procedures and practical usage scenarios Front cover Encryption Facility for z/OS V1.2 OpenPGP Support OpenPGP Support September 2007 International Technical Support Organization SG24-7434-00 © Copyright International Business Machines Corporation 2007. All rights reserved. Note to U.S.

Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. First Edition (September 2007) This edition applies to Version 1, Release 2, Modification 0 of IBM Encryption Facility for z/OS (product number 5655-P97). Note: Before using this information and the product it supports, read the information in cNotices d on page ix.

© Copyright IBM Corp. 2007. All rights reserved.

iii Contents Notices . . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

.ix Trademarks . . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . ... more. less.

. . . . . . . . . . . . . . . . . . . . . . . . . . x Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xi The team that wrote this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xi Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii Chapter 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 Why the Encryption Facility for z/OS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 Encryption Facility features/packaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 What is new with V1.2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.4 Considerations about data encryption. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.5 Miscellaneous information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Chapter 2. An introduction to OpenPGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.1 OpenPGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.1.1 Understanding OpenPGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2 OpenPGP messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3 OpenPGP versions and corresponding messages formats . . . . . . . . . . . 14 2.4 ASCII armor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.5 OpenPGP certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.5.1 A word on the X.509 standards. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.5.2 The OpenPGP certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.5.3 The OpenPGP keyring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.6 The OpenPGP Web of Trust concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.7 Considerations for OpenPGP implementation . . . . . . . . . . . . . . . . . . . . . 22 2.7.1 Hybrid X.509 and OpenPGP certificates and keys . . . . . . . . . . . . . . 22 2.7.2 OpenPGP concepts that are not implemented . . . . . . . . . . . . . . . . . 23 Chapter 3. Java and Java cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.1 Java infrastructure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.1.1 JZOS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.1.2 JRIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.1.3 Cryptographic facilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.2 Java cryptography. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.2.1 Java cryptographic APIs and services . . . . . . . . . . . . . . . . . . . . . . . 34 3.2.2 The IBM JCE providers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.2.3 Setting up the list of providers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 iv Encryption Facility for z/OS V1.2 OpenPGP Support 3.2.4 Jurisdiction policy files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.2.5 Keystores that can be used with the IBM JCE providers . . . . . . . . . 42 3.2.6 Managing keys in the keystores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Chapter 4. Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.1 Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.2 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.2.1 Hardware requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.2.2 OpenPGP support and hardware cryptography . . . . . . . . . . . . . . . . 56 4.2.3 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 4.2.4 Configuration setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.2.5 Exploitation of the z/OS integrated cryptography . . . . . . . . . . . . . . . 58 Chapter 5. Using the Encryption Facility for OpenPGP . . . . . . . . . . . . . . . 63 5.1 Encryption Facility for z/OS support of OpenPGP. . . . . . . . . . . . . . . . . . . 64 5.2 Overview of the OpenPGP support implementation . . . . . . . . . . . . . . . . . 65 5.2.1 Partner 9s preferred algorithms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.2.2 Sending OpenPGP protected data to multiple partners . . . . . . . . . . 66 5.3 Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.3.1 Symmetric algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 5.3.2 Asymmetric algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 5.3.3 Compression algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 5.3.4 Digital signature algorithms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 5.3.5 Message Digest algorithms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 5.4 Encryption Facility for OpenPGP performance considerations. . . . . . . . . 69 5.5 Encryption Facility for OpenPGP and digital certificates. . . . . . . . . . . . . . 70 5.5.1 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.5.2 Certificate management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 5.5.3 Generation of OpenPGP certificates - Subkeys . . . . . . . . . . . . . . . . 74 5.6 Invocation of Encryption Facility for OpenPGP. . . . . . . . . . . . . . . . . . . . . 75 5.6.1 Encryption Facility for OpenPGP commands . . . . . . . . . . . . . . . . . . 75 5.6.2 Encryption Facility for OpenPGP commands overview. . . . . . . . . . . 75 5.6.3 Encryption Facility for OpenPGP commands options. . . . . . . . . . . . 77 5.6.4 Options in the configuration file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 5.6.5 z/OS UNIX shell commands and scripts. . . . . . . . . . . . . . . . . . . . . . 77 5.6.6 JZOS and batch environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 5.6.7 Encrypting and decrypting z/OS data sets . . . . . . . . . . . . . . . . . . . . 80 5.7 Interoperability issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 5.7.1 Code page compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 5.7.2 Messages empty lines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Contents v Chapter 6. Session key protection: Passphrase-based encryption . . . . . 85 6.1 Choosing PBE or public key cryptography . . . . . . . . . . . . . . . . . . . . . . . . 86 6.2 PBE: z/OS-to-z/OS examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 6.2.1 Protecting a z/OS UNIX file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 6.2.2 Protecting a z/OS data sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 6.2.3 Invoking the Encryption Facility for OpenPGP with JCL. . . . . . . . . . 91 6.2.4 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 6.3 Protection-based Encryption with a non-z/OS client. . . . . . . . . . . . . . . . . 93 Chapter 7. Session key protection: Public key cryptography . . . . . . . . . . 99 7.1 Basic X.509 V3 certificate services in z/OS . . . . . . . . . . . . . . . . . . . . . . 100 7.1.1 Certificate services with RACDCERT . . . . . . . . . . . . . . . . . . . . . . . 100 7.1.2 Certificate services with ICSF panels (RSA keys only). . . . . . . . . . 101 7.1.3 Java keytool and hwkeytool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 7.2 OpenPGP certificates management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 7.3 Public key protection scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 7.3.1 z/OS to z/OS using RACF self-signed certificates . . . . . . . . . . . . . 105 7.3.2 Using key pairs in the ICSF PKDS . . . . . . . . . . . . . . . . . . . . . . . . . 114 7.3.3 ElGamal keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 7.3.4 Troubleshooting while running these scenarios . . . . . . . . . . . . . . . 127 7.4 Using public key protection with non-z/OS systems . . . . . . . . . . . . . . . . 129 7.4.1 Generation of an RSA key pair on z/OS . . . . . . . . . . . . . . . . . . . . . 130 7.4.2 Generation of an RSA key pair by the PGP desktop . . . . . . . . . . . 130 7.4.3 Exporting the RSA public key from z/OS to non-z/OS . . . . . . . . . . 132 7.4.4 Key preparation for exportation on the PGP system. . . . . . . . . . . . 132 7.4.5 Exchanging the OpenPGP certificates . . . . . . . . . . . . . . . . . . . . . . 134 7.4.6 Importing the partner 9s PGP certificate on z/OS. . . . . . . . . . . . . . . 134 7.4.7 Importing the partner 9s OpenPGP certificate on PGP Desktop. . . . 135 7.4.8 Exchanging an encrypted file: z/OS to non-z/OS . . . . . . . . . . . . . . 136 7.4.9 Exchanging an encrypted file: non-z/OS to z/OS . . . . . . . . . . . . . . 137 7.4.10 Decryption on the z/OS system. . . . . . . . . . . . . . . . . . . . . . . . . . . 138 7.4.11 Decryption on the PGP Desktop. . . . . . . . . . . . . . . . . . . . . . . . . . 139 Chapter 8. Certificate Authority: X.509 and OpenPGP coexistence . . . . 141 8.1 ITSO scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 8.2 Establishing CAs and personal certificates. . . . . . . . . . . . . . . . . . . . . . . 143 8.2.1 User 1 key materials and certificates creation . . . . . . . . . . . . . . . . 143 8.2.2 User2 key materials and certificates creation . . . . . . . . . . . . . . . . . 154 8.3 User1 sends user2 a signed message . . . . . . . . . . . . . . . . . . . . . . . . . . 160 8.3.1 User 2 sends user1 a signed message. . . . . . . . . . . . . . . . . . . . . . 161 8.3.2 User1 verifies the message. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 vi Encryption Facility for z/OS V1.2 OpenPGP Support Chapter 9. Sample code for an OpenPGP Certificate Server . . . . . . . . . 163 9.1 OpenPGP key authenticity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 9.2 OpenPGP key distribution and management . . . . . . . . . . . . . . . . . . . . . 165 9.3 Our scenario for using OpenPGP key server . . . . . . . . . . . . . . . . . . . . . 165 9.4 OpenPGP Public Key Server sample application design . . . . . . . . . . . . 167 9.4.1 User registries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 9.4.2 Thwarting identity theft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 9.5 Installing and configuring the IIPKS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 9.5.1 Load the LDAP schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 9.5.2 Install the EAR file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 9.5.3 Configure WebSphere Application Server . . . . . . . . . . . . . . . . . . . 176 9.5.4 Configure security and the user registries. . . . . . . . . . . . . . . . . . . . 181 9.5.5 Configuring user roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 9.5.6 Create pgppkiserver.properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 9.6 Using the IIPKS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 9.6.1 Search for an OpenPGP key. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 9.6.2 Submit an OpenPGP key to the key server . . . . . . . . . . . . . . . . . . 197 9.6.3 Add external user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 9.6.4 Using the Enable/Disable function . . . . . . . . . . . . . . . . . . . . . . . . . 200 9.7 Putting it all together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 Chapter 10. Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 10.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 10.1.1 IBM Java SDK 5 Runtime Environment for z/OS . . . . . . . . . . . . . 215 10.1.2 z/OS specialized hardware: zAAP and CPACF . . . . . . . . . . . . . . 216 10.1.3 Encryption Facility OpenPGP support. . . . . . . . . . . . . . . . . . . . . . 216 10.2 General CPU Service Units reduction using z/OS specialized hardware216 10.2.1 Hardware cryptographic acceleration . . . . . . . . . . . . . . . . . . . . . . 217 10.2.2 zAAP usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 10.2.3 Execution time reduction using parallel processing . . . . . . . . . . . 218 10.3 Putting it all together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 10.4 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Appendix A. Some encryption basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 What is encryption? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 Symmetric encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 Asymmetric encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 Contents vii What are the important characteristics of each method?. . . . . . . . . . . . . . . . 225 How are asymmetric encryption keys organized? . . . . . . . . . . . . . . . . . . . . . 225 What about large messages?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 Digital signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 Who to trust: The certificate authority . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 How can we use certificates? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 What it means to use cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 Appendix B. Configuration file options . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 Appendix C. OpenPGP key exchange and migration . . . . . . . . . . . . . . . 253 Exchanging OpenPGP certificates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 Exporting OpenPGP certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 Importing OpenPGP certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 Exchanging X.509 certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 Using keytool with X.509 certificates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 Using hwkeytool with X.509 Certificates. . . . . . . . . . . . . . . . . . . . . . . . . . 259 Considerations on certificate exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 Migrating key pairs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 Appendix D. Additional material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 Locating the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 Using the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 How to use the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 How to get IBM Redbooks publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 viii Encryption Facility for z/OS V1.2 OpenPGP Support © Copyright IBM Corp. 2007. All rights reserved. ix Notices This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785 U.S.A. The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrate programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. x Encryption Facility for z/OS V1.2 OpenPGP Support Trademarks The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both: Redbooks (logo) " OpenPGP eServer" z/Architecture® z/OS® zSeries® z9" DB2® DFSMS" DFSMSdss" DFSMShsm" IBM® IMS" MVS" Net.Commerce" OS/390® Redbooks® RACF® REXX" System z" System z9" Tivoli® WebSphere® The following terms are trademarks of other companies: Java, JDK, JNI, JRE, JVM, Sun, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. Linux is a trademark of Linus Torvalds in the United States, other countries, or both. OpenPGP and Pretty Good Privacy are trademarks of OpenPGP Corporation. Other company, product, or service names may be trademarks or service marks of others. © Copyright IBM Corp. 2007. All rights reserved. xi Preface This book is about the OpenPGP support available in the Encryption Facility for z/OS® V1.2 (Program Product 5655-P97). It begins with a discussion of the principles of operation of the OpenPGP protocol and a review of some basic cryptographic topics. It presents detailed steps for installing and configuring Encryption Facility for z/OS and implementing OpenPGP support. Practical examples from our lab and from the authors 9 real world experiences demonstrate how to set up and use the capabilities of OpenPGP support. The options available within the product are discussed, and recommendations for appropriate selections within the context of your intended use are offered. The team that wrote this book This book was produced by a team of specialists from around the world working at the International Technical Support Organization, Poughkeepsie Center. Patrick Kappeler has held many international positions, all dealing with mainframes hardware and software technical support and education, during his 36-year career in IBM®. He is now a lead consulting IT Specialist in the Montpellier European Product and Solutions Support Center (PSSC), and has specialized for the past 10 years on e-business security. Patrick provides advanced technical support and consulting on this topic worldwide along with extensive teaching and writing. He is also the co-author and leader of many other ITSO projects on z/OS Security and e-business. Saheem Granados is an Advisory software engineer who has worked for IBM for over 9 years. He is a Certified Information Systems Security Professional who throughout his career has been a designer and developer for critical z/OS security software, including: Net.Commerce" for OS/390®, Security Server LDAP Server, Tivoli® Federate Identity Manager, and Trusted Key Entry. As the development product owner of the Encryption Facility V1.2 OpenPGP support, Saheem designed the solution and led a team of developers to successful completion of all required development activities. Stanley Jon is an Advisory Remote Technical Support Specialist with IBM Canada. He has been with IBM and working on the System z" platform for ten years. He is part of the team supporting Canadian customers on z/OS defect xii Encryption Facility for z/OS V1.2 OpenPGP Support issues and North American customers for Q&A questions. He has supported ICSF since 1999 and System SSL since 2003. Benjamin Rogers is a Staff Software Engineer for IBM Systems & Technology Group, System z Lab Services organization. As a security services professional, he works with IBM customers to design and implement security solutions ranging from enterprise identity management to cryptographic solutions. Before joining Lab Services, Ben spent three years in the z/OS System Test organization architecting, implementing, and testing a security environment that exploited LDAP, RACF®, PKI, EIM, SSL, Kerberos, and ICSF. He spent the three years prior to joining the security team testing Java" on z/OS and Linux® for zSeries®, with a focus on Java security and test tool development. Ben holds a Bachelor 9s degree in Computational Mathematics from Michigan State University. Ken Rogers has more than 25 years systems programming experience in all IBM System z (and previous mainframe) operating systems. His areas of expertise include security and data protection. He has designed and implemented financial and manufacturing protection policies for a variety of customers. Working in almost every business sector, including financial, retail, manufacturing, extreme high technology, medical, and services industries, he has developed the externalist approach of problem solving to an uncommon level. Recently part of the Lab Services, Ken has designed and activated cost-effective, client-focused solutions to all types of problems. Richard Schultz has more than 28 years of experience in IBM, during which he has held several positions dealing with mainframe hardware and software technical support, with focus on performance measurement and analysis. For the past five years he has specialized on the performance evaluation of z/OS middleware cryptographic products. He provides advanced technical support on this topic within IBM and provides data on this topic to be published for customers worldwide. Thanks to the following people for their contributions to this project: Paola Bari, Robert Haimowitz, and Richard M. Conway International Technical Support Organization, Poughkeepsie Center John C. Dayka, Ravinder Gummadavelli, Bob St John, James W. Sweeny, and Wai Choi IBM STG Development, Poughkeepsie Thank to the PGP Corporation for their contribution and for the use of their material. Preface xiii Become a published author Join us for a two- to six-week residency program! Help write a book dealing with specific products or solutions, while getting hands-on experience with leading-edge technologies. You will have the opportunity to team with IBM technical professionals, Business Partners, and Clients. Your efforts will help increase product acceptance and customer satisfaction. As a bonus, you will develop a network of contacts in IBM development labs, and increase your productivity and marketability. Find out more about the residency program, browse the residency index, and apply online at: ibm.com /redbooks/residencies.html Comments welcome Your comments are important to us! We want our books to be as helpful as possible. Send us your comments about this book or other IBM Redbooks® publications in one of the following ways: Use the online Contact us review Redbooks form found at: ibm.com /redbooks Send your comments in an e-mail to: redbooks@us.ibm.com Mail your comments to: IBM Corporation, International Technical Support Organization Dept. HYTD Mail Station P099 2455 South Road Poughkeepsie, NY 12601-5400 xiv Encryption Facility for z/OS V1.2 OpenPGP Support © Copyright IBM Corp. 2007. All rights reserved. 1 Chapter 1. Introduction This chapter presents a summary of IBM Encryption Facility for z/OS V1.1 and introduces the IBM Encryption Facility for z/OS V1.2 new enhancements and features. This chapter also describes the environments in which the features execute, what functions they provide, and how the business needs that led IBM to market this product are met by the host-based Encryption Facility for z/OS. 1 2 Encryption Facility for z/OS V1.2 OpenPGP Support 1.1 Why the Encryption Facility for z/OS The Encryption Facility for z/OS processes data at rest and is intended for encryption of media whose contents must be securely transported: physically moved such as being shipped in a truck, for example, or electronically sent over non-secure links. The csecurity d of the movement here covers both network eavesdropping and unauthorized reading of physical media containing sensitive information. Consequences of such an unauthorized disclosure of information can be severe, as illustrated by many reported examples in which companies 9 finances and image were affected after losing track of physical media with sensitive contents that are known to be easily readable when one has access to the media itself. IBM Encryption Facility for z/OS exploits the existing strengths of the mainframe and the IBM z/OS operating system. It is a host-based facility that leverages existing centralized key management in z/OS and the hardware encryption capabilities of IBM mainframes. Encryption Facility can make use of ICSF to perform encryption and decryption and to manage cryptographic keys. To encrypt data files, Encryption Facility uses the following kinds of cryptographic keys: TDES triple-length keys 128 3bit AES keys Although the Encryption Facility for z/OS V1.1 implementation was based on a proprietary data format, the V1.2 release provides support for the OpenPGP Message Format standard as defined in RFC 2440. The OpenPGP standard was originally derived from PGP (Pretty Good Privacy). This support will meet the demand for standards-based solutions. While the functionality of Encryption Facility for z/OS V1.1 continues to be available, this book focuses on the OpenPGP portion of Encryption Facility V1.2. The Encryption Facility for z/OS V1.1 was described in Encryption Facility for z/OS Version 1.10 , SG24-7318. Chapter 1. Introduction 3 1.2 Encryption Facility features/packaging There are three components (or features) delivered under the generic name of cEncryption Facility for z/OS, d as shown in Figure 1-1. Figure 1-1 Encryption Facility V1.2 packaging Encryption Services feature This is an optional feature of the Encryption Facility for z/OS and supports both the cSystem z format d originally introduced in Encryption Facility for z/OS v1.1 and the OpenPGP format. Encryption Facility for OpenPGP provides encryption and decryption of messages and data files in accordance with the OpenPGP standards. This feature executes exclusively on z/OS (z/OS V1R6 and later) and exploits, whenever possible, the System z integrated hardware cryptography to encrypt and decrypt data files or data sets. The Encryption Services feature also provides ways to protect the key used to encrypt the data with a secret Note: RFC 2440 defines the set of data structures that an OpenPGP system must produce and consume. Encryption Facility for z/OS V1.2 will implement all of these data structures. IBM Encryption Facility for z/OS Java Client Feature: Encryption Services Feature: DFSMSdss Encryption Optional Priced Feature Licensed Program Product 5655-P97 Decryption Client Web download via click Entitled license OpenPGP support New with Release 2 Optional Priced Feature Encryption Facility for z/OS Client 4 Encryption Facility for z/OS V1.2 OpenPGP Support password or by using public key cryptography with the RSA algorithm and ElGamal for OpenPGP. The Encryption Services feature supports data in the following formats as input and output to the encryption and decryption process: 3 Physical sequential data sets as members of partitioned data sets (PDS) and partitioned data sets extended (PDSE) 3 Sequential data sets 3 z/OS UNIX® files (HFS or zFS) Additionally, it can also use the large block interface for output files written to tape in order to optimize both performance and media space. The Encryption Facility feature includes the following functions: 3 Batch programs CSDFILEN and CSDFILDE to respectively encrypt and decrypt z/OS data 3 Encryption Facility OpenPGP Support that supports the OpenPGP standard as described in the Internet Standard RFC 2440 Encryption Facility for z/OS Client This feature is a no-cost, Web deliverable, separately licensed program that provides two components in a single package that support encrypted data in cz format d only. 3 The Encryption Facility for z/OS Java Client is a Java Reference implementation. It is a Java technology-based code that enables client systems to decrypt and encrypt data files in an interoperable way with the other features of the Encryption Facility for z/OS, except for the OpenPGP support. As with the Encryption Services feature, the Java Client provides data encryption key protection through password or RSA public key cryptography. 3 The Decryption Client for z/OS is a native z/OS load module that can be installed and used for, as the name implies, decrypting files that were originally encrypted using the Encryption Services, except for data encrypted with the OpenPGP support. DFSMSdss" Encryption feature This feature enables encryption of DUMP data sets created by DFSMSdss and supports decryption during RESTORE. Note that DFSMShsm" exploits the encryption support provided by DFSMSdss in the DFSMShsm full-volume dump function and the associated restore functions, including both full-volume and data set-level restore. The Encryption Services and the DFSMSdss Encryption features are priced features of Program Product 5655-P97. Chapter 1. Introduction 5 You can download the Encryption Facility for z/OS Java Client from: http://www.ibm.com/servers/eserver/zseries/zos/downloads/#asis The Decryption Client for z/OS, as already mentioned, is also included in this download and is SMP/E installable. Optional data compression The Encryption Services, the DFSMSdss Encryption features, and the Decryption Client 4that is, all the System z cnative d programs 4can optionally compress data and, when not using the OpenPGP support, exploit the hardware-accelerated compression available on the System z platform. The OpenPGP support provides software-only compression. Limitations of the Java Client The Encryption Facility Java Client does not support data compression and decompression and does not natively support hardware crypto, nor does it support receiving data encrypted with a secure triple DES (T-DES) key. Figure 1-2 summarizes the possible exchanges between systems hosting the different features of the Encryption Facility for z/OS. Figure 1-2 Data exchanges with the Encryption Facility for z/OS Encrypted files optionall y c o mpresse d Encryption Services Encryption Facility for z/OS Client Encrypted files JAVA JAVA Encrypted files Encr y pted fi le s o p t io n al l y c ompressed Decryption Client z/OS z/OS z/OS z/OS Encryption Facility for z/OS Client Encryption optional compression DFSMSdss Encryption z/OS Encryption Services DFSMSdss Encryption Encryption optional compression OpenPGP Support z/OS Encryption Services Any OpenPGP compliant system Release 2 6 Encryption Facility for z/OS V1.2 OpenPGP Support 1.3 What is new with V1.2 Encryption Facility for z/OS V1.2 provides a new function compared to the previous version: it provides a secure and scalable OpenPGP client exploiting the existing security facilities of z/OS. This function is provided as part of the Encryption Facility Services feature and is implemented as a Java application that can be invoked in an interactive mode or via batch. In this book we are calling this function cEncryption Facility for OpenPGP d or cEncryption Facility OpenPGP support d interchangeably. Information about system pre-requisites is given in Chapter 4, cInstallation d on page 53. The OpenPGP Internet draft standard protocol defines a syntax for packaging data into packets, where each packet provides the context for a data integrity service like encryption or digital signature. Encryption Facility for OpenPGP implements all of the required services as described in the Internet draft standard protocol for OpenPGP and specifically provides the following services: Public key-based encryption of a session key Passphrase-based encryption (PBE) of a session key Modification detection of encrypted data Compression of data prior to encryption and decompression of data after decryption Importing and exporting of OpenPGP certificates in binary or cASCII armorized d formats Digital signatures of data The Encryption Facility for z/OS OpenPGP support is also able to make use of X.509 certificates provided in a public key infrastructure (PKI) environment, so that the basis of trust for OpenPGP environments can be complemented or extended. With Encryption Facility for OpenPGP, you can apply many of these services to the same data to form an OpenPGP message that you can exchange with other OpenPGP RFC2440-compatible applications. Encryption Facility for OpenPGP provides leverage of the existing security facilities of z/OS to provide a secure and scalable OpenPGP client. Chapter 1. Introduction 7 For example, the Encryption Facility OpenPGP support enables you to do the following: Use, as input or output, HFS/zFS files on USS or z/OS partitioned (PDS and PDSE) or sequential data sets Exploit the cryptographic acceleration provided by System z hardware Use the RACF database and the ICSF PKDS data set as key repositories 1.4 Considerations about data encryption In this section, we discuss general considerations about the use of data encryption and the consequences it might have on the relevant processes and organizations. Encryption and decryption of data Although the concept of secure data exchange using encryption and decryption is quite clear to people familiar with data processing technology, confusion arises as to where the process of encryption and decryption needs to occur: Encryption and decryption can be performed against data con the wire, d that is, be performed as part of the data transfer protocol. This is typically the case for TCP/IP communications when they are protected by the Secure Sockets Layer (SSL)/Transport Layer Security (TLS) or IP Security Architecture (IPSec) protocols. In this case, the encryption protocol operates on the data presented at the sending endpoint, and decryption occurs at the receiving endpoint, implying that data is cin clear d when not being handled by the transport protocol. Note that cin clear d can have a relative meaning here because an IPSec virtual private network (VPN) can transfer data already encrypted by other means, the point being that the VPN-specific encryption covers data only while it is con the wire, d meaning between the two endpoints of the VPN. Encryption and decryption is performed on data stored in a file or data set. In this situation there are still two cases to consider: 3 The data is calive, d meaning that it can be used at any time by an application and can therefore be rendered to its clear value on the fly in order to be processed and be re-encrypted when returned to the file or Note: For more information and details about OpenPGP support, refer to cUsing the Encryption Facility for OpenPGP d on page 63. 8 Encryption Facility for z/OS V1.2 OpenPGP Support data set. This is typically what happens with IBM Data Encryption for IMS" and DB2® Databases. 3 The data is put cat rest d before being encrypted. The data is explicitly made unavailable to applications and then goes through the encryption process. It has to go through a decryption process first before being made available again to applications. Compression and encryption Data compression involves a process where a data pattern is replaced by a binary number of a fixed length. At decompression time, the original data pattern is retrieved using the binary number. It takes two conditions for the compression process to be efficient: The decompression process must know which data patterns correspond to which binary numbers provided as a result of the compression. One of the most popular compression algorithms, the Ziv-Lempel algorithm, produces a so called ccompression dictionary d that provides this correspondence between the fixed length binary numbers (dictionary indexes) and the pattern for which they stand. The longer the data pattern the fixed length binary number represents, the better the compression ratio is. The compression algorithm works in such a way that the more repetitive a data pattern is, the higher the chance is to have it represented in its totality by a single binary number. In other words, input data repetitiveness is a mandatory condition to get efficient compression. Compression must occur before encryption. The result of the encryption process is as close as possible, by design, to random data, carefully hiding any repetitions that might occur in the clear source data. Therefore, encrypted data does not lend itself to efficient compression and might even, with the Ziv-Lempel algorithm, yield an inverted compression ratio (compressed data is bigger than the original uncompressed input 1 ). Important: The Encryption Facility for z/OS encrypts data cat rest d on DASD or tape medias. That is, the data is not intended to be used by applications until it is decrypted. Note also that the Encryption Facility for z/OS does not provide any electronic means of transport for the encrypted data. It is up to the installation to select and implement any required transport, be it a physical media movement or a purely electronic one. 1 Expansion of data occurs when the fixed length binary number replaces data shorter than the binary number itself. Chapter 1. Introduction 9 The Encryption Services and the DFSMSdss Encryption feature can optionally invoke System z hardware compression prior to encrypting the data. The System z platform uses the Ziv-Lempel algorithm with a static decompression dictionary that is then encrypted and stored along with the encrypted data. In compliance with OpenPGP standards that recommend compressing data for encryption, Encryption Facility for OpenPGP supports compression and decompression of OpenPGP messages and other data; however, there is no hardware assistance provided for OpenPGP compression and decompression of data. The Encryption Facility OpenPGP support proposes the zlib or zip algorithms to compress data. Both are widely known compression services libraries. 1.5 Miscellaneous information The z/OS bibliography of the Encryption facility for z/OS includes two books: Encryption Facility for z/OS: Planning and Customizing , SA23-2229 Encryption Facility for z/OS: Using Encryption Facility for OpenPGP , SA23-2230 Important: If you compress encrypted data, as occurs most of the time when you record data on a tape media, be prepared to see the volume of encrypted, then compressed, data on the tape exceed the volume of the same data when it is compressed only. Attention: We are referring in the rest of this book to the IBM RACF product as one possible certificates and keys repository. Other non-IBM products, which can replace RACF and are accessible through the z/OS SAF, may also provide this functionality. It is up to the reader to consult the product 9s vendor regarding whether this is actually the case. 10 Encryption Facility for z/OS V1.2 OpenPGP Support © Copyright IBM Corp. 2007. All rights reserved. 11 Chapter 2. An introduction to OpenPGP This chapter provides a high-level description of the security services and the data exchange messages formats as described in the OpenPGP standard. Whenever appropriate we highlight specific features of the OpenPGP implementation in the IBM Encryption Facility for z/OS V1.2, so that the reader can more precisely position this IBM offering with respect to the overall contents of the standard. 2 12 Encryption Facility for z/OS V1.2 OpenPGP Support 2.1 OpenPGP OpenPGP is a non-proprietary protocol for encrypting data in files or messages, which can then be recovered using public key cryptography or a secret passphrase. It is based on PGP (Pretty Good Privacy) protocol as originally developed by Phil Zimmermann and sold as a commercial product since 1991. The OpenPGP protocol defines standard formats for encrypted or signed data, digital signatures, and certificates that can be used to exchange public keys. The OpenPGP Working Group was formed in the Internet Engineering Task Force (IETF) in 1997 to define this standard. PGP, and later OpenPGP, have been very successful in becoming the widely spread standards for the encryption of e-mail and other sets of data that require protection, and emerge today as the leading standards for any requirements that pertain to data security and integrity with a heavy need for large scale interoperability. OpenPGP is an IETF proposed standard described in RFC 2440, which can be read at www.ietf.org/rfc/rfc2440.txt . The OpenPGP Alliance keeps working with member companies to promote the position of OpenPGP as the universal encryption standard and to model the Public Key Infrastructure (PKI) concepts that are emerging from the OpenPGP community. 2.1.1 Understanding OpenPGP The goal of OpenPGP is to enable trusted partners to exchange data with confidentiality and integrity. This relies on the use of symmetric and asymmetric encryption algorithms that provide the required service and are also used to establish a mutual trust between exchanging partners. Readers who are not familiar (or who were once familiar) with these algorithms are invited to read the refresher in Appendix A, cSome encryption basics d on page 223. The way trust is established between partners is discussed later. Session key OpenPGP uses symmetric encryption when requested to encrypt data. In OpenPGP terminology, the data encryption key is termed a csession key. d The Encryption Facility for OpenPGP encrypts data using a randomly generated session key and a symmetric encryption algorithm (such as TDES or AES). The session key is then itself protected by encryption and inserted next to the data in the resulting output file or message. Chapter 2. An introduction to OpenPGP 13 It is up to the receiving application to decrypt the session key and then use it to recover the clear data. The mechanisms that can be used to protect the session key are discussed in the following sections. Session key exchange using public key cryptography To protect the session key using public key cryptography, it is assumed that the data recipient owns a public and private key pair and provided his or her public key to the data sender. OpenPGP can then be directed to encrypt the dynamically generated session key using this public key, and deliver it encrypted in a cPublic Key Encrypted Session Key Packet d that also contains information for the recipient regarding the asymmetric algorithm and public key identifier that were involved in the process. This encrypted key cpacket d is then delivered along with the cSymmetrically Encrypted Data Packet d to the data recipient. Packets , subpackets , and messages are part of the OpenPGP terminology to designate formatted sets of data intended to be exchanged with OpenPGP-compliant partners. This is further described in cOpenPGP messages d on page 14. The Encryption Facility for OpenPGP proposes the RSA or ElGamal asymmetric algorithms for public key encryption of the session key. Session key exchange using passphrase-based encryption Passphrase-based encryption (PBE) provides a symmetric encryption of the randomly generated session key using a symmetric key that is derived from a shared secret passphrase. The session key encrypted with PBE is sent in a cSymmetric Key Encrypted Session Key d packet. This packet contains information on the symmetric algorithm used to encrypt the session key, and also on the derivation process used to obtain this symmetric key with the so-called cstring-to-key d (S2K) set of information. When decrypting the OpenPGP message, the data recipient should provide the secret passphrase as the input to an identical derivation process. Data compression OpenPGP offers as an option the capability of compressing clear data before encryption or decompressing clear data after decryption. The Encryption Facility for OpenPGP proposes the zlib or zip algorithms for the compression of data. zlib is a general purpose compression library that includes Note: The OpenPGP session key should be randomly generated. Therefore each new request for symmetric encryption gets a new, unpredictable session key. 14 Encryption Facility for z/OS V1.2 OpenPGP Support one implementation of the DEFLATE compression method, which is a combination of Lempel-Ziv and Huffman encoding of data. zip is the compression algorithm at the core of the PKZIP engine, which many platforms have implemented. 2.2 OpenPGP messages This section provides a high-level description of the data formats used to exchange data processed by OpenPGP services that provide encryption, decryption, signing, and key management functions. If more details are needed, refer to RFC2440. The data intended to be exchanged are cmessages d made of cpackets. d A packet is a segment of data with a specific content, the nature of which is indicated by the packet tag located in the packet header. The packet content itself includes items such as a time stamp, a key Identifier, the actual text message, and so forth. Each packet consists of a packet header followed by the packet body, which may in turn contain csubpackets. d The subpackets are other specific segments of data that are imbedded in the packets; each subpacket contains a subpacket header and a subpacket body. Note that OpenPGP certificates are also composed of packets, and are stored as such in the OpenPGP key ring. More details about OpenPGP certificates are presented in 2.5, cOpenPGP certificates d. 2.3 OpenPGP versions and corresponding messages formats The basis for the design of OpenPGP was PGP release 5.x (also known as cPGP 3 d). The previous PGP releases were the 2.6.x releases, which used messages and packets formats now deprecated and different from the PGP 5.x messages and packets formats. Generally speaking, PGP 2.6.x was supporting the Version 3 format of packets, whereas PGP 5.x introduced the more expandable Version 4 format. Note: For the sake of interoperability the Encryption Facility for OpenPGP accepts both version 3 and version 4 packets, but produces only version 4 packets. Chapter 2. An introduction to OpenPGP 15 2.4 ASCII armor The OpenPGP cASCII armorized d message is a variation of the Base-64 encoding commonly used to encode messages that may encounter transmission problems when flowing in their initial binary form. Usually these problems occur in networks where devices could interpret binary sequences of data bits as control characters, or more generally speaking are expecting to receive only ASCII printable characters. The OpenPGP standard specifies one optional data encoding scheme, where binary strings of data can be transformed into ASCII printable character strings. The OpenPGP encoding yields messages in the cASCII Armor d format. Data encoded into an ASCII armorized message has specific headers that are used by the OpenPGP receiving side to reconstruct the initial binary data string. Figure 2-1shows how an ASCII armorized message displays. This example was created with an ASCII armorized OpenPGP certificate that resides in a z/OS UNIX file. The display shows ASCII printable characters, which can therefore be copied from the z/OS attached display device screen and pasted onto an ASCII system attached display device. However, since z/OS is an EBCDIC system, this display results from an EBCDIC hexadecimal representation of these printable characters in the z/OS UNIX file. This z/OS ASCII armorized message should therefore be sent to an ASCII system using EBCDIC-to-ASCII character translation (something the FTP commonly does). Conversely, an ASCII armorized message generated on an ASCII system should be sent with ASCII-to-EBCDIC character conversion to z/OS. Note: Sending or receiving data being cASCII armored d is an option supported by the Encryption Facility for OpenPGP only for OpenPGP certificate messages. 16 Encryption Facility for z/OS V1.2 OpenPGP Support Figure 2-1 ASCII armorized OpenPGP certificate 2.5 OpenPGP certificates OpenPGP certificates use a specific format that differs from the widely accepted X.509 format. This section presents a high-level description of these two formats, with considerations regarding the characteristics of the environments in which they are used. 2.5.1 A word on the X.509 standards X.509 is a set of standards that have been adopted by the IETF PKIX group to promote interoperability between entities involved in Public Key Infrastructure (PKI) interactions. A conceptual view of a PKI is shown in Figure 2-2, where clients are asking digital certificates to a Certificate Authority. The Certificate Authority signs and provides certificates to the properly identified and entitled clients. It also publishes certificate revocation information containing a list of previously granted certificates that, for various reasons, must not be accepted anymore as a binding between a public key and a user identity. The prevalent technologies today to make this revocation information available are either the publishing of a Certificate Revocation List (CRL) in an LDAP directory, or the real time interrogation of the Certificate Authority via the Online Certificate Status Protocol (OCSP). -----BEGIN PGP PUBLIC KEY BLOCK----- Version: IBM Encryption Facility for z/OS V1.2 xo0ERftnwAEEAN34VgMNCxGaTTgXO+LwzWgbydbF/6vkOMzT22KEQYI+JIB7KZBIizRev7CeG2PH r+hkiSkctwLAKFgJjsVWBzJz/diwpRBVfL39FlhFzpoZuagrdcEYjTJPzyzSI/P0svSugrEy8Ly5 wOuIK6pNeIvASZlsDT345rq13YyEJ9Z1ABEBAAHCtQQfAQIAHwUCRjofPAIeAQIbDwULAgkIBwUV AgoJCAMWAQICF4AACgkQo8sMavB6vg/S6wP+L7zZfqL3Egc6r7HVC/WhbOQ7ZjX84DWYy7VLWN+y wpJaiK+neOAVyOk0notCRdoF8h1mgrKWOQF7N8ILEpytW6fdZxDzEC2DVjlXuXb00UND4ZdGwKa5 fxDcsCPamDiimFig2cxolk1qJtPYAn66hNip1OdNiRqBxHes2ghHaPfNK2thcHBlbGVyIDxubyBj b21tZW50PiA8a2FwcGVsZXJAZnIuaWJtLmNvbT7CtQQTAQIAHwUCRjofPQIeAQIbDwULAgkIBwUV AgoJCAMWAQICF4AACgkQo8sMavB6vg9MuAP+OvOtwyx8pSINBzj2dL5bZc5jDdBiar5rsMXIvM9/ wfeTvrD6gCObN6KHvtOLNwffu1y0vGrHqtHx1jYPzZlanS0Bq0S6PuinrI3QHppG16gpEo8tNx5y fhEV3yQoXDuh6QrzLE9vB7LbdiVgRJqfqbQq9zOzlWuAgPPMmco2kyo= =U0Fg -----END PGP PUBLIC KEY BLOCK----- Chapter 2. An introduction to OpenPGP 17 Figure 2-2 The PKIX Public Key Infrastructure The X.509 V3 certificate The PKIX recommended format for the digital certificate is the X.509 V3 format, as defined in RFC 2459, which is shown in Figure 2-3. The certificate contains mandatory fields along with optional extension fields; the digital signature of the certificate by the Certificate Authority (or by the owner of the certificate for a cself-signed d certificate) is calculated using a hash value generated from the totality of the certificate 9s fields. Certificates and CRLs Repository Certification Authority for the Domain (optionally with a Registration Authority) Certificate, exploiting Entity CA Policy Cerificate Owning Entity 1-Certificate Request 2-Certificate Issuance 4-Certificate Revocation Checking Certificate Revocation Lists Issuance 3-Certificate Utilization (e.g. SSL/TLS) PKI PKIX: Certificate Request in PKCS#10 format PKIX: Format of Certificate is X.509 V3 PKIX: Format of Certificate Revokation List is X.509 V2 PKIX: CRL repository (LDAP directory) Online Certificate Status Protocol (OCSP) 18 Encryption Facility for z/OS V1.2 OpenPGP Support Figure 2-3 The X.509 V3 digital certificate 2.5.2 The OpenPGP certificate The OpenPGP certificate can be thought of as a message containing specific packets that are similar to the X.509 certificate fields. A high-level graphical view of an OpenPGP certificate is given in Figure 2-4. One can retrieve in this certificate the public key to be bound to the user ID; however, be aware that the key owner may have several different user IDs, each of them being bound to the public key. Note that the OpenPGP naming model does not exploit distinguished names as proposed in the X.500 standard. It identifies the owner of the certificate with an OpenPGP User ID. The OpenPGP user ID is composed of a user real name, an optional e-mail address, and an optional comment. certificate version : 3 certificate serial number signature algorithm identifier issuer (CA) X.500 name validity period subject X.500 name subject public key info algorithm id public key value issuer unique identifier subject unique identifiers extensions Digital signature generate using issuer's private key Signature Note: Search commands or utilities for OpenPGP userID are actually looking for the specified substring in the string resulting from the concatenation of the userID full name, comment, and e-mail address. Chapter 2. An introduction to OpenPGP 19 In OpenPGP terminology, the public key is also called the cprimary key, d or the ctop-level key. d OpenPGP also requires that the primary key pair has signing capability, as DSA keys have. If the user also requires key pairs for encryption only, as is the case for ElGamal keys or RSA keys flagged for key-management only, then the user should provide the corresponding public keys as csubkeys d in the certificate. To ensure that the subkeys belong to the user, they are also signed with the primary key. Figure 2-4 The OpenPGP certificate A very specific feature of OpenPGP is that certification, or revocation, is not intended to be granted by a Certificate Authority. Instead the OpenPGP certificate exhibits sets of other OpenPGP users 9 signatures that vouch for the certification or the revocation of the keys. Actually, OpenPGP introduces the cWeb of Trust d concept as an alternative to a single centralized trusted Certificate Authority. The Web of Trust concept is explained in 2.6, cThe OpenPGP Web of Trust concept d on page 21. Note also that key bindings can be revoked using revocation signatures that are generated by the certificate owner or users designated as possible revokers. Note: An OpenPGP certificate is always self-signed, and may also include other signers 9 signatures. Public Key in Public Key Packet Opt. Revocation Signature Opt. Revocation Signature &.. User ID Packet Certfication Signature Certfication Signature &.. Opt Subkey Packet Certfication Signature Opt. Revocation Signature Can be several different User IDs, each with their Certification signatures Can be several different Subkeys, each with their signatures SIGN Signer Key SIGN SIGN SIGN SIGN Private key Revoker Key SIGN 20 Encryption Facility for z/OS V1.2 OpenPGP Support The OpenPGP Version 4 Signature Figure 2-5 shows, still at a high level, how OpenPGP signature packets are formed in the OpenPGP certificates. There are still in use today two versions of the OpenPGP signature packet format. Version 4 is the current version, which has superseded Version 3. The signature is delivered in a Signature Packet and is created using a combined hash of the public key value and the contents of the so-called chashed subpackets. d The hashed subpackets contain information similar to the X.509 V3 certificate fields and are also cryptographically bound to the public key value. Figure 2-5 Version 4 signatures in the OpenPGP certificate 2.5.3 The OpenPGP keyring Users keep OpenPGP certificates and keys in files that implement the concept of a ckeyring. d Certificates and keys are stored in a keyring as messages, packets, and subpackets. Figure 2-6 is a conceptual view of an OpenPGP certificate and Note: The Encryption Facility for OpenPGP accepts Version 3 signatures; however, it produces only Version 4 signatures. Version # Signature type Public Key algorithm Hash algorithm Signature Creation date Key flags Preferred Symmetric algo Preffered Hash algo Preferred Compression algo Signer 9s User ID Key expiration date &.. Other unhashed subpackets Issuer Key ID Others .. Signature Hash function Encrypt function Version 4 Signature packet Hashed subpackets Key value to sign Signing key &. Primary User ID Chapter 2. An introduction to OpenPGP 21 keys in a keyring. Note that the certificate and keys entries are labelled both with an OpenPGP user ID and a Key ID, the latter being a hash value calculated from the public key value. Note that OpenPGP looks also for signers 9 certificates in the keyring when it comes to verify a signature. When a certificate is imported into the OpenPGP keyring it can be granted a trust level (from 0 to 255) by the owner of the keyring, along with comments that are kept with the certificate. This trust level is exploited by OpenPGP implementations that automatically attempt to assess how many chained signer certificates are required to get to a pre-defined level of confidence in the trustworthiness of a signature. Figure 2-6 Conceptual view of the OpenPGP keyring 2.6 The OpenPGP Web of Trust concept This section presents a high-level description of the Web of Trust concept. Note that this concept does not have any support implementation in the Encryption Facility for OpenPGP. Note: Encryption Facility for OpenPGP does not exploit the certificate trust level beyond keeping it stored locally with the certificate. OpenPGP keyring Key ID User ID Certificate packets Public Key User ID Private Key Packet Subkey Private Subkey Packet In order for OpenPGP to verify signatures, the signers 9 certificates must also be in the keyring signature signature signature signature signature "Trust level "comment 22 Encryption Facility for z/OS V1.2 OpenPGP Support As already mentioned, the objective of OpenPGP is not to rely on a central Certificate Authority to establish a trusted binding between a public key and its owner 9s identity, although this could be done. Instead, the binding between keys and user IDs is still achieved via digital signature; however, these are other OpenPGP users 9 s

less