© Copyright 2013 Oracle Corporation
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
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 Page 2 of 20
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 3 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 4 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
API3
s, 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 5 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 6 of 20
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
Data Input / Data
Output
Control Input /
Status Output
Legend
kcf
Consumer Interface (Proprietary)
Provider Interface (Proprietary)
aes des rsa
Bignum
ecc
swrand
md5 sha2
sha1
Kernel Space
Processor
(Intel Xeon, SPARC64)
Hardware
Kernel Processes
Module Boundary
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 7 of 20
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
I/O Hub
Network
Interface
Clock
Generator
CPU(s)
RAM
Cache
HDD
Hardware
Management
External
Power Supply
Power
Interface
SCSI/SATA
Controller
PCI/PCIe
Slots
DVD
USB
BIOS
PCI/PCIe
Slots
Graphics
Controller
Plaintext data
Encrypted data
Control input
Status output
Crypto boundary
KEY:
Audio
LEDs/LCD
Serial
BIOS – Basic Input/Output System
CPU – Central Processing Unity
SATA – Serial Advanced Technology Attachment
SCSI – Small Computer System Interface
PCI – Peripheral Control Interface
LED – Light-Emitting Diode
LCD – Liquid-Crystal Display
PCIe – PCI express
HDD – Hard Disk Drive
DVD – Digital Versatile Disc
USB – Universal Serial Bus
RAM – Random Access Memory
Figure 2 – Intel Xeon-based GPC Hardware Block Diagram
© Copyright 2013 Oracle Corporation Page 8 of 20
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
I/O Hub
Network
Interface
Clock
Generator
CPU(s)
RAM
Cache
HDD
Lights-Out
Manager
External
Power Supply
Power
Interface
SCSI/SATA
Controller
PCI/PCIe
Slots
DVD
USB
Hypervisor
Graphics
Controller
Plaintext data
Encrypted data
Control input
Status output
Crypto boundary
KEY:
Audio
LEDs/LCD
Serial
I/O Hub – Input/Output Hub
CPU – Central Processing Unit
SATA – Serial Advanced Technology Attachment
SCSI – Small Computer System Interface
PCI – Peripheral Component Interconnect
LED – Light-Emitting Diode
LCD – Liquid-Crystal Display
PCIe – PCI Express
HDD – Hard Disk Drive
DVD – Digital Video Disc
USB – Universal Serial Bus
RAM – Random Access Memory
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 9 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
Interface
Module Logical Interface Physical Port
Data Input Oracle-proprietary API M3000 – Ethernet, USB6
, SAS7
port,
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 10 of 20
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
FIPS 140-2 Logical
Interface
Module Logical Interface Physical Port
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
Status Output Oracle-proprietary API M3000 – Ethernet, USB, VGA12
port
(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 11 of 20
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
Service Description CSP14
Type of
Access to CSP
Run POST KATs on-
demand
Restarting the appliance will
force the FIPS self-tests to run
when the module is loaded.
Calling the fips140_post()
function will call the Power-On
Self-Tests.
Crypto-Officer
credentials
Execute
Module Initialization Use external cryptoadm utility
to initialize the FIPS state.
Crypto-Officer
credentials
Execute
Module
Configuration
Use external cryptoadm utility
to configure the module.
Crypto-Officer
credentials
Execute
Zeroize keys Format operation on the host
appliance’s hard drive
Crypto-Officer
credentials
Execute
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
Symmetric
encryption
Encrypt a block of data using a
symmetric algorithm
AES15
key
Triple DES16
key
Execute
Symmetric
decryption
Decrypt a block of data using a
symmetric algorithm
AES key
Triple DES key
Execute
Asymmetric key
wrapping
Encrypt a block of data using an
asymmetric algorithm
RSA17
public key Execute
Asymmetric key
unwrapping
Decrypt a block of data using
an asymmetric algorithm
RSA private key Execute
Signature Generation Generate a signature RSA public key Execute
Signature Verification Verify a signature RSA private key Execute
Hashing Perform a hashing operation on
a block of data, using SHA-1,
SHA-224, SHA-256, SHA-384,
or SHA-512
N/A N/A
HMAC18
signing Perform a hashing operation on
a block of data, using a keyed
Hashed Message
Authentication Code with any
of the hashing operations listed
HMAC key Execute
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 12 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
generation
Generate random numbers swrand key
swrand seed key
Execute
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 13 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
,
GMAC24
, and CTR25
modes for 128, 192, and 256-bit
key sizes
#2309 #2573
AES: XTS26
mode for 256 and 512-bit key sizes #2309 #2573
Triple DES: CBC and ECB mode for keying option 1 #1456 #1559
Asymmetric Key
RSA PKCS#1.5 signature generation/verification:
1024- , 2048-bit (w/ SHA-1, SHA-256, SHA-384, SHA-
512)
#1192 #1320
ECDSA signature generation/verification: P-192, -224,
-256, -384, -521; K-163, -233, -283, -409, -571; B-
163, -233, -283, -409, -571
#374 #445
Secure Hashing Standard (SHS)
SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 #1993 #2173
Message Authentication
HMAC SHA-1, HMAC SHA-224, HMAC SHA-256,
HMAC SHA-384, HMAC SHA-512
#1423 #1595
Random Number Generators
swrand FIPS 186-2 Random Number Generator #1151 #1225
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 14 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
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-
bit key
Imported (passed
as an attribute in an
argument)
Output from the
module through Data
Output interface
Reference pointer
stored in volatile
memory during
execution
Zeroized upon
completion of
operation
Symmetric encryption
AES GCM IV Random data Imported (passed
as an attribute in an
argument)
Never output from
module
Reference Pointer
Stored in volatile
memory during
execution
Zeroized upon
completion of
operation or
reboot
IV input to AES GCM
function
Triple DES key Triple DES 168-bit key Imported (passed
as an attribute in an
argument)
Output from the
module through Data
Output interface
Reference pointer
stored in volatile
memory during
execution
Zeroized upon
completion of
operation
Symmetric encryption
RSA public key RSA 1024-, 2048-,
4096-, 8192-bit key
Imported (passed
as an attribute in an
argument)
Output from module
through Data Output
interface
Reference pointer
stored in volatile
memory during
execution
Zeroized upon
completion of
operation
Key wrapping,
certificate generation,
certificate verification,
signature verification
RSA private key RSA 1024-, 2048-,
4096-, 8192-bit key
Imported (passed
as an attribute in an
argument)
Output from module
through Data Output
interface
Reference pointer
stored in volatile
memory during
execution
Zeroized upon
completion of
operation
Key wrapping,
certificate generation,
certificate verification,
signature generation
RSA signature RSA 1024-, 2048-,
4096-, 8192-bit
signature
Imported (passed
as an attribute in an
argument)
Generated
internally
Output from module
through Data Output
interface
Reference pointer
stored in volatile
memory during
execution
Zeroized upon
completion of
operation
Signing data, signature
verification
ECDSA public key ECDSA 163-, 192-,
224-, 233-, 256-, 283-,
384-, 409-, 512-, 571-
bit public key
Imported (passed
as an attribute in an
argument)
Output from module
through Data Output
interface
Reference pointer
stored in volatile
memory during
execution
Zeroized upon
completion of
operation
Encrypting data,
verifying signature
ECDSA private
key
ECDSA 163-, 192-,
224-, 233-, 256-, 283-,
384-, 409-, 512-, 571-
bit private key
Imported (passed
as an attribute in an
argument)
Output from the
module through Data
Output interface
Reference pointer
stored in volatile
memory during
execution
Zeroized upon
completion of
operation
Decrypting data,
digitally signing data
© Copyright 2013 Oracle Corporation Page 16 of 20
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
Table 6 – Listing of Key and Critical Security Parameters
31
RNG – Random Number Generator
HMAC key HMAC secret key Imported Never output from
module
Reference pointer
stored in volatile
memory during
execution
Zeroized upon
completion of
operation
Message
Integrity/Authentication
FIPS 186-2 Seed 20-byte Hexadecimal
string
Generated
internally
Never output from
module
Plaintext in volatile
memory
Zeroized upon
completion of
operation
To calculate SHA-1
string in FIPS 186-2
RNG31
FIPS 186-2 Seed
Key
20 byte SHA-1 Digest Generated
internally
Never output from
module
Plaintext in volatile
memory
Zeroized upon
completion of
operation
To calculate SHA-1
string in FIPS 186-2
RNG
© Copyright 2013 Oracle Corporation
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 Page 18 of 20
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 <provider name> <mechanism list>”
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 DTLS32
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 <name>” 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 19 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 20 of 20
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
ACRONYMS
AES Advanced Encryption Standard
AES-NI Advanced Encryption Standard – New Instructions
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