1 About Cryptographic Providers in Oracle Solaris
This chapter describes the providers of cryptography to the Oracle Solaris operating system, and covers the following topics:
What's New in Cryptography for Oracle Solaris 11.4
This section highlights information for existing customers about new cryptographic services in this release.
-
The Cryptographic Framework is based on the latest version of the PKCS #11 Cryptographic Token Interface Standard, PKCS #11 v2.40. Several new cryptographic algorithms and security standards have been revised and published in this upgrade. For more information, see the OASIS PKCS #11 Technical Committee website: https://www.oasis-open.org/committees/pkcs11/.
-
ucrypto
is a simple and fast cryptographic interface to user-level cryptographic primitives.ucrypto
is useful for applications with simple needs for pure cryptographic functionality. In particular,ucrypto
is useful when programs cannot or should not use PKCS #11 or OpenSSL APIs. The faster path to cryptographic functionality throughucrypto
can significantly improve the performance of applications. For more information, see Simple and Fast ucrypto Provider -
An enhanced
elfsign
command makes it more difficult for attackers get at your data.elfsign
also separates the signature cryptographic algorithm calculation from the data range algorithm, making it easier for you to add and maintain new algorithms.For more information, see Elfsign Enhancements.
-
Configurable keystore
As of this Oracle Solaris release, token labels are configurable. You can simultaneously create a new token, set its PIN, and assign a label to it with a single
pktool inittoken
command. You can also use the same command to change the labels of existing tokens. However, to change the PINs of existing tokens, you continue to use thepktool setpin
command.Although the
pktool setpin
command remains a valid command to create a token, you cannot set the label name using this method. Instead, the default label name is used, which is Sun Software PKCS #11softtoken
.If you are running applications or scripts that use
pktool setpin
to create tokens, you must revise them to includepktool inittoken
to configure token labels as well. For examples of the use of thepktool inittoken
command, see How to Create a PKCS #11 Keystore. -
The
cryptoadm
command creates a new BE, thus retains the original BE. For more information, see Enabling FIPS 140-2 Mode in Oracle Solaris.
About Cryptography in Oracle Solaris
Oracle Solaris provides the Cryptographic Framework to handle cryptographic requirements. Third parties can add their cryptographic services as plugins to the Cryptographic Framework. See The Cryptographic Framework.
For faster access to cryptographic primitives, Oracle Solaris
offers the ucrypto
provider for access to user-level algorithms. See Simple and Fast ucrypto Provider.
OpenSSL, an open source project, is a source of cryptographic services for Transport Layer Security (TLS) and Secure Sockets in Oracle Solaris. Oracle Solaris supports both the non-FIPS 140-2 and the FIPS 140-2 versions of OpenSSL. See OpenSSL and Oracle Solaris.
The Cryptographic Framework
The Cryptographic Framework provides a common store of algorithms and PKCS #11 libraries to handle cryptographic requirements. The PKCS #11 libraries are implemented according to the RSA Security Inc. PKCS #11 Cryptographic Token Interface (Cryptoki) standard.
Figure 1-1 Cryptographic Framework Levels
![Shows the Application and Kernel levels of the Cryptographic Framework and the plugins at those two levels. Shows the Application and Kernel levels of the Cryptographic Framework and the plugins at those two levels.](img/scf-arch.png)
At the kernel level, the framework currently handles cryptographic requirements for ZFS, Kerberos and IPsec, as well as hardware. User-level consumers include the OpenSSL engine, Java Cryptographic Extensions (JCE) and IKE (Internet Key Protocol).
Export law in the United States requires that the use of open cryptographic interfaces be licensed. The Cryptographic Framework satisfies the current law by requiring that kernel cryptographic providers and PKCS #11 cryptographic providers be signed. For further discussion, see the information about the elfsign
command in User-Level Commands in the Cryptographic Framework.
- User-level plugins – Shared objects that provide services by using PKCS #11 libraries, such as
/var/user/$USER/pkcs11_softtoken.so.1
. - Kernel-level plugins – Kernel modules that provide implementations of cryptographic algorithms in software, such as AES.
Many of the algorithms in the framework are optimized for x86 with SSSE3 instructions and AVX instructions and for SPARC hardware. For T-Series optimizations, see Cryptographic Framework Optimizations for SPARC Based Systems.
- Hardware plugins – Device drivers and their associated hardware accelerators. The Niagara chips are one example. A hardware accelerator offloads expensive cryptographic functions from the operating system.
The framework implements a standard interface, the PKCS #11, v2.40 amendment 3 library, for user-level providers. The library can be used by third-party applications to reach providers. Third parties can also add signed libraries, signed kernel algorithm modules, and signed device drivers to the framework. These plugins are added when the Image Packaging System (IPS) installs the third-party software. For a diagram of the major components of the framework, see Figure 1-1.
Concepts in the Cryptographic Framework
Note the following descriptions of concepts and corresponding examples that are useful when working with the Cryptographic Framework.
-
Algorithms – Cryptographic algorithms are established, recursive computational procedures that encrypt or hash input. Encryption algorithms can be symmetric or asymmetric. Symmetric algorithms use the same key for encryption and decryption. Asymmetric algorithms, which are used in public-key cryptography, require two keys. Hashing functions are also algorithms.
Examples of algorithms include:
-
Symmetric algorithms, such as AES
-
Asymmetric algorithms, such as RSA
-
Hashing functions, such as SHA256
-
-
Consumers – Users of the cryptographic services that come from providers. Consumers can be applications, end users, or kernel operations.
Examples of consumers include:
-
Applications, such as IKE
-
End users, such as a regular user who runs the
encrypt
command -
Kernel operations, such as IPsec
-
-
Keystore – In the Cryptographic Framework, persistent storage for token objects, often used interchangeably with token. For information about a reserved keystore, see Metaslot in this list of definitions.
Token labels are configurable. You can simultaneously create a new token, set its PIN, and assign it a label with a single
pktool inittoken
command. You can also use the same command to change the labels of existing tokens. To change the PINs of existing tokens, you continue to use thepktool setpin
command. -
Mechanism – The application of a mode of an algorithm for a particular purpose.
For example, a DES mechanism that is applied to authentication, such as CKM_DES_MAC, is a separate mechanism from a DES mechanism that is applied to encryption, CKM_DES_CBC_PAD.
-
Metaslot – A single slot that presents a union of the capabilities of other slots which are loaded in the framework. The metaslot eases the work of dealing with all of the capabilities of the providers that are available through the framework. When an application that uses the metaslot requests an operation, the metaslot determines which actual slot will perform the operation. Metaslot capabilities are configurable, but configuration is not required. The metaslot is on by default. For more information, see the cryptoadm(8) man page.
The metaslot does not have its own keystore. Rather, the metaslot reserves the use of a keystore from one of the actual slots in the Cryptographic Framework. By default, the metaslot reserves the
Sun Crypto Softtoken
keystore. The keystore that is used by the metaslot is not shown as one of the available slots.Users can specify an alternate keystore for metaslot by setting the environment variables ${METASLOT_OBJECTSTORE_SLOT} and ${METASLOT_OBJECTSTORE_TOKEN}, or by running the
cryptoadm
command. For more information, see the libpkcs11(3LIB), pkcs11_softtoken(7), and cryptoadm(8) man pages. -
Mode – A version of a cryptographic algorithm. For example, CBC (Cipher Block Chaining) is a different mode from ECB (Electronic Code Book). The AES algorithm has modes such as CKM_AES_ECB and CKM_AES_CBC.
-
Policy – The choice, by an administrator, of which mechanisms to make available for use. By default, all providers and all mechanisms are available for use. The enabling or disabling of any mechanism would be an application of policy. For examples of setting and applying policy, see Administering the Cryptographic Framework.
-
Providers – Cryptographic services that consumers use. Providers plug in to the framework, and so are also called plugins.
Examples of providers include:
-
PKCS #11 libraries, such as
/var/user/$USER/pkcs11_softtoken.so
-
Modules of cryptographic algorithms, such as
aes
andarcfour
-
Device drivers and their associated hardware accelerators, such as the
mca
driver for the Sun Crypto Accelerator 6000
-
-
Slot – An interface to one or more cryptographic devices. Each slot, which corresponds to a physical reader or other device interface, might contain a token. A token provides a logical view of a cryptographic device in the framework.
-
Token – In a slot, a token provides a logical view of a cryptographic device in the framework.
Cryptographic Framework Commands and Plugins
The framework provides commands for administrators, for users, and for developers who supply providers.
-
Administrative commands – The
cryptoadm
command provides a ‐list subcommand to list the available providers and their capabilities. Regular users can run thecryptoadm list
and thecryptoadm --help
commands.All other
cryptoadm
subcommands require you to assume a role that includes the Crypto Management rights profile, or to become superuser. Subcommands such as ‐disable, ‐install, and ‐uninstall are available for administering the framework. For more information, see the cryptoadm(8) man page.The
svcadm
command is used to manage thekcfd
daemon and to refresh cryptographic policy in the kernel. For more information, see the svcadm(8) man page. -
User-level commands – The
digest
andmac
commands provide file integrity services. Theencrypt
anddecrypt
commands protect files from eavesdropping. To use these commands, see Protecting Files With the Cryptographic Framework.
Administrative Commands in the Cryptographic Framework
The cryptoadm
command administers a running Cryptographic
Framework. The command is part of the Crypto Management rights profile. This profile can
be assigned to a role for secure administration of the Cryptographic Framework. You use
the cryptoadm
command to do the following:
-
Disable or enable provider mechanisms
-
Disable or enable the metaslot
You use the svcadm
command to enable, refresh, and disable the cryptographic services daemon, kcfd
. This command is part of the Service Management Facility (SMF) feature of Oracle Solaris. svc:/system/cryptosvcs
is the service instance for the Cryptographic Framework. For more information, see the smf(7) and svcadm(8) man pages.
User-Level Commands in the Cryptographic Framework
The Cryptographic Framework provides user-level commands to check the integrity of files, to encrypt files, and to decrypt files.
-
digest
command – Computes a message digest for one or more files or for stdin. A digest is useful for verifying the integrity of a file. SHA1 and SHA384 are examples of digest functions. -
mac
command – Computes a MAC for one or more files or for stdin. A MAC associates data with an authenticated message. A MAC enables a receiver to verify that the message came from the sender and that the message has not been tampered with. Thesha1_mac
andsha384_hmac
mechanisms can compute a MAC. -
encrypt
command – Encrypts files or stdin with a symmetric cipher. Theencrypt -l
command lists the algorithms that are available. Mechanisms that are listed under a user-level library are available to theencrypt
command. The framework provides AES, 3DES (Triple-DES), and Camellia mechanisms for user encryption. -
decrypt
command – Decrypts files or stdin that were encrypted with theencrypt
command. Thedecrypt
command uses the identical key and mechanism that were used to encrypt the original file. -
elfsign
command – Provides a means to sign providers to be used with the Cryptographic Framework. Typically, this command is run by the developer of a provider. Theelfsign
command has subcommands to sign binaries and verify the signature on a binary. Unsigned binaries cannot be used by the Cryptographic Framework. Providers that have verifiable signed binaries can use the framework. For further information, see Elfsign Enhancements.
Elfsign Enhancements
The enhanced elfsign
command makes it more difficult for attackers
get at your data. elfsign
also separates the signature cryptographic
algorithm calculation from the data range algorithm, making it easier for you to add and
maintain new algorithms.
The data range algorithm determines what parts of the ELF file will be signed. The
algorithm used depends on the ELF file type, such as relocatable or executable. The
elfsign
process now automatically uses the most appropriate data range
algorithm. For relocatable ELF files, elfsign
signs the ELF headers and
ELF sections, except for the signature section. For executable files,
elfsign
signs the ELF headers and ELF program segments. These
enhancements provide further protection from attack.
You can use the ‐d option to specify what part of the ELF file should be signed.
The default cryptographic algorithm used is rsa_sha256
. Use the
‐F option to specify a different cryptographic algorithm. Alternatively,
you can use the new ‐O option to specify an algorithm's OID, although that
OID will not be validated.
The elfsign data
subcommand creates a file containing all the data
from the ELF file to be signed, rather than creating a file with a digest. Therefore,
signing servers can create a signature without needing to parse and extract data from the
ELF file. Since the elfsign
functionality and an Oracle Solaris system are no
longer needed for signature generation, signatures can be computed off-site.
Note:
Theelfsign
command continues to support the previous
elfsign
formats. Verified boot, however, accepts the new
elfsign
format and sends a warning or error message when an older
format is used.
For more information and examples, see the elfsign(1) man page.
Plugins to the Cryptographic Framework
Third parties can plug their providers into the Cryptographic Framework. A third-party provider can be one of the following objects:
-
PKCS #11 shared library
-
Loadable kernel software module, such as an encryption algorithm, MAC function, or digest function
-
Kernel device driver for a hardware accelerator
The objects from a provider must be signed with a certificate from Oracle. The certificate request is based on a private key that the third party selects, and a certificate that Oracle provides. The certificate request is sent to Oracle, which registers the third party and then issues the certificate. The third party then signs its provider object with the certificate from Oracle.
The loadable kernel software modules and the kernel device drivers for hardware accelerators must also register with the kernel. Registration is through the Cryptographic Framework SPI (service provider interface).
Cryptographic Framework and Zones
The global zone and each non-global zone has its own
/system/cryptosvc
service. When the cryptographic service is enabled or
refreshed in the global zone, the kcfd
daemon starts in the global zone,
user-level policy for the global zone is set, and kernel policy for the system is set. When
the service is enabled or refreshed in a non-global zone, the kcfd
daemon
starts in the zone, and user-level policy for the zone is set. Kernel policy was set by the
global zone.
For more information about zones, see Introduction to Oracle Solaris Zones. For more information about using SMF to manage persistent applications, see Chapter 1, Introduction to the Service Management Facility in Managing System Services in Oracle Solaris 11.4 and the smf(7) man page.
Cryptographic Sources and FIPS 140-2
FIPS 140-2 is a U.S. Government computer security standard for cryptography modules.
Oracle Solaris systems offer two providers of cryptographic algorithms that are approved for FIPS 140-2 Level 1.
-
The Cryptographic Framework of Oracle Solaris is a provider of two FIPS 140-2 approved modules. The userland module supplies cryptography for applications that run in user space. The kernel module provides cryptography for kernel-level processes.
-
Oracle Solaris 11.4 ships with FIPS 140-2 capable OpenSSL libraries which statically link to the Oracle OpenSSL FIPS Object Module (FOM) 1.0. The FOM provides cryptography for all consumers whose code supports FIPS 140-2. For more information, see About OpenSSL in FIPS 140-2 Mode in Oracle Solaris in Using a FIPS 140-2 Enabled System in Oracle Solaris 11.4.
-
The
ucrypto
provider – Provides low-level cryptographic routines to programs that cannot or should not use PKCS #11 or OpenSSL APIs.
Note the following key considerations:
-
Because FIPS 140-2 provider modules are CPU intensive, they are not enabled by default. As the system administrator, you are responsible for enabling the providers in FIPS 140-2 mode and configuring applications that use the FIPS 140-2 approved algorithms.
-
If you have a strict requirement to use only FIPS 140-2 validated cryptography, you must be running the Oracle Solaris 11.3 SRU 5.6 release. Oracle completed a FIPS 140-2 validation against the Cryptographic Framework in this specific release. Oracle Solaris 11.4 builds on this validated foundation and includes software improvements that address performance, functionality, and reliability. Whenever possible, you should configure Oracle Solaris 11.4 in FIPS 140-2 mode to take advantage of these improvements.
For more information, review the following:
Simple and Fast ucrypto Provider
The ucrypto
provider enables you to
directly access user-level cryptographic primitives.
Note:
Cryptographic primitives are well-established, low-level algorithms that function as basic building blocks in security systems. Primitives are designed to perform single tasks in a highly reliable fashion.
ucrypto
is an alternative to the Cryptographic Framework.
ucrypto
provides user-level cryptographic support only, and is intended for
use by applications with simple needs for pure cryptographic functionality. In particular,
ucrypto
is useful when programs cannot or should not use PKCS #11 or OpenSSL
APIs. The faster path to cryptographic functionality through ucrypto
can
significantly improve the performance of applications.
ucrypto
meets the requirements for FIPS 140-2 validation. The cryptographic
library for ucrypto
, libucrypto
, includes all
cryptographic algorithms supported by Oracle Solaris. pkcs11_softtoken
is a
consumer of libucrypto
.
Operations Supported by the ucrypto Provider
The ucrypto
provider supports atomic and multi-part cryptographic
operations with no locking and no session management. Atomic operations are performed using
one function call. Each multi-part operation uses a series of three function calls to
initialize, update zero or more times, and finalize each cryptographic operation.
Note:
During multi-part operations, the context is maintained in the caller's address space. The caller has the responsibility to pass the untouched context between multi-part operations and to ensure that the context is not used by multiple threads at the same time.Table 1-1
ucrypto
Operations
Cryptographic Operation | Description | Function |
---|---|---|
Encryption |
Performs atomic or multi-part encryption |
crypto_encrypt |
Decryption |
Performs atomic or multi-part decryption |
crypto_decrypt |
Signing |
Performs digital signature operations on atomic or multi-part data |
crypto_sign |
Verification |
Verifies a digital signature on atomic or multi-part data |
crypto_verify |
Digest |
Performs digest operations on atomic or multi-part data |
crypto_digest |
Message authentication code (Mac) operations |
Computes a message authentication code for atomic or multi-part data |
crypto_mac |
Symmetric and asymmetric key generation |
Generates keys for symmetric operations or key pairs for asymmetric operations |
crypto_keygen |
Utility functions |
Performs various tasks such as returning the ID number for a specified mechanism |
crypto_util |
For further
information, review the libucrypto*
man pages on the command line. The
man pages list the algorithms and algorithm modes that each function supports.
Disabling libucrypto Mechanisms
Administrators can use the Service Management Facility (SMF) to disable the
libucrypto
mechanisms. Each mechanism is a property in the
svc:/system/cryptosvc
service. The properties are stated using the
following format:
policy/libucrypto/algorithm-name
policy/libucrypto/algorithm-name{-[mode]}
For example, to disable the deprecated CRYPTO_MD5
algorithm, type the
following command:
# pfbash svccfg -s svc:/system/cryptosvc \ setprop policy/libucrypto/md5=disabled
where:
-
disabled
specifies that no functions of the algorithm are permitted. -
enabled
specifies that the algorithm is capable of performing all supported functions. For an encryption algorithm, both encryption and decryption are permitted. For signature algorithms, both signing and verification are permitted. Key or keypair generation for that algorithm is permitted. -
deprecated
means the algorithm should not be used to create any new cryptographic data. However, legacy data is still accessible. Decryption or verification is permitted. Encryption or signing is disabled. Key or keypair generation for that algorithm is not permitted.
Note:
Digests and MACs can only be enabled or disabled.For more information, see the setprop
subcommand description in the
svccfg
(8) man page.
OpenSSL and Oracle Solaris
Oracle Solaris supports two implementations of OpenSSL:
-
FIPS 140-2 capable OpenSSL
-
Non-FIPS 140-2 capable OpenSSL
Both implementations are compatible with the latest
OpenSSL version from the OpenSSL project. Use the openssl version
command to
determine the OpenSSL version that is running on your system. This version is
enhanced by code that incorporates Oracle Solaris features, such as rights profiles, into the OpenSSL project version. The libraries of the FIPS 140-2 and non-FIPS 140-2
OpenSSL implementations are API/ABI compatible.
While both implementations are present in the operating system, only one implementation can be active at a time. For an example of installing the FIPS 140-2 capable OpenSSL and switching implementations, see Example of Running in FIPS 140-2 Mode on an Oracle Solaris 11.4 System in Using a FIPS 140-2 Enabled System in Oracle Solaris 11.4.