1 files changed, 132 insertions, 0 deletions
diff --git a/articles/luks.html b/articles/luks.html
new file mode 100644
index 0000000..d2bbc5e
--- /dev/null
+++ b/articles/luks.html
@@ -0,0 +1,132 @@
+<!DOCTYPE html>
+<html lang=en>
+    <head>
+        <title></title>
+        <meta charset="utf-8"/>
+        <link rel="shortcut icon" href="favicon.ico"/>
+        <link rel='stylesheet' href='../style.css'/>
+        <meta name="viewport" content="width=device-width, initial-scale=1">
+    </head>
+<body>
+    <header><h1>LUKS Block Device Encryption</h1></header>
+    <main>
+                        <p>Linux Unified Key Setup (LUKS) is a method for encrypting 
+                        block devices that is built-in to the Linux Kernel. In this tutorial 
+                        I will be showing how to create an encrypted USB drive with LUKS, but 
+                        this process is applicable to other types of storage. 
+                        <strong>This process will wipe all data on the device that you 
+                        encrypt so make backups beforehand if needed</strong>.</p>
+                        <h2>Install Packages</h2>
+                        <p>Install cryptsetup and its dependencies</p>
+                        <pre><code>apt install cryptsetup</code></pre>
+                        <h2>Prepare the Drive</h2>
+                        <p>If the device you are encrypting was previously used, you will 
+                        want to completely overwrite any data on it before encryption. This 
+                        can be done using <strong>dd</strong> as shown below. This could take 
+                        a very long time depending on the size and type of your drive. 
+                        Be sure that you enter the correct path to your drive as the 
+                        argument to <strong>of</strong>, and do not specify a partition:
+                        <strong>/dev/sdb</strong> is correct, <strong>/dev/sdb1</strong> is 
+                        wrong. Obviously this will destroy any data on the device so be 
+                        absolutely sure you specify the correct device in the command 
+                        and have backups of data previously stored if needed.</p>
+                        <pre><code>dd if=/dev/zero of=<em>/dev/sdX</em> status=progress</code></pre>
+                        <h2>Encrypt the Drive</h2>
+                        <p><strong>cryptsetup</strong> is the main command used to perform 
+                        LUKS-related tasks. This main command is followed by a subcommand 
+                        that specifies which action to perform. To create a LUKS partition 
+                        on a drive we need to use the subcommand <strong>luksFormat</strong>. 
+                        We also use the type option to explicitly say to use LUKS version 2 
+                        encryption. Run the command and then enter and confirm the 
+                        encryption password.</p>
+                        <pre><code>cryptsetup --type luks2 luksFormat <em>/dev/sdX</em></code></pre>
+                        <p>Now we need to open and map the encrypted LUKS device. This is done 
+                        by using the <strong>luksOpen</strong> subcommand. This subcommand takes 
+                        the device as the first argument and then a map target as the second. The 
+                        map target can be any string as long as a map does not already exist with 
+                        that name. In the example I will use <em>crypt</em>.
+                        <pre><code>cryptsetup luksOpen <em>/dev/sdX crypt</em></code></pre>
+                        <p>And then we just need to create a filesystem on the device; I will 
+                        be making an ext4 filesystem in the example. To 
+                        interact with an encrypted drive after it has been opened you need 
+                        to refer to its device mapper target, which is found under /dev/mapper. 
+                        Since we used <em>crypt</em> as the map target, our encrypted drive 
+                        is /dev/mapper/<em>crypt</em>. </p>
+                        <pre><code>mkfs.ext4 /dev/mapper/<em>crypt</em></code></pre>
+                        <p>After creating the filesystem created the encrypted drive 
+                        can now be mounted and used like any other device. Remember that 
+                        when mounting the device you refer to the device mapper target 
+                        (mount /dev/mapper/<em>crypt</em> /mnt/crypt).</p>
+                        <p>In addition to unmounting the filesystem you should always close 
+                        the device mapping before removing your encrypted drive. This is 
+                        done with the <strong>luksClose</strong> subcommand and takes 
+                        the device mapping as the argument.</p>
+                        <pre><code>cryptsetup luksClose /dev/mapper/<em>crypt</em></code></pre>
+                        <h2>The LUKS Header</h2>
+                        <p>The LUKS header sits at the front of your encrypted drive and is 
+                        responsible for managing access to the device. If the header is 
+                        damaged accessing your encrypted data will not be possible. Because of 
+                        this, you may want to make backups of the header, but before doing so 
+                        you need to weigh the risks and benefits.</p>
+                        <p>The obvious benefit is that 
+                        in the event of damage to the LUKS header, you can easily restore a 
+                        backup and regain access to the data. However, having a backup of the 
+                        header makes it harder to wipe the LUKS device. Without a header 
+                        backup, overwriting the LUKS header on the device is enough to securely 
+                        wipe the drive. With backups, you need to either destroy all header 
+                        backups or overwrite all encrypted data on the device. The other main risk 
+                        is that an encryption password that is valid at the time you make a 
+                        backup will always be valid for that backup. For example, say you change 
+                        the encryption password on your device after making a backup because it 
+                        has been compromised. An attacker would be able to restore the header 
+                        backup and then use the compromised password to access the data.</p>
+                        <p>The cryptsetup documentation refers to creating header backups 
+                        as making a trade-off between safety and security. You need to make a 
+                        decision based on your individual use-case. It's a good idea to 
+                        routinely update your header backups if you do choose to make them</p>
+                        <p>When creating or restoring a header backup you always refer to the 
+                        block device in the command, not the device mapper taget. To create 
+                        a header backup:</p>
+                        <pre><code>cryptsetup luksHeaderBackup <em>/dev/sdX</em> --header-backup-file <em>path/to/backup</em></code></pre>
+                        <p>To restore a header from a backup:</p>
+                        <pre><code>cryptsetup luksHeaderRestore <em>/dev/sdX</em> --header-backup-file <em>path/to/backup</em></code></pre>
+                        <p>Note that is not necessary to store header backups on an encrypted 
+                        device. I would recommend storing backups on at least one non-encrypted 
+                        drive in case of an emergency.</p>
+    </main>
+<p>
+<hr>
+Consider <a href=../donate.html>donating</a> if this article was useful.
+<a class=qr href=../images/bitcoin.png>[BTC]</a>
+</p>
+        </main>
+    <footer>
+        <a href=../kb.html>Knowledge Base</a>
+        <br>
+        <a href=../index.html>www.chudnick.com</a>
+        </footer>
+</body>
+</html>

diff --git a/articles/luks.html b/articles/luks.html new file mode 100644 index 0000000..d2bbc5e --- /dev/null +++ b/articles/luks.html
@@ -0,0 +1,132 @@
	1	<!DOCTYPE html>
	2	<html lang=en>
	3	<head>
	4	<title></title>
	5	<meta charset="utf-8"/>
	6	<link rel="shortcut icon" href="favicon.ico"/>
	7	<link rel='stylesheet' href='../style.css'/>
	8	<meta name="viewport" content="width=device-width, initial-scale=1">
	9	</head>
	10	<body>
	11	<header><h1>LUKS Block Device Encryption</h1></header>
	12	<main>
	13	<p>Linux Unified Key Setup (LUKS) is a method for encrypting
	14	block devices that is built-in to the Linux Kernel. In this tutorial
	15	I will be showing how to create an encrypted USB drive with LUKS, but
	16	this process is applicable to other types of storage.
	17	<strong>This process will wipe all data on the device that you
	18	encrypt so make backups beforehand if needed</strong>.</p>
	19
	20	<h2>Install Packages</h2>
	21	<p>Install cryptsetup and its dependencies</p>
	22
	23	<pre><code>apt install cryptsetup</code></pre>
	24
	25	<h2>Prepare the Drive</h2>
	26	<p>If the device you are encrypting was previously used, you will
	27	want to completely overwrite any data on it before encryption. This
	28	can be done using <strong>dd</strong> as shown below. This could take
	29	a very long time depending on the size and type of your drive.
	30	Be sure that you enter the correct path to your drive as the
	31	argument to <strong>of</strong>, and do not specify a partition:
	32	<strong>/dev/sdb</strong> is correct, <strong>/dev/sdb1</strong> is
	33	wrong. Obviously this will destroy any data on the device so be
	34	absolutely sure you specify the correct device in the command
	35	and have backups of data previously stored if needed.</p>
	36
	37	<pre><code>dd if=/dev/zero of=<em>/dev/sdX</em> status=progress</code></pre>
	38
	39	<h2>Encrypt the Drive</h2>
	40	<p><strong>cryptsetup</strong> is the main command used to perform
	41	LUKS-related tasks. This main command is followed by a subcommand
	42	that specifies which action to perform. To create a LUKS partition
	43	on a drive we need to use the subcommand <strong>luksFormat</strong>.
	44	We also use the type option to explicitly say to use LUKS version 2
	45	encryption. Run the command and then enter and confirm the
	46	encryption password.</p>
	47
	48	<pre><code>cryptsetup --type luks2 luksFormat <em>/dev/sdX</em></code></pre>
	49
	50	<p>Now we need to open and map the encrypted LUKS device. This is done
	51	by using the <strong>luksOpen</strong> subcommand. This subcommand takes
	52	the device as the first argument and then a map target as the second. The
	53	map target can be any string as long as a map does not already exist with
	54	that name. In the example I will use <em>crypt</em>.
	55
	56	<pre><code>cryptsetup luksOpen <em>/dev/sdX crypt</em></code></pre>
	57
	58	<p>And then we just need to create a filesystem on the device; I will
	59	be making an ext4 filesystem in the example. To
	60	interact with an encrypted drive after it has been opened you need
	61	to refer to its device mapper target, which is found under /dev/mapper.
	62	Since we used <em>crypt</em> as the map target, our encrypted drive
	63	is /dev/mapper/<em>crypt</em>. </p>
	64
	65	<pre><code>mkfs.ext4 /dev/mapper/<em>crypt</em></code></pre>
	66
	67	<p>After creating the filesystem created the encrypted drive
	68	can now be mounted and used like any other device. Remember that
	69	when mounting the device you refer to the device mapper target
	70	(mount /dev/mapper/<em>crypt</em> /mnt/crypt).</p>
	71
	72	<p>In addition to unmounting the filesystem you should always close
	73	the device mapping before removing your encrypted drive. This is
	74	done with the <strong>luksClose</strong> subcommand and takes
	75	the device mapping as the argument.</p>
	76
	77	<pre><code>cryptsetup luksClose /dev/mapper/<em>crypt</em></code></pre>
	78
	79	<h2>The LUKS Header</h2>
	80	<p>The LUKS header sits at the front of your encrypted drive and is
	81	responsible for managing access to the device. If the header is
	82	damaged accessing your encrypted data will not be possible. Because of
	83	this, you may want to make backups of the header, but before doing so
	84	you need to weigh the risks and benefits.</p>
	85
	86	<p>The obvious benefit is that
	87	in the event of damage to the LUKS header, you can easily restore a
	88	backup and regain access to the data. However, having a backup of the
	89	header makes it harder to wipe the LUKS device. Without a header
	90	backup, overwriting the LUKS header on the device is enough to securely
	91	wipe the drive. With backups, you need to either destroy all header
	92	backups or overwrite all encrypted data on the device. The other main risk
	93	is that an encryption password that is valid at the time you make a
	94	backup will always be valid for that backup. For example, say you change
	95	the encryption password on your device after making a backup because it
	96	has been compromised. An attacker would be able to restore the header
	97	backup and then use the compromised password to access the data.</p>
	98
	99	<p>The cryptsetup documentation refers to creating header backups
	100	as making a trade-off between safety and security. You need to make a
	101	decision based on your individual use-case. It's a good idea to
	102	routinely update your header backups if you do choose to make them</p>
	103
	104	<p>When creating or restoring a header backup you always refer to the
	105	block device in the command, not the device mapper taget. To create
	106	a header backup:</p>
	107
	108	<pre><code>cryptsetup luksHeaderBackup <em>/dev/sdX</em> --header-backup-file <em>path/to/backup</em></code></pre>
	109
	110	<p>To restore a header from a backup:</p>
	111
	112	<pre><code>cryptsetup luksHeaderRestore <em>/dev/sdX</em> --header-backup-file <em>path/to/backup</em></code></pre>
	113
	114	<p>Note that is not necessary to store header backups on an encrypted
	115	device. I would recommend storing backups on at least one non-encrypted
	116	drive in case of an emergency.</p>
	117
	118	</main>
	119	<p>
	120	<hr>
	121	Consider <a href=../donate.html>donating</a> if this article was useful.
	122	<a class=qr href=../images/bitcoin.png>[BTC]</a>
	123	</p>
	124	</main>
	125	<footer>
	126	<a href=../kb.html>Knowledge Base</a>
	127	<br>
	128	<a href=../index.html>www.chudnick.com</a>
	129	</footer>
	130	</body>
	131	</html>
	132