DOCSLIB.ORG

Z/OS Version 2 Release 4

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Z/OS Version 2 Release 4 z/OS Version 2 Release 4 Open Cryptographic Services Facility Application Programming IBM SC14-7513-40 Note Before using this information and the product it supports, read the information in “Notices” on page 281. This edition applies to Version 2 Release 4 of z/OS (5650-ZOS) and to all subsequent releases and modifications until otherwise indicated in new editions. Last updated: 2020-03-25 © Copyright International Business Machines Corporation 1999, 2020. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Figures............................................................................................................... xiii Tables................................................................................................................. xv About this document...........................................................................................xix OCSF Architecture..................................................................................................................................... xix Who should use this information............................................................................................................... xx Requirements............................................................................................................................................ xxi Conventions used in this information....................................................................................................... xxi Where to Find More Information ..............................................................................................................xxi Internet Sources ................................................................................................................................. xxi How to send your comments to IBM...................................................................xxiii If you have a technical problem.............................................................................................................. xxiii Summary of changes.......................................................................................... xxv Summary of changes for z/OS Version 2 Release 4 (V2R4).................................................................... xxv Summary of changes for z/OS Version 2 Release 3 (V2R3).................................................................... xxv Summary of changes for z/OS Version 2 Release 2 (V2R2).................................................................... xxv Chapter 1. Configuring and Getting Started ........................................................... 1 Setting Up the Necessary Security Authorizations .................................................................................... 1 Security Administration..........................................................................................................................1 RACF FACILITY Class Profiles Required by OCSF ................................................................................ 1 Program Control .....................................................................................................................................2 APF Authorization...................................................................................................................................3 OSCF User Identities and Permissions ................................................................................................. 3 Granting Permission to Use OCSF Service ............................................................................................ 3 Using Groups.......................................................................................................................................... 4 Refreshing z/OS Security Server Data ...................................................................................................4 Running the Installation Script ................................................................................................................... 4 Running the Installation Verification Procedure ........................................................................................ 5 Common Problems ......................................................................................................................................6 Chapter 2. Open Cryptographic Services Facility Framework ..................................7 Module Management................................................................................................................................... 7 Installing and Uninstalling Service Provider Modules .......................................................................... 7 Listing Service Provider Modules and Services .................................................................................... 8 Attaching and Detaching Service Provider Modules .............................................................................8 Managing Calls Between Service Provider Modules .............................................................................9 Memory Management................................................................................................................................10 Security Context Management ................................................................................................................. 10 OCSF Security Context Changes ...............................................................................................................12 Integrity Verification Services .................................................................................................................. 13 Chapter 3. OCSF Policy Modules ..........................................................................15 Usage of OCSF Policy Modules ................................................................................................................. 15 OCSF Behavior When Only the OCSF Base is Installed ......................................................................15 OCSF Behavior When the OCSF Security Level 3 Feature is Installed ...............................................15 iii Implementation of OCSF Policy Modules .................................................................................................15 Chapter 4. Cryptographic Module Manager .......................................................... 17 Supporting Legacy CSPs............................................................................................................................ 17 Cryptography Services API ....................................................................................................................... 17 Dependencies with the Policy Modules ....................................................................................................18 Chapter 5. Trust Policy Module Manager .............................................................. 21 Trust Policy API .........................................................................................................................................22 Chapter 6. Certificate Library Module Manager .................................................... 23 Certificate Library Services API ................................................................................................................23 Chapter 7. Data Storage Library Module Manager .................................................25 Data Storage Library Services API ............................................................................................................25 Chapter 8. Service Provider Modules ................................................................... 27 Cryptographic Service Provider Modules ................................................................................................. 27 Trust Policy Modules .................................................................................................................................27 Certificate Library Modules .......................................................................................................................28 Data Storage Library Module .................................................................................................................... 28 OCSF Service Provider Modules ............................................................................................................... 28 IBM Software Cryptographic Service Provider, Version 1.0 .................................................................... 29 IBM Weak Software Cryptographic Service Provider, Version 1.0 .......................................................... 33 IBM Software Cryptographic Service Provider 2, Version 1.0 ................................................................. 34 IBM Weak Software Cryptographic Service Provider 2, Version 1.0 ....................................................... 38 IBM CCA Cryptographic Module Version 1.0 ............................................................................................39 IBM Standard Trust Policy Library, Version 1.0 ....................................................................................... 44 IBM Extended Trust Policy Library, Version 1.0 .......................................................................................45 IBM Certificate Library, Version 1.0 ........................................................................................................
Load more

Recommended publications
  • Bison Instantiating the Whitened Swap-Or-Not Construction (Full Version)
    bison Instantiating the Whitened Swap-Or-Not Construction (Full Version) Anne Canteaut1, Virginie Lallemand2, Gregor Leander2, Patrick Neumann2 and Friedrich Wiemer2 1 Inria, Paris, France [email protected] 2 Horst Görtz Institute for IT-Security, Ruhr University Bochum, Germany [email protected] Abstract. We give the first practical instance – bison – of the Whitened Swap-Or-Not construction. After clarifying inherent limitations of the construction, we point out that this way of building block ciphers allows easy and very strong arguments against differential attacks. Keywords: Whitened Swap-Or-Not · Instantiating Provable Security · Block Cipher Design · Differential Cryptanalysis 1 Introduction Block ciphers are among the most important cryptographic primitives as they are at the core responsible for a large fraction of all our data that is encrypted. Depending on the mode of operation (or used construction), a block cipher can be turned into an encryption function, a hash-function, a message authentication code or an authenticated encryption function. Due to their importance, it is not surprising that block ciphers are also among the best understood primitives. In particular the Advanced Encryption Standard (AES) [Fip] has been scrutinized by cryptanalysts ever since its development in 1998 [DR98] without any significant security threat discovered for the full cipher (see e. g. [BK09; Bir+09; Der+13; Dun+10; Fer+01; GM00; Gra+16; Gra+17; Røn+17]). The overall structure of AES, being built on several (round)-permutations interleaved with a (binary) addition of round keys is often referred to as key-alternating cipher and is depicted in Figure1. k0 k1 kr 1 kr − m R1 ..
    [Show full text]
  • Tuto Documentation Release 0.1.0
    Tuto Documentation Release 0.1.0 DevOps people 2020-05-09 09H16 CONTENTS 1 Documentation news 3 1.1 Documentation news 2020........................................3 1.1.1 New features of sphinx.ext.autodoc (typing) in sphinx 2.4.0 (2020-02-09)..........3 1.1.2 Hypermodern Python Chapter 5: Documentation (2020-01-29) by https://twitter.com/cjolowicz/..................................3 1.2 Documentation news 2018........................................4 1.2.1 Pratical sphinx (2018-05-12, pycon2018)...........................4 1.2.2 Markdown Descriptions on PyPI (2018-03-16)........................4 1.2.3 Bringing interactive examples to MDN.............................5 1.3 Documentation news 2017........................................5 1.3.1 Autodoc-style extraction into Sphinx for your JS project...................5 1.4 Documentation news 2016........................................5 1.4.1 La documentation linux utilise sphinx.............................5 2 Documentation Advices 7 2.1 You are what you document (Monday, May 5, 2014)..........................8 2.2 Rédaction technique...........................................8 2.2.1 Libérez vos informations de leurs silos.............................8 2.2.2 Intégrer la documentation aux processus de développement..................8 2.3 13 Things People Hate about Your Open Source Docs.........................9 2.4 Beautiful docs.............................................. 10 2.5 Designing Great API Docs (11 Jan 2012)................................ 10 2.6 Docness.................................................
    [Show full text]
  • Cryptanalysis of Substitution-Permutation Networks Using Key-Dependent Degeneracy*
    Cryptanalysis of Substitution-Permutation Networks Using Key-Dependent Degeneracy* Howard M. Heys Electrical Engineering, Faculty of Engineering and Applied Science Memorial University of Newfoundland St. John’s, Newfoundland, Canada A1B 3X5 Stafford E.Tavares Department of Electrical and Computer Engineering Queen’s University Kingston, Ontario, Canada K7L 3N6 * This research was supported by the Natural Sciences and Engineering Research Council of Canada and the Telecommunications Research Institute of Ontario and was completed during the first author’s doctoral studies at Queen’s University. Cryptanalysis of Substitution-Permutation Networks Using Key-Dependent Degeneracy Keywords Ð Cryptanalysis, Substitution-Permutation Network, S-box Abstract Ð This paper presents a novel cryptanalysis of Substitution- Permutation Networks using a chosen plaintext approach. The attack is based on the highly probable occurrence of key-dependent degeneracies within the network and is applicable regardless of the method of S-box keying. It is shown that a large number of rounds are required before a network is re- sistant to the attack. Experimental results have found 64-bit networks to be cryptanalyzable for as many as 8 to 12 rounds depending on the S-box properties. ¡ . Introduction The concept of Substitution-Permutation Networks (SPNs) for use in block cryp- tosystem design originates from the “confusion” and “diffusion” principles in- troduced by Shannon [1]. The SPN architecture considered in this paper was first suggested by Feistel [2] and consists of rounds of non-linear substitutions (S-boxes) connected by bit permutations. Such a cryptosystem structure, referred 1 to as LUCIFER1 by Feistel, is a simple, efficient implementation of Shannon’s concepts.
    [Show full text]
  • Block Ciphers and the Data Encryption Standard
    Lecture 3: Block Ciphers and the Data Encryption Standard Lecture Notes on “Computer and Network Security” by Avi Kak ([email protected]) January 26, 2021 3:43pm ©2021 Avinash Kak, Purdue University Goals: To introduce the notion of a block cipher in the modern context. To talk about the infeasibility of ideal block ciphers To introduce the notion of the Feistel Cipher Structure To go over DES, the Data Encryption Standard To illustrate important DES steps with Python and Perl code CONTENTS Section Title Page 3.1 Ideal Block Cipher 3 3.1.1 Size of the Encryption Key for the Ideal Block Cipher 6 3.2 The Feistel Structure for Block Ciphers 7 3.2.1 Mathematical Description of Each Round in the 10 Feistel Structure 3.2.2 Decryption in Ciphers Based on the Feistel Structure 12 3.3 DES: The Data Encryption Standard 16 3.3.1 One Round of Processing in DES 18 3.3.2 The S-Box for the Substitution Step in Each Round 22 3.3.3 The Substitution Tables 26 3.3.4 The P-Box Permutation in the Feistel Function 33 3.3.5 The DES Key Schedule: Generating the Round Keys 35 3.3.6 Initial Permutation of the Encryption Key 38 3.3.7 Contraction-Permutation that Generates the 48-Bit 42 Round Key from the 56-Bit Key 3.4 What Makes DES a Strong Cipher (to the 46 Extent It is a Strong Cipher) 3.5 Homework Problems 48 2 Computer and Network Security by Avi Kak Lecture 3 Back to TOC 3.1 IDEAL BLOCK CIPHER In a modern block cipher (but still using a classical encryption method), we replace a block of N bits from the plaintext with a block of N bits from the ciphertext.
    [Show full text]
  • US 2007/0043.668A1 Baxter Et Al
    US 2007.0043.668A1 (19) United States (12) Patent Application Publication (10) Pub. No.: US 2007/0043.668A1 Baxter et al. (43) Pub. Date: Feb. 22, 2007 (54) METHODS AND SYSTEMS FOR Related U.S. Application Data NEGOTABLE-INSTRUMENT FRAUD PREVENTION (63) Continuation of application No. 10/371,984, filed on Feb. 20, 2003, now Pat. No. 7,072,868. (75) Inventors: Craig A. Baxter, Castle Rock, CO (US); John Charles Ciaccia, Parker, Publication Classification CO (US); Rodney J. Esch, Littleton, CO (US) (51) Int. Cl. G06Q 99/00 (2006.01) Correspondence Address: (52) U.S. Cl. ................................................................ 705/50 TOWNSEND AND TOWNSEND AND CREW, LLP (57) ABSTRACT TWO EMBARCADERO CENTER EIGHTH FLOOR SAN FRANCISCO, CA 94111-3834 (US) An authentication value is provided in a magnetic-ink field of a negotiable instrument. The authentication value is (73) Assignee: First Data Corporation, Greenwood derived from application of an encryption algorithm defined Village, CO (US) by a secure key. The authentication value may be used to authenticate the instrument through reapplication of the (21) Appl. No.: 11/481,062 encryption algorithm and comparing the result with the authentication value. The instrument is authenticated if there (22) Filed: Jul. 3, 2006 is a match between the two. 530 instrument Presented at Port of Sae instrument Conveyed to First Financial MCR line Scanned and instrument 534 Institution Authenticated at Point of Sale 538 Electronic Package Generated with MICR-Line Information andlor image 542 Electronic
    [Show full text]
  • Related-Key Cryptanalysis of 3-WAY, Biham-DES,CAST, DES-X, Newdes, RC2, and TEA
    Related-Key Cryptanalysis of 3-WAY, Biham-DES,CAST, DES-X, NewDES, RC2, and TEA John Kelsey Bruce Schneier David Wagner Counterpane Systems U.C. Berkeley kelsey,schneier @counterpane.com [email protected] f g Abstract. We present new related-key attacks on the block ciphers 3- WAY, Biham-DES, CAST, DES-X, NewDES, RC2, and TEA. Differen- tial related-key attacks allow both keys and plaintexts to be chosen with specific differences [KSW96]. Our attacks build on the original work, showing how to adapt the general attack to deal with the difficulties of the individual algorithms. We also give specific design principles to protect against these attacks. 1 Introduction Related-key cryptanalysis assumes that the attacker learns the encryption of certain plaintexts not only under the original (unknown) key K, but also under some derived keys K0 = f(K). In a chosen-related-key attack, the attacker specifies how the key is to be changed; known-related-key attacks are those where the key difference is known, but cannot be chosen by the attacker. We emphasize that the attacker knows or chooses the relationship between keys, not the actual key values. These techniques have been developed in [Knu93b, Bih94, KSW96]. Related-key cryptanalysis is a practical attack on key-exchange protocols that do not guarantee key-integrity|an attacker may be able to flip bits in the key without knowing the key|and key-update protocols that update keys using a known function: e.g., K, K + 1, K + 2, etc. Related-key attacks were also used against rotor machines: operators sometimes set rotors incorrectly.
    [Show full text]
  • By Jennifer M. Fogel a Dissertation Submitted in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy
    A MODERN FAMILY: THE PERFORMANCE OF “FAMILY” AND FAMILIALISM IN CONTEMPORARY TELEVISION SERIES by Jennifer M. Fogel A dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy (Communication) in The University of Michigan 2012 Doctoral Committee: Associate Professor Amanda D. Lotz, Chair Professor Susan J. Douglas Professor Regina Morantz-Sanchez Associate Professor Bambi L. Haggins, Arizona State University © Jennifer M. Fogel 2012 ACKNOWLEDGEMENTS I owe my deepest gratitude to the members of my dissertation committee – Dr. Susan J. Douglas, Dr. Bambi L. Haggins, and Dr. Regina Morantz-Sanchez, who each contributed their time, expertise, encouragement, and comments throughout this entire process. These women who have mentored and guided me for a number of years have my utmost respect for the work they continue to contribute to our field. I owe my deepest gratitude to my advisor Dr. Amanda D. Lotz, who patiently refused to accept anything but my best work, motivated me to be a better teacher and academic, praised my successes, and will forever remain a friend and mentor. Without her constructive criticism, brainstorming sessions, and matching appreciation for good television, I would have been lost to the wolves of academia. One does not make a journey like this alone, and it would be remiss of me not to express my humble thanks to my parents and sister, without whom seven long and lonely years would not have passed by so quickly. They were both my inspiration and staunchest supporters. Without their tireless encouragement, laughter, and nurturing this dissertation would not have been possible.
    [Show full text]
  • Chapter 3 – Block Ciphers and the Data Encryption Standard
    Symmetric Cryptography Chapter 6 Block vs Stream Ciphers • Block ciphers process messages into blocks, each of which is then en/decrypted – Like a substitution on very big characters • 64-bits or more • Stream ciphers process messages a bit or byte at a time when en/decrypting – Many current ciphers are block ciphers • Better analyzed. • Broader range of applications. Block vs Stream Ciphers Block Cipher Principles • Block ciphers look like an extremely large substitution • Would need table of 264 entries for a 64-bit block • Arbitrary reversible substitution cipher for a large block size is not practical – 64-bit general substitution block cipher, key size 264! • Most symmetric block ciphers are based on a Feistel Cipher Structure • Needed since must be able to decrypt ciphertext to recover messages efficiently Ideal Block Cipher Substitution-Permutation Ciphers • in 1949 Shannon introduced idea of substitution- permutation (S-P) networks – modern substitution-transposition product cipher • These form the basis of modern block ciphers • S-P networks are based on the two primitive cryptographic operations we have seen before: – substitution (S-box) – permutation (P-box) (transposition) • Provide confusion and diffusion of message Diffusion and Confusion • Introduced by Claude Shannon to thwart cryptanalysis based on statistical analysis – Assume the attacker has some knowledge of the statistical characteristics of the plaintext • Cipher needs to completely obscure statistical properties of original message • A one-time pad does this Diffusion
    [Show full text]
  • Harris Sierra II, Programmable Cryptographic
    TYPE 1 PROGRAMMABLE ENCRYPTION Harris Sierra™ II Programmable Cryptographic ASIC KEY BENEFITS When embedded in radios and other voice and data communications equipment, > Legacy algorithm support the Harris Sierra II Programmable Cryptographic ASIC encrypts classified > Low power consumption information prior to transmission and storage. NSA-certified, it is the foundation > JTRS compliant for the Harris Sierra II family of products—which includes two package options for the ASIC and supporting software. > Compliant with NSA’s Crypto Modernization Program The Sierra II ASIC offers a broad range of functionality, with data rates greater than 300 Mbps, > Compact form factor legacy algorithm support, advanced programmability and low power consumption. Its software programmability provides a low-cost migration path for future upgrades to embedded communications equipment—without the logistics and cost burden normally associated with upgrading hardware. Plus, it’s totally compliant with all Joint Tactical Radio System (JTRS) and Crypto Modernization Program requirements. The Sierra II ASIC’s small size, low power requirements, and high data rates make it an ideal choice for battery-powered applications, including military radios, wireless LANs, remote sensors, guided munitions, UAVs and any other devices that require a low-power, programmable solution for encryption. Specifications for: Harris SIERRA II™ Programmable Cryptographic ASIC GENERAL BATON/MEDLEY SAVILLE/PADSTONE KEESEE/CRAYON/WALBURN Type 1 – Cryptographic GOODSPEED Algorithms* ACCORDION FIREFLY/Enhanced FIREFLY JOSEKI Decrypt High Assurance AES DES, Triple DES Type 3 – Cryptographic AES Algorithms* Digital Signature Standard (DSS) Secure Hash Algorithm (SHA) Type 4 – Cryptographic CITADEL® Algorithms* SARK/PARK (KY-57, KYV-5 and KG-84A/C OTAR) DS-101 and DS-102 Key Fill Key Management SINCGARS Mode 2/3 Fill Benign Key/Benign Fill *Other algorithms can be added later.
    [Show full text]
  • An Archeology of Cryptography: Rewriting Plaintext, Encryption, and Ciphertext
    An Archeology of Cryptography: Rewriting Plaintext, Encryption, and Ciphertext By Isaac Quinn DuPont A thesis submitted in conformity with the requirements for the degree of Doctor of Philosophy Faculty of Information University of Toronto © Copyright by Isaac Quinn DuPont 2017 ii An Archeology of Cryptography: Rewriting Plaintext, Encryption, and Ciphertext Isaac Quinn DuPont Doctor of Philosophy Faculty of Information University of Toronto 2017 Abstract Tis dissertation is an archeological study of cryptography. It questions the validity of thinking about cryptography in familiar, instrumentalist terms, and instead reveals the ways that cryptography can been understood as writing, media, and computation. In this dissertation, I ofer a critique of the prevailing views of cryptography by tracing a number of long overlooked themes in its history, including the development of artifcial languages, machine translation, media, code, notation, silence, and order. Using an archeological method, I detail historical conditions of possibility and the technical a priori of cryptography. Te conditions of possibility are explored in three parts, where I rhetorically rewrite the conventional terms of art, namely, plaintext, encryption, and ciphertext. I argue that plaintext has historically been understood as kind of inscription or form of writing, and has been associated with the development of artifcial languages, and used to analyze and investigate the natural world. I argue that the technical a priori of plaintext, encryption, and ciphertext is constitutive of the syntactic iii and semantic properties detailed in Nelson Goodman’s theory of notation, as described in his Languages of Art. I argue that encryption (and its reverse, decryption) are deterministic modes of transcription, which have historically been thought of as the medium between plaintext and ciphertext.
    [Show full text]
  • Cryptool 2 in Teaching Cryptography
    Journal of Computations & Modelling, vol.4, no.1, 2014, 349-358 ISSN: 1792-7625 (print), 1792-8850 (online) Scienpress Ltd, 2014 Cryptool 2 in Teaching Cryptography Major Konstantinos Loussios1 Abstract. Considering the value it had in the past, has continued to the present and will continue to have, perhaps to an even greater extent in the future concealing information during transmission or transport, leads automatically to attempt to discover the importance and the value of the means, methods and techniques used to implement the concealment. Cryptography is a branch of computer science attracts the attention with its great utility that has nowadays. Given therefore deemed necessary to standardize, analyze and present the encryption algorithms to learning and training on the operation with as efficiently and easily as possible. Having in mind that the theory must be accompanied by practice and examples that help to consolidate the syllabi material, we felt that the analytical presentation of an educational tool on learning algorithms of cryptography is a way of learning while embedding. The learning tool cryptool 2 is an implementation of all the above, and through this we will try to show, those essential functions, which help the user with visual and practical way, to see in detail all the properties and functional details of the algorithms contained, will present representative examples of functioning algorithms, we proceed to create digital signatures and will implement the cryptanalysis algorithms. The above is an object of study and teaching in the professional area of land, in the field of communications and transmissions-service systems. Knowing, however, that historically since the antiquity, first we Greeks, we use encryption in a simple form, for military purposes, but later down through the years and fighting wars around the world, the art encryption and decryption evolved and became object of all armies and weapons.
    [Show full text]
  • An Introduction to Cryptography Copyright © 1990-1999 Network Associates, Inc
    An Introduction to Cryptography Copyright © 1990-1999 Network Associates, Inc. and its Affiliated Companies. All Rights Reserved. PGP*, Version 6.5.1 6-99. Printed in the United States of America. PGP, Pretty Good, and Pretty Good Privacy are registered trademarks of Network Associates, Inc. and/or its Affiliated Companies in the US and other countries. All other registered and unregistered trademarks in this document are the sole property of their respective owners. Portions of this software may use public key algorithms described in U.S. Patent numbers 4,200,770, 4,218,582, 4,405,829, and 4,424,414, licensed exclusively by Public Key Partners; the IDEA(tm) cryptographic cipher described in U.S. patent number 5,214,703, licensed from Ascom Tech AG; and the Northern Telecom Ltd., CAST Encryption Algorithm, licensed from Northern Telecom, Ltd. IDEA is a trademark of Ascom Tech AG. Network Associates Inc. may have patents and/or pending patent applications covering subject matter in this software or its documentation; the furnishing of this software or documentation does not give you any license to these patents. The compression code in PGP is by Mark Adler and Jean-Loup Gailly, used with permission from the free Info-ZIP implementation. LDAP software provided courtesy University of Michigan at Ann Arbor, Copyright © 1992-1996 Regents of the University of Michigan. All rights reserved. This product includes software developed by the Apache Group for use in the Apache HTTP server project (http://www.apache.org/). Copyright © 1995-1999 The Apache Group. All rights reserved. See text files included with the software or the PGP web site for further information.
    [Show full text]