Joachim Korittky wrote:
after I couldn't find a way to mount my encrypted volumes und ClearOS 6.2 I did a little bit reverse engineering to help myself.
The dm-crypt app from 5.x has yet to be ported to ClearOS 6.x. As it is an old app, it requires a complete re-write and dusting off as you discovered.
The entered passphrase can be found in the file /tmp/dmcryptvtVz3E, padded with ASCII “0x0x...” at the beginning and the end.
This means that the user doesn’t see the “really” used passphrase and it is therefore impossible to “cryptsetup” the volume without ClearOS 5.2 Interface or this knowledge.
I agree that this should have been documented. Up until now, I don't recall anyone asking about how to manually mount an encrypted volume from the command-line. Perhaps that is why this "padding" information was not added to the user guide documentation. For 6.x, the padding will be changed to a SHA256 hash and will be documented to keep interested parties from having to read through source code.
For me the command for setting up the mapper looks very odd.
-c names the parameter for the cypher and leads to “aes-cbc-plain”. (which should no longer be used)
-h names the used hash algorithm for the key, but “aes-cbc-essiv:sha256” isn’t a valid hash algorithm.
Obviously the values for –c and –h are swapped!
Yes, and good catch! The correct parameters to cryptsetup should be:
# cryptsetup -c aes-cbc-essiv:sha256 -d /tmp/keyfileXYZ create <name> <loop_dev>
The AES key-size will default to 256. The key in /tmp/keyfileXYZ is to be SHA256 hashed.
Hmm, but why does it work anyway and what hapens with the hash algorithm?
I think the passphrase isn’t hashed at all!
No, it isn't and today I asked myself the same question: How can this work, why doesn't cryptsetup fail when supplied with an invalid hash algorithm? The answer I have discovered: the hash algorithm is ignored! It's not very apparent in the manual page for cryptsetup, but if you supply your own "key material" using the -d (--key-file) parameter, the -h (--hash) parameter is not parsed/validated because it isn't needed. The "key material" is accepted (possibly padded or truncated) as-is. Now I know that when using --key-file, I must hash the key myself as cryptsetup won't do it for me (even with correct parameters such as --hash sha256).
Hey, I and all other system admins can read my secret passphrase! For me this seems like the passphrase is used as master-key without any hashing.
The version of cryptsetup is 1.0.3. - very old!
Yes, any admin (anyone with root or disk permissions) will be able to see the key used for any encrypted volume. This is the case regardless of whether the key has been hashed or not. If the key had been hashed, then at least other super-users would not know the original plain-text key.
My point being that once your encrypted volume has been setup with cryptsetup, anyone with super-user access can view the key (hashed or not), and the decrypted contents. So although I agree it is a mistake to not hash the plain-text key (which was not my intention but a wrong assumption about cryptsetup), i wouldn't be too concerned about another super-user being able to read it.
I come to the result that a missing support for encrypted volumes in 6.2 would be no pitty because the security level is quite poor unless the user picks a very random passphrase.
You should probably check this. And when I am not totally wrong you should warn the other users.
Thanks for doing the research and bringing this to our attention. Aside from using aes-cbc-plain (accidentally), I disagree that the security level is quite poor. Can you explain how using a poor/weak password that is hashed (with any algorithm) would increase the security level against a brute force attack? My point being that a poor/weak password is still a poor/weak password regardless if it has been hashed or not (easily recoverable via brute force iteration).
If you are saying the security level is low because another super-user could read the plain-text key, then I disagree as well. First, you shouldn't be giving super-user access to those you don't trust, and secondly, even with a hashed password, I would still be able to read the key using dmsetup when the volume is created.
The security of the current implementation is not as good as it could be, nor is it as secure as was intended due to incorrect usage of cryptsetup. This will be corrected. I wish to be clear however, that there is no significant security threat for existing 5.x encrypted volumes.