In this section, we'll administer software and hardware providers in the Solaris cryptographic framework. As required by the exam, we'll look specifically at how to list the algorithms, libraries, and hardware devices available for use, and how to prevent the use of a user-level mechanism and disable mechanisms from a kernel module.
Using the cryptoadm utility, we can display cryptographic provider information for a system. The framework supports three types of providers: a user-level provider (a PKCS11 shared library), a kernel software provider (a loadable kernel software module), and a kernel hardware provider (a cryptographic hardware device). Following are the command's usage pertaining to the exam requirements:
cryptoadm list Displays the list of installed providers.
cryptoadm -m Displays a list of mechanisms that can be used with the installed providers. If a provider is specified, the command will display the name of the specified provider and the mechanism list that can be used with that provider.
cryptoadm list -p Displays the mechanism policy for the installed providers. Also displays the provider feature policy. If a provider is specified, the command will display the name of the provider with the mechanism policy enforced on it only.
To list only mechanisms at the user level that are available for use by regular users, you should execute the cryptoadm list command shown here:
# cryptoadm list user-level providers: /usr/lib/security/$ISA/pkcs11_kernel.so /usr/lib/security/$ISA/pkcs11_softtoken.so kernel software providers: des aes arcfour blowfish sha1 md5 rsa kernel hardware providers:
Use the cryptoadm list command with the -m option to list all providers and their mechanisms:
# cryptoadm list –m user-level providers: ===================== /usr/lib/security/$ISA/pkcs11_kernel.so: no slots presented. /usr/lib/security/$ISA/pkcs11_softtoken.so: CKM_DES_CBC,CKM_DES_CBC_PAD,CKM_DES_ECB,CKM_DES_KEY_GEN,CKM_DES_MAC_GENERAL,CKM_D ES_MAC,CKM_DES3_CBC,CKM_DES3_CBC_PAD,CKM_DES3_ECB,CKM_DES3_KEY_GEN,CKM_AES_CBC,CK M_AES_CBC_PAD,CKM_AES_ECB,CKM_AES_KEY_GEN,CKM_SHA_1,CKM_SHA_1_HMAC,CKM_SHA_1_HMAC _GENERAL,CKM_SSL3_SHA1_MAC,CKM_MD5,CKM_MD5_HMAC,CKM_MD5_HMAC_GENERAL,CKM_SSL3_MD5 _MAC,CKM_RC4,CKM_RC4_KEY_GEN,CKM_DSA,CKM_DSA_SHA1,CKM_DSA_KEY_PAIR_GEN,CKM_RSA_PK CS,CKM_RSA_PKCS_KEY_PAIR_GEN,CKM_RSA_X_509,CKM_MD5_RSA_PKCS,CKM_SHA1_RSA_PKCS,CKM _DH_PKCS_KEY_PAIR_GEN,CKM_DH_PKCS_DERIVE,CKM_MD5_KEY_DERIVATION,CKM_SHA1_KEY_DERI VATION,CKM_PBE_SHA1_RC4_128,CKM_PKCS5_PBKD2 kernel software providers: ========================== des: CKM_DES_ECB,CKM_DES_CBC,CKM_DES3_ECB,CKM_DES3_CBC aes: CKM_AES_ECB,CKM_AES_CBC arcfour: CKM_RC4 blowfish: CKM_BF_ECB,CKM_BF_CBC sha1: CKM_SHA_1,CKM_SHA_1_HMAC,CKM_SHA_1_HMAC_GENERAL md5: CKM_MD5,CKM_MD5_HMAC,CKM_MD5_HMAC_GENERAL rsa: CKM_RSA_PKCS,CKM_RSA_X_509,CKM_MD5_RSA_PKCS,CKM_SHA1_RSA_PKCS kernel hardware providers: ==========================
Listing All Providers and Their Mechanisms Permitted by Policy By issuing the -p option, you can display the list of providers and their mechanisms that are permitted only by the administrator's policy. The administrator sets the policy that determines which mechanisms are available for use.
# cryptoadm list –p user-level providers: ===================== /usr/lib/security/$ISA/pkcs11_kernel.so: all mechanisms are enabled. /usr/lib/security/$ISA/pkcs11_softtoken.so: all mechanisms are enabled. kernel software providers: ========================== des: all mechanisms are enabled. aes: all mechanisms are enabled. arcfour: all mechanisms are enabled. blowfish: all mechanisms are enabled. sha1: all mechanisms are enabled. md5: all mechanisms are enabled. rsa: all mechanisms are enabled. kernel hardware providers: ==========================
While administrating the cryptographic framework on a Solaris system, you may have to remove mechanisms from a library provider that should not be used. To do so, you either need to become superuser or assume a role that includes the Crypto Management rights profile. From there, you can issue the cryptoadm disable command to disable the mechanisms that should not be used. For example, let's list only the mechanisms that are offered by a user-level software provider we extracted from the previous section:
# cryptoadm list -m /usr/lib/security/'$ISA'/pkcs11_softtoken.so /usr/lib/security/$ISA/pkcs11_softtoken.so: CKM_DES_CBC,CKM_DES_CBC_PAD,CKM_DES_ECB,CKM_DES_KEY_GEN,CKM_DES_MAC_GENERAL,CKM_D ES_MAC,CKM_DES3_CBC,CKM_DES3_CBC_PAD,CKM_DES3_ECB,CKM_DES3_KEY_GEN,CKM_AES_CBC,CK M_AES_CBC_PAD,CKM_AES_ECB,CKM_AES_KEY_GEN,CKM_SHA_1,CKM_SHA_1_HMAC,CKM_SHA_1_HMAC _GENERAL,CKM_SSL3_SHA1_MAC,CKM_MD5,CKM_MD5_HMAC,CKM_MD5_HMAC_GENERAL,CKM_SSL3_MD5 _MAC,CKM_RC4,CKM_RC4_KEY_GEN,CKM_DSA,CKM_DSA_SHA1,CKM_DSA_KEY_PAIR_GEN,CKM_RSA_PK CS,CKM_RSA_PKCS_KEY_PAIR_GEN,CKM_RSA_X_509,CKM_MD5_RSA_PKCS,CKM_SHA1_RSA_PKCS,CKM _DH_PKCS_KEY_PAIR_GEN,CKM_DH_PKCS_DERIVE,CKM_MD5_KEY_DERIVATION,CKM_SHA1_KEY_DERI VATION,CKM_PBE_SHA1_RC4_128,CKM_PKCS5_PBKD2
Next, let's find out which mechanisms are available for use. From our cryptoadm list -p command, covered in the previous section, we know that all mechanisms are enabled:
/usr/lib/security/$ISA/pkcs11_softtoken.so: all mechanisms are enabled.
Let's disable the CKM_DES_CBC CKM_DES_CBC_PAD CKM_DES_ECB mechanisms:
# cryptoadm disable /usr/lib/security/'$ISA'/pkcs11_softtoken.so \ CKM_DES_CBC CKM_DES_CBC_PAD CKM_DES_ECB>
To verify that the mechanisms were successfully disabled, issue the cryptoadm list -p command again, as shown here:
# cryptoadm list -p user-level providers: ===================== /usr/lib/security/$ISA/pkcs11_kernel.so: all mechanisms are enabled. /usr/lib/security/$ISA/pkcs11_softtoken.so: all mechanisms are enabled, excep t CKM_DES_CBC,CKM_SHA_1_HMAC_GENERAL,CKM_SHA_1_HMAC,CKM_DES_CBC_PAD,CKM_DES_E CB
If you need to re-enable a mechanism—say, for example CKM_DES_CBC—simply issue the cryptoadm enable command:
# cryptoadm enable /usr/lib/security/'$ISA'/pkcs11_softtoken.so \ CKM_DES_CBC>
Exam Watch |
To prevent the use of a user-level mechanism, issue the cryptoadm disable provider \ mechanism(s) command. |
Using the same methodology in this section for preventing the use of user-level mechanisms, we can disable kernel software providers as well. After either becoming superuser or assuming a role that includes the Crypto Management rights profile, simply issue the cryptoadm disable command, as illustrated in these examples:
# cryptoadm disable aes CKM_AES_ECB # cryptoadm list -p aes aes: all mechanisms are enabled, except CKM_AES_ECB
If you need to remove the kernel software provider availability altogether, using aes in our example, simply issue the cryptoadm unload command:
# cryptoadm unload aes
To verify the removal, issue the cryptoadm list command again:
# cryptoadm list user-level providers: /usr/lib/security/$ISA/pkcs11_kernel.so /usr/lib/security/$ISA/pkcs11_softtoken.so kernel software providers: des aes (inactive) arcfour blowfish sha1 md5 rsa kernel hardware providers:
To restore any inactive software providers, issue the cryptoadm refresh command:
# cryptoadm refresh
Alternatively, to remove a provider permanently, issue the cryptoadm uninstall command:
# cryptoadm uninstall aes
Here are some of the key points from the certification objectives in Chapter 11.
Algorithms can be symmetric "secret key" or asymmetric "public key" computational procedures used for encryption. In symmetric algorithms, the same key is used for both encryption and decryption, and in asymmetric algorithms, two keys are used—one to encrypt and another to decrypt a message.
Providers are cryptographic plug-ins that are used by applications, end users, or kernel operations—all termed consumers. The Solaris cryptographic framework allows only three types of plug-ins: user-level plug-ins, kernel-level plug-ins, and hardware plug-ins.
To monitor and help prevent unauthorized changes from being made to system files, Sun recommends using the Automated Security Enhancement Tool (ASET), the Basic Security Module (BSM), Tripwire, and the Solaris cryptographic framework.
Random keys can be generated using the encrypt and mac commands.
To create a symmetric key, use the dd command:
dd if=/dev/urandom of=keyfile bs=n count=n
where if=/dev/urandom is the input file (for a random key, use the /dev/ urandom file), of=keyfile is the output file that holds the generated key, bs=n is the key size in bytes (for the length in bytes divide the key length in bits by 8), and count=n is the count of the input blocks.
To compute a message digest for one or more files, issue the digest command:
digest -v -a algorithm input-file > digest-listing
where -v displays the output with file information, -a algorithm is the algorithm used to compute a digest (that is, MD5 or SHA1), input-file is the input file for the digest to be computed, and digest-listing is the output file for the digest command.
To create a MAC of a file, use the command
mac -v -a algorithm -k keyfile input-file
where -v displays the output in the following format: algorithm (input-file) = mac; -a algorithm is 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 is the file that contains a key of algorithm-specified length; and input-file is the input file for the MAC.
To encrypt and decrypt a file, simply create a symmetric key, and then issue the encrypt command:
encrypt -a algorithm -k keyfile -i input-file -o output-file
where -a algorithm is the algorithm to use to encrypt the file (type the algorithm as the algorithm appears in the output of the encrypt -l command), -k keyfile is 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), -i input-file is the input file that you want to encrypt (this file is left unchanged), and -o output-file is the output file that is the encrypted form of the input file. To decrypt the output file, you simply pass the same key and the same encryption mechanism that encrypted the file but to the decrypt command.
To display the list of installed providers, issue the cryptoadm list command.
To display a list of mechanisms that can be used with the installed providers, issue the cryptoadm list -m command.
To display the mechanism policy for the installed providers and the provider feature policy, issue the cryptoadm list -p command.
To prevent the use of a user-level mechanism, issue the cryptoadm disable provider \ mechanism(s) command.
To disable a kernel software, issue the cryptoadm disable provider command; to restore an inactive software provider, issue the cryptoadm refresh command; to remove a provider permanently, issue the cryptoadm uninstall command.
The following questions will help you measure your understanding of the material presented in this chapter. Read all the choices carefully, because there might be more than one correct answer. Choose, and in some cases explain, all correct answers for each question. Some questions are short-answer questions to ensure you have a good understanding of the material.
In the Solaris cryptographic framework, which of the following best explains providers?
| ||
List and explain the providers supported by the Solaris cryptographic framework. | ||
In the Solaris cryptographic framework, which of the following commands can be used to generate random keys?
| ||
Which of the following is inherently provided for by using cryptography?
| ||
Explain the usage of a Message Authentication Code (MAC). | ||
Explain the usage of message digest with regard to file integrity. | ||
Which of the following provide for implementations of algorithms in software?
| ||
In which of the following is the same cryptographic key used for both encryption and decryption?
| ||
To monitor and help prevent unauthorized changes from being made to system files, which of the following does Sun recommend using?
| ||
In the Solaris cryptographic framework, which of the following best explains consumers?
|
Answers
þ B and C. Providers are cryptographic plug-ins that consumers use. According to Sun, the framework allows only three types of plug-ins: user-level plug-ins, which are shared objects that provide services by using PKCS #11 libraries; kernel-level plug-ins, which provide for implementations of algorithms in software; and hardware plug-ins, which are device drivers and their associated hardware accelerators. ý A is wrong because consumers, not providers, can be applications, end users, or kernel operations. |
|
þ Providers are cryptographic plug-ins that applications, end users, or kernel operations— which are all termed consumers—use. The Solaris cryptographic framework allows only three types of plug-ins: user-level plug-ins, which are shared objects that provide services by using PKCS #11 libraries; kernel-level plug-ins, which provide for implementations of algorithms in software; and hardware plug-ins, which are device drivers and their associated hardware accelerators. |
|
þ C and D. Random keys can be generated using the encrypt and mac commands. ý A is wrong because you generate the symmetric key with the dd command. B is wrong because you issue the digest command to compute a message digest for one or more files. |
|
þ A, B, C, and E. Cryptography provides for the integrity, confidentiality, and authenticity of information. One of the features of the framework allows you to provide a checksum that ensures the integrity of a file. ý D is incorrect because Role-Based Access Control (RBAC) relies on the principle of least privilege which states that a user should be given only enough privileges or permissions necessary for performing a job. |
|
þ This algorithm creates a short message digest from a larger block of text by hashing it with a secret key. Without altering the original file and to protect a digest, you can compute a MAC of a file. |
|
þ A message digest is a one-way function for a stream of binary data that serves as verification that the data was not altered since the message digest was first generated, such as when a file was compiled or modified. With regard to checking the integrity of files, you can use the Solaris Fingerprint Database (sfpDB), a free tool from Sun that allows you to check the integrity of system files through online cryptographic checksums. By doing so, you can determine whether system binaries and patches are safe in accordance with their original checksums among a huge database stored at Sun. |
|
þ B. Kernel-level plug-ins provide for implementations of algorithms in software. ý A is wrong because hardware plug-ins are device drivers and their associated hardware accelerators. C is wrong because user-level plug-ins are shared objects that provide services by using PKCS #11 libraries. |
|
þ C and D. In symmetric (secret key) algorithms, the same key is used for both encryption and decryption—anyone knowing the key can both encrypt and decrypt messages. ý A and B are wrong because with asymmetric (public key) algorithms, two keys are used: one to encrypt a message and another to decrypt it. |
|
þ E. All of the answers are correct. Protecting files is a core component in Sun's Solaris security strategy. Although MD5 and SHA1, part of the Solaris cryptographic framework, were developed to help detect corrupt or maliciously altered files, Sun also recommends using a more comprehensive package called Tripwire. In addition to Tripwire, to help prevent unauthorized changes from being made to system files, Sun also recommends using ASET (discussed in Chapter 8) and BSM (discussed in Chapter 5). |
|
þ A. Consumers can be applications, end users, or kernel operations. ý B and C are wrong because providers are cryptographic plug-ins that consumers use. According to Sun, the framework allows only three types of plug-ins: user-level plug-ins, which are shared objects that provide services by using PKCS #11 libraries; kernel-level plug-ins, which provide for implementations of algorithms in software; and hardware plug-ins, which are device drivers and their associated hardware accelerators. |
What command would you issue to remove a kernel software provider permanently? | ||
What command is used to prevent the use of a user-level mechanism? | ||
In which of the following are two cryptographic keys used: one to encrypt a message and another to decrypt it?
| ||
What command displays the list of installed providers? | ||
What commands would you issue to disable temporarily and then later restore the use of a kernel software provider? | ||
What command displays the mechanism policy for the installed providers? | ||
Which of the following are shared objects that provide services by using PKCS #11 libraries?
| ||
What command is used to display a list of mechanisms that can be used with the installed providers? | ||
What command displays the provider feature policy? If a provider is specified, this command will display the name of the provider with the mechanism policy enforced on it only. |
Answers
þ To remove a provider permanently, issue the cryptoadm uninstall command (for example: cryptoadm uninstall des). |
|
þ To prevent the use of a user-level mechanism, issue the cryptoadm disable provider \ mechanism(s) command. |
|
þ A and B. With asymmetric (public key) algorithms, two keys are used: one to encrypt a message and another to decrypt it. ý C and D are wrong because in symmetric (secret key) algorithms, the same key is used for both encryption and decryption—anyone knowing the key can both encrypt and decrypt messages. |
|
þ The cryptoadm list command displays the list of installed providers. |
|
þ To disable a kernel software provider, issue the cryptoadm disable provider command; to restore an inactive software provider, issue the cryptoadm refresh command. |
|
þ The cryptoadm list -p command displays the mechanism policy for the installed providers. It also displays the provider feature policy. If a provider is specified, the command will display the name of the provider with the mechanism policy enforced on it only. |
|
þ C. User-level plug-ins are shared objects that provide services by using PKCS #11 libraries. ý A is wrong because hardware plug-ins are device drivers and their associated hardware accelerators. B is wrong because kernel-level plug-ins provide for implementations of algorithms in software. |
|
þ The cryptoadm -m command displays a list of mechanisms that can be used with the installed providers. If a provider is specified, the command will display the name of the specified provider and the mechanism list that can be used with that provider. |
|
þ The cryptoadm list -p command displays the mechanism policy for the installed providers. It also displays the provider feature policy. If a provider is specified, the command will display the name of the provider with the mechanism policy enforced on it only. |
Explain and demonstrate how to create a symmetric key, how to compute a digest of a file, and how to encrypt and decrypt a file using the AES algorithm. |
Answers
The first part of the lab requires you to explain and demonstrate how to create a symmetric key. To create a symmetric key use the dd command: dd if=/dev/urandom of=keyfile bs=n count=n where if=/dev/urandom is the input file (for a random key, use the /dev/urandom file), of=keyfile is the output file that holds the generated key, bs=n is the key size in bytes (for the length in bytes divide the key length in bits by 8), and count=n is the count of the input blocks. The first step in creating a symmetric key is to determine the length (in bytes) required by your encryption algorithm. To do so, simply list the bit range of all supported algorithms with the encrypt -l and mac -l commands, shown here: encrypt -l Algorithm Keysize: Min Max (bits) --------------------------------------------- aes 128 128 arcfour 8 128 des 64 64 3des 192 192 mac -l Algorithm Keysize: Min Max (bits) --------------------------------------------- des_mac 64 64 sha1_hmac 8 512 md5_hmac 8 512 The next step is to determine the key length in bytes by dividing the minimum and maximum key sizes by 8. Then you can generate the symmetric key with the dd command: dd if=/dev/urandom of=keyfile bs=n count=n where if=/dev/urandom is the input file (for a random key, use the /dev/urandom file), of=keyfile is the output file that holds the generated key, bs=n is the key size in bytes (for the length in bytes divide the key length in bits by 8), and count=n is the count of the input blocks. For example, to create a key for the AES algorithm in a file for later decryption, you can issue the command: dd if=/dev/urandom of=$HOME/aeskey/aeskey16 bs=16 count=1 (Note that AES uses a mandatory 128-bit key or 16 bytes.) The second part of the lab requires you to create a digest of a file. To compute a message digest for one or more files, issue the digest command: digest -v -a algorithm input-file > digest-listing where -v displays the output with file information, -a algorithm is the algorithm used to compute a digest (that is, MD5 or SHA1), input-file is the input file for the digest to be computed, and digest-listing is the output file for the digest command. Following is an example of creating a file digest using the SHA1 mechanism within the cryptographic framework:
If testfile.tar.z was a system file, we could compare the output to that stored in the online sfpDB to determine whether system binaries and patches are safe in accordance with their original checksums. You can freely download MD5 software binaries that can be used with sfpDB for Intel and SPARC architectures at http://SunSolve.Sun.COM/md5/md5.tar.Z. The third part of the lab requires you to encrypt and decrypt a file using the AES algorithm. To encrypt and decrypt a file, create a symmetric key, and then issue the encrypt command: encrypt -a algorithm -k keyfile -i input-file -o output-file where -a algorithm is the algorithm to use to encrypt the file (type the algorithm as the algorithm appears in the output of the encrypt -l command), -k keyfile is 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), -i input-file is the input file that you want to encrypt (this file is left unchanged), and -o output-file is the output file that is the encrypted form of the input file. To decrypt the output file, you pass the same key and the same encryption mechanism that encrypted the file, but use the decrypt command. In the following example, a file is encrypted with the AES algorithm. Remember that AES mechanisms use a key of 128 bits, or 16 bytes: encrypt -a aes -k ~/keyf/10.09.aes16 \ -i my.file -o ~/enc/e.my.file The input file, my.file, will still exist in its original form. To decrypt the output file, pass the same key and the same encryption mechanism that encrypted the file to the decrypt command: decrypt -a aes .-k ~/keyf/10.09.aes16 \ -i ~/enc/e.my.file -o ~/my.file |