-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
4.17
-
None
-
Quality / Stability / Reliability
-
False
-
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
Description of problem:
- IHAC who is having query on the disk encryption algorithm used for book disk encryption. Referencing the same documentation link: https://docs.openshift.com/container-platform/4.17/installing/install_config/installing-customizing.html
- "Uses AES-256-XTS encryption, or AES-256-CBC if FIPS mode is enabled"
Is this referring to the root partition then? Because as we have seen FIPS is not enabled and the encryption method used does not match the documentation. To be honest I had actually though that this encryption applies to all the disks regardless of the partition. - I'm not sure why we'd ever chose a different algorithm for disk encryption in FIPS mode, since symmetric disk encryption happens in the kernel, which did have [AES-XTS certified in RHEL 8.6 already](https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Certificate/4804) (the 8.8 certificate hasn't been issued yet, so I can't link to the equivalent page in 8.8)
Version-Release number of selected component (if applicable):
Actual results:
In the [Doc](https://docs.openshift.com/container-platform/4.17/installing/install_config/installing-customizing.html) statement for disk encryption algorithm used for book disk encryption seems to be an wrong. "Uses AES-256-XTS encryption, or AES-256-CBC if FIPS mode is enabled"
Expected results:
The documentation should be corrected as it confuses the customer about the disk encryption algorithm used for book disk encryption.
Additional info:
The confusion comes as the below lines are mentioned in the Doc[1] that if the FIPS is enabled then it uses AES-256-XTS encryption, or AES-256-CBC and then customer check the FIPS whether it is enable or not using below command which is mentioned in KB[2].
~~~
$ oc get cm cluster-config-v1 -n kube-system -o json | jq -r '.data' | grep -i "fips"
~~~
[1] ** https://docs.openshift.com/container-platform/4.17/installing/install_config/installing-customizing.html **
"Uses AES-256-XTS encryption, or AES-256-CBC if FIPS mode is enabled"
In my cluster the FIPS is not enabled still the encrytpion algorithm used in my cluster is AES-CBC. So I thinks it is an conflict in documentation.
# cryptsetup status root /dev/mapper/root is active and is in use. type: LUKS2 cipher: aes-cbc-essiv:sha256 keysize: 256 bits key location: keyring device: /dev/nvme0n1p4 sector size: 512 offset: 32768 sectors size: 1874169823 sectors mode: read/write
This may also depend on whether the customer did set up disk encryption first (e.g., on install) and then enabled FIPS afterwards as a day-two operation, or whether the system was installed in FIPS mode. In any case, it does seem like this system uses AES-CBC-ESSIV, not AES-XTS.
In any case, I don't know the exact behavior of cryptsetup in FIPS mode or not, so you should probably contact the RHEL cryptsetup maintainer.
Cryptsetup (LUKS2) uses by default xts-aes by default both for key encryption and data encryption. It applies to both FIPS mode and non-FIPS mode. There's only one change related to FIPS and it's PBKDF for deriving kek from passphrase. In FIPS mode it's switched from Argon2id to pbkdf2 since NIST did not approve Argon2 (any variant) yet.
So, if there's aes-cbc-essiv:sha256 cipher configured for data encryption it must have been chosen on purpose by some higher layer in the stack
It's probably both the documentation and the behavior that's wrong.
The docs shouldn't suggest that AES-256-CBC (really AES-256-CBC-ESSIV) is used in FIPS mode, because there's absolutely no need to make a different choice in FIPS mode. And behavior wise, nothing should be choosing AES-256-CBC-ESSIV over AES-256-XTS, AES-256-XTS should always be used by default.