Using the Cryptographic Framework

3 Using the Cryptographic Framework

This chapter describes how to use the Cryptographic Framework, and covers the following topics:

Protecting Files With the Cryptographic Framework

This section describes how to generate symmetric keys, how to create checksums for file integrity, and how to protect files from eavesdropping. System users can run the commands described in this section, and developers can write scripts that use them.

To configure your system in FIPS 140-2 mode, you must use FIPS 140-2 validated algorithms, modes, and key lengths. See FIPS 140-2 Algorithms in the Cryptographic Framework in Using a FIPS 140-2 Enabled System in Oracle Solaris 11.4.

The Cryptographic Framework can help you protect your files. The following task map points to procedures for listing the available algorithms, and for protecting your files cryptographically.

Table 3-1 Protecting Files With the Cryptographic Framework Task Map

Task	Description	For Instructions
Generate a symmetric key.	Generates a key of user-specified length. Optionally, stores the key in a file or in a PKCS #11 keystore. For FIPS 140-2 approved mode, select a key type, mode, and key length that has been validated for FIPS 140-2. See FIPS 140-2 Algorithms in the Cryptographic Framework in Using a FIPS 140-2 Enabled System in Oracle Solaris 11.4.	How to Generate a Symmetric Key by Using the pktool Command
Provide a checksum that ensures the integrity of a file.	Verifies that the receiver's copy of a file is identical to the file that was sent.	How to Compute a Digest of a File
Protect a file with a message authentication code (MAC).	Verifies to the receiver of your message that you were the sender.	How to Compute a MAC of a File
Encrypt a file, and then decrypt the encrypted file.	Protects the content of files by encrypting the file. Provides the encryption parameters to decrypt the file.	How to Encrypt and Decrypt a File

How to Generate a Symmetric Key by Using the pktool Command

Some applications require a symmetric key for encryption and decryption of communications. In this procedure, you create a symmetric key and store it.

If your site has a random number generator, you can use the generator to create a random number for the key. This procedure does not use your site's random number generator.

If you plan to use a keystore, create it.

To create and initialize a PKCS #11 keystore, see How to Generate a Passphrase by Using the pktool setpin Command.
Generate a random number for use as a symmetric key.

For FIPS 140-2 approved algorithms, select a key length that has been validated for FIPS 140-2. See FIPS 140-2 Algorithms in the Cryptographic Framework in Using a FIPS 140-2 Enabled System in Oracle Solaris 11.4.

Use one of the following methods.
- Generate a key and store it in a file.
  
  The advantage of a file-stored key is that you can extract the key from this file to use in an application's key file, such as the /etc/inet/secret/ipseckeys file or IPsec. The usage statement shows the arguments.
```
$ pktool genkey keystore=file
...genkey keystore=file
outkey=key-fn
[ keytype=aes|arcfour|des|3des|generic ]
[ keylen=key-size (AES, ARCFOUR or GENERIC only)]
[ print=y|n ]
```
  outkey= key-fn
  
  The filename where the key is stored.
  
  keytype= specific-symmetric-algorithm
  
  For a symmetric key of any length, the value is generic. For a particular algorithm, specify aes, arcfour, des, or 3des.
  
  keylen= size-in-bits
  
  The length of the key in bits. The number must be divisible by 8. Do not specify for des or 3des.
  
  print=y
  
  Prints the key to the terminal window. By default, the value of print is n.
- Generate a key and store it in a PKCS #11 keystore.
  
  The advantage of the PKCS #11 keystore is that you can retrieve the key by its label. This method is useful for keys that encrypt and decrypt files. You must complete Step 1 before using this method. The usage statement shows the arguments. The brackets around the keystore argument indicate that when the keystore argument is not specified, the key is stored in the PKCS #11 keystore.
```
$ pktool genkey keystore=pkcs11
...genkey [ keystore=pkcs11 ]
label=key-label
[ keytype=aes|arcfour|des|3des|generic ]
[ keylen=key-size (AES, ARCFOUR or GENERIC only)]
[ token=token[:manuf[:serial]]]
[ sensitive=y|n ]
[ extractable=y|n ]
[ print=y|n ]
```
  label= key-label
  
  A user-specified label for the key. The key can be retrieved from the keystore by its label.
  
  keytype= specific-symmetric-algorithm
  
  For a symmetric key of any length, the value is generic. For a particular algorithm, specify aes, arcfour, des, or 3des.
  
  keylen= size-in-bits
  
  The length of the key in bits. The number must be divisible by 8. Do not specify for des or 3des.
  
  token= token
  
  The token name. By default, it is Sun Software PKCS#11 softtoken.
  
  sensitive=n
  
  Specifies the sensitivity of the key. When the value is y, the key cannot be printed by using the print=y argument. By default, the value of sensitive is n.
  
  extractable=y
  
  Specifies that the key can be extracted from the keystore. Specify n to prevent the key from being extracted.
  
  print=y
  
  Prints the key to the terminal window. By default, the value of print is n.

Verify that the key exists.

Use one of the following commands, depending on where you stored the key.

Verify the key in the key-fn file.

$ pktool list keystore=file objtype=key [infile=key-fn]
Found n keys.
Key #1 - keytype:location (keylen)

Verify the key in the PKCS #11 keystore.

For PKCS #11, use the following command:

$ pktool list keystore=pkcs11 objtype=key
Enter PIN for keystore:
Found n keys.
Key #1 - keytype:location (keylen)

Example 3-1 Creating a Symmetric Key by Using the pktool Command

In the following example, a user creates a PKCS #11 keystore for the first time and then generates a large symmetric key for an application. Finally, the user verifies that the key is in the keystore.

Note that the initial password for a PKCS #11 keystore is changeme.

$ pktool setpin
Create new passphrase:xxxxxxxx
Re-enter new passphrase:xxxxxxxx
Passphrase changed.
$ pktool genkey label=specialappkey keytype=generic keylen=1024
Enter PIN for Sun Software PKCS#11 softtoken  :xxxxxxxx

$ pktool list objtype=key
Enter PIN for Sun Software PKCS#11 softtoken  :Type password
No.      Key Type      Key Len.      Key Label
----------------------------------------------------
Symmetric keys:
1        Symmetric     1024          specialappkey

Example 3-2 Creating a FIPS 140-2 Approved AES Key by Using the pktool Command

In the following example, a secret key for the AES algorithm is created using a FIPS 140-2 approved algorithm and key length. The key is stored in a local file for later decryption. The command protects the file with 400 permissions. When the key is created, the print=y option displays the generated key in the terminal window.

The user who owns the keyfile retrieves the key by using the od command.

$ pktool genkey keystore=file outkey=256bit.file1 keytype=aes keylen=256 print=y
Key Value ="aaa2df1d10f02eaee2595d48964847757a6a49cf86c4339cd5205c24ac8c8873"
$ od -x 256bit.file1

0000000 aaa2 df1d 10f0 2eae e259 5d48 9648 4775
0000020 7a6a 49cf 86c4 339c d520 5c24 ac8c 8873
0000040

Example 3-3 Creating a Symmetric Key for IPsec Security Associations

In the following example, the administrator manually creates the keying material for IPsec SAs and stores them in files. Then, the administrator copies the keys to the /etc/inet/secret/ipseckeys file, destroys the original files, and sends the ipseckeys file to the communicating system by a secure mechanism.

First, the administrator creates and displays the keys that the IPsec policy requires:

$ pktool genkey keystore=file outkey=ipencrin1 keytype=aes keylen=256 print=y
Key Value ="294979e512cb8e79370dabeca...................dc3fcbb849e78d2d6bd2049"
$ pktool genkey keystore=file outkey=ipencrout1 keytype=aes keylen=256 print=y
Key Value ="9678f80e33406c86e3d1686e5...................0406bd0434819c20d09d204"
$ pktool genkey keystore=file outkey=ipspi1 keytype=aes keylen=32 print=y
Key Value ="acb...0"
$ pktool genkey keystore=file outkey=ipspi2 keytype=aes keylen=32 print=y
Key Value ="191...5"
$ pktool genkey keystore=file outkey=ipsha21 keytype=aes keylen=256 print=y
Key Value ="659c20f2d6c3f9570bcee93e9...................3369f72c5c786af4177fe9e"
$ pktool genkey keystore=file outkey=ipsha22 keytype=aes keylen=256 print=y
Key Value ="b041975a0e1fce0503665c396....................cf87b0a837b2da5d82c810"

Then, the administrator creates the following /etc/inet/secret/ipseckeys file:

##   SPI values require a leading 0x.
##   Backslashes indicate command continuation.
##
## for outbound packets on this system
add esp spi 0xacb...20 \
src 192.0.2.1 dst 192.0.2.2 \
encr_alg aes auth_alg sha256  \
encrkey  294979e512cb8e79370dabeca...................dc3fcbb849e78d2d6bd2049 \
authkey  659c20f2d6c3f9570bcee93e9...................3369f72c5c786af4177fe9e
##
## for inbound packets
add esp spi 0x191...5 \
src 192.0.2.2 dst 192.0.2.1 \
encr_alg aes auth_alg sha256  \
encrkey 9678f80e33406c86e3d1686e5...................0406bd0434819c20d09d204 \
authkey b041975a0e1fce0503665c396....................cf87b0a837b2da5d82c810

After verifying that the syntax of the ipseckeys file is valid, the administrator destroys the original key files.

$ ipseckey -c /etc/inet/secret/ipseckeys
$ rm ipencrin1 ipencrout1 ipspi1 ipspi2 ipsha21 ipsha22

The administrator copies the ipseckeys file to the communicating system by using the ssh command or another secure mechanism. On the communicating system, the protections are reversed. The first entry in the ipseckeys file protects inbound packets, and the second entry protects outbound packets. No keys are generated on the communicating system.

To proceed with using the key to create a message authentication code (MAC) for a file, see How to Compute a MAC of a File.

How to Compute a Digest of a File

When you compute a digest of a file, you can check to see that the file has not been tampered with by comparing digest outputs. A digest does not alter the original file.

digest command syntax List the available digest algorithms.
```
$ digest -l
sha1
md5
sha224
sha256
sha384
sha512
sha512_t
sha3_224
sha3_256
sha3_384
sha3_512
```
Note:
Whenever possible, select a FIPS 140-2 approved algorithm. See FIPS 140-2 Algorithms in the Cryptographic Framework in Using a FIPS 140-2 Enabled System in Oracle Solaris 11.4.
Compute the digest of the file and save the digest listing.
Provide an algorithm with the digest command.
```
$ digest -v -a algorithm input-file > digest-listing              
```
‐v
Displays the output in the following format:
```
algorithm (input-file) = digest                       
```
‐a algorithm

The algorithm to use to compute a digest of the file. Type the algorithm as the algorithm appears in the output of Step 1.

Note:
Whenever possible, select a FIPS 140-2 approved algorithm. See FIPS 140-2 Algorithms in the Cryptographic Framework in Using a FIPS 140-2 Enabled System in Oracle Solaris 11.4.

input-file

The input file for the digest command.

digest-listing

The output file for the digest command.

Example 3-4 Computing a Digest With a SHA2 Mechanism

In the following example, the digest command uses a SHA2 mechanism to provide a directory listing. The results are placed in a file.

$ digest -v -a sha512 docs/* > $HOME/digest.docs.legal.05.07
$ more ~/digest.docs.legal.05.07
sha512 (docs/legal1) = a269d...c618e1bf19b3d5c9f835242708eb2b572d7b
sha512 (docs/legal2) = 57be3...59a7168564296c142715cc9ed979dd838a7b
sha512 (docs/legal3) = ed31d...0fb3b80d4cd58327bcc29b2e7b90a0af6770
sha512 (docs/legal4) = 67ce1...0ba0c55695614329110d0686bc2773630b5f

How to Compute a MAC of a File

A message authentication code, or MAC, computes a digest for the file and uses a secret key to further protect the digest. A MAC does not alter the original file.

mac command syntax List the available mechanisms.
```
$ mac -l
Algorithm       Keysize:  Min   Max
-----------------------------------
sha1_hmac                   8   512
md5_hmac                    8   512
sha224_hmac                 8   512
sha256_hmac                 8   512
sha384_hmac                 8  1024
sha512_hmac                 8  1024
sha512_t_hmac               8  1024
```
Note:
Each supported algorithm is an alias to the most commonly used and least restricted version of a particular algorithm type. The preceding output shows available algorithm names and the keysize for each algorithm. Whenever possible, use a supported algorithm that matches a FIPS 140-2 approved algorithm with a FIPS 140-2 approved key length, listed at FIPS 140-2 Algorithms in the Cryptographic Framework in Using a FIPS 140-2 Enabled System in Oracle Solaris 11.4.
Generate a symmetric key of the appropriate length.
You can provide either a passphrase from which a key will be generated or you can provide a key.
- If you provide a passphrase, you must store or remember the passphrase. If you store the passphrase online, the passphrase file should be readable only by you.
- If you provide a key, it must be the correct size for the mechanism. You can use the pktool command. For the procedure and some examples, see How to Generate a Symmetric Key by Using the pktool Command.
Create a MAC for a file.
Provide a key and use a symmetric key algorithm with the mac command.
```
$ mac [-v] -a algorithm [-k keyfile | -K key-label [-T token]] input-file
```
‐v
Displays the output in the following format:
```
algorithm (input-file) = mac
```
‐a algorithm

The algorithm to use to compute the MAC. Type the algorithm as the algorithm appears in the output of the mac -l command.

‐k keyfile

The file that contains a key of algorithm-specified length.

‐K key-label

The label of a key in the PKCS #11 keystore.

‐T token

The token name. By default, it is Sun Software PKCS#11 softtoken. It is used only when the ‐K key-label option is used.

input-file

The input file for the MAC.

Example 3-5 Computing a MAC With SHA256_HMAC and a Passphrase

In the following example, the email attachment is authenticated with the SHA256_HMAC mechanism and a key that is derived from a passphrase. The MAC listing is saved to a file. If the passphrase is stored in a file, the file should not be readable by anyone but the user.

$ mac -v -a sha256_hmac email.attach
Enter passphrase: Type passphrase
sha256_hmac (email.attach) = 9c1ee...d6eb74e5d693b7605c96a23df238e52
$ echo "sha256_hmac (email.attach) = 9c1ee...d6eb74e5d693b7605c96a23df238e52" \
>> ~/sha256hmac.daily.05.13

Example 3-6 Computing a MAC With SHA256_HMAC and a Key File

In the following example, the directory manifest is authenticated with the SHA256_HMAC mechanism and a secret key. The results are placed in a file.

$ mac -v -a sha256_hmac \
-k $HOME/keyf/05.07.mack64 docs/* > $HOME/mac.docs.legal.05.07
$ more ~/mac.docs.legal.05.07
sha256_hmac (docs/legal1) = e1eb...814a595fb6f0aa8c77f6ef35a7f24ae07d1b9a55
sha256_hmac (docs/legal2) = 0460...88a34b895687ecfd97d1647b90fe3618f5114ff9
sha256_hmac (docs/legal3) = 9c1e...eee8a9913d6eb74e5d693b7605c96a23df238e52
sha256_hmac (docs/legal4) = 389f...cb340d33cca5e4aaa18534c06426d32594bdedf6

Example 3-7 Computing a MAC With SHA256_HMAC and a Key Label

In the following example, the directory manifest is authenticated with the SHA256_HMAC mechanism and a secret key. The results are placed in the user's PKCS #11 keystore. The user initially created the keystore and the password to the keystore by using the pktool setpin command.

$ mac -a sha256_hmac -K legaldocs0507 docs/*
Enter pin for Sun Software PKCS#11 softtoken:Type password

To retrieve the MAC from the keystore, the user uses the verbose option, and provides the key label and the name of the directory that was authenticated.

$ mac -v -a sha256_hmac -K legaldocs0507  docs/*
Enter pin for Sun Software PKCS#11 softtoken:Type password
sha256_hmac (docs/legal1) = e1eb...814a595fb6f0aa8c77f6ef35a7f24ae07d1b9a55
sha256_hmac (docs/legal2) = 0460...88a34b895687ecfd97d1647b90fe3618f5114ff9
sha256_hmac (docs/legal3) = 9c1e...eee8a9913d6eb74e5d693b7605c96a23df238e52
sha256_hmac (docs/legal4) = 389f...cb340d33cca5e4aaa18534c06426d32594bdedf6

How to Encrypt and Decrypt a File

When you encrypt a file, the original file is not removed or changed. The output file is encrypted.

For solutions to common errors related to the encrypt command, see the section that follows the examples.

Note:

When encrypting and decrypting files, try to use FIPS 140-2 approved algorithms with approved key lengths whenever possible. See FIPS 140-2 Algorithms in the Cryptographic Framework in Using a FIPS 140-2 Enabled System in Oracle Solaris 11.4. Run the encrypt -l command to view available algorithms and their key lengths.

Create a symmetric key of the appropriate length.
You can provide either a passphrase from which a key will be generated or you can provide a key.
- If you provide a passphrase, you must store or remember the passphrase. If you store the passphrase online, the passphrase file should be readable only by you.
- If you provide a key, it must be the correct size for the mechanism. You can use the pktool command. For the procedure and some examples, see How to Generate a Symmetric Key by Using the pktool Command.

List the encryption algorithms.

$ encrypt -l
Algorithm       Keysize:  Min   Max (bits)
------------------------------------------
aes                       128   256
arcfour                     8  2048
des                        64    64
3des                      128   192
camellia                  128   256

Encrypt a file.
Provide a key and use a symmetric key algorithm with the encrypt command.
```
$ encrypt -a algorithm [-v] \
[-k keyfile | -K key-label [-T token]] [-i input-file] [-o output-file]  
            
```
‐a algorithm

The algorithm to use to encrypt the file. Type the algorithm as the algorithm appears in the output of the encrypt -l command. Whenever possible, select a FIPS 140-2 approved algorithm. See “FIPS 140-2 Algorithms in the Cryptographic Framework” in Using a FIPS 140-2 Enabled System in Oracle Solaris 11.4.

‐k keyfile

The file that contains a key of algorithm-specified length. The key length for each algorithm is listed, in bits, in the output of the encrypt -l command.

‐K key-label

The label of a key in the PKCS #11 keystore.

‐T token

The token name. By default, it is Sun Software PKCS#11 softtoken. It is used only when the ‐K key-label option is used.

‐i input-file

The input file that you want to encrypt. This file is left unchanged by the command.

‐o output-file

The output file that is the encrypted form of the input file.

Example 3-8 Creating an AES Key for Encrypting Your Files

In the following example, a user creates and stores an AES key in an existing PKCS #11 keystore for use in encryption and decryption. The user can verify that the key exists and can use the key, but cannot view the key itself.

$ pktool genkey label=MyAESkeynumber1 keytype=aes keylen=256
Enter PIN for Sun Software PKCS#11 softtoken  :xxxxxxxx

$ pktool list objtype=key
Enter PIN for Sun Software PKCS#11 softtoken  :xxxxxxxx
No.      Key Type      Key Len.      Key Label
----------------------------------------------------
Symmetric keys:
1        AES           256           MyAESkeynumber1

To use the key to encrypt a file, the user retrieves the key by its label.

$ encrypt -a aes -K MyAESkeynumber1 -i encryptthisfile -o encryptedthisfile

To decrypt the encryptedthisfile file, the user retrieves the key by its label.

$ decrypt -a aes -K MyAESkeynumber1 -i encryptedthisfile -o sameasencryptthisfile

Example 3-9 Encrypting and Decrypting With AES and a Passphrase

In this example, a file is encrypted with the AES algorithm. The key is generated from the passphrase. If the passphrase is stored in a file, the file should not be readable by anyone but the user.

$ encrypt -a aes -i ticket.to.ride -o ~/enc/e.ticket.to.ride
Enter passphrase:    xxxxxxxx
Re-enter passphrase: xxxxxxxx

The input file, ticket.to.ride, still exists in its original form.

To decrypt the output file, the user uses the same passphrase and encryption mechanism that encrypted the file.

$ decrypt -a aes -i ~/enc/e.ticket.to.ride -o ~/d.ticket.to.ride
Enter passphrase: xxxxxxxx

Example 3-10 Encrypting and Decrypting With AES and a Key File

In this example, a file is encrypted with the AES algorithm. AES mechanisms use a key of 128 bits, or 16 bytes.

$ encrypt -a aes -k ~/keyf/05.07.aes128 \
            -i ticket.to.ride -o ~/enc/e.ticket.to.ride

The input file, ticket.to.ride, still exists in its original form.

To decrypt the output file, the user uses the same key and encryption mechanism that encrypted the file.

$ decrypt -a aes -k ~/keyf/05.07.aes128  \
            -i ~/enc/e.ticket.to.ride -o ~/d.ticket.to.ride

The following messages indicate that the key that you provided to the encrypt command is not permitted by the algorithm that you are using.

encrypt: unable to create key for crypto operation: CKR_ATTRIBUTE_VALUE_INVALID
encrypt: failed to initialize crypto operation: CKR_KEY_SIZE_RANGE

If you pass a key that does not meet the requirements of the algorithm, you must supply a better key by using one of the following methods:

Use a passphrase. The framework then provides a key that meets the requirements.
Pass a key size that the algorithm accepts. For example, the DES algorithm requires a key of 64 bits. The 3DES algorithm requires a key of 192 bits.

Administering the Cryptographic Framework

This section describes how to administer the software providers and the hardware providers in the Cryptographic Framework. You can, for example, disable the implementation of an algorithm from one software provider. You can then force the system to use the algorithm from a different software provider.

Caution:

Do not disable the default providers that are included with the Oracle Solaris operating system. In particular, the pkcs11_softtoken provider is a required part of Oracle Solaris and must not be disabled by using the cryptoadm command. Some of the cryptographic algorithms may be hardware accelerated. Administrators can run the following command to view a list of cryptographic algorithms for their system and check the HW column in the output:

$ cryptoadm list -vm provider='/usr/lib/security/$ISA/pkcs11_softtoken.so'`

For more information, see the pkcs11_softtoken(7) man page.

Note:

An important component of administering the Cryptographic Framework is to plan and implement your policy regarding FIPS 140-2, the U.S. Government computer security standard for cryptography modules. 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. Oracle completed a FIPS 140-2 validation against the Cryptographic Framework in this specific release. Oracle Solaris 11.4 builds on this validated foundation and includes software improvements that address performance, functionality, and reliability. Whenever possible, you should configure Oracle Solaris 11.4 in FIPS 140-2 mode to take advantage of these improvements.

Review Using a FIPS 140-2 Enabled System in Oracle Solaris 11.4 and plan an overall FIPS 140-2 policy for your systems.

The following task map points to procedures for administering software and hardware providers in the Cryptographic Framework.

Table 3-2 Administering the Cryptographic Framework Task Map

Task	Description	For Instructions
Plan the FIPS 140-2 policy for your systems.	Decide on your plan for enabling FIPS 140-2 approved providers and consumers and implement your plan.	Using a FIPS 140-2 Enabled System in Oracle Solaris 11.4
List the providers in the Cryptographic Framework.	Lists the algorithms, libraries, and hardware devices that are available for use in the Cryptographic Framework.	Listing Available Providers
Enable FIPS 140-2 mode.	Runs the Cryptographic Framework to a U.S. government standard for cryptography modules.	How to Create a Boot Environment With FIPS 140-2 Enabled
Add a software provider.	Adds a PKCS #11 library or a kernel module to the Cryptographic Framework. The provider must be signed.	How to Add a Software Provider
Prevent the use of a user-level mechanism.	Removes a software mechanism from use. The mechanism can be enabled again.	How to Prevent the Use of a User-Level Mechanism
Temporarily disable mechanisms from a kernel module.	Temporarily removes a mechanism from use. Usually used for testing.	How to Prevent the Use of a Kernel Software Mechanism
Uninstall a library.	Removes a user-level software provider from use.	Permanently Removing a User-Level Library
Uninstall a kernel provider.	Removes a kernel software provider from use.	Temporarily Removing Kernel Software Provider Availability
Disable mechanisms from a hardware provider.	Ensures that selected mechanisms on a hardware accelerator are not used.	How to Disable Hardware Provider Mechanisms and Features
Restart or refresh cryptographic services.	Ensures that cryptographic services are available.	How to Refresh or Restart All Cryptographic Services

Listing Available Providers

Hardware providers are automatically located and loaded. For more information, see the driver.conf(5) man page.

When you have hardware that expects to plug in to the Cryptographic Framework, the hardware registers with the SPI in the kernel. The framework checks that the hardware driver is signed. Specifically, the framework checks that the object file of the driver is signed with a certificate that Oracle issues.

For information about getting your provider signed, see the information about the elfsign command in User-Level Commands in the Cryptographic Framework.

To list available providers, you use the cryptoadm list commands with different options depending on the specific information you want to obtain.

Listing all the providers on the system.

The contents and format of the providers list varies for different Oracle Solaris releases and different hardware platforms. Run the cryptoadm list command on your system to see the providers that your system supports. Only those mechanisms at the user level are available for direct use by regular users.
```
$ cryptoadm list
User-level providers:/* for applications */
Provider: /usr/lib/security/$ISA/pkcs11_softtoken.so

Kernel providers:/* for IPsec, Kerberos */
        des
        aes
        arcfour
        blowfish
        camellia
        ecc
        sha1
        sha2
        sha3
        md5
        rsa
        swrand
n2rng/0 /* for hardware */
```

Listing the providers and their mechanisms in the Cryptographic Framework.

You can view the strength and modes, such as ECB and CBC, of the available mechanisms. However, some of the listed mechanisms might be unavailable for use. See the next item for instructions about how to list which mechanisms can be used.

The following output is truncated for display purposes.

$ cryptoadm list -m [provider=provider]
User-level providers:
=====================

Provider: /usr/lib/security/$ISA/pkcs11_softtoken.so
Mechanisms:
CKM_CAMELLIA_CBC
CKM_CAMELLIA_CBC_PAD
CKM_CAMELLIA_CTR
CKM_CAMELLIA_ECB
CKM_CAMELLIA_KEY_GEN
CKM_DES_CBC
...
CKM_ECDSA_SHA1
CKM_ECDH1_DERIVE

Kernel providers:
==========================
des: CKM_DES_ECB,CKM_DES_CBC,CKM_DES3_ECB,CKM_DES3_CBC
aes: CKM_AES_ECB,CKM_AES_CBC,CKM_AES_CTR,...CKM_AES_CFB8
arcfour: CKM_RC4
blowfish: CKM_BLOWFISH_ECB,CKM_BLOWFISH_CBC
camellia: CKM_CAMELLIA_CBC,CKM_CAMELLIA_CTR,CKM_CAMELLIA_CTS,CKM_CAMELLIA_ECB
ecc: CKM_EC_KEY_PAIR_GEN,CKM_ECDH1_DERIVE,CKM_ECDSA, \
     CKM_ECDSA_SHA1
sha1: CKM_SHA_1,CKM_SHA_1_HMAC,CKM_SHA_1_HMAC_GENERAL
sha2: CKM_SHA224,CKM_SHA224_HMAC,...CKM_SHA512_256_HMAC_GENERAL
sha3: CKM_SHA3_224,CKM_SHA3_224_HMAC,CKM_SHA3_256,...CKM_SHA3_512_HMAC
md5: CKM_MD5,CKM_MD5_HMAC,CKM_MD5_HMAC_GENERAL
rsa: CKM_RSA_PKCS,CKM_RSA_X_509,...CKM_SHA512_RSA_PKCS
swrand: No mechanisms presented.
n2rng/0: No mechanisms presented.

Listing the available cryptographic mechanisms.

Policy determines which mechanisms are available for use. The administrator sets the policy. An administrator can choose to disable mechanisms from a particular provider. The ‐p option displays the list of mechanisms that are permitted by the policy that the administrator has set.

$ cryptoadm list -p [provider=provider]
User-level providers:
=====================
/usr/lib/security/$ISA/pkcs11_softtoken.so: \
     all mechanisms are enabled, random is enabled.

Kernel providers:
==========================
des: all mechanisms are enabled.
aes: all mechanisms are enabled.
arcfour: all mechanisms are enabled.
blowfish: all mechanisms are enabled.
camellia: all mechanisms are enabled.
ecc: all mechanisms are enabled.
sha1: all mechanisms are enabled.
sha2: all mechanisms are enabled.
sha3: all mechanisms are enabled.
md5: all mechanisms are enabled.
rsa: all mechanisms are enabled.
swrand: random is enabled.
n2rng/0: all mechanisms are enabled. random is enabled.

The following examples show additional specific uses of the cryptoadm list command.

Example 3-11 Listing Cryptographic Information of a Specific Provider

Specifying the provider in the cryptoadm options command limits the output only to information that is applicable to the provider.

$ cryptoadm list -p provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so
/usr/lib/security/$ISA/pkcs11_softtoken.so: all mechanisms are enabled, except CKM_DES_CMC, CKM_DES_ECB,...random is disabled.

The following output shows that only the mechanisms have been enabled. The random generator continues to be disabled.

$ cryptoadm enable provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so mechanism=all
$ cryptoadm list -p provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so
/usr/lib/security/$ISA/pkcs11_softtoken.so: all mechanisms are enabled. random is disabled.

The following output shows that every feature and mechanism on the board has been enabled.

$ cryptoadm list -p provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so
/usr/lib/security/$ISA/pkcs11_softtoken.so: all mechanisms ar enabled, except CKM_DES_ECB,CKM_DES3_ECB. random is disabled.
$ cryptoadm enable provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so all
$ cryptoadm list -p provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so
/usr/lib/security/$ISA/pkcs11_softtoken.so: all mechanisms are enabled. random is enabled.

Example 3-12 Finding User-Level Cryptographic Mechanisms Only

In the following example, all mechanisms that the user-level library, pkcs11_softtoken, offers are listed.

$ cryptoadm list -m provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so
Mechanisms:
CKM_CAMELLIA_CBC
CKM_CAMELLIA_CBC_PAD
CKM_CAMELLIA_CTR
CKM_CAMELLIA_ECB
CKM_CAMELLIA_KEY_GEN
CKM_DES_CBC
…
CKM_ECDSA
CKM_ECDSA_SHA1
CKM_ECDH1_DERIVE

Example 3-13 Determining Which Cryptographic Mechanisms Perform Which Functions

Mechanisms perform specific cryptographic functions, such as signing or key generation. The ‐v ‐m options display every mechanism and its functions.

In this example, the administrator wants to determine the functions for which the CKM_ECDSA* mechanisms can be used.

$ cryptoadm list -vm
...

Provider: /usr/lib/security/$ISA/pkcs11_softtoken.so
Description: Sun Crypto Softtoken
Manufacturer: Oracle Corporation
PKCS#11 Version: 2.40
...
Mechanisms:
                                             E D     S   V   P       E E
                                             n e D   i V e K a   U D x C
                                             c c i   g e r e i   n e t
                                             r r g S + r + y r W w r e C
                                             y y e i R i R G G r r i n a
                                           H p p s g e f e e e a a v s p
Mechanism Name         Minimum    Maximum  W t t t n c y c n n p p e n s
---------------------- ------- ----------  - - - - - - - - - - - - - - -
...
CKM_ECDSA_SHA1             112        571  . . . . X . X . . . . . . . .
CKM_ECDH1_DERIVE           112        571  . . . . . . . . . . . . X . .
...
Kernel providers:
=================
...
ecc: CKM_EC_KEY_PAIR_GEN,CKM_ECDH1_DERIVE,CKM_ECDSA,CKM_ECDSA_SHA1
...

Each item in an entry represents a piece of information about the mechanism. For these ECC mechanisms, the listing indicates the following:

Minimum length – 112 bytes
Maximum length – 571 bytes
Hardware – Is or is not available on hardware.
Encrypt – Is not used to encrypt data.
Decrypt – Is not used to decrypt data.
Digest – Is not used to create message digests.
Sign – Is used to sign data.
Sign + Recover – Is not used to sign data, where the data can be recovered from the signature.
Verify – Is used to verify signed data.
Verify + Recover – Is not used to verify data that can be recovered from the signature.
Key generation – Is not used to generate a private key.
Pair generation – Is not used to generate a key pair.
Wrap – Is not used to wrap. that is, encrypt, an existing key.
Unwrap – Is not used to unwrap a wrapped key.
Derive – Is not used to derive a new key from a base key.
EC Caps – Absent EC capabilities that are not covered by previous items

Adding a Software Provider

The following procedure explains how to add providers to the system. You must become an administrator who is assigned the Crypto Management rights profile. For more information, see Using Your Assigned Administrative Rights in Securing Users and Processes in Oracle Solaris 11.4.

How to Add a Software Provider

Updated output s11.4 May 2018-

List the software providers that are available to the system.

$ cryptoadm list

User-level providers:
Provider: /usr/lib/security/$ISA/pkcs11_softtoken.so

Kernel providers:
         des
         aes
         arcfour
         blowfish
         camellia
         ecc
         sha1
         sha2
         sha3
         md5
         rsa
         swrand
         n2rng/0

repository installing third-party providers Add the package for a new provider from a repository.

This example installs the pkcs11_kmip package. For information about KMIP, see KMIP and PKCS #11 Client Applications.

$ pkg install pkcs11_kmip

            Packages to install:  2
        Create boot environment: No
Create backup boot environment: No

DOWNLOAD                                PKGS         FILES    XFER
(MB)   SPEED
Completed                                2/2         18/18 0.6/0.6  251k/s

PHASE                                          ITEMS
Installing new actions                         50/50
Updating package state database                 Done
Updating package cache                           0/0
Updating image state                            Done
Creating fast lookup database                   Done
Updating package cache                           1/1

$ cryptoadm install provider='/usr/lib/security/$ISA/pkcs11_kmip.so'

Locate the new provider on the list.

In this case, a new user-level software provider was installed.

$ cryptoadm list

User-level providers:
Provider: /usr/lib/security/$ISA/pkcs11_softtoken.so
Provider: /usr/lib/security/$ISA/pkcs11_kmip.so  <-- added provider

Kernel providers:
         des
         aes
         arcfour
         blowfish
         camellia
         ecc
         sha1
         sha2
         sha3
         md5
         rsa
         swrand
         n2rng/0

Enabling FIPS 140-2 Mode in Oracle Solaris

By default, FIPS 140-2 mode is disabled in Oracle Solaris. In this procedure, you create a boot environment (BE) for FIPS 140-2 mode, then activate and boot the new BE.

How to Create a Boot Environment With FIPS 140-2 Enabled

You must assume the root role. For more information, see Using Your Assigned Administrative Rights in Securing Users and Processes in Oracle Solaris 11.4.

Determine whether the system is in FIPS 140-2 mode.

$ cryptoadm list fips-140
User-level providers:
=====================
/usr/lib/security/$ISA/pkcs11_softtoken: FIPS 140 mode is disabled.

Kernel providers:
=================
des: FIPS 140 mode is disabled.
aes: FIPS 140 mode is disabled.
ecc: FIPS 140 mode is disabled.
sha1: FIPS 140 mode is disabled.
sha2: FIPS 140 mode is disabled.
sha3: FIPS 140 mode is disabled.
rsa: FIPS 140 mode is disabled.
swrand: FIPS 140 mode is disabled.

Enable FIPS 140-2 mode.
This command creates a BE in FIPS 140-2 mode. If the fips-140 package is not yet loaded, this command also loads the package.
```
# cryptoadm enable fips-140           
```

List the BEs.

$ beadm list
BE                  Flags  Mountpoint Space   Policy Created
--                  ------ ---------- ------  ------ ----------------
S114Jan             -      -          48.22G  static 2018-01-10 10:10
S114Jan-1           NR     /         287.01M  static 2018-01-20 10:10

Caution:

A FIPS 140-2 enabled system runs compliance tests that can cause a panic if they fail. Therefore, retain the original BE.

Activate the FIPS 140-2 BE and reboot.
```
# beadm activate S114Jan-1
# reboot              
```
You are now running in FIPS 140-2 mode.

Note:
FIPS 140-2 mode does not disable the non-FIPS 140-2 approved algorithms from the user-level pkcs11_softtoken library and the kernel software providers. The consumers of the framework are responsible for using only FIPS 140-2 approved algorithms. For more information, see Using a FIPS 140-2 Enabled System in Oracle Solaris 11.4 and the cryptoadm(8) man page.

To run without FIPS 140-2 enabled, boot a non-FIPS 140-2 BE.

In this example, you reboot to the original BE.

$ beadm list
BE                  Flags  Mountpoint Space     Policy Created
--                  ------ ---------- --------  ------ -----------------
S114Jan             -      -            48.22G  static 2018-01-10 10:10
S114Jan-1           NR     /           287.01M  static 2018-01-20 10:10
# beadm activate S114Jan
# beadm list
BE                  Flags  Mountpoint Space     Policy Created
--                  ------ ---------- -------   ------ -----------------
S114Jan             R      -           48.22G   static 2018-01-10 10:10
114Jan-1            N      /          287.01M   static 2018-01-20 10:10
# reboot

Preventing the Use of Mechanisms

If some of the cryptographic mechanisms from a library provider should not be used, you can remove selected mechanisms. You might consider preventing the use of mechanisms if, for example, the same mechanism in another library performs better, or if a security vulnerability is being investigated.

If the Cryptographic Framework provides multiple modes of a provider such as AES, you might remove a slow mechanism from use, or a corrupted mechanism. You might also use this procedure to remove an algorithm with proven security vulnerabilities.

You can selectively disable mechanisms and the random number feature from a hardware provider. To enable them again, see Selectively Enabling Mechanisms and Features on a Provider. The hardware in this example provides a random number generator.

How to Prevent the Use of a User-Level Mechanism

You must become an administrator who is assigned the Crypto Management rights profile. For more information, see Using Your Assigned Administrative Rights in Securing Users and Processes in Oracle Solaris 11.4.

List the mechanisms that are offered by a particular user-level software provider.

$ cryptoadm list -m provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so
Mechanisms:
CKM_CAMELLIA_CBC
CKM_CAMELLIA_CBC_PAD
CKM_CAMELLIA_CTR
...
CKM_ECDSA_SHA1
CKM_ECDH1_DERIVE

List the mechanisms that are available for use.

$ cryptoadm list -p
user-level providers:
=====================
...
/usr/lib/security/$ISA/pkcs11_softtoken.so: all mechanisms are enabled. random is enabled.…

Disable the mechanisms that should not be used.

$ cryptoadm disable provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so \
> mechanism=CKM_DES_CBC,CKM_DES_CBC_PAD,CKM_DES_ECB

List the mechanisms that are available for use.

$ cryptoadm list -p provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so
/usr/lib/security/$ISA/pkcs11_softtoken.so: all mechanisms are enabled,
except CKM_DES_ECB,CKM_DES_CBC_PAD,CKM_DES_CBC. random is enabled.

Example 3-14 Enabling a User-Level Software Provider Mechanism

In this example, a disabled AES mechanism is again made available for use.

$ cryptoadm list -m provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so
Mechanisms:
CKM_CAMELLIA_CBC
CKM_CAMELLIA_CBC_PAD
CKM_CAMELLIA_CTR
...
CKM_ECDSA_SHA1
CKM_ECDH1_DERIVE
$ cryptoadm list -p provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so
/usr/lib/security/$ISA/pkcs11_softtoken.so: all mechanisms are enabled,
except CKM_AES_ECB,CKM_DES_CBC_PAD,CKM_DES_CBC. random is enabled.
$ cryptoadm enable provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so \
> mechanism=CKM_AES_ECB
$ cryptoadm list -p provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so
/usr/lib/security/$ISA/pkcs11_softtoken.so: all mechanisms are enabled,
except CKM_DES_CBC_PAD,CKM_DES_CBC. random is enabled.

Example 3-15 Enabling All User-Level Software Provider Mechanisms

In the following example, all mechanisms from the user-level library are enabled.

$ cryptoadm enable provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so all
$ cryptoadm list -p provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so
/usr/lib/security/$ISA/pkcs11_softtoken.so: all mechanisms are enabled. random is enabled.

Example 3-16 Permanently Removing a User-Level Library

In this example, a libpkcs11.so.1 library from the /opt directory is removed.

$ cryptoadm uninstall provider=/opt/lib/\$ISA/libpkcs11.so.1
$ cryptoadm list
User-level providers:
Provider: /usr/lib/security/$ISA/pkcs11_softtoken.so

Kernel providers:
...

How to Prevent the Use of a Kernel Software Mechanism

List the mechanisms that are offered by a particular kernel software provider.

$ cryptoadm list -m provider=aes
aes: CKM_AES_ECB,CKM_AES_CBC,CKM_AES_CTR,CKM_AES_CCM,CKM_AES_GCM,\
CKM_AES_GMAC,CKM_AES_CFB128,CKM_AES_XTS,CKM_AES_XCBC_MAC,\
CKM_AES_XCBC_MAC_96,CKM_AES_CMAC,CKM_AES_CTS,CKM_AES_CFB8

List the mechanisms that are available for use.

$ cryptoadm list -p provider=aes
aes: all mechanisms are enabled.

Disable the mechanism that should not be used.

$ cryptoadm disable provider=aes mechanism=CKM_AES_ECB

List the mechanisms that are available for use.

$ cryptoadm list -p provider=aes
aes: all mechanisms are enabled, except CKM_AES_ECB.

Example 3-17 Enabling a Kernel Software Provider Mechanism

In this example, a disabled AES mechanism is again made available for use.

cryptoadm list -m provider=aes
aes: CKM_AES_ECB,CKM_AES_CBC,CKM_AES_CTR,CKM_AES_CCM,CKM_AES_GCM,\
CKM_AES_GMAC,CKM_AES_CFB128,CKM_AES_XTS,CKM_AES_XCBC_MAC,\
CKM_AES_XCBC_MAC_96,CKM_AES_CMAC,CKM_AES_CTS,CKM_AES_CFB8
$ cryptoadm list -p provider=aes
aes: all mechanisms are enabled, except CKM_AES_ECB.
$ cryptoadm enable provider=aes mechanism=CKM_AES_ECB
$ cryptoadm list -p provider=aes
aes: all mechanisms are enabled.

Example 3-18 Temporarily Removing Kernel Software Provider Availability

In the following example, the AES provider is temporarily removed from use. The unload subcommand is useful to prevent a provider from being loaded automatically while the provider is being uninstalled. For example, the unload subcommand might be used when modifying a mechanism of this provider.

$ cryptoadm unload provider=aes

$ cryptoadm list
...
Kernel software providers:
des
aes (inactive)
arcfour
blowfish
ecc
sha1
sha2
sha3
md5
rsa
swrand
n2rng/0

The AES provider is unavailable until the Cryptographic Framework is refreshed.

$ svcadm refresh system/cryptosvc

$ cryptoadm list
...
Kernel software providers:
des
aes
arcfour
blowfish
camellia
ecc
sha1
sha2
sha3
md5
rsa
swrand
n2rng/0

If a kernel consumer is using the kernel software provider, the software is not unloaded. An error message is displayed and the provider continues to be available for use.

Example 3-19 Permanently Removing Software Provider Availability

In the following example, the AES provider is removed from use. Once removed, the AES provider does not appear in the policy listing of kernel software providers.

$ cryptoadm uninstall provider=aes

$ cryptoadm list
...
Kernel software providers:
des
arcfour
blowfish
camellia
ecc
sha1
sha2
sha3
md5
rsa
swrand
n2rng/0

Example 3-20 Reinstalling a Removed Kernel Software Provider

In the following example, the AES kernel software provider is reinstalled. To reinstall a removed kernel provider, you must enumerate the mechanisms to be installed.

$ cryptoadm install provider=aes \
mechanism=CKM_AES_ECB,CKM_AES_CBC,CKM_AES_CTR,CKM_AES_CCM,CKM_AES_GCM,
CKM_AES_GMAC,CKM_AES_CFB128,CKM_AES_XTS,CKM_AES_XCBC_MAC,
CKM_AES_XCBC_MAC_96,CKM_AES_CMAC,CKM_AES_CTS,CKM_AES_CFB8

$ cryptoadm list
...;
Kernel software providers:
des
aes
arcfour
blowfish
camellia
ecc
sha1
sha2md5
rsa
swrand
n2rng/0

How to Disable Hardware Provider Mechanisms and Features

Choose the mechanisms or feature to disable.

List the provider.

$ cryptoadm list -p provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so
/usr/lib/security/$ISA/pkcs11_softtoken.so: all mechanisms are enabled except CKM_DES_ECB,CKM_DES3_ECB. random is enabled.

To disable selected mechanisms:

$ cryptoadm list -p provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so
/usr/lib/security/$ISA/pkcs11_softtoken.so: all mechanisms are enabled except CKM_DES_ECB,CKM_DES3_ECB. random is enabled.
# cryptoadm disable provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so mechanism=CKM_DES3_CBC
# cryptoadm list -p provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so
/usr/lib/security/$ISA/pkcs11_softtoken.so: all mechanisms are enabled except CKM_DES_ECB,CKM_DES3_CBC,CKM_DES3_ECB. random is enabled.

To disable the random number generator:

# cryptoadm list -p provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so
/usr/lib/security/$ISA/pkcs11_softtoken.so: all mechanisms are enabled except CKM_DES_ECB,CKM_DES3_CBC,CKM_DES3_ECB.
random is enabled.
# cryptoadm disable provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so random
# cryptoadm list -p provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so
/usr/lib/security/$ISA/pkcs11_softtoken.so: all mechanisms are enabled except CKM_DES_ECB,CKM_DES3_CBC,CKM_DES3_ECB. random is disabled.

To disable all mechanisms without disabling the random number generator, use mechanism=all:

# cryptoadm list -p provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so
/usr/lib/security/$ISA/pkcs11_softtoken.so: all mechanisms are enabled except CKM_DES_ECB,CKM_DES3_CBC,CKM_DES3_ECB.
random is enabled.
# cryptoadm disable provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so mechanism=all
# cryptoadm list -p provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so
usr/lib/security/$ISA/pkcs11_softtoken.so: all mechanisms are disabled. random is enabled.

To disable every feature and mechanism on the hardware, including the random number generator, use the all option:

# cryptoadm list -p provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so
/usr/lib/security/$ISA/pkcs11_softtoken.so: all mechanisms are enabled. random is enabled.
# cryptoadm disable provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so all
# cryptoadm list -p provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so
usr/lib/security/$ISA/pkcs11_softtoken.so: all mechanisms are disabled. random is disabled.

For examples of these options, see Example 3-21.

Example 3-21 Selectively Enabling Mechanisms and Features on a Provider

In these examples, disabled mechanisms on a provider are selectively enabled or disabled.

# cryptoadm list -p provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so
/usr/lib/security/$ISA/pkcs11_softtoken.so: all mechanisms are enabled except CKM_RSA_PKCS,CKM_DES_ECB,CKM_DES3_ECB. random is enabled.

# cryptoadm enable provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so mechanism=CKM_RSA_PKCS
# cryptoadm list -p provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so
/usr/lib/security/$ISA/pkcs11_softtoken.so: all mechanisms are enabled except CKM_DES_ECB,CKM_DES3_ECB. random is enabled.

In this example, only the random generator is enabled.

# cryptoadm list -p provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so
/usr/lib/security/$ISA/pkcs11_softtoken.so: all mechanisms are enabled, except CKM_MD5,CKM_MD5_HMAC,…. random is disabled.
# cryptoadm enable provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so random
# cryptoadm list -p provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so
/usr/lib/security/$ISA/pkcs11_softtoken.so: all mechanisms are enabled, except CKM_MD5,CKM_MD5_HMAC,…. random is enabled.

In this example, only the mechanisms are enabled. The random generator continues to be disabled.

# cryptoadm list -p provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so
/usr/lib/security/$ISA/pkcs11_softtoken.so: all mechanisms are enabled, except CKM_RSA_PKCS,CKM_RSA_X_509,…. random is disabled.
# cryptoadm enable provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so mechanism=all
# cryptoadm list -p provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so
/usr/lib/security/$ISA/pkcs11_softtoken.so: all mechanisms are enabled. random is disabled.

In this example, every feature and mechanism on the board is enabled.

# cryptoadm list -p provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so
/usr/lib/security/$ISA/pkcs11_softtoken.so: all mechanisms are enabled, except CKM_RSA_PKCS,CKM_RSA_X_509. random is disabled.
# cryptoadm enable provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so all
# cryptoadm list -p provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so
/usr/lib/security/$ISA/pkcs11_softtoken.so: all mechanisms are enabled. random is enabled.

Refreshing or Restarting All Cryptographic Services

By default, the Cryptographic Framework is enabled. When the kcfd daemon fails for any reason, the Service Management Facility (SMF) can be used to restart cryptographic services. For more information, see the smf(7) and svcadm(8) man pages. For the effect on zones of restarting cryptographic services, see Cryptographic Framework and Zones.

How to Refresh or Restart All Cryptographic Services

Before you begin, you must become an administrator who is assigned the Crypto Management rights profile. For more information, see Using Your Assigned Administrative Rights in Securing Users and Processes in Oracle Solaris 11.4.

Check the status of cryptographic services.

$ svcs cryptosvc
STATE          STIME    FMRI
offline         Dec_09   svc:/system/cryptosvc:default

Enable cryptographic services.

$ svcadm enable svc:/system/cryptosvc

Example 3-22 Refreshing Cryptographic Services

In the following example, cryptographic services are refreshed in the global zone. Therefore, kernel-level cryptographic policy in every non-global zone is also refreshed.

$ svcadm refresh system/cryptosvc