FIPS PUB 140-2 Security Policy for SAP NW SSO 2.0 Secure Login Library Crypto Kernel Document version: 1.4 Date: 2014-12-22 FIPS 140-2 SECURITY POLICY – SAP NW SSO 2.0 SECURE LOGIN LIBRARY CRYPTO KERNEL TABLE OF CONTENT 1 CRYPTOGRAPHIC MODULE DESCRIPTION ................................................................................. 4 1.1 Overview ........................................................................................................................................... 4 1.2 Architecture ...................................................................................................................................... 5 1.3 Usage ................................................................................................................................................. 5 1.4 Supported platforms ........................................................................................................................ 7 1.5 Logical and cryptographic boundary ............................................................................................. 8 2 SECURITY LEVEL............................................................................................................................. 9 3 APPROVED MODE OF OPERATION ............................................................................................. 10 4 CRYPTOGRAPHIC MODULE SECURITY POLICY ....................................................................... 11 4.1 Roles ................................................................................................................................................ 11 4.2 Services ........................................................................................................................................... 11 4.3 Cryptographic keys and other CSPs ............................................................................................ 11 4.4 Identification and authentication (I&A) policy ............................................................................. 11 4.5 Access control policy .................................................................................................................... 12 4.6 Physical security policy ................................................................................................................ 14 4.7 Security policy for mitigation of other attacks ............................................................................ 14 5 REFERENCES ................................................................................................................................. 15 2 FIPS 140-2 SECURITY POLICY – SAP NW SSO 2.0 SECURE LOGIN LIBRARY CRYPTO KERNEL This document contains the non-proprietary Security Policy according to FIPS PUB 140-2 for the cryptographic module “SAP NW SSO 2.0 Secure Login Library Crypto Kernel” in its version v2.0.0.1.32. The cryptographic module is a shared library providing various cryptographic functions, which has been validated according to overall Security Level 1 on various platforms (see section 1.5 hereinafter). 3 FIPS 140-2 SECURITY POLICY – SAP NW SSO 2.0 SECURE LOGIN LIBRARY CRYPTO KERNEL 1 CRYPTOGRAPHIC MODULE DESCRIPTION 1.1 Overview The cryptographic module is the “SAP NW SSO 2.0 Secure Login Library Crypto Kernel” in its version v2.0.0.1.32. It is a shared library, i.e. it consists of software only. On Windows platforms the cryptographic module consists of the dynamic link library file slcryptokernel.dll accompanied by the file slcryptokernel.dll.sha256 containing a HMAC-SHA-256 reference value for the software/firmware integrity test. On Linux and UNIX based platforms it consists of the shared library file accompanied by the file libslcryptokernel., libslcryptokernel. .sha256 containing the HMAC-SHA-256 reference value for the software/firmware integrity test (where “” stands for the OS-specific extension for shared libraries; extensions are “dylib“ for Mac OS, “sl“ for HP-UX, and “so” or “o” for the other Linux/Unix operating systems used). The cryptographic module provides an API in terms of C++ methods for key management and operation of the following cryptographic functions: Approved cryptographic functions · AES symmetric cipher encryption and decryption according to [FIPS 197], supporting key lengths 128 bit, 192 bit and 256 bit · Triple-DES (3TDES, i.e. using key length 168 bit, and 2TDES, i.e. using key length 112 bit) symmetric cipher encryption and decryption according to [SP 800-67] · Support of block cipher modes of operation CBC, CTR, ECB, OFB and CFB according to [SP 800- 38A], CBC-CS according to [SP 800-38A Add] and GCM according to [SP 800-38D] · DSA signature generation and verification according to [FIPS 186-3] · RSA signature generation and verification according to [FIPS 186-3] (supporting signature schemes RSASSA-PSS and RSASSA-PKCS1-V1_5 from [PKCS#1 V2.1]) · HMAC generation according to [FIPS 198-1] using any of the Approved hash functions listed below · CTR_DRBG (using AES-256) deterministic random number generation according to [SP 800-90A] and key generation for all of the approved cryptographic functions listed above · SHA-1, SHA-224, SHA-256, SHA-384 and SHA-512 hash functions according to [FIPS 180-4] Non-Approved cryptographic functions · IDEA, RC2, RC5-32 symmetric cipher encryption and decryption · RC4 stream cipher encryption and decryption · Diffie-Hellman (key agreement; key establishment methodology provides between 112 and 256 bits 1 of encryption strength; non-compliant less than 112 bits of encryption strength ) · ElGamal (key wrapping) · RSA (key wrapping; key establishment methodology provides between 112 and 256 bits of 1 encryption strength; non-compliant less than 112 bits of encryption strength ) · MD2, MD4, MD5, RIPEMD-128 and RIPEMD-160 hash functions · Non-deterministic random number generation by entropy collection (used for generation of seeds for for the Approved random number generator listed above) 1 The module supports arbitrary encryption strengths for Diffie-Hellman key agreement and RSA key wrapping. 4 FIPS 140-2 SECURITY POLICY – SAP NW SSO 2.0 SECURE LOGIN LIBRARY CRYPTO KERNEL 1.2 Architecture To be able to provide its cryptographic services, the cryptographic module is subdivided as follows: Figure 1: Block diagram of the cr yp tographic module 1.3 Ports and interfaces of the module As the cryptographic module is a software library, its logical interfaces are realized in terms of a set of APIs, which are shown in Figure 1 hereinabove. All functionality of the cryptographic module is made available to the calling application (i.e. the user of the cryptographic module) in terms of exported API functions. Some of the API functions are also used internally, e.g. the self-test service makes use of some of those API functions when performing cryptographic algorithm self-tests. For a full reference of all API functions please see guidance document “FIPS PUB 140-2 Cryptographic Ports and Interfaces of SAP NW SSO 2.0 Secure Login Library Crypto Kernel” as provided by SAP AG together with the cryptographic module. In the meaning of FIPS 140-2 the cryptographic module is of type multiple-chip standalone, therefore the physical ports of the module are identical to the ports (e.g. power port, data input/output ports) of the system the cryptographic module is used on. 1.4 Usage The cryptographic module is used by a single operator, which is the application using the library by calling its methods. The module does not employ functions for identification and authentication of its operator. It supports a crypto officer role and a user role, whereas the crypto officer role is authorized to load and initialize the cryptographic module, and the user role is authorized to perform cryptographic operations. The 5 FIPS 140-2 SECURITY POLICY – SAP NW SSO 2.0 SECURE LOGIN LIBRARY CRYPTO KERNEL roles are implicitly selected by the calling application in terms of methods being called. Typically, the cryptographic module is used by the “SAP NW SSO 2.0 Secure Login Library”, which itself is a library providing cryptographic protocols and services to an application using it. The cryptographic module in context of the other parts of the “SAP NW SSO 2.0 Secure Login Library” is shown in the following figure. Please take note that the cryptographic module can also be used without the other parts of the “SAP NW SSO 2.0 Secure Login Library”, i.e. it can also be used directly by an application. Figure 2: The cr yptog raph ic module (indicated b y r e d frame) in th e context o f S AP NW SSO 2.0 Secure Login Librar y 6 FIPS 140-2 SECURITY POLICY – SAP NW SSO 2.0 SECURE LOGIN LIBRARY CRYPTO KERNEL 1.5 Supported platforms The cryptographic module can be used on a great variety of different platforms (i.e. in different operational environments in the meaning of FIPS 140-2). It has been tested and validated on the following platforms: Operating system OS versions Processor Crypto Module Executable AIX 64-bit 5.1, 5.2, 6.1 PowerPC 32-bit and 64-bit HPUX PA-RISC 64-bit 11.00, 11.11, 11.31 PA-RISC 32-bit and 64-bit HPUX ia64 64-bit 11.23, 11.31 IA64 64-bit Linux intel 32-bit 2.4.18, 2.4.21, 2.6.5, 2.6.27 X86 32-bit Linux ia64 64-bit 2.4.19, 2.6.5 IA64 64-bit Linux Power 64-bit 2.6.5, 2.6.16, 2.6.32 PowerPC 64-bit Linux x86_64 64-bit 2.6.16, 2.6.32 X86_64 without AES-NI 64-bit 2.6.32 X86_64 with AES-NI 32-bit and 64-bit Linux zSeries 64-bit 2.6.5 z/Architecture (s390x) 64-bit Mac OS X 64-bit 10.7 X86_64 32-bit, 64-bit and 32/64-bit cross platform executable Windows x86 64-bit Windows Server 2008 R2 X86_64 without AES-NI 32-bit and 64-bit Windows 7 SP1 X86_64 with AES-NI 32-bit and 64-bit True64 Unix 64-bit 5.1 DEC Alpha 64-bit Solaris SPARC 64-bit 5.8, 5.9, 5.10 SPARC 32-bit and 64-bit Solaris x64 64-bit 5.10 X86_64 32-bit and 64-bit For further details please see the list of test configurations for the SAP NW SSO 2.0 Secure Login Library Crypto Kernel v2.0.0.1.32 at http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm. 7 FIPS 140-2 SECURITY POLICY – SAP NW SSO 2.0 SECURE LOGIN LIBRARY CRYPTO KERNEL Logical and cryptographic boundary The logical boundary of the module encloses the shared library (including its executable code and data). The physical boundary, i.e. the “cryptographic boundary” of the module as defined by FIPS PUB 140-2 is made up by the housing of the workstation or server hardware the cryptographic module is running on, i.e. in the meaning of FIPS PUB 140-2 the cryptographic module has got the type “multiple chip standalone”. 8 FIPS 140-2 SECURITY POLICY – SAP NW SSO 2.0 SECURE LOGIN LIBRARY CRYPTO KERNEL 2 SECURITY LEVEL The cryptographic module fulfills overall Security Level 1 according to FIPS PUB 140-2. The ratings of the individual requirement sections are as follows: Requirement section of FIPS PUB 140-2 Rating Cryptographic Module Specification Security Level 1 Cryptographic Module Ports and Interfaces Security Level 1 Roles, Services and Authentication Security Level 1 Finite State Model Security Level 1 Physical Security Not applicable Operational Environment Security Level 1 Cryptographic Key Management Security Level 1 EMI/EMC Security Level 1 Self-Tests Security Level 1 Design Assurance Security Level 1 Mitigation of Other Attacks Not applicable 9 FIPS 140-2 SECURITY POLICY – SAP NW SSO 2.0 SECURE LOGIN LIBRARY CRYPTO KERNEL 3 APPROVED MODE OF OPERATION The cryptographic module implements several non-Approved cryptographic functions as listed in section 1.1 hereinabove, but it does not technically enforce an Approved mode of operation (also known as FIPS mode), which would disable these non-Approved functions. Instead, the operator has to obey the following instructions to operate the cryptographic module in its Approved mode (i.e. the developer of the application using the cryptographic module has to obey these): · None of the “Non-Approved cryptographic functions” listed in section 1.1 hereinabove shall be used in the Approved mode of operation (unless it is part of an allowed cryptographic function, like MD5 as part of SSL v3.1 or TLS) · Triple-DES encryption using 112 bit keys (2TDES) is restricted: the total number of blocks of data 20 encrypted with the same cryptographic key shall not be greater than 2 . After December 31, 2015 Triple-DES using 112 bit keys (2TDES) shall not be used for encryption at all any longer. · RSA signature generation shall only be used with modulus size supporting between 112 and 256 bit of encryption strength (see NIST SP 800-57 part 1, table 2 for corresponding key lengths) in the Approved mode of operation. · DSA signature generation shall only be used with private key size supporting between 112 and 256 bit of encryption strength (see NIST SP 800-57 part 1, table 2 for corresponding key lengths) in the Approved mode of operation. · SHA-1 shall not be used for digital signature generation or hash-only applications in the Approved mode of operation (SHA-1 may be used applications in the Approved mode of operation for digital signature verification and keyed hashing, i.e. HMAC). · Diffie-Hellman key agreement and RSA key wrapping are allowed functions in the Approved mode of operation as long as these are used with key lengths supporting between 112 bit and 256 bit of encryption strength (see NIST SP 800-57 part 1, table 2 for corresponding key lengths). 10 FIPS 140-2 SECURITY POLICY – SAP NW SSO 2.0 SECURE LOGIN LIBRARY CRYPTO KERNEL 4 CRYPTOGRAPHIC MODULE SECURITY POLICY 4.1 Roles The cryptographic module supports the minimum two roles as required by FIPS PUB 140-2, this is a · crypto officer role (allowed to load, initialize and power-up self-test the module), and a · user role (allowed to perform cryptographic operations including related key entry and output). As the cryptographic module does not allow the operator to perform maintenance services, it does not support a maintenance role. 4.2 Services The services employed by the cryptographic module are as follows: · Loading · Initialization · Power-up and conditional self-tests · Block cipher encryption and decryption · Signature generation and verification · HMAC generation · Random number generation and key generation · Cryptographic hashing · Zeroization (no corresponding API call; implicitly performed when key objects are deleted) · Show status · Asymmetric encryption and decryption · Key exchange All services above, which use cryptographic functions, may be Approved or non-Approved, depending on whether an Approved or non-Approved function is used (only the asymmetric encryption/decryption and the key exchange are always non-Approved). 4.3 Cryptographic keys and other CSPs According to the cryptographic functions supported by the module the following keys are supported by the cryptographic module in its Approved mode of operation: · AES-128, AES-192- and AES-256 keys · Triple-DES (3TDES and 2TDES) keys · RSA private and public keys · DSA private and public keys · HMAC keys There are no other CSPs (e.g., authentication secrets or similar) supported by the cryptographic module. 4.4 Identification and authentication (I&A) policy The cryptographic module does not implement operator identification and authentication mechanisms. Crypto officer role and user role are implicitly selected by the operator in terms of the API call used to perform the corresponding service. 11 FIPS 140-2 SECURITY POLICY – SAP NW SSO 2.0 SECURE LOGIN LIBRARY CRYPTO KERNEL 4.5 Access control policy The following tables list the services, which the roles are authorized to perform in the Approved mode of operation, as well as the cryptographic keys and other CSPs, which are accessed while the services are performed in the Approved mode of operation. Role Authorized Services · Crypto officer Loading · Initialization · Power-up self-tests · User Block cipher encryption/decryption · Signature generation/verification · HMAC generation · Key generation · Export and import of cryptographic objects · Hashing · Conditional self-tests · Zeroization (no corresponding API call; implicitly performed when key objects are deleted) Service Accessed cryptographic keys Type(s) of access Loading None Initialization None Self-test None Block cipher AES-128/192/256 key, or Write, Execute encryption/decryption Triple-DES (3TDES or 2TDES) key Signature generation RSA private key, or Write, Execute DSA private key Signature verification RSA public key, or Write, Execute DSA public key HMAC generation HMAC key Write, Execute Key generation Any of the keys listed above Write Key export Any of the keys listed above Read Hashing None Zeroization Any of the keys listed above Write (overwrite) The self-test service includes the following set of self-tests (in the following “KAT” denotes to “known-answer test”): Power-up self-tests: · Software/firmware integrity, tested by verification of a HMAC-SHA-256; · AES-128, AES-192 and AES-256, each tested by a KAT for encryption and a KAT for decryption; · Triple-DES, tested by a KAT for encryption and a KAT for decryption; 12 FIPS 140-2 SECURITY POLICY – SAP NW SSO 2.0 SECURE LOGIN LIBRARY CRYPTO KERNEL · RSA signature generation and verification, tested by a KAT for signature generation and a subsequent verification; · DSA signature generation and verification, tested by a pairwise consistency test; · CTR_DRBG, tested by a KAT; · SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 (and all non-approved hash functions as well), each tested by a KAT; · HMAC generation, tested by a KAT. Conditional self-tests: · CTR_DRBG, tested by a continuous random number generator test; · Entropy source provided by the platform, tested by a continuous random number generator test (only applicable while seeding the CTR_DRBG); · RSA key pair generation, tested by two pairwise consistency tests (signature generation and verification as well as encryption and decryption using the generated key pair); · DSA key pair generation, tested by a pairwise consistency tests (signature generation and verification using the generated key pair); · ElGamal key pair generation, tested by a pairwise consistency test (encryption and decryption using the generated key pair). In case of a failure in at least one of the power-up self-tests the cryptographic module returns an error code to the application that tried to load and initialize the module, and none of the services of the module are available to the application in this case. In case of a failure during a conditional self-test the cryptographic module returns an error code to the application that tried to perform a corresponding function. Access of the application to random numbers or key pairs generated that caused the conditional self-test error is inhibited in this case. 13 FIPS 140-2 SECURITY POLICY – SAP NW SSO 2.0 SECURE LOGIN LIBRARY CRYPTO KERNEL 4.6 Physical security policy When run on one of the test platforms as indicated in section 1.5 hereinabove, the cryptographic module meets the physical security requirements of FIPS PUB 140-2 security level 1 (i.e. the hardware has to be production grade). No physical security mechanisms concerning tamper evidence or tamper detection and response are employed by the module, and therefore no actions are required by the operator(s) to ensure that physical security is maintained. 4.7 Security policy for mitigation of other attacks The cryptographic module does not implement measures to mitigate attacks other than those already addressed by functionality required by FIPS PUB 140-2 Security Level 1. 14 FIPS 140-2 SECURITY POLICY – SAP NW SSO 2.0 SECURE LOGIN LIBRARY CRYPTO KERNEL 5 REFERENCES [FIPS 140-2] NIST PUB 140-2, Security Requirements for Cryptographic Modules [FIPS 180-4] Federal Information Processing Standards Publication 180-4, Secure Hash Standard (SHS), March 2012 [FIPS 186-3] Federal Information Processing Standards Publication 186-3, Digital Signature Standard (DSS), June 2009 [FIPS 197] Federal Information Processing Standards Publication 197, Advanced Encryption Standard (AES), November 26, 2001 [FIPS 198-1] Federal Information Processing Standards Publication 198-1, The Keyed-Hash Message Authentication Code (HMAC), July 2008 [PKCS#1 V2.1] PKCS #1 v2.1: RSA Cryptography Standard, RSA Laboratories, June 14, 2002 [SP 800-38A] NIST Special Publication 800-38A, Recommendation for Block Cipher Modes of Operation, Methods and Techniques, December 2001 [SP 800-38A Add] Addendum to NIST Special Publication 800 -38A, Recommendation for Block Cipher Modes of Operation: Three Variants of Ciphertext Stealing for CBC Mode, October 2010 [SP 800-38D] NIST Special Publication 800-38D, Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC, November 2007 [SP 800-67] NIST Special Publication 800-67, Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher, Version 1.2, revised July 2011 [SP 800-90A] NIST Special Publication 800-90A, Recommendation for Random Number Generation Using Deterministic Random Bit Generators, January 2012 15 www.sap.com ©2013 SAP AG. All rights reserved. Copying and distribution of this document in the context of the Cryptographic Module Validation Program (CMVP) is allowed. SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP BusinessObjects Explorer, StreamWork, SAP HANA, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries. Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Business Objects Software Ltd. Business Objects is an SAP company. Sybase and Adaptive Server, iAnywhere, Sybase 365, SQL Anywhere, and other Sybase products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Sybase, Inc. Sybase is an SAP company. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.