In the Oracle Solaris operating system, application software is delivered in units that are called packages. A package is a collection of files that are required for the distribution and installation of a software product. Packages are usually designed and built by the application developer after the development of the application code is complete. For general information on packaging software applications, see Application Packaging Developer’s Guide.
Packaging a cryptographic provider has two additional requirements:
The developer must supply input files that add the application to the configuration files that manage the cryptographic framework.
The developer must supply an X.509 certificate to indicate compliance with the United States government's export laws. For testing purposes, the certificate can be generated prior to obtaining U.S. government approval. A package must have approval and a signed provider to be shipped.
The United States government restricts the export of open cryptographic interfaces, which are also referred to as crypto-with-a-hole. Due to this restriction, all vendors of providers must obtain export approval from the U.S. government. The vendor needs to request a certificate from Oracle Corporationto indicate compliance with export laws. The vendor then signs the provider electronically and ships the software with the certificate.
In the export approval process, the strength of your encryption determines the countries in which the software can be used.
The U.S. government defines two export categories for encryption products that are manufactured in the U.S.A.:
Retail encryption products – Retail encryption products are permitted to be shipped to all countries except for designated nations that are considered to be security threats.
Non-retail encryption products – Non-retail encryption products are permitted for domestic use only and to countries that have been exempted by the U.S. government.
If your provider has non-retail approval, you can make the provider eligible for retail approval. Retail approval can be obtained by disabling the use of your provider by certain callers such as IPsec. Oracle provides two different certificates in this case, for restricted and unrestricted use. You indicate this situation in the certificate request process, To Request a Certificate for Signing a Provider. In addition, a special activation file must be generated, signed, and shipped with the provider. See To Generate an Activation File for Retail Export.
A third-party developer of a user-level cryptographic provider application completes the following process:
Acquire a certificate from Oracle Corporation. Then, sign the library. See Adding Signatures to Providers.
Ship the certificate with the package. The certificate must be placed in the /etc/crypto/certs directory.
Add the pkcs11conf class into the CLASSES string of the pkginfo file. The following line should be added:
CLASS=none pkcs11conf
Create an input file pkcs11.conf in the etc/crypto directory.
The input file for user-level providers is named pkcs11.conf. This file specifies the path to the provider. The pkcs11.conf uses the following syntax for the entry:
filename
The entry is an absolute path to a file such as /opt/lib/$ISA/myProviderApp.so. This file is added to the configuration file when pkgadd is run. Note the $ISA expression in the path name. $ISA points to either a 32–bit version or a 64–bit version of the application, as needed.
Add the following line to the package's prototype file:
e pkcs11conf etc/crypto/pkcs11conf 0644 root sys
A third-party developer of a kernel-level cryptographic provider module completes the following process. For Solaris builds earlier than build 103, complete all steps. For Solaris build 103 or later, complete only the first two steps.
Acquire a certificate from Oracle Corporation. Then, sign the kernel software module or device driver. See Adding Signatures to Providers.
Ship the certificate with the package. The certificate should be placed in the /etc/crypto/certs directory.
The following steps are required only if you are using a Solaris build earlier than build 103. If you are using build 103 or later, the following steps are no longer required and are ignored.
Add the kcfconf class into the CLASSES string of the pkginfo file. The following line should be added:
CLASS=none kcfconf
Create an input file kcf.conf in the etc/crypto directory. This file is used to add software and hardware plug-ins to the kernel configuration file.
If the provider is a kernel software module with cryptographic mechanisms, use the following syntax for the entry:
provider-name:supportedlist=mech1,mech2,...
Base name for the kernel software module
Name of the cryptographic mechanism in the list
The following entry is an example of a kernel software module:
des:supportedlist=CKM_DES_CBC,CKM_DES_ECB,CKM_DES_CFB
If the provider is a device driver for cryptographic mechanisms, such as an accelerator card, then use the following syntax for the entry:
driver_names=devicedriver1,devicedriver2,...
Name of a device driver for a cryptographic device.
The following entry is an example of a device driver:
driver_names=dca