Document Version 1.3 ©Oracle Corporation
This document may be reproduced whole and intact including the Copyright notice.
FIPS 140-2 Non-Proprietary Security Policy
Oracle Solaris Kernel Cryptographic Framework
FIPS 140-2 Level 1 Validation
Software Version:
1.4
Date: January 13, 2022
Oracle Solaris Kernel Cryptographic Framework Security Policy
i
Title: Oracle Solaris Kernel Cryptographic Framework
Date: January 13, 2022
Author: Acumen Security
Contributing Authors:
Solaris Security Engineering,
Oracle Security Evaluations – Global Product Security
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
www.oracle.com
Copyright © 2022, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only and the contents hereof are subject to
change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in
law, including implied warranties and conditions of merchantability or fitness for a particular purpose. Oracle specifically disclaim any liability with respect to this
document and no contractual obligations are formed either directly or indirectly by this document. This document may reproduced or distributed whole and
intact including this copyright notice.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Oracle Solaris Kernel Cryptographic Framework Security Policy
ii
TABLE OF CONTENTS
Section Title Page
1 Introduction ...................................................................................................................................................1
1.1 Overview ....................................................................................................................................................................................1
1.2 Document Organization .............................................................................................................................................................1
2 Oracle Solaris Kernel Cryptographic Framework ..............................................................................................1
2.1 Functional Overview...................................................................................................................................................................1
3 Cryptographic Module Specification................................................................................................................2
3.1 Definition of the Cryptographic Module ....................................................................................................................................2
3.2 Cryptographic Boundary ............................................................................................................................................................2
3.3 FIPS 140-2 Validation Scope.......................................................................................................................................................3
3.4 Security Functions ......................................................................................................................................................................4
3.4.1 Approved or Allowed Security Functions ...............................................................................................................................4
3.4.2 Non-Approved Security Functions..........................................................................................................................................5
4 Module Ports and Interfaces...........................................................................................................................6
5 Operating System ...........................................................................................................................................7
5.1 Definition of Operating System Embodiment ............................................................................................................................7
5.2 Tested Configurations ................................................................................................................................................................7
5.3 Vendor Affirmed Configurations ................................................................................................................................................7
6 Roles and Services ..........................................................................................................................................9
7 Key and CSP Management ............................................................................................................................10
8 Self-Tests......................................................................................................................................................11
8.1 Power-Up Self-Tests.................................................................................................................................................................11
8.2 Conditional Self-Tests...............................................................................................................................................................11
9 Crypto-Officer and User Guidance.................................................................................................................11
9.1 Secure Setup and Initialization.................................................................................................................................................11
9.2 Module Security Policy Rules ...................................................................................................................................................12
9.2.1 Crypto-Officer Guidance.......................................................................................................................................................12
9.2.1.1 Initialization............................................................................................................................................................................................. 12
9.2.1.2 Management........................................................................................................................................................................................... 12
9.2.1.3 Zeroization............................................................................................................................................................................................... 12
9.2.2 User Guidance ......................................................................................................................................................................12
10 Mitigation of Other Attacks...........................................................................................................................13
Appendices.........................................................................................................................................................14
Acronyms, Terms and Abbreviations .................................................................................................................................................14
References..........................................................................................................................................................................................15
Oracle Solaris Kernel Cryptographic Framework Security Policy
iii
List of Tables
Table 1: FIPS 140-2 Security Requirements.................................................................................................3
Table 2: FIPS Approved or Allowed Security Functions...............................................................................4
Table 3: Non-Approved Security Functions..................................................................................................5
Table 4: Mapping of FIPS 140 Logical Interfaces to Logical Ports ...............................................................6
Table 5: Tested Operational Environments .................................................................................................7
Table 6: Services Authorized for Roles.........................................................................................................9
Table 7: Cryptographic Keys and CSPs....................................................................................................... 10
List of Figures
Figure 1: Solaris Cryptographic Framework Cryptographic Boundary ................................................2
Oracle Solaris Kernel Cryptographic Framework Security Policy
Page 1 of 14
1 Introduction
1.1 Overview
This document is the Security Policy for the Oracle Solaris Kernel Cryptographic Framework designed by Oracle
Corporation. The Oracle Solaris Kernel Cryptographic Framework is also referred to as ‘the module’ or ‘module’.
This Security Policy specifies the security rules under which the module shall operate to meet the requirements of
FIPS 140-2 Level 1. It also describes how Oracle Solaris Kernel Cryptographic Framework functions in order to meet
the FIPS requirements, and the actions that operators must take to maintain the security of Oracle Solaris Kernel
Cryptographic Framework.
This Security Policy describes the features and design of the Oracle Solaris Kernel Cryptographic Framework module
using the terminology contained in the FIPS 140-2 specification. FIPS 140-2, Security Requirements for Cryptographic
Modules specifies the security requirements that will be satisfied by a cryptographic module utilized within a security
system protecting sensitive but unclassified information. The NIST/CCCS Cryptographic Module Validation Program
(CMVP) validates cryptographic modules to FIPS 140-2. Validated products are accepted by the Federal agencies of
both the USA and Canada for the protection of sensitive or designated information.
1.2 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:
• Oracle Non-Proprietary Security Policy
• Oracle Vendor Evidence document
• Finite State Machine
• Entropy Assessment Document
• 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 and is releasable only under appropriate non-disclosure agreements. For access to these documents, please
contact Oracle.
2 Oracle Solaris Kernel Cryptographic Framework
2.1 Functional Overview
The Oracle Solaris Cryptographic Framework is an architecture that enables applications in the Oracle Solaris
operating system to use or provide cryptographic services. At a high level it consists of Userland Cryptographic
Framework and Kernel Cryptographic Framework. This Security Policy is for the Kernel Cryptographic Framework.
Oracle Solaris Kernel Cryptographic Framework Security Policy
Page 2 of 14
3 Cryptographic Module Specification
3.1 Definition of the Cryptographic Module
The Oracle Solaris Kernel Cryptographic Framework module is a multiple-chip standalone cryptographic module as
defined by the requirements of FIPS PUB 140-2. The module provides cryptographic functionality for the kernel
module. The module provides encryption, decryption, hashing, signature generation and verification, secure random
number generation, and message authentication functions. The module can leverage the algorithm acceleration
from SPARC and X86 processors when available.
The module supports both an Approved and non-Approved mode of operation. Section 9 provides the Crypto-Officer
and User Guidance required for operating the module in the Approved mode.
3.2 Cryptographic Boundary
The logical boundary of the cryptographic module is a collection of kernel modules that, collectively, are known as
the Oracle Solaris Kernel Cryptographic Framework. The physical cryptographic boundary is defined as the enclosure
of the host system on which it runs. A representation of the cryptographic boundary is defined below:
Figure 1: Solaris Cryptographic Framework Cryptographic Boundary
Oracle Solaris Kernel Cryptographic Framework Security Policy
Page 3 of 14
3.3 FIPS 140-2 Validation Scope
The Oracle Solaris Kernel Cryptographic Framework is being validated to overall FIPS 140-2 Level 1 requirements.
See Table 1 below.
Security Requirements Section Level
Cryptographic Module Specification 1
Cryptographic Module Ports and Interfaces 1
Roles and Services and Authentication 1
Finite State Machine Model 1
Physical Security N/A
Operational Environment 1
Cryptographic Key Management 1
EMI/EMC 1
Self-Tests 1
Design Assurance 3
Mitigation of Other Attacks N/A
Table 1: FIPS 140-2 Security Requirements
Oracle Solaris Kernel Cryptographic Framework Security Policy
Page 4 of 14
3.4 Security Functions
3.4.1 Approved or Allowed Security Functions
The Oracle Solaris Kernel Cryptographic Framework module contains the following FIPS Approved Algorithms listed in
Table 2:
Approved or Allowed Security Functions Certificate
Symmetric Encryption/Decryption
AES: (CBC, ECB, CFB128, CTR, CCM, CMAC, GCM, GMAC);
Encrypt/Decrypt; Key Size = 128, 192, 256
XTS1
; Encrypt/Decrypt; Full/Partial Block; Key Size = 128, 256
C1895
Triple-DES: TCBC( KO 1 e/d) ; TECB( KO 1 e/d) C1895
Secure Hash Standard (SHS)
SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512_224, SHA-
512_256, SHA-3 (Byte Only)
C1895
SHA-3 (224, 256, 384, 512) C1895
Data Authentication Code
HMAC-SHA-1, HMAC-SHA2-224, HMAC-SHA2-256, HMAC-SHA2-384,
HMAC-SHA2-512, HMAC-SHA2-512_224, HMAC-SHA2-512_256, HMAC-
SHA3-224, HMAC-SHA3-256, HMAC-SHA3-384, HMAC-SHA3-512,
(KeySizes = KS < BS; KS = BS; KS > BS)
C1895
Asymmetric Algorithms
RSA: FIPS186-4:
SIG(Ver) (1024 SHA(1, 224 , 256 , 384 , 512 )) (2048 SHA(1, 224, 256 ,
384 , 512 )) (3072 SHA(1, 224, 256 , 384 , 512 ))
C1895
Random Number Generation
NIST SP 800-90A Rev. 1:
Hash_Based DRBG: [ Prediction Resistance Tested: Enabled (SHA-512 ) ]
C1895
NDRNG Allowed
Table 2: FIPS Approved or Allowed Security Functions
Note that the DRBG requests 256 bits of entropy per GET function.
1
XTS mode can only be used for storage applications
Oracle Solaris Kernel Cryptographic Framework Security Policy
Page 5 of 14
3.4.2 Non-Approved Security Functions
The following are considered non-Approved security functions:
Non-Approved Security Functions
MD5 HMAC MD5
MD4 RC4
DES Blowfish
AES-XCBC-MAC ECDSA Key Generation and Signature Generation
Camelia RSA (Key Generation and Signature Generation,
non-compliant less than 112 bits of encryption
strength)
Triple-DES (2-key, CTR, CFB)
Table 3: Non-Approved Security Functions
Oracle Solaris Kernel Cryptographic Framework Security Policy
Page 6 of 14
4 Module Ports and Interfaces
The module can be accessed by utilizing the API it exposes. This API is an Oracle-proprietary consumer interface.
Table 4 below shows the interfaces provided by the module.
FIPS 140-2 Logical Interface Logical Port
Data Input Input arguments to Oracle-proprietary API
Data Output Output arguments to Oracle-proprietary API
Control Input Oracle-proprietary API
Status Output Return variables of Oracle-proprietary API
Power N/A
Table 4: Mapping of FIPS 140 Logical Interfaces to Logical Ports
Oracle Solaris Kernel Cryptographic Framework Security Policy
Page 7 of 14
5 Operating System
5.1 Definition of Operating System Embodiment
The module runs on a general purpose operating system as defined in Section 4.6 of FIPS PUB 140-2. The module
uses a strong integrity test using HMAC-SHA-256.
5.2 Tested Configurations
The module was tested on the following configurations:
Hardware Processor Operating System
Oracle SPARC T8 Server SPARC M8 (with
and without
acceleration)
Solaris 11.4
Oracle ZFS Storage Appliance ZS7 Intel® Xeon® Gold
6100 (with and
without
acceleration
Solaris 11.4
Table 5: Tested Operational Environments
5.3 Vendor Affirmed Configurations
Additionally, Oracle affirms that the module will function the same way and provide the same security services on any of the
systems listed below2
.
S3 Core Processors
• Oracle SPARC T4-1
• Oracle Netra SPARC T4-1B
• Oracle SPARC T4-2
• Oracle SPARC T4-4
• Oracle SPARC T4-1B
• Oracle Netra SPARC T5-1B
• Oracle SPARC T5-2
• Oracle SPARC T5-4 Server
• Oracle SPARC T5-8 Server
• Oracle SPARC M5-32 Server
• Oracle SPARC M6-32 Server
S4 Core Processors
• Oracle SPARC T7-1 Server
• Oracle SPARC T7-4 Server
• Oracle SPARC M7-8 Server
• Oracle SPARC M7-16 Server
2
The CMVP makes no claims as to the correct operation of the module or the security strengths of the generated keys when
ported to an operational environment which is not listed on the validation certificate.
Oracle Solaris Kernel Cryptographic Framework Security Policy
Page 8 of 14
• Oracle SPARC M8-8 Server
• Oracle SPARC S7-2 Server
• Oracle SPARC S7-2L Server
• Oracle MiniCluster S7-2 Engineered System
• Netra SPARC S7-2
X86 Systems
• Oracle Sun Blade X3-2B
• Oracle Sun Server X3-2
• Oracle Sun Server X3-2L
• Oracle Sun Blade X4-2B
• Oracle Sun Server X4-2
• Oracle Sun Server X4-2L
• Oracle Sun Server X4-4
• Oracle Sun Server X4-8
• Oracle Sun Server X5-2
• Oracle Sun Server X5-2L
• Oracle Sun Server X5-4
• Oracle Sun Server X5-8
• Oracle Netra Server X3-2
• Oracle Netra Server X5-2
• Oracle Server X5-2M
• Oracle Server X6-2
• Oracle Server X6-2L
• Oracle Server X6-2M
• Oracle Server X6-2S
• Oracle Server X8-2
• Oracle Server X8-2L
• Oracle Server X8-8
• Oracle Server X9-2
• Oracle ZFS Storage Appliance ZS5-2
• Oracle ZFS Storage Appliance ZS5-4
• Oracle ZFS Storage Appliance ZS5-ES
• Oracle ZFS Storage Appliance ZS9-2
Fujitsu further affirms that the module will function the same way and provide the same security services on any of
the systems listed below.
Note: The following Fujitsu M10 SPARC systems using the SPARC64 processor are known by different product
marketing names depending on locale and are otherwise identical:
• Fujitsu M10-1 is named the SPARC M10-1 in Japan.
• Fujitsu M10-4 is named the SPARC M10-4 in Japan.
• Fujitsu M10-4S is named the SPARC M10-4S in Japan.
• Fujitsu M12
• Fujitsu Server M12-1
• Fujitsu Server M12-2
• Fujitsu Server M12-2S
Oracle Solaris Kernel Cryptographic Framework Security Policy
Page 9 of 14
6 Roles and Services
The Oracle Solaris Kernel Cryptographic Framework implements two roles - a Crypto Officer Role (CO) and a User Role (U) that are implicitly assumed by
operators based on the services they execute.
Table 6 gives a high level description of all services provided by the module and lists the roles allowed to invoke each service. The following abbreviations
are used for roles:
X – Execute (includes read and write operations), Z – Zeroize
U CO Service Name Service Description Keys and CSP(s) Access Type(s)
X Run POSTs on-demand Restarting the appliance will force the FIPS self-tests to run
when the module is loaded. Alternatively the appropriate API
can also be called to run the on-demand self-test.
Software Integrity Key X
X Module Initialization Use external cryptoadm utility to initialize the FIPS state. N/A N/A
X Module Configuration Use external cryptoadm utility to configure the module. N/A N/A
X X Show Status Command: cryptoadm list fips-140 shows if FIPS mode is
enabled
N/A N/A
X Zeroize Keys Power-cycle All keys Z
X Symmetric Encryption
and Decryption
Encrypt/Decrypt data using a symmetric algorithm Symmetric Keys X
X Signature Generation Generate RSA signatures Asymmetric Private Key (RSA) X
X Signature Verification Verify RSA and ECDSA signatures No Key/CSP access but uses
Asymmetric Public Key (RSA and ECDSA)
N/A
X Hashing Perform a hashing operation on a block of data, using SHA
algorithm
N/A N/A
X HMAC Perform a hashing operation on a block of data, using a keyed
Hashed Message Authentication Code with any of the hashing
operations listed above
Keyed Hash Key (HMAC) X
X Random Number
Generation
Generate random numbers using SP 800-90A DRBG DRBG V value
DRBG C value
Entropy
X
X
X
Table 6: Services Authorized for Roles
Note: The services listed above can also be executed using non-approved algorithms (See Section 3.4.2) thereby making them non-approved services.
Oracle Solaris Kernel Cryptographic Framework Security Policy
Page 10 of 14
7 Key and CSP Management
The following keys, cryptographic key components and other critical security parameters are contained in the module.
CSP Name Generation/Input Input/Output Storage Use
Symmetric Keys (AES and Triple-
DES)
Entered via API Input via API RAM Used for symmetric encryption and decryption
Asymmetric Key pairs Entered via API Input via API RAM Used for RSA and ECDSA signature generation and
verification and RSA key wrapping
Keyed Hash Key (HMAC) Generated internally via
DRBG and Entered via API
Input via API RAM Used for keyed hashing (HMAC)
DRBG V value Generated internally via
entropy input
N/A RAM Used as part of SP 800-90A DRBG
DRBG C value Generated internally via
entropy input
N/A RAM Used as part of SP 800-90A DRBG
Entropy Entered via API N/A RAM Used as part of SP 800-90A DRBG
Table 7: Cryptographic Keys and CSPs
Oracle Solaris Kernel Cryptographic Framework Security Policy
Page 11 of 14
8 Self-Tests
8.1 Power-Up Self-Tests
Oracle Solaris Kernel Cryptographic Framework performs the following power-up self-tests when power is applied to
the module. These self-tests require no inputs or actions from the operator:
• Software Integrity Test (HMAC-SHA-256)
• AES GCM and ECB (Encrypt/Decrypt) KAT
• Triple-DES (Encrypt/Decrypt) KAT
• HMAC-SHA-1, HMAC-SHA2-512 KAT
• HMAC-SHA3-256
• RSA sign/verify KAT
• DRBG KAT
When the module is in a power-up self-test state or error state, the data output interface is inhibited and remains
inhibited until the module can transition into an operational state.
8.2 Conditional Self-Tests
The module performs the following conditional self-tests when called by the module:
• DRBG Health Tests; and
• Entropy source conditional test to verify that the output of the entropy source to be used as seeding material into
the FIPS Approved DRBG is not the same as the previously generated value.
9 Crypto-Officer and User Guidance
The module 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.
9.1 Secure Setup and Initialization
1. Firstly, the Crypto Officer must create a BE based on current configuration and boot it:
# beadm create S11.4-FIPS-140
# beadm activate S11.4-FIPS-140
# reboot
2. Upon successful reboot, in the new BE, enable FIPS 140 mode in the Cryptographic Framework:
# cryptoadm enable fips-140
If the fips-140 package is not yet loaded, this command also loads the package.
3. After the consumers are configured, reboot the BE.
# reboot
Oracle Solaris Kernel Cryptographic Framework Security Policy
Page 12 of 14
At this time the system should be in FIPS mode of operation. This can be verified by issuing the following command:
# cryptoadm list fips-140
In the output at least the following providers should have FIPS 140 mode enabled:
• DES
• AES
• ECC
• SHA1
• SHA2
• RSA
9.2 Module Security Policy Rules
This section describes the rules for operating the module in FIPS-approved mode of operation.
9.2.1 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. Algorithms listed in Table 4 shall not be used in FIPS-Approved
mode of operation.
9.2.1.1 Initialization
It is the Crypto-Officer’s responsibility to configure the module into the FIPS-Approved mode.
9.2.1.2 Management
Using the commands available to the Crypto-Officer, outlined in Table 7, the cryptoadm utility can be used to
configure and manage the module.
9.2.1.3 Zeroization
As shown in Table 7, all keys are stored in RAM and can be zeroized via a power-cycle.
9.2.2 User Guidance
It is the responsibility of the User to ensure that only FIPS-Approved algorithms and providers are being utilized. The
User is required to operate the module in a FIPS-Approved mode of operation. In order to maintain FIPS-mode, the
User must only utilize the module interfaces to call FIPS-Approved algorithms. Moreover, the module's AES-GCM
implementation conforms to IG A.5, scenario #2; in the Approved mode, the AES-GCM IV is generated internally:
• The IV is generated using the approved DRBG
• The DRBG is seeded using the NDRNG within the physical boundary
• The IV length is at least 96 bits
• The DRBG is instantiated with more than 96 bits of entropy
Oracle Solaris Kernel Cryptographic Framework Security Policy
Page 13 of 14
10 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.
Oracle Solaris Kernel Cryptographic Framework Security Policy
Page 14 of 14
Appendices
Acronyms, Terms and Abbreviations
Term Definition
AES Advanced Encryption Standard
BE Boot Environment
CMVP Cryptographic Module Validation Program
CCCS Canadian Centre for Cyber Security
CSP Critical Security Parameter
DRBG Deterministic Random Bit Generator
ECDSA Elliptic Curve Digital Signature Algorithm
HMAC (Keyed) Hash Message Authentication Code
KAT Known Answer Test
kCF Kernel Crypto Framework
NIST National Institute of Standards and Technology
POST Power On Self Test
PUB Publication
RAM Random Access Memory
SHA Secure Hash Algorithm
SPARC Scalable Processor Architecture
Oracle Solaris Kernel Cryptographic Framework Security Policy
Page 15 of 14
References
The FIPS 140-2 standard, and information on the CMVP, can be found at
http://csrc.nist.gov/groups/STM/cmvp/index.html. More information describing the Oracle Solaris Kernel
Cryptographic Framework can be found on the Oracle web site at www.oracle.com .
This Security Policy contains non-proprietary information. All other documentation submitted for FIPS 140-2
conformance testing and validation is “Oracle - Proprietary” and is releasable only under appropriate non-disclosure
agreements.
Document Author Title
FIPS PUB 140-2 NIST FIPS PUB 140-2: Security Requirements for Cryptographic Modules
(Dec. 2002)
FIPS IG NIST Implementation Guidance for FIPS PUB 140-2 and the
Cryptographic Module Validation Program
FIPS PUB 140-2
Annex A
NIST FIPS 140-2 Annex A: Approved Security Functions
FIPS PUB 140-2
Annex B
NIST FIPS 140-2 Annex B: Approved Protection Profiles
FIPS PUB 140-2
Annex C
NIST FIPS 140-2 Annex C: Approved Random Number Generators
FIPS PUB 140-2
Annex D
NIST FIPS 140-2 Annex D: Approved Key Establishment Techniques
DTR for FIPS PUB
140-2
NIST Derived Test Requirements (DTR) for FIPS PUB 140-2, Security
Requirements for Cryptographic Modules
NIST SP 800-67 NIST Recommendation for the Triple Data Encryption Algorithm TDEA
Block Cypher
FIPS PUB 197 NIST Advanced Encryption Standard
FIPS PUB 198-1 NIST The Keyed Hash Message Authentication Code (HMAC)
FIPS PUB 186-4 NIST Digital Signature Standard (DSS)
FIPS PUB 180-4 NIST Secure Hash Standard (SHS)
NIST SP 800-131A
Rev. 1
NIST Recommendation for the Transitioning of Cryptographic
Algorithms and Key Sizes
NIST SP 800-90A
Rev. 1
NIST Recommendation for Random Number Generation Using
Deterministic Random Bit Generators
PKCS#1 RSA
Laboratories
PKCS#1 v1.5: RSA Cryptographic Standard
All of the above references are available at URL: http://csrc.nist.gov/groups/STM/cmvp/index.html.