z/VM Version 6 Release 1 System SSL Security Policy IBM® z/VM® Version 6 Release 1 System SSL Cryptographic Module FIPS 140-2 Non-Proprietary Security Policy Policy Version 1.02 IBM Systems & Technology Group System z Development Endicott, New York IBM Research Zurich Research Laboratory June 05, 2012 © Copyright International Business Machines Corporation 2012 This document may be reproduced only in its original entirety without revision. © Copyright IBM Corp. 2012 Page 1 of 17 z/VM Version 6 Release 1 System SSL Security Policy Table of Contents 1. SCOPE OF DOCUMENT.....................................................................................................................................................................3 2. CRYPTOGRAPHIC MODULE SPECIFICATION..........................................................................................................................3 3. CRYPTOGRAPHIC MODULE SECURITY LEVEL......................................................................................................................4 4. PORTS AND INTERFACES................................................................................................................................................................4 5. ROLES, SERVICES AND AUTHENTICATION..............................................................................................................................5 5.1 ROLES.................................................................................................................................................................................................5 5.2 SERVICES.............................................................................................................................................................................................5 6. OPERATIONAL ENVIRONMENT....................................................................................................................................................9 7. KEY MANAGEMENT........................................................................................................................................................................11 8. PHYSICAL SECURITY.....................................................................................................................................................................13 9. EMI/EMC.............................................................................................................................................................................................13 10. SELF-TESTS......................................................................................................................................................................................13 11. OPERATIONAL REQUIREMENTS (OFFICER/USER GUIDANCE)......................................................................................14 11.1 MODULE CONFIGURATION FOR FIPS 140-2 COMPLIANCE.....................................................................................................................14 11.2 DETERMINING MODE OF OPERATION...................................................................................................................................................15 11.3 TESTING/PHYSICAL SECURITY INSPECTION RECOMMENDATIONS...............................................................................................................16 12. MITIGATION OF OTHER ATTACKS........................................................................................................................................16 13. GLOSSARY........................................................................................................................................................................................16 14. REFERENCES...................................................................................................................................................................................17 15. TRADEMARKS.................................................................................................................................................................................17 © Copyright IBM Corp. 2012 Page 2 of 17 z/VM Version 6 Release 1 System SSL Security Policy 1.Scope of Document This document describes the services that the z/VM System SSL library (“System SSL” or “module”) provides to security officers and end users, and the policy governing access to those services. It complements official product documentation, which concentrates on server usage of the functionality, as well as environmental set- up. Module Description The z/VM System SSL library in its FIPS 140-2 configuration consists of a set of loadable 31-bit modules. The deployed version consists of the following modules: Table 1 z/VM System SSL Library Modules Core Auxiliary GSKCMS31 GSKC31 GSKC31F GSKSUS31 GSKSSL GSKS31 GSKS31F Side Decks GSKKYMAN Message Catalogs The z/VM System SSL package consists of the core modules that are utilized while operating in FIPS 140-2 mode, as well as some auxiliary modules and files. The auxiliary modules either provide functionality that is not cryptographically relevant or are not utilized while operating in FIPS 140-2 mode. The files consist of side decks and message catalogs. The z/VM System SSL logical and physical boundaries are described in Figures 1 and 2 in the Operational Environment Section. 2.Cryptographic Module Specification The z/VM System SSL module is classified as a multi-chip standalone hybrid module for FIPS Pub 140-2 purposes. The actual cryptographic boundary for this FIPS 140-2 module validation includes the System SSL module running in configurations backed by hardware cryptography. The System SSL module consists of software-based cryptographic algorithms, as well as symmetric and hashing algorithms provided by the CP Assist for Cryptographic Function (CPACF). System SSL validation was performed using the z/VM Version 6 Release 1 operating system with the following platform configuration: 1.IBM System z10™ Enterprise Class (z10 EC) with CP Assist for Cryptographic Functions DES/TDES Enablement Feature 3863 The module running on the above platforms was validated as meeting all FIPS Pub 140-2 Level 1 security requirements. The z/VM System SSL module is packaged as a set of DLLs and executables which contains all the code for the module. In addition to the configurations tested by the laboratory, vendor-affirmed testing was performed using z/VM © Copyright IBM Corp. 2012 Page 3 of 17 z/VM Version 6 Release 1 System SSL Security Policy Version 6 Release 1 on the following platform: 2.IBM System z196™ with CP Assist for Cryptographic Functions DES/TDES Enablement Feature 3863 Security level This document describes the security policy for the z/VM System SSL with Level 1 overall security as defined in FIPS Pub 140-2 [1]. Table 2 System SSL Module Components Type Name Software (DLLs and executables) 573FAL00: z/VM 6.1 with APAR PM43382 Documentation Not applicable Hardware components z10 CP Assist for Cryptographic Functions DES/TDES Enablement Feature 3863 3.Cryptographic Module Security Level The module is intended to meet requirements of Security Level 1 overall, with certain categories of security requirements not applicable (Table 3). Table 3 Module Security Level Specification Security Requirements Section Level Cryptographic Module Specification 3 Module Ports and Interfaces 1 Roles, Services and Authentication 1 Finite State Model 1 Physical Security 1 Operational Environment 1 Cryptographic Key Management 1 EMI/EMC 1 Self-Tests 1 Design Assurance 1 Mitigation of other attacks N/A Overall 1 4.Ports and Interfaces As a multi-chip standalone module, the System SSL physical interfaces are the boundaries of the host running System SSL library code. The underlying logical interfaces of the module are self-controlled. Control inputs which control the mode of the module are provided. Data input and data output are provided in the variables passed through user-supplied buffers. Status output is provided in return codes and through messages. © Copyright IBM Corp. 2012 Page 4 of 17 z/VM Version 6 Release 1 System SSL Security Policy Cryptographic bypass capability is not supported by System SSL. Module Status The System SSL library communicates any error status synchronously through the use of its return codes. It is the responsibility of the calling application to handle exceptional conditions in a FIPS 140-2 appropriate manner. System SSL is optimized for library use and does not contain any terminating assertions or exceptions. Any internal error detected by System SSL and not induced by user data will be reflected back to the application with an appropriate return code. The calling application must examine the return code and act in a FIPS 140-2 appropriate manner to such failures and reflect this error in a fashion consistent with this application. User-induced or internal errors do not reveal any sensitive material to callers. 5.Roles, Services and Authentication 5.1Roles The module supports two roles: a cryptographic officer (Officer) role and a User role (Table 4). The module does not support user identification or authentication that would allow the module to distinguish between the two supported roles. Each of the roles is authenticated through the operating system prior to using any system services. The Officer role is a purely administrative role that does not involve the use of cryptographic services. The role is not explicitly authenticated but assumed implicitly on implementation of the module’s installation and usage sections defined in the security rules section. The User role has access to all of the module’s services. The role is not explicitly authenticated, but assumed implicitly on access of any of the non-Officer services. An operator is implicitly in the User or Officer role based upon the service(s) chosen. If any of the User-specific services are called, then the operator is in the User role; otherwise the operator is in the Officer role. Table 4 Roles and Authentication Mechanisms Role Type of Authentication Authentication Data Strength of Mechanism Officer None(Automatic) None N/A User None(Automatic) None N/A 5.2Services The module provides queries (Table 6) and commands. Queries return status of commands or command groups; commands exercise cryptographic functions. Officers perform queries; Users may perform both queries and commands. While most test queries are not executed automatically as part of regular operations, certain test queries are executed automatically; these special cases are parenthesized as (yes) in Table 6. Services are accessed only by an authorized calling application. These applications are defined in Section 6. Certificate management services (CMS) perform both non-cryptographic and cryptographic PKI management activities, as well as general cryptographic operations, such as signature verification. Functions in this group parse and categorize X.509 certificates and transport certificates, and also handle standard encodings (such © Copyright IBM Corp. 2012 Page 5 of 17 z/VM Version 6 Release 1 System SSL Security Policy as PKCS#7). Cryptographic operations, such as signature verification, are delegated to lower-level crypto core functions. SSL protocol implementation is split into infrastructure and protocol functions. Lower-level functions implement SSL message formatting and other primitives. SSL protocol operations extend SSL primitives with handshake state machines, session caching, and attribute parsing to provide a full SSL/TLS implementation. Both System SSL layers use cryptographic cores indirectly. SSL 3.0 functionality is disallowed in FIPS 140-2 mode: all other compliance checks are implemented at lower levels. In FIPS 140-2 mode, cipher suites are restricted to those built with approved algorithms only. Format conversions, labeled as “other operations", are other non-cryptographic commands that change the representation of data. Format converters read and write, among others, the following formats: •Various protocols based on ASN.1/BER encoded data (PKI-related and similar standard formats) •Conversions between industry-standard object identifiers and internal symbolic constants (mainly intrinsic, not externalized). Protocol-level format conversions generally package data without modification, treating output or input of lower-level crypto primitives as opaque data. The purpose of these conversions is to bridge protocols with predefined formats with cryptographic primitives, which are oriented around raw byte streams or blocks, but generally not standard encapsulation methods: •Base-64 encoding (“ASCII armor"), generating and reading printable representation of binary data, for example, encountered in certificates •Conversions between ASCII and non-ASCII data (such as EBCDIC), non-cryptographic but potentially modifying security-relevant data. Format conversion services do not provide cryptographic functionality, but may use other services if the transport mechanism requires them. As an example, if signed data is represented as a standard ASN.1 structure, it implicitly uses one of the sign calls. Similarly, certificate management or processing of PKCS#7 data may involve signature verifications, for example. © Copyright IBM Corp. 2012 Page 6 of 17 z/VM Version 6 Release 1 System SSL Security Policy Table 5 Services and Access Service Cryptographic If approved, Cryptographic keys and Types of Role Algorithms list Cert# CSPs Access Symmetric AES CBC Cert# 1873 128 or 256 bits AES Read/Write User encryption/decrypti (based on FIPS 197) symmetric keys on Triple-DES Cert# 1217 168 bits Triple-DES symmetric keys Asymmetric Key DSA Key/Parameter Cert# 586 DSA public and private Write User Generation Generation keys, 1024 bits (based on FIPS 186-2) modulus RSA Key Generation Cert# 953 RSA public and private (based on ANSI X9.31) keys, 1024 to 4096 bits modulus Digital Signature DSA Sign/Verify Cert# 586 DSA private key and Read User (based on FIPS 186-2) public key, 1024 bits modulus RSA Sign/Verify (based Cert# 953 RSA public and private on PKCS#1) keys, 1024 to 4096 bits modulus RSA Key Wrapping RSA Encrypt/Decrypt No Cert#. RSA public and private Read User (based on PKCS#1) Allowed in keys, 1024 to 4096 bits FIPS-mode. modulus Key Agreement Diffie-Hellman (DH) No Cert#. DH public and private Read/Write User Allowed in keys, 2048 bits FIPS-mode. modulus Secure Hashing SHA-1 Cert# 1646 None N/A User SHA-224 SHA-256 SHA-384 SHA-512 (based on FIPS 180-3) Message HMAC-SHA1 Cert# 1117 HMAC-SHA-1 key Authentication (based on FIPS 198, Write User 198a) HMAC-MD5 No Cert#. HMAC-MD5 key Only used in TLS Random Number RNG (based on FIPS Cert# 982 Seed Write User Generation 186-2) CPACF symmetric AES CBC Cert# 976 128 or 256 bits AES Read/Write User encryption/decrypti (based on FIPS 197) symmetric keys on Triple-DES Cert# 769 168 bits Triple-DES keys CPACF Secure SHA-1 Cert# 946 None N/A User Hashing SHA-224 SHA-256 SHA-384 © Copyright IBM Corp. 2012 Page 7 of 17 z/VM Version 6 Release 1 System SSL Security Policy SHA-512 (based on FIPS 180-3) Other services/functions (Not allowed in FIPS-mode/Not FIPS Approved) Service Notes Approved DES encryption/decryption Software No RC2 encryption/decryption Software No ArcFour encryption/decryption Software No MD2 Software No MD5 Software No DES CPACF No © Copyright IBM Corp. 2012 Page 8 of 17 z/VM Version 6 Release 1 System SSL Security Policy Table 6 Queries Service Notes Roles Module Status Officer User Query mode Check if module is in FIPS 140-2 mode Yes Yes Integrity Checks Power-up Tests Automatic before first use (yes) No Self-Tests DLL verification self-test. Self-tests can be Yes Yes done by stopping and restarting the appropriate server. Operational Correctness Checks RNG Tests Continuously performed (automatic) Yes Yes Pair-wise Continuously performed (automatic) Yes Yes consistency 6.Operational Environment Installation and Invocation System SSL is installed as part of the z/VM Version 6 Release 1 SDO. The evaluated version of System SSL requires the installation of service provided through APAR PM43382. The cryptographic modules are invoked via specific IBM programs. All other programs attempting to access the cryptographic modules will abend. These authorized programs are the z/VM SSL Server, the z/VM LDAP server and client utilities, the gskkyman utility (certificate management) and the gsktrace utility (debugging utility). Module Operation The System SSL security module is written in C, with certain functionality contained within assembler, such as functions that utilize the CPACF. Extensive internal consistency checks verify both user input and library configuration, terminating early if errors are encountered. Internal errors are externalized and do not terminate execution, since the code has been developed mainly for library use. Since System SSL can access certain platform-specific functionality, which is not represented in higher-level languages, System SSL uses a mixture of high-level and platform-specific native code. Using z/VM System SSL in a FIPS 140-2 approved manner assumes that the following defined criteria are followed: •The Operating System enforces authentication method(s) to prevent unauthorized access to Module services. •All host system components that can contain sensitive cryptographic data (main memory, system bus, disk storage) must be located within a secure environment. •The application using the module services must consist of one or more processes in which each process is utilizing a separate copy of the executable code. •The unauthorized reading, writing or modification of the virtual machine which contains the System SSL © Copyright IBM Corp. 2012 Page 9 of 17 z/VM Version 6 Release 1 System SSL Security Policy instance is not allowed. •An instance of the System SSL Library DLLs must be accessed only by a single process (virtual machine). This means that each process has it own instance of the System SSL Library DLLs. •The System SSL module must be initialized to execute in the FIPS 140-2 mode of operation. •The CP Assist for Cryptographic Functions DES/TDES Enablement Feature 3863 must be installed and enabled. This module implements both approved and non-approved services. The calling application controls the invocation of the services and the cryptographic material being supplied or used by the services. In FIPS 140-2 mode, the module only allows approved algorithms to be used in addition to RSA/Diffie-Hellman for key establishment and exchange. The FIPS 140-2 configuration automatically inhibits parameter combinations that are technically possible, but not permitted in FIPS 140-2 mode. The System SSL DLLs and gskkyman certificate utility represent the logical boundary of the module. The physical cryptographic boundary for the module is defined as the enclosure of the host on which the cryptographic module is to be executed. As shown in Figure 1, System SSL Cryptographic Module, the cryptographic module’s DLLs are instantiated within an application’s virtual machine. Each operating system component that utilizes the System SSL cryptographic module will create a new instance of the z/VM System SSL DLLs. Figure 1: System SSL Cryptographic Module © Copyright IBM Corp. 2012 Page 10 of 17 z/VM Version 6 Release 1 System SSL Security Policy 7.Key Management Key Storage The System SSL library retains key material within its virtual machine. In a typical SSL/TLS setting, private keys would be imported from a different key store. Public keys (certificates) would be distributed through other channels, such as out-of-band PKI messages. The module provides key import and export routines to applications such that key material can be used in conjunction with cryptographic services. It is the responsibility of applications using library services to ensure that these services are used in a FIPS 140-2 compliant manner. Keys managed or generated by applications or libraries may be passed from applications to the module in the clear, provided that the sending application or library exists within the physical boundary of the host computer. Key material resides in memory as clear data or in a standard key store format. The most frequently used standard formats, using passphrase-derived keys such as PKCS#12, are classified as clear-key storage according to FIPS Pub 140-2 guidelines. Key Generation Key Generation uses an approved RNG algorithm (specified in FIPS Pub 186-2) which is based on SHA-1. The DRNG has a maximum number of internal states of 2160, this maximum number reflecting the limitation of the compression function in SHA-1. RSA DSA and DH key generation algorithms use the DRNG engine seeded with 20 bytes of true random data. This true random number generator extracts entropy from time measurement jitter (minute variations of clock edges). The internal TRNG engine feeds entropy on demand into the DRNG; the TRNG itself maintains a running pool of samples, and provides seed if the pool passes basic entropy content checks. DSA key generation is done according to FIPS Pub 186-2. RSA key generation only implements the ANSI X9.31 key generation method [2]. Key Establishment When in FIPS 140-2 mode, the module provides support for asymmetric key establishment methods as allowed by Annex D in the FIPS Pub 140-2. The supported asymmetric key establishment methods are RSA Key Wrapping and Diffie-Hellman (DH) key agreement. When using Diffie-Hellman in FIPS 140-2 mode, the allowed modulus length is 2048 bits, which provides 112 bits of encryption strength. When using RSA Encrypt/decrypt in FIPS 140-2 mode, the allowed modulus lengths must be between 1024 and 4096 bits which provides between 80 and 150 bits of encryption strength. Key Entry and Key Exit The module does not support manual key entry or intermediate key generation key output. The module does not output or input keys outside of the physical boundary, with the exception of secret keys that are used for key establishment. The secret keys are wrapped with RSA. Key Protection To enforce compliance with FIPS Pub 140-2 key management requirements on the System SSL library itself, code issuing calls must manage keys in a FIPS Pub 140-2 compliant method. Keys managed or generated by applications may be passed from the application to the module in the clear in the FIPS Pub 140-2 validated configuration. The management and allocation of memory is the responsibility of the operating system. It is assumed that a unique process is allocated for each request, and that the operating system and the underlying hardware © Copyright IBM Corp. 2012 Page 11 of 17 z/VM Version 6 Release 1 System SSL Security Policy control access to the virtual machine which contains the process that uses the module. Each instance of the cryptographic module is self-contained within a process; the library relies on such process separation and address separation to maintain confidentiality of secrets. All platforms used during FIPS Pub 140-2 validation provide per-process protection for user data. Keys stored internally within the address range of System SSL are similarly separated logically (even if they reside in the same virtual machine). All keys are associated with the User role. It is the responsibility of application program developers to protect keys exported from the System SSL module. Key Destruction Applications must destroy persistent key objects and similar sensitive information using FIPS Pub 140-2 compliant procedures. The System SSL library itself does not destroy externally stored keys and secrets, as it does not own or discard persistent objects. Objects, when released on behalf of a caller, are erased before they are released. 8.Physical Security The System SSL installation inherits the physical characteristics of the host running it. The System SSL library has no physical security characteristics of its own. The CP Assist for Cryptographic Function (CPACF) offers the full complement of the Triple DES algorithm, Advanced Encryption Standard (AES) algorithm and Secure Hash Algorithm (SHA). CPACF Physical Design: Each two microprocessors (cores) on the quad-core chip share a Co-Processor Unit (CoP), which implements the crypto instructions and also provides the hardware compression function. The compression unit is integrated with the CP Assist for Cryptographic Function (CPACF), benefiting from combining (sharing) the use of buffers and interfaces. The CoP is located on the processor die and is connected to two cores and to L2 cache with dedicated buses. The CP Assist for Cryptographic Function (CPACF) accelerates the encrypting and decrypting of SSL transactions and VPN-encrypted data transfers and data-storing applications. The assist function uses a special instruction set for symmetrical clear key cryptographic encryption and encryption operations. Five special instructions are used with the cryptographic assist function. 9.EMI/EMC EMI/EMC properties of System SSL are not meaningful for the library itself. Systems utilizing the System SSL library services have their overall EMI/EMC ratings determined by the host system. The validation environments have FCC Class A ratings. 10.Self-Tests The System SSL library implements a number of self-tests to check proper functioning of the module including power-up self-tests and conditional self-tests. Conditional tests are performed when symmetric or asymmetric keys are generated. These tests include a continuous random number generator test and pair-wise consistency tests of the generated DSA or RSA keys. Startup Self-Tests “Power-up" self-tests consist of software integrity test(s) and known-answer tests of algorithm implementations. The module integrity test is automatically performed during loading. If any of these tests fail, the module will terminate the loading process. The module cannot be used in this state. © Copyright IBM Corp. 2012 Page 12 of 17 z/VM Version 6 Release 1 System SSL Security Policy The integrity of the module is verified by checking a SHA-256-based hash value of each module binary prior to being utilized in FIPS 140-2 compliant mode. Initialization will only succeed if all utilized module hash values are verified successfully. Module hash values are generated during the final phase of the build process. Algorithm known answer tests are performed when the authorized application invokes cryptographic modules to define FIPS 140-2 compliant mode and prior to any cryptographic algorithms being executed in FIPS 140-2 mode. The module tests the following cryptographic algorithms: AES, TDES, RSA (sign/verify, encrypt/decrypt), DSA (sign/verify), SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, HMAC-SHA-1, and the RNG. Self-tests are performed in logical order, verifying library integrity incrementally: 1. Integrity test on library, using SHA-256 2. Known-answer tests on algorithms, from integrity-verified binary. The integrity check process covers all constituent DLLs. DLLs are individually hashed and verified. Startup Recovery If any of the startup self-tests fail, System SSL will terminate FIPS 140-2 processing. Conditional Self-Testing Conditional self-testing includes continuous RNG testing. Continuous RNG testing involves comparing every newly-generated RNG block with the previously-generated one. The first output block generated by RNG is used only for the purpose of initiating the continuous RNG test. The test fails if the RNG outputs the same value twice subsequently. If the RNG outputs identical, subsequent pseudo-random blocks, it enters an error state and returns the corresponding status. The calling application must recognize this error and handle it in a FIPS 140-2 appropriate manner, for example, by reinitializing the library instance. Similar to the RNG, high-entropy seed extracted by the TRNG is checked for repeated blocks, before seeding the RNG. If blocks of entropy repeat, the TRNG reports a failure, which caller applications must also handle as an error. Pair-wise Consistency Checks This test is run whenever the module generates a private key. The private key structure always contains either the data of the corresponding public key or information sufficient for computing the corresponding public key. If the pair-wise consistency check fails, the module enters an error state and returns an error status code. The calling application must recognize this error and handle it in a FIPS 140-2 appropriate manner, for example, by reinitializing the library instance. Invoking FIPS 140-2 self-tests on demand. If a user can access System SSL services, the library has passed its integrity and power-up self tests. If a KAT failure is encountered, the module enters an error state and returns an error status code. The calling application must recognize this error and handle it in a FIPS 140-2 appropriate manner, for example, by reinitializing the library instance. © Copyright IBM Corp. 2012 Page 13 of 17 z/VM Version 6 Release 1 System SSL Security Policy 11.Operational Requirements (Officer/User Guidance) 11.1 Module Configuration for FIPS 140-2 Compliance To verify FIPS 140-2 compliant usage, the following requirements must be observed: •The Operating System (OS) hosting the library must be set up in accordance with FIPS Pub 140-2 rules. It must provide sufficient separation between processes to prevent inadvertent access to data of different processes. (This requirement was met for all platforms tested during validation.) •An instance of the module must not be used by multiple callers simultaneously such that they might interfere with each other. Note that for keys retained in caller-provided storage, this requirement is automatically met if the OS provides sufficient process separation (since the ownership of each memory region, therefore, each object, is uniquely determined.) •Applications using System SSL services must verify that ownership of keys is not compromised, and keys are not shared between different users of the calling application. Note that this requirement is not enforced by the System SSL library itself, but by the application providing the keys to System SSL. •Applications utilizing System SSL services must avoid using non-approved algorithms or modes of operation. If not feasible, the applications must indicate that they utilize non-approved cryptographic services. •To be in FIPS 140-2 mode, the System SSL installation must run on a host with commercial grade components and must be physically protected as prudent in an enterprise environment. oPhysical assumptions The module is intended for application in user areas that have physical control and monitoring. It is assumed that the following physical conditions will exist: LOCATION oThe processing resources of the module will be located within controlled access facilities that will prevent unauthorized physical access. PROTECTION oThe module hardware and software critical to security policy enforcement will be protected from unauthorized physical modification. o Personnel assumptions It is assumed that the following personnel conditions will exist: MANAGE oThere will be one or more competent individuals assigned to manage the module and the security of the information it contains. NO EVIL ADMINISTRATOR oThe system administrative personnel are not careless, willfully negligent, or hostile, and will follow and abide by the instructions provided by the administrator documentation. CO-OPERATION oAuthorized users possess the necessary authorization to access at least some of the information managed by the module and are expected to act in a cooperative manner in a benign environment. © Copyright IBM Corp. 2012 Page 14 of 17 z/VM Version 6 Release 1 System SSL Security Policy 11.2 Determining Mode of Operation The module provides a query function which will start indicating FIPS 140-2 mode after all self tests are successfully completed. Another function is provided which allows callers to switch into non-FIPS 140-2 mode. To return to FIPS 140-2 mode after a mode change, the application must re-instantiate the library or executable (i.e., reload it). Applications utilizing services must enforce key management compliant with FIPS Pub 140-2 requirements. This should be indicated in an application-specific way that is directly observable by administrators and end- users. While such application-specific details are outside the scope of the validation, they are mentioned here for completeness. In FIPS 140-2 mode, the module automatically restricts algorithms usage to approved or allowed algorithms and inhibits parameter combinations that are technically legal but outside standardized range (such as nonstandard DSA key sizes, short HMAC keys, etc.). 11.3 Testing/Physical Security Inspection Recommendations In addition to automatic tests, which are described elsewhere in this document, System SSL users may invoke FIPS 140-2 mode self-tests at any time. These self-tests are initiated through a dedicated function which is invoked automatically at startup. Continuous tests reside within their respective functions and are called implicitly during the function processing. These tests are not observable unless a failure is detected. Apart from prudent security practice of server applications and those of security-critical embedded systems, no further restrictions are placed on hosts utilizing these services. 12. Mitigation of Other Attacks The Mitigation of Other attacks security section of FIPS 140-2 is not applicable to the System SSL cryptographic module. 13. Glossary Control Program. A component of z/VM that manages the resources of a single computer so that CP multiple computing systems appear to exist. Each apparent system, or virtual machine, is the functional equivalent of the real computer, and CP simulates the real machine architecture in the virtual machine. CP Assist for Cryptographic Function, clear key on-chip accelerator integrated into mainframe CPACF processors. CPACF functionality is restricted to symmetric and hashing operations. Dynamic Link Library, shared program library instantiated separately from binaries using it. FIPS 140-2 DLL configurations of System SSL DLLs are never statically linked. DRNG Deterministic Random Number Generator, a deterministic function expanding a “true random” seed to a pseudo-random sequence. © Copyright IBM Corp. 2012 Page 15 of 17 z/VM Version 6 Release 1 System SSL Security Policy In the z/VM Language Environment, a collection of routines, one of which is named as the main Enclave routine. The enclave contains at least one thread. Multiple enclaves may be contained within a process. Known Answer Test KAT Operating System OS A collection of resources; both program code and data, consisting of at least one enclave. Process Prepackaged version of the z/VM Operating System SDO The functions and variables that can be imported by DLL applications. Side deck An execution construct that consists of synchronous invocations and terminations of routines. Thread The thread is the basic run_time path within the z/VM Language Environment program management model, and is dispatched by the operating system with its own run-time stack, instruction counter and registers. A thread may exist concurrently with other threads within a virtual machine. TRNG True Random Number Generator, a service that extracts cryptographically-useful random bits from non-deterministic (physical) sources. The “random seed” bits are post-processed by a DRNG. The simulation of a device by CP. Virtual Device The virtual processors, virtual storage, and virtual devices that CP allocates to a single Virtual Machine user. A virtual machine also includes any expanded storage dedicated to it. Virtual Processor A representation of a processor that is dispatched by CP on a real processor. It includes the contents of all registers and the state of the processor. Storage space that can be regarded as addressable main storage by the user of a Virtual Storage computer system in which virtual addresses are mapped into real addresses. 14.References [1] National Institute of Standards and Technology, Security Requirements for Cryptographic Modules (FIPS 140-2), 2002 [2] American National Standard Institute, Digital Signatures Using Reversible Public Key Cryptography for the Financial Services Industry (X9.31), 1998 15.Trademarks The following terms are trademarks of the IBM Corporation in the United States or other countries or both: •IBM •z10 © Copyright IBM Corp. 2012 Page 16 of 17 z/VM Version 6 Release 1 System SSL Security Policy •z196 •z/VM © Copyright IBM Corp. 2012 Page 17 of 17