Oracle Solaris Kernel Cryptographic Framework Software Version 1.0 and 1.1 FIPS 140-2 Non-Proprietary Security Policy Level 1 Validation Version 1.2 12/12/2013 © Copyright 2013 Oracle Corporation This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Table of Contents INTRODUCTION............................................................................................................ 3 PURPOSE ........................................................................................................................ 3 REFERENCES ................................................................................................................... 3 DOCUMENT ORGANIZATION .............................................................................................. 3 ORACLE SOLARIS KERNEL CRYPTOGRAPHIC FRAMEWORK 1.0 AND 1.1 .......... 4 OVERVIEW...................................................................................................................... 4 MODULE SPECIFICATION .................................................................................................. 5 MODULE INTERFACES ...................................................................................................... 8 ROLES AND SERVICES .................................................................................................... 10 Crypto-Officer Role ................................................................................................... 10 User Role .................................................................................................................. 11 PHYSICAL SECURITY ...................................................................................................... 12 OPERATIONAL ENVIRONMENT ......................................................................................... 12 CRYPTOGRAPHIC KEY MANAGEMENT .............................................................................. 12 SELF-TESTS .................................................................................................................. 17 Power-Up Self-tests ................................................................................................... 17 Conditional Self-tests ................................................................................................. 17 MITIGATION OF OTHER ATTACKS .................................................................................... 17 SECURE OPERATION ................................................................................................. 18 INITIAL SETUP ............................................................................................................... 18 CRYPTO-OFFICER GUIDANCE .......................................................................................... 18 Initialization .............................................................................................................. 19 Management ............................................................................................................. 19 Zeroization ................................................................................................................ 19 USER GUIDANCE ........................................................................................................... 19 ACRONYMS ................................................................................................................. 20 © Copyright 2013 Oracle Corporation Page 2 of 20 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Introduction Purpose This is a non-proprietary Cryptographic Module Security Policy for the Oracle Solaris Kernel Cryptographic Framework 1.0 and 1.1 from Oracle Corporation (Oracle). This Security Policy describes how the Solaris Kernel Cryptographic Framework 1.0 and 1.1 meets the security requirements of FIPS 140-2 (Federal Information Processing Standards Publication 140-2 — Security Requirements for Cryptographic Modules) and how to run the module in a secure FIPS 140-2 mode. This policy was prepared as part of the Level 1 FIPS 140-2 validation of the module. FIPS 140-2 details the U.S. Government requirements for cryptographic modules. More information about the FIPS 140-2 standard and validation program is available on the National Institute of Standards and Technology (NIST) Cryptographic Module Validation Program (CMVP) website at http://csrc.nist.gov/cryptval/. References This document deals only with operations and capabilities of the module in the technical terms of a FIPS 140-2 cryptographic module security policy. More information is available on the module from the following sources:  The Oracle Corporation website (http://www.oracle.com) contains information on the full line of products from Oracle.  The CMVP website (http://csrc.nist.gov/cryptval/) contains contact information for answers to technical or sales-related questions for the module. Document Organization The Security Policy document is one document in a FIPS 140-2 Submission Package. In addition to this document, the Submission Package contains:  Vendor Evidence document  Finite State Machine  Other supporting documentation as additional references With the exception of this Non-Proprietary Security Policy, the FIPS 140-2 Validation Documentation is proprietary to Oracle Corporation and is releasable only under appropriate non-disclosure agreements. For access to these documents, please contact Oracle Corporation. © Copyright 2013 Oracle Corporation Page 3 of 20 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. ORACLE SOLARIS KERNEL CRYPTOGRAPHIC FRAMEWORK 1.0 AND 1.1 Overview The Oracle Solaris 11 operating system (OS) is a highly configurable UNIX- based operating system that is optimized to quickly and securely deploy services in traditional enterprise data centers, large scale cloud environments and small personal desktop use. Oracle preserves the long-standing guarantee of binary compatibility – applications that run on previous Oracle Solaris releases can still run unchanged on Oracle Solaris 11 within the same processor architecture: x86 or SPARC1. The Oracle Solaris 11 OS can be installed on either x86 or SPARC hardware architectures or run in a virtualized environment. The operating system allows one or more processors and multiple hardware peripheral and storage devices to be accessed by multiple users in order to meet user requirements. Oracle Solaris 11 provides a suite of technologies and applications that create an operating system with optimal performance. Oracle Solaris 11 includes key technologies such as zones, ZFS file system, Image Packaging System (IPS), multiple boot environments, trusted extensions, and cryptographic framework. The Oracle Solaris 11 OS utilizes two cryptographic modules; one in the Userland space and the second in the Kernel space. The OS uses the Oracle Solaris Userland Cryptographic Framework module for cryptographic functionality for any applications running in user space. The Oracle Solaris Userland Cryptographic Framework exposes PKCS#112 API3s, uCrypto APIs, and libmd public interfaces to provide cryptography to any application designed to utilize it. The Oracle Solaris 11 OS also utilizes the Oracle Solaris Kernel Cryptographic Framework module to provide cryptographic functionality for any kernel-level processes that require it, via its Oracle-proprietary APIs. This document will focus solely on the Oracle Solaris Kernel Cryptographic Framework. The Oracle Solaris Userland Cryptographic Framework is discussed in another FIPS 140-2 Non-proprietary Security Policy. The module meets overall level 1 requirements for FIPS 140-2, and Table 1 describes the level achieved by the module in each of the eleven sections of FIPS 140-2 requirements. 1 SPARC – Scalable Processor Architecture 2 PKCS #11 – Public Key Cryptography Standards #11 3 API – Application Programming Interface © Copyright 2013 Oracle Corporation Page 4 of 20 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Section Section Title Level 1 Cryptographic Module Specification 1 2 Cryptographic Module Ports and Interfaces 1 3 Roles, Services, and Authentication 1 4 Finite State Model 1 5 Physical Security N/A 6 Operational Environment 1 7 Cryptographic Key Management 1 8 EMI/EMC 1 9 Self-tests 1 10 Design Assurance 1 11 Mitigation of Other Attacks N/A Table 1 – Security Level per FIPS 140-2 Section Module Specification The Oracle Solaris Kernel Cryptographic Framework is a software module with a multi-chip standalone embodiment. The overall security level of the module is level 1. The following sections will define the physical and logical boundaries of the module. The cryptographic module is a group of libraries that, collectively, are known as the Oracle Solaris Kernel Cryptographic Framework. The module provides cryptographic functionality for any application that calls into it. The module provides encryption, decryption, hashing, signature generation and verification, certificate generation and verification, and message authentication functions. The module can leverage the AES-NI4 instruction set, when operating on an Intel Xeon processor. Figure 1, below, is the logical block diagram for the module. It highlights the libraries that make up the module in orange, while illustrating the module boundary. 4 AES-NI – Advanced Encryption Standard – New Instructions © Copyright 2013 Oracle Corporation Page 5 of 20 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Kernel Processes Consumer Interface (Proprietary) kcf Provider Interface (Proprietary) aes des rsa ecc md5 sha1 sha2 swrand Bignum Kernel Space Hardware Processor (Intel Xeon, SPARC64) Legend Data Input / Data Control Input / Module Boundary Output Status Output Figure 1 - Oracle Solaris Kernel Cryptographic Framework Logical Block Diagram Figure 2 and Figure 3, below, show the hardware block diagrams for the GPCs5, utilizing Intel Xeon and SPARC64 processors that will execute the module. 5 GPC – General Purpose Computer © Copyright 2013 Oracle Corporation Page 6 of 20 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. DVD Hardware Network RAM Management Interface HDD Clock SCSI/SATA Generator Controller LEDs/LCD Serial CPU(s) I/O Hub Audio Cache PCI/PCIe Slots USB BIOS PCI/PCIe Power Graphics Slots Interface Controller External Power Supply KEY: BIOS – Basic Input/Output System LCD – Liquid-Crystal Display Plaintext data CPU – Central Processing Unity PCIe – PCI express Encrypted data SATA – Serial Advanced Technology Attachment HDD – Hard Disk Drive Control input SCSI – Small Computer System Interface DVD – Digital Versatile Disc Status output PCI – Peripheral Control Interface USB – Universal Serial Bus LED – Light-Emitting Diode RAM – Random Access Memory Crypto boundary Figure 2 – Intel Xeon-based GPC Hardware Block Diagram © Copyright 2013 Oracle Corporation Page 7 of 20 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Graphics DVD Controller SCSI/SATA Hypervisor Controller HDD Lights-Out Manager LEDs/LCD Clock Generator Serial I/O Hub Network CPU(s) Audio Interface USB Cache PCI/PCIe Power RAM Slots Interface External Power Supply KEY: I/O Hub – Input/Output Hub LCD – Liquid-Crystal Display Plaintext data CPU – Central Processing Unit PCIe – PCI Express Encrypted data SATA – Serial Advanced Technology Attachment HDD – Hard Disk Drive Control input SCSI – Small Computer System Interface DVD – Digital Video Disc PCI – Peripheral Component Interconnect Status output USB – Universal Serial Bus LED – Light-Emitting Diode RAM – Random Access Memory Crypto boundary Figure 3 – SPARC64-based GPC Hardware Block Diagram Module Interfaces The module can be accessed by utilizing the API it exposes. This API is an Oracle-proprietary consumer interface. Table 2, below, shows the interfaces provided by the module. Figure 4 and Figure 5, below, show the host appliances for the module. These diagrams show the physical ports that are available on the hardware. © Copyright 2013 Oracle Corporation Page 8 of 20 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Figure 4 – Sun Server X3-2 (formerly the Sun Fire X4170 M3 server) X3-2 Front and Rear Panel Ports (Intel- based) Figure 5 – M3000 Enterprise Server Front and Rear Panel Ports (SPARC64-based) FIPS 140-2 Logical Module Logical Interface Physical Port Interface M3000 – Ethernet, USB6, SAS7 port, Data Input Oracle-proprietary API Serial port (RJ8-45), UPC9 ports, RCI10 port, DVD11 optical drive Sun Server X3-2 – Ethernet, USB, Serial Port (RJ-45), DVD optical drive 6 USB – Universal Serial Bus 7 SAS – SCSI (Small Computer System Interface) Assisted Storage 8 RJ – Registered Jack 9 UPC – Usage Parameter Control 10 RCI – Remote Cabinet Interface 11 DVD – Digital Versatile Disc © Copyright 2013 Oracle Corporation Page 9 of 20 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. FIPS 140-2 Logical Module Logical Interface Physical Port Interface Data Output Oracle-proprietary API M3000 – Ethernet, USB, SAS port, Serial port (RJ-45) Sun Server X3-2 – Ethernet, USB, Serial Port (RJ-45) Control Input Oracle-proprietary API M3000 – Ethernet, USB, Power button Sun Server X3-2 – Ethernet, Serial (RJ- 45) USB, Power button, Locator button M3000 – Ethernet, USB, VGA12 port Status Output Oracle-proprietary API (HD13-15), status LEDs Sun Server X3-2 – LEDs, Serial (RJ-45), Ethernet, VGA port (HD-15) Power Input Not Applicable Power Supply Table 2 – FIPS 140-2 Logical Interfaces Roles and Services The module relies on the host OS for authentication. There are two roles in the module (as required by FIPS 140-2) that operators may assume: a Crypto Officer role and a User role. Crypto-Officer Role The Crypto-Officer is any operator on the host appliance with the permissions to utilize the external cryptoadm utility, or a program with the ability to access the module APIs. The Crypto-Officer role has the ability to enable and disable FIPS mode, check the status of the FIPS module, and configure cryptographic operations of the module, including which providers will be available. The Crypto-Officer is able to utilize these services via the cryptoadm commands. Descriptions of the services available to the Crypto-Officer role are provided in Table 3, below. The Crypto-Officer is also able to utilize all User services, described in Table 4. Please note that the keys and CSPs listed in the table indicate the type of access required using the following notation:  Read: The CSP is read.  Write: The CSP is established, generated, modified, or zeroized.  Execute: The CSP is used within an Approved or Allowed security function or authentication mechanism 12 VGA – Video Graphics Array 13 HD – High Density © Copyright 2013 Oracle Corporation Page 10 of 20 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. CSP14 Service Description Type of Access to CSP Run POST KATs on- Restarting the appliance will Crypto-Officer Execute demand force the FIPS self-tests to run credentials when the module is loaded. Calling the fips140_post() function will call the Power-On Self-Tests. Module Initialization Use external cryptoadm utility Crypto-Officer Execute to initialize the FIPS state. credentials Module Use external cryptoadm utility Crypto-Officer Execute Configuration to configure the module. credentials Zeroize keys Format operation on the host Crypto-Officer Execute appliance’s hard drive credentials Table 3 – Crypto-Officer Services The credentials for the Crypto-Officer are not considered CSPs, as requirements for module authentication are not enforced for Level 1 validation. The credentials are provided to the host OS, and are not part of the module. User Role The User role is able to utilize the cryptographic operations of the module, through its APIs. Descriptions of the services available to the User role are provided in Table 4, below. Service Description CSP Type of Access to CSP AES15 key Symmetric Encrypt a block of data using a Execute Triple DES16 key encryption symmetric algorithm Symmetric Decrypt a block of data using a AES key Execute decryption symmetric algorithm Triple DES key RSA17 public key Asymmetric key Encrypt a block of data using an Execute wrapping asymmetric algorithm Asymmetric key Decrypt a block of data using RSA private key Execute unwrapping an asymmetric algorithm Signature Generation Generate a signature RSA public key Execute Signature Verification Verify a signature RSA private key Execute Hashing Perform a hashing operation on N/A N/A a block of data, using SHA-1, SHA-224, SHA-256, SHA-384, or SHA-512 HMAC18 signing Perform a hashing operation on HMAC key Execute a block of data, using a keyed Hashed Message Authentication Code with any of the hashing operations listed 14 CSP – Critical Security Parameter 15 AES – Advanced Encryption Standard 16 DES – Data Encryption Standard 17 RSA – Rivest, Shamir, Adleman 18 HMAC – (Keyed-) Hash-based Message Authentication Code © Copyright 2013 Oracle Corporation Page 11 of 20 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Service Description CSP Type of Access to CSP above Random number Generate random numbers swrand key Execute generation swrand seed key Table 4 - User Services Note that non-FIPS-Approved algorithms can also be used as part of these services, when the module is not operating in a FIPS-Approved mode. Physical Security Oracle Solaris Kernel Cryptographic Framework is a software module, which FIPS defines as a multi-chip standalone cryptographic module. As such, it does not include physical security mechanisms. Thus, the FIPS 140-2 requirements for physical security are not applicable. Operational Environment The module operates as part of the Oracle Solaris 11.1 SRU3 and 11.1 SRU5.5 Operating System. The module is programmed to utilize Intel’s special instructions sets for hardware-accelerated AES cryptography when running on the Intel processor. The module has been tested on Oracle Solaris 11.1 SRU3 and 11.1 SRU5.5 OS, running on an M3000 Enterprise Server and Sun Server X3-2 (formerly the Sun Fire X4170 M3 server) appliance, using a SPARC64 and Intel Xeon 5600-series processor, respectively. This is a software only module the processors are outside of the logical boundary. The Crypto-Officer shall ensure that the OS is configured to a Single-User mode of operation. Each kernel process is the only user of the module, at the time it is requesting functionality from the module. Once the module has performed a service for that process, it is released to provide services to the next kernel process requesting services. There will be only one user of the module at any given time. Cryptographic Key Management The module implements the following FIPS-approved algorithms: © Copyright 2013 Oracle Corporation Page 12 of 20 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Key or CSP Certificate Number v1.0 v1.1 Symmetric Key AES: ECB19, CBC20, CFB21-128, CCM22, GCM23, #2573 #2309 GMAC24, and CTR25 modes for 128, 192, and 256-bit key sizes AES: XTS26 mode for 256 and 512-bit key sizes #2573 #2309 Triple DES: CBC and ECB mode for keying option 1 #1559 #1456 Asymmetric Key RSA PKCS#1.5 signature generation/verification: #1320 #1192 1024- , 2048-bit (w/ SHA-1, SHA-256, SHA-384, SHA- 512) ECDSA signature generation/verification: P-192, -224, #445 #374 -256, -384, -521; K-163, -233, -283, -409, -571; B- 163, -233, -283, -409, -571 Secure Hashing Standard (SHS) SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 #2173 #1993 Message Authentication HMAC SHA-1, HMAC SHA-224, HMAC SHA-256, #1595 #1423 HMAC SHA-384, HMAC SHA-512 Random Number Generators swrand FIPS 186-2 Random Number Generator #1225 #1151 Table 5 – FIPS-Approved Algorithm Implementations NOTE: The following security functions have been deemed “deprecated” or “restricted” by NIST. Please refer to NIST Special Publication 800-131A for further details.  The use of key lengths providing 80 bits of security strength for digital signature generation is deprecated after December 31, 2010.  RSA (encrypt/decrypt, sign/verify operations) provides 80 or 112 bits of encryption strength, for 1024 or 2048-bit key sizes, respectively. RSA provides higher bits of encryption strength with higher key sizes.  The use of RSA 1024-bit and SHA-1 for signature generation is deprecated from 2011 through 2013 and is disallowed after 2013 while the use of RSA 1024-bit and SHA-1 for signature verification is considered legacy-use after 2010.  RSA (key wrapping; key establishment methodology) provides 80 or 112 bits of encryption strength, for 1024 or 2048-bit key sizes, respectively. RSA provides higher bits of encryption strength with higher key sizes; non-compliant with less than 80 bits of encryption strength.  The use of the RNGs specified in FIPS 186-2 is deprecated from 2011 through December 31, 2015, and disallowed after 2015. 19 ECB – Electronic Codebook 20 CBC – Cipher-Block Chaining 21 CFB – Cipher Feedback 22 CCM – Counter with CBC-MAC 23 GCM – Galois/Counter Mode 24 GMAC – Galois Message Authentication Code 25 CTR – Counter 26 XTS – Xor-encrypt-xor-based tweaked-codebook mode with ciphertext stealing © Copyright 2013 Oracle Corporation Page 13 of 20 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. The module implements the following FIPS-Approved algorithm, however the implementation has not been validated and, as such, shall not be used in the FIPS- Approved mode of operation:  Two-key Triple-DES Additionally, the module implements the following non-FIPS-approved algorithms:  MD527, HMAC MD5  MD4  RC428  DES  Blowfish  AES CTS29, XCBC-MAC30 – 128-, 192-, 256-bit  RSA signature generation – 256-, 512-bit  RSA signature verification – 256-, 512-bit The CSPs that the module supports are listed in Table 6, below. 27 MD5 – Message Digest Algorithm 5 28 RC4 – Rivest Cipher 4 29 CTS – Ciphertext Stealing 30 XCBC-MAC – Extended Cipher-Block Chaining Message Authentication Code © Copyright 2013 Oracle Corporation Page 14 of 20 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Key or CSP Key type Generation Output Storage Zeroization Use AES key AES 128-, 192-, 256- Imported (passed Output from the Reference pointer Zeroized upon Symmetric encryption bit key as an attribute in an module through Data stored in volatile completion of argument) Output interface memory during operation execution AES GCM IV Random data Imported (passed Never output from Reference Pointer Zeroized upon IV input to AES GCM as an attribute in an module Stored in volatile completion of function argument) memory during operation or execution reboot Triple DES key Triple DES 168-bit key Imported (passed Output from the Reference pointer Zeroized upon Symmetric encryption as an attribute in an module through Data stored in volatile completion of argument) Output interface memory during operation execution RSA public key RSA 1024-, 2048-, Imported (passed Output from module Reference pointer Zeroized upon Key wrapping, 4096-, 8192-bit key as an attribute in an through Data Output stored in volatile completion of certificate generation, argument) interface memory during operation certificate verification, execution signature verification RSA private key RSA 1024-, 2048-, Imported (passed Output from module Reference pointer Zeroized upon Key wrapping, 4096-, 8192-bit key as an attribute in an through Data Output stored in volatile completion of certificate generation, argument) interface memory during operation certificate verification, execution signature generation RSA signature RSA 1024-, 2048-, Imported (passed Output from module Reference pointer Zeroized upon Signing data, signature 4096-, 8192-bit as an attribute in an through Data Output stored in volatile completion of verification signature argument) interface memory during operation execution Generated internally ECDSA public key ECDSA 163-, 192-, Imported (passed Output from module Reference pointer Zeroized upon Encrypting data, 224-, 233-, 256-, 283-, as an attribute in an through Data Output stored in volatile completion of verifying signature 384-, 409-, 512-, 571- argument) interface memory during operation bit public key execution ECDSA private ECDSA 163-, 192-, Imported (passed Output from the Reference pointer Zeroized upon Decrypting data, key 224-, 233-, 256-, 283-, as an attribute in an module through Data stored in volatile completion of digitally signing data 384-, 409-, 512-, 571- argument) Output interface memory during operation bit private key execution © Copyright 2013 Oracle Corporation This document may be freely reproduced and distributed whole and intact including this Copyright Notice. HMAC key HMAC secret key Imported Never output from Reference pointer Zeroized upon Message module stored in volatile completion of Integrity/Authentication memory during operation execution FIPS 186-2 Seed 20-byte Hexadecimal Generated Never output from Plaintext in volatile Zeroized upon To calculate SHA-1 string internally module memory completion of string in FIPS 186-2 RNG31 operation FIPS 186-2 Seed 20 byte SHA-1 Digest Generated Never output from Plaintext in volatile Zeroized upon To calculate SHA-1 Key internally module memory completion of string in FIPS 186-2 operation RNG Table 6 – Listing of Key and Critical Security Parameters 31 RNG – Random Number Generator © Copyright 2013 Oracle Corporation Page 16 of 20 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Self-Tests In order to prevent any secure data from being released, it is important to test the cryptographic components of a security module to ensure all components are functioning correctly. Power-Up Self-tests To confirm correct functionality, the software library performs the following self- tests:  Software Integrity Test (HMAC SHA-1)  Known Answer Tests (KATs) o AES KAT o Triple-DES KAT o RSA sign/verify KAT o SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 HMAC KAT o SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 KAT o swrand FIPS 186-2 RNG KAT  Pairwise Consistency Tests o ECDSA signature generation/verification Conditional Self-tests The Solaris Kernel Cryptographic Framework performs the following conditional self-tests:  swrand FIPS 186-2 Continuous RNG test  swrand Entropy Continuous RNG test Data output from the module is inhibited, while performing self-tests. Should any of the power-up self-tests or conditional self-tests fail, the modules will cease operation, inhibiting any further data output from the modules. The modules will need to reboot and perform power-up self-tests. Successful completion of the power-up self-tests will return the module to normal operation. Mitigation of Other Attacks This section is not applicable. The module does not claim to mitigate any attacks beyond the FIPS 140-2 Level 1 requirements for this validation. © Copyright 2013 Oracle Corporation This document may be freely reproduced and distributed whole and intact including this Copyright Notice. SECURE OPERATION The Oracle Solaris Kernel Cryptographic Framework meets Level 1 requirements for FIPS 140-2. The sections below describe how to place and keep the module in a FIPS-approved mode of operation. Initial Setup The first time that the Solaris operating system is booted, the Crypto-Officer must use cryptoadm to make the changes necessary to enable FIPS mode. The Crypto- Officer must use the “cryptoadm enable ” command to enable the necessary providers. The following provider list is to be used when enabling providers:  aes – Provides AES algorithm support  des – Provides Triple DES algorithm support  ecc – Provides Elliptic-Curve DSA algorithm support  rsa – Provides RSA algorithm support  md5 – Provides MD5 algorithm support (for TLS purposes)  sha1 – Provides SHA-1 and HMAC SHA-1 algorithm support  sha2 – Provides SHA-2 and HMAC SHA-2 algorithm support  swrand – Provides FIPS 186-2 RNG support Note that the use of MD5 is allowed in the TLS or DTLS 32 protocol only; MD5 shall not be used as a general hash function in an Approved mode of operation. Next, the Crypto-Officer must create a new boot environment, using the “beadm create ” command, where the name is one provided by the Crypto- Officer. This creates a boot environment which is a clone of the currently running environment, to be used if there is a panic or other error with initialization. The Crypto-Officer must then input the command “cryptoadm enable fips-140”, in order to enable FIPS mode. The module must then be restarted by a full system reboot. Once the module loads, it will perform power-on cryptographic self-tests. Once all tests are successful, the module will begin to operate in a FIPS-Approved mode. Crypto-Officer Guidance The Crypto-Officer is responsible for making sure the module is running in FIPS- Approved mode of operation and to ensure that only FIPS-Approved algorithms are utilized. The following algorithms and key sizes, provided by the module, cannot be used in FIPS-Approved mode of operation:  MD5 – For non-TLS uses 32 DTLS – Datagram Transport Layer Security © Copyright 2013 Oracle Corporation Page 18 of 20 This document may be freely reproduced and distributed whole and intact including this Copyright Notice.  HMAC MD5  RC4  DES  Blowfish  2-key Triple DES  AES CTS, XCBC-MAC – 128-, 192-, 256-bit  RSA signature generation – 256-, 512-bit  RSA signature verification – 256-, 512-bit Initialization It is the Crypto-Officer’s responsibility to configure the module into the FIPS- Approved mode. Management Using the commands available to the Crypto-Officer, outlined in Table 3, the cryptoadm utility can be used to configure and manage the module. Zeroization As shown in Table 6, certain keys are stored on the host appliance’s hard drive. A format of the host appliance’s hard-drive will zeroize all keys. User Guidance It is the responsibility of the User kernel processes to ensure that only FIPS- Approved algorithms and providers are being utilized by their commands. The User is required to operate the module in a FIPS-Approved mode of operation. In order to maintain FIPS-mode, the User must do the following:  Only utilize the module interfaces to call FIPS-Approved algorithms © Copyright 2013 Oracle Corporation Page 19 of 20 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. ACRONYMS AES Advanced Encryption Standard Advanced Encryption Standard – New Instructions AES-NI API Application Programming Interface CBC Cipher-Block Chaining CCM Counter with CBC-MAC CFB Cipher Feedback CMVP Cryptographic Module Validation Program CSP Critical Security Parameter CTR Counter CTS Ciphertext Stealing DES Data Encryption Standard DVD Digital Versatile Disc ECB Electronic Codebook ECDSA Elliptic-Curve Digital Signature Algorithm EMC Electromagnetic Compatibility EMI Electromagnetic Interference ESP Encapsulating Security Payload FCC Federal Communication Commission FIPS Federal Information Processing Standard GCM Galois/Counter Mode GPC General Purpose Computer HD High Density HMAC (Keyed-) Hash-based Message Authentication Code KAT Known Answer Test LED Light Emitting Diode MAC Message Authentication Code MD5 Message Digest Algorithm 5 NIST National Institute of Standards and Technology OS Operating System PKCS Public Key Cryptography Standards RCI Remote Cabinet Interface RJ Registered Jack RNG Random Number Generator RSA Rivest Shamir and Adleman SAS Small Computer System Interface-Assisted Storage SHA Secure Hash Algorithm SPARC Scalable Processor Architecture UPC Usage Parameter Control USB Universal Serial Bus VGA Video Graphics Array XCBC-MAC Extended Cipher-Block Chaining Message Authentication Code XTS Xor-encrypt-xor-based tweaked-codebook mode with ciphertext stealing © Copyright 2013 Oracle Corporation Page 20 of 20 This document may be freely reproduced and distributed whole and intact including this Copyright Notice.