Previous Page
Next Page

Certification Objective 11.02–Administer the Solaris Cryptographic Framework

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.

Listing Available Providers

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.

Listing Providers and Their Mechanisms at the User Level

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:

Listing All Providers and Their Mechanisms

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:
==========================

Preventing the Use of a User-Level Mechanism

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_CBCsimply 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.

Disabling Kernel Software Providers

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

Two-Minute Drill

Here are some of the key points from the certification objectives in Chapter 11.

Explain How to Protect Files Using the Solaris Cryptographic Framework

  • 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.

Administer the Solaris Cryptographic Framework

  • 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.

Self Test

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.

Explain How to Protect Files Using the Solaris Cryptographic Framework

1. 

In the Solaris cryptographic framework, which of the following best explains providers?

  1. Applications, end users, or kernel operations

  2. User-level plug-ins, kernel-level plug-ins, and hardware plug-ins

  3. Cryptographic plug-ins that consumers use

  4. All of the above

    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.

2. 

List and explain the providers supported by the Solaris cryptographic framework.

   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.

3. 

In the Solaris cryptographic framework, which of the following commands can be used to generate random keys?

  1. dd

  2. digest

  3. encrypt

  4. mac

  5. All of the above

    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.

4. 

Which of the following is inherently provided for by using cryptography?

  1. Authenticity

  2. Confidentiality

  3. Integrity

  4. RBAC

  5. Checksum

  6. All of the above

    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.

5. 

Explain the usage of a Message Authentication Code (MAC).

   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.

6. 

Explain the usage of message digest with regard to file integrity.

   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.

7. 

Which of the following provide for implementations of algorithms in software?

  1. Hardware plug-ins

  2. Kernel-level plug-ins

  3. User-level plug-ins

  4. All of the above

    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.

8. 

In which of the following is the same cryptographic key used for both encryption and decryption?

  1. Asymmetric algorithm

  2. Public key

  3. Secret key

  4. Symmetric algorithm

  5. All of the above

    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.

9. 

To monitor and help prevent unauthorized changes from being made to system files, which of the following does Sun recommend using?

  1. Automated Security Enhancement Tool (ASET)

  2. Basic Security Module (BSM)

  3. Solaris cryptographic framework

  4. Tripwire

  5. All of the above

    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 ).

10. 

In the Solaris cryptographic framework, which of the following best explains consumers?

  1. Applications, end users, or kernel operations

  2. User-level plug-ins, kernel-level plug-ins, and hardware plug-ins

  3. Cryptographic plug-ins that consumers use

  4. All of the above

    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.

Answers

1. 

þ 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.

2. 

þ 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.

3. 

þ 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.

4. 

þ 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.

5. 

þ 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.

6. 

þ 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.

7. 

þ 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.

8. 

þ 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.

9. 

þ 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).

10. 

þ 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.

Administer the Solaris Cryptographic Framework

11. 

What command would you issue to remove a kernel software provider permanently?

   To remove a provider permanently, issue the cryptoadm uninstall command (for example: cryptoadm uninstall des ).

12. 

What command is used to prevent the use of a user-level mechanism?

   To prevent the use of a user-level mechanism, issue the cryptoadm disable   provider   \   mechanism(s)  command.

13. 

In which of the following are two cryptographic keys used: one to encrypt a message and another to decrypt it?

  1. Asymmetric algorithm

  2. Public key

  3. Secret key

  4. Symmetric algorithm

  5. All of the above

    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.

14. 

What command displays the list of installed providers?

   The cryptoadm list command displays the list of installed providers.

15. 

What commands would you issue to disable temporarily and then later restore the use of a kernel software provider?

   To disable a kernel software provider, issue the cryptoadm disable   provider  command; to restore an inactive software provider, issue the cryptoadm refresh command.

16. 

What command displays the mechanism policy for the installed providers?

   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.

17. 

Which of the following are shared objects that provide services by using PKCS #11 libraries?

  1. Hardware plug-ins

  2. Kernel-level plug-ins

  3. User-level plug-ins

  4. All of the above

    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.

18. 

What command is used to display a list of mechanisms that can be used with the installed providers?

   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.

19. 

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.

   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.

Answers

11. 

þ To remove a provider permanently, issue the cryptoadm uninstall command (for example: cryptoadm uninstall des).

12. 

þ To prevent the use of a user-level mechanism, issue the cryptoadm disable provider \ mechanism(s) command.

13. 

þ 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.

14. 

þ The cryptoadm list command displays the list of installed providers.

15. 

þ To disable a kernel software provider, issue the cryptoadm disable provider command; to restore an inactive software provider, issue the cryptoadm refresh command.

16. 

þ 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.

17. 

þ 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.

18. 

þ 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.

19. 

þ 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.

Lab Question

 

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.

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 -lAlgorithmKeysize:Min Max (bits) --------------------------------------------- aes128 128 arcfour8 128 des6464 3des 192 192 mac -lAlgorithmKeysize:Min Max (bits) --------------------------------------------- des_mac6464 sha1_hmac8 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:  a. To compute an MD5 digest for file testfile.tar.Z into output file testfilesha1, issue this command:  digest -v -a md5 testfile.tar.Z -- $HOME/testfilemd5  b. Then issue the cat command,  cat ~/testfilemd5 to view the following output:  md5 (testfile.tar.Z) = 1ab89e5ad217e34f0a977a091a1b588b31f9b588   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

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:

  1. To compute an MD5 digest for file testfile.tar.Z into output file testfilesha1, issue this command:

    digest -v -a md5 testfile.tar.Z >> $HOME/testfilemd5
  2. Then issue the cat command,

    cat ~/testfilemd5

    to view the following output:

    md5 (testfile.tar.Z) = 1ab89e5ad217e34f0a977a091a1b588b31f9b588

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


Previous Page
Next Page