Dm-crypt/特記事項 - 版の履歴

Kusanaginoturugi: 二要素認証に用語を統一

2024-09-05T12:07:02Z

二要素認証に用語を統一

← 古い版		2024年9月5日 (木) 21:07時点における版
125行目:		125行目:
	== GPG や LUKS、OpenSSL の暗号化キーファイルを使う ==		== GPG や LUKS、OpenSSL の暗号化キーファイルを使う ==

	以下のフォーラム投稿では、この wiki ページの前の部分で説明したように平文のキーファイルを使うのではなく、2要素認証や gpg、openssl の暗号化キーファイルを使うための手順が示されています ([https://bbs.archlinux.org/viewtopic.php?id=120243 System Encryption using LUKS with GPG encrypted keys]):		以下のフォーラム投稿では、この wiki ページの前の部分で説明したように平文のキーファイルを使うのではなく、二要素認証や gpg、openssl の暗号化キーファイルを使うための手順が示されています ([https://bbs.archlinux.org/viewtopic.php?id=120243 System Encryption using LUKS with GPG encrypted keys]):

	* GnuPG: [https://bbs.archlinux.org/viewtopic.php?pid=943338#p943338 GPG 暗号化キーに関する投稿]。この投稿では一般的な手順が書かれてあります。		* GnuPG: [https://bbs.archlinux.org/viewtopic.php?pid=943338#p943338 GPG 暗号化キーに関する投稿]。この投稿では一般的な手順が書かれてあります。

Hikali: ‎ 誤字の修正 s/開放/解放/ in /* ソリッドステートドライブ (SSD) の Discard/TRIM のサポート */

2024-08-26T12:16:55Z

‎ 誤字の修正 s/開放/解放/ in ソリッドステートドライブ (SSD) の Discard/TRIM のサポート

← 古い版		2024年8月26日 (月) 21:16時点における版
207行目:		207行目:
	[[ソリッドステートドライブ]]を使用している場合、device-mapper はデフォルトでは TRIM コマンドを有効にしないので注意してください。デフォルト設定を上書きしないかぎりブロックデバイスは {{ic\|discard}} オプションが無効な状態でマウントされます。		[[ソリッドステートドライブ]]を使用している場合、device-mapper はデフォルトでは TRIM コマンドを有効にしないので注意してください。デフォルト設定を上書きしないかぎりブロックデバイスは {{ic\|discard}} オプションが無効な状態でマウントされます。

	セキュリティ上の問題があるため dm-crypt デバイスで TRIM のサポートがデフォルトで有効になることは永遠にないと device-mapper のメンテナは説明しています [http://www.saout.de/pipermail/dm-crypt/2011-September/002019.html][http://www.saout.de/pipermail/dm-crypt/2012-April/002420.html]。TRIM を有効にすると開放されたブロック情報という形でデータが漏洩する可能性が僅かにあり、そこから使用しているファイルシステムが判別される恐れがあります。TRIM を有効にすることによる問題の議論と説明は ''cryptsetup'' の開発者による [http://asalor.blogspot.de/2011/08/trim-dm-crypt-problems.html ブログ記事] で読むことができます。デバイスが昔 (cryptsetup <1.6.0) のデフォルト暗号である {{ic\|--cipher aes-cbc-essiv}} で暗号化されている場合、最新の[[Dm-crypt/デバイスの暗号化#LUKS モードの暗号化オプション\|デフォルト設定]]を使用している場合よりも TRIM されたセクタから多くの情報が漏洩する危険があります。		セキュリティ上の問題があるため dm-crypt デバイスで TRIM のサポートがデフォルトで有効になることは永遠にないと device-mapper のメンテナは説明しています [http://www.saout.de/pipermail/dm-crypt/2011-September/002019.html][http://www.saout.de/pipermail/dm-crypt/2012-April/002420.html]。TRIM を有効にすると解放されたブロック情報という形でデータが漏洩する可能性が僅かにあり、そこから使用しているファイルシステムが判別される恐れがあります。TRIM を有効にすることによる問題の議論と説明は ''cryptsetup'' の開発者による [http://asalor.blogspot.de/2011/08/trim-dm-crypt-problems.html ブログ記事] で読むことができます。デバイスが昔 (cryptsetup <1.6.0) のデフォルト暗号である {{ic\|--cipher aes-cbc-essiv}} で暗号化されている場合、最新の[[Dm-crypt/デバイスの暗号化#LUKS モードの暗号化オプション\|デフォルト設定]]を使用している場合よりも TRIM されたセクタから多くの情報が漏洩する危険があります。

	以下のケースに分かれます:		以下のケースに分かれます:

Kusanaginoturugi: カテゴリの修正

2024-06-08T04:48:45Z

カテゴリの修正

← 古い版		2024年6月8日 (土) 13:48時点における版
1行目:		1行目:
	{{Lowercase title}}		{{Lowercase title}}
	[[Category:デ~~ィスク~~暗号化]]		[[Category:保存データ暗号化]]
	[[en:dm-crypt/Specialties]]		[[en:dm-crypt/Specialties]]
	[[es:Dm-crypt (Español)/Specialties]]		[[es:Dm-crypt (Español)/Specialties]]

Kusanaginoturugi: /* 暗号化されていない boot パーティションのセキュア化 */ ユニファイドカーネルイメージに変更

2024-04-24T11:28:38Z

暗号化されていない boot パーティションのセキュア化: ユニファイドカーネルイメージに変更

← 古い版		2024年4月24日 (水) 20:28時点における版
13行目:		13行目:
	{{Warning\|1={{ic\|/boot}} パーティションと MBR をセキュア化することによりブートプロセス中に起こりうる数々の攻撃を緩和することはできますが、この方法で構成されたシステムは依然として BIOS/UEFI/ファームウェアの改ざん、ハードウェアキーロガー、コールドブート攻撃、そしてこの記事の範囲を超える他の多くの脅威に対しては脆弱である可能性があります。システムの信頼性の問題やディスク全体の暗号化に関連する問題の概要は、[https://www.youtube.com/watch?v=pKeiKYA03eE] を参照してください。}}		{{Warning\|1={{ic\|/boot}} パーティションと MBR をセキュア化することによりブートプロセス中に起こりうる数々の攻撃を緩和することはできますが、この方法で構成されたシステムは依然として BIOS/UEFI/ファームウェアの改ざん、ハードウェアキーロガー、コールドブート攻撃、そしてこの記事の範囲を超える他の多くの脅威に対しては脆弱である可能性があります。システムの信頼性の問題やディスク全体の暗号化に関連する問題の概要は、[https://www.youtube.com/watch?v=pKeiKYA03eE] を参照してください。}}

	{{Note\|[[UEFI]] を使用している場合、暗号化しないでおく必要があるのは [[ESP]] のみです ([[~~Unified~~ カーネルイメージ]]を使用している場合など)。この場合、[[セキュアブート]]を使用することにより、ブートプロセスが改ざんされていないことを保証することができます。これは、以下の方法と同じ効果を得ることのできる簡単な方法です。[[dm-crypt/システム全体の暗号化#Simple encrypted root with TPM2 and Secure Boot]]{{Broken section link}} を参照してください。}}		{{Note\|[[UEFI]] を使用している場合、暗号化しないでおく必要があるのは [[ESP]] のみです ([[ユニファイドカーネルイメージ]]を使用している場合など)。この場合、[[セキュアブート]]を使用することにより、ブートプロセスが改ざんされていないことを保証することができます。これは、以下の方法と同じ効果を得ることのできる簡単な方法です。[[dm-crypt/システム全体の暗号化#Simple encrypted root with TPM2 and Secure Boot]]{{Broken section link}} を参照してください。}}

	=== リムーバブルデバイスから起動 ===		=== リムーバブルデバイスから起動 ===

AshMyzk: "一度きりのパスワード無しの再起動" を追加

2023-09-24T03:19:52Z

"一度きりのパスワード無しの再起動" を追加

← 古い版		2023年9月24日 (日) 12:19時点における版
197行目:		197行目:
	# [[ブートローダー]]の設定を更新。例えば [[GRUB#メイン設定ファイルの生成\|GRUB]] の場合:{{bc\|# grub-mkconfig -o /boot/grub/grub.cfg}}		# [[ブートローダー]]の設定を更新。例えば [[GRUB#メイン設定ファイルの生成\|GRUB]] の場合:{{bc\|# grub-mkconfig -o /boot/grub/grub.cfg}}
	Remember to setup [[WiFi]], so you are able to login once the system is fully booted. In case you are unable to connect to the wifi network, try increasing the sleep times a bit.		Remember to setup [[WiFi]], so you are able to login once the system is fully booted. In case you are unable to connect to the wifi network, try increasing the sleep times a bit.

			== 一度きりのパスワード無しの再起動 ==

			ターミナルに暗号化済みルートドライブのパスワードを入力する必要なしにリモートのヘッドレスあるいはアクセス不能なシステムを再起動するためのもう一つの方法は、一時的な[[dm-crypt/システム設定#キーファイルでロックを解除する\|キーファイル]]を使用することです。キーファイルはブート時にカーネルからアクセス可能な場所に配置する必要があり、[[dm-crypt/システム設定#cryptkey\|cryptkey]] のブートパラメータを追加する必要があり、そして、そのキーファイルを "cryptsetup luksAddKey" コマンドを使って有効なキーとして登録する必要があります。

			この作業は {{AUR\|passless-boot}} を使えば簡単に行うことができます。[https://gitlab.com/Marcool04/passless-boot このツールの readme ファイル]で説明されているこのツールのセットアップ手順は、自身でセットアップする際のテンプレートとしても使えるかもしれません。[https://gitlab.com/Marcool04/passless-boot#security-considerations-and-threat-model Security considerations] の章での議論を参照してください。

	==ソリッドステートドライブ (SSD) の Discard/TRIM のサポート==		==ソリッドステートドライブ (SSD) の Discard/TRIM のサポート==

AshMyzk: /* GPG や LUKS、OpenSSL の暗号化キーファイルを使う */ 翻訳

2023-09-15T21:37:41Z

GPG や LUKS、OpenSSL の暗号化キーファイルを使う: 翻訳

← 古い版		2023年9月16日 (土) 06:37時点における版
125行目:		125行目:
	== GPG や LUKS、OpenSSL の暗号化キーファイルを使う ==		== GPG や LUKS、OpenSSL の暗号化キーファイルを使う ==

	~~The~~ ~~following~~ ~~forum~~ ~~posts give instructions to use two factor authentication,~~ gpg or openssl ~~encrypted keyfiles, instead of a plaintext keyfile described earlier in this wiki article~~ [https://bbs.archlinux.org/viewtopic.php?id=120243 System Encryption using LUKS with GPG encrypted keys]:		以下のフォーラム投稿では、この wiki ページの前の部分で説明したように平文のキーファイルを使うのではなく、2要素認証や gpg、openssl の暗号化キーファイルを使うための手順が示されています ([https://bbs.archlinux.org/viewtopic.php?id=120243 System Encryption using LUKS with GPG encrypted keys]):

	* GnuPG: [https://bbs.archlinux.org/viewtopic.php?pid=943338#p943338 ~~Post regarding~~ GPG ~~encrypted keys~~] ~~This post has the generic instructions.~~		* GnuPG: [https://bbs.archlinux.org/viewtopic.php?pid=943338#p943338 GPG 暗号化キーに関する投稿]。この投稿では一般的な手順が書かれてあります。
	* OpenSSL: [https://bbs.archlinux.org/viewtopic.php?pid=947805#p947805 ~~Post regarding~~ OpenSSL ~~encrypted keys~~] ~~This post only has the~~ {{ic\|ssldec}} ~~hooks.~~		* OpenSSL: [https://bbs.archlinux.org/viewtopic.php?pid=947805#p947805 OpenSSL 暗号化キーに関する投稿]。この投稿では {{ic\|ssldec}} フックが書かれてあるのみです。
	* OpenSSL: [https://bbs.archlinux.org/viewtopic.php?id=155393 ~~Post regarding~~ OpenSSL ~~salted~~ bf-cbc ~~encrypted keys~~] ~~This post has the~~ {{ic\|bfkf}} initcpio ~~hooks, install, and encrypted keyfile generator scripts.~~		* OpenSSL: [https://bbs.archlinux.org/viewtopic.php?id=155393 OpenSSL のソルトが付与された bf-cbc 暗号化キーに関する投稿]。この投稿では {{ic\|bfkf}} initcpio フック、インストールスクリプト、暗号化されたキーファイルの生成スクリプトが書かれてあります。
	* LUKS: [https://bbs.archlinux.org/viewtopic.php?pid=1502651#p1502651 ~~Post regarding~~ LUKS ~~encrypted keys~~] ~~with~~ ~~a {{ic\|lukskey}} initcpio hook.~~ Or [[#~~Encrypted~~ /boot ~~and a detached~~ LUKS ~~header~~ on ~~USB~~]] ~~below with a custom encrypt hook for initcpio.~~		* LUKS: {{ic\|lukskey}} initcpio フックと [https://bbs.archlinux.org/viewtopic.php?pid=1502651#p1502651 LUKS 暗号化キーに関する投稿]。あるいは、initcpio のカスタムの encrypt フックが書かれた以下の [[#/boot を暗号化し、デタッチされた LUKS ヘッダを USB 上に保存する]] を見てください。

			注意点:
	Note that:

			* 上記の手順に従う際に必要なのは 2 つの主要なパーティションだけです。1つはブートパーティション (暗号化のために必要) で、もう一つはプライマリ LVM パーティションです。この LVM パーティション内には好きなだけパーティションを作成できますが、最も重要なのは、少なくともルート、スワップ、ホームの論理ボリュームパーティションはこのパーティション内に作成する必要があるということです。これには、すべてのパーティションを1つのキーファイルだけで復号でき、さらに、暗号化されたスワップパーティションへハイバネートできるという利点があります。これを行う場合、{{ic\|/etc/mkinitcpio.conf}} でのフック配列は次のようになります: {{bc\|1=HOOKS=( ... usb usbinput (etwo または ssldec) encrypt (<- openssl を使用する場合) lvm2 resume ... )}} そして、次を[[カーネルパラメータ]]に追加する必要があります: {{bc\|1=resume=/dev/<VolumeGroupName>/<LVNameOfSwap>}}
	* You can follow the above instructions with only two primary partitions, one boot partition (required because of encryption) and one primary LVM partition. Within the LVM partition you can have as many partitions as you need, but most importantly it should contain at least root, swap, and home logical volume partitions. This has the added benefit of having only one keyfile for all your partitions, and having the ability to hibernate your computer (suspend to disk) where the swap partition is encrypted. If you decide to do so your hooks in {{ic\|/etc/mkinitcpio.conf}} should look like this:{{bc\|1=HOOKS=( ... usb usbinput (etwo or ssldec) encrypt (if using openssl) lvm2 resume ... )}} and you should add {{bc\|1=resume=/dev/<VolumeGroupName>/<LVNameOfSwap>}} to your [[kernel parameters]].
			* 暗号化されていないキーファイルを一時的にどこかに保存する必要がある場合、暗号化されていないディスク上には保存しないでください。{{ic\|/dev/shm}} などの RAM 上に保存するとなお良いです。
	* If you need to temporarily store the unencrypted keyfile somewhere, do not store them on an unencrypted disk. Even better make sure to store them to RAM such as {{ic\|/dev/shm}}.
			* GPG で暗号化されたキーファイルを使用したい場合、静的にコンパイルされた GnuPG バージョン 1.4 を使用する必要があります。これを使用しない場合、フックの配列を編集して {{AUR\|gnupg1}} を使用する必要があります。
	* If you want to use a GPG encrypted keyfile, you need to use a statically compiled GnuPG version 1.4 or you could edit the hooks and use {{AUR\|gnupg1}}
			* OpenSSL のアップデートにより、上記の2番目のフォーラムの投稿で言及されているカスタムの {{ic\|ssldec}} が壊れる可能性があります。
	* It is possible that an update to OpenSSL could break the custom {{ic\|ssldec}} mentioned in the second forum post.

	==root などのパーティションのリモート解除==		==root などのパーティションのリモート解除==

AshMyzk: /* GPG や OpenSSL で暗号化されたキーファイルを使う */ 同期

2023-09-08T07:41:09Z

GPG や OpenSSL で暗号化されたキーファイルを使う: 同期

AshMyzk: /* 暗号化されていない boot パーティションのセキュア化 */ 同期

2023-09-08T07:27:16Z

暗号化されていない boot パーティションのセキュア化: 同期

差分を表示

AshMyzk: 言語間リンクを同期

2023-09-08T04:10:00Z

言語間リンクを同期

← 古い版		2023年9月8日 (金) 13:10時点における版
1行目:		1行目:
	{{Lowercase title}}		{{Lowercase title}}
	[[Category:ディスク暗号化]]		[[Category:ディスク暗号化]]
	[[en:Dm-crypt/Specialties]]		[[en:dm-crypt/Specialties]]
			[[es:Dm-crypt (Español)/Specialties]]
			[[pl:Dm-crypt (Polski)/Specialties]]

	==暗号化されていない boot パーティションのセキュア化==		==暗号化されていない boot パーティションのセキュア化==

AshMyzk: リンクを修正

2023-07-10T00:56:50Z

リンクを修正

← 古い版		2023年7月10日 (月) 09:56時点における版
180行目:		180行目:
	# [[Mkinitcpio#イメージ作成とアクティベーション\|initramfs イメージを再生成]]。		# [[Mkinitcpio#イメージ作成とアクティベーション\|initramfs イメージを再生成]]。
	# [[ブートローダー]]の設定を更新。例えば [[GRUB#メイン設定ファイルの生成\|GRUB]] の場合:{{bc\|# grub-mkconfig -o /boot/grub/grub.cfg}}		# [[ブートローダー]]の設定を更新。例えば [[GRUB#メイン設定ファイルの生成\|GRUB]] の場合:{{bc\|# grub-mkconfig -o /boot/grub/grub.cfg}}
	Remember to setup [[~~ワイヤレス設定\|wifi~~]], so you are able to login once the system is fully booted. In case you are unable to connect to the wifi network, try increasing the sleep times a bit.		Remember to setup [[WiFi]], so you are able to login once the system is fully booted. In case you are unable to connect to the wifi network, try increasing the sleep times a bit.

	==ソリッドステートドライブ (SSD) の Discard/TRIM のサポート==		==ソリッドステートドライブ (SSD) の Discard/TRIM のサポート==

← 古い版		2023年9月8日 (金) 16:41時点における版
123行目:		123行目:
	論文の一部として、Arch Linux (2013年01月の時点の ISO) をベースにした[https://13.tc/p/potts/manual.html インストール]手順が公開されました。これを試したい場合、使われているツールが標準リポジトリ内に存在せず、この方法は維持に時間がかかることに注意してください。		論文の一部として、Arch Linux (2013年01月の時点の ISO) をベースにした[https://13.tc/p/potts/manual.html インストール]手順が公開されました。これを試したい場合、使われているツールが標準リポジトリ内に存在せず、この方法は維持に時間がかかることに注意してください。

	==GPG や OpenSSL で暗号化~~された~~キーファイルを使う==		== GPG や LUKS、OpenSSL の暗号化キーファイルを使う ==

	The following forum posts give instructions to use two factor authentication, gpg or openssl encrypted keyfiles, instead of a plaintext keyfile described earlier in this wiki article [https://bbs.archlinux.org/viewtopic.php?id=120243 System Encryption using LUKS with GPG encrypted keys]:		The following forum posts give instructions to use two factor authentication, gpg or openssl encrypted keyfiles, instead of a plaintext keyfile described earlier in this wiki article [https://bbs.archlinux.org/viewtopic.php?id=120243 System Encryption using LUKS with GPG encrypted keys]:

	* GnuPG: [https://bbs.archlinux.org/viewtopic.php?pid=943338#p943338 Post regarding GPG encrypted keys] This post has the generic instructions.		* GnuPG: [https://bbs.archlinux.org/viewtopic.php?pid=943338#p943338 Post regarding GPG encrypted keys] This post has the generic instructions.
	* OpenSSL: [https://bbs.archlinux.org/viewtopic.php?pid=947805#p947805 Post regarding OpenSSL encrypted keys] This post only has the {{ic\|ssldec}} hooks.		* OpenSSL: [https://bbs.archlinux.org/viewtopic.php?pid=947805#p947805 Post regarding OpenSSL encrypted keys] This post only has the {{ic\|ssldec}} hooks.
	* OpenSSL: [https://bbs.archlinux.org/viewtopic.php?id=155393 Post regarding OpenSSL salted bf-cbc encrypted keys] This post has the {{ic\|bfkf}} initcpio hooks, install, and encrypted keyfile generator scripts.		* OpenSSL: [https://bbs.archlinux.org/viewtopic.php?id=155393 Post regarding OpenSSL salted bf-cbc encrypted keys] This post has the {{ic\|bfkf}} initcpio hooks, install, and encrypted keyfile generator scripts.
	* LUKS: [https://bbs.archlinux.org/viewtopic.php?pid=1502651#p1502651 Post regarding LUKS encrypted keys] with a {{ic\|lukskey}} initcpio hook.		* LUKS: [https://bbs.archlinux.org/viewtopic.php?pid=1502651#p1502651 Post regarding LUKS encrypted keys] with a {{ic\|lukskey}} initcpio hook. Or [[#Encrypted /boot and a detached LUKS header on USB]] below with a custom encrypt hook for initcpio.

	Note that:		Note that:

	* You can follow the above instructions with only two primary partitions, one boot partition (required because of encryption) and one primary LVM partition. Within the LVM partition you can have as many partitions as you need, but most importantly it should contain at least root, swap, and home logical volume partitions. This has the added benefit of having only one keyfile for all your partitions, and having the ability to hibernate your computer (suspend to disk) where the swap partition is encrypted. If you decide to do so your hooks in {{ic\|/etc/mkinitcpio.conf}} should look like this:{{bc\|1=HOOKS=" ... usb usbinput (etwo or ssldec) encrypt (if using openssl) lvm2 resume ... "}} ~~そして[[カーネルパラメータ]]に以下を追加してください:~~ {{bc\|1=resume=/dev~~/mapper~~/<VolumeGroupName>-<LVNameOfSwap>}}		* You can follow the above instructions with only two primary partitions, one boot partition (required because of encryption) and one primary LVM partition. Within the LVM partition you can have as many partitions as you need, but most importantly it should contain at least root, swap, and home logical volume partitions. This has the added benefit of having only one keyfile for all your partitions, and having the ability to hibernate your computer (suspend to disk) where the swap partition is encrypted. If you decide to do so your hooks in {{ic\|/etc/mkinitcpio.conf}} should look like this:{{bc\|1=HOOKS=( ... usb usbinput (etwo or ssldec) encrypt (if using openssl) lvm2 resume ... )}} and you should add {{bc\|1=resume=/dev/<VolumeGroupName>/<LVNameOfSwap>}} to your [[kernel parameters]].
	* If you need to temporarily store the unencrypted keyfile somewhere, do not store them on an unencrypted disk. Even better make sure to store them to RAM such as {{ic\|/dev/shm}}.		* If you need to temporarily store the unencrypted keyfile somewhere, do not store them on an unencrypted disk. Even better make sure to store them to RAM such as {{ic\|/dev/shm}}.
			* If you want to use a GPG encrypted keyfile, you need to use a statically compiled GnuPG version 1.4 or you could edit the hooks and use {{AUR\|gnupg1}}
	* GPG で暗号化されたキーファイルを使いたい場合、静的にコンパイルされた GnuPG バージョン 1.4 を使う必要があります。もしくはフックを編集して AUR の {{AUR\|gnupg1}} パッケージを使ってください。
	* It is possible that an update to OpenSSL could break the custom {{ic\|ssldec}} mentioned in the second forum post.		* It is possible that an update to OpenSSL could break the custom {{ic\|ssldec}} mentioned in the second forum post.