[File] [PATCH] of Magdir/luks,linux for LUKS encrypted file; duplicates + version 2 wrong
Christos Zoulas
christos at zoulas.com
Wed Sep 7 11:23:57 UTC 2022
Committed, thanks!
christos
> On Sep 5, 2022, at 3:15 PM, Jörg Jenderek <joerg.jen.der.ek at gmx.net> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello,
>
> some days ago i installed a new Linux system on my PC.
> For security reasons i tried variants with encrypted partitions.
>
> When running file command (version 5.42) on such encrypted partitions
> and related images (taken from cryptsetup sources) with -k option i
> get an output like:
>
> compatimage.img: LUKS encrypted file, ver 1
> [aes, cbc-essiv:sha256, sha256] UUID:
> 28632274-8c8a-493f-835b-da802e1c576b
> LUKS encrypted file, ver 1
> [aes, cbc-essiv:sha256, sha256] UUID:
> 28632274-8c8a-493f-835b-da802e1c576b
> compatimage2.img: LUKS encrypted file, ver 2
> [, , sha256] UUID:
> 28632274-8c8a-493f-835b-da802e1c576b
> LUKS encrypted file, ver 2
> [, , sha256] UUID:
> 28632274-8c8a-493f-835b-da802e1c576b
> compatv10image.img: LUKS encrypted file, ver 1
> [aes, cbc-plain, sha1] UUID:
> e0d6124b-f9b7-4592-8c27-5adaddb7f1a4
> LUKS encrypted file, ver 1
> [aes, cbc-plain, sha1] UUID:
> e0d6124b-f9b7-4592-8c27-5adaddb7f1a4
> luks2_keyslot_unassigned.img: LUKS encrypted file, ver 2
> [, , sha256] UUID:
> 7c8493c0-4f6e-40ab-848e-f96b3b995a66
> LUKS encrypted file, ver 2
> [, , sha256] UUID:
> 7c8493c0-4f6e-40ab-848e-f96b3b995a66
> luks2_valid_hdr.img: LUKS encrypted file, ver 2
> [, , sha256] UUID:
> 12a3a118-7039-4575-a649-3f559d8d87ee
> LUKS encrypted file, ver 2
> [, , sha256] UUID:
> 12a3a118-7039-4575-a649-3f559d8d87ee
> sda3-kingston240.luks: LUKS encrypted file, ver 1
> [aes, xts-plain64, sha256] UUID:
> 95abe2fe-953f-487e-9aa4-882993350a36
> LUKS encrypted file, ver 1
> [aes, xts-plain64, sha256] UUID:
> 95abe2fe-953f-487e-9aa4-882993350a36
> sda3.luksVolumeHeaderBackUp: LUKS encrypted file, ver 2
> [, PI4, sha256] UUID:
> 242256c6-396e-4a35-af5f-5b70cb7af9a7
> LUKS encrypted file, ver 2
> [, PI4, sha256] UUID:
> 242256c6-396e-4a35-af5f-5b70cb7af9a7
>
> With --extension option only ??? is displayed. Furthermore with -i
> option for my samples only generic application/octet-stream is shown.
>
> For comparison reason i run the file format identification utility
> TrID ( See https://mark0.net/soft-trid-e.html). The version 2
> variants ( like compatimage2.img luks2_keyslot_unassigned.img
> luks2_valid_hdr.img) are described as "LUKS2 encrypted" by
> luks2.trid.xml. All examples are described with lower rate as
> "LUKS encrypted" by luks.trid.xml (See appended trid-v-luks.txt.gz).
> With -v option display reference URL.
>
> I get duplicated messages because Magdir/linux and Magdir/luks
> contain the same magic lines starting with line like:
> 0 string LUKS\xba\xbe LUKS encrypted file,
>
> So first i delete inside Magdir/linux the corresponding lines to
> remove duplicates message texts.
>
> The mentioned URL with web page luks.endorphin.org inside Magdir/luks
> does not exist any more. So with the help of TrID i replace it by
> comment lines like:
>
> # URL: https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup
> # http://fileformats.archiveteam.org/wiki/LUKS
> # Reference: https://mirrors.edge.kernel.org/pub/linux/utils/
> # cryptsetup/LUKS_docs/on-disk-format.pdf
> # https://gitlab.com/cryptsetup/LUKS2-docs/-/raw/master
> # luks2_doc_wip.pdf
> # http://mark0.net/download/triddefs_xml.7z
> # defs/l/luks.trid.xml
> # defs/l/luks2.trid.xml
>
> The information for version one ( shown by phrase ", ver 1") are
> correct, whereas for version two ( shown by phrase ", ver 2") the
> additional informations are garbage. This can be verified by
> running a command like:
> cryptsetup luksDump /dev/sda3
>
> Now inside Magdir/luks the description start with lines like:
> 0 string LUKS\xba\xbe LUKS encrypted file,
> !:mime application/x-raw-disk-image
> !:ext /luks/img/luksVolumeHeaderBackUp
>> 6 beshort x ver %d
>
> I myself would prefer a user defined mime type like
> application/x-luks-volume but according to FreeDesktop.org shared
> MIME database for LUKS encrypted there exist already one. That
> information can be found for example on web site reposcope.com. The
> file name extension is there listed but not exactly explained. The
> obviously "natural" file name suffix is luks for such encrypted
> files. These files are often handled by image writer or mounters like
> gnome-disk. Such utility can also handle other disk images. So
> apparently these use as generic suffix for disc image 3 byte suffix
> img. When handling partitions like /dev/sda3 then of course we have
> no file name extension. The header of such encrypted files can be
> saved for backup reasons separately. These headers of course look at
> first glance like the whole file or partition. This work for example
> can be done by tool like zuluCrypt. This use an own file name suffix
> for that reason. That is luksVolumeHeaderBackUp.
>
> The next lines showing cipher-name (like: aes twofish),
> cipher-mode (like: xts-plain64 cbc-essiv), hash type ( like: sha256
> sha1 ripemd160) and UID are only correct for version 1:
>> 8 string x [%s,
>> 40 string x %s,
>> 72 string x %s]
>> 168 string x UUID: %s
> So i put these lines in sub routine luks-v1 and test for version 1 or
> 2 and call correct sub routine. This is be done by inserted lines lik
> e:
>> 6 beshort 1
>>> 0 use luks-v1
>> 6 beshort >1
>>> 0 use luks-v2
> 0 name luks-v1
>
> According to cryptsetup output and the mentioned PDF documents i
> show in that sub routine more information ( like payload-offset, MK
> key-bytes, mk-digest, salt parameter and iterations parameter) by
> additional lines like:
>> 104 ubelong x \b, at %#x data
>> 108 ubelong x \b, %u key bytes
>> 112 ubequad x \b, MK digest %#16.16llx
>>> 120 ubequad x \b%16.16llx
>>> 128 ubelong x \b%8.8x
>> 132 ubequad x \b, MK salt %#16.16llx
>>> 140 ubequad x \b%16.16llx
>>> 148 ubequad x \b%16.16llx
>>> 156 ubequad x \b%16.16llx
>> 164 ubelong x \b, %u MK iterations
>
> You can use up to 8 different keys to decrypt such LUKS files. This
> information is stored in a key slot. So i display information (like
> in-active status, material offset, number of anti-forensic stripes)
> about LUKS slot by sub routine with lines like:
> 0 name luks-slot
>> 0 ubelong =0x00AC71F3 activ 0 ubelong =0x0000DEAD inactiv
> # iteration parameter for PBKDF2
> #>4 ubelong x \b, %u iterations
> # salt parameter for PBKDF2
> #>8 ubequad x \b, salt %#16.16llx
> #>16 ubequad x \b%16.16llx
> #>24 ubequad x \b%16.16llx
> #>32 ubequad x \b%16.16llx
>> 40 ubelong x \b, %#x material offset 44 ubelong !4000 \b, %u
>> stripes
>
> So show inside sub routine information about active key slots
> (maximal eight) by lines like:
>> 208 ubelong =0x00AC71F3 \b; slot #1
>>> 208 use luks-slot
>> 256 ubelong =0x00AC71F3 \b; slot #2
>>> 256 use luks-slot
> ...
>> 544 ubelong =0x00AC71F3 \b; slot #8
>>> 544 use luks-slot
>
> For LUKS version 2 the header format is quite different from version
> one. Part of the information is stored in text form as JSON at offset
> 0x1000. This informations (like label, sub label,UIID, JSON text) is
> displayed by second sub routine, which looks like:
> 0 name luks-v2
>> 8 ubequad x \b, header size %llu
>> 16 ubequad x \b, ID %llu
>> 24 string >\0 \b, label %s
>> 72 string x \b, algo %s
>> 104 ubequad x \b, salt %#llx...
>> 168 string x \b, UUID: %-.40s
>> 208 string >\0 \b, sub label %-.48s
>> 256 ubequad !0 \b, offset %llx
>> 448 ubequad x \b, crc %#llx...
>> 0x1000 string x \b, at 0x1000 %s
>
> After applying the above mentioned modifications by patches
> file-5.42-linux-luks.diff and file-5.42-luks-img.diff
> then duplicated messages vanish and version 2 variants are now
> described correctly like:
>
> compatimage.img: LUKS encrypted file, ver 1
> [aes, cbc-essiv:sha256, sha256] UUID:
> 28632274-8c8a-493f-835b-da802e1c576b
> , at 0x408 data, 16 key bytes
> , MK digest
> 0x81344f00b1b5bc7f296
> 3401e92ef373d869b1a8f
> , MK salt
> 0xf71b26130622d934f79823771f354b6
> 04b5d1d6e089fd01cc4a9f5584e9f526f
> , 1000 MK iterations
> ; slot #0 active, 0x8 material offset
> compatimage2.img: LUKS encrypted file, ver 2
> , header size 16384, ID 4, algo sha256
> , salt 0x62fea1336a455f46..., UUID:
> 28632274-8c8a-493f-835b-da802e1c576b,
> crc 0x66390aa542676a25..., at 0x1000
> {"keyslots":{"0":{"type":"luks2"
> compatv10image.img: LUKS encrypted file, ver 1
> [aes, cbc-plain, sha1] UUID:
> e0d6124b-f9b7-4592-8c27-5adaddb7f1a4
> , at 0x3f2 data, 16 key bytes
> , MK digest
> 0x5b4fd481c1dc0f3c275c
> 116e48bd2b6f6b55fff9
> , MK salt
> 0x32f93e8c57963010afebc8bd3eaa1d9
> 9fc34db83a46193d8bb98fa9fc5ce9600
> , 10 MK iterations
> ; slot #0 active, 0x2 material offset
> luks2_keyslot_unassigned.img: LUKS encrypted file, ver 2
> , header size 16384, ID 8, algo sha256
> , salt 0xc838d9771c1bde34..., UUID:
> 7c8493c0-4f6e-40ab-848e-f96b3b995a66,
> crc 0x8ba6e895289cb92c..., at 0x1000
> {"keyslots":{"0":{"type":"luks2",
> luks2_valid_hdr.img: LUKS encrypted file, ver 2
> , header size 16384, ID 10, algo sha256
> , salt 0x3904096481765b4..., UUID:
> 12a3a118-7039-4575-a649-3f559d8d87ee,
> crc 0xc474c736ae9ef3fa..., at 0x1000
> {"keyslots":{"0":{"type":"luks2",
> sda3-kingston240.luks: LUKS encrypted file, ver 1
> [aes, xts-plain64, sha256] UUID:
> 95abe2fe-953f-487e-9aa4-882993350a36
> , at 0x1000 data, 64 key bytes
> , MK digest
> 0xafa27b048a3d51528f5f
> 91aa23a4e8f006ba64a5
> , MK salt
> 0x3d2e514c4dc98c64bb5b05d37807ca4b
> be907e6a9d236043214f7f7b8f90ddfc
> , 35656 MK iterations
> ; slot #0 active, 0x8 material offset
> sda3.luksVolumeHeaderBackUp: LUKS encrypted file, ver 2
> , header size 16384, ID 9
> , label LUKS2_EXT4_ROOT_PI4
> , algo sha256
> , salt 0x14a40dac2737a873..., UUID:
> 242256c6-396e-4a35-af5f-5b70cb7af9a7
> , sub label MY_SUBSYSTEM,
> crc 0x44af19d85fa620ac..., at 0x1000
> {"keyslots":{"0":{"type":"luks2",
>
> I hope my diff files can be applied in future version of file utility
> .
>
> With best wishes
> Jörg Jenderek
> - --
> Jörg Jenderek
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iF0EARECAB0WIQS5/qNWKD4ASGOJGL+v8rHJQhrU1gUCYxZK1wAKCRCv8rHJQhrU
> 1oN+AKCdueT/0zDQvcmBGemKAXtnheQ9tgCeIe/S6szqOK6XdTc+1BgVHlwYUCw=
> =Y/3N
> -----END PGP SIGNATURE-----
> <file-5_42-linux-luks_diff.DEFANGED-52038><file-5_42-linux-luks_diff_sig.DEFANGED-52039><trid-v-luks.txt.gz><file-5_42-luks-img_diff.DEFANGED-52040><file-5_42-luks-img_diff_sig.DEFANGED-52041>--
> File mailing list
> File at astron.com
> https://mailman.astron.com/mailman/listinfo/file
> <sanitizer.log>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP
URL: <https://mailman.astron.com/pipermail/file/attachments/20220907/edc8e50e/attachment-0001.asc>
More information about the File
mailing list