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: AES - Advanced Encryption Standard - FIPS PUB 197 Twofish (a 128-bit block cipher) Serpent cast5 - RFC 2144 cast6 - RFC 2612 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! Enter runlevel 1 by typing the following at a shell prompt as root: Unmount your existing /home : If the command in the step fails, use fuser to find processes hogging /home and kill them: Verify /home is no longer mounted: Fill your partition with random data: 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. Initialize your partition: Open the newly encrypted device: Make sure the device is present: Create a file system: Mount the file system: Make sure the file system is visible: Add the following to the /etc/crypttab file: Edit the /etc/fstab file, removing the old entry for /home and adding the following line: Restore default SELinux security contexts: Reboot the machine: The entry in the /etc/crypttab makes your computer ask your luks passphrase on boot. 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: 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: 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.1.6. Additional Resources For additional information on LUKS or encrypting hard drives under Red Hat Enterprise Linux 7 visit one of the following links: LUKS home page LUKS/cryptsetup FAQ LUKS - Linux Unified Key Setup Wikipedia article HOWTO: Creating an encrypted Physical Volume (PV) using a second hard drive and pvmove 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: Install the Seahorse utility, which makes GPG key management easier: To create a key, from the Applications Accessories menu select Passwords and Encryption Keys , which starts the application Seahorse . From the File menu select New and then PGP Key . Then click Continue . Type your full name, email address, and an optional comment describing who you are (for example: John C. Smith, jsmith@example.com , 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 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: 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. 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. Enter your passphrase in the 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 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 Use the following shell command: 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. 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: 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. Choose the key size: Again, the default, 2048, is sufficient for almost all users, and represents an extremely strong level of security. 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. 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.) Before the gpg2 application asks for signature information, the following prompt appears: Enter y to finish the process. 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.") 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. 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: 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: 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.2.4. About Public Key Encryption Wikipedia - Public Key Cryptography HowStuffWorks - Encryption 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 : 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 : To ensure that the service is automatically started at boot time, enter the following command: 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): 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 : 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. 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: 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: Replace the hostname with the actual host name to which you want to connect. To save unnecessary typing time you connect to the remote server, store the path to the PKCS#11 library in your ~/.ssh/config file: Connect by running the ssh command without any additional options: 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: To avoid writing your PIN every time you connect using this key, add the card to the agent by running the following command: To remove the card from ssh-agent , use the following command: 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: 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: ~]USD keyctl add trusted name "new keylength [ options ]" keyring Using the above syntax, an example command can be constructed as follows: 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: 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: To load the trusted key from the user-space blob, use the add command again with the blob as an argument: The TPM -sealed trusted key can then be employed to create secure encrypted keys. The following command syntax is used for generating encrypted keys: ~]USD 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: 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. Then generate the encrypted key using the random-number user key: The list subcommand can be used to list all keys in the specified kernel keyring: 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 Red Hat Enterprise Linux 7 SELinux User's and Administrator's Guide - The SELinux User's and Administrator's Guide for Red Hat Enterprise Linux 7 describes the basic principles of SELinux and documents in detail how to configure and use SELinux with various services, such as the Apache HTTP Server . https://www.kernel.org/doc/Documentation/security/keys-trusted-encrypted.txt - The official documentation about the trusted and encrypted keys feature of the Linux kernel. See Also Section A.1.1, "Advanced Encryption Standard - AES" provides a concise description of the Advanced Encryption Standard . Section A.2, "Public-key Encryption" describes the public-key cryptographic approach and the various cryptographic protocols it uses. 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: To start the rngd daemon, execute the following command as root : To query the status of the daemon, use the following command: 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: The 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 : 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: 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: 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. 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.

Commands:
telinit 1
umount /home
fuser -mvk /home
grep home /proc/mounts
shred -v --iterations=1 /dev/VG00/LV_home
cryptsetup --verbose --verify-passphrase luksFormat /dev/VG00/LV_home
cryptsetup luksOpen /dev/VG00/LV_home home
ls -l /dev/mapper | grep home
mkfs.ext3 /dev/mapper/home
mount /dev/mapper/home /home
df -h | grep home
home /dev/VG00/LV_home none
/dev/mapper/home /home ext3 defaults 1 2
/sbin/restorecon -v -R /home
shutdown -r now
cryptsetup luksAddKey device
cryptsetup luksRemoveKey device
~]# yum install seahorse
~]USD gpg2 --gen-key
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?
RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048)
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)
Is this correct (y/N)?
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]
~]USD gpg2 --fingerprint jqdoe@example.com
~]# yum install opencryptoki
~]# systemctl start pkcsslotd
~]# systemctl enable pkcsslotd
~]USD pkcsconf -t
~]# yum install opensc
~]USD ssh-keygen -D /usr/lib64/pkcs11/opensc-pkcs11.so ssh-rsa AAAAB3NzaC1yc[...]+g4Mb9
~]USD 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.
[localhost ~]USD ssh -I /usr/lib64/pkcs11/opensc-pkcs11.so hostname Enter PIN for 'Test (UserPIN)': [hostname ~]USD
Host hostname PKCS11Provider /usr/lib64/pkcs11/opensc-pkcs11.so
[localhost ~]USD ssh hostname Enter PIN for 'Test (UserPIN)': [hostname ~]USD
~]USD ssh-add -l Could not open a connection to your authentication agent. ~]USD eval `ssh-agent`
~]USD ssh-add -s /usr/lib64/pkcs11/opensc-pkcs11.so Enter PIN for 'Test (UserPIN)': Card added: /usr/lib64/pkcs11/opensc-pkcs11.so
~]USD ssh-add -e /usr/lib64/pkcs11/opensc-pkcs11.so Card removed: /usr/lib64/pkcs11/opensc-pkcs11.so
~]# modprobe trusted encrypted-keys
~]USD keyctl add trusted kmk "new 32" @u 642500861
~]USD keyctl show Session Keyring -3 --alswrv 500 500 keyring: _ses 97833714 --alswrv 500 -1 \_ keyring: _uid.1000 642500861 --alswrv 500 500 \_ trusted: kmk
~]USD keyctl pipe 642500861 > kmk.blob
~]USD keyctl add trusted kmk "load `cat kmk.blob`" @u 268728824
~]USD keyctl add encrypted encr-key "new trusted:kmk 32" @u 159771175
~]USD keyctl add user kmk-user "`dd if=/dev/urandom bs=1 count=32 2>/dev/null`" @u 427069434
~]USD keyctl add encrypted encr-key "new user:kmk-user 32" @u 1012412758
~]USD keyctl list @u 2 keys in keyring: 427069434: --alswrv 1000 1000 user: kmk-user 1012412758: --alswrv 1000 1000 encrypted: encr-key
~]# yum install rng-tools
~]# systemctl start rngd
~]# systemctl status rngd
~]# rngd --rng-device= /dev/hwrng
~]# rngd -vf Unable to open file: /dev/tpm0 Available entropy sources: DRNG
~]USD cat /proc/cpuinfo | grep rdrand
~]USD 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