Managing Encryption and Certificates in Oracle^® Solaris 11.3

Introduction to 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  Cryptographic Framework Levels

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), libsasl, and IKE (Internet Key Protocol). The kernel SSL (kssl) proxy uses the Cryptographic Framework. For more information, see SSL Kernel Proxy Encrypts Web Server Communications in Securing the Network in Oracle Solaris 11.3 and the ksslcfg(1M) man page.

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.

The framework enables providers of cryptographic services to have their services used by many consumers in Oracle Solaris. Another name for providers is plugins. The framework supports three types of plugins:

• 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 and Oracle's ncp and n2cp device drivers are one example. A hardware accelerator offloads expensive cryptographic functions from the operating system. Sun Crypto Accelerator 6000 board is one example.

The framework implements a standard interface, the PKCS #11, v2.20 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 Cryptographic Framework Levels.

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 Diffie-Hellman and 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.

• 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(1M) 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(5), and cryptoadm(1M) 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 and arcfour

  • 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 the cryptoadm list and the cryptoadm --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(1M) man page.

  The svcadm command is used to manage the kcfd daemon and to refresh cryptographic policy in the kernel. For more information, see the svcadm(1M) man page.

• User-level commands – The digest and mac commands provide file integrity services. The encrypt and decrypt commands protect files from eavesdropping. To use these commands, see Figure 2, Table 2, Protecting Files With the Cryptographic Framework Task Map.

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(5) and svcadm(1M) 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. The sha1_mac and sha384_hmac mechanisms can compute a MAC.

• encrypt command – Encrypts files or stdin with a symmetric cipher. The encrypt -l command lists the algorithms that are available. Mechanisms that are listed under a user-level library are available to the encrypt command. The framework provides AES, 3DES (Triple-DES), and Camellia mechanisms for user encryption.

• decrypt command – Decrypts files or stdin that were encrypted with the encrypt command. The decrypt 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. The elfsign command has subcommands to request a certificate, 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.

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, which manages the Cryptographic Framework. 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.3 and the smf(5) 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.

• The OpenSSL object module provides FIPS 140-2 approved cryptography for SunSSH and web applications. For information about the implementations of Secure Shell in Oracle Solaris, see About Secure Shell in Managing Secure Shell Access in Oracle Solaris 11.3.

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. Later Oracle Solaris releases build on this validated foundation and include software improvements that address performance, functionality, and reliability. Whenever possible, you should configure Oracle Solaris in FIPS 140-2 mode to take advantage of these improvements.

For more information, review the following:

• Using a FIPS 140-2 Enabled System in Oracle Solaris 11.3

• Creating a Boot Environment With FIPS 140-2 Enabled