Oracle Solaris Security for Developers Guide

Packaging Cryptographic Provider Applications and Modules

In the 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 about 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.

Complying with U.S. Government Export Laws

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 Sun Microsystems, Inc. to 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. Sun 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.

Packaging User-Level Provider Applications

A third-party developer of a user-level cryptographic provider application completes the following process:

Acquire a certificate from Sun Microsystems, Inc. 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
```

Packaging Kernel-Level Provider Modules

A third-party developer of a kernel-level cryptographic provider module completes the following process:

Acquire a certificate from Sun Microsystems, Inc. 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.
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,...
```
  provider-name
  
  Base name for the kernel software module
  
  mech*
  
  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,...
```
  devicedriver*
  
  Name of a device driver for a cryptographic device.
  
  The following entry is an example of a device driver:
```
driver_names=dca
```