Dm-crypt/ドライブの準備 - 版の履歴

Kusanaginoturugi: カテゴリの修正

2024-06-08T04:48:20Z

カテゴリの修正

← 古い版		2024年6月8日 (土) 13:48時点における版
1行目:		1行目:
	{{Lowercase title}}		{{Lowercase title}}
	[[Category:デ~~ィスク~~暗号化]]		[[Category:保存データ暗号化]]
	[[Category:ファイルシステム]]		[[Category:ファイルシステム]]
	[[en:Dm-crypt/Drive preparation]]		[[en:Dm-crypt/Drive preparation]]

Kusanaginoturugi: カテゴリを変更

2023-09-09T09:16:55Z

カテゴリを変更

← 古い版		2023年9月9日 (土) 18:16時点における版
1行目:		1行目:
	{{Lowercase title}}		{{Lowercase title}}
	[[Category:暗号化]]		[[Category:ディスク暗号化]]
	[[Category:ファイルシステム]]		[[Category:ファイルシステム]]
	[[en:Dm-crypt/Drive preparation]]		[[en:Dm-crypt/Drive preparation]]

Kusakata: 戻るリンクの削除

2017-12-23T15:23:28Z

戻るリンクの削除

← 古い版		2017年12月24日 (日) 00:23時点における版
4行目:		4行目:
	[[en:Dm-crypt/Drive preparation]]		[[en:Dm-crypt/Drive preparation]]
	[[es:Dm-crypt/Drive preparation]]		[[es:Dm-crypt/Drive preparation]]
	[[Dm-crypt]] に戻る。

	ドライブを暗号化する前に、ドライブ全体をランダムデータで上書きしてディスクを完全に消去するべきです。暗号攻撃や、望ましくない[[ファイルリカバリ]]がされないように、後から dm-crypt によって書き込まれたデータと判別がつかないようにするのが理想的です。もっと細かい話は[[ディスク暗号化#ディスクの準備]]を見て下さい。		ドライブを暗号化する前に、ドライブ全体をランダムデータで上書きしてディスクを完全に消去するべきです。暗号攻撃や、望ましくない[[ファイルリカバリ]]がされないように、後から dm-crypt によって書き込まれたデータと判別がつかないようにするのが理想的です。もっと細かい話は[[ディスク暗号化#ディスクの準備]]を見て下さい。

Kusakata: カテゴリ変更

2017-11-02T16:06:55Z

カテゴリ変更

← 古い版		2017年11月3日 (金) 01:06時点における版
1行目:		1行目:
	{{Lowercase title}}		{{Lowercase title}}
	[[Category:~~セキュリティ~~]]		[[Category:暗号化]]
	[[Category:ファイルシステム]]		[[Category:ファイルシステム]]
	[[en:Dm-crypt/Drive preparation]]		[[en:Dm-crypt/Drive preparation]]

Kusakata: 同期

2017-10-11T14:39:11Z

同期

← 古い版		2017年10月11日 (水) 23:39時点における版
3行目:		3行目:
	[[Category:ファイルシステム]]		[[Category:ファイルシステム]]
	[[en:Dm-crypt/Drive preparation]]		[[en:Dm-crypt/Drive preparation]]
			[[es:Dm-crypt/Drive preparation]]
	[[Dm-crypt]] に戻る。		[[Dm-crypt]] に戻る。

Kusakata: 同期

2017-03-03T15:51:12Z

同期

← 古い版		2017年3月4日 (土) 00:51時点における版
23行目:		23行目:

	=== dm-crypt 固有の方法 ===		=== dm-crypt 固有の方法 ===
			以下の2つの方法はどちらも dm-crypt 専用の方法で、非常に高速な消去が可能でパーティションを設定した後でも実行できます。
	The following two methods are specific for dm-crypt and are mentioned because they are very fast and can be performed after a partition setup too.

	~~The~~ [https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#5-security-aspects cryptsetup FAQ] ~~mentions a very simple procedure to use an existing~~ dm-crypt~~-volume~~ to wipe all free space accessible on the underlying block device with random data by acting as a simple pseudorandom number generator. It is also claimed to protect against disclosure of usage patterns. That is because encrypted data is practically indistinguishable from random.		[https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#5-security-aspects cryptsetup FAQ] には既存の dm-crypt ボリュームをシンプルな疑似乱数生成器として使って簡単にブロックデバイスの空き領域をランダムなデータで消去する方法が載っています。ランダムなデータで消去することで使用パターンが漏洩するのを防ぐことが可能です。暗号化されたデータはランダムなデータと基本的に見分けが付きません。

	==== dm-crypt で空のディスクまたはパーティションを消去 ====		==== dm-crypt で空のディスクまたはパーティションを消去 ====
43行目:		43行目:

	{{Tip\|		{{Tip\|
			* ディスクのスループットを向上させるために、''dd'' を使うときはよく {{ic\|1=bs=}} オプションが使用されます。例: {{ic\|1=bs=1M}}。
	* Using ''dd'' with the {{ic\|1=bs=}} option, e.g. {{ic\|1=bs=1M}}, is frequently used to increase disk throughput of the operation.
			* 操作のチェックを実行したい場合、コンテナを作成するまえにパーティションをゼロ埋めしてください。消去後、{{ic\|blockdev --getsize64 ''/dev/mapper/container''}} を root で実行することでコンテナの正確なサイズを確認できます。消去が隅々まで行われたことを確認したい場合、''od'' を使うことでゼロ埋めされたセクタが上書きされているか抽出検査できます。例: {{ic\|od -j ''containersize - blocksize''}}。}}
	* To perform a check of the operation, zero the partition before creating the wipe container. After the wipe command {{ic\|blockdev --getsize64 ''/dev/mapper/container''}} can be used to get the exact container size as root. Now ''od'' can be used to spotcheck whether the wipe overwrote the zeroed sectors, e.g. {{ic\|od -j ''containersize - blocksize''}} to view the wipe completed to the end.}}

	最後に、一時コンテナを施錠:		最後に、一時コンテナを施錠:
66行目:		66行目:

	==== LUKS ヘッダーを消去 ====		==== LUKS ヘッダーを消去 ====
			dm-crypt/LUKS でフォーマットしたパーティションには使用している暗号や暗号オプションが記載されたヘッダーが含まれており、ブロックデバイスを解錠するときに {{ic\|dm-mod}} から参照されます。ヘッダーの後にランダムなデータのパーティションが来ます。既にランダム化したドライブに再インストールするときやドライブを廃棄処分するときは (パソコンを売るときやディスクを交換するときなど)、わざわざディスク全体を上書きする必要はありません。パーティションのヘッダーを消去すれば十分です。
	The partitions formatted with dm-crypt/LUKS contain a header with the cipher and crypt-options used, which is referred to {{ic\|dm-mod}} when opening the blockdevice. After the header the actual random data partition starts. Hence, when re-installing on an already randomized drive, or de-commissioning one (e.g. sale of PC, switch of drives, etc.) it ''may'' be just enough to wipe the header of the partition, rather than overwriting the whole drive - which can be a lengthy process.

			LUKS ヘッダーを消去すると PBKDF2 で暗号化された (AES) マスター鍵やソルトなども削除されます。
	Wiping the LUKS header will delete the PBKDF2-encrypted (AES) master key, salts and so on.

	{{Note\|It is crucial to write to the LUKS encrypted partition ({{ic\|/dev/sda'''1'''}} in this example) and not directly to the disks device node. Setups with encryption as a device-mapper layer on top of others, e.g. LVM on LUKS on RAID should then write to RAID respectively.}}		{{Note\|It is crucial to write to the LUKS encrypted partition ({{ic\|/dev/sda'''1'''}} in this example) and not directly to the disks device node. Setups with encryption as a device-mapper layer on top of others, e.g. LVM on LUKS on RAID should then write to RAID respectively.}}

			キースロットのサイズがデフォルトの256ビットのヘッダーなら、容量は 1024KB です。dm-crypt によって書き込まれる最初の 4KB も上書きすることが推奨されているため、合計で 1028KB だけ削除すれば良いことになります。バイトになおすと {{ic\|1052672}} です。
	A header with one single default 256 bit size keyslot is 1024KB in size. It is advised to also overwrite the first 4KB written by dm-crypt, so 1028KB have to be wiped. That is {{ic\|1052672}} Byte.

			オフセットがゼロの場合、以下のコマンドでヘッダーを消去できます:
	For zero offset use:
	# head -c 1052672 /dev/urandom > /dev/sda1; sync		# head -c 1052672 /dev/urandom > /dev/sda1; sync

			鍵長が512ビットの場合、ヘッダーは 2MB です (例: 512ビット鍵の aes-xts-plain)。
	For 512 bit key length (e.g. for aes-xts-plain with 512 bit key) the header is 2MB.

			心配であれば、10MB ほど上書きしてしまえば安全です:
	If in doubt, just be generous and overwrite the first 10MB or so.

	# dd if=/dev/urandom of=/dev/sda1 bs=512 count=20480		# dd if=/dev/urandom of=/dev/sda1 bs=512 count=20480
85行目:		85行目:
	{{Note\|With a backup-copy of the header data can get rescued but the filesystem was likely damaged as the first encrypted sectors were overwritten. See further sections on how to make a backup of the crucial header blocks.}}		{{Note\|With a backup-copy of the header data can get rescued but the filesystem was likely damaged as the first encrypted sectors were overwritten. See further sections on how to make a backup of the crucial header blocks.}}

			ヘッダーをランダムデータで消去すると、後はデバイスに残っているのは暗号化されたデータだけになります。SSD の場合はキャッシュの存在があるため、完全には消去されない可能性があります。万一過去にヘッダーがキャッシュされた場合、ヘッダーを消去した後でもキャッシュからアクセスできる可能性が理論上排除できません。セキュリティを完全なものにしたい場合、SSD の Secure ATA Erase を実行すると良いでしょう (詳しくは cryptsetup の [https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#5-security-aspects FAQ 5.19] を参照)。
	When wiping the header with random data everything left on the device is encrypted data. An exception to this may occur for an SSD, because of cache blocks SSDs employ. In theory it may happen that the header was cached in these some time before and that copy may consequently be still available after wiping the original header. For strong security concerns, a secure ATA erase of the SSD should be done (procedure please see the cryptsetup [https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#5-security-aspects FAQ 5.19]).

	==パーティショニング==		==パーティショニング==
101行目:		101行目:
	=== スタックブロックデバイス ===		=== スタックブロックデバイス ===

			もっと柔軟な構成にしたい場合、[[LVM]] や [[RAID]] などのスタックブロックデバイスと dm-crypt を共存させることができます。暗号化したコンテナを他のスタックブロックデバイスの上あるいは下に配置することが可能です:
	If more flexibility is needed, though, dm-crypt can coexist with other stacked block devices like [[LVM]] and [[RAID]]. The encrypted containers can either reside below or on top of other stacked block devices:

			* 暗号化レイヤーの上に LVM/RAID デバイスを作成した場合、文字通り同じ暗号化パーティションのファイルシステムを追加・削除・リサイズすることが可能になります。そしてファイルシステムに必要な鍵やパスフレーズはひとつだけで足ります。物理パーティション上に存在するのは暗号化レイヤーになるため、LVM や RAID を悪用してデータを盗み出すことは不可能です。
	* If the LVM/RAID devices are created on top of the encrypted layer, it will be possible to add, remove and resize the file systems of the same encrypted partition liberally, and only one key or passphrase will be required for all of them. Since the encrypted layer resides on a physical partition, though, it will not be possible to exploit the ability of LVM and RAID to span multiple disks.
			* LVM/RAID デバイスの上に暗号化レイヤーを作成した場合、後でファイルシステムを再構築することができますが、暗号化レイヤーも下のデバイスにあわせて変更しなければならなくなるため、複雑性が増します。さらに、暗号化デバイスそれぞれに別々のパスフレーズや鍵が必要になります。しかしながら、複数のデバイスにまたがるように暗号化ファイルシステムを作成したい場合は唯一の選択となります。
	* If the encrypted layer is created on top of LVM/RAID devices, it will still be possible to reorganize the file systems in the future, but with added complexity, since the encryption layers will have to be adjusted accordingly. Moreover, separate passphrases or keys will be required to open each encrypted device. This, however, is the only choice for systems that need encrypted file systems to span multiple disks.

	=== Btrfs のサブボリューム ===		=== Btrfs のサブボリューム ===

Kusakata: 同期

2016-10-12T15:11:30Z

同期

差分を表示

2015年8月20日 (木) 10:33にKusakataによる

2015-08-20T10:33:31Z

← 古い版		2015年8月20日 (木) 19:33時点における版
21行目:		21行目:
	The following methods are specific for dm-crypt and are mentioned complementarily, because they are very fast and can be performed after a partition setup too.		The following methods are specific for dm-crypt and are mentioned complementarily, because they are very fast and can be performed after a partition setup too.

	The [~~http~~://~~code.google~~.com/p/cryptsetup/~~wiki~~/FrequentlyAskedQuestions#5~~._Security_Aspects~~ cryptsetup FAQ] mentions a very simple procedure to use an existing dm-crypt-volume to wipe all free space accessible on the underlying block device with random data by acting as a simple pseudorandom number generator. It is also claimed to protect against disclosure of usage patterns.		The [https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#5-security-aspects cryptsetup FAQ] mentions a very simple procedure to use an existing dm-crypt-volume to wipe all free space accessible on the underlying block device with random data by acting as a simple pseudorandom number generator. It is also claimed to protect against disclosure of usage patterns.

	==== インストール前に dm-crypt で消去 ====		==== インストール前に dm-crypt で消去 ====
31行目:		31行目:
	Disk /dev/mapper/container does not contain a valid partition table}}		Disk /dev/mapper/container does not contain a valid partition table}}
	Finally, wipe it with pseudorandom (encrypted data), a use of {{ic\|/dev/urandom}} is not required as the encryption cipher is used for randomness:		Finally, wipe it with pseudorandom (encrypted data), a use of {{ic\|/dev/urandom}} is not required as the encryption cipher is used for randomness:
	{{hc\|# dd <nowiki>if=/dev/zero of=~~</nowiki>~~/dev/mapper/container\|		{{hc\|# dd <nowiki>if=/dev/zero of=/dev/mapper/container</nowiki>\|
	dd: writing to ‘/dev/mapper/container’: No space left on device}}		dd: writing to ‘/dev/mapper/container’: No space left on device}}
			{{Note\|
	Now the next step is [[#Partitioning]].
			* Regularly ''dd'' is used with a block size larger than default, for example {{ic\|1=bs=4M}}, to gain higher throughput. Using it with dm-crypt is detrimental, because it has the same default block size of 512 bytes and the command may exit before wiping the final blocks when a larger one is used.
			* For daily operation the performance loss of disk I/O operations with dm-crypt is not adversely affected by this. If the filesystem performs 4K operations, dm-crypt will process eight blocks at a time. It is important though that the underlying partition is aligned to disk geometry correctly when it is created.}}
			次は[[#パーティショニング\|パーティショニング]]です。

	==== インストール後に dm-crypt で空き領域を消去 ====		==== インストール後に dm-crypt で空き領域を消去 ====
65行目:		68行目:
	{{Note\|With a backup-copy of the header data can get rescued but the filesystem was likely damaged as the first encrypted sectors were overwritten. See further sections on how to make a backup of the crucial header blocks.}}		{{Note\|With a backup-copy of the header data can get rescued but the filesystem was likely damaged as the first encrypted sectors were overwritten. See further sections on how to make a backup of the crucial header blocks.}}

	When wiping the header with random data everything left on the device is encrypted data. An exception to this may occur for an SSD, because of cache blocks SSDs employ. In theory it may happen that the header was cached in these some time before and that copy may consequently be still available after wiping the original header. For strong security concerns, a secure ATA erase of the SSD should be done (procedure please see the cryptsetup [~~http~~://~~code.google~~.com/p/cryptsetup/~~wiki~~/FrequentlyAskedQuestions#5~~._Security_Aspects~~ FAQ 5.19]).		When wiping the header with random data everything left on the device is encrypted data. An exception to this may occur for an SSD, because of cache blocks SSDs employ. In theory it may happen that the header was cached in these some time before and that copy may consequently be still available after wiping the original header. For strong security concerns, a secure ATA erase of the SSD should be done (procedure please see the cryptsetup [https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#5-security-aspects FAQ 5.19]).

	==パーティショニング==		==パーティショニング==

			このセクションはシステム全体を暗号化する場合にのみあてはまります。ドライブを完全に上書きしたら、dm-crypt の要件を満たすように、慎重にパーティションスキームを決定する必要があります。ここで決めたことが結果的にシステムの管理に影響してきます。
	This section only applies when encrypting an entire system. After the drive(s) has/have been securely overwritten, a proper partitioning scheme will have to be accurately chosen, taking into account the requirements of dm-crypt, and the effects that the various choices will have on the management of the resulting system.

			ここからどんな場合でも {{ic\|/boot}} のパーティションは暗号化されていない状態にしておく必要があります。ブートローダーは {{ic\|/boot}} ディレクトリにアクセスする必要があり、システムをロードするために必要な initramfs や暗号化モジュールをロードします (詳しくは [[mkinitcpio]] を参照)。これがセキュリティ上問題となる場合、[[dm-crypt/特記事項#暗号化されていない boot パーティションのセキュア化]] を見て下さい。
	It is important to note from now that in every case there has to be a separate partition for {{ic\|/boot}} that must remain unencrypted, because the bootloader needs to access the {{ic\|/boot}} directory where it will load the initramfs/encryption modules needed to load the rest of the system (see [[mkinitcpio]] for details). If this raises security concerns, see [[dm-crypt/Specialties#Securing the unencrypted boot partition]].

			また、スワップ領域やサスペンドをどうするかというのも大事な点です。[[dm-crypt/スワップの暗号化]]を見て下さい。
	Another important factor to take into account is how the swap area and system suspension will be handled, see [[dm-crypt/Swap encryption]].

	=== 物理パーティション ===		=== 物理パーティション ===

	In the simplest case, the encrypted layers can be based directly on the physical partitions; see [[~~Partitioning~~]] for the methods to create them. Just like in an unencrypted system, a root partition is sufficient, besides another for {{ic\|/boot}} as noted above. This method allows deciding which partitions to encrypt and which to leave unencrypted, and works the same regardless of the number of disks involved. It will also be possible to add or remove partitions in the future, but resizing a partition will be limited by the size of the disk that is hosting it. Finally note that separate passphrases or keys are required to open each encrypted partition, even though this can be automated during boot using the {{ic\|crypttab}} file, see [[Dm-crypt/~~System configuration~~#crypttab]].		In the simplest case, the encrypted layers can be based directly on the physical partitions; see [[パーティショニング]] for the methods to create them. Just like in an unencrypted system, a root partition is sufficient, besides another for {{ic\|/boot}} as noted above. This method allows deciding which partitions to encrypt and which to leave unencrypted, and works the same regardless of the number of disks involved. It will also be possible to add or remove partitions in the future, but resizing a partition will be limited by the size of the disk that is hosting it. Finally note that separate passphrases or keys are required to open each encrypted partition, even though this can be automated during boot using the {{ic\|crypttab}} file, see [[Dm-crypt/システム設定#crypttab]].

	=== スタックブロックデバイス ===		=== スタックブロックデバイス ===
88行目:		91行目:
	=== Btrfs のサブボリューム ===		=== Btrfs のサブボリューム ===

			[[Btrfs]] の[[Btrfs#サブボリューム\|サブボリューム機能]]を dm-crypt で使うこともできます。他のファイルシステムが必要ない場合 LVM を完全に置き換えることが可能です。ただし、スワップの暗号化はできないので注意してください。今のところ btrfs はスワップファイルをサポートしていません [https://btrfs.wiki.kernel.org/index.php/FAQ#Does_btrfs_support_swap_files.3F]。
	[[Btrfs]]'s built-in [[Btrfs#Sub-volumes\|subvolumes feature]] can be used with dm-crypt, fully replacing the need for LVM if no other file systems are required. However, note that an encrypted swap is not possible this way and swap files are [https://btrfs.wiki.kernel.org/index.php/FAQ#Does_btrfs_support_swap_files.3F not supported] by btrfs up to now.

Kusakata: ページの作成:「{{Lowercase title}} Category:セキュリティ Category:ファイルシステム en:Dm-crypt/Drive preparation Dm-crypt に戻る。ドライブを暗...」

2015-02-13T09:44:25Z

ページの作成:「{{Lowercase title}} Category:セキュリティ Category:ファイルシステム en:Dm-crypt/Drive preparation Dm-crypt に戻る。ドライブを暗...」

新規ページ

{{Lowercase title}}
[[Category:セキュリティ]]
[[Category:ファイルシステム]]
[[en:Dm-crypt/Drive preparation]]
[[Dm-crypt]] に戻る。

ドライブを暗号化する前に、ドライブ全体をランダムデータで上書きしてディスクを完全に消去するべきです。暗号攻撃や、望ましくない[[ファイルリカバリ]]がされないように、後から dm-crypt によって書き込まれたデータと判別がつかないようにするのが理想的です。もっと細かい話は[[ディスク暗号化#ディスクの準備]]を見て下さい。

== ハードディスクドライブの完全消去 ==

In deciding which method to use for secure erasure of a hard disk drive, remember that this needs only to be performed once for as long as the drive is used as an encrypted drive.

{{Warning|Make appropriate backups of valuable data prior to starting.}}

{{Tip|The process of filling an encrypted drive can take over a day to complete on a multi-terabyte disk. In order not to leave the machine unusable during the operation, it may be worth to do it from a system already installed on another drive, rather than from the live Arch installation system.}}

=== 一般的な方法 ===
ドライブを消去して準備する詳しい手順は[[ディスクの完全消去]]を見て下さい。

=== dm-crypt 固有の方法 ===
The following methods are specific for dm-crypt and are mentioned complementarily, because they are very fast and can be performed after a partition setup too.

The [http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions#5._Security_Aspects cryptsetup FAQ] mentions a very simple procedure to use an existing dm-crypt-volume to wipe all free space accessible on the underlying block device with random data by acting as a simple pseudorandom number generator. It is also claimed to protect against disclosure of usage patterns.

==== インストール前に dm-crypt で消去 ====
First, create a temporary encrypted container on the partition ({{ic|sdXY}}) or the full disk ({{ic|sdX}}) you want to encrypt, e.g. using default parameters
# cryptsetup open --type plain /dev/sdXY container
Second, check it exists
{{hc|# fdisk -l|Disk /dev/mapper/container: 1000 MB, 1000277504 bytes
...
Disk /dev/mapper/container does not contain a valid partition table}}
Finally, wipe it with pseudorandom (encrypted data), a use of {{ic|/dev/urandom}} is not required as the encryption cipher is used for randomness:
{{hc|# dd <nowiki>if=/dev/zero of=</nowiki>/dev/mapper/container|
dd: writing to ‘/dev/mapper/container’: No space left on device}}
Now the next step is [[#Partitioning]].

==== インストール後に dm-crypt で空き領域を消去 ====

The same effect can be achieved if a file is created on an encrypted partition that fills the free space of the partition completely after the system is installed, booted and filesystems mounted. That is because encrypted data is practically indistinguishable from random.

{{bc|1=
# dd if=/dev/zero of=/file/in/container
# rm /file/in/container}}

The above process has to be repeated for every partition blockdevice created.

==== LUKS ヘッダーを消去 ====
The partitions formatted with dm-crypt/LUKS contain a header with the cipher and crypt-options used, which is referred to {{ic|dm-mod}} when opening the blockdevice. After the header the actual random data partition starts. Hence, when re-installing on an already randomised drive, or de-commissioning one (e.g. sale of PC, switch of drives, etc.) it ''may'' be just enough to wipe the header of the partition, rather than overwriting the whole drive - which can be a lengthy process.

Wiping the LUKS header will delete the PBKDF2-encrypted (AES) master key, salts and so on.

{{Note|It is crucial to write to the LUKS encrypted partition ({{ic|/dev/sda'''1'''}} in this example) and not directly to the disks device node. If you did set up encryption as a device-mapper layer on top of others, e.g. LVM on LUKS on RAID then write to RAID respectively.}}

A header with one single default 256 bit size keyslot is 1024KB in size. It is advised to also overwrite the first 4KB written by dm-crypt, so 1028KB have to be wiped. That is {{ic|1052672}} Byte.

For zero offset use:
#head -c 1052672 /dev/zero > /dev/sda1; sync

For 512 bit key length (e.g. for aes-xts-plain with 512 bit key) the header is 2MB.

If in doubt, just be generous and overwrite the first 10MB or so.

#dd if=/dev/zero of=/dev/sda1 bs=512 count=20480

{{Note|With a backup-copy of the header data can get rescued but the filesystem was likely damaged as the first encrypted sectors were overwritten. See further sections on how to make a backup of the crucial header blocks.}}

When wiping the header with random data everything left on the device is encrypted data. An exception to this may occur for an SSD, because of cache blocks SSDs employ. In theory it may happen that the header was cached in these some time before and that copy may consequently be still available after wiping the original header. For strong security concerns, a secure ATA erase of the SSD should be done (procedure please see the cryptsetup [http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions#5._Security_Aspects FAQ 5.19]).

==パーティショニング==

This section only applies when encrypting an entire system. After the drive(s) has/have been securely overwritten, a proper partitioning scheme will have to be accurately chosen, taking into account the requirements of dm-crypt, and the effects that the various choices will have on the management of the resulting system.

It is important to note from now that in every case there has to be a separate partition for {{ic|/boot}} that must remain unencrypted, because the bootloader needs to access the {{ic|/boot}} directory where it will load the initramfs/encryption modules needed to load the rest of the system (see [[mkinitcpio]] for details). If this raises security concerns, see [[dm-crypt/Specialties#Securing the unencrypted boot partition]].

Another important factor to take into account is how the swap area and system suspension will be handled, see [[dm-crypt/Swap encryption]].

=== 物理パーティション ===

In the simplest case, the encrypted layers can be based directly on the physical partitions; see [[Partitioning]] for the methods to create them. Just like in an unencrypted system, a root partition is sufficient, besides another for {{ic|/boot}} as noted above. This method allows deciding which partitions to encrypt and which to leave unencrypted, and works the same regardless of the number of disks involved. It will also be possible to add or remove partitions in the future, but resizing a partition will be limited by the size of the disk that is hosting it. Finally note that separate passphrases or keys are required to open each encrypted partition, even though this can be automated during boot using the {{ic|crypttab}} file, see [[Dm-crypt/System configuration#crypttab]].

=== スタックブロックデバイス ===

If more flexibility is needed, though, dm-crypt can coexist with other stacked block devices like [[LVM]] and [[RAID]]. The encrypted containers can either reside below or on top of other stacked block devices:

* If the LVM/RAID devices are created on top of the encrypted layer, it will be possible to add, remove and resize the file systems of the same encrypted partition liberally, and only one key or passphrase will be required for all of them. Since the encrypted layer resides on a physical partition, though, it will not be possible to exploit the ability of LVM and RAID to span multiple disks.
* If the encrypted layer is created on top of LVM/RAID devices, it will still be possible to reorganize the file systems in the future, but with added complexity, since the encryption layers will have to be adjusted accordingly. Moreover, separate passphrases or keys will be required to open each encrypted device. This, however, is the only choice for systems that need encrypted file systems to span multiple disks.

=== Btrfs のサブボリューム ===

[[Btrfs]]'s built-in [[Btrfs#Sub-volumes|subvolumes feature]] can be used with dm-crypt, fully replacing the need for LVM if no other file systems are required. However, note that an encrypted swap is not possible this way and swap files are [https://btrfs.wiki.kernel.org/index.php/FAQ#Does_btrfs_support_swap_files.3F not supported] by btrfs up to now.

Dm-crypt/ドライブの準備 - 版の履歴

Kusanaginoturugi: カテゴリの修正

Kusanaginoturugi: カテゴリを変更

Kusakata: 戻るリンクの削除

Kusakata: カテゴリ変更

Kusakata: 同期

Kusakata: 同期

Kusakata: 同期

2015年8月20日 (木) 10:33にKusakataによる

Kusakata: ページの作成:「{{Lowercase title}} Category:セキュリティ Category:ファイルシステム en:Dm-crypt/Drive preparation Dm-crypt に戻る。 ドライブを暗...」

Kusakata: ページの作成:「{{Lowercase title}} Category:セキュリティ Category:ファイルシステム en:Dm-crypt/Drive preparation Dm-crypt に戻る。ドライブを暗...」