new featurescryptographic framework new featuresSolaris Cryptographic Framework This chapter describes the Solaris Cryptographic Framework. The following is a list of the information in this chapter.Solaris Cryptographic Framework Terminology in the Solaris Cryptographic Framework Scope of the Solaris Cryptographic Framework Administrative Commands in the Solaris Cryptographic Framework User-Level Commands in the Solaris Cryptographic Framework Plugins to the Solaris Cryptographic Framework Cryptographic Services and Zones To administer and use the Solaris Cryptographic Framework, see Chapter 14, Solaris Cryptographic Framework (Tasks). CryptokiPKCS #11 library Solaris Cryptographic Frameworkcryptographic framework cryptographic servicescryptographic framework cryptographic frameworkdescription 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.cryptographic frameworkconsumerscryptographic frameworkprovidersprovidersdefinition as pluginspluginsin cryptographic frameworkThe 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:User-level plugins – Shared objects that provide services by using PKCS #11 libraries, such as 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 the SSE2 instruction set and for SPARC hardware. Hardware plugins – Device drivers and their associated hardware accelerators. A hardware accelerator offloads expensive cryptographic functions from the operating system. The Sun Crypto Accelerator 1000 board is one example. PKCS #11 libraryin Solaris Cryptographic Frameworkcryptographic frameworkPKCS #11 libraryThe 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 Solaris Cryptographic Framework, in Solaris Security for Developers Guide. cryptographic frameworkdefinition of termscryptographic frameworkprovidersprovidersdefinition as pluginsThe following list of definitions and examples is useful when working with the cryptographic framework.algorithmsdefinition in cryptographic frameworkAlgorithms – Cryptographic algorithms. These 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 and ARCFOUR Asymmetric algorithms, such as Diffie-Hellman and RSA Hashing functions, such as MD5 consumersdefinition in cryptographic frameworkConsumers – Are 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 an ordinary user who runs the encrypt command Kernel operations, such as IPsec mechanismdefinition in cryptographic frameworkMechanism – Is 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. metaslotdefinition in cryptographic frameworkMetaslot – Is 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 figures out which actual slot should perform the operation. Metaslot capabilities are configurable, but configuration is not required. The metaslot is on by default. To configure the metaslot, see the cryptoadm1M man page. modedefinition in cryptographic frameworkMode – Is 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 two modes, CKM_AES_ECB and CKM_AES_CBC. policydefinition in cryptographic frameworkPolicy – Is 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 disabling of any mechanism would be an application of policy. The enabling of a disabled mechanism would also be an application of policy. providersdefinition in cryptographic frameworkProviders – Are cryptographic services that consumers use. Providers plug in to the framework, so are also called plugins.Examples of providers include:PKCS #11 libraries, such as pkcs11_softtoken.so Modules of cryptographic algorithms, such as aes and arcfour Device drivers and their associated hardware accelerators, such as the dca/0 accelerator slotdefinition in cryptographic frameworkSlot – Is 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. tokendefinition in cryptographic frameworkToken – In a slot, a token provides a logical view of a cryptographic device in the framework. cryptographic frameworkinteracting with The framework provides commands for administrators, for users, and for developers who supply providers:cryptographic frameworkcryptoadm commandcryptoadm commanddescriptionsvcadm commandadministering cryptographic frameworkAdministrative commands – The cryptoadm command provides a list subcommand to list the available providers and their capabilities. Ordinary 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 cryptoadm1M 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 svcadm1M 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 Protecting Files With the Solaris Cryptographic Framework (Task Map). cryptographic frameworkelfsign commandelfsign commanddescriptionBinary signatures for third-party providers – The elfsign command enables third parties to sign binaries for use within the framework. Binaries that can be added to the framework are PKCS #11 libraries, kernel algorithm modules, and hardware device drivers. To use the elfsign command, see Appendix F, Packaging and Signing Cryptographic Providers, in Solaris Security for Developers Guide. cryptographic frameworkcryptoadm command administeringcryptographic framework commandscryptographic framework commands administeringmetaslot metaslotadministering 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:Displaying cryptographic provider information Disabling or enabling provider mechanisms Solaris 10 1/06: Disabling or enabling the metaslot daemonskcfdsvcadm commandadministering cryptographic frameworkThe 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 smf5 and svcadm1M man pages. cryptographic frameworkuser-level commands commandsuser-level cryptographic commands encryptingusing user-level commands 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.digest commanddescriptiondigest 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 MD5 are examples of digest functions. mac commanddescriptionmac command – Computes a message authentication code (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 md5_hmac mechanisms can compute a MAC. encrypt commanddescriptionencrypt 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, DES, 3DES (Triple-DES), and ARCFOUR mechanisms for user encryption. decrypt commanddescriptiondecrypt 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 commanddescriptioncryptographic frameworkelfsign commandThe 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 Solaris Security for Developers Guide. cryptographic frameworkconnecting providers Third parties can plug their providers into the Solaris Cryptographic Framework. A third-party provider can be one of the following objects:providersconnecting to cryptographic frameworkPKCS #11 shared library Loadable kernel software module, such as an encryption algorithm, MAC function, or digest function Kernel device driver for a hardware accelerator providerssigningcryptographic frameworksigning providerssigning providerscryptographic frameworkThe 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.providersregisteringcryptographic frameworkregistering providersregistering providerscryptographic frameworkThe 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).providersinstallingcryptographic frameworkinstalling providersinstallingproviders in cryptographic frameworkTo 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 Solaris Security for Developers Guide. cryptographic frameworkzones and administeringcryptographic framework and zones zonescryptographic framework and 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: Virtualization Using the Solaris Operating System. For more information on the service management facility that manages persistent applications, see Chapter 15, Managing Services (Overview), in System Administration Guide: Basic Administration and the smf5 man page.