web-dev-qa-db-ja.com

LUKS暗号名「@」とは何ですか？

暗号化されたボリュームのLUKSヘッダーを分析すると、cipher-nameフィールドに単一文字= '@'が表示されます。どういう意味ですか？

LUKS On-Disk Format Specification は、2005年にClemens Fruhwirthによって最初に公開されたLUKSヘッダーのエンコーディングを明確に定義しており、最初の3つのデータフィールドは次のようになっています。

+-------+--------+-------------+
| Start | Length | Field Name  |
+-------+--------+-------------+
|     0 |      6 | magic       |
|     6 |      2 | version     |
|     8 |     32 | cipher-name |
+-------+--------+-------------+

古いドライブでは、これは期待どおりに機能し、cipher-nameが「aes」であることは明らかです

root@disp8551:~# hexdump -Cs 0 -n 6 luksVol1 
00000000  4c 55 4b 53 ba be                                 |LUKS..|
00000006
root@disp8551:~# hexdump -Cs 6 -n 2 luksVol1 
00000006  00 01                                             |..|
00000008
root@disp8551:~# hexdump -Cs 8 -n 32 luksVol1 
00000008  61 65 73 00 00 00 00 00  00 00 00 00 00 00 00 00  |aes.............|
00000018  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000028
root@disp8551:~#

しかし、新しいドライブでは、cipher-nameフィールドの印刷可能な文字は '@'のみです。

root@disp85:~# hexdump -Cs 0 -n 6 luksVol2
00000000  4c 55 4b 53 ba be                                 |LUKS..|
00000006
root@disp85:~# hexdump -Cs 6 -n 2 luksVol2
00000006  00 02                                             |..|
00000008
root@disp85:~# hexdump -Cs 8 -n 32 luksVol2
00000008  00 00 00 00 00 00 40 00  00 00 00 00 00 00 00 03  |......@.........|
00000018  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000028
root@disp85:~#

LUKSが@でここで使用している暗号は何ですか？ cipher-name fieldのアットマークはどういう意味ですか？

linuxdisk-encryptionencodingciphersluks
1
Michael Altfield

あなたの例のcipher-nameはnot '@'です。あなたが見ているフィールドは実際にはhdr_sizeフィールドです。

あなたが犯した間違いは、LUKS1エンコーディングでLUKS2コンテナをデコードしようとしたことです。提供されたテーブルでは、2番目のフィールド（バイト6〜8）がversionデータフィールドであることを示しています。そして、hexdumpは、最初のLUKSコンテナー（luksVol1）にversion = 00 01があり、2番目のLUKSコンテナー（luksVol2）にversion =があることを明確に示しています00 02。これらの16進値は、前者をLUKS1および後者のLUKS2に直接関連付けます。

これを示すOPからの引用：

root@disp8551:~# hexdump -Cs 6 -n 2 luksVol1 
00000006  00 01                                             |..|
00000008
...
root@disp85:~# hexdump -Cs 6 -n 2 luksVol2
00000006  00 02                                             |..|
00000008

OPのエンコードテーブルは、2005年にClemens Fruhwirthによって公開された LUKS On-Disk Format Specification で定義されているLUKS1に対してのみ正しいものでした。

LUKS2は、2018年にMilanBrožによって公開された LUKS2 On-Disk Format Specification で定義されている別のエンコードを使用します。LUKS2の更新されたエンコードテーブルを次に示します。 LUKS2のバイナリヘッダーは、正確に4096バイトでなければならないことに注意してください。

+-------+--------+--------------+
| Start | Length |  Field Name  |
+-------+--------+--------------+
|     0 |      6 | magic        |
|     6 |      2 | version      |
|     8 |      8 | hdr_size     |
|    16 |      8 | seqid        |
|    24 |     48 | label        |
|    72 |     32 | csum_alg     |
|   104 |     64 | salt         |
|   168 |     40 | uuid         |
|   208 |     48 | subsystem    |
|   256 |      8 | hdr_offset   |
|   264 |    184 | _padding     |
|   448 |     64 | csum         |
|   512 |   3584 | _padding4096 |
+-------+--------+--------------+

次に、LUKS2コンテナーのプライマリヘッダーの例で、上記のデータフィールドに関連する16進ダンプを示します。

# magic
root@disp4117:~# hexdump -Cs 0 -n 6 luksVol2
00000000  4c 55 4b 53 ba be                                 |LUKS..|
00000006

# version
root@disp4117:~# hexdump -Cs 6 -n 2 luksVol2
00000006  00 02                                             |..|
00000008

# hdr_size
root@disp4117:~# hexdump -Cs 8 -n 8 luksVol2
00000008  00 00 00 00 00 00 40 00                           |......@.|
00000010

# seqid
root@disp4117:~# hexdump -Cs 16 -n 8 luksVol2
00000010  00 00 00 00 00 00 00 03                           |........|
00000018

# label
root@disp4117:~# hexdump -Cs 24 -n 48 luksVol2
00000018  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000048

# csum_alg
root@disp4117:~# hexdump -Cs 72 -n 31 luksVol2
00000048  73 68 61 32 35 36 00 00  00 00 00 00 00 00 00 00  |sha256..........|
00000058  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00     |...............|
00000067

# salt
root@disp4117:~# hexdump -Cs 104 -n 64 luksVol2
00000068  4f b1 7c b2 bf 7d da 1f  15 64 df cc ab 74 68 5c  |O.|..}...d...th\|
00000078  9a f9 3d 02 42 67 0f 92  ee 1d bf 98 11 5b 3d b8  |..=.Bg.......[=.|
00000088  87 e4 e0 a8 76 23 68 86  2f fc e1 98 a7 a1 5a a9  |....v#h./.....Z.|
00000098  b6 c5 e5 e2 9a 87 f7 ff  55 52 dc 07 07 dd fa a4  |........UR......|
000000a8

# uuid
root@disp4117:~# hexdump -Cs 168 -n 40 luksVol2
000000a8  65 63 30 32 36 64 64 66  2d 37 37 36 32 2d 34 34  |ec026ddf-7762-44|
000000b8  64 63 2d 39 65 37 30 2d  62 35 36 66 36 61 65 62  |dc-9e70-b56f6aeb|
000000c8  63 31 32 38 00 00 00 00                           |c128....|
000000d0

# subsystem
root@disp4117:~# hexdump -Cs 208 -n 48 luksVol2
000000d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000100

# hdr_offset
root@disp4117:~# hexdump -Cs 256 -n 8 luksVol2
00000100  00 00 00 00 00 00 00 00                           |........|
00000108

# _padding
root@disp4117:~# hexdump -Cs 264 -n 184 luksVol2
00000108  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*

# csum
000001c0
root@disp4117:~# hexdump -Cs 448 -n 64 luksVol2
000001c0  d0 9a e0 f8 96 ed 8f db  42 5f 58 19 99 2a 72 18  |........B_X..*r.|
000001d0  01 5e f7 81 34 99 f7 c5  17 a2 07 2f 60 be 40 bd  |.^..4....../`.@.|
000001e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200

# _padding4096
root@disp4117:~# hexdump -Cs 512 -n 3584 luksVol2
00000200  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001000
root@disp4117:~#

上記のフィールドには実際にはcipher-nameが含まれていないことに注意してください。 LUKS2では、それはJSONオブジェクトに格納されます。 LUKS2には、実際には6つのヘッダー領域があります。

  \/ primary binary header          alignment padding \/
+----+----------+----+----------+-------------------+----+
| /\ | 1st JSON | \/ | 2nd JSON |   Keyslots area   | /\ |
+----+----------+----+----------+-------------------+----+
                  /\ secondary binary header

上記のhexdumpは、「プライマリバイナリヘッダー」領域のみを示しています。 cipher-nameを取得するには、JSON領域を調べる必要があります。

LUKS2では、「プライマリバイナリヘッダー」と「1番目のJSON」領域に格納されたデータのコピーが実際に2つあります（2番目のコピーは、それぞれ「セカンダリバイナリヘッダー」と「2番目のJSON」領域と呼ばれます）。ほとんどの場合、「プライマリバイナリヘッダー」のデータは「セカンダリバイナリヘッダー」と完全に一致し、「1番目のJSON」領域のデータは「2番目のJSON」領域と完全に一致します。 データは2回保存されます 回復を支援し、破損から保護します。

「1番目のJSON」領域は常にバイト4096（「プライマリバイナリヘッダー」領域の直後）から始まりますが、その長さは可変です。長さは、バイナリヘッダーのhdr_size（つまり、cipher-nameと混同していたのと同じフィールド）を調べることで決定できます。上記の16進ダンプから、hdr_sizeフィールドの値が0x4000（hex）= 16384（10進数）であることは明らかです。ただし、hdr_sizeフィールドは、「プライマリバイナリヘッダー」プラス「1番目のJSON」領域のサイズを定義します。したがって、「1番目のJSON」領域の長さは、hdr_size値から「プライマリバイナリヘッダー」の長さを引いたものになります。この場合、それは16384 - 4096 = 122881です。 JSONオブジェクトに格納されているLUKS2コンテナーのメタデータの長さに応じて、JSON領域は最大4194304 - 4096 = 4190208バイトになる場合があります。

そこで、「1st JSON」エリアのhexdumpは、バイトオフセット4096から始まり、長さ122881になります。

root@disp4117:~# hexdump -Cs 4096 -n 12288 luksVol2
00001000  7b 22 6b 65 79 73 6c 6f  74 73 22 3a 7b 22 30 22  |{"keyslots":{"0"|
00001010  3a 7b 22 74 79 70 65 22  3a 22 6c 75 6b 73 32 22  |:{"type":"luks2"|
00001020  2c 22 6b 65 79 5f 73 69  7a 65 22 3a 36 34 2c 22  |,"key_size":64,"|
00001030  61 66 22 3a 7b 22 74 79  70 65 22 3a 22 6c 75 6b  |af":{"type":"luk|
00001040  73 31 22 2c 22 73 74 72  69 70 65 73 22 3a 34 30  |s1","stripes":40|
00001050  30 30 2c 22 68 61 73 68  22 3a 22 73 68 61 32 35  |00,"hash":"sha25|
00001060  36 22 7d 2c 22 61 72 65  61 22 3a 7b 22 74 79 70  |6"},"area":{"typ|
00001070  65 22 3a 22 72 61 77 22  2c 22 6f 66 66 73 65 74  |e":"raw","offset|
00001080  22 3a 22 33 32 37 36 38  22 2c 22 73 69 7a 65 22  |":"32768","size"|
00001090  3a 22 32 35 38 30 34 38  22 2c 22 65 6e 63 72 79  |:"258048","encry|
000010a0  70 74 69 6f 6e 22 3a 22  61 65 73 2d 78 74 73 2d  |ption":"aes-xts-|
000010b0  70 6c 61 69 6e 36 34 22  2c 22 6b 65 79 5f 73 69  |plain64","key_si|
000010c0  7a 65 22 3a 36 34 7d 2c  22 6b 64 66 22 3a 7b 22  |ze":64},"kdf":{"|
000010d0  74 79 70 65 22 3a 22 61  72 67 6f 6e 32 69 22 2c  |type":"argon2i",|
000010e0  22 74 69 6d 65 22 3a 34  2c 22 6d 65 6d 6f 72 79  |"time":4,"memory|
000010f0  22 3a 32 37 34 35 33 30  2c 22 63 70 75 73 22 3a  |":274530,"cpus":|
00001100  32 2c 22 73 61 6c 74 22  3a 22 71 4a 6e 79 2b 4a  |2,"salt":"qJny+J|
00001110  5c 2f 6f 35 71 77 57 77  35 78 2b 57 31 30 7a 47  |\/o5qwWw5x+W10zG|
00001120  59 54 6f 64 44 64 57 6f  39 6e 74 5c 2f 6c 67 49  |YTodDdWo9nt\/lgI|
00001130  41 61 61 6f 78 5c 2f 45  3d 22 7d 7d 7d 2c 22 74  |Aaaox\/E="}}},"t|
00001140  6f 6b 65 6e 73 22 3a 7b  7d 2c 22 73 65 67 6d 65  |okens":{},"segme|
00001150  6e 74 73 22 3a 7b 22 30  22 3a 7b 22 74 79 70 65  |nts":{"0":{"type|
00001160  22 3a 22 63 72 79 70 74  22 2c 22 6f 66 66 73 65  |":"crypt","offse|
00001170  74 22 3a 22 31 36 37 37  37 32 31 36 22 2c 22 69  |t":"16777216","i|
00001180  76 5f 74 77 65 61 6b 22  3a 22 30 22 2c 22 73 69  |v_Tweak":"0","si|
00001190  7a 65 22 3a 22 64 79 6e  61 6d 69 63 22 2c 22 65  |ze":"dynamic","e|
000011a0  6e 63 72 79 70 74 69 6f  6e 22 3a 22 61 65 73 2d  |ncryption":"aes-|
000011b0  78 74 73 2d 70 6c 61 69  6e 36 34 22 2c 22 73 65  |xts-plain64","se|
000011c0  63 74 6f 72 5f 73 69 7a  65 22 3a 35 31 32 7d 7d  |ctor_size":512}}|
000011d0  2c 22 64 69 67 65 73 74  73 22 3a 7b 22 30 22 3a  |,"digests":{"0":|
000011e0  7b 22 74 79 70 65 22 3a  22 70 62 6b 64 66 32 22  |{"type":"pbkdf2"|
000011f0  2c 22 6b 65 79 73 6c 6f  74 73 22 3a 5b 22 30 22  |,"keyslots":["0"|
00001200  5d 2c 22 73 65 67 6d 65  6e 74 73 22 3a 5b 22 30  |],"segments":["0|
00001210  22 5d 2c 22 68 61 73 68  22 3a 22 73 68 61 32 35  |"],"hash":"sha25|
00001220  36 22 2c 22 69 74 65 72  61 74 69 6f 6e 73 22 3a  |6","iterations":|
00001230  36 31 39 34 33 2c 22 73  61 6c 74 22 3a 22 46 69  |61943,"salt":"Fi|
00001240  4c 67 31 35 56 5c 2f 55  56 4b 47 72 72 4e 39 4f  |Lg15V\/UVKGrrN9O|
00001250  52 2b 5c 2f 69 59 46 51  70 38 38 59 44 77 50 4c  |R+\/iYFQp88YDwPL|
00001260  6a 4f 6f 4c 70 6a 77 6d  78 58 77 3d 22 2c 22 64  |jOoLpjwmxXw=","d|
00001270  69 67 65 73 74 22 3a 22  49 70 34 31 5a 58 70 44  |igest":"Ip41ZXpD|
00001280  76 77 52 76 6d 41 73 33  30 58 69 72 6c 48 65 6d  |vwRvmAs30XirlHem|
00001290  57 72 44 67 6c 5c 2f 44  4a 31 36 79 33 31 41 71  |WrDgl\/DJ16y31Aq|
000012a0  66 42 55 6f 3d 22 7d 7d  2c 22 63 6f 6e 66 69 67  |fBUo="}},"config|
000012b0  22 3a 7b 22 6a 73 6f 6e  5f 73 69 7a 65 22 3a 22  |":{"json_size":"|
000012c0  31 32 32 38 38 22 2c 22  6b 65 79 73 6c 6f 74 73  |12288","keyslots|
000012d0  5f 73 69 7a 65 22 3a 22  31 36 37 34 34 34 34 38  |_size":"16744448|
000012e0  22 7d 7d 00 00 00 00 00  00 00 00 00 00 00 00 00  |"}}.............|
000012f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00004000
root@disp4117:~#

LUKSコンテナー内のdataの暗号化に固有のcipher-nameを取得するには（指定されたキースロットを対称的に暗号化するために使用される暗号とは対照的） ）、上記のJSONのsegmentsオブジェクトを確認する必要があります。上記と同じsegmentsセクションですが、読みやすいようにフォーマットされています：

  "segments": {
    "0": {
      "type": "crypt",
      "offset": "16777216",
      "iv_Tweak": "0",
      "size": "dynamic",
      "encryption": "aes-xts-plain64",
      "sector_size": 512
    }
  },

LUKSは多くの異なるセグメントをサポートしますが、このLUKSコンテナーには1つしかありません。必要な属性はencryptionで、これには dm-crypt表記 の値があります。この場合、それはaes-xts-plain64です。つまり、cipher-nameはaesであり、cipher-modeはxts-plain64です。

これは、LUKS2コンテナーのcryptsetup luksDumpにリストされている暗号にも一致します

root@disp4117:~# cryptsetup luksDump luksVol2 | grep -i cipher | head -n1
    cipher: aes-xts-plain64
root@disp4117:~#
4
Michael Altfield