PCI DSS and Red Hat Enterprise Linux (Part #3)

Author: Feodor Kulishov

[Part #1] [Part #2]

Requirement 3: Protect stored cardholder data

3.4.1.а If disk encryption is used, logical access must be managed independently of native operating system access control mechanisms

The essence of the requirement is that access to decrypted data should be allowed only if the key is known; thereby, any processes and users (even system administrators) will not be able to read and modify such data correctly if they will not have the decryption key.

For all widespread mechanisms of encryption of the Linux file systems (cryptsetup, cryptsetup + LUKS, EncFS, eCryptFS), the decrypted file system (FS) is logically identical to the ordinary one and has the same access attributes, ACLs, etc. Thereby, the file system property of transparency is implemented. However, even if the data access rights are specified correctly, the root and the processes with UID=0 will be able to access any data after it will be decrypted by the key owner; is means that the given PCI DSS requirements are not fulfilled for all mechanisms of encryption of the Linux file systems.

SELinux settings that prescribe that only specified users can access the decrypted data will not ensure the requirement fulfillment, because:

  1. The situation will depend on SELinux, which represents the OS access isolation mechanism
  2. Even if the SELinux policies are defined, the root will be able to change them and access the decrypted data

From the other part, this requirement can be interpreted as «data access isolation mechanisms and data encryption mechanisms should be implemented by different OS components»; then the standard data encryption subsystem for Linux will satisfy these requirements.

Moreover, there is still another way to interpret this item. Maybe, the requirements concern only disc encryption hardware. In this case, the 3.4.1.a requirement will not be imposed and an organization will be free to apply any suitable technique of software encryption (including the standard LUKS) without any restrictions.

When considering this requirement, one should make a decision, whether the disc encryption is necessary at all (it concerns hard discs of servers/workstations and external disk arrays). In practice, these media require encryption in the following cases:

  1. Critical data is stored on a laptop that can leave the controlled perimeter (or leaves it regularly). The data can concern not only the payment cards, but also the network architecture, server accounts, etc
  2. Defective hard discs are given for repair to a third-party organization (which is a usual situation), which has a chance to recover some sensitive information from these discs and use this information for their purposes
  3. It is necessary to carry the configured and operational equipment (servers, disc arrays, etc.) with data from one place to another using the service of third-party organizations (carrier companies etc.) that cannot be fully controlled

3.4.1.с Verify that cardholder data on removable media is encrypted wherever stored. Note: Disk encryption often cannot encrypt removable media, so data stored on this media will need to be encrypted separately

To encrypt data on removable media, one can apply encryption of separate discs (eCryptFS, OpenSSL) or encryption of the entire disc (LUKS). eCryptFS is not included into the considered distribution kits by default, so we will discuss OpenSSL and LUKS.

You can encrypt separate discs using openssl, for example:
openssl enc -aes-256-cbc -in input.file -out output.file

For decryption, the “-d” key is additionally specified:
openssl enc -aes-256-cbc -d -in output.file -out input.file.decrypted

However, this method is most suitable for storing backup copies (“encrypted and forgotten”), because access to the encrypted data is laborious and non-transparent in this case.

A more universal scenario is to encrypt data at the disc level in the kernel mode. For this, perform the following actions:

1. Fill the target partition with pseudorandom data (let it be /dev/sdb1): 
dd if=/dev/urandom of=/dev/sdb1

2. Configure encryption of an empty disc partition: 
cryptsetup -y -c aes –key-size=256 luksFormat /dev/sdb1

Here, it will be necessary to enter the encryption password twice.

3. Create a file system in the encrypted partition. For this purpose, open it in manual mode: 
cryptsetup luksOpen /dev/sdb1 topsecret
(here, it is necessary to enter the password; it will not be prompted any more until the device is closed);

After this operation, a device with encrypted data /dev/mapper/topsecret will appear in the system; it can be accessed as a common disc partition or logical volume. 
mkfs.ext3 –m0 /dev/mapper/topsecret

Then, make sure that the operation was successful: 
mkdir /mnt/topsecret 
mount /dev/mapper/topsecret /mnt/topsecret 
ll /mnt/topsecret

That’s all; the created encrypted FS is ready for regular reading/writing.

IT IS IMPORTANT. It is necessary to configure the corresponding access permissions for decrypted data by setting standard rwz rights, file system ACL, and SELinux (the latter one if necessary). One should also take into consideration that the root can gain any access to the decrypted data.

If this FS is used occasionally, then you can skip the item 4 and execute the following two commands every time the FS is used:
cryptsetup luksOpen /dev/sdb1 topsecret
mount /dev/mapper/topsecret /mnt/topsecret

After the work with the encrypted device is finished, it should be logically erased:
cryptsetup luksClose topsecret

4. To ensure automounting of the FS at the OS boot (which is urgent for disc partitions, not for external devices), it is necessary to add the following entries to the files /etc/crypttab:
topsecret       /dev/sdb1     none    luks,check=ext2,retry=5

Here, the option «none» means that the password is typed from the keyboard (or the path to the file containing the encryption key is specified, see man crypttab), the last field contains the encryption options (for example, retry=5 defines the maximal number of attempts to enter the password).

ATTENTION! If the partition is described in /etc/crypttab (it doesn\’t matter whether this FS is presented in /etc/fstab or not), then the OS will attempt to decrypt it at startup (at that, if the password is typed from the keyboard, then the OS will be waiting for this input and will not boot until the password will be entered; such behavior is extremely undesirable for servers). If there is no need in continuous presence of the encrypted partition in the system, then the /etc/crypttab setting is not required.

/dev/mapper/topsecret   /mnt/topsecret          ext3    noauto,defaults      0 0

5. In unforeseen circumstances (for example, in case of power-off), the decrypted device (here, /dev/mapper/topsecret) disappears from the system; it will not be possible to access data if the key of partition decryption will not be reentered.

6. To make sure that the data is stored in the encrypted form, you can verify whether the specified disc partition is encrypted with LUKS:

cryptsetup isLuks /dev/sdb1 && echo OK || echo fail

If separate files are encrypted with OpenSSL or other similar tools, such check can be fully-automatic.
The only restriction is that you should ensure that the NULL encryption algorithm wasn’t applied:
grep -a -q pattern /dev/sdb1 && echo fail || echo OK

where “pattern” represents any part of the unencrypted file.

3.5.2 Examine system configuration files to verify that keys are stored in encrypted format and that key-encrypting keys are stored separately from data-encrypting keys

Application of LUKS makes this requirement to be fulfilled, because the data encryption keys are stored in the encrypted form (they are encrypted using a password typed by a user from the keyboard) in the existing encrypted FS partition, i.e. these keys are stored separately from the key encryption keys.

You can check how the LUKS encryption is used as described below:
cryptsetup isLuks /dev/sdb1 && echo OK || echo fail

Here, /dev/sdb1 represents the encrypted partition (NOT the name of the decrypted device in /dev/mapper), which can be a disc partition or a logical volume.

In conclusion of this chapter, let us notice that the CIS doesn’t consider the problems of encryption of the stored data.

6 thoughts on “PCI DSS and Red Hat Enterprise Linux (Part #3)

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.