ウェブサイト検索

切り離されたヘッダーを使用してLUKSを使う方法

Linux Unified Key Setup (LUKS) は、Linux ベースのシステムで使用される事実上の標準ブロックデバイス暗号化フォーマットです。以前のチュートリアルで LUKS デバイスキーとしてファイルを使用するためのいくつかの機能について議論しました。LUKS を使用する際、暗号化メタデータは暗号化デバイスの最初に作成されたヘッダーに保存されます（LUKS2 を使用する際は冗長性のためにデバイスの最後にもヘッダーのコピーが作成されます）。必要に応じて、ヘッダーをデバイスから切り離すように指定することも可能です。このチュートリアルでは、その方法を説明します。

このチュートリアルでは、次のことを学びます。

  • LUKSヘッダーとは何ですか？また、その中にどのような情報が保存されていますか？
  • LUKSヘッダーのバックアップを作成および復元する方法
  • 切り離されたヘッダーを使用してLUKSを使う方法

使用されるソフトウェア要件と規約

LUKSヘッダーとは何ですか？

すでに述べたように、LUKS形式で暗号化されるブロックデバイスを設定する際、メタデータを含むヘッダーが、デフォルトで暗号化されたパーティションまたは生のブロックデバイスの先頭に保存されます。LUKSヘッダーにはどのような情報が保存されているのでしょうか？その内容を調べるのは非常に簡単です。暗号化されたブロックデバイスが/dev/sdbであると仮定すると、LUKSヘッダーに関する情報を得るために、次のコマンドを実行します:

sudo cryptsetup luksDump /dev/sdb

こちらが私たちが得る出力の例です。

LUKS header information for /dev/sdb

Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha512
Payload offset: 4096
MK bits:        512
MK digest:      a5 2b 28 28 65 1b 72 47 b6 5e 13 03 53 d1 21 58 16 16 01 0e
MK salt:        2d 69 3a 58 a0 05 43 d4 c6 b3 12 fb 93 21 a1 0a
                3d 35 78 59 a6 48 48 e3 8c 8c 4a 27 93 ec a1 d6
MK iterations:  63750
UUID:           ecbc1d41-d1b6-4fc1-b2f0-7688c93cdc45

Key Slot 0: ENABLED
        Iterations:             2582695
        Salt:                   ab f9 18 8b 35 f9 f0 d6 fe a2 82 0a 08 1d 18 d9
                                b4 de 02 d8 71 8a a6 00 54 04 65 c5 75 66 91 8b
        Key material offset:    8
        AF stripes:             4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

コマンドの出力を見てみると、使用中のLUKSバージョン（この場合は1、ただし最新のバージョンは2）、暗号名とモード、パスワードソルトのために使用されるハッシュアルゴリズム、マスターキービット、ダイジェスト、ソルトとハッシュの反復回数、そしてデバイスのUUIDなど、いくつかの重要な情報が表示されていることがわかります。また、利用可能な7つのパスワードスロットのうち、最初の1つだけが使用されていることもわかります。

LUKSヘッダーはセットアップの重要な部分です。何らかの理由でそれが損傷した場合、ディスク上のすべてのデータは修復不可能に失われます。だからこそ、常にそれをバックアップすることは良いアイデアです。では、どうすればよいか見てみましょう。

LUKSヘッダーのバックアップを作成および復元する

LUKSヘッダーのバックアップを作成するのは非常に簡単な作業です。cryptsetupユーティリティを使用し、luksHeaderBackupコマンドを使用して行います。/dev/sdbデバイスのLUKSヘッダーのバックアップを作成するには、次のように実行します:

sudo cryptsetup luksHeaderBackup /dev/sdb --header-backup-file sdbheaderbackup.img

上記で行ったことを見てみましょう。私たちは、sudoを使用して取得したルート特権でcryptsetupを呼び出しました。前述の通り、バックアップを作成するために、luksHeaderBackupコマンドを使用し、LUKSフォーマットされたデバイスのパスを引数として渡しました。その後、--header-backup-fileオプションを使用して、ヘッダーをどこに保存するかを指定しました：この場合、sdbheaderbackup.imgファイルです。

作成したバックアップをブロックデバイスに復元するのも同様に簡単です。変更する必要があるのはコマンドだけです。luksHeaderBackupの代わりにluksHeaderRestoreを使用します。以下は、ヘッダーバックアップをブロックデバイスに復元するために実行するコマンドです:

sudo cryptsetup luksHeaderRestore /dev/sdb --header-backup-file sdbheaderbackup.img

LUKSヘッダーのバックアップを作成する際に考慮すべき可能なセキュリティ問題の1つは、バックアップを復元することによって、元々スロットに存在していたパスワードを使用してブロックデバイスをアンロックできる可能性があることです。バックアップが完了した後、そのパスワードを変更またはディスクから削除することを決定するかもしれません。

切り離されたLUKSヘッダーを使用する

私たちが見たように、デフォルトではLUKSヘッダーは暗号化されたブロックデバイスの最初に作成されます。しかし、LUKSでデバイスのフォーマットをする際に、別に保存された分離されたヘッダーを作成することを選択できます。なぜそれを行いたいのでしょうか？考えられる理由の1つは、信頼性のある否認を達成するためです：ブロックデバイスが暗号化されているという証拠がないため（メタデータが保存されていない）、それが暗号化されていないと主張することができます。たとえディスクがランダムなデータで埋め尽くされているように見え、暗号化が使用されていることを示唆したとしても、それが証明されることはありません。

LUKSでデバイスをフォーマットする際にデタッチドヘッダーを作成するには、--headerオプションを使い、ヘッダーを保存すべきファイルまたはデバイスのパスを指定するだけです。以下に例を示します:

sudo cryptsetup luksFormat /dev/sdb --header luksheader.img

想像できるように、--headerオプションは、デバイスのロックを解除しようとするたび、またはパスワードの追加、削除、変更など、デバイスを変更する他の操作を行う必要があるときに使用されます。また、luksDumpを使用してその内容を読むときにも使用します。たとえば、切り離されたヘッダーを持つLUKSデバイスのロックを解除するには、次のように実行します:

sudo cryptsetup luksOpen /dev/sdb sdb-crypt --header=luksheader.img

切り離されたLUKSヘッダーによるフルディスク暗号化

デタッチされたLUKSヘッダーのセットアップは、システムの重要な部分ではない生のブロックデバイスやパーティションを暗号化する場合に簡単に取得できます。しかし、デタッチされたヘッダーを用いてLVM上のLUKSの完全なディスク暗号化セットアップをどのように実現すればいいのでしょうか？

そのような設定では、暗号化されていない唯一のパーティションは、/boot パーティションにマウントされたものであり、そこには grub ファイル、Linux カーネルイメージ、および関連する initramfs アーカイブが含まれています。このパーティションは、追加のセキュリティのために通常は別の USB デバイス上に作成されます。システムの他の部分は、LVM 論理ボリュームとして単一の LUKS 暗号化デバイス内に作成されます。これは、パーティションを個別に暗号化することなく、複数のパーティションを持つために行われます。

このような設定で使用されるLUKSデバイスのために分離されたヘッダーを使用したい場合、システムのcrypttabでデバイスの扱いを変更する必要があります。以下のエントリを持っているとします:

sdb_crypt /dev/sdb none luks

私たちが知っているように、crypttabファイルの最初の列にはデバイスマッパー名が、2つ目には暗号化されたデバイスのパスが、3つ目にはデバイスキーとして使用される最終的なファイルのパス（この場合はnone）が、4つ目にはデバイスに使用するオプションのカンマ区切りリストがあります。この場合、luksオプションのみが使用され、LUKSモードを明示的に指定するために使用されます（通常のdm-cryptに対して）。

私たちがする必要があるのは、行を修正してheaderオプションを追加し、luksヘッダーがどこに格納されているかを指定することです。ヘッダーは次のように保存することができます:

  1. 分離された生のデバイス上で
  2. 分離されたファイルシステム上で

最初のシナリオでは、例えば、/dev/sdb LUKSデバイスのヘッダーが生の/dev/sdc（--header=/dev/sdc）ブロックデバイスに保存されています。このような場合、私たちがしなければならないことは、headerオプションの値として生デバイスのパスを渡すことだけです。上の行は次のようになります:

sdb_crypt /dev/sdb none luks,header=/dev/sdc

2番目のシナリオは、切り離されたヘッダーをファイルとしてファイルシステムに保存することを決定する場合に存在します。例えば、信頼性のある否認を達成するために、外部の取り外し可能なUSBデバイスに作成されたパーティションを/bootとして使用し、LUKSで暗号化されたメインブロックデバイスのヘッダーをそこに保存することができます。そのような場所を指定するために特定の表記を使用する必要があります。/bootにマウントされるパーティションが/dev/sdc1であると仮定すると、次のように書きます:

sdb_crypt /dev/sdb none luks,header=/path/to/header.img:/dev/sdc1

上記に使用されている表記は、ファイルシステム上のヘッダーファイルの絶対パスをファイルシステム識別子、例えばそのUUIDからコロン:で区切って指定することを含みます。

sdb_crypt /dev/sdb none luks,header=/path/to/header.img:UUID=<filesystem-uuid>

修正されたcrypttabファイル（/etc/crypttab）はルートファイルシステムの一部であり、暗号化されているため、ブート時に使用するためにinitramfsにコピーする必要があります。この操作を行う方法は、使用しているディストリビューションによって異なります。たとえば、Fedoraでは、initramfsを再生成するためにdracutを使用します:

sudo dracut --regenerate-all --force

結論

このチュートリアルでは、LUKSヘッダーの役割と、LUKSでブロックデバイスを暗号化する際にデタッチヘッダーを使用する方法について学びました。また、ヘッダーのバックアップを作成および復元する方法と、フルディスク暗号化の設定においてデタッチヘッダーを使用する方法についても見ました。

関連記事: