SupportConsoleDevelopersStart a trialContact

4.9. Encryption

4.9.1. Using LUKS Disk Encryption

Linux Unified Key Setup-on-disk-format (or LUKS) allows you to encrypt partitions on your Linux computer. This is particularly important when it comes to mobile computers and removable media. LUKS allows multiple user keys to decrypt a master key, which is used for the bulk encryption of the partition.

Overview of LUKS

What LUKS does
  • LUKS encrypts entire block devices and is therefore well-suited for protecting the contents of mobile devices such as removable storage media or laptop disk drives.
  • The underlying contents of the encrypted block device are arbitrary. This makes it useful for encrypting swap devices. This can also be useful with certain databases that use specially formatted block devices for data storage.
  • LUKS uses the existing device mapper kernel subsystem.
  • LUKS provides passphrase strengthening which protects against dictionary attacks.
  • LUKS devices contain multiple key slots, allowing users to add backup keys or passphrases.
What LUKS does not do:
  • LUKS is not well-suited for scenarios requiring many (more than eight) users to have distinct access keys to the same device.
  • LUKS is not well-suited for applications requiring file-level encryption.

Important

Disk-encryption solutions like LUKS only protect the data when your system is off. Once the system is on and LUKS has decrypted the disk, the files on that disk are available to anyone who would normally have access to them.

4.9.1.1. LUKS Implementation in Red Hat Enterprise Linux

Red Hat Enterprise Linux 7 utilizes LUKS to perform file system encryption. By default, the option to encrypt the file system is unchecked during the installation. If you select the option to encrypt your hard drive, you will be prompted for a passphrase that will be asked every time you boot the computer. This passphrase "unlocks" the bulk encryption key that is used to decrypt your partition. If you choose to modify the default partition table you can choose which partitions you want to encrypt. This is set in the partition table settings.
The default cipher used for LUKS (see cryptsetup --help) is aes-cbc-essiv:sha256 (ESSIV - Encrypted Salt-Sector Initialization Vector). Note that the installation program, Anaconda, uses by default XTS mode (aes-xts-plain64). The default key size for LUKS is 256 bits. The default key size for LUKS with Anaconda (XTS mode) is 512 bits. Ciphers that are available are:

4.9.1.2. Manually Encrypting Directories

Warning

Following this procedure will remove all data on the partition that you are encrypting. You WILL lose all your information! Make sure you backup your data to an external source before beginning this procedure!
  1. Enter runlevel 1 by typing the following at a shell prompt as root: 
    telinit 1
  2. Unmount your existing /home: 
    umount /home
  3. If the command in the previous step fails, use fuser to find processes hogging /home and kill them: 
    fuser -mvk /home
  4. Verify /home is no longer mounted: 
    grep home /proc/mounts
  5. Fill your partition with random data: 
    shred -v --iterations=1 /dev/VG00/LV_home
    This command proceeds at the sequential write speed of your device and may take some time to complete. It is an important step to ensure no unencrypted data is left on a used device, and to obfuscate the parts of the device that contain encrypted data as opposed to just random data.
  6. Initialize your partition: 
    cryptsetup --verbose --verify-passphrase luksFormat /dev/VG00/LV_home
  7. Open the newly encrypted device: 
    cryptsetup luksOpen /dev/VG00/LV_home home
  8. Make sure the device is present: 
    ls -l /dev/mapper | grep home
  9. Create a file system: 
    mkfs.ext3 /dev/mapper/home
  10. Mount the file system: 
    mount /dev/mapper/home /home
  11. Make sure the file system is visible: 
    df -h | grep home
  12. Add the following to the /etc/crypttab file: 
    home /dev/VG00/LV_home none
  13. Edit the /etc/fstab file, removing the old entry for /home and adding the following line: 
    /dev/mapper/home /home ext3 defaults 1 2
  14. Restore default SELinux security contexts: 
    /sbin/restorecon -v -R /home
  15. Reboot the machine: 
    shutdown -r now
  16. The entry in the /etc/crypttab makes your computer ask your luks passphrase on boot.
  17. Log in as root and restore your backup.
You now have an encrypted partition for all of your data to safely rest while the computer is off.

4.9.1.3. Add a New Passphrase to an Existing Device

Use the following command to add a new passphrase to an existing device: 
cryptsetup luksAddKey device
After being prompted for any one of the existing passprases for authentication, you will be prompted to enter the new passphrase.

4.9.1.4. Remove a Passphrase from an Existing Device

Use the following command to remove a passphrase from an existing device: 
cryptsetup luksRemoveKey device
You will be prompted for the passphrase you want to remove and then for any one of the remaining passphrases for authentication.

4.9.1.5. Creating Encrypted Block Devices in Anaconda

You can create encrypted devices during system installation. This allows you to easily configure a system with encrypted partitions.
To enable block device encryption, check the Encrypt System check box when selecting automatic partitioning or the Encrypt check box when creating an individual partition, software RAID array, or logical volume. After you finish partitioning, you will be prompted for an encryption passphrase. This passphrase will be required to access the encrypted devices. If you have pre-existing LUKS devices and provided correct passphrases for them earlier in the install process the passphrase entry dialog will also contain a check box. Checking this check box indicates that you would like the new passphrase to be added to an available slot in each of the pre-existing encrypted block devices.

Note

Checking the Encrypt System check box on the Automatic Partitioning screen and then choosing Create custom layout does not cause any block devices to be encrypted automatically.

Note

You can use kickstart to set a separate passphrase for each new encrypted block device.

4.9.2. Creating GPG Keys

GPG is used to identify yourself and authenticate your communications, including those with people you do not know. GPG allows anyone reading a GPG-signed email to verify its authenticity. In other words, GPG allows someone to be reasonably certain that communications signed by you actually are from you. GPG is useful because it helps prevent third parties from altering code or intercepting conversations and altering the message.

4.9.2.1. Creating GPG Keys in GNOME

To create a GPG Key in GNOME, follow these steps:
  1. Install the Seahorse utility, which makes GPG key management easier: 
    ~]# yum install seahorse
  2. To create a key, from the Applications Accessories menu select Passwords and Encryption Keys, which starts the application Seahorse.
  3. From the File menu select New and then PGP Key. Then click Continue.
  4. Type your full name, email address, and an optional comment describing who you are (for example: John C. Smith, , Software Engineer). Click Create. A dialog is displayed asking for a passphrase for the key. Choose a strong passphrase but also easy to remember. Click OK and the key is created.

Warning

If you forget your passphrase, you will not be able to decrypt the data.
To find your GPG key ID, look in the Key ID column next to the newly created key. In most cases, if you are asked for the key ID, prepend 0x to the key ID, as in 0x6789ABCD. You should make a backup of your private key and store it somewhere secure.

4.9.2.2. Creating GPG Keys in KDE

To create a GPG Key in KDE, follow these steps:
  1. Start the KGpg program from the main menu by selecting Applications Utilities Encryption Tool. If you have never used KGpg before, the program walks you through the process of creating your own GPG keypair.
  2. A dialog box appears prompting you to create a new key pair. Enter your name, email address, and an optional comment. You can also choose an expiration time for your key, as well as the key strength (number of bits) and algorithms.
  3. Enter your passphrase in the next dialog box. At this point, your key appears in the main KGpg window.

Warning

If you forget your passphrase, you will not be able to decrypt the data.
To find your GPG key ID, look in the Key ID column next to the newly created key. In most cases, if you are asked for the key ID, prepend 0x to the key ID, as in 0x6789ABCD. You should make a backup of your private key and store it somewhere secure.

4.9.2.3. Creating GPG Keys Using the Command Line

  1. Use the following shell command: 
    ~]$ gpg2 --gen-key
    This command generates a key pair that consists of a public and a private key. Other people use your public key to authenticate and decrypt your communications. Distribute your public key as widely as possible, especially to people who you know will want to receive authentic communications from you, such as a mailing list.
  2. A series of prompts directs you through the process. Press the Enter key to assign a default value if desired. The first prompt asks you to select what kind of key you prefer: 
    Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
Your selection?
    In almost all cases, the default is the correct choice. An RSA/RSA key allows you not only to sign communications, but also to encrypt files.
  3. Choose the key size: 
    RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)
    Again, the default, 2048, is sufficient for almost all users, and represents an extremely strong level of security.
  4. Choose when the key will expire. It is a good idea to choose an expiration date instead of using the default, which is none. If, for example, the email address on the key becomes invalid, an expiration date will remind others to stop using that public key. 
    Please specify how long the key should be valid.
0 = key does not expire
d = key expires in n days
w = key expires in n weeks
m = key expires in n months
y = key expires in n years
key is valid for? (0)
    Entering a value of 1y, for example, makes the key valid for one year. (You may change this expiration date after the key is generated, if you change your mind.)
  5. Before the gpg2 application asks for signature information, the following prompt appears: 
    Is this correct (y/N)?
    Enter y to finish the process.
  6. Enter your name and email address for your GPG key. Remember this process is about authenticating you as a real individual. For this reason, include your real name. If you choose a bogus email address, it will be more difficult for others to find your public key. This makes authenticating your communications difficult. If you are using this GPG key for self-introduction on a mailing list, for example, enter the email address you use on that list.
    Use the comment field to include aliases or other information. (Some people use different keys for different purposes and identify each key with a comment, such as "Office" or "Open Source Projects.")
  7. At the confirmation prompt, enter the letter O to continue if all entries are correct, or use the other options to fix any problems. Finally, enter a passphrase for your secret key. The gpg2 program asks you to enter your passphrase twice to ensure you made no typing errors.
  8. Finally, gpg2 generates random data to make your key as unique as possible. Move your mouse, type random keys, or perform other tasks on the system during this step to speed up the process. Once this step is finished, your keys are complete and ready to use: 
    pub  1024D/1B2AFA1C 2005-03-31 John Q. Doe <jqdoe@example.com>
Key fingerprint = 117C FE83 22EA B843 3E86  6486 4320 545E 1B2A FA1C
sub  1024g/CEA4B22E 2005-03-31 [expires: 2006-03-31]
  9. The key fingerprint is a shorthand "signature" for your key. It allows you to confirm to others that they have received your actual public key without any tampering. You do not need to write this fingerprint down. To display the fingerprint at any time, use this command, substituting your email address: 
    ~]$ gpg2 --fingerprint jqdoe@example.com
    Your "GPG key ID" consists of 8 hex digits identifying the public key. In the example above, the GPG key ID is 1B2AFA1C. In most cases, if you are asked for the key ID, prepend 0x to the key ID, as in 0x6789ABCD.

Warning

If you forget your passphrase, the key cannot be used and any data encrypted using that key will be lost.

4.9.3. Using openCryptoki for Public-Key Cryptography

openCryptoki is a Linux implementation of PKCS#11, which is a Public-Key Cryptography Standard that defines an application programming interface (API) to cryptographic devices called tokens. Tokens may be implemented in hardware or software. This chapter provides an overview of the way the openCryptoki system is installed, configured, and used in Red Hat Enterprise Linux 7.

4.9.3.1. Installing openCryptoki and Starting the Service

To install the basic openCryptoki packages on your system, including a software implementation of a token for testing purposes, enter the following command as root: 
~]# yum install opencryptoki
Depending on the type of hardware tokens you intend to use, you may need to install additional packages that provide support for your specific use case. For example, to obtain support for Trusted Platform Module (TPM) devices, you need to install the opencryptoki-tpmtok package.
See the Installing Packages section of the Red Hat Enterprise Linux 7 System Administrator's Guide for general information on how to install packages using the Yum package manager.
To enable the openCryptoki service, you need to run the pkcsslotd daemon. Start the daemon for the current session by executing the following command as root: 
~]# systemctl start pkcsslotd
To ensure that the service is automatically started at boot time, enter the following command: 
~]# systemctl enable pkcsslotd
See the Managing Services with systemd chapter of the Red Hat Enterprise Linux 7 System Administrator's Guide for more information on how to use systemd targets to manage services.

4.9.3.2. Configuring and Using openCryptoki

When started, the pkcsslotd daemon reads the /etc/opencryptoki/opencryptoki.conf configuration file, which it uses to collect information about the tokens configured to work with the system and about their slots.
The file defines the individual slots using key-value pairs. Each slot definition can contain a description, a specification of the token library to be used, and an ID of the slot's manufacturer. Optionally, the version of the slot's hardware and firmware may be defined. See the opencryptoki.conf(5) manual page for a description of the file's format and for a more detailed description of the individual keys and the values that can be assigned to them.
To modify the behavior of the pkcsslotd daemon at run time, use the pkcsconf utility. This tool allows you to show and configure the state of the daemon, as well as to list and modify the currently configured slots and tokens. For example, to display information about tokens, issue the following command (note that all non-root users that need to communicate with the pkcsslotd daemon must be a part of the pkcs11 system group): 
~]$ pkcsconf -t
See the pkcsconf(1) manual page for a list of arguments available with the pkcsconf tool.

Warning

Keep in mind that only fully trusted users should be assigned membership in the pkcs11 group, as all members of this group have the right to block other users of the openCryptoki service from accessing configured PKCS#11 tokens. All members of this group can also execute arbitrary code with the privileges of any other users of openCryptoki.

4.9.4. Using Smart Cards to Supply Credentials to OpenSSH

The smart card is a lightweight hardware security module in a USB stick, MicroSD, or SmartCard form factor. It provides a remotely manageable secure key store. In Red Hat Enterprise Linux 7, OpenSSH supports authentication using smart cards.
To use your smart card with OpenSSH, store the public key from the card to the ~/.ssh/authorized_keys file. Install the PKCS#11 library provided by the opensc package on the client. PKCS#11 is a Public-Key Cryptography Standard that defines an application programming interface (API) to cryptographic devices called tokens. Enter the following command as root: 
~]# yum install opensc

4.9.4.1. Retrieving a Public Key from a Card

To list the keys on your card, use the ssh-keygen command. Specify the shared library (OpenSC in the following example) with the -D directive. 
~]$ ssh-keygen -D /usr/lib64/pkcs11/opensc-pkcs11.so
ssh-rsa AAAAB3NzaC1yc[...]+g4Mb9

4.9.4.2. Storing a Public Key on a Server

To enable authentication using a smart card on a remote server, transfer the public key to the remote server. Do it by copying the retrieved string (key) and pasting it to the remote shell, or by storing your key to a file (smartcard.pub in the following example) and using the ssh-copy-id command: 
~]$ ssh-copy-id -f -i smartcard.pub user@hostname
user@hostname's password:

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh user@hostname"
and check to make sure that only the key(s) you wanted were added.
Storing a public key without a private key file requires to use the SSH_COPY_ID_LEGACY=1 environment variable or the -f option.

4.9.4.3. Authenticating to a Server with a Key on a Smart Card

OpenSSH can read your public key from a smart card and perform operations with your private key without exposing the key itself. This means that the private key does not leave the card. To connect to a remote server using your smart card for authentication, enter the following command and enter the PIN protecting your card: 
[localhost ~]$ ssh -I /usr/lib64/pkcs11/opensc-pkcs11.so hostname
Enter PIN for 'Test (UserPIN)':
[hostname ~]$
Replace the hostname with the actual host name to which you want to connect.
To save unnecessary typing next time you connect to the remote server, store the path to the PKCS#11 library in your ~/.ssh/config file: 
Host hostname
    PKCS11Provider /usr/lib64/pkcs11/opensc-pkcs11.so
Connect by running the ssh command without any additional options: 
[localhost ~]$ ssh hostname
Enter PIN for 'Test (UserPIN)':
[hostname ~]$

4.9.4.4. Using ssh-agent to Automate PIN Logging In

Set up environmental variables to start using ssh-agent. You can skip this step in most cases because ssh-agent is already running in a typical session. Use the following command to check whether you can connect to your authentication agent: 
~]$ ssh-add -l
Could not open a connection to your authentication agent.
~]$ eval `ssh-agent`
To avoid writing your PIN every time you connect using this key, add the card to the agent by running the following command: 
~]$ ssh-add -s /usr/lib64/pkcs11/opensc-pkcs11.so
Enter PIN for 'Test (UserPIN)':
Card added: /usr/lib64/pkcs11/opensc-pkcs11.so
To remove the card from ssh-agent, use the following command: 
~]$ ssh-add -e /usr/lib64/pkcs11/opensc-pkcs11.so
Card removed: /usr/lib64/pkcs11/opensc-pkcs11.so

Note

FIPS 201-2 requires explicit user action by the Personal Identity Verification (PIV) cardholder as a condition for use of the digital signature key stored on the card. OpenSC correctly enforces this requirement.
However, for some applications it is impractical to require the cardholder to enter the PIN for each signature. To cache the smart card PIN, remove the # character before the pin_cache_ignore_user_consent = true; option in the /etc/opensc-x86_64.conf.
See the Cardholder Authentication for the PIV Digital Signature Key (NISTIR 7863) report for more information.

4.9.4.5. Additional Resources

Setting up your hardware or software token is described in the Smart Card support in Red Hat Enterprise Linux 7 article.
For more information about the pkcs11-tool utility for managing and using smart cards and similar PKCS#11 security tokens, see the pkcs11-tool(1) man page.

4.9.5. Trusted and Encrypted Keys

Trusted and encrypted keys are variable-length symmetric keys generated by the kernel that utilize the kernel keyring service. The fact that the keys never appear in user space in an unencrypted form means that their integrity can be verified, which in turn means that they can be used, for example, by the extended verification module (EVM) to verify and confirm the integrity of a running system. User-level programs can only ever access the keys in the form of encrypted blobs.
Trusted keys need a hardware component: the Trusted Platform Module (TPM) chip, which is used to both create and encrypt (seal) the keys. The TPM seals the keys using a 2048-bit RSA key called the storage root key (SRK).
In addition to that, trusted keys may also be sealed using a specific set of the TPM's platform configuration register (PCR) values. The PCR contains a set of integrity-management values that reflect the BIOS, boot loader, and operating system. This means that PCR-sealed keys can only be decrypted by the TPM on the exact same system on which they were encrypted. However, once a PCR-sealed trusted key is loaded (added to a keyring), and thus its associated PCR values are verified, it can be updated with new (or future) PCR values, so that a new kernel, for example, can be booted. A single key can also be saved as multiple blobs, each with different PCR values.
Encrypted keys do not require a TPM, as they use the kernel AES encryption, which makes them faster than trusted keys. Encrypted keys are created using kernel-generated random numbers and encrypted by a master key when they are exported into user-space blobs. This master key can be either a trusted key or a user key, which is their main disadvantage — if the master key is not a trusted key, the encrypted key is only as secure as the user key used to encrypt it.

4.9.5.1. Working with keys

Before performing any operations with the keys, ensure that the trusted and encrypted-keys kernel modules are loaded in the system. Consider the following points while loading the kernel modules in different RHEL kernel architectures:
  • For RHEL kernels with the x86_64 architecture, the TRUSTED_KEYS and ENCRYPTED_KEYS code is built in as a part of the core kernel code. As a result, the x86_64 system users can use these keys without loading the trusted and encrypted-keys modules.
  • For all other architectures, it is necessary to load the trusted and encrypted-keys kernel modules before performing any operations with the keys. To load the kernel modules, execute the following command: 
    ~]# modprobe trusted encrypted-keys
The trusted and encrypted keys can be created, loaded, exported, and updated using the keyctl utility. For detailed information about using keyctl, see keyctl(1).

Note

In order to use a TPM (such as for creating and sealing trusted keys), it needs to be enabled and active. This can be usually achieved through a setting in the machine's BIOS or using the tpm_setactive command from the tpm-tools package of utilities. Also, the TrouSers application needs to be installed (the trousers package), and the tcsd daemon, which is a part of the TrouSers suite, running to communicate with the TPM.
To create a trusted key using a TPM, execute the keyctl command with the following syntax: 
~]$ keyctl add trusted name "new keylength [options]" keyring
Using the above syntax, an example command can be constructed as follows: 
~]$ keyctl add trusted kmk "new 32" @u
642500861
The above example creates a trusted key called kmk with the length of 32 bytes (256 bits) and places it in the user keyring (@u). The keys may have a length of 32 to 128 bytes (256 to 1024 bits). Use the show subcommand to list the current structure of the kernel keyrings: 
~]$ keyctl show
Session Keyring
       -3 --alswrv    500   500  keyring: _ses
 97833714 --alswrv    500    -1   \_ keyring: _uid.1000
642500861 --alswrv    500   500       \_ trusted: kmk
The print subcommand outputs the encrypted key to the standard output. To export the key to a user-space blob, use the pipe subcommand as follows: 
~]$ keyctl pipe 642500861 > kmk.blob
To load the trusted key from the user-space blob, use the add command again with the blob as an argument: 
~]$ keyctl add trusted kmk "load `cat kmk.blob`" @u
268728824
The TPM-sealed trusted key can then be employed to create secure encrypted keys. The following command syntax is used for generating encrypted keys: 
~]$ keyctl add encrypted name "new [format] key-type:master-key-name keylength" keyring
Based on the above syntax, a command for generating an encrypted key using the already created trusted key can be constructed as follows: 
~]$ keyctl add encrypted encr-key "new trusted:kmk 32" @u
159771175
To create an encrypted key on systems where a TPM is not available, use a random sequence of numbers to generate a user key, which is then used to seal the actual encrypted keys. 
~]$ keyctl add user kmk-user "`dd if=/dev/urandom bs=1 count=32 2>/dev/null`" @u
427069434
Then generate the encrypted key using the random-number user key: 
~]$ keyctl add encrypted encr-key "new user:kmk-user 32" @u
1012412758
The list subcommand can be used to list all keys in the specified kernel keyring: 
~]$ keyctl list @u
2 keys in keyring:
427069434: --alswrv  1000  1000 user: kmk-user
1012412758: --alswrv  1000  1000 encrypted: encr-key

Important

Keep in mind that encrypted keys that are not sealed by a master trusted key are only as secure as the user master key (random-number key) used to encrypt them. Therefore, the master user key should be loaded as securely as possible and preferably early during the boot process.

4.9.5.2. Additional Resources

The following offline and online resources can be used to acquire additional information pertaining to the use of trusted and encrypted keys.

Installed Documentation

  • keyctl(1) — Describes the use of the keyctl utility and its subcommands.

Online Documentation

See Also

4.9.6. Using the Random Number Generator

In order to be able to generate secure cryptographic keys that cannot be easily broken, a source of random numbers is required. Generally, the more random the numbers are, the better the chance of obtaining unique keys. Entropy for generating random numbers is usually obtained from computing environmental "noise" or using a hardware random number generator.
The rngd daemon, which is a part of the rng-tools package, is capable of using both environmental noise and hardware random number generators for extracting entropy. The daemon checks whether the data supplied by the source of randomness is sufficiently random and then stores it in the random-number entropy pool of the kernel. The random numbers it generates are made available through the /dev/random and /dev/urandom character devices.
The difference between /dev/random and /dev/urandom is that the former is a blocking device, which means it stops supplying numbers when it determines that the amount of entropy is insufficient for generating a properly random output. Conversely, /dev/urandom is a non-blocking source, which reuses the entropy pool of the kernel and is thus able to provide an unlimited supply of pseudo-random numbers, albeit with less entropy. As such, /dev/urandom should not be used for creating long-term cryptographic keys.
To install the rng-tools package, issue the following command as the root user: 
~]# yum install rng-tools
To start the rngd daemon, execute the following command as root: 
~]# systemctl start rngd
To query the status of the daemon, use the following command: 
~]# systemctl status rngd
To start the rngd daemon with optional parameters, execute it directly. For example, to specify an alternative source of random-number input (other than /dev/hwrandom), use the following command: 
~]# rngd --rng-device=/dev/hwrng
The previous command starts the rngd daemon with /dev/hwrng as the device from which random numbers are read. Similarly, you can use the -o (or --random-device) option to choose the kernel device for random-number output (other than the default /dev/random). See the rngd(8) manual page for a list of all available options.
To check which sources of entropy are available in a given system, execute the following command as root: 
~]# rngd -vf
Unable to open file: /dev/tpm0
Available entropy sources:
	DRNG

Note

After entering the rngd -v command, the according process continues running in background. The -b, --background option (become a daemon) is applied by default.
If there is not any TPM device present, you will see only the Intel Digital Random Number Generator (DRNG) as a source of entropy. To check if your CPU supports the RDRAND processor instruction, enter the following command: 
~]$ cat /proc/cpuinfo | grep rdrand

Note

For more information and software code examples, see Intel Digital Random Number Generator (DRNG) Software Implementation Guide.
The rng-tools package also contains the rngtest utility, which can be used to check the randomness of data. To test the level of randomness of the output of /dev/random, use the rngtest tool as follows: 
~]$ cat /dev/random | rngtest -c 1000
rngtest 5
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 998
rngtest: FIPS 140-2 failures: 2
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 0
rngtest: FIPS 140-2(2001-10-10) Long run: 2
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=1.171; avg=8.453; max=11.374)Mibits/s
rngtest: FIPS tests speed: (min=15.545; avg=143.126; max=157.632)Mibits/s
rngtest: Program run time: 2390520 microseconds
A high number of failures shown in the output of the rngtest tool indicates that the randomness of the tested data is insufficient and should not be relied upon. See the rngtest(1) manual page for a list of options available for the rngtest utility.
Red Hat Enterprise Linux 7 introduced the virtio RNG (Random Number Generator) device that provides KVM virtual machines with access to entropy from the host machine. With the recommended setup, hwrng feeds into the entropy pool of the host Linux kernel (through /dev/random), and QEMU will use /dev/random as the source for entropy requested by guests.
The virtio RNG device

Figure 4.1. The virtio RNG device

Previously, Red Hat Enterprise Linux 7.0 and Red Hat Enterprise Linux 6 guests could make use of the entropy from hosts through the rngd user space daemon. Setting up the daemon was a manual step for each Red Hat Enterprise Linux installation. With Red Hat Enterprise Linux 7.1, the manual step has been eliminated, making the entire process seamless and automatic. The use of rngd is now not required and the guest kernel itself fetches entropy from the host when the available entropy falls below a specific threshold. The guest kernel is then in a position to make random numbers available to applications as soon as they request them.
The Red Hat Enterprise Linux installer, Anaconda, now provides the virtio-rng module in its installer image, making available host entropy during the Red Hat Enterprise Linux installation.

Important

To correctly decide which random number generator you should use in your scenario, see the Understanding the Red Hat Enterprise Linux random number generator interface article.
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.