6 ms·

Cryptsetup 2.0.0 introduces new on-disk LUKS2 format

100 points by tyngde 9y ago

wonderous 9y ago
Anyone aware of any independent formal security audits of this version of this or any prior version of LUKS?
raverbashing 9y ago
As noted on the release notes, do not use this for production systems (for now) unless you have a backup of your data
2bluesc 9y ago
Section regarding the format: LUKS2 format and features ~~~~~~~~~~~~~~~~~~~~~~~~~ The LUKS2 is an on-disk storage format designed to provide simple key management, primarily intended for Full Disk Encryption based on dm-crypt. The LUKS2 is inspired by LUKS1 format and in some specific situations (most of the default configurations) can be converted in-place from LUKS1. The LUKS2 format is designed to allow future updates of various parts without the need to modify binary structures and internally uses JSON text format for metadata. Compilation now requires the json-c library that is used for JSON data processing. On-disk format provides redundancy of metadata, detection of metadata corruption and automatic repair from metadata copy. NOTE: For security reasons, there is no redundancy in keyslots binary data (encrypted keys) but the format allows adding such a feature in future. NOTE: to operate correctly, LUKS2 requires locking of metadata. Locking is performed by using flock() system call for images in file and for block device by using a specific lock file in /run/lock/cryptsetup. This directory must be created by distribution (do not rely on internal fallback). For systemd-based distribution, you can simply install scripts/cryptsetup.conf into tmpfiles.d directory. For more details see LUKS2-format.txt and LUKS2-locking.txt in the docs directory. (Please note this is just overview, there will be more formal documentation later.)
- deleted 9y ago
  [deleted]
- codys 9y ago
  > JSON text format for metadata It seems like it could be better to use some easier to parse binary format that allows the same flexibility that json does, like cbor/msgpack/bson. Using JSON here is a very strange choice.
  - cesarb 9y ago
    At least it's not XML.
  - loeg 9y ago
    > Using JSON here is a very strange choice. I agree! Perhaps the userspace administrative tool (which links json-c) parses it and converts it to something more like an ioctl struct for the kernel.
    - majewsky 9y ago
      AFAIK the kernel only contains dm-crypt. The whole key handling takes place in userspace, in cryptsetup(1). (If you want to have a bad day, you can send a patch to Linus to put a JSON parser in the kernel.)
  - Crontab 9y ago
    To me, the worst part is that it introduces a library dependency, which itself can introduce security issues unless they intend to audit it. I don't under this choice at all.
  - klodolph 9y ago
    BSON, despite its name, is really just a format for MongoDB rather than a binary alternative for JSON.
    - deleted 9y ago
      [deleted]
deleted 9y ago
[deleted]
sprash 9y ago
Doesn't solve my most important problem with LUKS: Allowing Trim passthrough on SSDs without impacting vulnerability. Also, why use json for meta-data instead of simple C Structs? No human is supposed to read this kind of data anyways.
- simcop2387 9y ago
  Likely for easier future extensions to the metadata without requiring prior agreement among all implementations about how things are laid out.
- bmalehorn 9y ago
  > Alowing Trim passthrough on SSDs without impacting vulnerability. Unfortunately I don’t think that’s possible. If I scan your encrypted disk and see that 10% of blocks are zeroed out, I can assume that your disk is 90% full. So information has been leaked, which is arguably a vulnerability.
  - saghm 9y ago
    Couldn't this be an opt-in feature? For some people, this might be a reasonable trade-off given their threat model
    - Denvercoder9 9y ago
      Yes, it can be, and it's already present.
      - saghm 9y ago
        Oops, probably should have checked before asking
    - kakarot 9y ago
      Fedora decided with release 27 to enable trim by default on newly created encrypted devices. I was not happy about this decision and try to make some noise but nobody really seem to care. There is a reason that it is disabled by default in the Linux kernel, and making this kind of decision on behalf of the users without any input from the community is pretty fucked up. Personally, I would like to explore the idea of a secure enclave that keeps a map of which blocks are in use that gets referred to during write operations. This seems like a problem that is going to need to be solved with hardware.
jwilk 9y ago
LUKS2 on-disk format specification: https://gitlab.com/cryptsetup/cryptsetup/raw/v2.0.0/docs/LUKS2-format.txt https://gitlab.com/cryptsetup/cryptsetup/raw/v2.0.0/docs/LUK...
fpgaminer 9y ago
I'm surprised to see so many comments here throwing up on the use of JSON. Have we really forgotten the Unix philosophy? > Write programs to handle text streams, because that is a universal interface. A lot of the data formats I've written recently have used JSON. Partly because of that aforementioned principal, but mostly because it's just easier and there are very little downsides. Almost every language has support for it so it's fairly universal, it's self documenting, it's easy to debug, easy to manipulate by hand, and easy to maintain. Put more simply: I've implemented several data formats using custom binary and several data formats using JSON. JSON was easier and faster every single time. My recommendation for data formats: just use JSON; unless you have a really good reason not to. And I do mean really good reason. For example, many might think concerns about data size would be a reason not to use JSON. But go ahead and run some JSON through a compression algorithm some time. You'll be amazed. Compressed JSON is very competitive versus a custom binary format.
- codys 9y ago
  > several data formats using custom binary and several data formats using JSON You may not realize it, but you've presented a false dichotomy here. The alternate to JSON isn't "custom binary", it's standardized binary encodings that allow the same flexibility (or additional flexibility) compared to JSON. Some examples include cbor & msgpack. >> Write programs to handle text streams, because that is a universal interface. cryptsetup manipulates block devices. I don't think that line can or should really be applied to something that is fairly similar to a filesystem's on-disk format.

100 points by tyngde 9y ago

wonderous 9y ago

Anyone aware of any independent formal security audits of this version of this or any prior version of LUKS?

raverbashing 9y ago

As noted on the release notes, do not use this for production systems (for now) unless you have a backup of your data

2bluesc 9y ago

Section regarding the format: LUKS2 format and features ~~~~~~~~~~~~~~~~~~~~~~~~~ The LUKS2 is an on-disk storage format designed to provide simple key management, primarily intended for Full Disk Encryption based on dm-crypt. The LUKS2 is inspired by LUKS1 format and in some specific situations (most of the default configurations) can be converted in-place from LUKS1. The LUKS2 format is designed to allow future updates of various parts without the need to modify binary structures and internally uses JSON text format for metadata. Compilation now requires the json-c library that is used for JSON data processing. On-disk format provides redundancy of metadata, detection of metadata corruption and automatic repair from metadata copy. NOTE: For security reasons, there is no redundancy in keyslots binary data (encrypted keys) but the format allows adding such a feature in future. NOTE: to operate correctly, LUKS2 requires locking of metadata. Locking is performed by using flock() system call for images in file and for block device by using a specific lock file in /run/lock/cryptsetup. This directory must be created by distribution (do not rely on internal fallback). For systemd-based distribution, you can simply install scripts/cryptsetup.conf into tmpfiles.d directory. For more details see LUKS2-format.txt and LUKS2-locking.txt in the docs directory. (Please note this is just overview, there will be more formal documentation later.)

deleted 9y ago
[deleted]
codys 9y ago
> JSON text format for metadata It seems like it could be better to use some easier to parse binary format that allows the same flexibility that json does, like cbor/msgpack/bson. Using JSON here is a very strange choice.
- cesarb 9y ago
  At least it's not XML.
- loeg 9y ago
  > Using JSON here is a very strange choice. I agree! Perhaps the userspace administrative tool (which links json-c) parses it and converts it to something more like an ioctl struct for the kernel.
  - majewsky 9y ago
    AFAIK the kernel only contains dm-crypt. The whole key handling takes place in userspace, in cryptsetup(1). (If you want to have a bad day, you can send a patch to Linus to put a JSON parser in the kernel.)
- Crontab 9y ago
  To me, the worst part is that it introduces a library dependency, which itself can introduce security issues unless they intend to audit it. I don't under this choice at all.
- klodolph 9y ago
  BSON, despite its name, is really just a format for MongoDB rather than a binary alternative for JSON.
  - deleted 9y ago
    [deleted]

deleted 9y ago

[deleted]

sprash 9y ago

Doesn't solve my most important problem with LUKS: Allowing Trim passthrough on SSDs without impacting vulnerability. Also, why use json for meta-data instead of simple C Structs? No human is supposed to read this kind of data anyways.

simcop2387 9y ago
Likely for easier future extensions to the metadata without requiring prior agreement among all implementations about how things are laid out.
bmalehorn 9y ago
> Alowing Trim passthrough on SSDs without impacting vulnerability. Unfortunately I don’t think that’s possible. If I scan your encrypted disk and see that 10% of blocks are zeroed out, I can assume that your disk is 90% full. So information has been leaked, which is arguably a vulnerability.
- saghm 9y ago
  Couldn't this be an opt-in feature? For some people, this might be a reasonable trade-off given their threat model
  - Denvercoder9 9y ago
    Yes, it can be, and it's already present.
    - saghm 9y ago
      Oops, probably should have checked before asking
  - kakarot 9y ago
    Fedora decided with release 27 to enable trim by default on newly created encrypted devices. I was not happy about this decision and try to make some noise but nobody really seem to care. There is a reason that it is disabled by default in the Linux kernel, and making this kind of decision on behalf of the users without any input from the community is pretty fucked up. Personally, I would like to explore the idea of a secure enclave that keeps a map of which blocks are in use that gets referred to during write operations. This seems like a problem that is going to need to be solved with hardware.

jwilk 9y ago

LUKS2 on-disk format specification: https://gitlab.com/cryptsetup/cryptsetup/raw/v2.0.0/docs/LUKS2-format.txt https://gitlab.com/cryptsetup/cryptsetup/raw/v2.0.0/docs/LUK...

fpgaminer 9y ago

I'm surprised to see so many comments here throwing up on the use of JSON. Have we really forgotten the Unix philosophy? > Write programs to handle text streams, because that is a universal interface. A lot of the data formats I've written recently have used JSON. Partly because of that aforementioned principal, but mostly because it's just easier and there are very little downsides. Almost every language has support for it so it's fairly universal, it's self documenting, it's easy to debug, easy to manipulate by hand, and easy to maintain. Put more simply: I've implemented several data formats using custom binary and several data formats using JSON. JSON was easier and faster every single time. My recommendation for data formats: just use JSON; unless you have a really good reason not to. And I do mean really good reason. For example, many might think concerns about data size would be a reason not to use JSON. But go ahead and run some JSON through a compression algorithm some time. You'll be amazed. Compressed JSON is very competitive versus a custom binary format.

codys 9y ago
> several data formats using custom binary and several data formats using JSON You may not realize it, but you've presented a false dichotomy here. The alternate to JSON isn't "custom binary", it's standardized binary encodings that allow the same flexibility (or additional flexibility) compared to JSON. Some examples include cbor & msgpack. >> Write programs to handle text streams, because that is a universal interface. cryptsetup manipulates block devices. I don't think that line can or should really be applied to something that is fairly similar to a filesystem's on-disk format.