ArchWiki - 利用者の投稿記録 [ja]

Man ページ

2025-03-15T16:40:33Z

Takemaro: 未訳の部分2箇所を翻訳

{{Lowercase title}}
[[Category:コマンドライン]]
[[ar:Man page]]
[[en:Man page]]
[[es:Man page]]
[[id:Man page]]
[[ko:Man page]]
[[pt:Man page]]
[[ru:Man page]]
[[zh-hans:Man page]]
{{Related articles start}}
{{Related|コンソールのカラー出力#man}}
{{Related articles end}}
'''man ページ''' ("マニュアルページ"の略) は Arch Linux を含む、ほとんどの主要な UNIX ライクなオペレーティングシステムで最初からインストールされているドキュメントです。man ページを表示するには {{Ic|man}} コマンドを使います。

man ページのカバーする範囲の如何を問わず、man ページは完結型のドキュメントとして作られており、必然的に、関連する話題を述べるときに他の man ページを参照するということが控えられています。このことはハイパーリンクを使用する info ファイルと対照的であり、GNU は info ファイルで伝統的な man ページ形式を置き換えようとしています。

== インストール ==

Arch Linux では、{{Pkg|man-db}} が ''man'' を実装しており、''man'' で使用されるデフォルトのページャは [[Core utilities#Essentials|less]] です。{{Pkg|mandoc}} も使用できます。

{{Pkg|man-pages}} は Linux と POSIX.1 の両方の man pages を提供します。([https://www.kernel.org/doc/man-pages/download.html] を参照)。

各種プロジェクトにより翻訳された man ページもあります:

* {{Pkg|man-pages-cs}} チェコ語
* {{Pkg|man-pages-de}} ドイツ語
* {{Pkg|man-pages-es}} スペイン語
* {{Pkg|man-pages-fr}} フランス語
* {{Pkg|man-pages-it}} イタリア語
* {{AUR|man-pages-ja}} 日本語
* {{Pkg|man-pages-nl}} オランダ語
* {{Pkg|man-pages-pl}} ポーランド語
* {{Pkg|man-pages-pt_br}} ブラジルポルトガル語
* {{Pkg|man-pages-ro}} ルーマニア語
* {{AUR|man-pages-ru}} ロシア語
* {{AUR|man-pages-tr}} トルコ語
* {{Pkg|man-pages-zh_cn}} 中国語簡体字
* {{Pkg|man-pages-zh_tw}} 中国語繁体字

いくつかのアプリケーションを使用して、マニュアルページを表示できます:

* {{App|GNOME Help|Help viewer for [[GNOME]]. It can show man pages via {{ic|yelp man:<name>}} or the undocumented {{ic|Ctrl+L}} keybinding from an existing window.|https://wiki.gnome.org/Apps/Yelp|{{Pkg|yelp}}}}
* {{App|KHelpCenter|Application to show [[KDE]] Applications' documentation. Man pages are in ''UNIX manual pages'' or by running {{ic|khelpcenter man:<name>}}.|https://userbase.kde.org/KHelpCenter|{{Pkg|khelpcenter}}}}
* {{App|[[Wikipedia:Konqueror|Konqueror]]|KDE file manager and web browser. It can show man pages via {{ic|man:<name>}}.|https://konqueror.org/|{{Pkg|konqueror}}}}
* {{App|xman|Provides a categorized look at man pages.|https://xorg.freedesktop.org/|{{pkg|xorg-xman}}}}

== Man ページの表示 ==
man ページを読むには、次を入力してください:

$ man ''page_name''

マニュアルは複数のセクションに分類されています:
# 一般的なコマンド
# システムコール (カーネルによって提供されている関数)
# ライブラリコール (C ライブラリの関数)
# 特殊ファイル (通常は {{ic|/dev}} 以下に存在します) とドライバー
# ファイルのフォーマットと規則
# ゲーム
# その他 (約束事など)
# システム管理コマンド (通常は root 権限を必要とします) とデーモン

基本的に Man ページはページの名前で呼ばれ、括弧で囲まれたセクション番号が後ろに付きます。{{man|1|man}} と {{man|7|man}} のように、同じ名前の man ページが存在することも時々あります。この場合は、man を呼び出すときにセクション番号と man ページの名前を指定します。例:

$ man 5 passwd

上記のコマンドを実行すると {{Ic|passwd}} ユーティリティではなく、{{Ic|/etc/passwd}} についての man ページが表示されます。

または、ページ名の後にピリオドで区切ってセクション番号を付けても同じことができます:

$ man passwd.5

== マニュアルの検索 ==
{{Ic|man}} ユーティリティを使えば man ページを表示することはできますが、そもそも読みたいマニュアルページの名前を知らない場合に問題が起こります。幸いに、{{Ic|-k}} または {{Ic|--apropos}} オプションを使うことで、キーワードを指定してマニュアルページの説明文を検索することができます。

検索機能は専用のキャッシュを使っています。デフォルトでは、キャッシュが作成されていないために、何を検索しても''該当するページは見つからない''という結果になってしまいます。次を実行することでキャッシュを生成または更新することが可能です:
# mandb
新しい man ページをインストールしたら上のコマンドを実行するようにしてください。

キャッシュを作成したら検索をすることができます。例えば、"password" に関する man ページを検索するには:

$ man -k password

または:

$ man --apropos password

上記のコマンドは以下のように {{Ic|apropos}} コマンドを実行するのと同じです:

$ apropos password

デフォルトでは、指定したキーワードは正規表現として解釈されます。

ページ全体でキーワードが検索されるように細かく検索して欲しい場合、{{ic|-K}} オプションを使います:
$ man -K password

== ページ幅 ==
man ページの幅は {{Ic|MANWIDTH}} 環境変数で制御できます。

ターミナルのカラム数が小さすぎる場合 (例: ウィンドウの幅が小さい場合)、間違ったところで改行されることがあります。{{Ic|man}} を実行するときに MANWIDTH を設定することで読みやすくすることが可能です:

{{Hc|~/.bashrc|<nowiki>
man() {
local width=$(tput cols)
[ $width -gt $MANWIDTH ] && width=$MANWIDTH
env MANWIDTH=$width \
man "$@"
}
</nowiki>}}

== ローカルの man ページを読む ==

標準のインターフェイスの代わりに、{{Pkg|lynx}} や [[Firefox]] などのブラウザを使って man ページを見ることで info ページの利点 (ハイパーリンク) を得ることができます。代替手段としては、以下のようなものがあります。

=== ブラウザで表示できる HTML に変換する ===
==== mandoc ====
{{Pkg|mandoc}} パッケージをインストールしてください。例えば {{ic|free(1)}} のページを変換するなら:
$ gunzip -c /usr/share/man/man1/free.1.gz | mandoc -Thtml -Ostyle=style.css 1> free.html

{{ic|free.html}} ファイルをお好きなブラウザで開いて下さい。

==== man2html ====
まず、[[公式リポジトリ]]から {{Pkg|man2html}} をインストールします。

そして、man ページを変換:
$ man free | man2html -compress -cgiurl man$section/$title.$section$subsection.html > ~/man/free.html

他の使い方として印刷しやすいように {{Ic|man2html}} でプレーンテキストにすることもできます:
$ man free | man2html -bare > ~/free.txt

==== man -H ====
Arch のリポジトリに入っている man の GNU 実装には HTML で表示する機能が付いています:
$ man -H free

使用されるブラウザは {{ic|BROWSER}} [[環境変数]]によって決まります。{{ic|-H}} オプションにバイナリを渡すことで上書きできます。

==== roffit ====
[[AUR]] から {{AUR|roffit}} をインストールしてください。

man ページを変換するには:

$ gunzip -c /usr/share/man/man1/free.1.gz | roffit > free.html

=== PDF に変換する ===
man ページは基本的に印刷ができるようになっています。man ページは troff で書かれており、troff はもともと組版言語だからです。{{Pkg|ghostscript}} をインストールしていれば、man ページを PDF に変換するのはとても簡単に行えます: {{ic|<nowiki>man -t <manpage> | ps2pdf - <pdf></nowiki>}}。どんな風になるかは [https://www.google.com/search?q=manpage+pdf+troff&num=100&hl=en&prmd=imvns&source=lnms&tbm=isch&sa=X&ei=5BZpUI3oH6rI2AXvx4CoAw&ved=0CAoQ_AUoAQ&biw=1321&bih=1100 google で画像検索] してみればわかります。これは万人向けとは言えないでしょう。

{{Note|基本的にフォントは決まったサイズの Times に制限されています。ハイパーリンクは存在しません。man ページによってはターミナルでの表示に特化されていることがあり、PS や PDF のような形だと上手くいかないことがあります。}}

== オンラインの Man ページ ==
man ページのオンラインデータベース:
* [https://jlk.fjfi.cvut.cz/arch/manpages/ Arch Linux の man ページ] ([https://man.kusakata.com 日本語訳]) ArchWiki の[[テンプレート:Man|man ページ]] のリンク先です。
* [http://man7.org/linux/man-pages/index.html man7.org] - Arch Linux の {{pkg|man-pages}} で使われています。
* [https://manned.org/ manned.org の様々な Linux ディストリビューションや BSD などのマニュアルページ集]
* [https://linux.die.net/man/ linux.die.net]
* [https://man.cx/ man.cx]
* [https://manpages.debian.org/ Debian GNU/Linux の man ページ]
* [https://manpages.ubuntu.com/ Ubuntu の manpage リポジトリ]
* [https://leaf.dragonflybsd.org/cgi/web-man DragonFlyBSD マニュアルページ]
* [https://www.freebsd.org/cgi/man.cgi FreeBSD の man ページ]
* [http://netbsd.gw.com/cgi-bin/man-cgi NetBSD マニュアルページ]
* [https://www.openbsd.org/cgi-bin/man.cgi OpenBSD マニュアルページ]
* [http://man.cat-v.org/plan_9/ Plan 9 マニュアル — Volume 1]
* [http://man.cat-v.org/inferno/ Inferno マニュアル — Volume 1]
* [https://www.unix.com/man-page/OpenSolaris/1/man/ UNIX と Linux フォーラムの man ページリポジトリ]

{{pkg|man-pages}} は POSIX.1 の man pages を提供していますが([https://www.kernel.org/doc/man-pages/download.html] を参照)、公式のオンラインリファレンスも存在することに注意してください。

* [https://pubs.opengroup.org/onlinepubs/9699919799/ POSIX.1-2017]

[https://gist.github.com/rixx/6cb5fa38f694009ad0bd50c275bb61f2 オンライン man ページの比較表]もあります。

{{Warning|ディストリビューションによっては、Arch が使っているのとは異なる man ページを使用していることがあります (パッチを適用していたり単純に古くなっているなど)。オンラインの man ページを使用するときはそのことに注意してください。}}

==特筆すべき man ページ==

以下は読む価値があるページの部分的なリストであり、様々なことを深く理解するのに役立ちます。リファレンスとして役立つページもあります (ascii テーブルなど)。

* {{man|7|ascii}}
* {{man|7|boot}}
* {{man|7|charsets}}
* {{man|1|chmod}}
* {{man|7|credentials}}
* {{man|5|fstab}}
* {{man|7|hier}}
* {{man|1|systemd}}
* {{man|1p|locale}}, {{man|5|locale}}, {{man|7|locale}}
* {{man|3|printf}}
* {{man|5|proc}}
* {{man|7|regex}}
* {{man|7|signal}}
* {{man|5|term}}, {{man|7|term}}
* {{man|5|termcap}}
* {{man|5|terminfo}}
* {{man|7|utf-8}}

他のページは、[http://man7.org/linux/man-pages/dir_section_7.html カテゴリ 7 (miscellaneous) ページ] を見て下さい:
$ man -s 7 -k ".*"

Arch Linux 特有のページ:
* {{man|5|alpm-hooks}}
* {{man|7|archlinux}}
* {{man|3|libalpm}}
* {{man|8|makepkg}}
* {{man|5|makepkg.conf}}
* {{man|1|makepkg-template}}
* {{man|8|mkinitcpio}}
* {{man|8|pacman}}
* {{man|5|pacman.conf}}
* {{man|8|pacman-conf}}
* {{man|8|pacman-key}}

== 参照 ==

* [https://wiki.gentoo.org/wiki/Man_page man page - Gentoo Wiki] - Gentoo wiki の記事
* [https://linuxtidbits.wordpress.com/2013/08/21/wtfm-write-the-fine-manual-with-pod2man-text-converter/ Write The Fine Manual with pod2man]
* [https://manpages.bsd.lv/history.html History of UNIX Manpages]

Dm-crypt/デバイスの暗号化

2025-03-10T12:41:22Z

Takemaro: /* plain モードでデバイスを暗号化 */ 未訳部分を最新の英語版から翻訳

{{Lowercase title}}
[[Category:保存データ暗号化]]
[[Category:ファイルシステム]]
[[en:Dm-crypt/Device encryption]]
このセクションではコマンドラインから ''dm-crypt'' を利用して手動でシステムを暗号化する方法を説明しています。

== 準備 ==
{{pkg|cryptsetup}} を使用する前に、{{ic|dm_crypt}} [[カーネルモジュール]]がロードされていることを確認してください。

== Cryptsetup の使用方法 ==
''Cryptsetup'' は暗号化デバイスを作成・管理する ''dm-crypt'' を使うためのコマンドラインツールです。後に Linux カーネルの '''d'''evice-'''m'''apper と '''crypt'''ographic モジュールを使用する別の暗号化もサポートするように拡張されました。最も著しい拡張は Linux Unified Key Setup (LUKS) の拡張で、dm-crypt をセットアップするのに必要な情報を全てディスク自体に保存してパーティションとキーの管理を抽象化することで使いやすさを増しています。device-mapper によってアクセスされるデバイスはブロックデバイスと呼ばれます。詳しくは[[ディスク暗号化#ブロックデバイスの暗号化]]を見て下さい。

ツールは以下のように使います:

# cryptsetup ''action'' ''options'' ''device'' ''dmname''

オプションや暗号化モードにはデフォルト値が存在し、コマンドラインで何も指定しなかった場合はデフォルト値が使われます。オプションや暗号化モードのデフォルトパラメータを確認するには以下のコマンドを実行:

$ cryptsetup --help

オプションの完全なリストは man ページで確認できます。暗号化モードやアクションによって必要なパラメータは変わるため、以下のセクションでは違いについて説明しています。ブロックデバイス暗号化は高速ですが、速度は非常に重要な問題です。ブロックデバイスの暗号を設定後に変更することは難しいため、それぞれのパラメータについて ''dm-crypt'' のパフォーマンスをチェックすると良いでしょう:

$ cryptsetup benchmark

上記のコマンドはインストールするときにアルゴリズムや鍵長を決める手がかりになります。特定の AES 暗号が非常に高速に処理される場合、おそらくその暗号は CPU によるハードウェア支援の恩恵に与かっています。

{{Tip|テストしたいときは[[:カテゴリ:仮想化|仮想マシン]]の仮想ハードドライブで練習すると良いでしょう。}}

=== Cryptsetup のパスフレーズとキー ===
暗号化されたブロックデバイスはキーによって保護されます。キーは以下のいずれかです:

*パスフレーズ、[[セキュリティ#パスワード]]を見て下さい。
*キーファイル、[[#キーファイル]] を見て下さい。

どちらのタイプのキーも最大サイズが決められています: パスフレーズは512文字まで、キーファイルは 8192kB までです。

''LUKS'' の重要な特徴として、キーは LUKS によって暗号化されたデバイスのマスターキーを解除するのに使われ、root 権限で変えることができるということです。他の暗号化モードでは設定後にキーを変更することはできません。暗号化にマスターキーを使わないためです。詳しくは[[ディスク暗号化#ブロックデバイスの暗号化]]を見て下さい。

== dm-crypt の暗号化オプション ==
''Cryptsetup'' は ''dm-crypt'' で使用できる様々な暗号化モードをサポートしています。
* {{ic|--type luks}} - LUKS フォーマットのデフォルトバージョン ({{Pkg|cryptsetup}} < 2.1.0 ではLUKS1、{{Pkg|cryptsetup}} ≥ 2.1.0 では LUKS2) を使用。
* {{ic|--type luks1}} - LUKS の古いバージョンである LUKS1 を使用。
* {{ic|--type luks2}} - LUKS に追加の拡張が導入された現在のバージョンである LUKS2 を使用。
** {{ic|--hw-opal-only}} - TCG OPAL 標準をサポートするドライブでハードウェアベースの暗号化を使用。[[自己暗号化ドライブ]]や {{man|8|cryptsetup|SED (SELF ENCRYPTING DRIVE) OPAL EXTENSION}} も参照して下さい。
** {{ic|--hw-opal}} - OPAL によるハードウェア暗号化と dm-crypt によるソフトウェア暗号化の両方を使用。
*{{ic|--type plain}} - dm-crypt plain モードを使用。
*{{ic|--type loopaes}} - loopaes legacy モードを使用。
*{{ic|--type tcrypt}} - [[Truecrypt]] 互換モードを使用。
* {{ic|--type bitlk}} - [[Wikipedia:ja:BitLocker|BitLocker]] 互換モードを使用。 {{man|8|cryptsetup|BITLK (WINDOWS BITLOCKER COMPATIBLE) EXTENSION}} も参照して下さい。

暗号やハッシュの基本的な暗号化オプションは全てのモードで使うことができ、カーネルの暗号化バックエンド機能を利用します。使用できるオプションは以下のコマンドで確認できます:

$ less /proc/crypto

{{Tip|リストが短い場合、{{ic|cryptsetup benchmark}} を実行すればモジュールのロードが行われます。}}

以下では LUKS モードと plain モードの暗号化オプションを紹介します。記事の中で例として使っているオプションを並べていますが、利用できるオプションの全てではないので注意してください。

=== LUKS モードの暗号化オプション ===
LUKS 暗号化モードで新しい dm-crypt デバイスをセットアップする ''cryptsetup'' のアクションは ''luksFormat'' です。名前にはフォーマットとありますが、実際にはデバイスをフォーマットするのではなく、LUKS デバイスヘッダーを設定して指定された暗号オプションを使ってマスター鍵を暗号化します。

デフォルトパラメータ ({{ic|cryptsetup --help}}で確認できます) で新しい LUKS デバイスを作成する場合、単に以下のコマンドを実行します:

# cryptsetup luksFormat ''device''

cryptsetup 2.4.0 の場合、これは以下と同等です:

# cryptsetup luksFormat --type luks2 --cipher aes-xts-plain64 --hash sha256 --iter-time 2000 --key-size 256 --pbkdf argon2id --use-urandom --verify-passphrase ''device''

以下の表でデフォルト値とサンプルにコメントを付けて説明しています:

{| class="wikitable"
! scope="col" style="text-align:left" | オプション
! scope="col" style="text-align:left" | Cryptsetup 2.1.0 のデフォルト
! scope="col" style="text-align:left" | 例
! scope="col" style="text-align:left" | コメント
|-
! scope="row" style="text-align:right" | --cipher, -c
| {{ic|aes-xts-plain64}}
| {{ic|aes-xts-plain64}}
| [https://www.kernel.org/pub/linux/utils/cryptsetup/v1.6/v1.6.0-ReleaseNotes バージョン 1.6.0]からデフォルトが AES [[ディスク暗号化#暗号と利用形態|暗号]]と [[wikipedia:Disk encryption theory#XEX-based tweaked-codebook mode with ciphertext stealing (XTS)|XTS]] を使用するよう変わりました ([https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#5-security-aspects FAQ] の 5.16 も参照)。以前のデフォルトである {{ic|--cipher aes-cbc-essiv}} は、[[wikipedia:Disk encryption theory#Cipher-block chaining (CBC)|既知の問題]]があり、[https://www.jakoblell.com/blog/2013/12/22/practical-malleability-attack-against-cbc-encrypted-luks-partitions/ 実際の攻撃]も存在するため、使用しないことをお勧めします。
|-
! scope="row" style="text-align:right" | --key-size, -s
| {{ic|256}} (XTSでは {{ic|512}})
| {{ic|512}}
| XTS モードの暗号では 512 ビットがデフォルトです。[[wikipedia:Disk encryption theory#XEX-based tweaked-codebook mode with ciphertext stealing (XTS)|XTS はキーを半分に割る]]ので、これは AES-256 が使われることを意味します。
|-
! scope="row" style="text-align:right" | --hash, -h
| {{ic|sha256}}
| {{ic|sha512}}
| [[ディスク暗号化#暗号メタデータ|鍵導出]] で使用されるハッシュアルゴリズム。リリース 1.7.0 でデフォルト設定が {{ic|sha1}} から {{ic|sha256}} に変更されました。セキュリティ上の理由ではなく SHA1 が使用できないシステムでも動作するようにするためです [https://www.kernel.org/pub/linux/utils/cryptsetup/v1.7/v1.7.0-ReleaseNotes]。{{ic|sha1}} でも十分セキュアであるため古いバージョンの ''cryptsetup'' と互換性を維持する目的で使用できます [https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#5-security-aspects]。
|-
! scope="row" style="text-align:right" | --iter-time, -i
| {{ic|2000}}
| {{ic|5000}}
| PBKDF2 パスフレーズを処理するのに費やす時間 (ミリ秒単位)。"''PBKDF2 の反復回数を高く保持したままユーザーが許容できる数値にするため''"、リリース 1.7.0 からデフォルト値が {{ic|1000}} から {{ic|2000}} に変更されています [https://www.kernel.org/pub/linux/utils/cryptsetup/v1.7/v1.7.0-ReleaseNotes]。''luksFormat'' や ''luksAddKey'' などパスフレーズを設定・変更する LUKS 操作のみに関連するオプションです。パラメータとして 0 を指定するとコンパイル時のデフォルトが選択されます。
|-
! scope="row" style="text-align:right" | --use-{u,}random
| {{ic|--use-'''u'''random}}
| {{ic|--use-random}}
| [[乱数生成|乱数生成器]]の選択。現在は {{ic|/dev/random}} と {{ic|/dev/urandom}} は等価なので、 {{ic|--use-random}} と {{ic|--use-urandom}} も等価です。
|-
! scope="row" style="text-align:right" | --verify-passphrase, -y
| Yes
| -
| {{ic|luksFormat}} と {{ic|luksAddKey}} で使われます。Arch Linux ではデフォルトで有効です。
|-
! scope="row" style="text-align:right" | --sector-size
| {{ic|512}} または {{ic|4096}} (デバイスに依存)
| {{ic|4096}}
| ディスク暗号化で使われるセクタサイズを設定します。デフォルトは、4Kn や 512e のブロックデバイスでは {{ic|4096}} で、512n のブロックデバイスでは {{ic|512}} です。最近のストレージデバイスのほとんどでは、セクタサイズを 512 バイトから 4096 バイトにすることでパフォーマンスが向上します。[[アドバンスドフォーマット#dm-crypt]]を見て下さい。
|}

LUKS の機能やオプションについては [https://gitlab.com/cryptsetup/cryptsetup/-/raw/master/docs/on-disk-format.pdf LUKS1 の仕様]や [https://gitlab.com/cryptsetup/cryptsetup/-/raw/master/docs/on-disk-format-luks2.pdf LUKS2の仕様] で説明されています。
{{Tip|開発者によるプレゼンテーション [https://mbroz.fedorapeople.org/talks/DevConf2016/devconf2016-luks2.pdf devconfcz2016] (pdf) では、LUKS2 での主な仕様変更の背景がまとめられています。cryptsetup のメジャーバージョンである[https://mirrors.edge.kernel.org/pub/linux/utils/cryptsetup/v2.0/v2.0.0-ReleaseNotes バージョン 2 のリリースノート]も見て下さい。}}

==== イテレーション時間 ====
[https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions#2-setup cryptsetup FAQ§2.1] と [https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions#3-common-problems §3.4]から:

:鍵スロットを解除するのにかかる時間は[...]パスフレーズを設定した時に決まります。デフォルトでは1秒 (LUKS2 では2秒) です。[...]
:パスフレーズをイテレーションする回数は時間によって決まり、したがってセキュリティレベルは LUKS コンテナを作成したマシンの CPU の能力に依存します。[...]
:もし高速なマシンでパスフレーズを設定し、低速なマシンでそれを解除した場合、解除にかかる時間は長くなります。

このことから、コンテナを作成する際は、そのコンテナに最も頻繁にアクセスすることになるマシンの上で作成するのが良いでしょう。

イテレーション回数を正しく調節する方法については、上の記事の残りの部分を読んで下さい。

=== plain モードの暗号化オプション ===
dm-crypt の ''plain'' モードでは、デバイスのマスター鍵が存在せず、セットアップも必要ありません。代わりに、直接暗号化オプションを使用して暗号ディスクと名前付きデバイスのマッピングを作成します。パーティションやデバイス全体に対してマッピングを作成できます。後者の場合、パーティションテーブルも不要です。

cryptsetup のデフォルトパラメータを使って ''plain'' のマッピングを作成するには:

# cryptsetup open --type plain ''options'' ''device'' ''dmname''

実行するとパスワードを求められます。非常に高いエントロピーのパスワードが必要です。デフォルトではありませんが、 {{ic|--verify-passphrase}} オプションを使えます。

一般論として、作成時の暗号化オプションは精確に記録しておくと良いでしょう。暗号化されたデバイス上にはオプションの内容は記録されていませんし、デフォルトのオプションは変わる可能性があります。

以下は [[Dm-crypt/システム全体の暗号化#Plain dm-crypt]] の例とデフォルトパラメータの比較表です。

{| class="wikitable"
! オプション !! Cryptsetup (2.7.0) のデフォルト !! 例 !! コメント !!
|-
| '''--hash, -h''' || {{ic|sha256}} || - || パスフレーズからキーを作成するのに使用するハッシュ。キーファイルを用いる場合は使われない。
|-
| '''--cipher, -c'''|| {{ic|aes-xts-plain64}}|| {{ic|aes-xts-plain64}} || 暗号は3つの文字列からなります: cipher-chainmode-IV generator。[[ディスク暗号化#暗号と利用形態]]や [https://gitlab.com/cryptsetup/cryptsetup/wikis/DMCrypt DMCrypt のドキュメント] を見てください。
|-
| '''--key-size, -s'''||{{ic|256}}||{{ic|512}}||キーサイズ (ビット数)。サイズは使用する暗号や使用するチェインモードによって変わります。XTS モードは CBC モードの2倍のキーサイズを必要とします。
|-
| '''--size, -b'''||対象ディスクの実際のサイズ||- (デフォルト)||512バイト単位のセクタ数。デバイスの最大サイズ以下。
|-
| '''--offset, -o'''||{{ic|0}}||{{ic|0}}||マッピングを開始するディスクの先頭からのオフセット。512バイト単位のセクタ数。
|-
| '''--skip, -p'''||{{ic|0}}||{{ic|2048}} (512B×2048=1MiB をスキップ)||初期ベクトル (IV) を計算する際にスキップする暗号化されたデータのサイズ。512バイト単位のセクタ数。
|-
| '''--key-file, -d'''||デフォルトではパスフレーズを使用||{{ic|/dev/sd''Z''}} (もしくは {{ic|/boot/keyfile.enc}})||キーとして使用するデバイスまたはファイル。詳しくは [[#キーファイル]] を参照。
|-
| '''--keyfile-offset'''||{{ic|0}}||{{ic|0}}||キーファイルの先頭からのオフセット (バイト数)。''cryptsetup'' 1.6.7 以上でサポートされているオプション。
|-
| '''--keyfile-size, -l'''||{{ic|8192kB}}||- (デフォルト)||キーファイルから読み込まれるバイト数を制限。''cryptsetup'' 1.6.7 以上でサポートされているオプション。
|-
| '''--sector-size, -l'''||{{ic|512}}||{{ic|4096}}||ディスク暗号化の際に使われるセクタサイズ。4Kn のブロックデバイス以外では、 {{ic|512}} がデフォルト。最近のストレージデバイスのほとんどでは、セクタサイズを 512 バイトから 4096 バイトにすることでパフォーマンスが向上します。[[アドバンスドフォーマット#dm-crypt]]を見て下さい。
|}

{{ic|/dev/sd''X''}} デバイスで、上記の例を使用する場合:

# cryptsetup open --type plain --cipher=aes-xts-plain64 --offset=0 --skip=2048 --key-file=/dev/sd''Z'' --key-size=512 --sector-size 4096 /dev/sdX enc

{{Warning|LUKS による暗号化と違って、上記のコマンドはマッピングを再現するために毎回 '''全て''' 指定する必要があります。暗号やハッシュ、キーファイルについて覚えておく必要があります。cryptsetup のデフォルトはバージョンによって変わるので、デフォルトに頼らないで下さい。}}

マッピングが作成されたことは以下のコマンドで確認できます:
# fdisk -l
{{ic|/dev/mapper/enc}} のエントリが存在しているはずです。

== cryptsetup でデバイスを暗号化 ==
以下のセクションでは新しい暗号化ブロックデバイスを作成するオプションと手動のアクセス方法を説明します。

{{Warning|GRUB の LUKS2 サポートは限られています。[[GRUB#暗号化された /boot]] を見て下さい。GRUB が解錠する必要のあるパーティションには、LUKS2 を PBKDF2 で使用 ({{ic|cryptsetup luksFormat --pbkdf pbkdf2}})して下さい。}}

=== LUKS モードでデバイスを暗号化 ===
==== LUKS パーティションのフォーマット ====

暗号化 LUKS パーティションとして設定するには次を実行:

# cryptsetup luksFormat ''device''

上記のコマンドを実行するとパスワードの入力が要求されます。

コマンドラインオプションは [[#LUKS モードの暗号化オプション]]を参照。

結果は次のコマンドで確認できます:

# cryptsetup luksDump ''device''

ダンプでは暗号のヘッダー情報だけでなく、LUKS パーティションで使われるキースロットもわかります。

以下の例はデフォルトの AES 暗号を使って256ビットの XTS モードで {{ic|/dev/sda1}} に暗号化したルートパーティションを作成します:
# cryptsetup luksFormat -s 512 /dev/sda1

=====LUKS を使ってキーファイルでパーティションをフォーマット=====

LUKS による暗号化パーティションを新しく作成する場合、以下のように作成するときにパーティションにキーファイルを関連付けることができます:

# cryptsetup luksFormat ''device'' ''/path/to/mykeyfile''

キーファイルを作成・管理する方法は [[#キーファイル]] を見て下さい。

====デバイスマッパーで LUKS パーティションのロックを解除・マップ====

LUKS パーティションを作成したら、解錠することができます。

解錠ではデバイスマッパーによってパーティションが新しいデバイス名にマッピングされます。カーネルは {{ic|''device''}} が暗号化デバイスであり暗号化データを上書きしないように {{ic|/dev/mapper/''dm_name''}} を使って LUKS 経由で解決する必要があることを知ります。間違って上書きしないために、設定が完了したら[[#バックアップとリストア|暗号化ヘッダーをバックアップ]]する方法を確認してください。

暗号化された LUKS パーティションを開くには次のコマンドを実行:

# cryptsetup open --type luks ''device'' ''dm_name''

実行するとパーティションを解錠するパスワードの入力が求められます。通常、マッピングするデバイスの名前はパーティションの機能が分かりやすいものにします。例えば、以下のコマンドは luks パーティション {{ic|/dev/sda1}} を解錠して {{ic|cryptroot}} という名前のデバイスマッパーにマッピングします:

# cryptsetup open --type luks /dev/sda1 cryptroot

パーティションをオープンしたら、ルートパーティションのデバイスアドレスはパーティション本体 (例: {{ic|/dev/sda1}}) の代わりに {{ic|/dev/mapper/cryptroot}} が使われます。

暗号化レイヤーの上に LVM をセットアップする場合、復号化したボリュームグループのデバイスファイルは {{ic|/dev/sda1}} ではなく {{ic|/dev/mapper/cryptroot}} などとなります。それから LVM は作成されている論理ボリューム全てに名前を割り当てます (例: {{ic|/dev/mapper/lvmpool-root}} や {{ic|/dev/mapper/lvmpool-swap}})。

暗号化データをパーティションに書き込むときは、マッピングされたデバイス名を使ってアクセスする必要があります。例えば[[ファイルシステム#デバイスのフォーマット|ファイルシステムを作成]]するときは以下のようにします:

# mkfs -t ext4 /dev/mapper/cryptroot

{{ic|/dev/mapper/cryptroot}} デバイスは他のパーティションと同じように[[マウント]]できます。

luks コンテナを閉じるには、パーティションをアンマウントし、以下を実行して下さい:

# cryptsetup close cryptroot

==== 鍵を TPM に保管する ====

[[Trusted Platform Module#LUKS による保存データの暗号化]]を見て下さい。

=== plain モードでデバイスを暗号化 ===

''dm-crypt'' プレーンモード暗号化の作成とその後のアクセスはどちらも、正しい [[#plain モードの暗号化オプション|オプション]] を指定して ''cryptsetup'' {{ic|open}} アクションを使用するだけで済みます。以下は、非ルートデバイスの2つの例で示していますが、両方をスタックする (2番目は最初のデバイス内に作成される) という変わった構成になっています。もちろん、暗号化をスタックするとオーバーヘッドが2倍になります。ここでの使用例は、暗号オプションの使用法のさらなる例を説明するためのものです。

最初のマッパーは、上の表の左側の列で示されているような ''cryptsetup'' のプレーンモードのデフォルトで作成されます。

{{hc|# cryptsetup --type plain -v open /dev/sdaX plain1|
WARNING: Using default options for cipher (aes-xts-plain64, key size 256 bits) that could be incompatible with older versions.
WARNING: Using default options for hash (sha256) that could be incompatible with older versions.
For plain mode, always use options --cipher, --key-size and if no keyfile is used, then also --hash.
Enter passphrase for /dev/sd''xY'':
Command successful.
}}

次に、さまざまな暗号化パラメーターを使用し、(オプションの) オフセットを使用して、その中に2番目のブロックデバイスを追加し、ファイルシステムを作成してマウントします。

{{hc|# lsblk -p|
NAME
/dev/sda
├─/dev/sd''xY''
│ └─/dev/mapper/plain1
│ └─/dev/mapper/plain2
...
}}

# mkfs -t ext2 /dev/mapper/plain2
# mount -t ext2 /dev/mapper/plain2 /mnt
# echo "This is stacked. one passphrase per foot to shoot." > /mnt/stacked.txt

正しくアクセスできるかどうか確認するため、一度スタックを閉じます。

# cryptsetup close plain2
# cryptsetup close plain1

まず、ファイルシステムを直接開いてみます:

# cryptsetup --type plain --cipher=serpent-xts-plain64 --hash=sha256 --key-size=256 --offset=10 open /dev/sd''xY'' plain2

{{hc|# mount -t ext2 /dev/mapper/plain2 /mnt|
mount: /mnt: wrong fs type, bad option, bad superblock on /dev/mapper/plain2, missing codepage or helper program, or other error.
dmesg(1) may have more information after failed mount system call.
}}

なぜこれが機能しないのでしょう? "plain2" の始まるブロック ({{ic|10}}) はまだ "plain1" によって暗号化されているからで、スタックされたマッパーを通してアクセスする必要があります。このエラーは曖昧で、誤ったパスワードや誤ったオプションでも同じエラーになります。 ''dm-crypt'' のプレーンモードでは、 {{ic|open}} アクション自体はエラーを出しません。

上で開いたマッパーを閉じた上で、今度は正しい順序で:

# cryptsetup close plain2

{{hc|# cryptsetup --type plain open /dev/sd''xY'' plain1|
WARNING: Using default options for cipher (aes-xts-plain64, key size 256 bits) that could be incompatible with older versions.
WARNING: Using default options for hash (sha256) that could be incompatible with older versions.
For plain mode, always use options --cipher, --key-size and if no keyfile is used, then also --hash.
Enter passphrase for /dev/sd''xY'':
}}

{{hc|1=# cryptsetup --type plain --cipher=serpent-xts-plain64 --hash=sha256 --key-size=256 --offset=10 open /dev/mapper/plain1 plain2|2=
Enter passphrase for /dev/mapper/plain1:
}}

{{hc|# mount /dev/mapper/plain2 /mnt && cat /mnt/stacked.txt|
This is stacked. one passphrase per foot to shoot.
}}

''dm-crypt'' は異なるモードを混ぜてスタックされた暗号化も扱えます。たとえば、LUKS モードが "plain1" マッパーの上にスタックされることができます。LUKS のヘッダーが "plain1" 内で暗号化されることになります。

プレーンモードのみで使用できるオプションに {{ic|--shared}} があります。これを用いると、重複しない範囲であれば、1つのデバイスから複数のマッパーを割り当てることができます。 "plain2" に ''loopaes'' 互換の暗号化モードを用いた例でその例を示します:

{{hc|# cryptsetup --type plain --offset 0 --size 1000 open /dev/sd''xY'' plain1|2=
WARNING: Using default options for cipher (aes-xts-plain64, key size 256 bits) that could be incompatible with older versions.
WARNING: Using default options for hash (sha256) that could be incompatible with older versions.
For plain mode, always use options --cipher, --key-size and if no keyfile is used, then also --hash.
Enter passphrase for /dev/sd''xY'':
}}

{{hc|1=# cryptsetup --type plain --offset 1000 --size 1000 --shared --cipher=aes-cbc-lmk --hash=sha256 open /dev/sd''xY'' plain2|2=
WARNING: Using default options for cipher (aes-cbc-lmk, key size 256 bits) that could be incompatible with older versions.
For plain mode, always use options --cipher, --key-size and if no keyfile is used, then also --hash.
Enter passphrase for /dev/sd''xY'':
}}

{{hc|# lsblk -p|
NAME
dev/sd''xY''
├─/dev/sd''xY''
│ ├─/dev/mapper/plain1
│ └─/dev/mapper/plain2
...
}}

デバイスツリーは2つが同じレベルで横並びになっていることを示しており、 "plain2" がスタックされることなく別個に開かれていることを意味します。

== LUKS 固有の Cryptsetup のアクション ==
=== キーの管理 ===
LUKS パーティションには異なる8つまでのキーを定義することができます。バックアップストレージのためのアクセスキーを作成することが可能です。いわゆるキーエスクローで、あるキーは日常的に使用するために使い、他のキーはエスクローに保存して日常用のパスフレーズを忘れたときやキーファイルを喪失・破損したときにパーティションにアクセスするために使います。また、別のキースロットを使って一時的なキーを発行してユーザーにパーティションへのアクセスを許可し、後でキーを無効化したりできます。

暗号化パーティションを作成すると、初期キースロット 0 が作成されます (手動で別の数字を指定しなかった場合)。追加キースロットは 1 から 7 までの数字が割り振られます。どのキースロットを使用しているかは以下のコマンドで確認できます (<device> は LUKS ヘッダーが存在するボリュームに置き換えてください):
{{hc|# cryptsetup luksDump /dev/<device> {{!}} grep BLED|
Key Slot 0: ENABLED
Key Slot 1: ENABLED
Key Slot 2: ENABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED}}

上記のコマンドや下で説明しているコマンドはヘッダーのバックアップファイルでも使えます。

==== LUKS キーの追加 ====

新しいキースロットの追加は cryptsetup の {{ic|luksAddKey}} アクションを使うことでできます。デバイスが解錠されていても安全のために、新しいキーを入力する前に、必ず既存のキーの入力が求められます ("any passphrase"):

{{hc|# cryptsetup luksAddKey /dev/<device> (/path/to/<additionalkeyfile>)|
Enter any passphrase:
Enter new passphrase for key slot:
Verify passphrase:
}}

{{ic|/path/to/<additionalkeyfile>}} を指定した場合、cryptsetup は <additionalkeyfile> の新しいキースロットを追加します。指定しなかった場合は新しいパスフレーズの入力が2回要求されます。既存の''キーファイル''を使って認証するには、{{ic|--key-file}} または {{ic|-d}} オプションの後に"既存"の <keyfile> を指定することで全てのキーファイルのキースロットが解除されます:

# cryptsetup luksAddKey /dev/<device> (/path/to/<additionalkeyfile>) -d /path/to/<keyfile>

複数のキーを使っていてキーを変更・無効化する場合、{{ic|--key-slot}} または {{ic|-S}} オプションでスロットを指定できます:
{{hc|# cryptsetup luksAddKey /dev/<device> -S 6|
Enter any passphrase:
Enter new passphrase for key slot:
Verify passphrase:
}}
{{hc|# cryptsetup luksDump /dev/sda8 {{!}} grep 'Slot 6'|
Key Slot 6: ENABLED
}}

例えばキーを変更したい場合:
{{hc|# cryptsetup luksChangeKey /dev/<device> -S 6|
Enter LUKS passphrase to be changed:
Enter new LUKS passphrase:
}}

==== LUKS キーの削除 ====

ヘッダーからキーを削除するアクションは3つ存在します:
*{{ic|luksRemoveKey}} はパスフレーズやキーファイルを指定してキーを削除します。
*{{ic|luksKillSlot}} は (他のキーを使って) 指定したキースロットからキーを削除します。パスフレーズを忘れたり、キーファイルを無くしたり、誰もアクセスできないようにしたい場合に有用です。
*{{ic|luksErase}} は全ての有効なキーを即座に削除します。
{{warning|
*All above actions can be used to irrevocably delete the last active key for an encrypted device!
*The {{ic|luksErase}} command was added in version 1.6.4 to quickly nuke access to the device. This action '''will not''' prompt for a valid passphrase! It will not [[Dm-crypt/ドライブの準備#LUKS ヘッダーを消去|wipe the LUKS header]], but all keyslots at once and you will, therefore, not be able to regain access unless you have a valid backup of the LUKS header.}}

For above warning it is good to know the key we want to '''keep''' is valid. An easy check is to unlock the device with the {{ic|-v}} option, which will specify which slot it occupies:
{{hc|# cryptsetup -v open /dev/<device> testcrypt|
Enter passphrase for /dev/<device>:
Key slot 1 unlocked.
Command successful.}}

Now we can remove the key added in the previous subsection using its passphrase:
{{hc|# cryptsetup luksRemoveKey /dev/<device>|
Enter LUKS passphrase to be deleted:
}}
If we had used the same passphrase for two keyslots, the first slot would be wiped now. Only executing it again would remove the second one.

Alternatively, we can specify the key slot:
{{hc|# cryptsetup luksKillSlot /dev/<device> 6|
Enter any remaining LUKS passphrase:
}}

Note that in both cases, no confirmation was required.
{{hc|# cryptsetup luksDump /dev/sda8 {{!}} grep 'Slot 6'|
Key Slot 6: DISABLED
}}
To re-iterate the warning above: If the same passphrase had been used for key slots 1 and 6, both would be gone now.

=== バックアップとリストア ===
If the header of a LUKS encrypted partition gets destroyed, you will not be able to decrypt your data. It is just as much of a dilemma as forgetting the passphrase or damaging a key-file used to unlock the partition. Damage may occur by your own fault while re-partitioning the disk later or by third-party programs misinterpreting the partition table. Therefore, having a backup of the header and storing it on another disk might be a good idea.

{{Note|If the LUKS-encrypted partitions' master passphrase becomes compromised, you must revoke it on ''every'' copy of the cryptheader, even those you have backed up. Otherwise, a copy of the backed-up cryptheader that uses the compromised passphrase can be used to decrypt the associated partition. See [https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#6-backup-and-data-recovery LUKS FAQ] for further details.}}

==== cryptsetup を使ってバックアップ ====
Cryptsetup's {{ic|luksHeaderBackup}} action stores a binary backup of the LUKS header and keyslot area:
# cryptsetup luksHeaderBackup /dev/<device> --header-backup-file /mnt/<backup>/<file>.img
where <device> is the partition containing the LUKS volume.

{{Tip|You can also back up the plaintext header into ramfs and encrypt it in example with gpg before writing to persistent backup storage by executing the following commands.}}
# mkdir /root/<tmp>/
# mount ramfs /root/<tmp>/ -t ramfs
# cryptsetup luksHeaderBackup /dev/<device> --header-backup-file /root/<tmp>/<file>.img
# gpg2 --recipient <User ID> --encrypt /root/<tmp>/<file>.img
# cp /root/<tmp>/<file>.img.gpg /mnt/<backup>/
# umount /root/<tmp>
{{Warning|Tmpfs can swap to harddisk if low on memory so it is not recommended here.}}

==== cryptsetup を使ってリストア ====

{{Warning|Restoring the wrong header or restoring to an unencrypted partition will cause data loss! The action can not perform a check whether the header is actually the ''correct'' one for that particular device.}}

In order to evade restoring a wrong header, you can ensure it does work by using it as a remote {{ic|--header}} first:

{{hc|# cryptsetup -v --header /mnt/<backup>/<file>.img open /dev/<device> test|
Key slot 0 unlocked.
Command successful.
}}
# mount /dev/mapper/test /mnt/test && ls /mnt/test
# umount /mnt/test
# cryptsetup close test

Now that the check succeeded, the restore may be performed:
# cryptsetup luksHeaderRestore /dev/<device> --header-backup-file ./mnt/<backup>/<file>.img

Now that all the keyslot areas are overwritten; only active keyslots from the backup file are available after issuing the command.

==== 手動バックアップとリストア ====
The header always resides at the beginning of the device and a backup can be performed without access to ''cryptsetup'' as well. First you have to find out the payload offset of the crypted partition:
{{hc|# cryptsetup luksDump /dev/<device> {{!}} grep "Payload offset"|
Payload offset: 4040}}
Second check the sector size of the drive
{{hc|# fdisk -l /dev/<device> {{!}} grep "Sector size"|Sector size (logical/physical): 512 bytes / 512 bytes}}

Now that you know the values, you can backup the header with a simple dd command:
# dd if=/dev/<device> of=/path/to/<file>.img bs=512 count=4040
and store it safely.

A restore can then be performed using the same values as when backing up:
# dd if=./<file>.img of=/dev/<device> bs=512 count=4040

=== デバイスの再暗号化 ===

The {{Pkg|cryptsetup}} package features the ''cryptsetup-reencrypt'' tool. It can be used to convert an existing unencrypted filesystem to a LUKS encrypted one (option {{ic|--new}}) and permanently remove LUKS encryption ({{ic|--decrypt}}) from a device. As its name suggests it can also be used to re-encrypt an existing LUKS encrypted device, though, re-encryption is not possible for a detached LUKS header or other encryption modes (e.g. plain-mode). For re-encryption it is possible to change the [[#LUKS モードの暗号化オプション]]. ''cryptsetup-reencrypt'' actions can be performed to unmounted devices only. See {{man|8|cryptsetup-reencrypt}} for more information.

One application of re-encryption may be to secure the data again after a passphrase or [[#キーファイル|keyfile]] has been compromised ''and'' one cannot be certain that no copy of the LUKS header has been obtained. For example, if only a passphrase has been shoulder-surfed but no physical/logical access to the device happened, it would be enough to change the respective passphrase/key only ([[#Key management]]).

{{Warning|Always make sure a '''reliable backup''' is available and double-check options you specify before using the tool!}}

The following shows an example to encrypt an unencrypted filesystem partition and a re-encryption of an existing LUKS device.

==== 暗号化されていないファイルシステムの暗号化 ====

A LUKS encryption header is always stored at the beginning of the device. Since an existing filesystem will usually be allocated all partition sectors, the first step is to shrink it to make space for the LUKS header.

The [[#LUKS モードの暗号化オプション|default]] LUKS header encryption cipher requires {{ic|4096}} 512-byte sectors. We already checked space and keep it simple by shrinking the existing {{ic|ext4}} filesystem on {{ic|/dev/sdaX}} to its current possible minimum:

# umount /mnt
{{hc|# e2fsck -f /dev/sdaX|
e2fsck 1.43-WIP (18-May-2015)
Pass 1: Checking inodes, blocks, and sizes
...
/dev/sda6: 12/166320 files (0.0% non-contiguous), 28783/665062 blocks
}}
{{hc|# resize2fs -M /dev/sdaX|
resize2fs 1.43-WIP (18-May-2015)
Resizing the filesystem on /dev/sdaX to 26347 (4k) blocks.
The filesystem on /dev/sdaX is now 26347 (4k) blocks long.}}

Now we encrypt it, using the default cipher we do not have to specify it explicitly. Note there is no option (yet) to double-check the passphrase before encryption starts, be careful not to mistype:

{{hc|# cryptsetup-reencrypt /dev/sdaX --new --reduce-device-size 4096S|
WARNING: this is experimental code, it can completely break your data.
Enter new passphrase:
Progress: 100,0%, ETA 00:00, 2596 MiB written, speed 37,6 MiB/s}}

After it finished, the encryption was performed to the full partition, i.e. not only the space the filesystem was shrunk to ({{ic|sdaX}} has {{ic|2.6GiB}} and the CPU used in the example has no hardware AES instructions). As a final step we extend the filesystem of the now encrypted device again to occupy available space:

{{hc|# cryptsetup open /dev/sdaX recrypt|
Enter passphrase for /dev/sdaX:
...
}}
{{hc|# resize2fs /dev/mapper/recrypt|
resize2fs 1.43-WIP (18-May-2015)
Resizing the filesystem on /dev/mapper/recrypt to 664807 (4k) blocks.
The filesystem on /dev/mapper/recrypt is now 664807 (4k) blocks long.}}
# mount /dev/mapper/recrypt /mnt

and are done.

==== 既存の LUKS パーティションの再暗号化 ====

以下の例では既存の LUKS デバイスを最暗号化しています。

{{Warning|Double-check you specify encryption options for ''cryptsetup-reencrypt'' correctly and ''never'' re-encrypt without a '''reliable backup'''! As of September 2015 the tool '''does''' accept invalid options and damage the LUKS header, if not used correctly!}}

In order to re-encrypt a device with its existing encryption options, they do not need to be specified. A simple:

{{hc|# cryptsetup-reencrypt /dev/sdaX|
WARNING: this is experimental code, it can completely break your data.
Enter passphrase for key slot 0:
Progress: 100,0%, ETA 00:00, 2596 MiB written, speed 36,5 MiB/s}}

performs it.

A possible usecase is to re-encrypt LUKS devices which have non-current encryption options. Apart from above warning on specifying options correctly, the ability to change the LUKS header may also be limited by its size. For example, if the device was initially encrypted using a CBC mode cipher and 128 bit key-size, the LUKS header will be half the size of above mentioned {{ic|4096}} sectors:
{{hc|# cryptsetup luksDump /dev/sdaX <nowiki>|</nowiki>grep -e "mode" -e "Payload" -e "MK bits"|
Cipher mode: cbc-essiv:sha256
Payload offset: '''2048'''
MK bits: 128}}
While it is possible to upgrade the encryption of such a device, it is currently only feasible in two steps. First, re-encrypting with the same encryption options, but using the {{ic|--reduce-device-size}} option to make further space for the larger LUKS header. Second, re-encypt the whole device again with the desired cipher. For this reason and the fact that a backup should be created in any case, creating a new, fresh encrypted device to restore into is always the faster option.

== 暗号化デバイスのリサイズ ==

If a storage device encrypted with dm-crypt is being cloned (with a tool like dd) to another larger device, the underlying dm-crypt device must be resized to use the whole space.

The destination device is /dev/sdX2 in this example, the whole available space adjacent to the partition will be used:

# cryptsetup luksOpen /dev/sdX2 sdX2
# cryptsetup resize sdX2

Then the underlying filesystem must be resized.

=== ループバックファイルシステム ===

暗号化したループバックデバイスを {{ic|/mnt/secret}} にマウントしている場合、例えば [[Dm-crypt/root 以外のファイルシステムの暗号化#Loop デバイス]] に従っている場合、最初に暗号化コンテナをアンマウント:
# umount /mnt/secret
# cryptsetup close secret
# losetup -d /dev/loop0

次に、追加したいデータ容量を決めてコンテナファイルを拡張します:

{{Warning|{{ic|>}} を2つ使っていることに注意してください。1つだけだと現在のコンテナを上書きしてしまいます。}}
# dd if=/dev/urandom bs=1M count=1024 | cat - >> /bigsecret

ループデバイスにコンテナをマップ:
# losetup /dev/loop0 /bigsecret
# cryptsetup --type luks open /dev/loop0 secret

その後、コンテナの暗号化された部分をコンテナファイルの最大サイズまでリサイズ:
# cryptsetup resize secret

最後に、ファイルシステムのチェックを実行して、問題なければ、リサイズを行います (例: ext2/3/4):
# e2fsck -f /dev/mapper/secret
# resize2fs /dev/mapper/secret

またコンテナをマウントすることができます:
# mount /dev/mapper/secret /mnt/secret

== キーファイル ==

{{Note|このセクションでは平文のキーファイルを使う方法を説明しています。キーファイルを暗号化して二段階認証したい場合は[[Dm-crypt/特記事項#GPG や OpenSSL で暗号化されたキーファイルを使う|GPG や OpenSSL で暗号化されたキーファイルを使う]]を見て下さい。ただし、このセクションもあらかじめ読むようにしてください。}}

'''キーファイルとは？'''

キーファイルは暗号化されたボリュームを解錠するパスフレーズとして使用するデータを含んだファイルです。ファイルを喪失した場合、ボリュームの復号化はできなくなります。

{{Tip|Define a passphrase in addition to the keyfile for backup access to encrypted volumes in the event the defined keyfile is lost or changed.}}

'''なぜキーファイルを使うのか？'''

キーファイルには様々なタイプがあります。以下で説明しているようにそれぞれメリットとデメリットが存在します:

=== キーファイルのタイプ ===
==== passphrase ====

単にパスフレーズが記述されたキーファイルです。メリットはファイルを無くしても暗号化ボリュームの所有者が簡単に中身を思い出せることです。デメリットはパスフレーズの入力と比べてセキュリティ上の優位点がないことです。

例: {{ic|1234}}。

{{Note|パスフレーズが記述されたキーファイルに改行を含めてはいけません。以下のようなコマンドでファイルを作成できます:
# echo -n 'your_passphrase' > /path/to/<keyfile>
# chown root:root /path/to/<keyfile>; chmod 400 /path/to/<keyfile>
}}

==== randomtext ====

This is a keyfile containing a block of random characters. The benefit of this type of keyfile is that it is much more resistant to dictionary attacks than a simple passphrase. An additional strength of keyfiles can be utilized in this situation which is the length of data used. Since this is not a string meant to be memorized by a person for entry, it is trivial to create files containing thousands of random characters as the key. The disadvantage is that if this file is lost or changed, it will most likely not be possible to access the encrypted volume without a backup passphrase.

例: {{ic|fjqweifj830149-57 819y4my1-38t1934yt8-91m 34co3;t8y;9p3y-}}。

==== binary ====

This is a binary file that has been defined as a keyfile. When identifying files as candidates for a keyfile, it is recommended to choose files that are relatively static such as photos, music, video clips. The benefit of these files is that they serve a dual function which can make them harder to identify as keyfiles. Instead of having a text file with a large amount of random text, the keyfile would look like a regular image file or music clip to the casual observer. The disadvantage is that if this file is lost or changed, it will most likely not be possible to access the encrypted volume without a backup passphrase. Additionally, there is a theoretical loss of randomness when compared to a randomly generated text file. This is due to the fact that images, videos and music have some intrinsic relationship between neighboring bits of data that does not exist for a text file. However this is controversial and has never been exploited publicly.

例: 画像, テキスト, 動画。

=== ランダムな文字列でキーファイルを作成 ===

==== ファイルシステムにキーファイルを保存 ====

キーファイルの中身とサイズは任意に決められます。

以下では {{ic|dd}} を使って2048バイトのランダムなキーファイルを生成して、{{ic|/etc/mykeyfile}} ファイルに保存します:

# dd bs=512 count=4 if=/dev/urandom of=/etc/mykeyfile

キーファイルを外部デバイスに保存する場合、出力先を適切なディレクトリに変更します:

# dd bs=512 count=4 if=/dev/urandom of=/media/usbstick/mykeyfile

===== 保存されたキーファイルを完全に消去 =====

物理的なストレージデバイスに一時的なキーファイルを保存する場合、削除するときは、以下のように完全に削除してください:

# shred --remove --zero mykeyfile

FAT や ext2 であれば上記で十分ですが、ジャーナリングファイルシステムやフラッシュメモリハードウェアの場合、[[ディスクの完全消去]]あるいはキーファイルのあるパーティションを削除することを強く推奨します。

==== ramfs にキーファイルを保存 ====

もしくは、ramfs をマウントしてキーファイルを一時的に保存:

# mkdir /root/myramfs
# mount ramfs /root/myramfs/ -t ramfs
# cd /root/myramfs

物理ディスクではなくメモリ上に配置することで、ramfs をアンマウントしたら復元できないという利点があります。キーファイルを他の安全なファイルシステムにコピーしたら、以下のコマンドで ramfs をアンマウントしてください:
# umount /root/myramfs

=== キーファイルを使用するように LUKS を設定 ===

キーファイルのキースロットを LUKS ヘッダに追加:

{{hc|# cryptsetup luksAddKey /dev/sda2 /etc/mykeyfile|
Enter any LUKS passphrase:
key slot 0 unlocked.
Command successful.}}

=== キーファイルを使ってパーティションを手動でアンロック ===

LUKS デバイスをオープンするときに {{ic|--key-file}} オプションを使ってください:

# cryptsetup open /dev/sda2 ''dm_name'' --key-file /etc/mykeyfile

=== 起動時にロックを解除 ===

ファイルシステムのキーファイルを暗号化されたルートディレクトリの中に保存することで、システムの電源が切れているときに安全を確保することができ、[[Dm-crypt/システム設定#crypttab|crypttab]] によって起動時に自動的にマウントを解錠することができます。[[UUID]] を使用する例:
{{hc|/etc/crypttab|<nowiki>home UUID=<UUID identifier> /etc/mykeyfile</nowiki>}}
is all needed for unlocking, and
{{hc|/etc/fstab|/dev/mapper/home /home ext4 defaults 0 2}} for mounting the LUKS blockdevice with the generated keyfile.
{{Tip|If you prefer to use a {{ic|--plain}} mode blockdevice, the encryption options necessary to unlock it are specified in {{ic|/etc/crypttab}}. Take care to apply the systemd workaround mentioned in [[Dm-crypt/システム設定#crypttab|crypttab]] in this case.}}

=== キーファイルを使って起動時に root パーティションのロックを解除 ===

[[mkinitcpio]] を設定して必要なモジュールやファイルを記述して [[Dm-crypt/システム設定#cryptkey|cryptkey]] [[カーネルパラメータ]]を設定してキーファイルの場所を指定します。

2つの方法が存在します:

# 外部メディア (USB スティック) にキーファイルを保存
# initramfs にキーファイルを埋め込む

==== キーファイルを外部メディアに保存 ====

===== mkinitcpio の設定 =====

ドライブのファイルシステムを使うために {{ic|/etc/mkinitcpio.conf}} にモジュールを追加してください (以下の例では {{ic|vfat}} モジュール):
MODULES=(vfat)

In this example it is assumed that you use a FAT formatted USB drive ({{ic|vfat}} module). Replace those module names if you use another file system on your USB stick (e.g. {{ic|ext2}}) or another codepage. If it complains of bad superblock and bad codepage at boot, then you need an extra codepage module to be loaded. For instance, you may need {{ic|nls_iso8859-1}} module for {{ic|iso8859-1}} codepage.

If you have a non-US keyboard, it might prove useful to load your keyboard layout before you are prompted to enter the password to unlock the root partition at boot. For this, you will need the {{ic|keymap}} hook before {{ic|encrypt}}.

Generate a new initramfs image:

# mkinitcpio -p linux

===== カーネルパラメータの設定 =====

以下のオプションを[[カーネルパラメータ]]に追加してください ({{ic|encrypt}} フックではなく {{ic|sd-encrypt}} フックを使用する場合は [[Dm-crypt/システム設定#sd-encrypt フックを使う]]を参照):

cryptdevice=/dev/''<partition1>'':root cryptkey=/dev/''<partition2>'':<fstype>:<path>

例:

cryptdevice=/dev/sda3:root cryptkey=/dev/sdb1:vfat:/keys/secretkey

Choosing a plain filename for your key provides a bit of 'security through obscurity'. The keyfile can not be a hidden file, that means the filename must not start with a dot, or the {{ic|encrypt}} hook will fail to find the keyfile during the boot process.

{{ic|/dev/sdb1}} のようなデバイスノードの名前は再起動しても同じであるとは保証されていません。udev による[[永続的なブロックデバイスの命名]]を使ったほうが確実にデバイスにアクセスできます。外部ストレージデバイスからキーファイルを読み取るときに {{ic|encrypt}} フックが確実にキーファイルを見つけられるように、永続的なブロックデバイスの名前を絶対に使うべきです。[[永続的なブロックデバイスの命名]]を見て下さい。

==== キーファイルを initramfs に埋め込む ====

{{Warning|Use an embedded keyfile '''only''' if you have some form of authentication mechanism beforehand that protects the keyfile sufficiently. Otherwise auto-decryption will occur, defeating completely the purpose of block device encryption.}}

This method allows to use a specially named keyfile that will be embedded in the [[initramfs]] and picked up by the {{ic|encrypt}} [[Mkinitcpio#HOOKS|hook]] to unlock the root filesystem ({{ic|cryptdevice}}) automatically. It may be useful to apply when using the [[GRUB#暗号化された /boot|GRUB early cryptodisk]] feature, in order to avoid entering two passphrases during boot.

The {{ic|encrypt}} hook lets the user specify a keyfile with the {{ic|cryptkey}} kernel parameter: in the case of initramfs, the syntax is {{ic|rootfs:''path''}}, see [[Dm-crypt/システム設定#cryptkey]]. Besides, this kernel parameter defaults to use {{ic|/crypto_keyfile.bin}}, and if the initramfs contains a valid key with this name, decryption will occur automatically without the need to configure the {{ic|cryptkey}} parameter.

{{ic|encrypt}} の代わりに {{ic|sd-encrypt}} を使用する場合、{{ic|luks.key}} カーネルパラメータでキーファイルの場所を指定してください。[[Dm-crypt/システム設定#luks.key]] を参照。

[[#ランダムな文字列でキーファイルを作成|キーファイルを生成]]して適切な権限を与えて [[#LUKS キーの追加|LUKS キーとして追加]]:

# dd bs=512 count=4 if=/dev/urandom of=/crypto_keyfile.bin
# chmod 000 /crypto_keyfile.bin
# chmod 600 /boot/initramfs-linux*
# cryptsetup luksAddKey /dev/sdX# /crypto_keyfile.bin

{{Warning|When initramfs' permissions are set to 644 (by default), then all users will be able to dump the keyfile. Make sure the permissions are still 600 if you install a new kernel.}}

[[Mkinitcpio#BINARIES_と_FILES|mkinitcpio の FILES]] にキーを記述:

{{hc|/etc/mkinitcpio.conf|2=FILES=(/crypto_keyfile.bin)}}

最後に [[Mkinitcpio#イメージ作成とアクティベーション|initramfs を再生成]]してください。

次の起動時からコンテナを復号化するパスフレーズを入力するのは一度だけですむようになります。

詳しくは [http://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/#bonus-login-once こちら] を参照。

Dm-crypt/デバイスの暗号化

2025-03-09T18:43:45Z

Takemaro: /* cryptsetup でデバイスを暗号化 */ 翻訳済みの部分について最新の英語版を反映: GRUB の LUKS2 に関する警告、コマンド出力の更新、等

{{Lowercase title}}
[[Category:保存データ暗号化]]
[[Category:ファイルシステム]]
[[en:Dm-crypt/Device encryption]]
このセクションではコマンドラインから ''dm-crypt'' を利用して手動でシステムを暗号化する方法を説明しています。

== 準備 ==
{{pkg|cryptsetup}} を使用する前に、{{ic|dm_crypt}} [[カーネルモジュール]]がロードされていることを確認してください。

== Cryptsetup の使用方法 ==
''Cryptsetup'' は暗号化デバイスを作成・管理する ''dm-crypt'' を使うためのコマンドラインツールです。後に Linux カーネルの '''d'''evice-'''m'''apper と '''crypt'''ographic モジュールを使用する別の暗号化もサポートするように拡張されました。最も著しい拡張は Linux Unified Key Setup (LUKS) の拡張で、dm-crypt をセットアップするのに必要な情報を全てディスク自体に保存してパーティションとキーの管理を抽象化することで使いやすさを増しています。device-mapper によってアクセスされるデバイスはブロックデバイスと呼ばれます。詳しくは[[ディスク暗号化#ブロックデバイスの暗号化]]を見て下さい。

ツールは以下のように使います:

# cryptsetup ''action'' ''options'' ''device'' ''dmname''

オプションや暗号化モードにはデフォルト値が存在し、コマンドラインで何も指定しなかった場合はデフォルト値が使われます。オプションや暗号化モードのデフォルトパラメータを確認するには以下のコマンドを実行:

$ cryptsetup --help

オプションの完全なリストは man ページで確認できます。暗号化モードやアクションによって必要なパラメータは変わるため、以下のセクションでは違いについて説明しています。ブロックデバイス暗号化は高速ですが、速度は非常に重要な問題です。ブロックデバイスの暗号を設定後に変更することは難しいため、それぞれのパラメータについて ''dm-crypt'' のパフォーマンスをチェックすると良いでしょう:

$ cryptsetup benchmark

上記のコマンドはインストールするときにアルゴリズムや鍵長を決める手がかりになります。特定の AES 暗号が非常に高速に処理される場合、おそらくその暗号は CPU によるハードウェア支援の恩恵に与かっています。

{{Tip|テストしたいときは[[:カテゴリ:仮想化|仮想マシン]]の仮想ハードドライブで練習すると良いでしょう。}}

=== Cryptsetup のパスフレーズとキー ===
暗号化されたブロックデバイスはキーによって保護されます。キーは以下のいずれかです:

*パスフレーズ、[[セキュリティ#パスワード]]を見て下さい。
*キーファイル、[[#キーファイル]] を見て下さい。

どちらのタイプのキーも最大サイズが決められています: パスフレーズは512文字まで、キーファイルは 8192kB までです。

''LUKS'' の重要な特徴として、キーは LUKS によって暗号化されたデバイスのマスターキーを解除するのに使われ、root 権限で変えることができるということです。他の暗号化モードでは設定後にキーを変更することはできません。暗号化にマスターキーを使わないためです。詳しくは[[ディスク暗号化#ブロックデバイスの暗号化]]を見て下さい。

== dm-crypt の暗号化オプション ==
''Cryptsetup'' は ''dm-crypt'' で使用できる様々な暗号化モードをサポートしています。
* {{ic|--type luks}} - LUKS フォーマットのデフォルトバージョン ({{Pkg|cryptsetup}} < 2.1.0 ではLUKS1、{{Pkg|cryptsetup}} ≥ 2.1.0 では LUKS2) を使用。
* {{ic|--type luks1}} - LUKS の古いバージョンである LUKS1 を使用。
* {{ic|--type luks2}} - LUKS に追加の拡張が導入された現在のバージョンである LUKS2 を使用。
** {{ic|--hw-opal-only}} - TCG OPAL 標準をサポートするドライブでハードウェアベースの暗号化を使用。[[自己暗号化ドライブ]]や {{man|8|cryptsetup|SED (SELF ENCRYPTING DRIVE) OPAL EXTENSION}} も参照して下さい。
** {{ic|--hw-opal}} - OPAL によるハードウェア暗号化と dm-crypt によるソフトウェア暗号化の両方を使用。
*{{ic|--type plain}} - dm-crypt plain モードを使用。
*{{ic|--type loopaes}} - loopaes legacy モードを使用。
*{{ic|--type tcrypt}} - [[Truecrypt]] 互換モードを使用。
* {{ic|--type bitlk}} - [[Wikipedia:ja:BitLocker|BitLocker]] 互換モードを使用。 {{man|8|cryptsetup|BITLK (WINDOWS BITLOCKER COMPATIBLE) EXTENSION}} も参照して下さい。

暗号やハッシュの基本的な暗号化オプションは全てのモードで使うことができ、カーネルの暗号化バックエンド機能を利用します。使用できるオプションは以下のコマンドで確認できます:

$ less /proc/crypto

{{Tip|リストが短い場合、{{ic|cryptsetup benchmark}} を実行すればモジュールのロードが行われます。}}

以下では LUKS モードと plain モードの暗号化オプションを紹介します。記事の中で例として使っているオプションを並べていますが、利用できるオプションの全てではないので注意してください。

=== LUKS モードの暗号化オプション ===
LUKS 暗号化モードで新しい dm-crypt デバイスをセットアップする ''cryptsetup'' のアクションは ''luksFormat'' です。名前にはフォーマットとありますが、実際にはデバイスをフォーマットするのではなく、LUKS デバイスヘッダーを設定して指定された暗号オプションを使ってマスター鍵を暗号化します。

デフォルトパラメータ ({{ic|cryptsetup --help}}で確認できます) で新しい LUKS デバイスを作成する場合、単に以下のコマンドを実行します:

# cryptsetup luksFormat ''device''

cryptsetup 2.4.0 の場合、これは以下と同等です:

# cryptsetup luksFormat --type luks2 --cipher aes-xts-plain64 --hash sha256 --iter-time 2000 --key-size 256 --pbkdf argon2id --use-urandom --verify-passphrase ''device''

以下の表でデフォルト値とサンプルにコメントを付けて説明しています:

{| class="wikitable"
! scope="col" style="text-align:left" | オプション
! scope="col" style="text-align:left" | Cryptsetup 2.1.0 のデフォルト
! scope="col" style="text-align:left" | 例
! scope="col" style="text-align:left" | コメント
|-
! scope="row" style="text-align:right" | --cipher, -c
| {{ic|aes-xts-plain64}}
| {{ic|aes-xts-plain64}}
| [https://www.kernel.org/pub/linux/utils/cryptsetup/v1.6/v1.6.0-ReleaseNotes バージョン 1.6.0]からデフォルトが AES [[ディスク暗号化#暗号と利用形態|暗号]]と [[wikipedia:Disk encryption theory#XEX-based tweaked-codebook mode with ciphertext stealing (XTS)|XTS]] を使用するよう変わりました ([https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#5-security-aspects FAQ] の 5.16 も参照)。以前のデフォルトである {{ic|--cipher aes-cbc-essiv}} は、[[wikipedia:Disk encryption theory#Cipher-block chaining (CBC)|既知の問題]]があり、[https://www.jakoblell.com/blog/2013/12/22/practical-malleability-attack-against-cbc-encrypted-luks-partitions/ 実際の攻撃]も存在するため、使用しないことをお勧めします。
|-
! scope="row" style="text-align:right" | --key-size, -s
| {{ic|256}} (XTSでは {{ic|512}})
| {{ic|512}}
| XTS モードの暗号では 512 ビットがデフォルトです。[[wikipedia:Disk encryption theory#XEX-based tweaked-codebook mode with ciphertext stealing (XTS)|XTS はキーを半分に割る]]ので、これは AES-256 が使われることを意味します。
|-
! scope="row" style="text-align:right" | --hash, -h
| {{ic|sha256}}
| {{ic|sha512}}
| [[ディスク暗号化#暗号メタデータ|鍵導出]] で使用されるハッシュアルゴリズム。リリース 1.7.0 でデフォルト設定が {{ic|sha1}} から {{ic|sha256}} に変更されました。セキュリティ上の理由ではなく SHA1 が使用できないシステムでも動作するようにするためです [https://www.kernel.org/pub/linux/utils/cryptsetup/v1.7/v1.7.0-ReleaseNotes]。{{ic|sha1}} でも十分セキュアであるため古いバージョンの ''cryptsetup'' と互換性を維持する目的で使用できます [https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#5-security-aspects]。
|-
! scope="row" style="text-align:right" | --iter-time, -i
| {{ic|2000}}
| {{ic|5000}}
| PBKDF2 パスフレーズを処理するのに費やす時間 (ミリ秒単位)。"''PBKDF2 の反復回数を高く保持したままユーザーが許容できる数値にするため''"、リリース 1.7.0 からデフォルト値が {{ic|1000}} から {{ic|2000}} に変更されています [https://www.kernel.org/pub/linux/utils/cryptsetup/v1.7/v1.7.0-ReleaseNotes]。''luksFormat'' や ''luksAddKey'' などパスフレーズを設定・変更する LUKS 操作のみに関連するオプションです。パラメータとして 0 を指定するとコンパイル時のデフォルトが選択されます。
|-
! scope="row" style="text-align:right" | --use-{u,}random
| {{ic|--use-'''u'''random}}
| {{ic|--use-random}}
| [[乱数生成|乱数生成器]]の選択。現在は {{ic|/dev/random}} と {{ic|/dev/urandom}} は等価なので、 {{ic|--use-random}} と {{ic|--use-urandom}} も等価です。
|-
! scope="row" style="text-align:right" | --verify-passphrase, -y
| Yes
| -
| {{ic|luksFormat}} と {{ic|luksAddKey}} で使われます。Arch Linux ではデフォルトで有効です。
|-
! scope="row" style="text-align:right" | --sector-size
| {{ic|512}} または {{ic|4096}} (デバイスに依存)
| {{ic|4096}}
| ディスク暗号化で使われるセクタサイズを設定します。デフォルトは、4Kn や 512e のブロックデバイスでは {{ic|4096}} で、512n のブロックデバイスでは {{ic|512}} です。最近のストレージデバイスのほとんどでは、セクタサイズを 512 バイトから 4096 バイトにすることでパフォーマンスが向上します。[[アドバンスドフォーマット#dm-crypt]]を見て下さい。
|}

LUKS の機能やオプションについては [https://gitlab.com/cryptsetup/cryptsetup/-/raw/master/docs/on-disk-format.pdf LUKS1 の仕様]や [https://gitlab.com/cryptsetup/cryptsetup/-/raw/master/docs/on-disk-format-luks2.pdf LUKS2の仕様] で説明されています。
{{Tip|開発者によるプレゼンテーション [https://mbroz.fedorapeople.org/talks/DevConf2016/devconf2016-luks2.pdf devconfcz2016] (pdf) では、LUKS2 での主な仕様変更の背景がまとめられています。cryptsetup のメジャーバージョンである[https://mirrors.edge.kernel.org/pub/linux/utils/cryptsetup/v2.0/v2.0.0-ReleaseNotes バージョン 2 のリリースノート]も見て下さい。}}

==== イテレーション時間 ====
[https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions#2-setup cryptsetup FAQ§2.1] と [https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions#3-common-problems §3.4]から:

:鍵スロットを解除するのにかかる時間は[...]パスフレーズを設定した時に決まります。デフォルトでは1秒 (LUKS2 では2秒) です。[...]
:パスフレーズをイテレーションする回数は時間によって決まり、したがってセキュリティレベルは LUKS コンテナを作成したマシンの CPU の能力に依存します。[...]
:もし高速なマシンでパスフレーズを設定し、低速なマシンでそれを解除した場合、解除にかかる時間は長くなります。

このことから、コンテナを作成する際は、そのコンテナに最も頻繁にアクセスすることになるマシンの上で作成するのが良いでしょう。

イテレーション回数を正しく調節する方法については、上の記事の残りの部分を読んで下さい。

=== plain モードの暗号化オプション ===
dm-crypt の ''plain'' モードでは、デバイスのマスター鍵が存在せず、セットアップも必要ありません。代わりに、直接暗号化オプションを使用して暗号ディスクと名前付きデバイスのマッピングを作成します。パーティションやデバイス全体に対してマッピングを作成できます。後者の場合、パーティションテーブルも不要です。

cryptsetup のデフォルトパラメータを使って ''plain'' のマッピングを作成するには:

# cryptsetup open --type plain ''options'' ''device'' ''dmname''

実行するとパスワードを求められます。非常に高いエントロピーのパスワードが必要です。デフォルトではありませんが、 {{ic|--verify-passphrase}} オプションを使えます。

一般論として、作成時の暗号化オプションは精確に記録しておくと良いでしょう。暗号化されたデバイス上にはオプションの内容は記録されていませんし、デフォルトのオプションは変わる可能性があります。

以下は [[Dm-crypt/システム全体の暗号化#Plain dm-crypt]] の例とデフォルトパラメータの比較表です。

{| class="wikitable"
! オプション !! Cryptsetup (2.7.0) のデフォルト !! 例 !! コメント !!
|-
| '''--hash, -h''' || {{ic|sha256}} || - || パスフレーズからキーを作成するのに使用するハッシュ。キーファイルを用いる場合は使われない。
|-
| '''--cipher, -c'''|| {{ic|aes-xts-plain64}}|| {{ic|aes-xts-plain64}} || 暗号は3つの文字列からなります: cipher-chainmode-IV generator。[[ディスク暗号化#暗号と利用形態]]や [https://gitlab.com/cryptsetup/cryptsetup/wikis/DMCrypt DMCrypt のドキュメント] を見てください。
|-
| '''--key-size, -s'''||{{ic|256}}||{{ic|512}}||キーサイズ (ビット数)。サイズは使用する暗号や使用するチェインモードによって変わります。XTS モードは CBC モードの2倍のキーサイズを必要とします。
|-
| '''--size, -b'''||対象ディスクの実際のサイズ||- (デフォルト)||512バイト単位のセクタ数。デバイスの最大サイズ以下。
|-
| '''--offset, -o'''||{{ic|0}}||{{ic|0}}||マッピングを開始するディスクの先頭からのオフセット。512バイト単位のセクタ数。
|-
| '''--skip, -p'''||{{ic|0}}||{{ic|2048}} (512B×2048=1MiB をスキップ)||初期ベクトル (IV) を計算する際にスキップする暗号化されたデータのサイズ。512バイト単位のセクタ数。
|-
| '''--key-file, -d'''||デフォルトではパスフレーズを使用||{{ic|/dev/sd''Z''}} (もしくは {{ic|/boot/keyfile.enc}})||キーとして使用するデバイスまたはファイル。詳しくは [[#キーファイル]] を参照。
|-
| '''--keyfile-offset'''||{{ic|0}}||{{ic|0}}||キーファイルの先頭からのオフセット (バイト数)。''cryptsetup'' 1.6.7 以上でサポートされているオプション。
|-
| '''--keyfile-size, -l'''||{{ic|8192kB}}||- (デフォルト)||キーファイルから読み込まれるバイト数を制限。''cryptsetup'' 1.6.7 以上でサポートされているオプション。
|-
| '''--sector-size, -l'''||{{ic|512}}||{{ic|4096}}||ディスク暗号化の際に使われるセクタサイズ。4Kn のブロックデバイス以外では、 {{ic|512}} がデフォルト。最近のストレージデバイスのほとんどでは、セクタサイズを 512 バイトから 4096 バイトにすることでパフォーマンスが向上します。[[アドバンスドフォーマット#dm-crypt]]を見て下さい。
|}

{{ic|/dev/sd''X''}} デバイスで、上記の例を使用する場合:

# cryptsetup open --type plain --cipher=aes-xts-plain64 --offset=0 --skip=2048 --key-file=/dev/sd''Z'' --key-size=512 --sector-size 4096 /dev/sdX enc

{{Warning|LUKS による暗号化と違って、上記のコマンドはマッピングを再現するために毎回 '''全て''' 指定する必要があります。暗号やハッシュ、キーファイルについて覚えておく必要があります。cryptsetup のデフォルトはバージョンによって変わるので、デフォルトに頼らないで下さい。}}

マッピングが作成されたことは以下のコマンドで確認できます:
# fdisk -l
{{ic|/dev/mapper/enc}} のエントリが存在しているはずです。

== cryptsetup でデバイスを暗号化 ==
以下のセクションでは新しい暗号化ブロックデバイスを作成するオプションと手動のアクセス方法を説明します。

{{Warning|GRUB の LUKS2 サポートは限られています。[[GRUB#暗号化された /boot]] を見て下さい。GRUB が解錠する必要のあるパーティションには、LUKS2 を PBKDF2 で使用 ({{ic|cryptsetup luksFormat --pbkdf pbkdf2}})して下さい。}}

=== LUKS モードでデバイスを暗号化 ===
==== LUKS パーティションのフォーマット ====

暗号化 LUKS パーティションとして設定するには次を実行:

# cryptsetup luksFormat ''device''

上記のコマンドを実行するとパスワードの入力が要求されます。

コマンドラインオプションは [[#LUKS モードの暗号化オプション]]を参照。

結果は次のコマンドで確認できます:

# cryptsetup luksDump ''device''

ダンプでは暗号のヘッダー情報だけでなく、LUKS パーティションで使われるキースロットもわかります。

以下の例はデフォルトの AES 暗号を使って256ビットの XTS モードで {{ic|/dev/sda1}} に暗号化したルートパーティションを作成します:
# cryptsetup luksFormat -s 512 /dev/sda1

=====LUKS を使ってキーファイルでパーティションをフォーマット=====

LUKS による暗号化パーティションを新しく作成する場合、以下のように作成するときにパーティションにキーファイルを関連付けることができます:

# cryptsetup luksFormat ''device'' ''/path/to/mykeyfile''

キーファイルを作成・管理する方法は [[#キーファイル]] を見て下さい。

====デバイスマッパーで LUKS パーティションのロックを解除・マップ====

LUKS パーティションを作成したら、解錠することができます。

解錠ではデバイスマッパーによってパーティションが新しいデバイス名にマッピングされます。カーネルは {{ic|''device''}} が暗号化デバイスであり暗号化データを上書きしないように {{ic|/dev/mapper/''dm_name''}} を使って LUKS 経由で解決する必要があることを知ります。間違って上書きしないために、設定が完了したら[[#バックアップとリストア|暗号化ヘッダーをバックアップ]]する方法を確認してください。

暗号化された LUKS パーティションを開くには次のコマンドを実行:

# cryptsetup open --type luks ''device'' ''dm_name''

実行するとパーティションを解錠するパスワードの入力が求められます。通常、マッピングするデバイスの名前はパーティションの機能が分かりやすいものにします。例えば、以下のコマンドは luks パーティション {{ic|/dev/sda1}} を解錠して {{ic|cryptroot}} という名前のデバイスマッパーにマッピングします:

# cryptsetup open --type luks /dev/sda1 cryptroot

パーティションをオープンしたら、ルートパーティションのデバイスアドレスはパーティション本体 (例: {{ic|/dev/sda1}}) の代わりに {{ic|/dev/mapper/cryptroot}} が使われます。

暗号化レイヤーの上に LVM をセットアップする場合、復号化したボリュームグループのデバイスファイルは {{ic|/dev/sda1}} ではなく {{ic|/dev/mapper/cryptroot}} などとなります。それから LVM は作成されている論理ボリューム全てに名前を割り当てます (例: {{ic|/dev/mapper/lvmpool-root}} や {{ic|/dev/mapper/lvmpool-swap}})。

暗号化データをパーティションに書き込むときは、マッピングされたデバイス名を使ってアクセスする必要があります。例えば[[ファイルシステム#デバイスのフォーマット|ファイルシステムを作成]]するときは以下のようにします:

# mkfs -t ext4 /dev/mapper/cryptroot

{{ic|/dev/mapper/cryptroot}} デバイスは他のパーティションと同じように[[マウント]]できます。

luks コンテナを閉じるには、パーティションをアンマウントし、以下を実行して下さい:

# cryptsetup close cryptroot

==== 鍵を TPM に保管する ====

[[Trusted Platform Module#LUKS による保存データの暗号化]]を見て下さい。

=== plain モードでデバイスを暗号化 ===

''dm-crypt'' プレーンモード暗号化の作成とその後のアクセスはどちらも、正しい [[#plain モードの暗号化オプション|オプション]] を指定して ''cryptsetup'' {{ic|open}} アクションを使用するだけで済みます。以下は、非ルートデバイスの2つの例で示していますが、両方をスタックすることで癖が追加されています (つまり、2番目は最初のデバイス内に作成されます) 明らかに、暗号化をスタックするとオーバーヘッドが2倍になります。ここでの使用例は、暗号オプションの使用法の別の例を説明するためのものです。

上記の表の左側の列で説明されているように、最初のマッパーは ''cryptsetup'' のプレーンモードのデフォルトで作成されます。
{{hc|# cryptsetup --type plain -v open /dev/sdaX plain1|
WARNING: Using default options for cipher (aes-xts-plain64, key size 256 bits) that could be incompatible with older versions.
WARNING: Using default options for hash (sha256) that could be incompatible with older versions.
For plain mode, always use options --cipher, --key-size and if no keyfile is used, then also --hash.
Enter passphrase for /dev/sd''xY'':
Command successful.
}}
次に、さまざまな暗号化パラメーターを使用し、(オプションの) オフセットを使用して、その中に2番目のブロックデバイスを追加し、ファイルシステムを作成してマウントします。
{{hc|1=# cryptsetup --type plain --cipher=serpent-xts-plain64 --hash=sha256 --key-size=256 --offset=10 open /dev/mapper/plain1 plain2|2=
Enter passphrase for /dev/mapper/plain1:
}}
{{hc|# lsblk -p|
NAME
/dev/sda
├─/dev/sdaX
│ └─/dev/mapper/plain1
│ └─/dev/mapper/plain2
...
}}
# mkfs -t ext2 /dev/mapper/plain2
# mount -t ext2 /dev/mapper/plain2 /mnt
# echo "This is stacked. one passphrase per foot to shoot." > /mnt/stacked.txt
We close the stack to check access works
# cryptsetup close plain2
# cryptsetup close plain1
First, let's try to open the filesystem directly:
# cryptsetup --type plain --cipher=serpent-xts-plain64 --hash=sha256 --key-size=256 --offset=10 open /dev/sdaX plain2
{{hc|# mount -t ext2 /dev/mapper/plain2 /mnt|
mount: wrong fs type, bad option, bad superblock on /dev/mapper/plain2,
missing codepage or helper program, or other error
}}
Why that did not work? Because the "plain2" starting block ({{ic|10}}) is still encrypted with the cipher from "plain1". It can only be accessed via the stacked mapper. The error is arbitrary though, trying a wrong passphrase or wrong options will yield the same. For ''dm-crypt'' plain mode, the {{ic|open}} action will not error out itself.

Trying again in correct order:
# cryptsetup close plain2 # dysfunctional mapper from previous try
{{hc|# cryptsetup --type plain open /dev/sdaX plain1|
Enter passphrase:
}}
{{hc|1=# cryptsetup --type plain --cipher=serpent-xts-plain64 --hash=sha256 --key-size=256 --offset=10 open /dev/mapper/plain1 plain2|2=
Enter passphrase:
}}
{{hc|# mount /dev/mapper/plain2 /mnt && cat /mnt/stacked.txt|
This is stacked. one passphrase per foot to shoot.
}}
# exit
''dm-crypt'' will handle stacked encryption with some mixed modes too. For example LUKS mode could be stacked on the "plain1" mapper. Its header would then be encrypted inside "plain1" when that is closed.

Available for plain mode only is the option {{ic|--shared}}. With it a single device can be segmented into different non-overlapping mappers. We do that in the next example, using a ''loopaes'' compatible cipher mode for "plain2" this time:
{{hc|# cryptsetup --type plain --offset 0 --size 1000 open /dev/sdaX plain1|2=
Enter passphrase:
}}
{{hc|1=# cryptsetup --type plain --offset 1000 --size 1000 --shared --cipher=aes-cbc-lmk --hash=sha256 open /dev/sdaX plain2|2=
Enter passphrase:
}}
{{hc|# lsblk -p|
NAME
dev/sdaX
├─/dev/sdaX
│ ├─/dev/mapper/plain1
│ └─/dev/mapper/plain2
...
}}
As the devicetree shows both reside on the same level, i.e. are not stacked and "plain2" can be opened individually.

== LUKS 固有の Cryptsetup のアクション ==
=== キーの管理 ===
LUKS パーティションには異なる8つまでのキーを定義することができます。バックアップストレージのためのアクセスキーを作成することが可能です。いわゆるキーエスクローで、あるキーは日常的に使用するために使い、他のキーはエスクローに保存して日常用のパスフレーズを忘れたときやキーファイルを喪失・破損したときにパーティションにアクセスするために使います。また、別のキースロットを使って一時的なキーを発行してユーザーにパーティションへのアクセスを許可し、後でキーを無効化したりできます。

暗号化パーティションを作成すると、初期キースロット 0 が作成されます (手動で別の数字を指定しなかった場合)。追加キースロットは 1 から 7 までの数字が割り振られます。どのキースロットを使用しているかは以下のコマンドで確認できます (<device> は LUKS ヘッダーが存在するボリュームに置き換えてください):
{{hc|# cryptsetup luksDump /dev/<device> {{!}} grep BLED|
Key Slot 0: ENABLED
Key Slot 1: ENABLED
Key Slot 2: ENABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED}}

上記のコマンドや下で説明しているコマンドはヘッダーのバックアップファイルでも使えます。

==== LUKS キーの追加 ====

新しいキースロットの追加は cryptsetup の {{ic|luksAddKey}} アクションを使うことでできます。デバイスが解錠されていても安全のために、新しいキーを入力する前に、必ず既存のキーの入力が求められます ("any passphrase"):

{{hc|# cryptsetup luksAddKey /dev/<device> (/path/to/<additionalkeyfile>)|
Enter any passphrase:
Enter new passphrase for key slot:
Verify passphrase:
}}

{{ic|/path/to/<additionalkeyfile>}} を指定した場合、cryptsetup は <additionalkeyfile> の新しいキースロットを追加します。指定しなかった場合は新しいパスフレーズの入力が2回要求されます。既存の''キーファイル''を使って認証するには、{{ic|--key-file}} または {{ic|-d}} オプションの後に"既存"の <keyfile> を指定することで全てのキーファイルのキースロットが解除されます:

# cryptsetup luksAddKey /dev/<device> (/path/to/<additionalkeyfile>) -d /path/to/<keyfile>

複数のキーを使っていてキーを変更・無効化する場合、{{ic|--key-slot}} または {{ic|-S}} オプションでスロットを指定できます:
{{hc|# cryptsetup luksAddKey /dev/<device> -S 6|
Enter any passphrase:
Enter new passphrase for key slot:
Verify passphrase:
}}
{{hc|# cryptsetup luksDump /dev/sda8 {{!}} grep 'Slot 6'|
Key Slot 6: ENABLED
}}

例えばキーを変更したい場合:
{{hc|# cryptsetup luksChangeKey /dev/<device> -S 6|
Enter LUKS passphrase to be changed:
Enter new LUKS passphrase:
}}

==== LUKS キーの削除 ====

ヘッダーからキーを削除するアクションは3つ存在します:
*{{ic|luksRemoveKey}} はパスフレーズやキーファイルを指定してキーを削除します。
*{{ic|luksKillSlot}} は (他のキーを使って) 指定したキースロットからキーを削除します。パスフレーズを忘れたり、キーファイルを無くしたり、誰もアクセスできないようにしたい場合に有用です。
*{{ic|luksErase}} は全ての有効なキーを即座に削除します。
{{warning|
*All above actions can be used to irrevocably delete the last active key for an encrypted device!
*The {{ic|luksErase}} command was added in version 1.6.4 to quickly nuke access to the device. This action '''will not''' prompt for a valid passphrase! It will not [[Dm-crypt/ドライブの準備#LUKS ヘッダーを消去|wipe the LUKS header]], but all keyslots at once and you will, therefore, not be able to regain access unless you have a valid backup of the LUKS header.}}

For above warning it is good to know the key we want to '''keep''' is valid. An easy check is to unlock the device with the {{ic|-v}} option, which will specify which slot it occupies:
{{hc|# cryptsetup -v open /dev/<device> testcrypt|
Enter passphrase for /dev/<device>:
Key slot 1 unlocked.
Command successful.}}

Now we can remove the key added in the previous subsection using its passphrase:
{{hc|# cryptsetup luksRemoveKey /dev/<device>|
Enter LUKS passphrase to be deleted:
}}
If we had used the same passphrase for two keyslots, the first slot would be wiped now. Only executing it again would remove the second one.

Alternatively, we can specify the key slot:
{{hc|# cryptsetup luksKillSlot /dev/<device> 6|
Enter any remaining LUKS passphrase:
}}

Note that in both cases, no confirmation was required.
{{hc|# cryptsetup luksDump /dev/sda8 {{!}} grep 'Slot 6'|
Key Slot 6: DISABLED
}}
To re-iterate the warning above: If the same passphrase had been used for key slots 1 and 6, both would be gone now.

=== バックアップとリストア ===
If the header of a LUKS encrypted partition gets destroyed, you will not be able to decrypt your data. It is just as much of a dilemma as forgetting the passphrase or damaging a key-file used to unlock the partition. Damage may occur by your own fault while re-partitioning the disk later or by third-party programs misinterpreting the partition table. Therefore, having a backup of the header and storing it on another disk might be a good idea.

{{Note|If the LUKS-encrypted partitions' master passphrase becomes compromised, you must revoke it on ''every'' copy of the cryptheader, even those you have backed up. Otherwise, a copy of the backed-up cryptheader that uses the compromised passphrase can be used to decrypt the associated partition. See [https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#6-backup-and-data-recovery LUKS FAQ] for further details.}}

==== cryptsetup を使ってバックアップ ====
Cryptsetup's {{ic|luksHeaderBackup}} action stores a binary backup of the LUKS header and keyslot area:
# cryptsetup luksHeaderBackup /dev/<device> --header-backup-file /mnt/<backup>/<file>.img
where <device> is the partition containing the LUKS volume.

{{Tip|You can also back up the plaintext header into ramfs and encrypt it in example with gpg before writing to persistent backup storage by executing the following commands.}}
# mkdir /root/<tmp>/
# mount ramfs /root/<tmp>/ -t ramfs
# cryptsetup luksHeaderBackup /dev/<device> --header-backup-file /root/<tmp>/<file>.img
# gpg2 --recipient <User ID> --encrypt /root/<tmp>/<file>.img
# cp /root/<tmp>/<file>.img.gpg /mnt/<backup>/
# umount /root/<tmp>
{{Warning|Tmpfs can swap to harddisk if low on memory so it is not recommended here.}}

==== cryptsetup を使ってリストア ====

{{Warning|Restoring the wrong header or restoring to an unencrypted partition will cause data loss! The action can not perform a check whether the header is actually the ''correct'' one for that particular device.}}

In order to evade restoring a wrong header, you can ensure it does work by using it as a remote {{ic|--header}} first:

{{hc|# cryptsetup -v --header /mnt/<backup>/<file>.img open /dev/<device> test|
Key slot 0 unlocked.
Command successful.
}}
# mount /dev/mapper/test /mnt/test && ls /mnt/test
# umount /mnt/test
# cryptsetup close test

Now that the check succeeded, the restore may be performed:
# cryptsetup luksHeaderRestore /dev/<device> --header-backup-file ./mnt/<backup>/<file>.img

Now that all the keyslot areas are overwritten; only active keyslots from the backup file are available after issuing the command.

==== 手動バックアップとリストア ====
The header always resides at the beginning of the device and a backup can be performed without access to ''cryptsetup'' as well. First you have to find out the payload offset of the crypted partition:
{{hc|# cryptsetup luksDump /dev/<device> {{!}} grep "Payload offset"|
Payload offset: 4040}}
Second check the sector size of the drive
{{hc|# fdisk -l /dev/<device> {{!}} grep "Sector size"|Sector size (logical/physical): 512 bytes / 512 bytes}}

Now that you know the values, you can backup the header with a simple dd command:
# dd if=/dev/<device> of=/path/to/<file>.img bs=512 count=4040
and store it safely.

A restore can then be performed using the same values as when backing up:
# dd if=./<file>.img of=/dev/<device> bs=512 count=4040

=== デバイスの再暗号化 ===

The {{Pkg|cryptsetup}} package features the ''cryptsetup-reencrypt'' tool. It can be used to convert an existing unencrypted filesystem to a LUKS encrypted one (option {{ic|--new}}) and permanently remove LUKS encryption ({{ic|--decrypt}}) from a device. As its name suggests it can also be used to re-encrypt an existing LUKS encrypted device, though, re-encryption is not possible for a detached LUKS header or other encryption modes (e.g. plain-mode). For re-encryption it is possible to change the [[#LUKS モードの暗号化オプション]]. ''cryptsetup-reencrypt'' actions can be performed to unmounted devices only. See {{man|8|cryptsetup-reencrypt}} for more information.

One application of re-encryption may be to secure the data again after a passphrase or [[#キーファイル|keyfile]] has been compromised ''and'' one cannot be certain that no copy of the LUKS header has been obtained. For example, if only a passphrase has been shoulder-surfed but no physical/logical access to the device happened, it would be enough to change the respective passphrase/key only ([[#Key management]]).

{{Warning|Always make sure a '''reliable backup''' is available and double-check options you specify before using the tool!}}

The following shows an example to encrypt an unencrypted filesystem partition and a re-encryption of an existing LUKS device.

==== 暗号化されていないファイルシステムの暗号化 ====

A LUKS encryption header is always stored at the beginning of the device. Since an existing filesystem will usually be allocated all partition sectors, the first step is to shrink it to make space for the LUKS header.

The [[#LUKS モードの暗号化オプション|default]] LUKS header encryption cipher requires {{ic|4096}} 512-byte sectors. We already checked space and keep it simple by shrinking the existing {{ic|ext4}} filesystem on {{ic|/dev/sdaX}} to its current possible minimum:

# umount /mnt
{{hc|# e2fsck -f /dev/sdaX|
e2fsck 1.43-WIP (18-May-2015)
Pass 1: Checking inodes, blocks, and sizes
...
/dev/sda6: 12/166320 files (0.0% non-contiguous), 28783/665062 blocks
}}
{{hc|# resize2fs -M /dev/sdaX|
resize2fs 1.43-WIP (18-May-2015)
Resizing the filesystem on /dev/sdaX to 26347 (4k) blocks.
The filesystem on /dev/sdaX is now 26347 (4k) blocks long.}}

Now we encrypt it, using the default cipher we do not have to specify it explicitly. Note there is no option (yet) to double-check the passphrase before encryption starts, be careful not to mistype:

{{hc|# cryptsetup-reencrypt /dev/sdaX --new --reduce-device-size 4096S|
WARNING: this is experimental code, it can completely break your data.
Enter new passphrase:
Progress: 100,0%, ETA 00:00, 2596 MiB written, speed 37,6 MiB/s}}

After it finished, the encryption was performed to the full partition, i.e. not only the space the filesystem was shrunk to ({{ic|sdaX}} has {{ic|2.6GiB}} and the CPU used in the example has no hardware AES instructions). As a final step we extend the filesystem of the now encrypted device again to occupy available space:

{{hc|# cryptsetup open /dev/sdaX recrypt|
Enter passphrase for /dev/sdaX:
...
}}
{{hc|# resize2fs /dev/mapper/recrypt|
resize2fs 1.43-WIP (18-May-2015)
Resizing the filesystem on /dev/mapper/recrypt to 664807 (4k) blocks.
The filesystem on /dev/mapper/recrypt is now 664807 (4k) blocks long.}}
# mount /dev/mapper/recrypt /mnt

and are done.

==== 既存の LUKS パーティションの再暗号化 ====

以下の例では既存の LUKS デバイスを最暗号化しています。

{{Warning|Double-check you specify encryption options for ''cryptsetup-reencrypt'' correctly and ''never'' re-encrypt without a '''reliable backup'''! As of September 2015 the tool '''does''' accept invalid options and damage the LUKS header, if not used correctly!}}

In order to re-encrypt a device with its existing encryption options, they do not need to be specified. A simple:

{{hc|# cryptsetup-reencrypt /dev/sdaX|
WARNING: this is experimental code, it can completely break your data.
Enter passphrase for key slot 0:
Progress: 100,0%, ETA 00:00, 2596 MiB written, speed 36,5 MiB/s}}

performs it.

A possible usecase is to re-encrypt LUKS devices which have non-current encryption options. Apart from above warning on specifying options correctly, the ability to change the LUKS header may also be limited by its size. For example, if the device was initially encrypted using a CBC mode cipher and 128 bit key-size, the LUKS header will be half the size of above mentioned {{ic|4096}} sectors:
{{hc|# cryptsetup luksDump /dev/sdaX <nowiki>|</nowiki>grep -e "mode" -e "Payload" -e "MK bits"|
Cipher mode: cbc-essiv:sha256
Payload offset: '''2048'''
MK bits: 128}}
While it is possible to upgrade the encryption of such a device, it is currently only feasible in two steps. First, re-encrypting with the same encryption options, but using the {{ic|--reduce-device-size}} option to make further space for the larger LUKS header. Second, re-encypt the whole device again with the desired cipher. For this reason and the fact that a backup should be created in any case, creating a new, fresh encrypted device to restore into is always the faster option.

== 暗号化デバイスのリサイズ ==

If a storage device encrypted with dm-crypt is being cloned (with a tool like dd) to another larger device, the underlying dm-crypt device must be resized to use the whole space.

The destination device is /dev/sdX2 in this example, the whole available space adjacent to the partition will be used:

# cryptsetup luksOpen /dev/sdX2 sdX2
# cryptsetup resize sdX2

Then the underlying filesystem must be resized.

=== ループバックファイルシステム ===

暗号化したループバックデバイスを {{ic|/mnt/secret}} にマウントしている場合、例えば [[Dm-crypt/root 以外のファイルシステムの暗号化#Loop デバイス]] に従っている場合、最初に暗号化コンテナをアンマウント:
# umount /mnt/secret
# cryptsetup close secret
# losetup -d /dev/loop0

次に、追加したいデータ容量を決めてコンテナファイルを拡張します:

{{Warning|{{ic|>}} を2つ使っていることに注意してください。1つだけだと現在のコンテナを上書きしてしまいます。}}
# dd if=/dev/urandom bs=1M count=1024 | cat - >> /bigsecret

ループデバイスにコンテナをマップ:
# losetup /dev/loop0 /bigsecret
# cryptsetup --type luks open /dev/loop0 secret

その後、コンテナの暗号化された部分をコンテナファイルの最大サイズまでリサイズ:
# cryptsetup resize secret

最後に、ファイルシステムのチェックを実行して、問題なければ、リサイズを行います (例: ext2/3/4):
# e2fsck -f /dev/mapper/secret
# resize2fs /dev/mapper/secret

またコンテナをマウントすることができます:
# mount /dev/mapper/secret /mnt/secret

== キーファイル ==

{{Note|このセクションでは平文のキーファイルを使う方法を説明しています。キーファイルを暗号化して二段階認証したい場合は[[Dm-crypt/特記事項#GPG や OpenSSL で暗号化されたキーファイルを使う|GPG や OpenSSL で暗号化されたキーファイルを使う]]を見て下さい。ただし、このセクションもあらかじめ読むようにしてください。}}

'''キーファイルとは？'''

キーファイルは暗号化されたボリュームを解錠するパスフレーズとして使用するデータを含んだファイルです。ファイルを喪失した場合、ボリュームの復号化はできなくなります。

{{Tip|Define a passphrase in addition to the keyfile for backup access to encrypted volumes in the event the defined keyfile is lost or changed.}}

'''なぜキーファイルを使うのか？'''

キーファイルには様々なタイプがあります。以下で説明しているようにそれぞれメリットとデメリットが存在します:

=== キーファイルのタイプ ===
==== passphrase ====

単にパスフレーズが記述されたキーファイルです。メリットはファイルを無くしても暗号化ボリュームの所有者が簡単に中身を思い出せることです。デメリットはパスフレーズの入力と比べてセキュリティ上の優位点がないことです。

例: {{ic|1234}}。

{{Note|パスフレーズが記述されたキーファイルに改行を含めてはいけません。以下のようなコマンドでファイルを作成できます:
# echo -n 'your_passphrase' > /path/to/<keyfile>
# chown root:root /path/to/<keyfile>; chmod 400 /path/to/<keyfile>
}}

==== randomtext ====

This is a keyfile containing a block of random characters. The benefit of this type of keyfile is that it is much more resistant to dictionary attacks than a simple passphrase. An additional strength of keyfiles can be utilized in this situation which is the length of data used. Since this is not a string meant to be memorized by a person for entry, it is trivial to create files containing thousands of random characters as the key. The disadvantage is that if this file is lost or changed, it will most likely not be possible to access the encrypted volume without a backup passphrase.

例: {{ic|fjqweifj830149-57 819y4my1-38t1934yt8-91m 34co3;t8y;9p3y-}}。

==== binary ====

This is a binary file that has been defined as a keyfile. When identifying files as candidates for a keyfile, it is recommended to choose files that are relatively static such as photos, music, video clips. The benefit of these files is that they serve a dual function which can make them harder to identify as keyfiles. Instead of having a text file with a large amount of random text, the keyfile would look like a regular image file or music clip to the casual observer. The disadvantage is that if this file is lost or changed, it will most likely not be possible to access the encrypted volume without a backup passphrase. Additionally, there is a theoretical loss of randomness when compared to a randomly generated text file. This is due to the fact that images, videos and music have some intrinsic relationship between neighboring bits of data that does not exist for a text file. However this is controversial and has never been exploited publicly.

例: 画像, テキスト, 動画。

=== ランダムな文字列でキーファイルを作成 ===

==== ファイルシステムにキーファイルを保存 ====

キーファイルの中身とサイズは任意に決められます。

以下では {{ic|dd}} を使って2048バイトのランダムなキーファイルを生成して、{{ic|/etc/mykeyfile}} ファイルに保存します:

# dd bs=512 count=4 if=/dev/urandom of=/etc/mykeyfile

キーファイルを外部デバイスに保存する場合、出力先を適切なディレクトリに変更します:

# dd bs=512 count=4 if=/dev/urandom of=/media/usbstick/mykeyfile

===== 保存されたキーファイルを完全に消去 =====

物理的なストレージデバイスに一時的なキーファイルを保存する場合、削除するときは、以下のように完全に削除してください:

# shred --remove --zero mykeyfile

FAT や ext2 であれば上記で十分ですが、ジャーナリングファイルシステムやフラッシュメモリハードウェアの場合、[[ディスクの完全消去]]あるいはキーファイルのあるパーティションを削除することを強く推奨します。

==== ramfs にキーファイルを保存 ====

もしくは、ramfs をマウントしてキーファイルを一時的に保存:

# mkdir /root/myramfs
# mount ramfs /root/myramfs/ -t ramfs
# cd /root/myramfs

物理ディスクではなくメモリ上に配置することで、ramfs をアンマウントしたら復元できないという利点があります。キーファイルを他の安全なファイルシステムにコピーしたら、以下のコマンドで ramfs をアンマウントしてください:
# umount /root/myramfs

=== キーファイルを使用するように LUKS を設定 ===

キーファイルのキースロットを LUKS ヘッダに追加:

{{hc|# cryptsetup luksAddKey /dev/sda2 /etc/mykeyfile|
Enter any LUKS passphrase:
key slot 0 unlocked.
Command successful.}}

=== キーファイルを使ってパーティションを手動でアンロック ===

LUKS デバイスをオープンするときに {{ic|--key-file}} オプションを使ってください:

# cryptsetup open /dev/sda2 ''dm_name'' --key-file /etc/mykeyfile

=== 起動時にロックを解除 ===

ファイルシステムのキーファイルを暗号化されたルートディレクトリの中に保存することで、システムの電源が切れているときに安全を確保することができ、[[Dm-crypt/システム設定#crypttab|crypttab]] によって起動時に自動的にマウントを解錠することができます。[[UUID]] を使用する例:
{{hc|/etc/crypttab|<nowiki>home UUID=<UUID identifier> /etc/mykeyfile</nowiki>}}
is all needed for unlocking, and
{{hc|/etc/fstab|/dev/mapper/home /home ext4 defaults 0 2}} for mounting the LUKS blockdevice with the generated keyfile.
{{Tip|If you prefer to use a {{ic|--plain}} mode blockdevice, the encryption options necessary to unlock it are specified in {{ic|/etc/crypttab}}. Take care to apply the systemd workaround mentioned in [[Dm-crypt/システム設定#crypttab|crypttab]] in this case.}}

=== キーファイルを使って起動時に root パーティションのロックを解除 ===

[[mkinitcpio]] を設定して必要なモジュールやファイルを記述して [[Dm-crypt/システム設定#cryptkey|cryptkey]] [[カーネルパラメータ]]を設定してキーファイルの場所を指定します。

2つの方法が存在します:

# 外部メディア (USB スティック) にキーファイルを保存
# initramfs にキーファイルを埋め込む

==== キーファイルを外部メディアに保存 ====

===== mkinitcpio の設定 =====

ドライブのファイルシステムを使うために {{ic|/etc/mkinitcpio.conf}} にモジュールを追加してください (以下の例では {{ic|vfat}} モジュール):
MODULES=(vfat)

In this example it is assumed that you use a FAT formatted USB drive ({{ic|vfat}} module). Replace those module names if you use another file system on your USB stick (e.g. {{ic|ext2}}) or another codepage. If it complains of bad superblock and bad codepage at boot, then you need an extra codepage module to be loaded. For instance, you may need {{ic|nls_iso8859-1}} module for {{ic|iso8859-1}} codepage.

If you have a non-US keyboard, it might prove useful to load your keyboard layout before you are prompted to enter the password to unlock the root partition at boot. For this, you will need the {{ic|keymap}} hook before {{ic|encrypt}}.

Generate a new initramfs image:

# mkinitcpio -p linux

===== カーネルパラメータの設定 =====

以下のオプションを[[カーネルパラメータ]]に追加してください ({{ic|encrypt}} フックではなく {{ic|sd-encrypt}} フックを使用する場合は [[Dm-crypt/システム設定#sd-encrypt フックを使う]]を参照):

cryptdevice=/dev/''<partition1>'':root cryptkey=/dev/''<partition2>'':<fstype>:<path>

例:

cryptdevice=/dev/sda3:root cryptkey=/dev/sdb1:vfat:/keys/secretkey

Choosing a plain filename for your key provides a bit of 'security through obscurity'. The keyfile can not be a hidden file, that means the filename must not start with a dot, or the {{ic|encrypt}} hook will fail to find the keyfile during the boot process.

{{ic|/dev/sdb1}} のようなデバイスノードの名前は再起動しても同じであるとは保証されていません。udev による[[永続的なブロックデバイスの命名]]を使ったほうが確実にデバイスにアクセスできます。外部ストレージデバイスからキーファイルを読み取るときに {{ic|encrypt}} フックが確実にキーファイルを見つけられるように、永続的なブロックデバイスの名前を絶対に使うべきです。[[永続的なブロックデバイスの命名]]を見て下さい。

==== キーファイルを initramfs に埋め込む ====

{{Warning|Use an embedded keyfile '''only''' if you have some form of authentication mechanism beforehand that protects the keyfile sufficiently. Otherwise auto-decryption will occur, defeating completely the purpose of block device encryption.}}

This method allows to use a specially named keyfile that will be embedded in the [[initramfs]] and picked up by the {{ic|encrypt}} [[Mkinitcpio#HOOKS|hook]] to unlock the root filesystem ({{ic|cryptdevice}}) automatically. It may be useful to apply when using the [[GRUB#暗号化された /boot|GRUB early cryptodisk]] feature, in order to avoid entering two passphrases during boot.

The {{ic|encrypt}} hook lets the user specify a keyfile with the {{ic|cryptkey}} kernel parameter: in the case of initramfs, the syntax is {{ic|rootfs:''path''}}, see [[Dm-crypt/システム設定#cryptkey]]. Besides, this kernel parameter defaults to use {{ic|/crypto_keyfile.bin}}, and if the initramfs contains a valid key with this name, decryption will occur automatically without the need to configure the {{ic|cryptkey}} parameter.

{{ic|encrypt}} の代わりに {{ic|sd-encrypt}} を使用する場合、{{ic|luks.key}} カーネルパラメータでキーファイルの場所を指定してください。[[Dm-crypt/システム設定#luks.key]] を参照。

[[#ランダムな文字列でキーファイルを作成|キーファイルを生成]]して適切な権限を与えて [[#LUKS キーの追加|LUKS キーとして追加]]:

# dd bs=512 count=4 if=/dev/urandom of=/crypto_keyfile.bin
# chmod 000 /crypto_keyfile.bin
# chmod 600 /boot/initramfs-linux*
# cryptsetup luksAddKey /dev/sdX# /crypto_keyfile.bin

{{Warning|When initramfs' permissions are set to 644 (by default), then all users will be able to dump the keyfile. Make sure the permissions are still 600 if you install a new kernel.}}

[[Mkinitcpio#BINARIES_と_FILES|mkinitcpio の FILES]] にキーを記述:

{{hc|/etc/mkinitcpio.conf|2=FILES=(/crypto_keyfile.bin)}}

最後に [[Mkinitcpio#イメージ作成とアクティベーション|initramfs を再生成]]してください。

次の起動時からコンテナを復号化するパスフレーズを入力するのは一度だけですむようになります。

詳しくは [http://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/#bonus-login-once こちら] を参照。

Dm-crypt/デバイスの暗号化

2025-03-09T18:23:21Z

Takemaro: /* dm-crypt の暗号化オプション */ 英語版を反映: LUKS2の追加、オプションの追加、イテレーション時間の記述の追加、等

{{Lowercase title}}
[[Category:保存データ暗号化]]
[[Category:ファイルシステム]]
[[en:Dm-crypt/Device encryption]]
このセクションではコマンドラインから ''dm-crypt'' を利用して手動でシステムを暗号化する方法を説明しています。

== 準備 ==
{{pkg|cryptsetup}} を使用する前に、{{ic|dm_crypt}} [[カーネルモジュール]]がロードされていることを確認してください。

== Cryptsetup の使用方法 ==
''Cryptsetup'' は暗号化デバイスを作成・管理する ''dm-crypt'' を使うためのコマンドラインツールです。後に Linux カーネルの '''d'''evice-'''m'''apper と '''crypt'''ographic モジュールを使用する別の暗号化もサポートするように拡張されました。最も著しい拡張は Linux Unified Key Setup (LUKS) の拡張で、dm-crypt をセットアップするのに必要な情報を全てディスク自体に保存してパーティションとキーの管理を抽象化することで使いやすさを増しています。device-mapper によってアクセスされるデバイスはブロックデバイスと呼ばれます。詳しくは[[ディスク暗号化#ブロックデバイスの暗号化]]を見て下さい。

ツールは以下のように使います:

# cryptsetup ''action'' ''options'' ''device'' ''dmname''

オプションや暗号化モードにはデフォルト値が存在し、コマンドラインで何も指定しなかった場合はデフォルト値が使われます。オプションや暗号化モードのデフォルトパラメータを確認するには以下のコマンドを実行:

$ cryptsetup --help

オプションの完全なリストは man ページで確認できます。暗号化モードやアクションによって必要なパラメータは変わるため、以下のセクションでは違いについて説明しています。ブロックデバイス暗号化は高速ですが、速度は非常に重要な問題です。ブロックデバイスの暗号を設定後に変更することは難しいため、それぞれのパラメータについて ''dm-crypt'' のパフォーマンスをチェックすると良いでしょう:

$ cryptsetup benchmark

上記のコマンドはインストールするときにアルゴリズムや鍵長を決める手がかりになります。特定の AES 暗号が非常に高速に処理される場合、おそらくその暗号は CPU によるハードウェア支援の恩恵に与かっています。

{{Tip|テストしたいときは[[:カテゴリ:仮想化|仮想マシン]]の仮想ハードドライブで練習すると良いでしょう。}}

=== Cryptsetup のパスフレーズとキー ===
暗号化されたブロックデバイスはキーによって保護されます。キーは以下のいずれかです:

*パスフレーズ、[[セキュリティ#パスワード]]を見て下さい。
*キーファイル、[[#キーファイル]] を見て下さい。

どちらのタイプのキーも最大サイズが決められています: パスフレーズは512文字まで、キーファイルは 8192kB までです。

''LUKS'' の重要な特徴として、キーは LUKS によって暗号化されたデバイスのマスターキーを解除するのに使われ、root 権限で変えることができるということです。他の暗号化モードでは設定後にキーを変更することはできません。暗号化にマスターキーを使わないためです。詳しくは[[ディスク暗号化#ブロックデバイスの暗号化]]を見て下さい。

== dm-crypt の暗号化オプション ==
''Cryptsetup'' は ''dm-crypt'' で使用できる様々な暗号化モードをサポートしています。
* {{ic|--type luks}} - LUKS フォーマットのデフォルトバージョン ({{Pkg|cryptsetup}} < 2.1.0 ではLUKS1、{{Pkg|cryptsetup}} ≥ 2.1.0 では LUKS2) を使用。
* {{ic|--type luks1}} - LUKS の古いバージョンである LUKS1 を使用。
* {{ic|--type luks2}} - LUKS に追加の拡張が導入された現在のバージョンである LUKS2 を使用。
** {{ic|--hw-opal-only}} - TCG OPAL 標準をサポートするドライブでハードウェアベースの暗号化を使用。[[自己暗号化ドライブ]]や {{man|8|cryptsetup|SED (SELF ENCRYPTING DRIVE) OPAL EXTENSION}} も参照して下さい。
** {{ic|--hw-opal}} - OPAL によるハードウェア暗号化と dm-crypt によるソフトウェア暗号化の両方を使用。
*{{ic|--type plain}} - dm-crypt plain モードを使用。
*{{ic|--type loopaes}} - loopaes legacy モードを使用。
*{{ic|--type tcrypt}} - [[Truecrypt]] 互換モードを使用。
* {{ic|--type bitlk}} - [[Wikipedia:ja:BitLocker|BitLocker]] 互換モードを使用。 {{man|8|cryptsetup|BITLK (WINDOWS BITLOCKER COMPATIBLE) EXTENSION}} も参照して下さい。

暗号やハッシュの基本的な暗号化オプションは全てのモードで使うことができ、カーネルの暗号化バックエンド機能を利用します。使用できるオプションは以下のコマンドで確認できます:

$ less /proc/crypto

{{Tip|リストが短い場合、{{ic|cryptsetup benchmark}} を実行すればモジュールのロードが行われます。}}

以下では LUKS モードと plain モードの暗号化オプションを紹介します。記事の中で例として使っているオプションを並べていますが、利用できるオプションの全てではないので注意してください。

=== LUKS モードの暗号化オプション ===
LUKS 暗号化モードで新しい dm-crypt デバイスをセットアップする ''cryptsetup'' のアクションは ''luksFormat'' です。名前にはフォーマットとありますが、実際にはデバイスをフォーマットするのではなく、LUKS デバイスヘッダーを設定して指定された暗号オプションを使ってマスター鍵を暗号化します。

デフォルトパラメータ ({{ic|cryptsetup --help}}で確認できます) で新しい LUKS デバイスを作成する場合、単に以下のコマンドを実行します:

# cryptsetup luksFormat ''device''

cryptsetup 2.4.0 の場合、これは以下と同等です:

# cryptsetup luksFormat --type luks2 --cipher aes-xts-plain64 --hash sha256 --iter-time 2000 --key-size 256 --pbkdf argon2id --use-urandom --verify-passphrase ''device''

以下の表でデフォルト値とサンプルにコメントを付けて説明しています:

{| class="wikitable"
! scope="col" style="text-align:left" | オプション
! scope="col" style="text-align:left" | Cryptsetup 2.1.0 のデフォルト
! scope="col" style="text-align:left" | 例
! scope="col" style="text-align:left" | コメント
|-
! scope="row" style="text-align:right" | --cipher, -c
| {{ic|aes-xts-plain64}}
| {{ic|aes-xts-plain64}}
| [https://www.kernel.org/pub/linux/utils/cryptsetup/v1.6/v1.6.0-ReleaseNotes バージョン 1.6.0]からデフォルトが AES [[ディスク暗号化#暗号と利用形態|暗号]]と [[wikipedia:Disk encryption theory#XEX-based tweaked-codebook mode with ciphertext stealing (XTS)|XTS]] を使用するよう変わりました ([https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#5-security-aspects FAQ] の 5.16 も参照)。以前のデフォルトである {{ic|--cipher aes-cbc-essiv}} は、[[wikipedia:Disk encryption theory#Cipher-block chaining (CBC)|既知の問題]]があり、[https://www.jakoblell.com/blog/2013/12/22/practical-malleability-attack-against-cbc-encrypted-luks-partitions/ 実際の攻撃]も存在するため、使用しないことをお勧めします。
|-
! scope="row" style="text-align:right" | --key-size, -s
| {{ic|256}} (XTSでは {{ic|512}})
| {{ic|512}}
| XTS モードの暗号では 512 ビットがデフォルトです。[[wikipedia:Disk encryption theory#XEX-based tweaked-codebook mode with ciphertext stealing (XTS)|XTS はキーを半分に割る]]ので、これは AES-256 が使われることを意味します。
|-
! scope="row" style="text-align:right" | --hash, -h
| {{ic|sha256}}
| {{ic|sha512}}
| [[ディスク暗号化#暗号メタデータ|鍵導出]] で使用されるハッシュアルゴリズム。リリース 1.7.0 でデフォルト設定が {{ic|sha1}} から {{ic|sha256}} に変更されました。セキュリティ上の理由ではなく SHA1 が使用できないシステムでも動作するようにするためです [https://www.kernel.org/pub/linux/utils/cryptsetup/v1.7/v1.7.0-ReleaseNotes]。{{ic|sha1}} でも十分セキュアであるため古いバージョンの ''cryptsetup'' と互換性を維持する目的で使用できます [https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#5-security-aspects]。
|-
! scope="row" style="text-align:right" | --iter-time, -i
| {{ic|2000}}
| {{ic|5000}}
| PBKDF2 パスフレーズを処理するのに費やす時間 (ミリ秒単位)。"''PBKDF2 の反復回数を高く保持したままユーザーが許容できる数値にするため''"、リリース 1.7.0 からデフォルト値が {{ic|1000}} から {{ic|2000}} に変更されています [https://www.kernel.org/pub/linux/utils/cryptsetup/v1.7/v1.7.0-ReleaseNotes]。''luksFormat'' や ''luksAddKey'' などパスフレーズを設定・変更する LUKS 操作のみに関連するオプションです。パラメータとして 0 を指定するとコンパイル時のデフォルトが選択されます。
|-
! scope="row" style="text-align:right" | --use-{u,}random
| {{ic|--use-'''u'''random}}
| {{ic|--use-random}}
| [[乱数生成|乱数生成器]]の選択。現在は {{ic|/dev/random}} と {{ic|/dev/urandom}} は等価なので、 {{ic|--use-random}} と {{ic|--use-urandom}} も等価です。
|-
! scope="row" style="text-align:right" | --verify-passphrase, -y
| Yes
| -
| {{ic|luksFormat}} と {{ic|luksAddKey}} で使われます。Arch Linux ではデフォルトで有効です。
|-
! scope="row" style="text-align:right" | --sector-size
| {{ic|512}} または {{ic|4096}} (デバイスに依存)
| {{ic|4096}}
| ディスク暗号化で使われるセクタサイズを設定します。デフォルトは、4Kn や 512e のブロックデバイスでは {{ic|4096}} で、512n のブロックデバイスでは {{ic|512}} です。最近のストレージデバイスのほとんどでは、セクタサイズを 512 バイトから 4096 バイトにすることでパフォーマンスが向上します。[[アドバンスドフォーマット#dm-crypt]]を見て下さい。
|}

LUKS の機能やオプションについては [https://gitlab.com/cryptsetup/cryptsetup/-/raw/master/docs/on-disk-format.pdf LUKS1 の仕様]や [https://gitlab.com/cryptsetup/cryptsetup/-/raw/master/docs/on-disk-format-luks2.pdf LUKS2の仕様] で説明されています。
{{Tip|開発者によるプレゼンテーション [https://mbroz.fedorapeople.org/talks/DevConf2016/devconf2016-luks2.pdf devconfcz2016] (pdf) では、LUKS2 での主な仕様変更の背景がまとめられています。cryptsetup のメジャーバージョンである[https://mirrors.edge.kernel.org/pub/linux/utils/cryptsetup/v2.0/v2.0.0-ReleaseNotes バージョン 2 のリリースノート]も見て下さい。}}

==== イテレーション時間 ====
[https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions#2-setup cryptsetup FAQ§2.1] と [https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions#3-common-problems §3.4]から:

:鍵スロットを解除するのにかかる時間は[...]パスフレーズを設定した時に決まります。デフォルトでは1秒 (LUKS2 では2秒) です。[...]
:パスフレーズをイテレーションする回数は時間によって決まり、したがってセキュリティレベルは LUKS コンテナを作成したマシンの CPU の能力に依存します。[...]
:もし高速なマシンでパスフレーズを設定し、低速なマシンでそれを解除した場合、解除にかかる時間は長くなります。

このことから、コンテナを作成する際は、そのコンテナに最も頻繁にアクセスすることになるマシンの上で作成するのが良いでしょう。

イテレーション回数を正しく調節する方法については、上の記事の残りの部分を読んで下さい。

=== plain モードの暗号化オプション ===
dm-crypt の ''plain'' モードでは、デバイスのマスター鍵が存在せず、セットアップも必要ありません。代わりに、直接暗号化オプションを使用して暗号ディスクと名前付きデバイスのマッピングを作成します。パーティションやデバイス全体に対してマッピングを作成できます。後者の場合、パーティションテーブルも不要です。

cryptsetup のデフォルトパラメータを使って ''plain'' のマッピングを作成するには:

# cryptsetup open --type plain ''options'' ''device'' ''dmname''

実行するとパスワードを求められます。非常に高いエントロピーのパスワードが必要です。デフォルトではありませんが、 {{ic|--verify-passphrase}} オプションを使えます。

一般論として、作成時の暗号化オプションは精確に記録しておくと良いでしょう。暗号化されたデバイス上にはオプションの内容は記録されていませんし、デフォルトのオプションは変わる可能性があります。

以下は [[Dm-crypt/システム全体の暗号化#Plain dm-crypt]] の例とデフォルトパラメータの比較表です。

{| class="wikitable"
! オプション !! Cryptsetup (2.7.0) のデフォルト !! 例 !! コメント !!
|-
| '''--hash, -h''' || {{ic|sha256}} || - || パスフレーズからキーを作成するのに使用するハッシュ。キーファイルを用いる場合は使われない。
|-
| '''--cipher, -c'''|| {{ic|aes-xts-plain64}}|| {{ic|aes-xts-plain64}} || 暗号は3つの文字列からなります: cipher-chainmode-IV generator。[[ディスク暗号化#暗号と利用形態]]や [https://gitlab.com/cryptsetup/cryptsetup/wikis/DMCrypt DMCrypt のドキュメント] を見てください。
|-
| '''--key-size, -s'''||{{ic|256}}||{{ic|512}}||キーサイズ (ビット数)。サイズは使用する暗号や使用するチェインモードによって変わります。XTS モードは CBC モードの2倍のキーサイズを必要とします。
|-
| '''--size, -b'''||対象ディスクの実際のサイズ||- (デフォルト)||512バイト単位のセクタ数。デバイスの最大サイズ以下。
|-
| '''--offset, -o'''||{{ic|0}}||{{ic|0}}||マッピングを開始するディスクの先頭からのオフセット。512バイト単位のセクタ数。
|-
| '''--skip, -p'''||{{ic|0}}||{{ic|2048}} (512B×2048=1MiB をスキップ)||初期ベクトル (IV) を計算する際にスキップする暗号化されたデータのサイズ。512バイト単位のセクタ数。
|-
| '''--key-file, -d'''||デフォルトではパスフレーズを使用||{{ic|/dev/sd''Z''}} (もしくは {{ic|/boot/keyfile.enc}})||キーとして使用するデバイスまたはファイル。詳しくは [[#キーファイル]] を参照。
|-
| '''--keyfile-offset'''||{{ic|0}}||{{ic|0}}||キーファイルの先頭からのオフセット (バイト数)。''cryptsetup'' 1.6.7 以上でサポートされているオプション。
|-
| '''--keyfile-size, -l'''||{{ic|8192kB}}||- (デフォルト)||キーファイルから読み込まれるバイト数を制限。''cryptsetup'' 1.6.7 以上でサポートされているオプション。
|-
| '''--sector-size, -l'''||{{ic|512}}||{{ic|4096}}||ディスク暗号化の際に使われるセクタサイズ。4Kn のブロックデバイス以外では、 {{ic|512}} がデフォルト。最近のストレージデバイスのほとんどでは、セクタサイズを 512 バイトから 4096 バイトにすることでパフォーマンスが向上します。[[アドバンスドフォーマット#dm-crypt]]を見て下さい。
|}

{{ic|/dev/sd''X''}} デバイスで、上記の例を使用する場合:

# cryptsetup open --type plain --cipher=aes-xts-plain64 --offset=0 --skip=2048 --key-file=/dev/sd''Z'' --key-size=512 --sector-size 4096 /dev/sdX enc

{{Warning|LUKS による暗号化と違って、上記のコマンドはマッピングを再現するために毎回 '''全て''' 指定する必要があります。暗号やハッシュ、キーファイルについて覚えておく必要があります。cryptsetup のデフォルトはバージョンによって変わるので、デフォルトに頼らないで下さい。}}

マッピングが作成されたことは以下のコマンドで確認できます:
# fdisk -l
{{ic|/dev/mapper/enc}} のエントリが存在しているはずです。

== cryptsetup でデバイスを暗号化 ==
以下のセクションでは新しい暗号化ブロックデバイスを作成するオプションと手動のアクセス方法を説明します。

=== LUKS モードでデバイスを暗号化 ===
==== LUKS パーティションのフォーマット ====

暗号化 LUKS パーティションとして設定するには次を実行:

# cryptsetup luksFormat ''device''

上記のコマンドを実行するとパスワードの入力が要求されます。

コマンドラインオプションは [[#LUKS モードの暗号化オプション]]を参照。

結果は次のコマンドで確認できます:

# cryptsetup luksDump ''device''

ダンプでは暗号のヘッダー情報だけでなく、LUKS パーティションで使われるキースロットもわかります。

以下の例はデフォルトの AES 暗号を使って256ビットの XTS モードで {{ic|/dev/sda1}} に暗号化したルートパーティションを作成します:
# cryptsetup -s 512 luksFormat /dev/sda1

=====LUKS を使ってキーファイルでパーティションをフォーマット=====

LUKS による暗号化パーティションを新しく作成する場合、以下のように作成するときにパーティションにキーファイルを関連付けることができます:

# cryptsetup luksFormat ''device'' ''/path/to/mykeyfile''

キーファイルを作成・管理する方法は [[#キーファイル]] を見て下さい。

====デバイスマッパーで LUKS パーティションのロックを解除・マップ====

LUKS パーティションを作成したら、解錠することができます。

解錠ではデバイスマッパーによってパーティションが新しいデバイス名にマッピングされます。カーネルは {{ic|''device''}} が暗号化デバイスであり暗号化データを上書きしないように {{ic|/dev/mapper/''dm_name''}} を使って LUKS 経由で解決する必要があることを知ります。間違って上書きしないために、設定が完了したら[[#バックアップとリストア|暗号化ヘッダーをバックアップ]]する方法を確認してください。

暗号化された LUKS パーティションを開くには次のコマンドを実行:

# cryptsetup open --type luks ''device'' ''dm_name''

実行するとパーティションを解錠するパスワードの入力が求められます。通常、マッピングするデバイスの名前はパーティションの機能が分かりやすいものにします。例えば、以下のコマンドは luks パーティション {{ic|/dev/sda1}} を解錠して {{ic|cryptroot}} という名前のデバイスマッパーにマッピングします:

# cryptsetup open --type luks /dev/sda1 cryptroot

パーティションをオープンしたら、ルートパーティションのデバイスアドレスはパーティション本体 (例: {{ic|/dev/sda1}}) の代わりに {{ic|/dev/mapper/cryptroot}} が使われます。

暗号化レイヤーの上に LVM をセットアップする場合、復号化したボリュームグループのデバイスファイルは {{ic|/dev/sda1}} ではなく {{ic|/dev/mapper/cryptroot}} などとなります。それから LVM は作成されている論理ボリューム全てに名前を割り当てます (例: {{ic|/dev/mapper/lvmpool-root}} や {{ic|/dev/mapper/lvmpool-swap}})。

暗号化データをパーティションに書き込むときは、マッピングされたデバイス名を使ってアクセスする必要があります。例えば[[ファイルシステム#デバイスのフォーマット|ファイルシステムを作成]]するときは以下のようにします:

# mkfs -t ext4 /dev/mapper/cryptroot

{{ic|/dev/mapper/cryptroot}} デバイスは他のパーティションと同じように[[マウント]]できます。

luks コンテナを閉じるには、パーティションをアンマウントしてください:

# cryptsetup close cryptroot

=== plain モードでデバイスを暗号化 ===

''dm-crypt'' プレーンモード暗号化の作成とその後のアクセスはどちらも、正しい [[#plain視の暗号化オプション| parametersで ''cryptsetup'' {{ic|open}} アクションを使用するだけで済みます。]] 以下は、非ルートデバイスの2つの例で示していますが、両方をスタックすることで癖が追加されています (つまり、2番目は最初のデバイス内に作成されます) 明らかに、暗号化をスタックするとオーバーヘッドが2倍になります。ここでの使用例は、暗号オプションの使用法の別の例を説明するためのものです。

上記の表の左側の列で説明されているように、最初のマッパーは ''cryptsetup'' のプレーンモードのデフォルトで作成されます。
{{hc|# cryptsetup --type plain -v open /dev/sdaX plain1|
Enter passphrase:
Command successful.
}}
次に、さまざまな暗号化パラメーターを使用し、(オプションの) オフセットを使用して、その中に2番目のブロックデバイスを追加し、ファイルシステムを作成してマウントします。
{{hc|1=# cryptsetup --type plain --cipher=serpent-xts-plain64 --hash=sha256 --key-size=256 --offset=10 open /dev/mapper/plain1 plain2|2=
Enter passphrase:
}}
{{hc|# lsblk -p|
NAME
/dev/sda
├─/dev/sdaX
│ └─/dev/mapper/plain1
│ └─/dev/mapper/plain2
...
}}
# mkfs -t ext2 /dev/mapper/plain2
# mount -t ext2 /dev/mapper/plain2 /mnt
# echo "This is stacked. one passphrase per foot to shoot." > /mnt/stacked.txt
We close the stack to check access works
# cryptsetup close plain2
# cryptsetup close plain1
First, let's try to open the filesystem directly:
# cryptsetup --type plain --cipher=serpent-xts-plain64 --hash=sha256 --key-size=256 --offset=10 open /dev/sdaX plain2
{{hc|# mount -t ext2 /dev/mapper/plain2 /mnt|
mount: wrong fs type, bad option, bad superblock on /dev/mapper/plain2,
missing codepage or helper program, or other error
}}
Why that did not work? Because the "plain2" starting block ({{ic|10}}) is still encrypted with the cipher from "plain1". It can only be accessed via the stacked mapper. The error is arbitrary though, trying a wrong passphrase or wrong options will yield the same. For ''dm-crypt'' plain mode, the {{ic|open}} action will not error out itself.

Trying again in correct order:
# cryptsetup close plain2 # dysfunctional mapper from previous try
{{hc|# cryptsetup --type plain open /dev/sdaX plain1|
Enter passphrase:
}}
{{hc|1=# cryptsetup --type plain --cipher=serpent-xts-plain64 --hash=sha256 --key-size=256 --offset=10 open /dev/mapper/plain1 plain2|2=
Enter passphrase:
}}
{{hc|# mount /dev/mapper/plain2 /mnt && cat /mnt/stacked.txt|
This is stacked. one passphrase per foot to shoot.
}}
# exit
''dm-crypt'' will handle stacked encryption with some mixed modes too. For example LUKS mode could be stacked on the "plain1" mapper. Its header would then be encrypted inside "plain1" when that is closed.

Available for plain mode only is the option {{ic|--shared}}. With it a single device can be segmented into different non-overlapping mappers. We do that in the next example, using a ''loopaes'' compatible cipher mode for "plain2" this time:
{{hc|# cryptsetup --type plain --offset 0 --size 1000 open /dev/sdaX plain1|2=
Enter passphrase:
}}
{{hc|1=# cryptsetup --type plain --offset 1000 --size 1000 --shared --cipher=aes-cbc-lmk --hash=sha256 open /dev/sdaX plain2|2=
Enter passphrase:
}}
{{hc|# lsblk -p|
NAME
dev/sdaX
├─/dev/sdaX
│ ├─/dev/mapper/plain1
│ └─/dev/mapper/plain2
...
}}
As the devicetree shows both reside on the same level, i.e. are not stacked and "plain2" can be opened individually.

== LUKS 固有の Cryptsetup のアクション ==
=== キーの管理 ===
LUKS パーティションには異なる8つまでのキーを定義することができます。バックアップストレージのためのアクセスキーを作成することが可能です。いわゆるキーエスクローで、あるキーは日常的に使用するために使い、他のキーはエスクローに保存して日常用のパスフレーズを忘れたときやキーファイルを喪失・破損したときにパーティションにアクセスするために使います。また、別のキースロットを使って一時的なキーを発行してユーザーにパーティションへのアクセスを許可し、後でキーを無効化したりできます。

暗号化パーティションを作成すると、初期キースロット 0 が作成されます (手動で別の数字を指定しなかった場合)。追加キースロットは 1 から 7 までの数字が割り振られます。どのキースロットを使用しているかは以下のコマンドで確認できます (<device> は LUKS ヘッダーが存在するボリュームに置き換えてください):
{{hc|# cryptsetup luksDump /dev/<device> {{!}} grep BLED|
Key Slot 0: ENABLED
Key Slot 1: ENABLED
Key Slot 2: ENABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED}}

上記のコマンドや下で説明しているコマンドはヘッダーのバックアップファイルでも使えます。

==== LUKS キーの追加 ====

新しいキースロットの追加は cryptsetup の {{ic|luksAddKey}} アクションを使うことでできます。デバイスが解錠されていても安全のために、新しいキーを入力する前に、必ず既存のキーの入力が求められます ("any passphrase"):

{{hc|# cryptsetup luksAddKey /dev/<device> (/path/to/<additionalkeyfile>)|
Enter any passphrase:
Enter new passphrase for key slot:
Verify passphrase:
}}

{{ic|/path/to/<additionalkeyfile>}} を指定した場合、cryptsetup は <additionalkeyfile> の新しいキースロットを追加します。指定しなかった場合は新しいパスフレーズの入力が2回要求されます。既存の''キーファイル''を使って認証するには、{{ic|--key-file}} または {{ic|-d}} オプションの後に"既存"の <keyfile> を指定することで全てのキーファイルのキースロットが解除されます:

# cryptsetup luksAddKey /dev/<device> (/path/to/<additionalkeyfile>) -d /path/to/<keyfile>

複数のキーを使っていてキーを変更・無効化する場合、{{ic|--key-slot}} または {{ic|-S}} オプションでスロットを指定できます:
{{hc|# cryptsetup luksAddKey /dev/<device> -S 6|
Enter any passphrase:
Enter new passphrase for key slot:
Verify passphrase:
}}
{{hc|# cryptsetup luksDump /dev/sda8 {{!}} grep 'Slot 6'|
Key Slot 6: ENABLED
}}

例えばキーを変更したい場合:
{{hc|# cryptsetup luksChangeKey /dev/<device> -S 6|
Enter LUKS passphrase to be changed:
Enter new LUKS passphrase:
}}

==== LUKS キーの削除 ====

ヘッダーからキーを削除するアクションは3つ存在します:
*{{ic|luksRemoveKey}} はパスフレーズやキーファイルを指定してキーを削除します。
*{{ic|luksKillSlot}} は (他のキーを使って) 指定したキースロットからキーを削除します。パスフレーズを忘れたり、キーファイルを無くしたり、誰もアクセスできないようにしたい場合に有用です。
*{{ic|luksErase}} は全ての有効なキーを即座に削除します。
{{warning|
*All above actions can be used to irrevocably delete the last active key for an encrypted device!
*The {{ic|luksErase}} command was added in version 1.6.4 to quickly nuke access to the device. This action '''will not''' prompt for a valid passphrase! It will not [[Dm-crypt/ドライブの準備#LUKS ヘッダーを消去|wipe the LUKS header]], but all keyslots at once and you will, therefore, not be able to regain access unless you have a valid backup of the LUKS header.}}

For above warning it is good to know the key we want to '''keep''' is valid. An easy check is to unlock the device with the {{ic|-v}} option, which will specify which slot it occupies:
{{hc|# cryptsetup -v open /dev/<device> testcrypt|
Enter passphrase for /dev/<device>:
Key slot 1 unlocked.
Command successful.}}

Now we can remove the key added in the previous subsection using its passphrase:
{{hc|# cryptsetup luksRemoveKey /dev/<device>|
Enter LUKS passphrase to be deleted:
}}
If we had used the same passphrase for two keyslots, the first slot would be wiped now. Only executing it again would remove the second one.

Alternatively, we can specify the key slot:
{{hc|# cryptsetup luksKillSlot /dev/<device> 6|
Enter any remaining LUKS passphrase:
}}

Note that in both cases, no confirmation was required.
{{hc|# cryptsetup luksDump /dev/sda8 {{!}} grep 'Slot 6'|
Key Slot 6: DISABLED
}}
To re-iterate the warning above: If the same passphrase had been used for key slots 1 and 6, both would be gone now.

=== バックアップとリストア ===
If the header of a LUKS encrypted partition gets destroyed, you will not be able to decrypt your data. It is just as much of a dilemma as forgetting the passphrase or damaging a key-file used to unlock the partition. Damage may occur by your own fault while re-partitioning the disk later or by third-party programs misinterpreting the partition table. Therefore, having a backup of the header and storing it on another disk might be a good idea.

{{Note|If the LUKS-encrypted partitions' master passphrase becomes compromised, you must revoke it on ''every'' copy of the cryptheader, even those you have backed up. Otherwise, a copy of the backed-up cryptheader that uses the compromised passphrase can be used to decrypt the associated partition. See [https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#6-backup-and-data-recovery LUKS FAQ] for further details.}}

==== cryptsetup を使ってバックアップ ====
Cryptsetup's {{ic|luksHeaderBackup}} action stores a binary backup of the LUKS header and keyslot area:
# cryptsetup luksHeaderBackup /dev/<device> --header-backup-file /mnt/<backup>/<file>.img
where <device> is the partition containing the LUKS volume.

{{Tip|You can also back up the plaintext header into ramfs and encrypt it in example with gpg before writing to persistent backup storage by executing the following commands.}}
# mkdir /root/<tmp>/
# mount ramfs /root/<tmp>/ -t ramfs
# cryptsetup luksHeaderBackup /dev/<device> --header-backup-file /root/<tmp>/<file>.img
# gpg2 --recipient <User ID> --encrypt /root/<tmp>/<file>.img
# cp /root/<tmp>/<file>.img.gpg /mnt/<backup>/
# umount /root/<tmp>
{{Warning|Tmpfs can swap to harddisk if low on memory so it is not recommended here.}}

==== cryptsetup を使ってリストア ====

{{Warning|Restoring the wrong header or restoring to an unencrypted partition will cause data loss! The action can not perform a check whether the header is actually the ''correct'' one for that particular device.}}

In order to evade restoring a wrong header, you can ensure it does work by using it as a remote {{ic|--header}} first:

{{hc|# cryptsetup -v --header /mnt/<backup>/<file>.img open /dev/<device> test|
Key slot 0 unlocked.
Command successful.
}}
# mount /dev/mapper/test /mnt/test && ls /mnt/test
# umount /mnt/test
# cryptsetup close test

Now that the check succeeded, the restore may be performed:
# cryptsetup luksHeaderRestore /dev/<device> --header-backup-file ./mnt/<backup>/<file>.img

Now that all the keyslot areas are overwritten; only active keyslots from the backup file are available after issuing the command.

==== 手動バックアップとリストア ====
The header always resides at the beginning of the device and a backup can be performed without access to ''cryptsetup'' as well. First you have to find out the payload offset of the crypted partition:
{{hc|# cryptsetup luksDump /dev/<device> {{!}} grep "Payload offset"|
Payload offset: 4040}}
Second check the sector size of the drive
{{hc|# fdisk -l /dev/<device> {{!}} grep "Sector size"|Sector size (logical/physical): 512 bytes / 512 bytes}}

Now that you know the values, you can backup the header with a simple dd command:
# dd if=/dev/<device> of=/path/to/<file>.img bs=512 count=4040
and store it safely.

A restore can then be performed using the same values as when backing up:
# dd if=./<file>.img of=/dev/<device> bs=512 count=4040

=== デバイスの再暗号化 ===

The {{Pkg|cryptsetup}} package features the ''cryptsetup-reencrypt'' tool. It can be used to convert an existing unencrypted filesystem to a LUKS encrypted one (option {{ic|--new}}) and permanently remove LUKS encryption ({{ic|--decrypt}}) from a device. As its name suggests it can also be used to re-encrypt an existing LUKS encrypted device, though, re-encryption is not possible for a detached LUKS header or other encryption modes (e.g. plain-mode). For re-encryption it is possible to change the [[#LUKS モードの暗号化オプション]]. ''cryptsetup-reencrypt'' actions can be performed to unmounted devices only. See {{man|8|cryptsetup-reencrypt}} for more information.

One application of re-encryption may be to secure the data again after a passphrase or [[#キーファイル|keyfile]] has been compromised ''and'' one cannot be certain that no copy of the LUKS header has been obtained. For example, if only a passphrase has been shoulder-surfed but no physical/logical access to the device happened, it would be enough to change the respective passphrase/key only ([[#Key management]]).

{{Warning|Always make sure a '''reliable backup''' is available and double-check options you specify before using the tool!}}

The following shows an example to encrypt an unencrypted filesystem partition and a re-encryption of an existing LUKS device.

==== 暗号化されていないファイルシステムの暗号化 ====

A LUKS encryption header is always stored at the beginning of the device. Since an existing filesystem will usually be allocated all partition sectors, the first step is to shrink it to make space for the LUKS header.

The [[#LUKS モードの暗号化オプション|default]] LUKS header encryption cipher requires {{ic|4096}} 512-byte sectors. We already checked space and keep it simple by shrinking the existing {{ic|ext4}} filesystem on {{ic|/dev/sdaX}} to its current possible minimum:

# umount /mnt
{{hc|# e2fsck -f /dev/sdaX|
e2fsck 1.43-WIP (18-May-2015)
Pass 1: Checking inodes, blocks, and sizes
...
/dev/sda6: 12/166320 files (0.0% non-contiguous), 28783/665062 blocks
}}
{{hc|# resize2fs -M /dev/sdaX|
resize2fs 1.43-WIP (18-May-2015)
Resizing the filesystem on /dev/sdaX to 26347 (4k) blocks.
The filesystem on /dev/sdaX is now 26347 (4k) blocks long.}}

Now we encrypt it, using the default cipher we do not have to specify it explicitly. Note there is no option (yet) to double-check the passphrase before encryption starts, be careful not to mistype:

{{hc|# cryptsetup-reencrypt /dev/sdaX --new --reduce-device-size 4096S|
WARNING: this is experimental code, it can completely break your data.
Enter new passphrase:
Progress: 100,0%, ETA 00:00, 2596 MiB written, speed 37,6 MiB/s}}

After it finished, the encryption was performed to the full partition, i.e. not only the space the filesystem was shrunk to ({{ic|sdaX}} has {{ic|2.6GiB}} and the CPU used in the example has no hardware AES instructions). As a final step we extend the filesystem of the now encrypted device again to occupy available space:

{{hc|# cryptsetup open /dev/sdaX recrypt|
Enter passphrase for /dev/sdaX:
...
}}
{{hc|# resize2fs /dev/mapper/recrypt|
resize2fs 1.43-WIP (18-May-2015)
Resizing the filesystem on /dev/mapper/recrypt to 664807 (4k) blocks.
The filesystem on /dev/mapper/recrypt is now 664807 (4k) blocks long.}}
# mount /dev/mapper/recrypt /mnt

and are done.

==== 既存の LUKS パーティションの再暗号化 ====

以下の例では既存の LUKS デバイスを最暗号化しています。

{{Warning|Double-check you specify encryption options for ''cryptsetup-reencrypt'' correctly and ''never'' re-encrypt without a '''reliable backup'''! As of September 2015 the tool '''does''' accept invalid options and damage the LUKS header, if not used correctly!}}

In order to re-encrypt a device with its existing encryption options, they do not need to be specified. A simple:

{{hc|# cryptsetup-reencrypt /dev/sdaX|
WARNING: this is experimental code, it can completely break your data.
Enter passphrase for key slot 0:
Progress: 100,0%, ETA 00:00, 2596 MiB written, speed 36,5 MiB/s}}

performs it.

A possible usecase is to re-encrypt LUKS devices which have non-current encryption options. Apart from above warning on specifying options correctly, the ability to change the LUKS header may also be limited by its size. For example, if the device was initially encrypted using a CBC mode cipher and 128 bit key-size, the LUKS header will be half the size of above mentioned {{ic|4096}} sectors:
{{hc|# cryptsetup luksDump /dev/sdaX <nowiki>|</nowiki>grep -e "mode" -e "Payload" -e "MK bits"|
Cipher mode: cbc-essiv:sha256
Payload offset: '''2048'''
MK bits: 128}}
While it is possible to upgrade the encryption of such a device, it is currently only feasible in two steps. First, re-encrypting with the same encryption options, but using the {{ic|--reduce-device-size}} option to make further space for the larger LUKS header. Second, re-encypt the whole device again with the desired cipher. For this reason and the fact that a backup should be created in any case, creating a new, fresh encrypted device to restore into is always the faster option.

== 暗号化デバイスのリサイズ ==

If a storage device encrypted with dm-crypt is being cloned (with a tool like dd) to another larger device, the underlying dm-crypt device must be resized to use the whole space.

The destination device is /dev/sdX2 in this example, the whole available space adjacent to the partition will be used:

# cryptsetup luksOpen /dev/sdX2 sdX2
# cryptsetup resize sdX2

Then the underlying filesystem must be resized.

=== ループバックファイルシステム ===

暗号化したループバックデバイスを {{ic|/mnt/secret}} にマウントしている場合、例えば [[Dm-crypt/root 以外のファイルシステムの暗号化#Loop デバイス]] に従っている場合、最初に暗号化コンテナをアンマウント:
# umount /mnt/secret
# cryptsetup close secret
# losetup -d /dev/loop0

次に、追加したいデータ容量を決めてコンテナファイルを拡張します:

{{Warning|{{ic|>}} を2つ使っていることに注意してください。1つだけだと現在のコンテナを上書きしてしまいます。}}
# dd if=/dev/urandom bs=1M count=1024 | cat - >> /bigsecret

ループデバイスにコンテナをマップ:
# losetup /dev/loop0 /bigsecret
# cryptsetup --type luks open /dev/loop0 secret

その後、コンテナの暗号化された部分をコンテナファイルの最大サイズまでリサイズ:
# cryptsetup resize secret

最後に、ファイルシステムのチェックを実行して、問題なければ、リサイズを行います (例: ext2/3/4):
# e2fsck -f /dev/mapper/secret
# resize2fs /dev/mapper/secret

またコンテナをマウントすることができます:
# mount /dev/mapper/secret /mnt/secret

== キーファイル ==

{{Note|このセクションでは平文のキーファイルを使う方法を説明しています。キーファイルを暗号化して二段階認証したい場合は[[Dm-crypt/特記事項#GPG や OpenSSL で暗号化されたキーファイルを使う|GPG や OpenSSL で暗号化されたキーファイルを使う]]を見て下さい。ただし、このセクションもあらかじめ読むようにしてください。}}

'''キーファイルとは？'''

キーファイルは暗号化されたボリュームを解錠するパスフレーズとして使用するデータを含んだファイルです。ファイルを喪失した場合、ボリュームの復号化はできなくなります。

{{Tip|Define a passphrase in addition to the keyfile for backup access to encrypted volumes in the event the defined keyfile is lost or changed.}}

'''なぜキーファイルを使うのか？'''

キーファイルには様々なタイプがあります。以下で説明しているようにそれぞれメリットとデメリットが存在します:

=== キーファイルのタイプ ===
==== passphrase ====

単にパスフレーズが記述されたキーファイルです。メリットはファイルを無くしても暗号化ボリュームの所有者が簡単に中身を思い出せることです。デメリットはパスフレーズの入力と比べてセキュリティ上の優位点がないことです。

例: {{ic|1234}}。

{{Note|パスフレーズが記述されたキーファイルに改行を含めてはいけません。以下のようなコマンドでファイルを作成できます:
# echo -n 'your_passphrase' > /path/to/<keyfile>
# chown root:root /path/to/<keyfile>; chmod 400 /path/to/<keyfile>
}}

==== randomtext ====

This is a keyfile containing a block of random characters. The benefit of this type of keyfile is that it is much more resistant to dictionary attacks than a simple passphrase. An additional strength of keyfiles can be utilized in this situation which is the length of data used. Since this is not a string meant to be memorized by a person for entry, it is trivial to create files containing thousands of random characters as the key. The disadvantage is that if this file is lost or changed, it will most likely not be possible to access the encrypted volume without a backup passphrase.

例: {{ic|fjqweifj830149-57 819y4my1-38t1934yt8-91m 34co3;t8y;9p3y-}}。

==== binary ====

This is a binary file that has been defined as a keyfile. When identifying files as candidates for a keyfile, it is recommended to choose files that are relatively static such as photos, music, video clips. The benefit of these files is that they serve a dual function which can make them harder to identify as keyfiles. Instead of having a text file with a large amount of random text, the keyfile would look like a regular image file or music clip to the casual observer. The disadvantage is that if this file is lost or changed, it will most likely not be possible to access the encrypted volume without a backup passphrase. Additionally, there is a theoretical loss of randomness when compared to a randomly generated text file. This is due to the fact that images, videos and music have some intrinsic relationship between neighboring bits of data that does not exist for a text file. However this is controversial and has never been exploited publicly.

例: 画像, テキスト, 動画。

=== ランダムな文字列でキーファイルを作成 ===

==== ファイルシステムにキーファイルを保存 ====

キーファイルの中身とサイズは任意に決められます。

以下では {{ic|dd}} を使って2048バイトのランダムなキーファイルを生成して、{{ic|/etc/mykeyfile}} ファイルに保存します:

# dd bs=512 count=4 if=/dev/urandom of=/etc/mykeyfile

キーファイルを外部デバイスに保存する場合、出力先を適切なディレクトリに変更します:

# dd bs=512 count=4 if=/dev/urandom of=/media/usbstick/mykeyfile

===== 保存されたキーファイルを完全に消去 =====

物理的なストレージデバイスに一時的なキーファイルを保存する場合、削除するときは、以下のように完全に削除してください:

# shred --remove --zero mykeyfile

FAT や ext2 であれば上記で十分ですが、ジャーナリングファイルシステムやフラッシュメモリハードウェアの場合、[[ディスクの完全消去]]あるいはキーファイルのあるパーティションを削除することを強く推奨します。

==== ramfs にキーファイルを保存 ====

もしくは、ramfs をマウントしてキーファイルを一時的に保存:

# mkdir /root/myramfs
# mount ramfs /root/myramfs/ -t ramfs
# cd /root/myramfs

物理ディスクではなくメモリ上に配置することで、ramfs をアンマウントしたら復元できないという利点があります。キーファイルを他の安全なファイルシステムにコピーしたら、以下のコマンドで ramfs をアンマウントしてください:
# umount /root/myramfs

=== キーファイルを使用するように LUKS を設定 ===

キーファイルのキースロットを LUKS ヘッダに追加:

{{hc|# cryptsetup luksAddKey /dev/sda2 /etc/mykeyfile|
Enter any LUKS passphrase:
key slot 0 unlocked.
Command successful.}}

=== キーファイルを使ってパーティションを手動でアンロック ===

LUKS デバイスをオープンするときに {{ic|--key-file}} オプションを使ってください:

# cryptsetup open /dev/sda2 ''dm_name'' --key-file /etc/mykeyfile

=== 起動時にロックを解除 ===

ファイルシステムのキーファイルを暗号化されたルートディレクトリの中に保存することで、システムの電源が切れているときに安全を確保することができ、[[Dm-crypt/システム設定#crypttab|crypttab]] によって起動時に自動的にマウントを解錠することができます。[[UUID]] を使用する例:
{{hc|/etc/crypttab|<nowiki>home UUID=<UUID identifier> /etc/mykeyfile</nowiki>}}
is all needed for unlocking, and
{{hc|/etc/fstab|/dev/mapper/home /home ext4 defaults 0 2}} for mounting the LUKS blockdevice with the generated keyfile.
{{Tip|If you prefer to use a {{ic|--plain}} mode blockdevice, the encryption options necessary to unlock it are specified in {{ic|/etc/crypttab}}. Take care to apply the systemd workaround mentioned in [[Dm-crypt/システム設定#crypttab|crypttab]] in this case.}}

=== キーファイルを使って起動時に root パーティションのロックを解除 ===

[[mkinitcpio]] を設定して必要なモジュールやファイルを記述して [[Dm-crypt/システム設定#cryptkey|cryptkey]] [[カーネルパラメータ]]を設定してキーファイルの場所を指定します。

2つの方法が存在します:

# 外部メディア (USB スティック) にキーファイルを保存
# initramfs にキーファイルを埋め込む

==== キーファイルを外部メディアに保存 ====

===== mkinitcpio の設定 =====

ドライブのファイルシステムを使うために {{ic|/etc/mkinitcpio.conf}} にモジュールを追加してください (以下の例では {{ic|vfat}} モジュール):
MODULES=(vfat)

In this example it is assumed that you use a FAT formatted USB drive ({{ic|vfat}} module). Replace those module names if you use another file system on your USB stick (e.g. {{ic|ext2}}) or another codepage. If it complains of bad superblock and bad codepage at boot, then you need an extra codepage module to be loaded. For instance, you may need {{ic|nls_iso8859-1}} module for {{ic|iso8859-1}} codepage.

If you have a non-US keyboard, it might prove useful to load your keyboard layout before you are prompted to enter the password to unlock the root partition at boot. For this, you will need the {{ic|keymap}} hook before {{ic|encrypt}}.

Generate a new initramfs image:

# mkinitcpio -p linux

===== カーネルパラメータの設定 =====

以下のオプションを[[カーネルパラメータ]]に追加してください ({{ic|encrypt}} フックではなく {{ic|sd-encrypt}} フックを使用する場合は [[Dm-crypt/システム設定#sd-encrypt フックを使う]]を参照):

cryptdevice=/dev/''<partition1>'':root cryptkey=/dev/''<partition2>'':<fstype>:<path>

例:

cryptdevice=/dev/sda3:root cryptkey=/dev/sdb1:vfat:/keys/secretkey

Choosing a plain filename for your key provides a bit of 'security through obscurity'. The keyfile can not be a hidden file, that means the filename must not start with a dot, or the {{ic|encrypt}} hook will fail to find the keyfile during the boot process.

{{ic|/dev/sdb1}} のようなデバイスノードの名前は再起動しても同じであるとは保証されていません。udev による[[永続的なブロックデバイスの命名]]を使ったほうが確実にデバイスにアクセスできます。外部ストレージデバイスからキーファイルを読み取るときに {{ic|encrypt}} フックが確実にキーファイルを見つけられるように、永続的なブロックデバイスの名前を絶対に使うべきです。[[永続的なブロックデバイスの命名]]を見て下さい。

==== キーファイルを initramfs に埋め込む ====

{{Warning|Use an embedded keyfile '''only''' if you have some form of authentication mechanism beforehand that protects the keyfile sufficiently. Otherwise auto-decryption will occur, defeating completely the purpose of block device encryption.}}

This method allows to use a specially named keyfile that will be embedded in the [[initramfs]] and picked up by the {{ic|encrypt}} [[Mkinitcpio#HOOKS|hook]] to unlock the root filesystem ({{ic|cryptdevice}}) automatically. It may be useful to apply when using the [[GRUB#暗号化された /boot|GRUB early cryptodisk]] feature, in order to avoid entering two passphrases during boot.

The {{ic|encrypt}} hook lets the user specify a keyfile with the {{ic|cryptkey}} kernel parameter: in the case of initramfs, the syntax is {{ic|rootfs:''path''}}, see [[Dm-crypt/システム設定#cryptkey]]. Besides, this kernel parameter defaults to use {{ic|/crypto_keyfile.bin}}, and if the initramfs contains a valid key with this name, decryption will occur automatically without the need to configure the {{ic|cryptkey}} parameter.

{{ic|encrypt}} の代わりに {{ic|sd-encrypt}} を使用する場合、{{ic|luks.key}} カーネルパラメータでキーファイルの場所を指定してください。[[Dm-crypt/システム設定#luks.key]] を参照。

[[#ランダムな文字列でキーファイルを作成|キーファイルを生成]]して適切な権限を与えて [[#LUKS キーの追加|LUKS キーとして追加]]:

# dd bs=512 count=4 if=/dev/urandom of=/crypto_keyfile.bin
# chmod 000 /crypto_keyfile.bin
# chmod 600 /boot/initramfs-linux*
# cryptsetup luksAddKey /dev/sdX# /crypto_keyfile.bin

{{Warning|When initramfs' permissions are set to 644 (by default), then all users will be able to dump the keyfile. Make sure the permissions are still 600 if you install a new kernel.}}

[[Mkinitcpio#BINARIES_と_FILES|mkinitcpio の FILES]] にキーを記述:

{{hc|/etc/mkinitcpio.conf|2=FILES=(/crypto_keyfile.bin)}}

最後に [[Mkinitcpio#イメージ作成とアクティベーション|initramfs を再生成]]してください。

次の起動時からコンテナを復号化するパスフレーズを入力するのは一度だけですむようになります。

詳しくは [http://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/#bonus-login-once こちら] を参照。

Dm-crypt/デバイスの暗号化

2025-03-09T18:19:18Z

Takemaro: /* Cryptsetup の使用方法 */ 英語版を反映

{{Lowercase title}}
[[Category:保存データ暗号化]]
[[Category:ファイルシステム]]
[[en:Dm-crypt/Device encryption]]
このセクションではコマンドラインから ''dm-crypt'' を利用して手動でシステムを暗号化する方法を説明しています。

== 準備 ==
{{pkg|cryptsetup}} を使用する前に、{{ic|dm_crypt}} [[カーネルモジュール]]がロードされていることを確認してください。

== Cryptsetup の使用方法 ==
''Cryptsetup'' は暗号化デバイスを作成・管理する ''dm-crypt'' を使うためのコマンドラインツールです。後に Linux カーネルの '''d'''evice-'''m'''apper と '''crypt'''ographic モジュールを使用する別の暗号化もサポートするように拡張されました。最も著しい拡張は Linux Unified Key Setup (LUKS) の拡張で、dm-crypt をセットアップするのに必要な情報を全てディスク自体に保存してパーティションとキーの管理を抽象化することで使いやすさを増しています。device-mapper によってアクセスされるデバイスはブロックデバイスと呼ばれます。詳しくは[[ディスク暗号化#ブロックデバイスの暗号化]]を見て下さい。

ツールは以下のように使います:

# cryptsetup ''action'' ''options'' ''device'' ''dmname''

オプションや暗号化モードにはデフォルト値が存在し、コマンドラインで何も指定しなかった場合はデフォルト値が使われます。オプションや暗号化モードのデフォルトパラメータを確認するには以下のコマンドを実行:

$ cryptsetup --help

オプションの完全なリストは man ページで確認できます。暗号化モードやアクションによって必要なパラメータは変わるため、以下のセクションでは違いについて説明しています。ブロックデバイス暗号化は高速ですが、速度は非常に重要な問題です。ブロックデバイスの暗号を設定後に変更することは難しいため、それぞれのパラメータについて ''dm-crypt'' のパフォーマンスをチェックすると良いでしょう:

$ cryptsetup benchmark

上記のコマンドはインストールするときにアルゴリズムや鍵長を決める手がかりになります。特定の AES 暗号が非常に高速に処理される場合、おそらくその暗号は CPU によるハードウェア支援の恩恵に与かっています。

{{Tip|テストしたいときは[[:カテゴリ:仮想化|仮想マシン]]の仮想ハードドライブで練習すると良いでしょう。}}

=== Cryptsetup のパスフレーズとキー ===
暗号化されたブロックデバイスはキーによって保護されます。キーは以下のいずれかです:

*パスフレーズ、[[セキュリティ#パスワード]]を見て下さい。
*キーファイル、[[#キーファイル]] を見て下さい。

どちらのタイプのキーも最大サイズが決められています: パスフレーズは512文字まで、キーファイルは 8192kB までです。

''LUKS'' の重要な特徴として、キーは LUKS によって暗号化されたデバイスのマスターキーを解除するのに使われ、root 権限で変えることができるということです。他の暗号化モードでは設定後にキーを変更することはできません。暗号化にマスターキーを使わないためです。詳しくは[[ディスク暗号化#ブロックデバイスの暗号化]]を見て下さい。

== dm-crypt の暗号化オプション ==
''Cryptsetup'' は ''dm-crypt'' で使用できる様々な暗号化モードをサポートしています。最も一般的な (デフォルトの) モードは:
*{{ic|--type LUKS}}
他に利用できるモードは:
*{{ic|--type plain}} - dm-crypt plain モードを使用。
*{{ic|--type loopaes}} - loopaes legacy モードを使用。
*{{ic|--type tcrypt}} - [[Truecrypt]] 互換モードを使用。

暗号やハッシュの基本的な暗号化オプションは全てのモードで使うことができ、カーネルの暗号化バックエンド機能を利用します。使用できるオプションは以下のコマンドで確認できます:
$ less /proc/crypto
リストが短い場合、{{ic|cryptsetup benchmark}} を実行すればモジュールのロードが行われます。

以下では最初の2つのモードの暗号化オプションを紹介します。記事の中で例として使っているオプションを並べていますが、利用できるオプションの全てではないので注意してください。

=== LUKS モードの暗号化オプション ===
LUKS 暗号化モードで新しい dm-crypt デバイスをセットアップする ''cryptsetup'' のアクションは ''luksFormat'' です。名前にはフォーマットとありますが、実際にはデバイスをフォーマットするのではなく、LUKS デバイスヘッダーを設定して指定された暗号オプションを使ってマスター鍵を暗号化します。

LUKS はデフォルトの暗号化モードなので、デフォルトパラメータで新しい LUKS デバイスを作成する場合、以下のコマンドだけで作成できます ({{ic|-v}} は任意です):

# cryptsetup -v luksFormat ''device''

手動でデフォルトのオプションを全て指定すると以下のようになります:

# cryptsetup -v --cipher aes-xts-plain64 --key-size 256 --hash sha256 --iter-time 2000 --use-urandom --verify-passphrase luksFormat ''device''

以下の表ではデフォルト値とサンプルにコメントを付けて説明しています:

{| class="wikitable"
! scope="col" style="text-align:left" | オプション
! scope="col" style="text-align:left" | Cryptsetup (1.7.0) のデフォルト
! scope="col" style="text-align:left" | 例
! scope="col" style="text-align:left" | コメント
|-
! scope="row" style="text-align:right" | --cipher, -c
| {{ic|aes-xts-plain64}}
| {{ic|aes-xts-plain64}}
| 例ではデフォルトと同じ暗号を使っています: AES [[ディスク暗号化#暗号と利用形態|暗号]]と [[wikipedia:Disk encryption theory#XEX-based tweaked-codebook mode with ciphertext stealing (XTS)|XTS]]。
|-
! scope="row" style="text-align:right" | --key-size, -s
| {{ic|256}}
| {{ic|512}}
| デフォルトでは256ビットが使われます。ただし [[wikipedia:Disk encryption theory#XEX-based tweaked-codebook mode with ciphertext stealing (XTS)|XTS はキーを半分に割る]]ので、AES-128 ではなく AES-256 を使うには XTS のキーサイズを {{ic|512}} に設定する必要があります。
|-
! scope="row" style="text-align:right" | --hash, -h
| {{ic|sha256}}
| {{ic|sha512}}
| [[ディスク暗号化#キーとキーファイルとパスフレーズ|PBKDF2]] で使用されるハッシュアルゴリズム。リリース 1.7.0 でデフォルト設定が {{ic|sha1}} から {{ic|sha256}} に変更されました。セキュリティ上の理由ではなく SHA1 が使用できないシステムでも動作するようにするためです [https://www.kernel.org/pub/linux/utils/cryptsetup/v1.7/v1.7.0-ReleaseNotes]。{{ic|sha1}} でも十分セキュアであるため古いバージョンの ''cryptsetup'' と互換性を維持する目的で使用できます [https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#5-security-aspects]。
|-
! scope="row" style="text-align:right" | --iter-time, -i
| {{ic|2000}}
| {{ic|5000}}
| PBKDF2 パスフレーズを処理するのに費やす時間 (ミリ秒単位)。"''PBKDF2 の反復回数を高く保持したままユーザーが許容できる数値にするため''"、リリース 1.7.0 からデフォルト値が {{ic|1000}} から {{ic|2000}} に変更されています [https://www.kernel.org/pub/linux/utils/cryptsetup/v1.7/v1.7.0-ReleaseNotes]。''luksFormat'' や ''luksAddKey'' などパスフレーズを設定・変更する LUKS 操作のみに関連するオプションです。パラメータとして 0 を指定するとコンパイル時のデフォルトが選択されます。
|-
! scope="row" style="text-align:right" | --use-{u,}random
| {{ic|--use-'''u'''random}}
| {{ic|--use-random}}
| [[乱数生成|乱数生成器]]の選択。cryptsetup のマニュアルページより: "エントロピーが少ない環境 (例: 組み込み環境)、どちらを選択しても問題になります。/dev/urandom を使うとキーが弱くなりかねません。/dev/random を使うと長い時間がかかり、カーネルから提供されるエントロピーが足りない場合、永遠に終わりません。"
|-
! scope="row" style="text-align:right" | --verify-passphrase, -y
| Yes
| -
| luksFormat と luksAddKey のデフォルトのみ。Arch Linux で LUKS モードを使うのに入力する必要はありません。
|}

LUKS の暗号機能について詳しく知りたい場合は [https://gitlab.com/cryptsetup/cryptsetup/wikis/Specification LUKS specification] (例: 付記) を読むと良いでしょう。
{{Tip|LUKS ヘッダーは、やがて別の大きな改訂を受けると予想されます。計画に興味がある場合は、開発者の [https://mbroz.fedorapeople.org/talks/DevConf2016/devconf2016-luks2.pdf devconfcz2016] (pdf) プレゼンテーションに要約されています。}}

=== plain モードの暗号化オプション ===
dm-crypt の ''plain'' モードでは、デバイスのマスター鍵が存在せず、セットアップも必要ありません。代わりに、直接暗号化オプションを使用して暗号ディスクと名前付きデバイスのマッピングを作成します。パーティションやデバイス全体に対してマッピングを作成できます。後者の場合、パーティションテーブルも不要です。

cryptsetup のデフォルトパラメータを使って ''plain'' のマッピングを作成するには:
# cryptsetup <options> open --type plain <device> <dmname>
実行するとパスワードを求められます。以下は [[Dm-crypt/システム全体の暗号化#Plain dm-crypt]] の例とデフォルトパラメータの比較表です。

{| class="wikitable"
! オプション !! Cryptsetup (1.7.0) のデフォルト !! 例 !! コメント !!
|-
| '''--hash''' || {{ic|ripemd160}} || - || パスフレーズからキーを作成するのに使用するハッシュ。キーファイルでは使われない。
|-
| '''--cipher'''|| {{ic|aes-cbc-essiv:sha256}}|| {{ic|twofish-xts-plain64}} || 暗号は3つの文字列からなります: cipher-chainmode-IV generator。[[ディスク暗号化#暗号と利用形態]]や [https://gitlab.com/cryptsetup/cryptsetup/wikis/DMCrypt DMCrypt のドキュメント] を見てください。
|-
| '''--key-size'''||{{ic|256}}||{{ic|512}}||キーサイズ (ビット数)。サイズは使用する暗号や使用するチェインモードによって変わります。Xts モードは cbc モードの2倍のキーサイズを必要とします。
|-
| '''--offset'''||{{ic|0}}||{{ic|0}}||マッピングを開始するディスクの先頭からのオフセット。
|-
| '''--key-file'''||デフォルトではパスフレーズを使用||{{ic|/dev/sd''Z''}} (もしくは {{ic|/boot/keyfile.enc}})||キーとして使用するデバイスまたはファイル。詳しくは [[#キーファイル]] を参照。
|-
| '''--keyfile-offset'''||{{ic|0}}||{{ic|0}}||キーファイルの先頭からのオフセット (バイト数)。''cryptsetup'' 1.6.7 以上でサポートされているオプション。
|-
| '''--keyfile-size'''||{{ic|8192kB}}||- (デフォルト)||キーファイルから読み込まれるバイト数を制限。''cryptsetup'' 1.6.7 以上でサポートされているオプション。
|}

{{ic|/dev/sd''X''}} デバイスで、上記の例を使用する場合:
# cryptsetup --cipher=twofish-xts-plain64 --offset=0 --key-file=/dev/sd''Z'' --key-size=512 open --type=plain /dev/sdX enc

LUKS による暗号化と違って、上記のコマンドはマッピングを再現するために毎回全て指定する必要があります。暗号やハッシュ、キーファイルについて覚えておく必要があります。マッピングが作成されたことは以下のコマンドで確認できます:
# fdisk -l
{{ic|/dev/mapper/enc}} のエントリが存在しているはずです。

== cryptsetup でデバイスを暗号化 ==
以下のセクションでは新しい暗号化ブロックデバイスを作成するオプションと手動のアクセス方法を説明します。

=== LUKS モードでデバイスを暗号化 ===
==== LUKS パーティションのフォーマット ====

暗号化 LUKS パーティションとして設定するには次を実行:

# cryptsetup luksFormat ''device''

上記のコマンドを実行するとパスワードの入力が要求されます。

コマンドラインオプションは [[#LUKS モードの暗号化オプション]]を参照。

結果は次のコマンドで確認できます:

# cryptsetup luksDump ''device''

ダンプでは暗号のヘッダー情報だけでなく、LUKS パーティションで使われるキースロットもわかります。

以下の例はデフォルトの AES 暗号を使って256ビットの XTS モードで {{ic|/dev/sda1}} に暗号化したルートパーティションを作成します:
# cryptsetup -s 512 luksFormat /dev/sda1

=====LUKS を使ってキーファイルでパーティションをフォーマット=====

LUKS による暗号化パーティションを新しく作成する場合、以下のように作成するときにパーティションにキーファイルを関連付けることができます:

# cryptsetup luksFormat ''device'' ''/path/to/mykeyfile''

キーファイルを作成・管理する方法は [[#キーファイル]] を見て下さい。

====デバイスマッパーで LUKS パーティションのロックを解除・マップ====

LUKS パーティションを作成したら、解錠することができます。

解錠ではデバイスマッパーによってパーティションが新しいデバイス名にマッピングされます。カーネルは {{ic|''device''}} が暗号化デバイスであり暗号化データを上書きしないように {{ic|/dev/mapper/''dm_name''}} を使って LUKS 経由で解決する必要があることを知ります。間違って上書きしないために、設定が完了したら[[#バックアップとリストア|暗号化ヘッダーをバックアップ]]する方法を確認してください。

暗号化された LUKS パーティションを開くには次のコマンドを実行:

# cryptsetup open --type luks ''device'' ''dm_name''

実行するとパーティションを解錠するパスワードの入力が求められます。通常、マッピングするデバイスの名前はパーティションの機能が分かりやすいものにします。例えば、以下のコマンドは luks パーティション {{ic|/dev/sda1}} を解錠して {{ic|cryptroot}} という名前のデバイスマッパーにマッピングします:

# cryptsetup open --type luks /dev/sda1 cryptroot

パーティションをオープンしたら、ルートパーティションのデバイスアドレスはパーティション本体 (例: {{ic|/dev/sda1}}) の代わりに {{ic|/dev/mapper/cryptroot}} が使われます。

暗号化レイヤーの上に LVM をセットアップする場合、復号化したボリュームグループのデバイスファイルは {{ic|/dev/sda1}} ではなく {{ic|/dev/mapper/cryptroot}} などとなります。それから LVM は作成されている論理ボリューム全てに名前を割り当てます (例: {{ic|/dev/mapper/lvmpool-root}} や {{ic|/dev/mapper/lvmpool-swap}})。

暗号化データをパーティションに書き込むときは、マッピングされたデバイス名を使ってアクセスする必要があります。例えば[[ファイルシステム#デバイスのフォーマット|ファイルシステムを作成]]するときは以下のようにします:

# mkfs -t ext4 /dev/mapper/cryptroot

{{ic|/dev/mapper/cryptroot}} デバイスは他のパーティションと同じように[[マウント]]できます。

luks コンテナを閉じるには、パーティションをアンマウントしてください:

# cryptsetup close cryptroot

=== plain モードでデバイスを暗号化 ===

''dm-crypt'' プレーンモード暗号化の作成とその後のアクセスはどちらも、正しい [[#plain視の暗号化オプション| parametersで ''cryptsetup'' {{ic|open}} アクションを使用するだけで済みます。]] 以下は、非ルートデバイスの2つの例で示していますが、両方をスタックすることで癖が追加されています (つまり、2番目は最初のデバイス内に作成されます) 明らかに、暗号化をスタックするとオーバーヘッドが2倍になります。ここでの使用例は、暗号オプションの使用法の別の例を説明するためのものです。

上記の表の左側の列で説明されているように、最初のマッパーは ''cryptsetup'' のプレーンモードのデフォルトで作成されます。
{{hc|# cryptsetup --type plain -v open /dev/sdaX plain1|
Enter passphrase:
Command successful.
}}
次に、さまざまな暗号化パラメーターを使用し、(オプションの) オフセットを使用して、その中に2番目のブロックデバイスを追加し、ファイルシステムを作成してマウントします。
{{hc|1=# cryptsetup --type plain --cipher=serpent-xts-plain64 --hash=sha256 --key-size=256 --offset=10 open /dev/mapper/plain1 plain2|2=
Enter passphrase:
}}
{{hc|# lsblk -p|
NAME
/dev/sda
├─/dev/sdaX
│ └─/dev/mapper/plain1
│ └─/dev/mapper/plain2
...
}}
# mkfs -t ext2 /dev/mapper/plain2
# mount -t ext2 /dev/mapper/plain2 /mnt
# echo "This is stacked. one passphrase per foot to shoot." > /mnt/stacked.txt
We close the stack to check access works
# cryptsetup close plain2
# cryptsetup close plain1
First, let's try to open the filesystem directly:
# cryptsetup --type plain --cipher=serpent-xts-plain64 --hash=sha256 --key-size=256 --offset=10 open /dev/sdaX plain2
{{hc|# mount -t ext2 /dev/mapper/plain2 /mnt|
mount: wrong fs type, bad option, bad superblock on /dev/mapper/plain2,
missing codepage or helper program, or other error
}}
Why that did not work? Because the "plain2" starting block ({{ic|10}}) is still encrypted with the cipher from "plain1". It can only be accessed via the stacked mapper. The error is arbitrary though, trying a wrong passphrase or wrong options will yield the same. For ''dm-crypt'' plain mode, the {{ic|open}} action will not error out itself.

Trying again in correct order:
# cryptsetup close plain2 # dysfunctional mapper from previous try
{{hc|# cryptsetup --type plain open /dev/sdaX plain1|
Enter passphrase:
}}
{{hc|1=# cryptsetup --type plain --cipher=serpent-xts-plain64 --hash=sha256 --key-size=256 --offset=10 open /dev/mapper/plain1 plain2|2=
Enter passphrase:
}}
{{hc|# mount /dev/mapper/plain2 /mnt && cat /mnt/stacked.txt|
This is stacked. one passphrase per foot to shoot.
}}
# exit
''dm-crypt'' will handle stacked encryption with some mixed modes too. For example LUKS mode could be stacked on the "plain1" mapper. Its header would then be encrypted inside "plain1" when that is closed.

Available for plain mode only is the option {{ic|--shared}}. With it a single device can be segmented into different non-overlapping mappers. We do that in the next example, using a ''loopaes'' compatible cipher mode for "plain2" this time:
{{hc|# cryptsetup --type plain --offset 0 --size 1000 open /dev/sdaX plain1|2=
Enter passphrase:
}}
{{hc|1=# cryptsetup --type plain --offset 1000 --size 1000 --shared --cipher=aes-cbc-lmk --hash=sha256 open /dev/sdaX plain2|2=
Enter passphrase:
}}
{{hc|# lsblk -p|
NAME
dev/sdaX
├─/dev/sdaX
│ ├─/dev/mapper/plain1
│ └─/dev/mapper/plain2
...
}}
As the devicetree shows both reside on the same level, i.e. are not stacked and "plain2" can be opened individually.

== LUKS 固有の Cryptsetup のアクション ==
=== キーの管理 ===
LUKS パーティションには異なる8つまでのキーを定義することができます。バックアップストレージのためのアクセスキーを作成することが可能です。いわゆるキーエスクローで、あるキーは日常的に使用するために使い、他のキーはエスクローに保存して日常用のパスフレーズを忘れたときやキーファイルを喪失・破損したときにパーティションにアクセスするために使います。また、別のキースロットを使って一時的なキーを発行してユーザーにパーティションへのアクセスを許可し、後でキーを無効化したりできます。

暗号化パーティションを作成すると、初期キースロット 0 が作成されます (手動で別の数字を指定しなかった場合)。追加キースロットは 1 から 7 までの数字が割り振られます。どのキースロットを使用しているかは以下のコマンドで確認できます (<device> は LUKS ヘッダーが存在するボリュームに置き換えてください):
{{hc|# cryptsetup luksDump /dev/<device> {{!}} grep BLED|
Key Slot 0: ENABLED
Key Slot 1: ENABLED
Key Slot 2: ENABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED}}

上記のコマンドや下で説明しているコマンドはヘッダーのバックアップファイルでも使えます。

==== LUKS キーの追加 ====

新しいキースロットの追加は cryptsetup の {{ic|luksAddKey}} アクションを使うことでできます。デバイスが解錠されていても安全のために、新しいキーを入力する前に、必ず既存のキーの入力が求められます ("any passphrase"):

{{hc|# cryptsetup luksAddKey /dev/<device> (/path/to/<additionalkeyfile>)|
Enter any passphrase:
Enter new passphrase for key slot:
Verify passphrase:
}}

{{ic|/path/to/<additionalkeyfile>}} を指定した場合、cryptsetup は <additionalkeyfile> の新しいキースロットを追加します。指定しなかった場合は新しいパスフレーズの入力が2回要求されます。既存の''キーファイル''を使って認証するには、{{ic|--key-file}} または {{ic|-d}} オプションの後に"既存"の <keyfile> を指定することで全てのキーファイルのキースロットが解除されます:

# cryptsetup luksAddKey /dev/<device> (/path/to/<additionalkeyfile>) -d /path/to/<keyfile>

複数のキーを使っていてキーを変更・無効化する場合、{{ic|--key-slot}} または {{ic|-S}} オプションでスロットを指定できます:
{{hc|# cryptsetup luksAddKey /dev/<device> -S 6|
Enter any passphrase:
Enter new passphrase for key slot:
Verify passphrase:
}}
{{hc|# cryptsetup luksDump /dev/sda8 {{!}} grep 'Slot 6'|
Key Slot 6: ENABLED
}}

例えばキーを変更したい場合:
{{hc|# cryptsetup luksChangeKey /dev/<device> -S 6|
Enter LUKS passphrase to be changed:
Enter new LUKS passphrase:
}}

==== LUKS キーの削除 ====

ヘッダーからキーを削除するアクションは3つ存在します:
*{{ic|luksRemoveKey}} はパスフレーズやキーファイルを指定してキーを削除します。
*{{ic|luksKillSlot}} は (他のキーを使って) 指定したキースロットからキーを削除します。パスフレーズを忘れたり、キーファイルを無くしたり、誰もアクセスできないようにしたい場合に有用です。
*{{ic|luksErase}} は全ての有効なキーを即座に削除します。
{{warning|
*All above actions can be used to irrevocably delete the last active key for an encrypted device!
*The {{ic|luksErase}} command was added in version 1.6.4 to quickly nuke access to the device. This action '''will not''' prompt for a valid passphrase! It will not [[Dm-crypt/ドライブの準備#LUKS ヘッダーを消去|wipe the LUKS header]], but all keyslots at once and you will, therefore, not be able to regain access unless you have a valid backup of the LUKS header.}}

For above warning it is good to know the key we want to '''keep''' is valid. An easy check is to unlock the device with the {{ic|-v}} option, which will specify which slot it occupies:
{{hc|# cryptsetup -v open /dev/<device> testcrypt|
Enter passphrase for /dev/<device>:
Key slot 1 unlocked.
Command successful.}}

Now we can remove the key added in the previous subsection using its passphrase:
{{hc|# cryptsetup luksRemoveKey /dev/<device>|
Enter LUKS passphrase to be deleted:
}}
If we had used the same passphrase for two keyslots, the first slot would be wiped now. Only executing it again would remove the second one.

Alternatively, we can specify the key slot:
{{hc|# cryptsetup luksKillSlot /dev/<device> 6|
Enter any remaining LUKS passphrase:
}}

Note that in both cases, no confirmation was required.
{{hc|# cryptsetup luksDump /dev/sda8 {{!}} grep 'Slot 6'|
Key Slot 6: DISABLED
}}
To re-iterate the warning above: If the same passphrase had been used for key slots 1 and 6, both would be gone now.

=== バックアップとリストア ===
If the header of a LUKS encrypted partition gets destroyed, you will not be able to decrypt your data. It is just as much of a dilemma as forgetting the passphrase or damaging a key-file used to unlock the partition. Damage may occur by your own fault while re-partitioning the disk later or by third-party programs misinterpreting the partition table. Therefore, having a backup of the header and storing it on another disk might be a good idea.

{{Note|If the LUKS-encrypted partitions' master passphrase becomes compromised, you must revoke it on ''every'' copy of the cryptheader, even those you have backed up. Otherwise, a copy of the backed-up cryptheader that uses the compromised passphrase can be used to decrypt the associated partition. See [https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#6-backup-and-data-recovery LUKS FAQ] for further details.}}

==== cryptsetup を使ってバックアップ ====
Cryptsetup's {{ic|luksHeaderBackup}} action stores a binary backup of the LUKS header and keyslot area:
# cryptsetup luksHeaderBackup /dev/<device> --header-backup-file /mnt/<backup>/<file>.img
where <device> is the partition containing the LUKS volume.

{{Tip|You can also back up the plaintext header into ramfs and encrypt it in example with gpg before writing to persistent backup storage by executing the following commands.}}
# mkdir /root/<tmp>/
# mount ramfs /root/<tmp>/ -t ramfs
# cryptsetup luksHeaderBackup /dev/<device> --header-backup-file /root/<tmp>/<file>.img
# gpg2 --recipient <User ID> --encrypt /root/<tmp>/<file>.img
# cp /root/<tmp>/<file>.img.gpg /mnt/<backup>/
# umount /root/<tmp>
{{Warning|Tmpfs can swap to harddisk if low on memory so it is not recommended here.}}

==== cryptsetup を使ってリストア ====

{{Warning|Restoring the wrong header or restoring to an unencrypted partition will cause data loss! The action can not perform a check whether the header is actually the ''correct'' one for that particular device.}}

In order to evade restoring a wrong header, you can ensure it does work by using it as a remote {{ic|--header}} first:

{{hc|# cryptsetup -v --header /mnt/<backup>/<file>.img open /dev/<device> test|
Key slot 0 unlocked.
Command successful.
}}
# mount /dev/mapper/test /mnt/test && ls /mnt/test
# umount /mnt/test
# cryptsetup close test

Now that the check succeeded, the restore may be performed:
# cryptsetup luksHeaderRestore /dev/<device> --header-backup-file ./mnt/<backup>/<file>.img

Now that all the keyslot areas are overwritten; only active keyslots from the backup file are available after issuing the command.

==== 手動バックアップとリストア ====
The header always resides at the beginning of the device and a backup can be performed without access to ''cryptsetup'' as well. First you have to find out the payload offset of the crypted partition:
{{hc|# cryptsetup luksDump /dev/<device> {{!}} grep "Payload offset"|
Payload offset: 4040}}
Second check the sector size of the drive
{{hc|# fdisk -l /dev/<device> {{!}} grep "Sector size"|Sector size (logical/physical): 512 bytes / 512 bytes}}

Now that you know the values, you can backup the header with a simple dd command:
# dd if=/dev/<device> of=/path/to/<file>.img bs=512 count=4040
and store it safely.

A restore can then be performed using the same values as when backing up:
# dd if=./<file>.img of=/dev/<device> bs=512 count=4040

=== デバイスの再暗号化 ===

The {{Pkg|cryptsetup}} package features the ''cryptsetup-reencrypt'' tool. It can be used to convert an existing unencrypted filesystem to a LUKS encrypted one (option {{ic|--new}}) and permanently remove LUKS encryption ({{ic|--decrypt}}) from a device. As its name suggests it can also be used to re-encrypt an existing LUKS encrypted device, though, re-encryption is not possible for a detached LUKS header or other encryption modes (e.g. plain-mode). For re-encryption it is possible to change the [[#LUKS モードの暗号化オプション]]. ''cryptsetup-reencrypt'' actions can be performed to unmounted devices only. See {{man|8|cryptsetup-reencrypt}} for more information.

One application of re-encryption may be to secure the data again after a passphrase or [[#キーファイル|keyfile]] has been compromised ''and'' one cannot be certain that no copy of the LUKS header has been obtained. For example, if only a passphrase has been shoulder-surfed but no physical/logical access to the device happened, it would be enough to change the respective passphrase/key only ([[#Key management]]).

{{Warning|Always make sure a '''reliable backup''' is available and double-check options you specify before using the tool!}}

The following shows an example to encrypt an unencrypted filesystem partition and a re-encryption of an existing LUKS device.

==== 暗号化されていないファイルシステムの暗号化 ====

A LUKS encryption header is always stored at the beginning of the device. Since an existing filesystem will usually be allocated all partition sectors, the first step is to shrink it to make space for the LUKS header.

The [[#LUKS モードの暗号化オプション|default]] LUKS header encryption cipher requires {{ic|4096}} 512-byte sectors. We already checked space and keep it simple by shrinking the existing {{ic|ext4}} filesystem on {{ic|/dev/sdaX}} to its current possible minimum:

# umount /mnt
{{hc|# e2fsck -f /dev/sdaX|
e2fsck 1.43-WIP (18-May-2015)
Pass 1: Checking inodes, blocks, and sizes
...
/dev/sda6: 12/166320 files (0.0% non-contiguous), 28783/665062 blocks
}}
{{hc|# resize2fs -M /dev/sdaX|
resize2fs 1.43-WIP (18-May-2015)
Resizing the filesystem on /dev/sdaX to 26347 (4k) blocks.
The filesystem on /dev/sdaX is now 26347 (4k) blocks long.}}

Now we encrypt it, using the default cipher we do not have to specify it explicitly. Note there is no option (yet) to double-check the passphrase before encryption starts, be careful not to mistype:

{{hc|# cryptsetup-reencrypt /dev/sdaX --new --reduce-device-size 4096S|
WARNING: this is experimental code, it can completely break your data.
Enter new passphrase:
Progress: 100,0%, ETA 00:00, 2596 MiB written, speed 37,6 MiB/s}}

After it finished, the encryption was performed to the full partition, i.e. not only the space the filesystem was shrunk to ({{ic|sdaX}} has {{ic|2.6GiB}} and the CPU used in the example has no hardware AES instructions). As a final step we extend the filesystem of the now encrypted device again to occupy available space:

{{hc|# cryptsetup open /dev/sdaX recrypt|
Enter passphrase for /dev/sdaX:
...
}}
{{hc|# resize2fs /dev/mapper/recrypt|
resize2fs 1.43-WIP (18-May-2015)
Resizing the filesystem on /dev/mapper/recrypt to 664807 (4k) blocks.
The filesystem on /dev/mapper/recrypt is now 664807 (4k) blocks long.}}
# mount /dev/mapper/recrypt /mnt

and are done.

==== 既存の LUKS パーティションの再暗号化 ====

以下の例では既存の LUKS デバイスを最暗号化しています。

{{Warning|Double-check you specify encryption options for ''cryptsetup-reencrypt'' correctly and ''never'' re-encrypt without a '''reliable backup'''! As of September 2015 the tool '''does''' accept invalid options and damage the LUKS header, if not used correctly!}}

In order to re-encrypt a device with its existing encryption options, they do not need to be specified. A simple:

{{hc|# cryptsetup-reencrypt /dev/sdaX|
WARNING: this is experimental code, it can completely break your data.
Enter passphrase for key slot 0:
Progress: 100,0%, ETA 00:00, 2596 MiB written, speed 36,5 MiB/s}}

performs it.

A possible usecase is to re-encrypt LUKS devices which have non-current encryption options. Apart from above warning on specifying options correctly, the ability to change the LUKS header may also be limited by its size. For example, if the device was initially encrypted using a CBC mode cipher and 128 bit key-size, the LUKS header will be half the size of above mentioned {{ic|4096}} sectors:
{{hc|# cryptsetup luksDump /dev/sdaX <nowiki>|</nowiki>grep -e "mode" -e "Payload" -e "MK bits"|
Cipher mode: cbc-essiv:sha256
Payload offset: '''2048'''
MK bits: 128}}
While it is possible to upgrade the encryption of such a device, it is currently only feasible in two steps. First, re-encrypting with the same encryption options, but using the {{ic|--reduce-device-size}} option to make further space for the larger LUKS header. Second, re-encypt the whole device again with the desired cipher. For this reason and the fact that a backup should be created in any case, creating a new, fresh encrypted device to restore into is always the faster option.

== 暗号化デバイスのリサイズ ==

If a storage device encrypted with dm-crypt is being cloned (with a tool like dd) to another larger device, the underlying dm-crypt device must be resized to use the whole space.

The destination device is /dev/sdX2 in this example, the whole available space adjacent to the partition will be used:

# cryptsetup luksOpen /dev/sdX2 sdX2
# cryptsetup resize sdX2

Then the underlying filesystem must be resized.

=== ループバックファイルシステム ===

暗号化したループバックデバイスを {{ic|/mnt/secret}} にマウントしている場合、例えば [[Dm-crypt/root 以外のファイルシステムの暗号化#Loop デバイス]] に従っている場合、最初に暗号化コンテナをアンマウント:
# umount /mnt/secret
# cryptsetup close secret
# losetup -d /dev/loop0

次に、追加したいデータ容量を決めてコンテナファイルを拡張します:

{{Warning|{{ic|>}} を2つ使っていることに注意してください。1つだけだと現在のコンテナを上書きしてしまいます。}}
# dd if=/dev/urandom bs=1M count=1024 | cat - >> /bigsecret

ループデバイスにコンテナをマップ:
# losetup /dev/loop0 /bigsecret
# cryptsetup --type luks open /dev/loop0 secret

その後、コンテナの暗号化された部分をコンテナファイルの最大サイズまでリサイズ:
# cryptsetup resize secret

最後に、ファイルシステムのチェックを実行して、問題なければ、リサイズを行います (例: ext2/3/4):
# e2fsck -f /dev/mapper/secret
# resize2fs /dev/mapper/secret

またコンテナをマウントすることができます:
# mount /dev/mapper/secret /mnt/secret

== キーファイル ==

{{Note|このセクションでは平文のキーファイルを使う方法を説明しています。キーファイルを暗号化して二段階認証したい場合は[[Dm-crypt/特記事項#GPG や OpenSSL で暗号化されたキーファイルを使う|GPG や OpenSSL で暗号化されたキーファイルを使う]]を見て下さい。ただし、このセクションもあらかじめ読むようにしてください。}}

'''キーファイルとは？'''

キーファイルは暗号化されたボリュームを解錠するパスフレーズとして使用するデータを含んだファイルです。ファイルを喪失した場合、ボリュームの復号化はできなくなります。

{{Tip|Define a passphrase in addition to the keyfile for backup access to encrypted volumes in the event the defined keyfile is lost or changed.}}

'''なぜキーファイルを使うのか？'''

キーファイルには様々なタイプがあります。以下で説明しているようにそれぞれメリットとデメリットが存在します:

=== キーファイルのタイプ ===
==== passphrase ====

単にパスフレーズが記述されたキーファイルです。メリットはファイルを無くしても暗号化ボリュームの所有者が簡単に中身を思い出せることです。デメリットはパスフレーズの入力と比べてセキュリティ上の優位点がないことです。

例: {{ic|1234}}。

{{Note|パスフレーズが記述されたキーファイルに改行を含めてはいけません。以下のようなコマンドでファイルを作成できます:
# echo -n 'your_passphrase' > /path/to/<keyfile>
# chown root:root /path/to/<keyfile>; chmod 400 /path/to/<keyfile>
}}

==== randomtext ====

This is a keyfile containing a block of random characters. The benefit of this type of keyfile is that it is much more resistant to dictionary attacks than a simple passphrase. An additional strength of keyfiles can be utilized in this situation which is the length of data used. Since this is not a string meant to be memorized by a person for entry, it is trivial to create files containing thousands of random characters as the key. The disadvantage is that if this file is lost or changed, it will most likely not be possible to access the encrypted volume without a backup passphrase.

例: {{ic|fjqweifj830149-57 819y4my1-38t1934yt8-91m 34co3;t8y;9p3y-}}。

==== binary ====

This is a binary file that has been defined as a keyfile. When identifying files as candidates for a keyfile, it is recommended to choose files that are relatively static such as photos, music, video clips. The benefit of these files is that they serve a dual function which can make them harder to identify as keyfiles. Instead of having a text file with a large amount of random text, the keyfile would look like a regular image file or music clip to the casual observer. The disadvantage is that if this file is lost or changed, it will most likely not be possible to access the encrypted volume without a backup passphrase. Additionally, there is a theoretical loss of randomness when compared to a randomly generated text file. This is due to the fact that images, videos and music have some intrinsic relationship between neighboring bits of data that does not exist for a text file. However this is controversial and has never been exploited publicly.

例: 画像, テキスト, 動画。

=== ランダムな文字列でキーファイルを作成 ===

==== ファイルシステムにキーファイルを保存 ====

キーファイルの中身とサイズは任意に決められます。

以下では {{ic|dd}} を使って2048バイトのランダムなキーファイルを生成して、{{ic|/etc/mykeyfile}} ファイルに保存します:

# dd bs=512 count=4 if=/dev/urandom of=/etc/mykeyfile

キーファイルを外部デバイスに保存する場合、出力先を適切なディレクトリに変更します:

# dd bs=512 count=4 if=/dev/urandom of=/media/usbstick/mykeyfile

===== 保存されたキーファイルを完全に消去 =====

物理的なストレージデバイスに一時的なキーファイルを保存する場合、削除するときは、以下のように完全に削除してください:

# shred --remove --zero mykeyfile

FAT や ext2 であれば上記で十分ですが、ジャーナリングファイルシステムやフラッシュメモリハードウェアの場合、[[ディスクの完全消去]]あるいはキーファイルのあるパーティションを削除することを強く推奨します。

==== ramfs にキーファイルを保存 ====

もしくは、ramfs をマウントしてキーファイルを一時的に保存:

# mkdir /root/myramfs
# mount ramfs /root/myramfs/ -t ramfs
# cd /root/myramfs

物理ディスクではなくメモリ上に配置することで、ramfs をアンマウントしたら復元できないという利点があります。キーファイルを他の安全なファイルシステムにコピーしたら、以下のコマンドで ramfs をアンマウントしてください:
# umount /root/myramfs

=== キーファイルを使用するように LUKS を設定 ===

キーファイルのキースロットを LUKS ヘッダに追加:

{{hc|# cryptsetup luksAddKey /dev/sda2 /etc/mykeyfile|
Enter any LUKS passphrase:
key slot 0 unlocked.
Command successful.}}

=== キーファイルを使ってパーティションを手動でアンロック ===

LUKS デバイスをオープンするときに {{ic|--key-file}} オプションを使ってください:

# cryptsetup open /dev/sda2 ''dm_name'' --key-file /etc/mykeyfile

=== 起動時にロックを解除 ===

ファイルシステムのキーファイルを暗号化されたルートディレクトリの中に保存することで、システムの電源が切れているときに安全を確保することができ、[[Dm-crypt/システム設定#crypttab|crypttab]] によって起動時に自動的にマウントを解錠することができます。[[UUID]] を使用する例:
{{hc|/etc/crypttab|<nowiki>home UUID=<UUID identifier> /etc/mykeyfile</nowiki>}}
is all needed for unlocking, and
{{hc|/etc/fstab|/dev/mapper/home /home ext4 defaults 0 2}} for mounting the LUKS blockdevice with the generated keyfile.
{{Tip|If you prefer to use a {{ic|--plain}} mode blockdevice, the encryption options necessary to unlock it are specified in {{ic|/etc/crypttab}}. Take care to apply the systemd workaround mentioned in [[Dm-crypt/システム設定#crypttab|crypttab]] in this case.}}

=== キーファイルを使って起動時に root パーティションのロックを解除 ===

[[mkinitcpio]] を設定して必要なモジュールやファイルを記述して [[Dm-crypt/システム設定#cryptkey|cryptkey]] [[カーネルパラメータ]]を設定してキーファイルの場所を指定します。

2つの方法が存在します:

# 外部メディア (USB スティック) にキーファイルを保存
# initramfs にキーファイルを埋め込む

==== キーファイルを外部メディアに保存 ====

===== mkinitcpio の設定 =====

ドライブのファイルシステムを使うために {{ic|/etc/mkinitcpio.conf}} にモジュールを追加してください (以下の例では {{ic|vfat}} モジュール):
MODULES=(vfat)

In this example it is assumed that you use a FAT formatted USB drive ({{ic|vfat}} module). Replace those module names if you use another file system on your USB stick (e.g. {{ic|ext2}}) or another codepage. If it complains of bad superblock and bad codepage at boot, then you need an extra codepage module to be loaded. For instance, you may need {{ic|nls_iso8859-1}} module for {{ic|iso8859-1}} codepage.

If you have a non-US keyboard, it might prove useful to load your keyboard layout before you are prompted to enter the password to unlock the root partition at boot. For this, you will need the {{ic|keymap}} hook before {{ic|encrypt}}.

Generate a new initramfs image:

# mkinitcpio -p linux

===== カーネルパラメータの設定 =====

以下のオプションを[[カーネルパラメータ]]に追加してください ({{ic|encrypt}} フックではなく {{ic|sd-encrypt}} フックを使用する場合は [[Dm-crypt/システム設定#sd-encrypt フックを使う]]を参照):

cryptdevice=/dev/''<partition1>'':root cryptkey=/dev/''<partition2>'':<fstype>:<path>

例:

cryptdevice=/dev/sda3:root cryptkey=/dev/sdb1:vfat:/keys/secretkey

Choosing a plain filename for your key provides a bit of 'security through obscurity'. The keyfile can not be a hidden file, that means the filename must not start with a dot, or the {{ic|encrypt}} hook will fail to find the keyfile during the boot process.

{{ic|/dev/sdb1}} のようなデバイスノードの名前は再起動しても同じであるとは保証されていません。udev による[[永続的なブロックデバイスの命名]]を使ったほうが確実にデバイスにアクセスできます。外部ストレージデバイスからキーファイルを読み取るときに {{ic|encrypt}} フックが確実にキーファイルを見つけられるように、永続的なブロックデバイスの名前を絶対に使うべきです。[[永続的なブロックデバイスの命名]]を見て下さい。

==== キーファイルを initramfs に埋め込む ====

{{Warning|Use an embedded keyfile '''only''' if you have some form of authentication mechanism beforehand that protects the keyfile sufficiently. Otherwise auto-decryption will occur, defeating completely the purpose of block device encryption.}}

This method allows to use a specially named keyfile that will be embedded in the [[initramfs]] and picked up by the {{ic|encrypt}} [[Mkinitcpio#HOOKS|hook]] to unlock the root filesystem ({{ic|cryptdevice}}) automatically. It may be useful to apply when using the [[GRUB#暗号化された /boot|GRUB early cryptodisk]] feature, in order to avoid entering two passphrases during boot.

The {{ic|encrypt}} hook lets the user specify a keyfile with the {{ic|cryptkey}} kernel parameter: in the case of initramfs, the syntax is {{ic|rootfs:''path''}}, see [[Dm-crypt/システム設定#cryptkey]]. Besides, this kernel parameter defaults to use {{ic|/crypto_keyfile.bin}}, and if the initramfs contains a valid key with this name, decryption will occur automatically without the need to configure the {{ic|cryptkey}} parameter.

{{ic|encrypt}} の代わりに {{ic|sd-encrypt}} を使用する場合、{{ic|luks.key}} カーネルパラメータでキーファイルの場所を指定してください。[[Dm-crypt/システム設定#luks.key]] を参照。

[[#ランダムな文字列でキーファイルを作成|キーファイルを生成]]して適切な権限を与えて [[#LUKS キーの追加|LUKS キーとして追加]]:

# dd bs=512 count=4 if=/dev/urandom of=/crypto_keyfile.bin
# chmod 000 /crypto_keyfile.bin
# chmod 600 /boot/initramfs-linux*
# cryptsetup luksAddKey /dev/sdX# /crypto_keyfile.bin

{{Warning|When initramfs' permissions are set to 644 (by default), then all users will be able to dump the keyfile. Make sure the permissions are still 600 if you install a new kernel.}}

[[Mkinitcpio#BINARIES_と_FILES|mkinitcpio の FILES]] にキーを記述:

{{hc|/etc/mkinitcpio.conf|2=FILES=(/crypto_keyfile.bin)}}

最後に [[Mkinitcpio#イメージ作成とアクティベーション|initramfs を再生成]]してください。

次の起動時からコンテナを復号化するパスフレーズを入力するのは一度だけですむようになります。

詳しくは [http://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/#bonus-login-once こちら] を参照。