System Administration Guide: Security Services

Chapter 13 Solaris Cryptographic Framework (Overview)

This chapter describes the Solaris Cryptographic Framework. The following is a list of the information in this chapter.

To administer and use the Solaris Cryptographic Framework, see Chapter 14, Solaris Cryptographic Framework (Tasks).

What's New in the Solaris Cryptographic Framework?

Solaris 10 1/06: The framework library,, contains a new component, the metaslot. The metaslot serves as a single virtual slot with the combined capabilities of all tokens and slots that have been installed in the framework. Effectively, the metaslot enables an application to transparently connect with any available cryptographic service through a single slot.

Solaris Cryptographic Framework

The Solaris 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 following standard: RSA Security Inc. PKCS #11 Cryptographic Token Interface (Cryptoki).

At the kernel level, the framework currently handles cryptographic requirements for Kerberos and IPsec. User-level consumers include libsasl and IKE.

Export law in the United States requires that the use of open cryptographic interfaces be restricted. The Solaris Cryptographic Framework satisfies the current law by requiring that kernel cryptographic providers and PKCS #11 cryptographic providers be signed. For further discussion, see Binary Signatures for Third-Party Software.

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

The framework implements a standard interface, the PKCS #11, v2.11 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 pkgadd utility installs the third-party software. For a diagram of the major components of the framework, see Chapter 8, Introduction to the Oracle Solaris Cryptographic Framework, in Oracle Solaris Security for Developers Guide.

Terminology in the Solaris Cryptographic Framework

The following list of definitions and examples is useful when working with the cryptographic framework.

Scope of the Solaris Cryptographic Framework

The framework provides commands for administrators, for users, and for developers who supply providers:

Administrative Commands in the Solaris 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. The cryptoadm command manages the following:

The svcadm command is used to enable, refresh, and disable the cryptographic services daemon, kcfd. This command is part of the Solaris service management facility, smf. 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 Solaris Cryptographic Framework

The Solaris Cryptographic Framework provides user-level commands to check the integrity of files, to encrypt files, and to decrypt files. A separate command, elfsign, enables providers to sign binaries for use with the framework.

Binary Signatures for Third-Party Software

The elfsign command provides a means to sign providers to be used with the Solaris Cryptographic Framework. Typically, this command is run by the developer of a provider.

The elfsign command has subcommands to request a certificate from Sun and to sign binaries. Another subcommand verifies the signature. Unsigned binaries cannot be used by the Solaris Cryptographic Framework. To sign one or more providers requires the certificate from Sun and the private key that was used to request the certificate. For more information, see Appendix F, Packaging and Signing Cryptographic Providers, in Oracle Solaris Security for Developers Guide.

Plugins to the Solaris Cryptographic Framework

Third parties can plug their providers into the Solaris Cryptographic Framework. A third-party provider can be one of the following objects:

The objects from a provider must be signed with a certificate from Sun. The certificate request is based on a private key that the third party selects, and a certificate that Sun provides. The certificate request is sent to Sun, which registers the third party and then issues the certificate. The third party then signs its provider object with the certificate from Sun.

The loadable kernel software modules and the kernel device drivers for hardware accelerators must also register with the kernel. Registration is through the Solaris Cryptographic Framework SPI (service provider interface).

To install the provider, the third party provides a package that installs the signed object and the certificate from Sun. The package must include the certificate, and enable the administrator to place the certificate in a secure directory. For more information, see the Appendix F, Packaging and Signing Cryptographic Providers, in Oracle Solaris Security for Developers Guide.

Cryptographic Services 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 on zones, see Part II, Zones, in System Administration Guide: Oracle Solaris Containers-Resource Management and Oracle Solaris Zones. For more information on the service management facility that manages persistent applications, see Chapter 18, Managing Services (Overview), in System Administration Guide: Basic Administration and the smf(5) man page.