https://wiki.archlinux.org/api.php?action=feedcontributions&user=Vinhsynd&feedformat=atomArchWiki - User contributions [en]2024-03-29T14:34:32ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Talk:Nouveau&diff=125874Talk:Nouveau2010-12-23T23:11:58Z<p>Vinhsynd: </p>
<hr />
<div>I cannot confirm needing a 20-nouveau.conf anymore, nouveau seems to get autodetected. Maybe this section can be removed?<br />
--[[User:Litemotiv|Litemotiv]] 14:00, 17 October 2010 (EDT)<br />
<br />
Adding "options nouveau modeset=1" to /etc/modprobe.d/modprobe.conf was mentioned in a few places in the forums but is absent from this wiki page. I've included here as well.<br />
--[[User:Vinhsynd|Vinhsynd]] 17:09, 23 December 2010 (CDT)</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Nouveau&diff=125872Nouveau2010-12-23T23:09:20Z<p>Vinhsynd: /* Early start */</p>
<hr />
<div>[[Category: Graphics (English)]]<br />
[[Category: X Server (English)]]<br />
[[Category: HOWTOs (English)]]<br />
{{i18n|Nouveau}}<br />
{{Article summary start}}<br />
{{Article summary text|This article details the installation of the Nouveau Open Source 3D acceleration graphics driver for NVIDIA cards. The name of the project refers to the fact that "nouveau" means "new" in French.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|KMS}}<br />
{{Article summary wiki|Xorg}}<br />
{{Article summary wiki|NVIDIA}}<br />
{{Article summary end}}<br />
<br />
[http://nouveau.freedesktop.org/wiki/ Nouveau] is an open source graphic driver for NVIDIA cards.<br />
Do not forget to check out the [http://nouveau.freedesktop.org/wiki/FAQ FAQ] if you have any questions, as there is a lot of valuable information there.<br />
<br />
==Installation==<br />
Before proceeding, have a look at the [http://nouveau.freedesktop.org/wiki/FeatureMatrix FeatureMatrix] to see what features are supported for a given architecture, and the list of [http://nouveau.freedesktop.org/wiki/CodeNames codenames] to determine the card's category.<br />
<br />
You could also consult [[Wikipedia:Comparison_of_Nvidia_Graphics_Processing_Units|wikipedia]] for a even more detailed list.<br />
<br />
Install the following package:<br />
# pacman -S xf86-video-nouveau<br />
<br />
In addition to {{Package Official|xf86-video-nouveau}}, install the package below for the highly experimental Mesa Gallium3D DRI drivers for Nouveau:<br />
# pacman -S nouveau-dri<br />
<br />
{{Warning|3D acceleration is still not officially supported, so don't report any bugs unless you are looking to contribute patches.}}<br />
<br />
As of [http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=d5f3c90d4f3ad6b054f9855b7b69137b97bda131 2010-02-25], nouveau automatically generates the firmware for nv50. Thus nouveau-firmware is no longer needed for any cards with nouveau-drm 0.0.15_20100313-1.<br />
<br />
==Loading==<br />
<br />
If you kept the proprietary nvidia driver installed, nouveau is probably not going to work.<br />
Either uninstall nvidia or blacklist it by adding the following line to /etc/modprobe.d/modprobe.conf<br />
blacklist nvidia<br />
<br />
Then nouveau should load fine automatically on next reboot. To test it now, first make sure nvidia is no longer loaded<br />
# rmmod nvidia<br />
Now load nouveau<br />
# modprobe nouveau<br />
And check that it loaded fine by looking at kernel messages<br />
$ dmesg<br />
<br />
==Configuration==<br />
Create the file {{Filename|/etc/X11/xorg.conf.d/20-nouveau.conf}}, and input the following contents:<br />
Section "Device"<br />
Identifier "n"<br />
Driver "nouveau"<br />
EndSection<br />
This is required to ensure that nouveau driver is loaded. Xorg is not yet smart enough to do this by itself.<br />
<br />
==KMS==<br />
Kernel Mode-Setting ([[KMS]]) is required by the Nouveau driver. See the [http://nouveau.freedesktop.org/wiki/KernelModeSetting KernelModeSetting] page for more information.<br />
<br />
===Late start===<br />
With this choice, KMS will be enabled when the boot process says, "Loading modules." This may cause an undesirable screen flicker as the mode changes.<br />
<br />
Remove all "vga=" and "video=" options from your kernel commandline in {{Filename|/boot/grub/menu.lst}}. Using other framebuffer drivers (such as uvesafb) will conflict with KMS.<br />
<br />
===Early start===<br />
{{Warning|If you have troubles with nouveau, and are led to rebuild nouveau-drm several times for testing purpose, do not add nouveau to the initramfs. It is too easy to forget to rebuild the initramfs and it will just make any testing harder. Just use ''late start''. There might be additional problems with initramfs if you need a firmware for the nv50 family}}<br />
<br />
This method will start KMS as early as possible in the boot process, when the [[initramfs]] is loaded. Here is how to do this with the official packages:<br />
<br />
1) Add "nouveau" to the ''MODULES'' array in {{Filename|/etc/mkinitcpio.conf}}:<br />
MODULES="'''nouveau''' ..."<br />
<br />
2) Add "options nouveau modeset=1" to "/etc/modprobe.d/modprobe.conf".<br />
<br />
3) Add "/etc/modprobe.d/modprobe.conf" to the FILES section in {{Filename|/etc/mkinitcpio.conf}}:<br />
FILES="/etc/modprobe.d/modprobe.conf"<br />
<br />
4) Re-generate your initcpio:<br />
# mkinitcpio -p <''your kernel preset (kernel26, etc.)''><br />
<br />
<small>You can also look at the [[Intel]] instructions for an early start: [[Intel#KMS_.28Kernel_Mode_Setting.29|Intel Graphics:KMS (Kernel Mode Setting)]]</small><br />
<br />
==Alternative installation==<br />
If the official Arch Linux packages do not work, you can try a more current video driver from the [[AUR]]: {{Package AUR|xf86-video-nouveau-git}}. A more up-to-date DRM module can be built by using the {{Package Official|nouveau-drm}} PKGBUILD from [[Arch Build System|ABS]]. Simply update {{Codeline|_snapdate}} to the current date, and modify the {{Codeline|sources}} array to read:<br />
source=(# ftp://ftp.archlinux.org/other/$pkgname/master-${_snapdate}.tar.gz<br />
http://people.freedesktop.org/~pq/nouveau-drm/master.tar.gz<br />
# get the Makefile from http://cgit.freedesktop.org/nouveau/linux-2.6/plain/nouveau/Makefile?h=master-compat<br />
Makefile)<br />
<br />
You can use {{Package AUR|kernel26-nouveau-git}} to compile the nouveau project's kernel tree, which already includes the necessary modules. This is the method recommended by upstream.<br />
<br />
==DualHead==<br />
Nouveau supports the xrandr extension for modesetting and multiple monitors. See the [[RandR12]] page for tutorials.<br />
<br />
Here is a full sample {{Filename|/etc/X11/xorg.conf}} above for running 2 monitors in dual head mode. You may prefer to use a graphical tool to configure monitors like gnome-display-properties (System -> Preferences -> Display).<br />
<pre><br />
# the right one<br />
Section "Monitor"<br />
Identifier "NEC"<br />
Option "PreferredMode" "1280x1024_60.00"<br />
EndSection<br />
<br />
# the left one<br />
Section "Monitor"<br />
Identifier "FUS"<br />
Option "PreferredMode" "1280x1024_60.00"<br />
Option "LeftOf" "NEC"<br />
EndSection<br />
<br />
Section "Device"<br />
Identifier "nvidia card"<br />
Driver "nouveau"<br />
Option "Monitor-DVI-I-0" "NEC"<br />
Option "Monitor-DVI-I-1" "FUS"<br />
#Option "AccelMethod" "XAA"<br />
EndSection<br />
<br />
Section "Screen"<br />
Identifier "screen1"<br />
DefaultDepth 24<br />
SubSection "Display"<br />
Depth 24<br />
Virtual 2560 1024<br />
EndSubSection<br />
Device "nvidia card"<br />
EndSection<br />
<br />
Section "ServerLayout"<br />
Identifier "layout1"<br />
Screen "screen1"<br />
# will be replaced by gallium 3D<br />
Option "AIGLX" "false"<br />
EndSection<br />
</pre><br />
<br />
==Setting console resolution==<br />
Use the {{Package Official|fbset}} tool to adjust console resolution.<br />
<br />
You can also pass the resolution to nouveau with the video= kernel line option (see [[KMS]]).</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=121985Dm-crypt2010-11-22T04:30:13Z<p>Vinhsynd: /* Configuring LUKS */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is too simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [[#System_Encryption_with_eCryptfs eCryptfs|System Encryption with eCryptfs]].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Initial Setup ==<br />
=== Overview and Preparation ===<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can be accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
#dd if=/dev/urandom of=/dev/<drive> bs=1M<br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
#badblocks -c 10240 -Wsvt random /dev/<drive><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]] which is suggested reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
<br />
'''How does LVM fit into the overall system?'''<br />
<br />
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKs). It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKs on LVM). However the deployment of LVM on LUKS is considered much more generalizable. One reason for this that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In which case, logical volume management would be layered on top of the hardware encryption - usage of LUKS would be superfluous.<br />
<br />
<br />
==== Creating Disk Partitions ====<br />
<br />
Disk partitions are created using:<br />
<br />
# cfdisk<br />
<br />
This will display a graphical interface for creating disk partitions.<br />
<br />
There are 2 required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*'''/'''<br />
:::*Will be encrypted and store all system and user files (/usr, /bin, /var, /home, etc.)<br />
<br />
::An initial boot partition<br />
<br />
:::*'''/boot'''<br />
:::*Will ''not'' be encrypted; the bootloader needs to access the /boot directory where it will load the initrd/encryption modules needed to load the rest of the system (which ''is'' encrypted). For this reason /boot needs to reside on its own, unencrypted, partition.<br />
<br />
<br />
{{Note| A swap partition is optional; it can be encrypted with dm-crypt/LUKS. See [[#Encrypting_the_Swap_partition|Encrypting the Swap Partition]] for details.}}<br />
<br />
<br />
'''Single Disk Systems'''<br />
<br />
Depending on the system demands, there may be additional partitions desired. These partitions can be individually created at this level by defining separate primary or extended/logical partitions. However if LVM is to be employed, the space unoccupied by /boot and swap should be defined as single large partition which will be divided up later at the logical volume manager level.<br />
<br />
<br />
'''Multiple Disk Systems'''<br />
<br />
In systems that will have multiple harddisk drives, the same options exist as a single disk system. After the creation of the /boot and swap partitions, the remaining free space on physical disks can divided up into their respective partitions at this level, or large partitions can define all free space per physical disk with intent to partition them within the LVM.<br />
<br />
== Configuring LUKS ==<br />
<br />
Creating LUKS partitions with a passphrase is supported by the /arch/setup program. <br />
<br />
This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. <br />
<br />
The steps for accomplishing this through the graphical installer are very similar and can be located in dialogue for manual configuration of the hard drive.<br />
<br />
<br />
<br />
=== Mapping Physical Partitions to LUKS ===<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions and then mount them through the device mapper.<br />
<br />
When creating LUKS partitions they must be associated with a key. <br />
<br />
A key is either a: <br />
<br />
::*Passphrase<br />
::*Keyfile <br />
<br />
It is possible to define up to 8 different keys can be defined per LUKS partition.<br />
<br />
<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
There are many options that cryptsetup with accept, a full list can be reference in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::-c defines the cipher type<br />
::-y prompts for password confirmation on password creation<br />
::-s defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
<br />
In the following examples for creating LUKS partitions we will use AES with XTS, at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup and details about them can be found [[http://en.wikipedia.org/wiki/Block_cipher Wikipedia: BlockCipher]]<br />
<br />
<br />
'''Formating LUKS Partitions'''<br />
<br />
In order to format a desired partition as an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup -c <cipher> -y -s <key size> luksFormat /dev/<partition name><br />
Enter passphrase: <password><br />
Verify passphrase: <password><br />
<br />
<br />
This should be repeated until all partitions except for /boot and possibly swap.<br />
<br />
<br />
Example:<br />
<br />
::*cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2<br />
:::Will create and encrypted root partition using the AES cipher<br />
<br />
<br />
{{Note| If hibernation usage is planned, swap must be encrypted in this fashion. Otherwise if hibernation is not a planned feature for the system, encrypting the swap file will be performed in a alternative manner.}}<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
<br />
'''Unlocking/Mapping LUKS Partitions with the Device Mapper'''<br />
<br />
Once the LUKS partitions have been created it is time to unlock them. <br />
<br />
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that /dev/<partition name> is actually an encrypted device and should be addressed through LUKS using the /dev/mapper/<name> so as not to overwrite the encrypted data. <br />
<br />
<br />
In order to open an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup luksOpen /dev/<partition name> <device-mapper name><br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda2 '''swap'''<br />
::::Once opened the swap partition device address would be '''/dev/mapper/swap''' instead of /dev/sda2<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda3 '''root'''<br />
::::Once opened the root partition device address would be '''/dev/mapper/root''' instead of /dev/sda3<br />
<br />
<br />
{{Note| Since /boot is not encrypted it does not need a device mapped name and will be addressed as /dev/sda1.}}<br />
<br />
<br />
{{Warning| In order to write encrypted data into the partition it must be accessed through the device mapped name.}}<br />
<br />
<br />
<br />
==== Using LUKS to Format Partitions with a Keyfile ====<br />
<br />
<br />
'''What is a Keyfile?'''<br />
<br />
A keyfiles is any file in which the data contained within is used as the passphrase to unlock an encrypted volume.<br />
Therefore if these files are lost or changed, decrypting the volume will no longer be possible.<br />
<br />
<br />
{{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.}}<br />
<br />
<br />
'''Why use a Keyfile?'''<br />
<br />
There are many kinds of keyfiles, each type of keyfile used has benefits and disadvantages summarized below:<br />
<br />
<br />
:'''keyfile.passphrase:'''<br />
::this is my passphrase I would have typed during boot but I've placed in a file instead<br />
<br />
<br />
This is a keyfile containing a simple passphrase. The benefit of this type of keyfile is that if the file is lost the data it contained is known and hopefully easily remembered by the owner of the encrypted volume. However the disadvantage is that this does not any security over entering a passphrase during the initial system start.<br />
<br />
<br />
:'''keyfile.randomtext:'''<br />
::fjqweifj830149-57 819y4my1- 38t1934yt8-91m 34co3;t8y;9p3y-<br />
<br />
<br />
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.<br />
<br />
<br />
:'''keyfile.binary:'''<br />
::where any binary file, images, text, video could be chosen as the keyfile<br />
<br />
<br />
This is a binary file that has been defined as a keyfile. When identifying files as candidates for a keyfile, its 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 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, music have some intrinsic relationship between neighboring bits of data that is not existent for a text file. However this is controversial and has never been exploited publicly.<br />
<br />
<br />
<br />
'''Creating a Keyfile with Random Characters'''<br />
<br />
<br />
Here dd is used to generate a keyfile of 2048bits of random characters.<br />
<br />
<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
<br />
The usage of dd is similar to initially wiping the volume with random data prior to encryption. While badblocks may also be used, most key files are on the order of a few kilobytes and there is no noticable speed difference between dd, or badblocks.<br />
<br />
<br />
<br />
'''Creating a new LUKS encrypted partition with a Keyfile'''<br />
<br />
<br />
When creating a new LUKS encrypted partition a keyfile may be associated with the partition on its creation using:<br />
<br />
<br />
# cryptsetup -c <desired cipher> -s <key size> -v luksFormat /dev/<volume to encrypt> '''/path/to/mykeyfile'''<br />
<br />
<br />
This is accomplished by appending the bold area to the standard cryptsetup command which defines where the keyfile is located.<br />
<br />
<br />
<br />
==== Adding Additional Passphrases or Keyfiles to a LUKS Encrypted Partition ====<br />
<br />
<br />
LUKS supports the association of up to 8 keys with any single encrypted volume.<br />
Keys can be either keyfiles or passphrases.<br />
<br />
Once an encrytped partition has been created, the initial key is associated at slot0.<br />
Additional keys will occupy slots 1 - 7.<br />
<br />
The addition of new keys to an encrypted partition is accomplished using cryptsetup with luksAddKey extension.<br />
<br />
<br />
# cryptsetup luksAddKey /dev/<encrypted volume> '''/path/to/mykeyfile'''<br />
<br />
<br />
Where /dev/<encrypted volume> is the volume that is to have the new key associated with it.<br />
<br />
If the bolded area is present cryptsetup will look for the keyfile defined at that location to associate with the encrypted volume specified.<br />
<br />
<br />
<br />
=== Storing the Key File ===<br />
<br />
<br />
==== External Storage on a USB Drive ====<br />
<br />
===== Preparation for permanent device names =====<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
===== Quick method =====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
==== Generating the keyfile ====<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
==== Storing the keyfile ====<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
=== Encrypting the Swap partition ===<br />
<br />
<br />
==== Encrypting Swap without Suspend Support ====<br />
<br />
In systems where suspend to disk is not a desired feature, it is possible to create a swap file that will have a random passphrase with each boot.<br />
<br />
This is accomplished by using dm-crypt directly without LUKS extensions.<br />
<br />
<br />
Execute the following command to setup a randomly encrypted swap partition:<br />
<br />
# echo swap <swap physical partition> <device-mapper name> "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
<br />
This command adds the following swap partition details to /mnt/etc/crypttab:<br />
<br />
::*'echo' and '>> /mnt/etc/crypttab' adds the command to the file /mnt/etc/crypttab directly<br />
::*swap identifies the partition as a swap partition<br />
::*-c defines a cipher<br />
::*-h defines a hash algorithm<br />
::*-s defines the key size<br />
<br />
<br />
Example (/dev/sda2 is the physical swap partition):<br />
<br />
::*echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
:::Maps /dev/sda2 to /dev/mapper/SWAP as a swap partition which is encrypted by AES with Whirlpool as the hash algorithm.<br />
<br />
<br />
There are many hash algorithms that can be employed, for further details [[http://en.wikipedia.org/wiki/Cryptographic_hash_function Cryptographic Hash Functions]]. <br />
<br />
<br />
{{Tip | Many people prefer Whirlpool as it is patent free. On modern hardware this is minimal performance difference between algorithms.}}<br />
<br />
<br />
If the partition chosen for swap was previously a LUKS partition, crypttab will not overwite to partition to create a swap partition. This is safetly measure to prevent data loss from accidental miss identification of the swap partition in crypttab. In order to use such a partition the LUKS header must be removed. This can be accomplished by<br />
<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
==== Encrypted swap with suspend-to-disk support ====<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Installing the system ==<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important thing in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=121984Dm-crypt2010-11-22T04:27:08Z<p>Vinhsynd: /* Mapping Physical Partitions to LUKS */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is too simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [[#System_Encryption_with_eCryptfs eCryptfs|System Encryption with eCryptfs]].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Initial Setup ==<br />
=== Overview and Preparation ===<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can be accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
#dd if=/dev/urandom of=/dev/<drive> bs=1M<br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
#badblocks -c 10240 -Wsvt random /dev/<drive><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]] which is suggested reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
<br />
'''How does LVM fit into the overall system?'''<br />
<br />
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKs). It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKs on LVM). However the deployment of LVM on LUKS is considered much more generalizable. One reason for this that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In which case, logical volume management would be layered on top of the hardware encryption - usage of LUKS would be superfluous.<br />
<br />
<br />
==== Creating Disk Partitions ====<br />
<br />
Disk partitions are created using:<br />
<br />
# cfdisk<br />
<br />
This will display a graphical interface for creating disk partitions.<br />
<br />
There are 2 required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*'''/'''<br />
:::*Will be encrypted and store all system and user files (/usr, /bin, /var, /home, etc.)<br />
<br />
::An initial boot partition<br />
<br />
:::*'''/boot'''<br />
:::*Will ''not'' be encrypted; the bootloader needs to access the /boot directory where it will load the initrd/encryption modules needed to load the rest of the system (which ''is'' encrypted). For this reason /boot needs to reside on its own, unencrypted, partition.<br />
<br />
<br />
{{Note| A swap partition is optional; it can be encrypted with dm-crypt/LUKS. See [[#Encrypting_the_Swap_partition|Encrypting the Swap Partition]] for details.}}<br />
<br />
<br />
'''Single Disk Systems'''<br />
<br />
Depending on the system demands, there may be additional partitions desired. These partitions can be individually created at this level by defining separate primary or extended/logical partitions. However if LVM is to be employed, the space unoccupied by /boot and swap should be defined as single large partition which will be divided up later at the logical volume manager level.<br />
<br />
<br />
'''Multiple Disk Systems'''<br />
<br />
In systems that will have multiple harddisk drives, the same options exist as a single disk system. After the creation of the /boot and swap partitions, the remaining free space on physical disks can divided up into their respective partitions at this level, or large partitions can define all free space per physical disk with intent to partition them within the LVM.<br />
<br />
== Configuring LUKS ==<br />
<br />
Creating LUKS partitions with a passphrase is supported by the /arch/setup program. <br />
<br />
This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. <br />
<br />
The steps for accomplishing this through the graphical installer are very similar and can be located in dialogue for manual configuration of the hard drive.<br />
<br />
<br />
<br />
=== Mapping Physical Partitions to LUKS ===<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions and then mount them through the device mapper.<br />
<br />
When creating LUKS partitions they must be associated with a key. <br />
<br />
A key is either a: <br />
<br />
::*Passphrase<br />
::*Keyfile <br />
<br />
It is possible to define up to 8 different keys can be defined per LUKS partition.<br />
<br />
<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
There are many options that cryptsetup with accept, a full list can be reference in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::-c defines the cipher type<br />
::-y prompts for password confirmation on password creation<br />
::-s defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
<br />
In the following examples for creating LUKS partitions we will use AES with XTS, at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup and details about them can be found [[http://en.wikipedia.org/wiki/Block_cipher Wikipedia: BlockCipher]]<br />
<br />
<br />
'''Formating LUKS Partitions'''<br />
<br />
In order to format a desired partition as an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup -c <cipher> -y -s <key size> luksFormat /dev/<partition name><br />
Enter passphrase: <password><br />
Verify passphrase: <password><br />
<br />
<br />
This should be repeated until all partitions except for /boot and possibly swap.<br />
<br />
<br />
Example:<br />
<br />
::*cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2<br />
:::Will create and encrypted root partition using the AES cipher<br />
<br />
<br />
{{Note| If hibernation usage is planned, swap must be encrypted in this fashion. Otherwise if hibernation is not a planned feature for the system, encrypting the swap file will be performed in a alternative manner.}}<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
<br />
'''Unlocking/Mapping LUKS Partitions with the Device Mapper'''<br />
<br />
Once the LUKS partitions have been created it is time to unlock them. <br />
<br />
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that /dev/<partition name> is actually an encrypted device and should be addressed through LUKS using the /dev/mapper/<name> so as not to overwrite the encrypted data. <br />
<br />
<br />
In order to open an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup luksOpen /dev/<partition name> <device-mapper name><br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda2 '''swap'''<br />
::::Once opened the swap partition device address would be '''/dev/mapper/swap''' instead of /dev/sda2<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda3 '''root'''<br />
::::Once opened the root partition device address would be '''/dev/mapper/root''' instead of /dev/sda3<br />
<br />
<br />
{{Note| Since /boot is not encrypted it does not need a device mapped name and will be addressed as /dev/sda1.}}<br />
<br />
<br />
{{Warning| In order to write encrypted data into the partition it must be accessed through the device mapped name.}}<br />
<br />
<br />
<br />
==== Using LUKS to Format Partitions with a Keyfile ====<br />
<br />
<br />
'''What is a Keyfile?'''<br />
<br />
A keyfiles is any file in which the data contained within is used as the passphrase to unlock an encrypted volume.<br />
Therefore if these files are lost or changed, decrypting the volume will no longer be possible.<br />
<br />
<br />
{{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.}}<br />
<br />
<br />
'''Why use a Keyfile?'''<br />
<br />
There are many kinds of keyfiles, each type of keyfile used has benefits and disadvantages summarized below:<br />
<br />
<br />
:'''keyfile.passphrase:'''<br />
::this is my passphrase I would have typed during boot but I've placed in a file instead<br />
<br />
<br />
This is a keyfile containing a simple passphrase. The benefit of this type of keyfile is that if the file is lost the data it contained is known and hopefully easily remembered by the owner of the encrypted volume. However the disadvantage is that this does not any security over entering a passphrase during the initial system start.<br />
<br />
<br />
:'''keyfile.randomtext:'''<br />
::fjqweifj830149-57 819y4my1- 38t1934yt8-91m 34co3;t8y;9p3y-<br />
<br />
<br />
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.<br />
<br />
<br />
:'''keyfile.binary:'''<br />
::where any binary file, images, text, video could be chosen as the keyfile<br />
<br />
<br />
This is a binary file that has been defined as a keyfile. When identifying files as candidates for a keyfile, its 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 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, music have some intrinsic relationship between neighboring bits of data that is not existent for a text file. However this is controversial and has never been exploited publicly.<br />
<br />
<br />
<br />
'''Creating a Keyfile with Random Characters'''<br />
<br />
<br />
Here dd is used to generate a keyfile of 2048bits of random characters.<br />
<br />
<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
<br />
The usage of dd is similar to initially wiping the volume with random data prior to encryption. While badblocks may also be used, most key files are on the order of a few kilobytes and there is no noticable speed difference between dd, or badblocks.<br />
<br />
<br />
<br />
'''Creating a new LUKS encrypted partition with a Keyfile'''<br />
<br />
<br />
When creating a new LUKS encrypted partition a keyfile may be associated with the partition on its creation using:<br />
<br />
<br />
# cryptsetup -c <desired cipher> -s <key size> -v luksFormat /dev/<volume to encrypt> '''/path/to/mykeyfile'''<br />
<br />
<br />
This is accomplished by appending the bold area to the standard cryptsetup command which defines where the keyfile is located.<br />
<br />
<br />
<br />
==== Adding Additional Passphrases or Keyfiles to a LUKS Encrypted Partition ====<br />
<br />
<br />
LUKS supports the association of up to 8 keys with any single encrypted volume.<br />
Keys can be either keyfiles or passphrases.<br />
<br />
Once an encrytped partition has been created, the initial key is associated at slot0.<br />
Additional keys will occupy slots 1 - 7.<br />
<br />
The addition of new keys to an encrypted partition is accomplished using cryptsetup with luksAddKey extension.<br />
<br />
<br />
# cryptsetup luksAddKey /dev/<encrypted volume> '''/path/to/mykeyfile'''<br />
<br />
<br />
Where /dev/<encrypted volume> is the volume that is to have the new key associated with it.<br />
<br />
If the bolded area is present cryptsetup will look for the keyfile defined at that location to associate with the encrypted volume specified.<br />
<br />
=== Storing the Key File ===<br />
<br />
==== External Storage on a USB Drive ====<br />
<br />
===== Preparation for permanent device names =====<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
===== Quick method =====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
==== Generating the keyfile ====<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
==== Storing the keyfile ====<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
=== Encrypting the Swap partition ===<br />
<br />
<br />
==== Encrypting Swap without Suspend Support ====<br />
<br />
In systems where suspend to disk is not a desired feature, it is possible to create a swap file that will have a random passphrase with each boot.<br />
<br />
This is accomplished by using dm-crypt directly without LUKS extensions.<br />
<br />
<br />
Execute the following command to setup a randomly encrypted swap partition:<br />
<br />
# echo swap <swap physical partition> <device-mapper name> "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
<br />
This command adds the following swap partition details to /mnt/etc/crypttab:<br />
<br />
::*'echo' and '>> /mnt/etc/crypttab' adds the command to the file /mnt/etc/crypttab directly<br />
::*swap identifies the partition as a swap partition<br />
::*-c defines a cipher<br />
::*-h defines a hash algorithm<br />
::*-s defines the key size<br />
<br />
<br />
Example (/dev/sda2 is the physical swap partition):<br />
<br />
::*echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
:::Maps /dev/sda2 to /dev/mapper/SWAP as a swap partition which is encrypted by AES with Whirlpool as the hash algorithm.<br />
<br />
<br />
There are many hash algorithms that can be employed, for further details [[http://en.wikipedia.org/wiki/Cryptographic_hash_function Cryptographic Hash Functions]]. <br />
<br />
<br />
{{Tip | Many people prefer Whirlpool as it is patent free. On modern hardware this is minimal performance difference between algorithms.}}<br />
<br />
<br />
If the partition chosen for swap was previously a LUKS partition, crypttab will not overwite to partition to create a swap partition. This is safetly measure to prevent data loss from accidental miss identification of the swap partition in crypttab. In order to use such a partition the LUKS header must be removed. This can be accomplished by<br />
<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
==== Encrypted swap with suspend-to-disk support ====<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Installing the system ==<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important thing in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=121983Dm-crypt2010-11-22T04:24:25Z<p>Vinhsynd: /* Using LUKS to Format Partitions with a Passphrase */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is too simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [[#System_Encryption_with_eCryptfs eCryptfs|System Encryption with eCryptfs]].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Initial Setup ==<br />
=== Overview and Preparation ===<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can be accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
#dd if=/dev/urandom of=/dev/<drive> bs=1M<br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
#badblocks -c 10240 -Wsvt random /dev/<drive><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]] which is suggested reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
<br />
'''How does LVM fit into the overall system?'''<br />
<br />
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKs). It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKs on LVM). However the deployment of LVM on LUKS is considered much more generalizable. One reason for this that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In which case, logical volume management would be layered on top of the hardware encryption - usage of LUKS would be superfluous.<br />
<br />
<br />
==== Creating Disk Partitions ====<br />
<br />
Disk partitions are created using:<br />
<br />
# cfdisk<br />
<br />
This will display a graphical interface for creating disk partitions.<br />
<br />
There are 2 required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*'''/'''<br />
:::*Will be encrypted and store all system and user files (/usr, /bin, /var, /home, etc.)<br />
<br />
::An initial boot partition<br />
<br />
:::*'''/boot'''<br />
:::*Will ''not'' be encrypted; the bootloader needs to access the /boot directory where it will load the initrd/encryption modules needed to load the rest of the system (which ''is'' encrypted). For this reason /boot needs to reside on its own, unencrypted, partition.<br />
<br />
<br />
{{Note| A swap partition is optional; it can be encrypted with dm-crypt/LUKS. See [[#Encrypting_the_Swap_partition|Encrypting the Swap Partition]] for details.}}<br />
<br />
<br />
'''Single Disk Systems'''<br />
<br />
Depending on the system demands, there may be additional partitions desired. These partitions can be individually created at this level by defining separate primary or extended/logical partitions. However if LVM is to be employed, the space unoccupied by /boot and swap should be defined as single large partition which will be divided up later at the logical volume manager level.<br />
<br />
<br />
'''Multiple Disk Systems'''<br />
<br />
In systems that will have multiple harddisk drives, the same options exist as a single disk system. After the creation of the /boot and swap partitions, the remaining free space on physical disks can divided up into their respective partitions at this level, or large partitions can define all free space per physical disk with intent to partition them within the LVM.<br />
<br />
== Configuring LUKS ==<br />
<br />
Creating LUKS partitions with a passphrase is supported by the /arch/setup program. <br />
<br />
This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. <br />
<br />
The steps for accomplishing this through the graphical installer are very similar and can be located in dialogue for manual configuration of the hard drive.<br />
<br />
<br />
<br />
=== Mapping Physical Partitions to LUKS ===<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions and then mount them through the device mapper.<br />
<br />
When creating LUKS partitions they must be associated with a key. <br />
<br />
A key is either a: <br />
<br />
::*Passphrase<br />
::*Keyfile <br />
<br />
It is possible to define up to 8 different keys can be defined per LUKS partition.<br />
<br />
<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
There are many options that cryptsetup with accept, a full list can be reference in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::-c defines the cipher type<br />
::-y prompts for password confirmation on password creation<br />
::-s defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
<br />
In the following examples for creating LUKS partitions we will use AES with XTS, at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup and details about them can be found [[http://en.wikipedia.org/wiki/Block_cipher Wikipedia: BlockCipher]]<br />
<br />
<br />
'''Formating LUKS Partitions'''<br />
<br />
In order to format a desired partition as an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup -c <cipher> -y -s <key size> luksFormat /dev/<partition name><br />
Enter passphrase: <password><br />
Verify passphrase: <password><br />
<br />
<br />
This should be repeated until all partitions except for /boot and possibly swap.<br />
<br />
<br />
Example:<br />
<br />
::*cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2<br />
:::Will create and encrypted root partition using the AES cipher<br />
<br />
<br />
{{Note| If hibernation usage is planned, swap must be encrypted in this fashion. Otherwise if hibernation is not a planned feature for the system, encrypting the swap file will be performed in a alternative manner.}}<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
<br />
'''Unlocking/Mapping LUKS Partitions with the Device Mapper'''<br />
<br />
Once the LUKS partitions have been created it is time to unlock them. <br />
<br />
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that /dev/<partition name> is actually an encrypted device and should be addressed through LUKS using the /dev/mapper/<name> so as not to overwrite the encrypted data. <br />
<br />
<br />
In order to open an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup luksOpen /dev/<partition name> <device-mapper name><br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda2 '''swap'''<br />
::::Once opened the swap partition device address would be '''/dev/mapper/swap''' instead of /dev/sda2<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda3 '''root'''<br />
::::Once opened the root partition device address would be '''/dev/mapper/root''' instead of /dev/sda3<br />
<br />
<br />
{{Note| Since /boot is not encrypted it does not need a device mapped name and will be addressed as /dev/sda1.}}<br />
<br />
<br />
{{Warning| In order to write encrypted data into the partition it must be accessed through the device mapped name.}}<br />
<br />
==== Using LUKS to Format Paritions with a Keyfile ====<br />
<br />
<br />
'''What is a Keyfile?'''<br />
<br />
A keyfiles is any file in which the data contained within is used as the passphrase to unlock an encrypted volume.<br />
Therefore if these files are lost or changed, decrypting the volume will no longer be possible.<br />
<br />
<br />
{{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.}}<br />
<br />
<br />
'''Why use a Keyfile?'''<br />
<br />
There are many kinds of keyfiles, each type of keyfile used has benefits and disadvantages summarized below:<br />
<br />
<br />
:'''keyfile.passphrase:'''<br />
::this is my passphrase I would have typed during boot but I've placed in a file instead<br />
<br />
<br />
This is a keyfile containing a simple passphrase. The benefit of this type of keyfile is that if the file is lost the data it contained is known and hopefully easily remembered by the owner of the encrypted volume. However the disadvantage is that this does not any security over entering a passphrase during the initial system start.<br />
<br />
<br />
:'''keyfile.randomtext:'''<br />
::fjqweifj830149-57 819y4my1- 38t1934yt8-91m 34co3;t8y;9p3y-<br />
<br />
<br />
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.<br />
<br />
<br />
:'''keyfile.binary:'''<br />
::where any binary file, images, text, video could be chosen as the keyfile<br />
<br />
<br />
This is a binary file that has been defined as a keyfile. When identifying files as candidates for a keyfile, its 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 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, music have some intrinsic relationship between neighboring bits of data that is not existent for a text file. However this is controversial and has never been exploited publicly.<br />
<br />
<br />
<br />
===== Creating a Keyfile with Random Characters =====<br />
<br />
<br />
Here dd is used to generate a keyfile of 2048bits of random characters.<br />
<br />
<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
<br />
The usage of dd is similar to initially wiping the volume with random data prior to encryption. While badblocks may also be used, most key files are on the order of a few kilobytes and there is no noticable speed difference between dd, or badblocks.<br />
<br />
<br />
===== Creating a new LUKS encrypted partition with a Keyfile =====<br />
<br />
<br />
When creating a new LUKS encrypted partition a keyfile may be associated with the partition on its creation using:<br />
<br />
<br />
# cryptsetup -c <desired cipher> -s <key size> -v luksFormat /dev/<volume to encrypt> '''/path/to/mykeyfile'''<br />
<br />
<br />
This is accomplished by appending the bold area to the standard cryptsetup command which defines where the keyfile is located.<br />
<br />
<br />
<br />
==== Adding Additional Passphrases or Keyfiles to a LUKS Encrypted Partition ====<br />
<br />
<br />
LUKS supports the association of up to 8 keys with any single encrypted volume.<br />
Keys can be either keyfiles or passphrases.<br />
<br />
Once an encrytped partition has been created, the initial key is associated at slot0.<br />
Additional keys will occupy slots 1 - 7.<br />
<br />
The addition of new keys to an encrypted partition is accomplished using cryptsetup with luksAddKey extension.<br />
<br />
<br />
# cryptsetup luksAddKey /dev/<encrypted volume> '''/path/to/mykeyfile'''<br />
<br />
<br />
Where /dev/<encrypted volume> is the volume that is to have the new key associated with it.<br />
<br />
If the bolded area is present cryptsetup will look for the keyfile defined at that location to associate with the encrypted volume specified.<br />
<br />
<br />
<br />
=== Storing the Key File ===<br />
<br />
==== External Storage on a USB Drive ====<br />
<br />
===== Preparation for permanent device names =====<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
===== Quick method =====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
==== Generating the keyfile ====<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
==== Storing the keyfile ====<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
=== Encrypting the Swap partition ===<br />
<br />
<br />
==== Encrypting Swap without Suspend Support ====<br />
<br />
In systems where suspend to disk is not a desired feature, it is possible to create a swap file that will have a random passphrase with each boot.<br />
<br />
This is accomplished by using dm-crypt directly without LUKS extensions.<br />
<br />
<br />
Execute the following command to setup a randomly encrypted swap partition:<br />
<br />
# echo swap <swap physical partition> <device-mapper name> "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
<br />
This command adds the following swap partition details to /mnt/etc/crypttab:<br />
<br />
::*'echo' and '>> /mnt/etc/crypttab' adds the command to the file /mnt/etc/crypttab directly<br />
::*swap identifies the partition as a swap partition<br />
::*-c defines a cipher<br />
::*-h defines a hash algorithm<br />
::*-s defines the key size<br />
<br />
<br />
Example (/dev/sda2 is the physical swap partition):<br />
<br />
::*echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
:::Maps /dev/sda2 to /dev/mapper/SWAP as a swap partition which is encrypted by AES with Whirlpool as the hash algorithm.<br />
<br />
<br />
There are many hash algorithms that can be employed, for further details [[http://en.wikipedia.org/wiki/Cryptographic_hash_function Cryptographic Hash Functions]]. <br />
<br />
<br />
{{Tip | Many people prefer Whirlpool as it is patent free. On modern hardware this is minimal performance difference between algorithms.}}<br />
<br />
<br />
If the partition chosen for swap was previously a LUKS partition, crypttab will not overwite to partition to create a swap partition. This is safetly measure to prevent data loss from accidental miss identification of the swap partition in crypttab. In order to use such a partition the LUKS header must be removed. This can be accomplished by<br />
<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
==== Encrypted swap with suspend-to-disk support ====<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Installing the system ==<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important thing in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=121982Dm-crypt2010-11-22T04:23:13Z<p>Vinhsynd: /* Configuring LUKS */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is too simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [[#System_Encryption_with_eCryptfs eCryptfs|System Encryption with eCryptfs]].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Initial Setup ==<br />
=== Overview and Preparation ===<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can be accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
#dd if=/dev/urandom of=/dev/<drive> bs=1M<br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
#badblocks -c 10240 -Wsvt random /dev/<drive><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]] which is suggested reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
<br />
'''How does LVM fit into the overall system?'''<br />
<br />
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKs). It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKs on LVM). However the deployment of LVM on LUKS is considered much more generalizable. One reason for this that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In which case, logical volume management would be layered on top of the hardware encryption - usage of LUKS would be superfluous.<br />
<br />
<br />
==== Creating Disk Partitions ====<br />
<br />
Disk partitions are created using:<br />
<br />
# cfdisk<br />
<br />
This will display a graphical interface for creating disk partitions.<br />
<br />
There are 2 required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*'''/'''<br />
:::*Will be encrypted and store all system and user files (/usr, /bin, /var, /home, etc.)<br />
<br />
::An initial boot partition<br />
<br />
:::*'''/boot'''<br />
:::*Will ''not'' be encrypted; the bootloader needs to access the /boot directory where it will load the initrd/encryption modules needed to load the rest of the system (which ''is'' encrypted). For this reason /boot needs to reside on its own, unencrypted, partition.<br />
<br />
<br />
{{Note| A swap partition is optional; it can be encrypted with dm-crypt/LUKS. See [[#Encrypting_the_Swap_partition|Encrypting the Swap Partition]] for details.}}<br />
<br />
<br />
'''Single Disk Systems'''<br />
<br />
Depending on the system demands, there may be additional partitions desired. These partitions can be individually created at this level by defining separate primary or extended/logical partitions. However if LVM is to be employed, the space unoccupied by /boot and swap should be defined as single large partition which will be divided up later at the logical volume manager level.<br />
<br />
<br />
'''Multiple Disk Systems'''<br />
<br />
In systems that will have multiple harddisk drives, the same options exist as a single disk system. After the creation of the /boot and swap partitions, the remaining free space on physical disks can divided up into their respective partitions at this level, or large partitions can define all free space per physical disk with intent to partition them within the LVM.<br />
<br />
== Configuring LUKS ==<br />
<br />
Creating LUKS partitions with a passphrase is supported by the /arch/setup program. <br />
<br />
This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. <br />
<br />
The steps for accomplishing this through the graphical installer are very similar and can be located in dialogue for manual configuration of the hard drive.<br />
<br />
<br />
<br />
=== Mapping Physical Partitions to LUKS ===<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions and then mount them through the device mapper.<br />
<br />
When creating LUKS partitions they must be associated with a key. <br />
<br />
A key is either a: <br />
<br />
::*Passphrase<br />
::*Keyfile <br />
<br />
It is possible to define up to 8 different keys can be defined per LUKS partition.<br />
<br />
<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
There are many options that cryptsetup with accept, a full list can be reference in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::-c defines the cipher type<br />
::-y prompts for password confirmation on password creation<br />
::-s defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
<br />
In the following examples for creating LUKS partitions we will use AES with XTS, at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup and details about them can be found [[http://en.wikipedia.org/wiki/Block_cipher Wikipedia: BlockCipher]]<br />
<br />
<br />
'''Formating LUKS Partitions'''<br />
<br />
In order to format a desired partition as an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/<partition name><br />
Enter passphrase: <password><br />
Verify passphrase: <password><br />
<br />
<br />
This should be repeated until all partitions except for /boot and possibly swap.<br />
<br />
<br />
Example:<br />
<br />
::*cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2<br />
:::Will create and encrypted root partition using the AES cipher<br />
<br />
<br />
{{Note| If hibernation usage is planned, swap must be encrypted in this fashion. Otherwise if hibernation is not a planned feature for the system, encrypting the swap file will be performed in a alternative manner.}}<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
<br />
'''Unlocking/Mapping LUKS Partitions with the Device Mapper'''<br />
<br />
Once the LUKS partitions have been created it is time to unlock them. <br />
<br />
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that /dev/<partition name> is actually an encrypted device and should be addressed through LUKS using the /dev/mapper/<name> so as not to overwrite the encrypted data. <br />
<br />
<br />
In order to open an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup luksOpen /dev/<partition name> <device-mapper name><br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda2 '''swap'''<br />
::::Once opened the swap partition device address would be '''/dev/mapper/swap''' instead of /dev/sda2<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda3 '''root'''<br />
::::Once opened the root partition device address would be '''/dev/mapper/root''' instead of /dev/sda3<br />
<br />
<br />
{{Note| Since /boot is not encrypted it does not need a device mapped name and will be addressed as /dev/sda1.}}<br />
<br />
<br />
{{Warning| In order to write encrypted data into the partition it must be accessed through the device mapped name.}}<br />
<br />
<br />
<br />
==== Using LUKS to Format Paritions with a Keyfile ====<br />
<br />
<br />
'''What is a Keyfile?'''<br />
<br />
A keyfiles is any file in which the data contained within is used as the passphrase to unlock an encrypted volume.<br />
Therefore if these files are lost or changed, decrypting the volume will no longer be possible.<br />
<br />
<br />
{{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.}}<br />
<br />
<br />
'''Why use a Keyfile?'''<br />
<br />
There are many kinds of keyfiles, each type of keyfile used has benefits and disadvantages summarized below:<br />
<br />
<br />
:'''keyfile.passphrase:'''<br />
::this is my passphrase I would have typed during boot but I've placed in a file instead<br />
<br />
<br />
This is a keyfile containing a simple passphrase. The benefit of this type of keyfile is that if the file is lost the data it contained is known and hopefully easily remembered by the owner of the encrypted volume. However the disadvantage is that this does not any security over entering a passphrase during the initial system start.<br />
<br />
<br />
:'''keyfile.randomtext:'''<br />
::fjqweifj830149-57 819y4my1- 38t1934yt8-91m 34co3;t8y;9p3y-<br />
<br />
<br />
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.<br />
<br />
<br />
:'''keyfile.binary:'''<br />
::where any binary file, images, text, video could be chosen as the keyfile<br />
<br />
<br />
This is a binary file that has been defined as a keyfile. When identifying files as candidates for a keyfile, its 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 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, music have some intrinsic relationship between neighboring bits of data that is not existent for a text file. However this is controversial and has never been exploited publicly.<br />
<br />
<br />
<br />
===== Creating a Keyfile with Random Characters =====<br />
<br />
<br />
Here dd is used to generate a keyfile of 2048bits of random characters.<br />
<br />
<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
<br />
The usage of dd is similar to initially wiping the volume with random data prior to encryption. While badblocks may also be used, most key files are on the order of a few kilobytes and there is no noticable speed difference between dd, or badblocks.<br />
<br />
<br />
===== Creating a new LUKS encrypted partition with a Keyfile =====<br />
<br />
<br />
When creating a new LUKS encrypted partition a keyfile may be associated with the partition on its creation using:<br />
<br />
<br />
# cryptsetup -c <desired cipher> -s <key size> -v luksFormat /dev/<volume to encrypt> '''/path/to/mykeyfile'''<br />
<br />
<br />
This is accomplished by appending the bold area to the standard cryptsetup command which defines where the keyfile is located.<br />
<br />
<br />
<br />
==== Adding Additional Passphrases or Keyfiles to a LUKS Encrypted Partition ====<br />
<br />
<br />
LUKS supports the association of up to 8 keys with any single encrypted volume.<br />
Keys can be either keyfiles or passphrases.<br />
<br />
Once an encrytped partition has been created, the initial key is associated at slot0.<br />
Additional keys will occupy slots 1 - 7.<br />
<br />
The addition of new keys to an encrypted partition is accomplished using cryptsetup with luksAddKey extension.<br />
<br />
<br />
# cryptsetup luksAddKey /dev/<encrypted volume> '''/path/to/mykeyfile'''<br />
<br />
<br />
Where /dev/<encrypted volume> is the volume that is to have the new key associated with it.<br />
<br />
If the bolded area is present cryptsetup will look for the keyfile defined at that location to associate with the encrypted volume specified.<br />
<br />
<br />
<br />
=== Storing the Key File ===<br />
<br />
==== External Storage on a USB Drive ====<br />
<br />
===== Preparation for permanent device names =====<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
===== Quick method =====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
==== Generating the keyfile ====<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
==== Storing the keyfile ====<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
=== Encrypting the Swap partition ===<br />
<br />
<br />
==== Encrypting Swap without Suspend Support ====<br />
<br />
In systems where suspend to disk is not a desired feature, it is possible to create a swap file that will have a random passphrase with each boot.<br />
<br />
This is accomplished by using dm-crypt directly without LUKS extensions.<br />
<br />
<br />
Execute the following command to setup a randomly encrypted swap partition:<br />
<br />
# echo swap <swap physical partition> <device-mapper name> "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
<br />
This command adds the following swap partition details to /mnt/etc/crypttab:<br />
<br />
::*'echo' and '>> /mnt/etc/crypttab' adds the command to the file /mnt/etc/crypttab directly<br />
::*swap identifies the partition as a swap partition<br />
::*-c defines a cipher<br />
::*-h defines a hash algorithm<br />
::*-s defines the key size<br />
<br />
<br />
Example (/dev/sda2 is the physical swap partition):<br />
<br />
::*echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
:::Maps /dev/sda2 to /dev/mapper/SWAP as a swap partition which is encrypted by AES with Whirlpool as the hash algorithm.<br />
<br />
<br />
There are many hash algorithms that can be employed, for further details [[http://en.wikipedia.org/wiki/Cryptographic_hash_function Cryptographic Hash Functions]]. <br />
<br />
<br />
{{Tip | Many people prefer Whirlpool as it is patent free. On modern hardware this is minimal performance difference between algorithms.}}<br />
<br />
<br />
If the partition chosen for swap was previously a LUKS partition, crypttab will not overwite to partition to create a swap partition. This is safetly measure to prevent data loss from accidental miss identification of the swap partition in crypttab. In order to use such a partition the LUKS header must be removed. This can be accomplished by<br />
<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
==== Encrypted swap with suspend-to-disk support ====<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Installing the system ==<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important thing in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=121981Dm-crypt2010-11-22T04:20:09Z<p>Vinhsynd: </p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is too simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [[#System_Encryption_with_eCryptfs eCryptfs|System Encryption with eCryptfs]].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Initial Setup ==<br />
=== Overview and Preparation ===<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can be accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
#dd if=/dev/urandom of=/dev/<drive> bs=1M<br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
#badblocks -c 10240 -Wsvt random /dev/<drive><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]] which is suggested reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
<br />
'''How does LVM fit into the overall system?'''<br />
<br />
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKs). It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKs on LVM). However the deployment of LVM on LUKS is considered much more generalizable. One reason for this that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In which case, logical volume management would be layered on top of the hardware encryption - usage of LUKS would be superfluous.<br />
<br />
<br />
==== Creating Disk Partitions ====<br />
<br />
Disk partitions are created using:<br />
<br />
# cfdisk<br />
<br />
This will display a graphical interface for creating disk partitions.<br />
<br />
There are 2 required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*'''/'''<br />
:::*Will be encrypted and store all system and user files (/usr, /bin, /var, /home, etc.)<br />
<br />
::An initial boot partition<br />
<br />
:::*'''/boot'''<br />
:::*Will ''not'' be encrypted; the bootloader needs to access the /boot directory where it will load the initrd/encryption modules needed to load the rest of the system (which ''is'' encrypted). For this reason /boot needs to reside on its own, unencrypted, partition.<br />
<br />
<br />
{{Note| A swap partition is optional; it can be encrypted with dm-crypt/LUKS. See [[#Encrypting_the_Swap_partition|Encrypting the Swap Partition]] for details.}}<br />
<br />
<br />
'''Single Disk Systems'''<br />
<br />
Depending on the system demands, there may be additional partitions desired. These partitions can be individually created at this level by defining separate primary or extended/logical partitions. However if LVM is to be employed, the space unoccupied by /boot and swap should be defined as single large partition which will be divided up later at the logical volume manager level.<br />
<br />
<br />
'''Multiple Disk Systems'''<br />
<br />
In systems that will have multiple harddisk drives, the same options exist as a single disk system. After the creation of the /boot and swap partitions, the remaining free space on physical disks can divided up into their respective partitions at this level, or large partitions can define all free space per physical disk with intent to partition them within the LVM.<br />
<br />
== Configuring LUKS ==<br />
<br />
Creating LUKS partitions with a passphrase is supported by the /arch/setup program. <br />
<br />
This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. <br />
<br />
The steps for accomplishing this through the graphical installer are very similar and can be located in dialogue for manual configuration of the hard drive.<br />
<br />
<br />
<br />
=== Mapping Physical Partitions to LUKS ===<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions and then mount them through the device mapper.<br />
<br />
When creating LUKS partitions they must be associated with a key. <br />
<br />
A key is either a: <br />
<br />
::*Passphrase<br />
::*Keyfile <br />
<br />
It is possible to define up to 8 different keys can be defined per LUKS partition.<br />
<br />
<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
There are many options that cryptsetup with accept, a full list can be reference in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::-c defines the cipher type<br />
::-y prompts for password confirmation on password creation<br />
::-s defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
<br />
In the following examples for creating LUKS partitions we will use AES with XTS, at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup and details about them can be found [[http://en.wikipedia.org/wiki/Block_cipher Wikipedia: BlockCipher]]<br />
<br />
<br />
'''Formating LUKS Partitions'''<br />
<br />
In order to format a desired partition as an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/<partition name><br />
Enter passphrase: <password><br />
Verify passphrase: <password><br />
<br />
<br />
This should be repeated until all partitions except for /boot and possibly swap.<br />
<br />
<br />
Example:<br />
<br />
::*cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2<br />
:::Will create and encrypted root partition using the AES cipher<br />
<br />
<br />
{{Note| If hibernation usage is planned, swap must be encrypted in this fashion. Otherwise if hibernation is not a planned feature for the system, encrypting the swap file will be performed in a alternative manner.}}<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
<br />
'''Unlocking/Mapping LUKS Partitions with the Device Mapper'''<br />
<br />
Once the LUKS partitions have been created it is time to unlock them. <br />
<br />
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that /dev/<partition name> is actually an encrypted device and should be addressed through LUKS using the /dev/mapper/<name> so as not to overwrite the encrypted data. <br />
<br />
<br />
In order to open an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup luksOpen /dev/<partition name> <device-mapper name><br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda2 '''swap'''<br />
::::Once opened the swap partition device address would be '''/dev/mapper/swap''' instead of /dev/sda2<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda3 '''root'''<br />
::::Once opened the root partition device address would be '''/dev/mapper/root''' instead of /dev/sda3<br />
<br />
<br />
{{Note| Since /boot is not encrypted it does not need a device mapped name and will be addressed as /dev/sda1.}}<br />
<br />
<br />
{{Warning| In order to write encrypted data into the partition it must be accessed through the device mapped name.}}<br />
<br />
==== Using LUKS to Format Paritions with a Keyfile ====<br />
<br />
<br />
===== What is a Keyfile? =====<br />
<br />
A keyfiles is any file in which the data contained within is used as the passphrase to unlock an encrypted volume.<br />
Therefore if these files are lost or changed, decrypting the volume will no longer be possible.<br />
<br />
<br />
{{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.}}<br />
<br />
<br />
===== Why use a Keyfile? =====<br />
<br />
There are many kinds of keyfiles, each type of keyfile used has benefits and disadvantages summarized below:<br />
<br />
<br />
:'''keyfile.passphrase:'''<br />
::this is my passphrase I would have typed during boot but I've placed in a file instead<br />
<br />
<br />
This is a keyfile containing a simple passphrase. The benefit of this type of keyfile is that if the file is lost the data it contained is known and hopefully easily remembered by the owner of the encrypted volume. However the disadvantage is that this does not any security over entering a passphrase during the initial system start.<br />
<br />
<br />
:'''keyfile.randomtext:'''<br />
::fjqweifj830149-57 819y4my1- 38t1934yt8-91m 34co3;t8y;9p3y-<br />
<br />
<br />
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.<br />
<br />
<br />
:'''keyfile.binary:'''<br />
::where any binary file, images, text, video could be chosen as the keyfile<br />
<br />
<br />
This is a binary file that has been defined as a keyfile. When identifying files as candidates for a keyfile, its 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 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, music have some intrinsic relationship between neighboring bits of data that is not existent for a text file. However this is controversial and has never been exploited publicly.<br />
<br />
<br />
<br />
===== Creating a Keyfile with Random Characters =====<br />
<br />
<br />
Here dd is used to generate a keyfile of 2048bits of random characters.<br />
<br />
<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
<br />
The usage of dd is similar to initially wiping the volume with random data prior to encryption. While badblocks may also be used, most key files are on the order of a few kilobytes and there is no noticable speed difference between dd, or badblocks.<br />
<br />
<br />
===== Creating a new LUKS encrypted partition with a Keyfile =====<br />
<br />
<br />
When creating a new LUKS encrypted partition a keyfile may be associated with the partition on its creation using:<br />
<br />
<br />
# cryptsetup -c <desired cipher> -s <key size> -v luksFormat /dev/<volume to encrypt> '''/path/to/mykeyfile'''<br />
<br />
<br />
This is accomplished by appending the bold area to the standard cryptsetup command which defines where the keyfile is located.<br />
<br />
<br />
<br />
==== Adding Additional Passphrases or Keyfiles to a LUKS Encrypted Partition ====<br />
<br />
<br />
LUKS supports the association of up to 8 keys with any single encrypted volume.<br />
Keys can be either keyfiles or passphrases.<br />
<br />
Once an encrytped partition has been created, the initial key is associated at slot0.<br />
Additional keys will occupy slots 1 - 7.<br />
<br />
The addition of new keys to an encrypted partition is accomplished using cryptsetup with luksAddKey extension.<br />
<br />
<br />
# cryptsetup luksAddKey /dev/<encrypted volume> '''/path/to/mykeyfile'''<br />
<br />
<br />
Where /dev/<encrypted volume> is the volume that is to have the new key associated with it.<br />
<br />
If the bolded area is present cryptsetup will look for the keyfile defined at that location to associate with the encrypted volume specified.<br />
<br />
=== Storing the Key File ===<br />
<br />
==== External Storage on a USB Drive ====<br />
<br />
===== Preparation for permanent device names =====<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
===== Quick method =====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
==== Generating the keyfile ====<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
==== Storing the keyfile ====<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
=== Encrypting the Swap partition ===<br />
<br />
<br />
==== Encrypting Swap without Suspend Support ====<br />
<br />
In systems where suspend to disk is not a desired feature, it is possible to create a swap file that will have a random passphrase with each boot.<br />
<br />
This is accomplished by using dm-crypt directly without LUKS extensions.<br />
<br />
<br />
Execute the following command to setup a randomly encrypted swap partition:<br />
<br />
# echo swap <swap physical partition> <device-mapper name> "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
<br />
This command adds the following swap partition details to /mnt/etc/crypttab:<br />
<br />
::*'echo' and '>> /mnt/etc/crypttab' adds the command to the file /mnt/etc/crypttab directly<br />
::*swap identifies the partition as a swap partition<br />
::*-c defines a cipher<br />
::*-h defines a hash algorithm<br />
::*-s defines the key size<br />
<br />
<br />
Example (/dev/sda2 is the physical swap partition):<br />
<br />
::*echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
:::Maps /dev/sda2 to /dev/mapper/SWAP as a swap partition which is encrypted by AES with Whirlpool as the hash algorithm.<br />
<br />
<br />
There are many hash algorithms that can be employed, for further details [[http://en.wikipedia.org/wiki/Cryptographic_hash_function Cryptographic Hash Functions]]. <br />
<br />
<br />
{{Tip | Many people prefer Whirlpool as it is patent free. On modern hardware this is minimal performance difference between algorithms.}}<br />
<br />
<br />
If the partition chosen for swap was previously a LUKS partition, crypttab will not overwite to partition to create a swap partition. This is safetly measure to prevent data loss from accidental miss identification of the swap partition in crypttab. In order to use such a partition the LUKS header must be removed. This can be accomplished by<br />
<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
==== Encrypted swap with suspend-to-disk support ====<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Installing the system ==<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important thing in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=120977Dm-crypt2010-11-10T03:46:48Z<p>Vinhsynd: /* Data Encryption */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is too simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [[#System_Encryption_with_eCryptfs eCryptfs|System Encryption with eCryptfs]].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Initial Setup ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
#dd if=/dev/urandom of=/dev/<drive> bs=1M<br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
#badblocks -c 10240 -Wsvt random /dev/<drive><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]] which is suggested reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
<br />
'''How does LVM fit into the overall system?'''<br />
<br />
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKs). It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKs on LVM). However the deployment of LVM on LUKS is considered much more generalizable. One reason for this that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In which case, logical volume management would be layered on top of the hardware encryption - usage of LUKS would be superfluous.<br />
<br />
<br />
==== Creating Disk Partitions ====<br />
<br />
Disk partitions are created using:<br />
<br />
# cfdisk<br />
<br />
This will display a graphical interface for creating disk partitions.<br />
<br />
There are 2 required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*'''/'''<br />
:::*Will be encrypted and store all system and user files (/usr, /bin, /var, /home, etc.)<br />
<br />
::An initial boot partition<br />
<br />
:::*'''/boot'''<br />
:::*Will ''not'' be encrypted; the bootloader needs to access the /boot directory where it will load the initrd/encryption modules needed to load the rest of the system (which ''is'' encrypted). For this reason /boot needs to reside on its own, unencrypted, partition.<br />
<br />
<br />
{{Note| A swap partition is optional; it can be encrypted with dm-crypt/LUKS. See [[#Encrypting_the_Swap_partition|Encrypting the Swap Partition]] for details.}}<br />
<br />
<br />
'''Single Disk Systems'''<br />
<br />
Depending on the system demands, there may be additional partitions desired. These partitions can be individually created at this level by defining separate primary or extended/logical partitions. However if LVM is to be employed, the space unoccupied by /boot and swap should be defined as single large partition which will be divided up later at the logical volume manager level.<br />
<br />
<br />
'''Multiple Disk Systems'''<br />
<br />
In systems that will have multiple harddisk drives, the same options exist as a single disk system. After the creation of the /boot and swap partitions, the remaining free space on physical disks can divided up into their respective partitions at this level, or large partitions can define all free space per physical disk with intent to partition them within the LVM.<br />
<br />
== Configuring LUKS ==<br />
<br />
Creating LUKS partitions with a passphrase is supported by the /arch/setup program. <br />
<br />
This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. <br />
<br />
The steps for accomplishing this through the graphical installer are very similar and can be located in dialogue for manual configuration of the hard drive.<br />
<br />
<br />
<br />
=== Mapping Physical Partitions to LUKS ===<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions and then mount them through the device mapper.<br />
<br />
When creating LUKS partitions they must be associated with a key. <br />
<br />
A key is either a: <br />
<br />
::*Passphrase<br />
::*Keyfile <br />
<br />
It is possible to define up to 8 different keys can be defined per LUKS partition.<br />
<br />
<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
There are many options that cryptsetup with accept, a full list can be reference in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::-c defines the cipher type<br />
::-y prompts for password confirmation on password creation<br />
::-s defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
<br />
In the following examples for creating LUKS partitions we will use AES with XTS, at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup and details about them can be found [[http://en.wikipedia.org/wiki/Block_cipher Wikipedia: BlockCipher]]<br />
<br />
<br />
'''Formating LUKS Partitions'''<br />
<br />
In order to format a desired partition as an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/<partition name><br />
Enter passphrase: <password><br />
Verify passphrase: <password><br />
<br />
<br />
This should be repeated until all partitions except for /boot and possibly swap.<br />
<br />
<br />
Example:<br />
<br />
::*cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2<br />
:::Will create and encrypted root partition using the AES cipher<br />
<br />
<br />
{{Note| If hibernation usage is planned, swap must be encrypted in this fashion. Otherwise if hibernation is not a planned feature for the system, encrypting the swap file will be performed in a alternative manner.}}<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
<br />
'''Unlocking/Mapping LUKS Partitions with the Device Mapper'''<br />
<br />
Once the LUKS partitions have been created it is time to unlock them. <br />
<br />
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that /dev/<partition name> is actually an encrypted device and should be addressed through LUKS using the /dev/mapper/<name> so as not to overwrite the encrypted data. <br />
<br />
<br />
In order to open an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup luksOpen /dev/<partition name> <device-mapper name><br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda2 '''swap'''<br />
::::Once opened the swap partition device address would be '''/dev/mapper/swap''' instead of /dev/sda2<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda3 '''root'''<br />
::::Once opened the root partition device address would be '''/dev/mapper/root''' instead of /dev/sda3<br />
<br />
<br />
{{Note| Since /boot is not encrypted it does not need a device mapped name and will be addressed as /dev/sda1.}}<br />
<br />
<br />
{{Warning| In order to write encrypted data into the partition it must be accessed through the device mapped name.}}<br />
<br />
==== Using LUKS to Format Paritions with a Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
=== Storing the Key File ===<br />
<br />
==== External Storage on a USB Drive ====<br />
<br />
===== Preparation for permanent device names =====<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
===== Quick method =====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
==== Generating the keyfile ====<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
==== Storing the keyfile ====<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
=== Encrypting the Swap partition ===<br />
<br />
<br />
==== Encrypting Swap without Suspend Support ====<br />
<br />
In systems where suspend to disk is not a desired feature, it is possible to create a swap file that will have a random passphrase with each boot.<br />
<br />
This is accomplished by using dm-crypt directly without LUKS extensions.<br />
<br />
<br />
Execute the following command to setup a randomly encrypted swap partition:<br />
<br />
# echo swap <swap physical partition> <device-mapper name> "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
<br />
This command adds the following swap partition details to /mnt/etc/crypttab:<br />
<br />
::*'echo' and '>> /mnt/etc/crypttab' adds the command to the file /mnt/etc/crypttab directly<br />
::*swap identifies the partition as a swap partition<br />
::*-c defines a cipher<br />
::*-h defines a hash algorithm<br />
::*-s defines the key size<br />
<br />
<br />
Example (/dev/sda2 is the physical swap partition):<br />
<br />
::*echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
:::Maps /dev/sda2 to /dev/mapper/SWAP as a swap partition which is encrypted by AES with Whirlpool as the hash algorithm.<br />
<br />
<br />
There are many hash algorithms that can be employed, for further details [[http://en.wikipedia.org/wiki/Cryptographic_hash_function Cryptographic Hash Functions]]. <br />
<br />
<br />
{{Tip | Many people prefer Whirlpool as it is patent free. On modern hardware this is minimal performance difference between algorithms.}}<br />
<br />
<br />
If the partition chosen for swap was previously a LUKS partition, crypttab will not overwite to partition to create a swap partition. This is safetly measure to prevent data loss from accidental miss identification of the swap partition in crypttab. In order to use such a partition the LUKS header must be removed. This can be accomplished by<br />
<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
==== Encrypted swap with suspend-to-disk support ====<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Installing the system ==<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=120976Dm-crypt2010-11-10T03:42:34Z<p>Vinhsynd: /* Secure Erasure of the Harddisk Drive */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is too simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Initial Setup ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
#dd if=/dev/urandom of=/dev/<drive> bs=1M<br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
#badblocks -c 10240 -Wsvt random /dev/<drive><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]] which is suggested reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
<br />
'''How does LVM fit into the overall system?'''<br />
<br />
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKs). It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKs on LVM). However the deployment of LVM on LUKS is considered much more generalizable. One reason for this that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In which case, logical volume management would be layered on top of the hardware encryption - usage of LUKS would be superfluous.<br />
<br />
<br />
==== Creating Disk Partitions ====<br />
<br />
Disk partitions are created using:<br />
<br />
# cfdisk<br />
<br />
This will display a graphical interface for creating disk partitions.<br />
<br />
There are 2 required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*'''/'''<br />
:::*Will be encrypted and store all system and user files (/usr, /bin, /var, /home, etc.)<br />
<br />
::An initial boot partition<br />
<br />
:::*'''/boot'''<br />
:::*Will ''not'' be encrypted; the bootloader needs to access the /boot directory where it will load the initrd/encryption modules needed to load the rest of the system (which ''is'' encrypted). For this reason /boot needs to reside on its own, unencrypted, partition.<br />
<br />
<br />
{{Note| A swap partition is optional; it can be encrypted with dm-crypt/LUKS. See [[#Encrypting_the_Swap_partition|Encrypting the Swap Partition]] for details.}}<br />
<br />
<br />
'''Single Disk Systems'''<br />
<br />
Depending on the system demands, there may be additional partitions desired. These partitions can be individually created at this level by defining separate primary or extended/logical partitions. However if LVM is to be employed, the space unoccupied by /boot and swap should be defined as single large partition which will be divided up later at the logical volume manager level.<br />
<br />
<br />
'''Multiple Disk Systems'''<br />
<br />
In systems that will have multiple harddisk drives, the same options exist as a single disk system. After the creation of the /boot and swap partitions, the remaining free space on physical disks can divided up into their respective partitions at this level, or large partitions can define all free space per physical disk with intent to partition them within the LVM.<br />
<br />
== Configuring LUKS ==<br />
<br />
Creating LUKS partitions with a passphrase is supported by the /arch/setup program. <br />
<br />
This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. <br />
<br />
The steps for accomplishing this through the graphical installer are very similar and can be located in dialogue for manual configuration of the hard drive.<br />
<br />
<br />
<br />
=== Mapping Physical Partitions to LUKS ===<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions and then mount them through the device mapper.<br />
<br />
When creating LUKS partitions they must be associated with a key. <br />
<br />
A key is either a: <br />
<br />
::*Passphrase<br />
::*Keyfile <br />
<br />
It is possible to define up to 8 different keys can be defined per LUKS partition.<br />
<br />
<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
There are many options that cryptsetup with accept, a full list can be reference in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::-c defines the cipher type<br />
::-y prompts for password confirmation on password creation<br />
::-s defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
<br />
In the following examples for creating LUKS partitions we will use AES with XTS, at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup and details about them can be found [[http://en.wikipedia.org/wiki/Block_cipher Wikipedia: BlockCipher]]<br />
<br />
<br />
'''Formating LUKS Partitions'''<br />
<br />
In order to format a desired partition as an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/<partition name><br />
Enter passphrase: <password><br />
Verify passphrase: <password><br />
<br />
<br />
This should be repeated until all partitions except for /boot and possibly swap.<br />
<br />
<br />
Example:<br />
<br />
::*cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2<br />
:::Will create and encrypted root partition using the AES cipher<br />
<br />
<br />
{{Note| If hibernation usage is planned, swap must be encrypted in this fashion. Otherwise if hibernation is not a planned feature for the system, encrypting the swap file will be performed in a alternative manner.}}<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
<br />
'''Unlocking/Mapping LUKS Partitions with the Device Mapper'''<br />
<br />
Once the LUKS partitions have been created it is time to unlock them. <br />
<br />
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that /dev/<partition name> is actually an encrypted device and should be addressed through LUKS using the /dev/mapper/<name> so as not to overwrite the encrypted data. <br />
<br />
<br />
In order to open an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup luksOpen /dev/<partition name> <device-mapper name><br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda2 '''swap'''<br />
::::Once opened the swap partition device address would be '''/dev/mapper/swap''' instead of /dev/sda2<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda3 '''root'''<br />
::::Once opened the root partition device address would be '''/dev/mapper/root''' instead of /dev/sda3<br />
<br />
<br />
{{Note| Since /boot is not encrypted it does not need a device mapped name and will be addressed as /dev/sda1.}}<br />
<br />
<br />
{{Warning| In order to write encrypted data into the partition it must be accessed through the device mapped name.}}<br />
<br />
==== Using LUKS to Format Paritions with a Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
=== Storing the Key File ===<br />
<br />
==== External Storage on a USB Drive ====<br />
<br />
===== Preparation for permanent device names =====<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
===== Quick method =====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
==== Generating the keyfile ====<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
==== Storing the keyfile ====<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
=== Encrypting the Swap partition ===<br />
<br />
<br />
==== Encrypting Swap without Suspend Support ====<br />
<br />
In systems where suspend to disk is not a desired feature, it is possible to create a swap file that will have a random passphrase with each boot.<br />
<br />
This is accomplished by using dm-crypt directly without LUKS extensions.<br />
<br />
<br />
Execute the following command to setup a randomly encrypted swap partition:<br />
<br />
# echo swap <swap physical partition> <device-mapper name> "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
<br />
This command adds the following swap partition details to /mnt/etc/crypttab:<br />
<br />
::*'echo' and '>> /mnt/etc/crypttab' adds the command to the file /mnt/etc/crypttab directly<br />
::*swap identifies the partition as a swap partition<br />
::*-c defines a cipher<br />
::*-h defines a hash algorithm<br />
::*-s defines the key size<br />
<br />
<br />
Example (/dev/sda2 is the physical swap partition):<br />
<br />
::*echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
:::Maps /dev/sda2 to /dev/mapper/SWAP as a swap partition which is encrypted by AES with Whirlpool as the hash algorithm.<br />
<br />
<br />
There are many hash algorithms that can be employed, for further details [[http://en.wikipedia.org/wiki/Cryptographic_hash_function Cryptographic Hash Functions]]. <br />
<br />
<br />
{{Tip | Many people prefer Whirlpool as it is patent free. On modern hardware this is minimal performance difference between algorithms.}}<br />
<br />
<br />
If the partition chosen for swap was previously a LUKS partition, crypttab will not overwite to partition to create a swap partition. This is safetly measure to prevent data loss from accidental miss identification of the swap partition in crypttab. In order to use such a partition the LUKS header must be removed. This can be accomplished by<br />
<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
==== Encrypted swap with suspend-to-disk support ====<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Installing the system ==<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=120975Dm-crypt2010-11-10T03:41:00Z<p>Vinhsynd: /* Creating Disk Partitions */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is too simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Initial Setup ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
<code>dd if=/dev/urandom of=/dev/<drive> bs=1M</code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
<code>badblocks -c 10240 -Wsvt random /dev/<drive></code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]] which is suggested reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
<br />
'''How does LVM fit into the overall system?'''<br />
<br />
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKs). It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKs on LVM). However the deployment of LVM on LUKS is considered much more generalizable. One reason for this that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In which case, logical volume management would be layered on top of the hardware encryption - usage of LUKS would be superfluous.<br />
<br />
<br />
==== Creating Disk Partitions ====<br />
<br />
Disk partitions are created using:<br />
<br />
# cfdisk<br />
<br />
This will display a graphical interface for creating disk partitions.<br />
<br />
There are 2 required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*'''/'''<br />
:::*Will be encrypted and store all system and user files (/usr, /bin, /var, /home, etc.)<br />
<br />
::An initial boot partition<br />
<br />
:::*'''/boot'''<br />
:::*Will ''not'' be encrypted; the bootloader needs to access the /boot directory where it will load the initrd/encryption modules needed to load the rest of the system (which ''is'' encrypted). For this reason /boot needs to reside on its own, unencrypted, partition.<br />
<br />
<br />
{{Note| A swap partition is optional; it can be encrypted with dm-crypt/LUKS. See [[#Encrypting_the_Swap_partition|Encrypting the Swap Partition]] for details.}}<br />
<br />
<br />
'''Single Disk Systems'''<br />
<br />
Depending on the system demands, there may be additional partitions desired. These partitions can be individually created at this level by defining separate primary or extended/logical partitions. However if LVM is to be employed, the space unoccupied by /boot and swap should be defined as single large partition which will be divided up later at the logical volume manager level.<br />
<br />
<br />
'''Multiple Disk Systems'''<br />
<br />
In systems that will have multiple harddisk drives, the same options exist as a single disk system. After the creation of the /boot and swap partitions, the remaining free space on physical disks can divided up into their respective partitions at this level, or large partitions can define all free space per physical disk with intent to partition them within the LVM.<br />
<br />
== Configuring LUKS ==<br />
<br />
Creating LUKS partitions with a passphrase is supported by the /arch/setup program. <br />
<br />
This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. <br />
<br />
The steps for accomplishing this through the graphical installer are very similar and can be located in dialogue for manual configuration of the hard drive.<br />
<br />
<br />
<br />
=== Mapping Physical Partitions to LUKS ===<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions and then mount them through the device mapper.<br />
<br />
When creating LUKS partitions they must be associated with a key. <br />
<br />
A key is either a: <br />
<br />
::*Passphrase<br />
::*Keyfile <br />
<br />
It is possible to define up to 8 different keys can be defined per LUKS partition.<br />
<br />
<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
There are many options that cryptsetup with accept, a full list can be reference in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::-c defines the cipher type<br />
::-y prompts for password confirmation on password creation<br />
::-s defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
<br />
In the following examples for creating LUKS partitions we will use AES with XTS, at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup and details about them can be found [[http://en.wikipedia.org/wiki/Block_cipher Wikipedia: BlockCipher]]<br />
<br />
<br />
'''Formating LUKS Partitions'''<br />
<br />
In order to format a desired partition as an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/<partition name><br />
Enter passphrase: <password><br />
Verify passphrase: <password><br />
<br />
<br />
This should be repeated until all partitions except for /boot and possibly swap.<br />
<br />
<br />
Example:<br />
<br />
::*cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2<br />
:::Will create and encrypted root partition using the AES cipher<br />
<br />
<br />
{{Note| If hibernation usage is planned, swap must be encrypted in this fashion. Otherwise if hibernation is not a planned feature for the system, encrypting the swap file will be performed in a alternative manner.}}<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
<br />
'''Unlocking/Mapping LUKS Partitions with the Device Mapper'''<br />
<br />
Once the LUKS partitions have been created it is time to unlock them. <br />
<br />
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that /dev/<partition name> is actually an encrypted device and should be addressed through LUKS using the /dev/mapper/<name> so as not to overwrite the encrypted data. <br />
<br />
<br />
In order to open an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup luksOpen /dev/<partition name> <device-mapper name><br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda2 '''swap'''<br />
::::Once opened the swap partition device address would be '''/dev/mapper/swap''' instead of /dev/sda2<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda3 '''root'''<br />
::::Once opened the root partition device address would be '''/dev/mapper/root''' instead of /dev/sda3<br />
<br />
<br />
{{Note| Since /boot is not encrypted it does not need a device mapped name and will be addressed as /dev/sda1.}}<br />
<br />
<br />
{{Warning| In order to write encrypted data into the partition it must be accessed through the device mapped name.}}<br />
<br />
==== Using LUKS to Format Paritions with a Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
=== Storing the Key File ===<br />
<br />
==== External Storage on a USB Drive ====<br />
<br />
===== Preparation for permanent device names =====<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
===== Quick method =====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
==== Generating the keyfile ====<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
==== Storing the keyfile ====<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
=== Encrypting the Swap partition ===<br />
<br />
<br />
==== Encrypting Swap without Suspend Support ====<br />
<br />
In systems where suspend to disk is not a desired feature, it is possible to create a swap file that will have a random passphrase with each boot.<br />
<br />
This is accomplished by using dm-crypt directly without LUKS extensions.<br />
<br />
<br />
Execute the following command to setup a randomly encrypted swap partition:<br />
<br />
# echo swap <swap physical partition> <device-mapper name> "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
<br />
This command adds the following swap partition details to /mnt/etc/crypttab:<br />
<br />
::*'echo' and '>> /mnt/etc/crypttab' adds the command to the file /mnt/etc/crypttab directly<br />
::*swap identifies the partition as a swap partition<br />
::*-c defines a cipher<br />
::*-h defines a hash algorithm<br />
::*-s defines the key size<br />
<br />
<br />
Example (/dev/sda2 is the physical swap partition):<br />
<br />
::*echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
:::Maps /dev/sda2 to /dev/mapper/SWAP as a swap partition which is encrypted by AES with Whirlpool as the hash algorithm.<br />
<br />
<br />
There are many hash algorithms that can be employed, for further details [[http://en.wikipedia.org/wiki/Cryptographic_hash_function Cryptographic Hash Functions]]. <br />
<br />
<br />
{{Tip | Many people prefer Whirlpool as it is patent free. On modern hardware this is minimal performance difference between algorithms.}}<br />
<br />
<br />
If the partition chosen for swap was previously a LUKS partition, crypttab will not overwite to partition to create a swap partition. This is safetly measure to prevent data loss from accidental miss identification of the swap partition in crypttab. In order to use such a partition the LUKS header must be removed. This can be accomplished by<br />
<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
==== Encrypted swap with suspend-to-disk support ====<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Installing the system ==<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=118880Dm-crypt2010-10-09T03:15:54Z<p>Vinhsynd: </p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is to simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Initial Setup ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
<code>dd if=/dev/urandom of=/dev/<drive> bs=1M</code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
<code>badblocks -c 10240 -Wsvt random /dev/<drive></code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]] which is suggested reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
<br />
'''How does LVM fit into the overall system?'''<br />
<br />
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKs). It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKs on LVM). However the deployment of LVM on LUKS is considered much more generalizable. One reason for this that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In which case, logical volume management would be layered on top of the hardware encryption - usage of LUKS would be superfluous.<br />
<br />
<br />
==== Creating Disk Partitions ====<br />
<br />
Disk partitions are created using:<br />
<br />
# cfdisk<br />
<br />
This will display a graphical interface for creating disk partitions.<br />
<br />
There are 3 required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*'''/'''<br />
<br />
::An initial boot partition<br />
<br />
:::*'''/boot'''<br />
<br />
::A swap partition<br />
<br />
:::*'''swap'''<br />
<br />
<br />
'''Single Disk Systems'''<br />
<br />
Depending on the system demands, there may be additional partitions desired. These partitions can be individually created at this level by defining separate primary or extended/logical partitions. However if LVM is to be employed, the space unoccupied by /boot and swap should be defined as single large partition which will be divided up later at the logical volume manager level.<br />
<br />
<br />
'''Multiple Disk Systems'''<br />
<br />
In systems that will have multiple harddisk drives, the same options exist as a single disk system. After the creation of the /boot and swap partitions, the remaining free space on physical disks can divided up into their respective partitions at this level, or large partitions can define all free space per physical disk with intent to partition them within the LVM.<br />
<br />
== Configuring LUKS ==<br />
<br />
Creating LUKS partitions with a passphrase is supported by the /arch/setup program. <br />
<br />
This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. <br />
<br />
The steps for accomplishing this through the graphical installer are very similar and can be located in dialogue for manual configuration of the hard drive.<br />
<br />
<br />
<br />
=== Mapping Physical Partitions to LUKS ===<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions and then mount them through the device mapper.<br />
<br />
When creating LUKS partitions they must be associated with a key. <br />
<br />
A key is either a: <br />
<br />
::*Passphrase<br />
::*Keyfile <br />
<br />
It is possible to define up to 8 different keys can be defined per LUKS partition.<br />
<br />
<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
There are many options that cryptsetup with accept, a full list can be reference in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::-c defines the cipher type<br />
::-y prompts for password confirmation on password creation<br />
::-s defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
<br />
In the following examples for creating LUKS partitions we will use AES with XTS, at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup and details about them can be found [[http://en.wikipedia.org/wiki/Block_cipher Wikipedia: BlockCipher]]<br />
<br />
<br />
'''Formating LUKS Partitions'''<br />
<br />
In order to format a desired partition as an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/<partition name><br />
Enter passphrase: <password><br />
Verify passphrase: <password><br />
<br />
<br />
This should be repeated until all partitions except for /boot and possibly swap.<br />
<br />
<br />
Example:<br />
<br />
::*cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2<br />
:::Will create and encrypted root partition using the AES cipher<br />
<br />
<br />
{{Note| If hibernation usage is planned, swap must be encrypted in this fashion. Otherwise if hibernation is not a planned feature for the system, encrypting the swap file will be performed in a alternative manner.}}<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
<br />
'''Unlocking/Mapping LUKS Partitions with the Device Mapper'''<br />
<br />
Once the LUKS partitions have been created it is time to unlock them. <br />
<br />
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that /dev/<partition name> is actually an encrypted device and should be addressed through LUKS using the /dev/mapper/<name> so as not to overwrite the encrypted data. <br />
<br />
<br />
In order to open an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup luksOpen /dev/<partition name> <device-mapper name><br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda2 '''swap'''<br />
::::Once opened the swap partition device address would be '''/dev/mapper/swap''' instead of /dev/sda2<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda3 '''root'''<br />
::::Once opened the root partition device address would be '''/dev/mapper/root''' instead of /dev/sda3<br />
<br />
<br />
{{Note| Since /boot is not encrypted it does not need a device mapped name and will be addressed as /dev/sda1.}}<br />
<br />
<br />
{{Warning| In order to write encrypted data into the partition it must be accessed through the device mapped name.}}<br />
<br />
==== Using LUKS to Format Paritions with a Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
=== Storing the Key File ===<br />
<br />
==== External Storage on a USB Drive ====<br />
<br />
===== Preparation for permanent device names =====<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
===== Quick method =====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
==== Generating the keyfile ====<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
==== Storing the keyfile ====<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
=== Encrypting the Swap partition ===<br />
<br />
<br />
==== Encrypting Swap without Suspend Support ====<br />
<br />
In systems where suspend to disk is not a desired feature, it is possible to create a swap file that will have a random passphrase with each boot.<br />
<br />
This is accomplished by using dm-crypt directly without LUKS extensions.<br />
<br />
<br />
Execute the following command to setup a randomly encrypted swap partition:<br />
<br />
# echo swap <swap physical partition> <device-mapper name> "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
<br />
This command adds the following swap partition details to /mnt/etc/crypttab:<br />
<br />
::*'echo' and '>> /mnt/etc/crypttab' adds the command to the file /mnt/etc/crypttab directly<br />
::*swap identifies the partition as a swap partition<br />
::*-c defines a cipher<br />
::*-h defines a hash algorithm<br />
::*-s defines the key size<br />
<br />
<br />
Example (/dev/sda2 is the physical swap partition):<br />
<br />
::*echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
:::Maps /dev/sda2 to /dev/mapper/SWAP as a swap partition which is encrypted by AES with Whirlpool as the hash algorithm.<br />
<br />
<br />
There are many hash algorithms that can be employed, for further details [[http://en.wikipedia.org/wiki/Cryptographic_hash_function Cryptographic Hash Functions]]. <br />
<br />
<br />
{{Tip | Many people prefer Whirlpool as it is patent free. On modern hardware this is minimal performance difference between algorithms.}}<br />
<br />
<br />
If the partition chosen for swap was previously a LUKS partition, crypttab will not overwite to partition to create a swap partition. This is safetly measure to prevent data loss from accidental miss identification of the swap partition in crypttab. In order to use such a partition the LUKS header must be removed. This can be accomplished by<br />
<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
==== Encrypted swap with suspend-to-disk support ====<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Installing the system ==<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=118879Dm-crypt2010-10-09T03:14:14Z<p>Vinhsynd: </p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt, or AES-Loop}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt or AES-Loop.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is to simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Initial Setup ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
<code>dd if=/dev/urandom of=/dev/<drive> bs=1M</code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
<code>badblocks -c 10240 -Wsvt random /dev/<drive></code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]] which is suggested reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
<br />
'''How does LVM fit into the overall system?'''<br />
<br />
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKs). It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKs on LVM). However the deployment of LVM on LUKS is considered much more generalizable. One reason for this that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In which case, logical volume management would be layered on top of the hardware encryption - usage of LUKS would be superfluous.<br />
<br />
<br />
==== Creating Disk Partitions ====<br />
<br />
Disk partitions are created using:<br />
<br />
# cfdisk<br />
<br />
This will display a graphical interface for creating disk partitions.<br />
<br />
There are 3 required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*'''/'''<br />
<br />
::An initial boot partition<br />
<br />
:::*'''/boot'''<br />
<br />
::A swap partition<br />
<br />
:::*'''swap'''<br />
<br />
<br />
'''Single Disk Systems'''<br />
<br />
Depending on the system demands, there may be additional partitions desired. These partitions can be individually created at this level by defining separate primary or extended/logical partitions. However if LVM is to be employed, the space unoccupied by /boot and swap should be defined as single large partition which will be divided up later at the logical volume manager level.<br />
<br />
<br />
'''Multiple Disk Systems'''<br />
<br />
In systems that will have multiple harddisk drives, the same options exist as a single disk system. After the creation of the /boot and swap partitions, the remaining free space on physical disks can divided up into their respective partitions at this level, or large partitions can define all free space per physical disk with intent to partition them within the LVM.<br />
<br />
== Configuring LUKS ==<br />
<br />
Creating LUKS partitions with a passphrase is supported by the /arch/setup program. <br />
<br />
This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. <br />
<br />
The steps for accomplishing this through the graphical installer are very similar and can be located in dialogue for manual configuration of the hard drive.<br />
<br />
<br />
<br />
=== Mapping Physical Partitions to LUKS ===<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions and then mount them through the device mapper.<br />
<br />
When creating LUKS partitions they must be associated with a key. <br />
<br />
A key is either a: <br />
<br />
::*Passphrase<br />
::*Keyfile <br />
<br />
It is possible to define up to 8 different keys can be defined per LUKS partition.<br />
<br />
<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
There are many options that cryptsetup with accept, a full list can be reference in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::-c defines the cipher type<br />
::-y prompts for password confirmation on password creation<br />
::-s defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
<br />
In the following examples for creating LUKS partitions we will use AES with XTS, at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup and details about them can be found [[http://en.wikipedia.org/wiki/Block_cipher Wikipedia: BlockCipher]]<br />
<br />
<br />
'''Formating LUKS Partitions'''<br />
<br />
In order to format a desired partition as an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/<partition name><br />
Enter passphrase: <password><br />
Verify passphrase: <password><br />
<br />
<br />
This should be repeated until all partitions except for /boot and possibly swap.<br />
<br />
<br />
Example:<br />
<br />
::*cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2<br />
:::Will create and encrypted root partition using the AES cipher<br />
<br />
<br />
{{Note| If hibernation usage is planned, swap must be encrypted in this fashion. Otherwise if hibernation is not a planned feature for the system, encrypting the swap file will be performed in a alternative manner.}}<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
<br />
'''Unlocking/Mapping LUKS Partitions with the Device Mapper'''<br />
<br />
Once the LUKS partitions have been created it is time to unlock them. <br />
<br />
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that /dev/<partition name> is actually an encrypted device and should be addressed through LUKS using the /dev/mapper/<name> so as not to overwrite the encrypted data. <br />
<br />
<br />
In order to open an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup luksOpen /dev/<partition name> <device-mapper name><br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda2 '''swap'''<br />
::::Once opened the swap partition device address would be '''/dev/mapper/swap''' instead of /dev/sda2<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda3 '''root'''<br />
::::Once opened the root partition device address would be '''/dev/mapper/root''' instead of /dev/sda3<br />
<br />
<br />
{{Note| Since /boot is not encrypted it does not need a device mapped name and will be addressed as /dev/sda1.}}<br />
<br />
<br />
{{Warning| In order to write encrypted data into the partition it must be accessed through the device mapped name.}}<br />
<br />
==== Using LUKS to Format Paritions with a Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
=== Storing the Key File ===<br />
<br />
==== External Storage on a USB Drive ====<br />
<br />
===== Preparation for permanent device names =====<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
===== Quick method =====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
==== Generating the keyfile ====<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
==== Storing the keyfile ====<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
=== Encrypting the Swap partition ===<br />
<br />
<br />
==== Encrypting Swap without Suspend Support ====<br />
<br />
In systems where suspend to disk is not a desired feature, it is possible to create a swap file that will have a random passphrase with each boot.<br />
<br />
This is accomplished by using dm-crypt directly without LUKS extensions.<br />
<br />
<br />
Execute the following command to setup a randomly encrypted swap partition:<br />
<br />
# echo swap <swap physical partition> <device-mapper name> "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
<br />
This command adds the following swap partition details to /mnt/etc/crypttab:<br />
<br />
::*'echo' and '>> /mnt/etc/crypttab' adds the command to the file /mnt/etc/crypttab directly<br />
::*swap identifies the partition as a swap partition<br />
::*-c defines a cipher<br />
::*-h defines a hash algorithm<br />
::*-s defines the key size<br />
<br />
<br />
Example (/dev/sda2 is the physical swap partition):<br />
<br />
::*echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
:::Maps /dev/sda2 to /dev/mapper/SWAP as a swap partition which is encrypted by AES with Whirlpool as the hash algorithm.<br />
<br />
<br />
There are many hash algorithms that can be employed, for further details [[http://en.wikipedia.org/wiki/Cryptographic_hash_function Cryptographic Hash Functions]]. <br />
<br />
<br />
{{Tip | Many people prefer Whirlpool as it is patent free. On modern hardware this is minimal performance difference between algorithms.}}<br />
<br />
<br />
If the partition chosen for swap was previously a LUKS partition, crypttab will not overwite to partition to create a swap partition. This is safetly measure to prevent data loss from accidental miss identification of the swap partition in crypttab. In order to use such a partition the LUKS header must be removed. This can be accomplished by<br />
<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
==== Encrypted swap with suspend-to-disk support ====<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Installing the system ==<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=118878Dm-crypt2010-10-09T03:10:34Z<p>Vinhsynd: /* Storing the Key File */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is to simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Initial Setup ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
<code>dd if=/dev/urandom of=/dev/<drive> bs=1M</code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
<code>badblocks -c 10240 -Wsvt random /dev/<drive></code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]] which is suggested reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
<br />
'''How does LVM fit into the overall system?'''<br />
<br />
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKs). It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKs on LVM). However the deployment of LVM on LUKS is considered much more generalizable. One reason for this that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In which case, logical volume management would be layered on top of the hardware encryption - usage of LUKS would be superfluous.<br />
<br />
<br />
==== Creating Disk Partitions ====<br />
<br />
Disk partitions are created using:<br />
<br />
# cfdisk<br />
<br />
This will display a graphical interface for creating disk partitions.<br />
<br />
There are 3 required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*'''/'''<br />
<br />
::An initial boot partition<br />
<br />
:::*'''/boot'''<br />
<br />
::A swap partition<br />
<br />
:::*'''swap'''<br />
<br />
<br />
'''Single Disk Systems'''<br />
<br />
Depending on the system demands, there may be additional partitions desired. These partitions can be individually created at this level by defining separate primary or extended/logical partitions. However if LVM is to be employed, the space unoccupied by /boot and swap should be defined as single large partition which will be divided up later at the logical volume manager level.<br />
<br />
<br />
'''Multiple Disk Systems'''<br />
<br />
In systems that will have multiple harddisk drives, the same options exist as a single disk system. After the creation of the /boot and swap partitions, the remaining free space on physical disks can divided up into their respective partitions at this level, or large partitions can define all free space per physical disk with intent to partition them within the LVM.<br />
<br />
== Configuring LUKS ==<br />
<br />
Creating LUKS partitions with a passphrase is supported by the /arch/setup program. <br />
<br />
This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. <br />
<br />
The steps for accomplishing this through the graphical installer are very similar and can be located in dialogue for manual configuration of the hard drive.<br />
<br />
<br />
<br />
=== Mapping Physical Partitions to LUKS ===<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions and then mount them through the device mapper.<br />
<br />
When creating LUKS partitions they must be associated with a key. <br />
<br />
A key is either a: <br />
<br />
::*Passphrase<br />
::*Keyfile <br />
<br />
It is possible to define up to 8 different keys can be defined per LUKS partition.<br />
<br />
<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
There are many options that cryptsetup with accept, a full list can be reference in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::-c defines the cipher type<br />
::-y prompts for password confirmation on password creation<br />
::-s defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
<br />
In the following examples for creating LUKS partitions we will use AES with XTS, at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup and details about them can be found [[http://en.wikipedia.org/wiki/Block_cipher Wikipedia: BlockCipher]]<br />
<br />
<br />
'''Formating LUKS Partitions'''<br />
<br />
In order to format a desired partition as an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/<partition name><br />
Enter passphrase: <password><br />
Verify passphrase: <password><br />
<br />
<br />
This should be repeated until all partitions except for /boot and possibly swap.<br />
<br />
<br />
Example:<br />
<br />
::*cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2<br />
:::Will create and encrypted root partition using the AES cipher<br />
<br />
<br />
{{Note| If hibernation usage is planned, swap must be encrypted in this fashion. Otherwise if hibernation is not a planned feature for the system, encrypting the swap file will be performed in a alternative manner.}}<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
<br />
'''Unlocking/Mapping LUKS Partitions with the Device Mapper'''<br />
<br />
Once the LUKS partitions have been created it is time to unlock them. <br />
<br />
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that /dev/<partition name> is actually an encrypted device and should be addressed through LUKS using the /dev/mapper/<name> so as not to overwrite the encrypted data. <br />
<br />
<br />
In order to open an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup luksOpen /dev/<partition name> <device-mapper name><br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda2 '''swap'''<br />
::::Once opened the swap partition device address would be '''/dev/mapper/swap''' instead of /dev/sda2<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda3 '''root'''<br />
::::Once opened the root partition device address would be '''/dev/mapper/root''' instead of /dev/sda3<br />
<br />
<br />
{{Note| Since /boot is not encrypted it does not need a device mapped name and will be addressed as /dev/sda1.}}<br />
<br />
<br />
{{Warning| In order to write encrypted data into the partition it must be accessed through the device mapped name.}}<br />
<br />
==== Using LUKS to Format Paritions with a Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
=== Storing the Key File ===<br />
<br />
==== External Storage on a USB Drive ====<br />
<br />
===== Preparation for permanent device names =====<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
===== Quick method =====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
==== Generating the keyfile ====<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
==== Storing the keyfile ====<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
=== Encrypting the Swap partition ===<br />
<br />
<br />
==== Encrypting Swap without Suspend Support ====<br />
<br />
In systems where suspend to disk is not a desired feature, it is possible to create a swap file that will have a random passphrase with each boot.<br />
<br />
This is accomplished by using dm-crypt directly without LUKS extensions.<br />
<br />
<br />
Execute the following command to setup a randomly encrypted swap partition:<br />
<br />
# echo swap <swap physical partition> <device-mapper name> "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
<br />
This command adds the following swap partition details to /mnt/etc/crypttab:<br />
<br />
::*'echo' and '>> /mnt/etc/crypttab' adds the command to the file /mnt/etc/crypttab directly<br />
::*swap identifies the partition as a swap partition<br />
::*-c defines a cipher<br />
::*-h defines a hash algorithm<br />
::*-s defines the key size<br />
<br />
<br />
Example (/dev/sda2 is the physical swap partition):<br />
<br />
::*echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
:::Maps /dev/sda2 to /dev/mapper/SWAP as a swap partition which is encrypted by AES with Whirlpool as the hash algorithm.<br />
<br />
<br />
There are many hash algorithms that can be employed, for further details [[http://en.wikipedia.org/wiki/Cryptographic_hash_function Cryptographic Hash Functions]]. <br />
<br />
<br />
{{Tip | Many people prefer Whirlpool as it is patent free. On modern hardware this is minimal performance difference between algorithms.}}<br />
<br />
<br />
If the partition chosen for swap was previously a LUKS partition, crypttab will not overwite to partition to create a swap partition. This is safetly measure to prevent data loss from accidental miss identification of the swap partition in crypttab. In order to use such a partition the LUKS header must be removed. This can be accomplished by<br />
<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
==== Encrypted swap with suspend-to-disk support ====<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Installing the system ==<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=118877Dm-crypt2010-10-09T03:09:13Z<p>Vinhsynd: /* TEMP */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is to simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Initial Setup ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
<code>dd if=/dev/urandom of=/dev/<drive> bs=1M</code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
<code>badblocks -c 10240 -Wsvt random /dev/<drive></code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]] which is suggested reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
<br />
'''How does LVM fit into the overall system?'''<br />
<br />
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKs). It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKs on LVM). However the deployment of LVM on LUKS is considered much more generalizable. One reason for this that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In which case, logical volume management would be layered on top of the hardware encryption - usage of LUKS would be superfluous.<br />
<br />
<br />
==== Creating Disk Partitions ====<br />
<br />
Disk partitions are created using:<br />
<br />
# cfdisk<br />
<br />
This will display a graphical interface for creating disk partitions.<br />
<br />
There are 3 required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*'''/'''<br />
<br />
::An initial boot partition<br />
<br />
:::*'''/boot'''<br />
<br />
::A swap partition<br />
<br />
:::*'''swap'''<br />
<br />
<br />
'''Single Disk Systems'''<br />
<br />
Depending on the system demands, there may be additional partitions desired. These partitions can be individually created at this level by defining separate primary or extended/logical partitions. However if LVM is to be employed, the space unoccupied by /boot and swap should be defined as single large partition which will be divided up later at the logical volume manager level.<br />
<br />
<br />
'''Multiple Disk Systems'''<br />
<br />
In systems that will have multiple harddisk drives, the same options exist as a single disk system. After the creation of the /boot and swap partitions, the remaining free space on physical disks can divided up into their respective partitions at this level, or large partitions can define all free space per physical disk with intent to partition them within the LVM.<br />
<br />
== Configuring LUKS ==<br />
<br />
Creating LUKS partitions with a passphrase is supported by the /arch/setup program. <br />
<br />
This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. <br />
<br />
The steps for accomplishing this through the graphical installer are very similar and can be located in dialogue for manual configuration of the hard drive.<br />
<br />
<br />
<br />
=== Mapping Physical Partitions to LUKS ===<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions and then mount them through the device mapper.<br />
<br />
When creating LUKS partitions they must be associated with a key. <br />
<br />
A key is either a: <br />
<br />
::*Passphrase<br />
::*Keyfile <br />
<br />
It is possible to define up to 8 different keys can be defined per LUKS partition.<br />
<br />
<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
There are many options that cryptsetup with accept, a full list can be reference in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::-c defines the cipher type<br />
::-y prompts for password confirmation on password creation<br />
::-s defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
<br />
In the following examples for creating LUKS partitions we will use AES with XTS, at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup and details about them can be found [[http://en.wikipedia.org/wiki/Block_cipher Wikipedia: BlockCipher]]<br />
<br />
<br />
'''Formating LUKS Partitions'''<br />
<br />
In order to format a desired partition as an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/<partition name><br />
Enter passphrase: <password><br />
Verify passphrase: <password><br />
<br />
<br />
This should be repeated until all partitions except for /boot and possibly swap.<br />
<br />
<br />
Example:<br />
<br />
::*cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2<br />
:::Will create and encrypted root partition using the AES cipher<br />
<br />
<br />
{{Note| If hibernation usage is planned, swap must be encrypted in this fashion. Otherwise if hibernation is not a planned feature for the system, encrypting the swap file will be performed in a alternative manner.}}<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
<br />
'''Unlocking/Mapping LUKS Partitions with the Device Mapper'''<br />
<br />
Once the LUKS partitions have been created it is time to unlock them. <br />
<br />
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that /dev/<partition name> is actually an encrypted device and should be addressed through LUKS using the /dev/mapper/<name> so as not to overwrite the encrypted data. <br />
<br />
<br />
In order to open an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup luksOpen /dev/<partition name> <device-mapper name><br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda2 '''swap'''<br />
::::Once opened the swap partition device address would be '''/dev/mapper/swap''' instead of /dev/sda2<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda3 '''root'''<br />
::::Once opened the root partition device address would be '''/dev/mapper/root''' instead of /dev/sda3<br />
<br />
<br />
{{Note| Since /boot is not encrypted it does not need a device mapped name and will be addressed as /dev/sda1.}}<br />
<br />
<br />
{{Warning| In order to write encrypted data into the partition it must be accessed through the device mapped name.}}<br />
<br />
==== Using LUKS to Format Paritions with a Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
=== Storing the Key File ===<br />
<br />
==== External Storage on a USB Drive ====<br />
<br />
===== Preparation for permanent device names =====<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
===== Quick method =====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
==== Generating the keyfile ====<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
==== Storing the keyfile ====<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
=== Encrypting the Swap partition ===<br />
<br />
<br />
==== Encrypting Swap without Suspend Support ====<br />
<br />
In systems where suspend to disk is not a desired feature, it is possible to create a swap file that will have a random passphrase with each boot.<br />
<br />
This is accomplished by using dm-crypt directly without LUKS extensions.<br />
<br />
<br />
Execute the following command to setup a randomly encrypted swap partition:<br />
<br />
# echo swap <swap physical partition> <device-mapper name> "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
<br />
This command adds the following swap partition details to /mnt/etc/crypttab:<br />
<br />
::*'echo' and '>> /mnt/etc/crypttab' adds the command to the file /mnt/etc/crypttab directly<br />
::*swap identifies the partition as a swap partition<br />
::*-c defines a cipher<br />
::*-h defines a hash algorithm<br />
::*-s defines the key size<br />
<br />
<br />
Example (/dev/sda2 is the physical swap partition):<br />
<br />
::*echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
:::Maps /dev/sda2 to /dev/mapper/SWAP as a swap partition which is encrypted by AES with Whirlpool as the hash algorithm.<br />
<br />
<br />
There are many hash algorithms that can be employed, for further details [[http://en.wikipedia.org/wiki/Cryptographic_hash_function Cryptographic Hash Functions]]. <br />
<br />
<br />
{{Tip | Many people prefer Whirlpool as it is patent free. On modern hardware this is minimal performance difference between algorithms.}}<br />
<br />
<br />
If the partition chosen for swap was previously a LUKS partition, crypttab will not overwite to partition to create a swap partition. This is safetly measure to prevent data loss from accidental miss identification of the swap partition in crypttab. In order to use such a partition the LUKS header must be removed. This can be accomplished by<br />
<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
==== Encrypted swap with suspend-to-disk support ====<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Installing the system ==<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Storing the Key File ==<br />
<br />
=== External Storage on a USB Drive ===<br />
<br />
==== Preparation for permanent device names ====<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
===== Quick method =====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
==== Generating the keyfile ====<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
==== Storing the keyfile ====<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=118876Dm-crypt2010-10-09T03:08:27Z<p>Vinhsynd: /* Encrypting the Swap partition */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is to simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Initial Setup ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
<code>dd if=/dev/urandom of=/dev/<drive> bs=1M</code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
<code>badblocks -c 10240 -Wsvt random /dev/<drive></code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]] which is suggested reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
<br />
'''How does LVM fit into the overall system?'''<br />
<br />
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKs). It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKs on LVM). However the deployment of LVM on LUKS is considered much more generalizable. One reason for this that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In which case, logical volume management would be layered on top of the hardware encryption - usage of LUKS would be superfluous.<br />
<br />
<br />
==== Creating Disk Partitions ====<br />
<br />
Disk partitions are created using:<br />
<br />
# cfdisk<br />
<br />
This will display a graphical interface for creating disk partitions.<br />
<br />
There are 3 required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*'''/'''<br />
<br />
::An initial boot partition<br />
<br />
:::*'''/boot'''<br />
<br />
::A swap partition<br />
<br />
:::*'''swap'''<br />
<br />
<br />
'''Single Disk Systems'''<br />
<br />
Depending on the system demands, there may be additional partitions desired. These partitions can be individually created at this level by defining separate primary or extended/logical partitions. However if LVM is to be employed, the space unoccupied by /boot and swap should be defined as single large partition which will be divided up later at the logical volume manager level.<br />
<br />
<br />
'''Multiple Disk Systems'''<br />
<br />
In systems that will have multiple harddisk drives, the same options exist as a single disk system. After the creation of the /boot and swap partitions, the remaining free space on physical disks can divided up into their respective partitions at this level, or large partitions can define all free space per physical disk with intent to partition them within the LVM.<br />
<br />
== Configuring LUKS ==<br />
<br />
Creating LUKS partitions with a passphrase is supported by the /arch/setup program. <br />
<br />
This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. <br />
<br />
The steps for accomplishing this through the graphical installer are very similar and can be located in dialogue for manual configuration of the hard drive.<br />
<br />
<br />
<br />
=== Mapping Physical Partitions to LUKS ===<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions and then mount them through the device mapper.<br />
<br />
When creating LUKS partitions they must be associated with a key. <br />
<br />
A key is either a: <br />
<br />
::*Passphrase<br />
::*Keyfile <br />
<br />
It is possible to define up to 8 different keys can be defined per LUKS partition.<br />
<br />
<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
There are many options that cryptsetup with accept, a full list can be reference in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::-c defines the cipher type<br />
::-y prompts for password confirmation on password creation<br />
::-s defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
<br />
In the following examples for creating LUKS partitions we will use AES with XTS, at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup and details about them can be found [[http://en.wikipedia.org/wiki/Block_cipher Wikipedia: BlockCipher]]<br />
<br />
<br />
'''Formating LUKS Partitions'''<br />
<br />
In order to format a desired partition as an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/<partition name><br />
Enter passphrase: <password><br />
Verify passphrase: <password><br />
<br />
<br />
This should be repeated until all partitions except for /boot and possibly swap.<br />
<br />
<br />
Example:<br />
<br />
::*cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2<br />
:::Will create and encrypted root partition using the AES cipher<br />
<br />
<br />
{{Note| If hibernation usage is planned, swap must be encrypted in this fashion. Otherwise if hibernation is not a planned feature for the system, encrypting the swap file will be performed in a alternative manner.}}<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
<br />
'''Unlocking/Mapping LUKS Partitions with the Device Mapper'''<br />
<br />
Once the LUKS partitions have been created it is time to unlock them. <br />
<br />
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that /dev/<partition name> is actually an encrypted device and should be addressed through LUKS using the /dev/mapper/<name> so as not to overwrite the encrypted data. <br />
<br />
<br />
In order to open an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup luksOpen /dev/<partition name> <device-mapper name><br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda2 '''swap'''<br />
::::Once opened the swap partition device address would be '''/dev/mapper/swap''' instead of /dev/sda2<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda3 '''root'''<br />
::::Once opened the root partition device address would be '''/dev/mapper/root''' instead of /dev/sda3<br />
<br />
<br />
{{Note| Since /boot is not encrypted it does not need a device mapped name and will be addressed as /dev/sda1.}}<br />
<br />
<br />
{{Warning| In order to write encrypted data into the partition it must be accessed through the device mapped name.}}<br />
<br />
==== Using LUKS to Format Paritions with a Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
=== TEMP ===<br />
=== Encrypting the Swap partition ===<br />
<br />
<br />
==== Encrypting Swap without Suspend Support ====<br />
<br />
In systems where suspend to disk is not a desired feature, it is possible to create a swap file that will have a random passphrase with each boot.<br />
<br />
This is accomplished by using dm-crypt directly without LUKS extensions.<br />
<br />
<br />
Execute the following command to setup a randomly encrypted swap partition:<br />
<br />
# echo swap <swap physical partition> <device-mapper name> "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
<br />
This command adds the following swap partition details to /mnt/etc/crypttab:<br />
<br />
::*'echo' and '>> /mnt/etc/crypttab' adds the command to the file /mnt/etc/crypttab directly<br />
::*swap identifies the partition as a swap partition<br />
::*-c defines a cipher<br />
::*-h defines a hash algorithm<br />
::*-s defines the key size<br />
<br />
<br />
Example (/dev/sda2 is the physical swap partition):<br />
<br />
::*echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
:::Maps /dev/sda2 to /dev/mapper/SWAP as a swap partition which is encrypted by AES with Whirlpool as the hash algorithm.<br />
<br />
<br />
There are many hash algorithms that can be employed, for further details [[http://en.wikipedia.org/wiki/Cryptographic_hash_function Cryptographic Hash Functions]]. <br />
<br />
<br />
{{Tip | Many people prefer Whirlpool as it is patent free. On modern hardware this is minimal performance difference between algorithms.}}<br />
<br />
<br />
If the partition chosen for swap was previously a LUKS partition, crypttab will not overwite to partition to create a swap partition. This is safetly measure to prevent data loss from accidental miss identification of the swap partition in crypttab. In order to use such a partition the LUKS header must be removed. This can be accomplished by<br />
<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
==== Encrypted swap with suspend-to-disk support ====<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Installing the system ==<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Storing the Key File ==<br />
<br />
=== External Storage on a USB Drive ===<br />
<br />
==== Preparation for permanent device names ====<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
===== Quick method =====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
==== Generating the keyfile ====<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
==== Storing the keyfile ====<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=118875Dm-crypt2010-10-09T03:07:16Z<p>Vinhsynd: /* Storing the key externally (USB stick) */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is to simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Initial Setup ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
<code>dd if=/dev/urandom of=/dev/<drive> bs=1M</code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
<code>badblocks -c 10240 -Wsvt random /dev/<drive></code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]] which is suggested reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
<br />
'''How does LVM fit into the overall system?'''<br />
<br />
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKs). It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKs on LVM). However the deployment of LVM on LUKS is considered much more generalizable. One reason for this that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In which case, logical volume management would be layered on top of the hardware encryption - usage of LUKS would be superfluous.<br />
<br />
<br />
==== Creating Disk Partitions ====<br />
<br />
Disk partitions are created using:<br />
<br />
# cfdisk<br />
<br />
This will display a graphical interface for creating disk partitions.<br />
<br />
There are 3 required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*'''/'''<br />
<br />
::An initial boot partition<br />
<br />
:::*'''/boot'''<br />
<br />
::A swap partition<br />
<br />
:::*'''swap'''<br />
<br />
<br />
'''Single Disk Systems'''<br />
<br />
Depending on the system demands, there may be additional partitions desired. These partitions can be individually created at this level by defining separate primary or extended/logical partitions. However if LVM is to be employed, the space unoccupied by /boot and swap should be defined as single large partition which will be divided up later at the logical volume manager level.<br />
<br />
<br />
'''Multiple Disk Systems'''<br />
<br />
In systems that will have multiple harddisk drives, the same options exist as a single disk system. After the creation of the /boot and swap partitions, the remaining free space on physical disks can divided up into their respective partitions at this level, or large partitions can define all free space per physical disk with intent to partition them within the LVM.<br />
<br />
== Configuring LUKS ==<br />
<br />
Creating LUKS partitions with a passphrase is supported by the /arch/setup program. <br />
<br />
This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. <br />
<br />
The steps for accomplishing this through the graphical installer are very similar and can be located in dialogue for manual configuration of the hard drive.<br />
<br />
<br />
<br />
=== Mapping Physical Partitions to LUKS ===<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions and then mount them through the device mapper.<br />
<br />
When creating LUKS partitions they must be associated with a key. <br />
<br />
A key is either a: <br />
<br />
::*Passphrase<br />
::*Keyfile <br />
<br />
It is possible to define up to 8 different keys can be defined per LUKS partition.<br />
<br />
<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
There are many options that cryptsetup with accept, a full list can be reference in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::-c defines the cipher type<br />
::-y prompts for password confirmation on password creation<br />
::-s defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
<br />
In the following examples for creating LUKS partitions we will use AES with XTS, at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup and details about them can be found [[http://en.wikipedia.org/wiki/Block_cipher Wikipedia: BlockCipher]]<br />
<br />
<br />
'''Formating LUKS Partitions'''<br />
<br />
In order to format a desired partition as an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/<partition name><br />
Enter passphrase: <password><br />
Verify passphrase: <password><br />
<br />
<br />
This should be repeated until all partitions except for /boot and possibly swap.<br />
<br />
<br />
Example:<br />
<br />
::*cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2<br />
:::Will create and encrypted root partition using the AES cipher<br />
<br />
<br />
{{Note| If hibernation usage is planned, swap must be encrypted in this fashion. Otherwise if hibernation is not a planned feature for the system, encrypting the swap file will be performed in a alternative manner.}}<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
<br />
'''Unlocking/Mapping LUKS Partitions with the Device Mapper'''<br />
<br />
Once the LUKS partitions have been created it is time to unlock them. <br />
<br />
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that /dev/<partition name> is actually an encrypted device and should be addressed through LUKS using the /dev/mapper/<name> so as not to overwrite the encrypted data. <br />
<br />
<br />
In order to open an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup luksOpen /dev/<partition name> <device-mapper name><br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda2 '''swap'''<br />
::::Once opened the swap partition device address would be '''/dev/mapper/swap''' instead of /dev/sda2<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda3 '''root'''<br />
::::Once opened the root partition device address would be '''/dev/mapper/root''' instead of /dev/sda3<br />
<br />
<br />
{{Note| Since /boot is not encrypted it does not need a device mapped name and will be addressed as /dev/sda1.}}<br />
<br />
<br />
{{Warning| In order to write encrypted data into the partition it must be accessed through the device mapped name.}}<br />
<br />
==== Using LUKS to Format Paritions with a Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
=== Encrypting the Swap partition ===<br />
<br />
<br />
==== Encrypting Swap without Suspend Support ====<br />
<br />
In systems where suspend to disk is not a desired feature, it is possible to create a swap file that will have a random passphrase with each boot.<br />
<br />
This is accomplished by using dm-crypt directly without LUKS extensions.<br />
<br />
<br />
Execute the following command to setup a randomly encrypted swap partition:<br />
<br />
# echo swap <swap physical partition> <device-mapper name> "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
<br />
This command adds the following swap partition details to /mnt/etc/crypttab:<br />
<br />
::*'echo' and '>> /mnt/etc/crypttab' adds the command to the file /mnt/etc/crypttab directly<br />
::*swap identifies the partition as a swap partition<br />
::*-c defines a cipher<br />
::*-h defines a hash algorithm<br />
::*-s defines the key size<br />
<br />
<br />
Example (/dev/sda2 is the physical swap partition):<br />
<br />
::*echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
:::Maps /dev/sda2 to /dev/mapper/SWAP as a swap partition which is encrypted by AES with Whirlpool as the hash algorithm.<br />
<br />
<br />
There are many hash algorithms that can be employed, for further details [[http://en.wikipedia.org/wiki/Cryptographic_hash_function Cryptographic Hash Functions]]. <br />
<br />
<br />
{{Tip | Many people prefer Whirlpool as it is patent free. On modern hardware this is minimal performance difference between algorithms.}}<br />
<br />
<br />
If the partition chosen for swap was previously a LUKS partition, crypttab will not overwite to partition to create a swap partition. This is safetly measure to prevent data loss from accidental miss identification of the swap partition in crypttab. In order to use such a partition the LUKS header must be removed. This can be accomplished by<br />
<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
==== Encrypted swap with suspend-to-disk support ====<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Installing the system ==<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Storing the Key File ==<br />
<br />
=== External Storage on a USB Drive ===<br />
<br />
==== Preparation for permanent device names ====<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
===== Quick method =====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
==== Generating the keyfile ====<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
==== Storing the keyfile ====<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=118874Dm-crypt2010-10-09T03:04:22Z<p>Vinhsynd: /* Encrypting Swap without Suspend Support */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is to simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Initial Setup ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
<code>dd if=/dev/urandom of=/dev/<drive> bs=1M</code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
<code>badblocks -c 10240 -Wsvt random /dev/<drive></code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]] which is suggested reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
<br />
'''How does LVM fit into the overall system?'''<br />
<br />
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKs). It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKs on LVM). However the deployment of LVM on LUKS is considered much more generalizable. One reason for this that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In which case, logical volume management would be layered on top of the hardware encryption - usage of LUKS would be superfluous.<br />
<br />
<br />
==== Creating Disk Partitions ====<br />
<br />
Disk partitions are created using:<br />
<br />
# cfdisk<br />
<br />
This will display a graphical interface for creating disk partitions.<br />
<br />
There are 3 required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*'''/'''<br />
<br />
::An initial boot partition<br />
<br />
:::*'''/boot'''<br />
<br />
::A swap partition<br />
<br />
:::*'''swap'''<br />
<br />
<br />
'''Single Disk Systems'''<br />
<br />
Depending on the system demands, there may be additional partitions desired. These partitions can be individually created at this level by defining separate primary or extended/logical partitions. However if LVM is to be employed, the space unoccupied by /boot and swap should be defined as single large partition which will be divided up later at the logical volume manager level.<br />
<br />
<br />
'''Multiple Disk Systems'''<br />
<br />
In systems that will have multiple harddisk drives, the same options exist as a single disk system. After the creation of the /boot and swap partitions, the remaining free space on physical disks can divided up into their respective partitions at this level, or large partitions can define all free space per physical disk with intent to partition them within the LVM.<br />
<br />
== Configuring LUKS ==<br />
<br />
Creating LUKS partitions with a passphrase is supported by the /arch/setup program. <br />
<br />
This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. <br />
<br />
The steps for accomplishing this through the graphical installer are very similar and can be located in dialogue for manual configuration of the hard drive.<br />
<br />
<br />
<br />
=== Mapping Physical Partitions to LUKS ===<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions and then mount them through the device mapper.<br />
<br />
When creating LUKS partitions they must be associated with a key. <br />
<br />
A key is either a: <br />
<br />
::*Passphrase<br />
::*Keyfile <br />
<br />
It is possible to define up to 8 different keys can be defined per LUKS partition.<br />
<br />
<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
There are many options that cryptsetup with accept, a full list can be reference in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::-c defines the cipher type<br />
::-y prompts for password confirmation on password creation<br />
::-s defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
<br />
In the following examples for creating LUKS partitions we will use AES with XTS, at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup and details about them can be found [[http://en.wikipedia.org/wiki/Block_cipher Wikipedia: BlockCipher]]<br />
<br />
<br />
'''Formating LUKS Partitions'''<br />
<br />
In order to format a desired partition as an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/<partition name><br />
Enter passphrase: <password><br />
Verify passphrase: <password><br />
<br />
<br />
This should be repeated until all partitions except for /boot and possibly swap.<br />
<br />
<br />
Example:<br />
<br />
::*cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2<br />
:::Will create and encrypted root partition using the AES cipher<br />
<br />
<br />
{{Note| If hibernation usage is planned, swap must be encrypted in this fashion. Otherwise if hibernation is not a planned feature for the system, encrypting the swap file will be performed in a alternative manner.}}<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
<br />
'''Unlocking/Mapping LUKS Partitions with the Device Mapper'''<br />
<br />
Once the LUKS partitions have been created it is time to unlock them. <br />
<br />
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that /dev/<partition name> is actually an encrypted device and should be addressed through LUKS using the /dev/mapper/<name> so as not to overwrite the encrypted data. <br />
<br />
<br />
In order to open an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup luksOpen /dev/<partition name> <device-mapper name><br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda2 '''swap'''<br />
::::Once opened the swap partition device address would be '''/dev/mapper/swap''' instead of /dev/sda2<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda3 '''root'''<br />
::::Once opened the root partition device address would be '''/dev/mapper/root''' instead of /dev/sda3<br />
<br />
<br />
{{Note| Since /boot is not encrypted it does not need a device mapped name and will be addressed as /dev/sda1.}}<br />
<br />
<br />
{{Warning| In order to write encrypted data into the partition it must be accessed through the device mapped name.}}<br />
<br />
==== Using LUKS to Format Paritions with a Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
=== Encrypting the Swap partition ===<br />
<br />
<br />
==== Encrypting Swap without Suspend Support ====<br />
<br />
In systems where suspend to disk is not a desired feature, it is possible to create a swap file that will have a random passphrase with each boot.<br />
<br />
This is accomplished by using dm-crypt directly without LUKS extensions.<br />
<br />
<br />
Execute the following command to setup a randomly encrypted swap partition:<br />
<br />
# echo swap <swap physical partition> <device-mapper name> "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
<br />
This command adds the following swap partition details to /mnt/etc/crypttab:<br />
<br />
::*'echo' and '>> /mnt/etc/crypttab' adds the command to the file /mnt/etc/crypttab directly<br />
::*swap identifies the partition as a swap partition<br />
::*-c defines a cipher<br />
::*-h defines a hash algorithm<br />
::*-s defines the key size<br />
<br />
<br />
Example (/dev/sda2 is the physical swap partition):<br />
<br />
::*echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
:::Maps /dev/sda2 to /dev/mapper/SWAP as a swap partition which is encrypted by AES with Whirlpool as the hash algorithm.<br />
<br />
<br />
There are many hash algorithms that can be employed, for further details [[http://en.wikipedia.org/wiki/Cryptographic_hash_function Cryptographic Hash Functions]]. <br />
<br />
<br />
{{Tip | Many people prefer Whirlpool as it is patent free. On modern hardware this is minimal performance difference between algorithms.}}<br />
<br />
<br />
If the partition chosen for swap was previously a LUKS partition, crypttab will not overwite to partition to create a swap partition. This is safetly measure to prevent data loss from accidental miss identification of the swap partition in crypttab. In order to use such a partition the LUKS header must be removed. This can be accomplished by<br />
<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
==== Encrypted swap with suspend-to-disk support ====<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Installing the system ==<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Storing the key externally (USB stick) ==<br />
=== Preparation for permanent device names ===<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
==== Quick method ====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
=== Generating the keyfile ===<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
=== Storing the keyfile ===<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=118873Dm-crypt2010-10-09T01:44:40Z<p>Vinhsynd: /* Encrypting the Swap partition */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is to simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Initial Setup ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
<code>dd if=/dev/urandom of=/dev/<drive> bs=1M</code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
<code>badblocks -c 10240 -Wsvt random /dev/<drive></code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]] which is suggested reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
<br />
'''How does LVM fit into the overall system?'''<br />
<br />
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKs). It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKs on LVM). However the deployment of LVM on LUKS is considered much more generalizable. One reason for this that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In which case, logical volume management would be layered on top of the hardware encryption - usage of LUKS would be superfluous.<br />
<br />
<br />
==== Creating Disk Partitions ====<br />
<br />
Disk partitions are created using:<br />
<br />
# cfdisk<br />
<br />
This will display a graphical interface for creating disk partitions.<br />
<br />
There are 3 required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*'''/'''<br />
<br />
::An initial boot partition<br />
<br />
:::*'''/boot'''<br />
<br />
::A swap partition<br />
<br />
:::*'''swap'''<br />
<br />
<br />
'''Single Disk Systems'''<br />
<br />
Depending on the system demands, there may be additional partitions desired. These partitions can be individually created at this level by defining separate primary or extended/logical partitions. However if LVM is to be employed, the space unoccupied by /boot and swap should be defined as single large partition which will be divided up later at the logical volume manager level.<br />
<br />
<br />
'''Multiple Disk Systems'''<br />
<br />
In systems that will have multiple harddisk drives, the same options exist as a single disk system. After the creation of the /boot and swap partitions, the remaining free space on physical disks can divided up into their respective partitions at this level, or large partitions can define all free space per physical disk with intent to partition them within the LVM.<br />
<br />
== Configuring LUKS ==<br />
<br />
Creating LUKS partitions with a passphrase is supported by the /arch/setup program. <br />
<br />
This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. <br />
<br />
The steps for accomplishing this through the graphical installer are very similar and can be located in dialogue for manual configuration of the hard drive.<br />
<br />
<br />
<br />
=== Mapping Physical Partitions to LUKS ===<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions and then mount them through the device mapper.<br />
<br />
When creating LUKS partitions they must be associated with a key. <br />
<br />
A key is either a: <br />
<br />
::*Passphrase<br />
::*Keyfile <br />
<br />
It is possible to define up to 8 different keys can be defined per LUKS partition.<br />
<br />
<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
There are many options that cryptsetup with accept, a full list can be reference in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::-c defines the cipher type<br />
::-y prompts for password confirmation on password creation<br />
::-s defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
<br />
In the following examples for creating LUKS partitions we will use AES with XTS, at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup and details about them can be found [[http://en.wikipedia.org/wiki/Block_cipher Wikipedia: BlockCipher]]<br />
<br />
<br />
'''Formating LUKS Partitions'''<br />
<br />
In order to format a desired partition as an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/<partition name><br />
Enter passphrase: <password><br />
Verify passphrase: <password><br />
<br />
<br />
This should be repeated until all partitions except for /boot and possibly swap.<br />
<br />
<br />
Example:<br />
<br />
::*cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2<br />
:::Will create and encrypted root partition using the AES cipher<br />
<br />
<br />
{{Note| If hibernation usage is planned, swap must be encrypted in this fashion. Otherwise if hibernation is not a planned feature for the system, encrypting the swap file will be performed in a alternative manner.}}<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
<br />
'''Unlocking/Mapping LUKS Partitions with the Device Mapper'''<br />
<br />
Once the LUKS partitions have been created it is time to unlock them. <br />
<br />
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that /dev/<partition name> is actually an encrypted device and should be addressed through LUKS using the /dev/mapper/<name> so as not to overwrite the encrypted data. <br />
<br />
<br />
In order to open an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup luksOpen /dev/<partition name> <device-mapper name><br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda2 '''swap'''<br />
::::Once opened the swap partition device address would be '''/dev/mapper/swap''' instead of /dev/sda2<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda3 '''root'''<br />
::::Once opened the root partition device address would be '''/dev/mapper/root''' instead of /dev/sda3<br />
<br />
<br />
{{Note| Since /boot is not encrypted it does not need a device mapped name and will be addressed as /dev/sda1.}}<br />
<br />
<br />
{{Warning| In order to write encrypted data into the partition it must be accessed through the device mapped name.}}<br />
<br />
==== Using LUKS to Format Paritions with a Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
=== Encrypting the Swap partition ===<br />
<br />
<br />
==== Encrypting Swap without Suspend Support ====<br />
Sensitive data stored in memory may be written to swap at any time. If you've gone to the trouble of encrypting your root and home partitions, you should encrypt your swap as well. There are two options here: random encryption on each boot (better security), or the same encryption each time. We won't cover the second option here, as it is pretty much identical to how you set up the /home partition above. Just replace all references to home with swap, and sda5 with sda2.<br />
<br />
Arch Linux provides a convenient way for the first option, which uses dm-crypt directly without LUKS. If you're still in the archsetup process, just switch to a different virtual console (ALT+F2). If you've exited already, the new root will have been unmounted. Use <tt>mount /dev/mapper/root /mnt</tt> to mount it again.<br />
<br />
Now add an entry to the cryptsetup file:<br />
# echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
{{ Tip | Recommended hash algorithms are "whirlpool" (patent free), "sha256", "sha384" or "sha512". Default is "ripemd160" (not recommended).}}<br />
<br />
''[why is it not recommended? only RIPEMD (128bit) was hacked RIPEMD-160 is still safe[https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=83310], isn't it? I heard wirlpool is at least twice as slow. ]''<br />
<br />
{{ Warning | Please take extra care to put the right partition here. The startup script won't ask before overwriting the provided device, destroying '''all''' data on it, ''unless it has a LUKS header'', then it simply won't work.}}<br />
<br />
If you have been following these instructions closely, then in the section "Mapping Partitions" above you put a LUKS header on your swap partition. Erase it with something like the command below, replacing /dev/sda2 with the appropriate swap device:<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
From now on, each time you boot, the partition will be encrypted automatically with a random key, and will then be formated with mkswap.<br />
<br />
Now all you have to do is adjust the corresponding entry in /etc/fstab:<br />
/dev/mapper/swap swap swap defaults 0 0<br />
<br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
==== Encrypted swap with suspend-to-disk support ====<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Installing the system ==<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Storing the key externally (USB stick) ==<br />
=== Preparation for permanent device names ===<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
==== Quick method ====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
=== Generating the keyfile ===<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
=== Storing the keyfile ===<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=118872Dm-crypt2010-10-09T01:44:08Z<p>Vinhsynd: /* Encrypting the Swap partition */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is to simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Initial Setup ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
<code>dd if=/dev/urandom of=/dev/<drive> bs=1M</code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
<code>badblocks -c 10240 -Wsvt random /dev/<drive></code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]] which is suggested reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
<br />
'''How does LVM fit into the overall system?'''<br />
<br />
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKs). It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKs on LVM). However the deployment of LVM on LUKS is considered much more generalizable. One reason for this that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In which case, logical volume management would be layered on top of the hardware encryption - usage of LUKS would be superfluous.<br />
<br />
<br />
==== Creating Disk Partitions ====<br />
<br />
Disk partitions are created using:<br />
<br />
# cfdisk<br />
<br />
This will display a graphical interface for creating disk partitions.<br />
<br />
There are 3 required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*'''/'''<br />
<br />
::An initial boot partition<br />
<br />
:::*'''/boot'''<br />
<br />
::A swap partition<br />
<br />
:::*'''swap'''<br />
<br />
<br />
'''Single Disk Systems'''<br />
<br />
Depending on the system demands, there may be additional partitions desired. These partitions can be individually created at this level by defining separate primary or extended/logical partitions. However if LVM is to be employed, the space unoccupied by /boot and swap should be defined as single large partition which will be divided up later at the logical volume manager level.<br />
<br />
<br />
'''Multiple Disk Systems'''<br />
<br />
In systems that will have multiple harddisk drives, the same options exist as a single disk system. After the creation of the /boot and swap partitions, the remaining free space on physical disks can divided up into their respective partitions at this level, or large partitions can define all free space per physical disk with intent to partition them within the LVM.<br />
<br />
== Configuring LUKS ==<br />
<br />
Creating LUKS partitions with a passphrase is supported by the /arch/setup program. <br />
<br />
This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. <br />
<br />
The steps for accomplishing this through the graphical installer are very similar and can be located in dialogue for manual configuration of the hard drive.<br />
<br />
<br />
<br />
=== Mapping Physical Partitions to LUKS ===<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions and then mount them through the device mapper.<br />
<br />
When creating LUKS partitions they must be associated with a key. <br />
<br />
A key is either a: <br />
<br />
::*Passphrase<br />
::*Keyfile <br />
<br />
It is possible to define up to 8 different keys can be defined per LUKS partition.<br />
<br />
<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
There are many options that cryptsetup with accept, a full list can be reference in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::-c defines the cipher type<br />
::-y prompts for password confirmation on password creation<br />
::-s defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
<br />
In the following examples for creating LUKS partitions we will use AES with XTS, at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup and details about them can be found [[http://en.wikipedia.org/wiki/Block_cipher Wikipedia: BlockCipher]]<br />
<br />
<br />
'''Formating LUKS Partitions'''<br />
<br />
In order to format a desired partition as an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/<partition name><br />
Enter passphrase: <password><br />
Verify passphrase: <password><br />
<br />
<br />
This should be repeated until all partitions except for /boot and possibly swap.<br />
<br />
<br />
Example:<br />
<br />
::*cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2<br />
:::Will create and encrypted root partition using the AES cipher<br />
<br />
<br />
{{Note| If hibernation usage is planned, swap must be encrypted in this fashion. Otherwise if hibernation is not a planned feature for the system, encrypting the swap file will be performed in a alternative manner.}}<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
<br />
'''Unlocking/Mapping LUKS Partitions with the Device Mapper'''<br />
<br />
Once the LUKS partitions have been created it is time to unlock them. <br />
<br />
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that /dev/<partition name> is actually an encrypted device and should be addressed through LUKS using the /dev/mapper/<name> so as not to overwrite the encrypted data. <br />
<br />
<br />
In order to open an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup luksOpen /dev/<partition name> <device-mapper name><br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda2 '''swap'''<br />
::::Once opened the swap partition device address would be '''/dev/mapper/swap''' instead of /dev/sda2<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda3 '''root'''<br />
::::Once opened the root partition device address would be '''/dev/mapper/root''' instead of /dev/sda3<br />
<br />
<br />
{{Note| Since /boot is not encrypted it does not need a device mapped name and will be addressed as /dev/sda1.}}<br />
<br />
<br />
{{Warning| In order to write encrypted data into the partition it must be accessed through the device mapped name.}}<br />
<br />
==== Using LUKS to Format Paritions with a Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
=== Encrypting the Swap partition ===<br />
<br />
<br />
==== Encrypting Swap without Suspend Support ====<br />
Sensitive data stored in memory may be written to swap at any time. If you've gone to the trouble of encrypting your root and home partitions, you should encrypt your swap as well. There are two options here: random encryption on each boot (better security), or the same encryption each time. We won't cover the second option here, as it is pretty much identical to how you set up the /home partition above. Just replace all references to home with swap, and sda5 with sda2.<br />
<br />
Arch Linux provides a convenient way for the first option, which uses dm-crypt directly without LUKS. If you're still in the archsetup process, just switch to a different virtual console (ALT+F2). If you've exited already, the new root will have been unmounted. Use <tt>mount /dev/mapper/root /mnt</tt> to mount it again.<br />
<br />
Now add an entry to the cryptsetup file:<br />
# echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
{{ Tip | Recommended hash algorithms are "whirlpool" (patent free), "sha256", "sha384" or "sha512". Default is "ripemd160" (not recommended).}}<br />
<br />
''[why is it not recommended? only RIPEMD (128bit) was hacked RIPEMD-160 is still safe[https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=83310], isn't it? I heard wirlpool is at least twice as slow. ]''<br />
<br />
{{ Warning | Please take extra care to put the right partition here. The startup script won't ask before overwriting the provided device, destroying '''all''' data on it, ''unless it has a LUKS header'', then it simply won't work.}}<br />
<br />
If you have been following these instructions closely, then in the section "Mapping Partitions" above you put a LUKS header on your swap partition. Erase it with something like the command below, replacing /dev/sda2 with the appropriate swap device:<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
From now on, each time you boot, the partition will be encrypted automatically with a random key, and will then be formated with mkswap.<br />
<br />
Now all you have to do is adjust the corresponding entry in /etc/fstab:<br />
/dev/mapper/swap swap swap defaults 0 0<br />
<br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
==== Encrypted swap with suspend-to-disk support ====<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Installing the system ==<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Encrypting the Swap partition ==<br />
=== Encrypting Swap without Suspend Support ===<br />
Sensitive data stored in memory may be written to swap at any time. If you've gone to the trouble of encrypting your root and home partitions, you should encrypt your swap as well. There are two options here: random encryption on each boot (better security), or the same encryption each time. We won't cover the second option here, as it is pretty much identical to how you set up the /home partition above. Just replace all references to home with swap, and sda5 with sda2.<br />
<br />
Arch Linux provides a convenient way for the first option, which uses dm-crypt directly without LUKS. If you're still in the archsetup process, just switch to a different virtual console (ALT+F2). If you've exited already, the new root will have been unmounted. Use <tt>mount /dev/mapper/root /mnt</tt> to mount it again.<br />
<br />
Now add an entry to the cryptsetup file:<br />
# echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
{{ Tip | Recommended hash algorithms are "whirlpool" (patent free), "sha256", "sha384" or "sha512". Default is "ripemd160" (not recommended).}}<br />
<br />
''[why is it not recommended? only RIPEMD (128bit) was hacked RIPEMD-160 is still safe[https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=83310], isn't it? I heard wirlpool is at least twice as slow. ]''<br />
<br />
{{ Warning | Please take extra care to put the right partition here. The startup script won't ask before overwriting the provided device, destroying '''all''' data on it, ''unless it has a LUKS header'', then it simply won't work.}}<br />
<br />
If you have been following these instructions closely, then in the section "Mapping Partitions" above you put a LUKS header on your swap partition. Erase it with something like the command below, replacing /dev/sda2 with the appropriate swap device:<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
From now on, each time you boot, the partition will be encrypted automatically with a random key, and will then be formated with mkswap.<br />
<br />
Now all you have to do is adjust the corresponding entry in /etc/fstab:<br />
/dev/mapper/swap swap swap defaults 0 0<br />
<br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
=== Encrypted swap with suspend-to-disk support ===<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Storing the key externally (USB stick) ==<br />
=== Preparation for permanent device names ===<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
==== Quick method ====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
=== Generating the keyfile ===<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
=== Storing the keyfile ===<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=118871Dm-crypt2010-10-09T01:43:14Z<p>Vinhsynd: /* TEMP */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is to simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Initial Setup ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
<code>dd if=/dev/urandom of=/dev/<drive> bs=1M</code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
<code>badblocks -c 10240 -Wsvt random /dev/<drive></code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]] which is suggested reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
<br />
'''How does LVM fit into the overall system?'''<br />
<br />
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKs). It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKs on LVM). However the deployment of LVM on LUKS is considered much more generalizable. One reason for this that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In which case, logical volume management would be layered on top of the hardware encryption - usage of LUKS would be superfluous.<br />
<br />
<br />
==== Creating Disk Partitions ====<br />
<br />
Disk partitions are created using:<br />
<br />
# cfdisk<br />
<br />
This will display a graphical interface for creating disk partitions.<br />
<br />
There are 3 required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*'''/'''<br />
<br />
::An initial boot partition<br />
<br />
:::*'''/boot'''<br />
<br />
::A swap partition<br />
<br />
:::*'''swap'''<br />
<br />
<br />
'''Single Disk Systems'''<br />
<br />
Depending on the system demands, there may be additional partitions desired. These partitions can be individually created at this level by defining separate primary or extended/logical partitions. However if LVM is to be employed, the space unoccupied by /boot and swap should be defined as single large partition which will be divided up later at the logical volume manager level.<br />
<br />
<br />
'''Multiple Disk Systems'''<br />
<br />
In systems that will have multiple harddisk drives, the same options exist as a single disk system. After the creation of the /boot and swap partitions, the remaining free space on physical disks can divided up into their respective partitions at this level, or large partitions can define all free space per physical disk with intent to partition them within the LVM.<br />
<br />
== Configuring LUKS ==<br />
<br />
Creating LUKS partitions with a passphrase is supported by the /arch/setup program. <br />
<br />
This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. <br />
<br />
The steps for accomplishing this through the graphical installer are very similar and can be located in dialogue for manual configuration of the hard drive.<br />
<br />
<br />
<br />
=== Mapping Physical Partitions to LUKS ===<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions and then mount them through the device mapper.<br />
<br />
When creating LUKS partitions they must be associated with a key. <br />
<br />
A key is either a: <br />
<br />
::*Passphrase<br />
::*Keyfile <br />
<br />
It is possible to define up to 8 different keys can be defined per LUKS partition.<br />
<br />
<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
There are many options that cryptsetup with accept, a full list can be reference in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::-c defines the cipher type<br />
::-y prompts for password confirmation on password creation<br />
::-s defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
<br />
In the following examples for creating LUKS partitions we will use AES with XTS, at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup and details about them can be found [[http://en.wikipedia.org/wiki/Block_cipher Wikipedia: BlockCipher]]<br />
<br />
<br />
'''Formating LUKS Partitions'''<br />
<br />
In order to format a desired partition as an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/<partition name><br />
Enter passphrase: <password><br />
Verify passphrase: <password><br />
<br />
<br />
This should be repeated until all partitions except for /boot and possibly swap.<br />
<br />
<br />
Example:<br />
<br />
::*cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2<br />
:::Will create and encrypted root partition using the AES cipher<br />
<br />
<br />
{{Note| If hibernation usage is planned, swap must be encrypted in this fashion. Otherwise if hibernation is not a planned feature for the system, encrypting the swap file will be performed in a alternative manner.}}<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
<br />
'''Unlocking/Mapping LUKS Partitions with the Device Mapper'''<br />
<br />
Once the LUKS partitions have been created it is time to unlock them. <br />
<br />
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that /dev/<partition name> is actually an encrypted device and should be addressed through LUKS using the /dev/mapper/<name> so as not to overwrite the encrypted data. <br />
<br />
<br />
In order to open an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup luksOpen /dev/<partition name> <device-mapper name><br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda2 '''swap'''<br />
::::Once opened the swap partition device address would be '''/dev/mapper/swap''' instead of /dev/sda2<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda3 '''root'''<br />
::::Once opened the root partition device address would be '''/dev/mapper/root''' instead of /dev/sda3<br />
<br />
<br />
{{Note| Since /boot is not encrypted it does not need a device mapped name and will be addressed as /dev/sda1.}}<br />
<br />
<br />
{{Warning| In order to write encrypted data into the partition it must be accessed through the device mapped name.}}<br />
<br />
==== Using LUKS to Format Paritions with a Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
== Encrypting the Swap partition ==<br />
=== Encrypting Swap without Suspend Support ===<br />
Sensitive data stored in memory may be written to swap at any time. If you've gone to the trouble of encrypting your root and home partitions, you should encrypt your swap as well. There are two options here: random encryption on each boot (better security), or the same encryption each time. We won't cover the second option here, as it is pretty much identical to how you set up the /home partition above. Just replace all references to home with swap, and sda5 with sda2.<br />
<br />
Arch Linux provides a convenient way for the first option, which uses dm-crypt directly without LUKS. If you're still in the archsetup process, just switch to a different virtual console (ALT+F2). If you've exited already, the new root will have been unmounted. Use <tt>mount /dev/mapper/root /mnt</tt> to mount it again.<br />
<br />
Now add an entry to the cryptsetup file:<br />
# echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
{{ Tip | Recommended hash algorithms are "whirlpool" (patent free), "sha256", "sha384" or "sha512". Default is "ripemd160" (not recommended).}}<br />
<br />
''[why is it not recommended? only RIPEMD (128bit) was hacked RIPEMD-160 is still safe[https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=83310], isn't it? I heard wirlpool is at least twice as slow. ]''<br />
<br />
{{ Warning | Please take extra care to put the right partition here. The startup script won't ask before overwriting the provided device, destroying '''all''' data on it, ''unless it has a LUKS header'', then it simply won't work.}}<br />
<br />
If you have been following these instructions closely, then in the section "Mapping Partitions" above you put a LUKS header on your swap partition. Erase it with something like the command below, replacing /dev/sda2 with the appropriate swap device:<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
From now on, each time you boot, the partition will be encrypted automatically with a random key, and will then be formated with mkswap.<br />
<br />
Now all you have to do is adjust the corresponding entry in /etc/fstab:<br />
/dev/mapper/swap swap swap defaults 0 0<br />
<br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
=== Encrypted swap with suspend-to-disk support ===<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Installing the system ==<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Encrypting the Swap partition ==<br />
=== Encrypting Swap without Suspend Support ===<br />
Sensitive data stored in memory may be written to swap at any time. If you've gone to the trouble of encrypting your root and home partitions, you should encrypt your swap as well. There are two options here: random encryption on each boot (better security), or the same encryption each time. We won't cover the second option here, as it is pretty much identical to how you set up the /home partition above. Just replace all references to home with swap, and sda5 with sda2.<br />
<br />
Arch Linux provides a convenient way for the first option, which uses dm-crypt directly without LUKS. If you're still in the archsetup process, just switch to a different virtual console (ALT+F2). If you've exited already, the new root will have been unmounted. Use <tt>mount /dev/mapper/root /mnt</tt> to mount it again.<br />
<br />
Now add an entry to the cryptsetup file:<br />
# echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
{{ Tip | Recommended hash algorithms are "whirlpool" (patent free), "sha256", "sha384" or "sha512". Default is "ripemd160" (not recommended).}}<br />
<br />
''[why is it not recommended? only RIPEMD (128bit) was hacked RIPEMD-160 is still safe[https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=83310], isn't it? I heard wirlpool is at least twice as slow. ]''<br />
<br />
{{ Warning | Please take extra care to put the right partition here. The startup script won't ask before overwriting the provided device, destroying '''all''' data on it, ''unless it has a LUKS header'', then it simply won't work.}}<br />
<br />
If you have been following these instructions closely, then in the section "Mapping Partitions" above you put a LUKS header on your swap partition. Erase it with something like the command below, replacing /dev/sda2 with the appropriate swap device:<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
From now on, each time you boot, the partition will be encrypted automatically with a random key, and will then be formated with mkswap.<br />
<br />
Now all you have to do is adjust the corresponding entry in /etc/fstab:<br />
/dev/mapper/swap swap swap defaults 0 0<br />
<br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
=== Encrypted swap with suspend-to-disk support ===<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Storing the key externally (USB stick) ==<br />
=== Preparation for permanent device names ===<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
==== Quick method ====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
=== Generating the keyfile ===<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
=== Storing the keyfile ===<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=118870Dm-crypt2010-10-09T01:42:42Z<p>Vinhsynd: /* Installing the system */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is to simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Initial Setup ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
<code>dd if=/dev/urandom of=/dev/<drive> bs=1M</code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
<code>badblocks -c 10240 -Wsvt random /dev/<drive></code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]] which is suggested reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
<br />
'''How does LVM fit into the overall system?'''<br />
<br />
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKs). It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKs on LVM). However the deployment of LVM on LUKS is considered much more generalizable. One reason for this that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In which case, logical volume management would be layered on top of the hardware encryption - usage of LUKS would be superfluous.<br />
<br />
<br />
==== Creating Disk Partitions ====<br />
<br />
Disk partitions are created using:<br />
<br />
# cfdisk<br />
<br />
This will display a graphical interface for creating disk partitions.<br />
<br />
There are 3 required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*'''/'''<br />
<br />
::An initial boot partition<br />
<br />
:::*'''/boot'''<br />
<br />
::A swap partition<br />
<br />
:::*'''swap'''<br />
<br />
<br />
'''Single Disk Systems'''<br />
<br />
Depending on the system demands, there may be additional partitions desired. These partitions can be individually created at this level by defining separate primary or extended/logical partitions. However if LVM is to be employed, the space unoccupied by /boot and swap should be defined as single large partition which will be divided up later at the logical volume manager level.<br />
<br />
<br />
'''Multiple Disk Systems'''<br />
<br />
In systems that will have multiple harddisk drives, the same options exist as a single disk system. After the creation of the /boot and swap partitions, the remaining free space on physical disks can divided up into their respective partitions at this level, or large partitions can define all free space per physical disk with intent to partition them within the LVM.<br />
<br />
== Configuring LUKS ==<br />
<br />
Creating LUKS partitions with a passphrase is supported by the /arch/setup program. <br />
<br />
This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. <br />
<br />
The steps for accomplishing this through the graphical installer are very similar and can be located in dialogue for manual configuration of the hard drive.<br />
<br />
<br />
<br />
=== Mapping Physical Partitions to LUKS ===<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions and then mount them through the device mapper.<br />
<br />
When creating LUKS partitions they must be associated with a key. <br />
<br />
A key is either a: <br />
<br />
::*Passphrase<br />
::*Keyfile <br />
<br />
It is possible to define up to 8 different keys can be defined per LUKS partition.<br />
<br />
<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
There are many options that cryptsetup with accept, a full list can be reference in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::-c defines the cipher type<br />
::-y prompts for password confirmation on password creation<br />
::-s defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
<br />
In the following examples for creating LUKS partitions we will use AES with XTS, at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup and details about them can be found [[http://en.wikipedia.org/wiki/Block_cipher Wikipedia: BlockCipher]]<br />
<br />
<br />
'''Formating LUKS Partitions'''<br />
<br />
In order to format a desired partition as an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/<partition name><br />
Enter passphrase: <password><br />
Verify passphrase: <password><br />
<br />
<br />
This should be repeated until all partitions except for /boot and possibly swap.<br />
<br />
<br />
Example:<br />
<br />
::*cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2<br />
:::Will create and encrypted root partition using the AES cipher<br />
<br />
<br />
{{Note| If hibernation usage is planned, swap must be encrypted in this fashion. Otherwise if hibernation is not a planned feature for the system, encrypting the swap file will be performed in a alternative manner.}}<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
<br />
'''Unlocking/Mapping LUKS Partitions with the Device Mapper'''<br />
<br />
Once the LUKS partitions have been created it is time to unlock them. <br />
<br />
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that /dev/<partition name> is actually an encrypted device and should be addressed through LUKS using the /dev/mapper/<name> so as not to overwrite the encrypted data. <br />
<br />
<br />
In order to open an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup luksOpen /dev/<partition name> <device-mapper name><br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda2 '''swap'''<br />
::::Once opened the swap partition device address would be '''/dev/mapper/swap''' instead of /dev/sda2<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda3 '''root'''<br />
::::Once opened the root partition device address would be '''/dev/mapper/root''' instead of /dev/sda3<br />
<br />
<br />
{{Note| Since /boot is not encrypted it does not need a device mapped name and will be addressed as /dev/sda1.}}<br />
<br />
<br />
{{Warning| In order to write encrypted data into the partition it must be accessed through the device mapped name.}}<br />
<br />
==== Using LUKS to Format Paritions with a Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
== TEMP ==<br />
== Installing the system ==<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Encrypting the Swap partition ==<br />
=== Encrypting Swap without Suspend Support ===<br />
Sensitive data stored in memory may be written to swap at any time. If you've gone to the trouble of encrypting your root and home partitions, you should encrypt your swap as well. There are two options here: random encryption on each boot (better security), or the same encryption each time. We won't cover the second option here, as it is pretty much identical to how you set up the /home partition above. Just replace all references to home with swap, and sda5 with sda2.<br />
<br />
Arch Linux provides a convenient way for the first option, which uses dm-crypt directly without LUKS. If you're still in the archsetup process, just switch to a different virtual console (ALT+F2). If you've exited already, the new root will have been unmounted. Use <tt>mount /dev/mapper/root /mnt</tt> to mount it again.<br />
<br />
Now add an entry to the cryptsetup file:<br />
# echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
{{ Tip | Recommended hash algorithms are "whirlpool" (patent free), "sha256", "sha384" or "sha512". Default is "ripemd160" (not recommended).}}<br />
<br />
''[why is it not recommended? only RIPEMD (128bit) was hacked RIPEMD-160 is still safe[https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=83310], isn't it? I heard wirlpool is at least twice as slow. ]''<br />
<br />
{{ Warning | Please take extra care to put the right partition here. The startup script won't ask before overwriting the provided device, destroying '''all''' data on it, ''unless it has a LUKS header'', then it simply won't work.}}<br />
<br />
If you have been following these instructions closely, then in the section "Mapping Partitions" above you put a LUKS header on your swap partition. Erase it with something like the command below, replacing /dev/sda2 with the appropriate swap device:<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
From now on, each time you boot, the partition will be encrypted automatically with a random key, and will then be formated with mkswap.<br />
<br />
Now all you have to do is adjust the corresponding entry in /etc/fstab:<br />
/dev/mapper/swap swap swap defaults 0 0<br />
<br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
=== Encrypted swap with suspend-to-disk support ===<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Storing the key externally (USB stick) ==<br />
=== Preparation for permanent device names ===<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
==== Quick method ====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
=== Generating the keyfile ===<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
=== Storing the keyfile ===<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=118869Dm-crypt2010-10-09T01:41:48Z<p>Vinhsynd: /* Encrypted swap with suspend-to-disk support */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is to simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Initial Setup ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
<code>dd if=/dev/urandom of=/dev/<drive> bs=1M</code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
<code>badblocks -c 10240 -Wsvt random /dev/<drive></code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]] which is suggested reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
<br />
'''How does LVM fit into the overall system?'''<br />
<br />
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKs). It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKs on LVM). However the deployment of LVM on LUKS is considered much more generalizable. One reason for this that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In which case, logical volume management would be layered on top of the hardware encryption - usage of LUKS would be superfluous.<br />
<br />
<br />
==== Creating Disk Partitions ====<br />
<br />
Disk partitions are created using:<br />
<br />
# cfdisk<br />
<br />
This will display a graphical interface for creating disk partitions.<br />
<br />
There are 3 required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*'''/'''<br />
<br />
::An initial boot partition<br />
<br />
:::*'''/boot'''<br />
<br />
::A swap partition<br />
<br />
:::*'''swap'''<br />
<br />
<br />
'''Single Disk Systems'''<br />
<br />
Depending on the system demands, there may be additional partitions desired. These partitions can be individually created at this level by defining separate primary or extended/logical partitions. However if LVM is to be employed, the space unoccupied by /boot and swap should be defined as single large partition which will be divided up later at the logical volume manager level.<br />
<br />
<br />
'''Multiple Disk Systems'''<br />
<br />
In systems that will have multiple harddisk drives, the same options exist as a single disk system. After the creation of the /boot and swap partitions, the remaining free space on physical disks can divided up into their respective partitions at this level, or large partitions can define all free space per physical disk with intent to partition them within the LVM.<br />
<br />
== Configuring LUKS ==<br />
<br />
Creating LUKS partitions with a passphrase is supported by the /arch/setup program. <br />
<br />
This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. <br />
<br />
The steps for accomplishing this through the graphical installer are very similar and can be located in dialogue for manual configuration of the hard drive.<br />
<br />
<br />
<br />
=== Mapping Physical Partitions to LUKS ===<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions and then mount them through the device mapper.<br />
<br />
When creating LUKS partitions they must be associated with a key. <br />
<br />
A key is either a: <br />
<br />
::*Passphrase<br />
::*Keyfile <br />
<br />
It is possible to define up to 8 different keys can be defined per LUKS partition.<br />
<br />
<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
There are many options that cryptsetup with accept, a full list can be reference in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::-c defines the cipher type<br />
::-y prompts for password confirmation on password creation<br />
::-s defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
<br />
In the following examples for creating LUKS partitions we will use AES with XTS, at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup and details about them can be found [[http://en.wikipedia.org/wiki/Block_cipher Wikipedia: BlockCipher]]<br />
<br />
<br />
'''Formating LUKS Partitions'''<br />
<br />
In order to format a desired partition as an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/<partition name><br />
Enter passphrase: <password><br />
Verify passphrase: <password><br />
<br />
<br />
This should be repeated until all partitions except for /boot and possibly swap.<br />
<br />
<br />
Example:<br />
<br />
::*cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2<br />
:::Will create and encrypted root partition using the AES cipher<br />
<br />
<br />
{{Note| If hibernation usage is planned, swap must be encrypted in this fashion. Otherwise if hibernation is not a planned feature for the system, encrypting the swap file will be performed in a alternative manner.}}<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
<br />
'''Unlocking/Mapping LUKS Partitions with the Device Mapper'''<br />
<br />
Once the LUKS partitions have been created it is time to unlock them. <br />
<br />
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that /dev/<partition name> is actually an encrypted device and should be addressed through LUKS using the /dev/mapper/<name> so as not to overwrite the encrypted data. <br />
<br />
<br />
In order to open an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup luksOpen /dev/<partition name> <device-mapper name><br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda2 '''swap'''<br />
::::Once opened the swap partition device address would be '''/dev/mapper/swap''' instead of /dev/sda2<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda3 '''root'''<br />
::::Once opened the root partition device address would be '''/dev/mapper/root''' instead of /dev/sda3<br />
<br />
<br />
{{Note| Since /boot is not encrypted it does not need a device mapped name and will be addressed as /dev/sda1.}}<br />
<br />
<br />
{{Warning| In order to write encrypted data into the partition it must be accessed through the device mapped name.}}<br />
<br />
==== Using LUKS to Format Paritions with a Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
== Installing the system ==<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Encrypting the Swap partition ==<br />
=== Encrypting Swap without Suspend Support ===<br />
Sensitive data stored in memory may be written to swap at any time. If you've gone to the trouble of encrypting your root and home partitions, you should encrypt your swap as well. There are two options here: random encryption on each boot (better security), or the same encryption each time. We won't cover the second option here, as it is pretty much identical to how you set up the /home partition above. Just replace all references to home with swap, and sda5 with sda2.<br />
<br />
Arch Linux provides a convenient way for the first option, which uses dm-crypt directly without LUKS. If you're still in the archsetup process, just switch to a different virtual console (ALT+F2). If you've exited already, the new root will have been unmounted. Use <tt>mount /dev/mapper/root /mnt</tt> to mount it again.<br />
<br />
Now add an entry to the cryptsetup file:<br />
# echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
{{ Tip | Recommended hash algorithms are "whirlpool" (patent free), "sha256", "sha384" or "sha512". Default is "ripemd160" (not recommended).}}<br />
<br />
''[why is it not recommended? only RIPEMD (128bit) was hacked RIPEMD-160 is still safe[https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=83310], isn't it? I heard wirlpool is at least twice as slow. ]''<br />
<br />
{{ Warning | Please take extra care to put the right partition here. The startup script won't ask before overwriting the provided device, destroying '''all''' data on it, ''unless it has a LUKS header'', then it simply won't work.}}<br />
<br />
If you have been following these instructions closely, then in the section "Mapping Partitions" above you put a LUKS header on your swap partition. Erase it with something like the command below, replacing /dev/sda2 with the appropriate swap device:<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
From now on, each time you boot, the partition will be encrypted automatically with a random key, and will then be formated with mkswap.<br />
<br />
Now all you have to do is adjust the corresponding entry in /etc/fstab:<br />
/dev/mapper/swap swap swap defaults 0 0<br />
<br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
=== Encrypted swap with suspend-to-disk support ===<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Storing the key externally (USB stick) ==<br />
=== Preparation for permanent device names ===<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
==== Quick method ====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
=== Generating the keyfile ===<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
=== Storing the keyfile ===<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=118868Dm-crypt2010-10-09T01:41:37Z<p>Vinhsynd: /* Encrypting swap partition */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is to simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Initial Setup ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
<code>dd if=/dev/urandom of=/dev/<drive> bs=1M</code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
<code>badblocks -c 10240 -Wsvt random /dev/<drive></code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]] which is suggested reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
<br />
'''How does LVM fit into the overall system?'''<br />
<br />
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKs). It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKs on LVM). However the deployment of LVM on LUKS is considered much more generalizable. One reason for this that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In which case, logical volume management would be layered on top of the hardware encryption - usage of LUKS would be superfluous.<br />
<br />
<br />
==== Creating Disk Partitions ====<br />
<br />
Disk partitions are created using:<br />
<br />
# cfdisk<br />
<br />
This will display a graphical interface for creating disk partitions.<br />
<br />
There are 3 required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*'''/'''<br />
<br />
::An initial boot partition<br />
<br />
:::*'''/boot'''<br />
<br />
::A swap partition<br />
<br />
:::*'''swap'''<br />
<br />
<br />
'''Single Disk Systems'''<br />
<br />
Depending on the system demands, there may be additional partitions desired. These partitions can be individually created at this level by defining separate primary or extended/logical partitions. However if LVM is to be employed, the space unoccupied by /boot and swap should be defined as single large partition which will be divided up later at the logical volume manager level.<br />
<br />
<br />
'''Multiple Disk Systems'''<br />
<br />
In systems that will have multiple harddisk drives, the same options exist as a single disk system. After the creation of the /boot and swap partitions, the remaining free space on physical disks can divided up into their respective partitions at this level, or large partitions can define all free space per physical disk with intent to partition them within the LVM.<br />
<br />
== Configuring LUKS ==<br />
<br />
Creating LUKS partitions with a passphrase is supported by the /arch/setup program. <br />
<br />
This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. <br />
<br />
The steps for accomplishing this through the graphical installer are very similar and can be located in dialogue for manual configuration of the hard drive.<br />
<br />
<br />
<br />
=== Mapping Physical Partitions to LUKS ===<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions and then mount them through the device mapper.<br />
<br />
When creating LUKS partitions they must be associated with a key. <br />
<br />
A key is either a: <br />
<br />
::*Passphrase<br />
::*Keyfile <br />
<br />
It is possible to define up to 8 different keys can be defined per LUKS partition.<br />
<br />
<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
There are many options that cryptsetup with accept, a full list can be reference in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::-c defines the cipher type<br />
::-y prompts for password confirmation on password creation<br />
::-s defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
<br />
In the following examples for creating LUKS partitions we will use AES with XTS, at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup and details about them can be found [[http://en.wikipedia.org/wiki/Block_cipher Wikipedia: BlockCipher]]<br />
<br />
<br />
'''Formating LUKS Partitions'''<br />
<br />
In order to format a desired partition as an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/<partition name><br />
Enter passphrase: <password><br />
Verify passphrase: <password><br />
<br />
<br />
This should be repeated until all partitions except for /boot and possibly swap.<br />
<br />
<br />
Example:<br />
<br />
::*cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2<br />
:::Will create and encrypted root partition using the AES cipher<br />
<br />
<br />
{{Note| If hibernation usage is planned, swap must be encrypted in this fashion. Otherwise if hibernation is not a planned feature for the system, encrypting the swap file will be performed in a alternative manner.}}<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
<br />
'''Unlocking/Mapping LUKS Partitions with the Device Mapper'''<br />
<br />
Once the LUKS partitions have been created it is time to unlock them. <br />
<br />
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that /dev/<partition name> is actually an encrypted device and should be addressed through LUKS using the /dev/mapper/<name> so as not to overwrite the encrypted data. <br />
<br />
<br />
In order to open an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup luksOpen /dev/<partition name> <device-mapper name><br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda2 '''swap'''<br />
::::Once opened the swap partition device address would be '''/dev/mapper/swap''' instead of /dev/sda2<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda3 '''root'''<br />
::::Once opened the root partition device address would be '''/dev/mapper/root''' instead of /dev/sda3<br />
<br />
<br />
{{Note| Since /boot is not encrypted it does not need a device mapped name and will be addressed as /dev/sda1.}}<br />
<br />
<br />
{{Warning| In order to write encrypted data into the partition it must be accessed through the device mapped name.}}<br />
<br />
==== Using LUKS to Format Paritions with a Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
== Installing the system ==<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Encrypting the Swap partition ==<br />
=== Encrypting Swap without Suspend Support ===<br />
Sensitive data stored in memory may be written to swap at any time. If you've gone to the trouble of encrypting your root and home partitions, you should encrypt your swap as well. There are two options here: random encryption on each boot (better security), or the same encryption each time. We won't cover the second option here, as it is pretty much identical to how you set up the /home partition above. Just replace all references to home with swap, and sda5 with sda2.<br />
<br />
Arch Linux provides a convenient way for the first option, which uses dm-crypt directly without LUKS. If you're still in the archsetup process, just switch to a different virtual console (ALT+F2). If you've exited already, the new root will have been unmounted. Use <tt>mount /dev/mapper/root /mnt</tt> to mount it again.<br />
<br />
Now add an entry to the cryptsetup file:<br />
# echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
{{ Tip | Recommended hash algorithms are "whirlpool" (patent free), "sha256", "sha384" or "sha512". Default is "ripemd160" (not recommended).}}<br />
<br />
''[why is it not recommended? only RIPEMD (128bit) was hacked RIPEMD-160 is still safe[https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=83310], isn't it? I heard wirlpool is at least twice as slow. ]''<br />
<br />
{{ Warning | Please take extra care to put the right partition here. The startup script won't ask before overwriting the provided device, destroying '''all''' data on it, ''unless it has a LUKS header'', then it simply won't work.}}<br />
<br />
If you have been following these instructions closely, then in the section "Mapping Partitions" above you put a LUKS header on your swap partition. Erase it with something like the command below, replacing /dev/sda2 with the appropriate swap device:<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
From now on, each time you boot, the partition will be encrypted automatically with a random key, and will then be formated with mkswap.<br />
<br />
Now all you have to do is adjust the corresponding entry in /etc/fstab:<br />
/dev/mapper/swap swap swap defaults 0 0<br />
<br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Encrypted swap with suspend-to-disk support ==<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Storing the key externally (USB stick) ==<br />
=== Preparation for permanent device names ===<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
==== Quick method ====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
=== Generating the keyfile ===<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
=== Storing the keyfile ===<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=118867Dm-crypt2010-10-09T01:40:40Z<p>Vinhsynd: /* Installing the system */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is to simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Initial Setup ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
<code>dd if=/dev/urandom of=/dev/<drive> bs=1M</code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
<code>badblocks -c 10240 -Wsvt random /dev/<drive></code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]] which is suggested reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
<br />
'''How does LVM fit into the overall system?'''<br />
<br />
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKs). It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKs on LVM). However the deployment of LVM on LUKS is considered much more generalizable. One reason for this that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In which case, logical volume management would be layered on top of the hardware encryption - usage of LUKS would be superfluous.<br />
<br />
<br />
==== Creating Disk Partitions ====<br />
<br />
Disk partitions are created using:<br />
<br />
# cfdisk<br />
<br />
This will display a graphical interface for creating disk partitions.<br />
<br />
There are 3 required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*'''/'''<br />
<br />
::An initial boot partition<br />
<br />
:::*'''/boot'''<br />
<br />
::A swap partition<br />
<br />
:::*'''swap'''<br />
<br />
<br />
'''Single Disk Systems'''<br />
<br />
Depending on the system demands, there may be additional partitions desired. These partitions can be individually created at this level by defining separate primary or extended/logical partitions. However if LVM is to be employed, the space unoccupied by /boot and swap should be defined as single large partition which will be divided up later at the logical volume manager level.<br />
<br />
<br />
'''Multiple Disk Systems'''<br />
<br />
In systems that will have multiple harddisk drives, the same options exist as a single disk system. After the creation of the /boot and swap partitions, the remaining free space on physical disks can divided up into their respective partitions at this level, or large partitions can define all free space per physical disk with intent to partition them within the LVM.<br />
<br />
== Configuring LUKS ==<br />
<br />
Creating LUKS partitions with a passphrase is supported by the /arch/setup program. <br />
<br />
This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. <br />
<br />
The steps for accomplishing this through the graphical installer are very similar and can be located in dialogue for manual configuration of the hard drive.<br />
<br />
<br />
<br />
=== Mapping Physical Partitions to LUKS ===<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions and then mount them through the device mapper.<br />
<br />
When creating LUKS partitions they must be associated with a key. <br />
<br />
A key is either a: <br />
<br />
::*Passphrase<br />
::*Keyfile <br />
<br />
It is possible to define up to 8 different keys can be defined per LUKS partition.<br />
<br />
<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
There are many options that cryptsetup with accept, a full list can be reference in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::-c defines the cipher type<br />
::-y prompts for password confirmation on password creation<br />
::-s defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
<br />
In the following examples for creating LUKS partitions we will use AES with XTS, at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup and details about them can be found [[http://en.wikipedia.org/wiki/Block_cipher Wikipedia: BlockCipher]]<br />
<br />
<br />
'''Formating LUKS Partitions'''<br />
<br />
In order to format a desired partition as an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/<partition name><br />
Enter passphrase: <password><br />
Verify passphrase: <password><br />
<br />
<br />
This should be repeated until all partitions except for /boot and possibly swap.<br />
<br />
<br />
Example:<br />
<br />
::*cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2<br />
:::Will create and encrypted root partition using the AES cipher<br />
<br />
<br />
{{Note| If hibernation usage is planned, swap must be encrypted in this fashion. Otherwise if hibernation is not a planned feature for the system, encrypting the swap file will be performed in a alternative manner.}}<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
<br />
'''Unlocking/Mapping LUKS Partitions with the Device Mapper'''<br />
<br />
Once the LUKS partitions have been created it is time to unlock them. <br />
<br />
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that /dev/<partition name> is actually an encrypted device and should be addressed through LUKS using the /dev/mapper/<name> so as not to overwrite the encrypted data. <br />
<br />
<br />
In order to open an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup luksOpen /dev/<partition name> <device-mapper name><br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda2 '''swap'''<br />
::::Once opened the swap partition device address would be '''/dev/mapper/swap''' instead of /dev/sda2<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda3 '''root'''<br />
::::Once opened the root partition device address would be '''/dev/mapper/root''' instead of /dev/sda3<br />
<br />
<br />
{{Note| Since /boot is not encrypted it does not need a device mapped name and will be addressed as /dev/sda1.}}<br />
<br />
<br />
{{Warning| In order to write encrypted data into the partition it must be accessed through the device mapped name.}}<br />
<br />
==== Using LUKS to Format Paritions with a Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
== Installing the system ==<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Encrypting swap partition ==<br />
Sensitive data stored in memory may be written to swap at any time. If you've gone to the trouble of encrypting your root and home partitions, you should encrypt your swap as well. There are two options here: random encryption on each boot (better security), or the same encryption each time. We won't cover the second option here, as it is pretty much identical to how you set up the /home partition above. Just replace all references to home with swap, and sda5 with sda2.<br />
<br />
Arch Linux provides a convenient way for the first option, which uses dm-crypt directly without LUKS. If you're still in the archsetup process, just switch to a different virtual console (ALT+F2). If you've exited already, the new root will have been unmounted. Use <tt>mount /dev/mapper/root /mnt</tt> to mount it again.<br />
<br />
Now add an entry to the cryptsetup file:<br />
# echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
{{ Tip | Recommended hash algorithms are "whirlpool" (patent free), "sha256", "sha384" or "sha512". Default is "ripemd160" (not recommended).}}<br />
<br />
''[why is it not recommended? only RIPEMD (128bit) was hacked RIPEMD-160 is still safe[https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=83310], isn't it? I heard wirlpool is at least twice as slow. ]''<br />
<br />
{{ Warning | Please take extra care to put the right partition here. The startup script won't ask before overwriting the provided device, destroying '''all''' data on it, ''unless it has a LUKS header'', then it simply won't work.}}<br />
<br />
If you have been following these instructions closely, then in the section "Mapping Partitions" above you put a LUKS header on your swap partition. Erase it with something like the command below, replacing /dev/sda2 with the appropriate swap device:<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
From now on, each time you boot, the partition will be encrypted automatically with a random key, and will then be formated with mkswap.<br />
<br />
Now all you have to do is adjust the corresponding entry in /etc/fstab:<br />
/dev/mapper/swap swap swap defaults 0 0<br />
<br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Encrypted swap with suspend-to-disk support ==<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Storing the key externally (USB stick) ==<br />
=== Preparation for permanent device names ===<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
==== Quick method ====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
=== Generating the keyfile ===<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
=== Storing the keyfile ===<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=118866Dm-crypt2010-10-09T01:38:48Z<p>Vinhsynd: /* Installation */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is to simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Initial Setup ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
<code>dd if=/dev/urandom of=/dev/<drive> bs=1M</code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
<code>badblocks -c 10240 -Wsvt random /dev/<drive></code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]] which is suggested reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
<br />
'''How does LVM fit into the overall system?'''<br />
<br />
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKs). It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKs on LVM). However the deployment of LVM on LUKS is considered much more generalizable. One reason for this that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In which case, logical volume management would be layered on top of the hardware encryption - usage of LUKS would be superfluous.<br />
<br />
<br />
==== Creating Disk Partitions ====<br />
<br />
Disk partitions are created using:<br />
<br />
# cfdisk<br />
<br />
This will display a graphical interface for creating disk partitions.<br />
<br />
There are 3 required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*'''/'''<br />
<br />
::An initial boot partition<br />
<br />
:::*'''/boot'''<br />
<br />
::A swap partition<br />
<br />
:::*'''swap'''<br />
<br />
<br />
'''Single Disk Systems'''<br />
<br />
Depending on the system demands, there may be additional partitions desired. These partitions can be individually created at this level by defining separate primary or extended/logical partitions. However if LVM is to be employed, the space unoccupied by /boot and swap should be defined as single large partition which will be divided up later at the logical volume manager level.<br />
<br />
<br />
'''Multiple Disk Systems'''<br />
<br />
In systems that will have multiple harddisk drives, the same options exist as a single disk system. After the creation of the /boot and swap partitions, the remaining free space on physical disks can divided up into their respective partitions at this level, or large partitions can define all free space per physical disk with intent to partition them within the LVM.<br />
<br />
== Configuring LUKS ==<br />
<br />
Creating LUKS partitions with a passphrase is supported by the /arch/setup program. <br />
<br />
This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. <br />
<br />
The steps for accomplishing this through the graphical installer are very similar and can be located in dialogue for manual configuration of the hard drive.<br />
<br />
<br />
<br />
=== Mapping Physical Partitions to LUKS ===<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions and then mount them through the device mapper.<br />
<br />
When creating LUKS partitions they must be associated with a key. <br />
<br />
A key is either a: <br />
<br />
::*Passphrase<br />
::*Keyfile <br />
<br />
It is possible to define up to 8 different keys can be defined per LUKS partition.<br />
<br />
<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
There are many options that cryptsetup with accept, a full list can be reference in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::-c defines the cipher type<br />
::-y prompts for password confirmation on password creation<br />
::-s defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
<br />
In the following examples for creating LUKS partitions we will use AES with XTS, at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup and details about them can be found [[http://en.wikipedia.org/wiki/Block_cipher Wikipedia: BlockCipher]]<br />
<br />
<br />
'''Formating LUKS Partitions'''<br />
<br />
In order to format a desired partition as an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/<partition name><br />
Enter passphrase: <password><br />
Verify passphrase: <password><br />
<br />
<br />
This should be repeated until all partitions except for /boot and possibly swap.<br />
<br />
<br />
Example:<br />
<br />
::*cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2<br />
:::Will create and encrypted root partition using the AES cipher<br />
<br />
<br />
{{Note| If hibernation usage is planned, swap must be encrypted in this fashion. Otherwise if hibernation is not a planned feature for the system, encrypting the swap file will be performed in a alternative manner.}}<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
<br />
'''Unlocking/Mapping LUKS Partitions with the Device Mapper'''<br />
<br />
Once the LUKS partitions have been created it is time to unlock them. <br />
<br />
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that /dev/<partition name> is actually an encrypted device and should be addressed through LUKS using the /dev/mapper/<name> so as not to overwrite the encrypted data. <br />
<br />
<br />
In order to open an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup luksOpen /dev/<partition name> <device-mapper name><br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda2 '''swap'''<br />
::::Once opened the swap partition device address would be '''/dev/mapper/swap''' instead of /dev/sda2<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda3 '''root'''<br />
::::Once opened the root partition device address would be '''/dev/mapper/root''' instead of /dev/sda3<br />
<br />
<br />
{{Note| Since /boot is not encrypted it does not need a device mapped name and will be addressed as /dev/sda1.}}<br />
<br />
<br />
{{Warning| In order to write encrypted data into the partition it must be accessed through the device mapped name.}}<br />
<br />
==== Using LUKS to Format Paritions with a Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
=== Installing the system ===<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Encrypting swap partition ==<br />
Sensitive data stored in memory may be written to swap at any time. If you've gone to the trouble of encrypting your root and home partitions, you should encrypt your swap as well. There are two options here: random encryption on each boot (better security), or the same encryption each time. We won't cover the second option here, as it is pretty much identical to how you set up the /home partition above. Just replace all references to home with swap, and sda5 with sda2.<br />
<br />
Arch Linux provides a convenient way for the first option, which uses dm-crypt directly without LUKS. If you're still in the archsetup process, just switch to a different virtual console (ALT+F2). If you've exited already, the new root will have been unmounted. Use <tt>mount /dev/mapper/root /mnt</tt> to mount it again.<br />
<br />
Now add an entry to the cryptsetup file:<br />
# echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
{{ Tip | Recommended hash algorithms are "whirlpool" (patent free), "sha256", "sha384" or "sha512". Default is "ripemd160" (not recommended).}}<br />
<br />
''[why is it not recommended? only RIPEMD (128bit) was hacked RIPEMD-160 is still safe[https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=83310], isn't it? I heard wirlpool is at least twice as slow. ]''<br />
<br />
{{ Warning | Please take extra care to put the right partition here. The startup script won't ask before overwriting the provided device, destroying '''all''' data on it, ''unless it has a LUKS header'', then it simply won't work.}}<br />
<br />
If you have been following these instructions closely, then in the section "Mapping Partitions" above you put a LUKS header on your swap partition. Erase it with something like the command below, replacing /dev/sda2 with the appropriate swap device:<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
From now on, each time you boot, the partition will be encrypted automatically with a random key, and will then be formated with mkswap.<br />
<br />
Now all you have to do is adjust the corresponding entry in /etc/fstab:<br />
/dev/mapper/swap swap swap defaults 0 0<br />
<br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Encrypted swap with suspend-to-disk support ==<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Storing the key externally (USB stick) ==<br />
=== Preparation for permanent device names ===<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
==== Quick method ====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
=== Generating the keyfile ===<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
=== Storing the keyfile ===<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=118865Dm-crypt2010-10-09T01:33:26Z<p>Vinhsynd: /* Using LUKS to Format Partitions with a Passphrase */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is to simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Installation ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
<code>dd if=/dev/urandom of=/dev/<drive> bs=1M</code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
<code>badblocks -c 10240 -Wsvt random /dev/<drive></code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]] which is suggested reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
<br />
'''How does LVM fit into the overall system?'''<br />
<br />
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKs). It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKs on LVM). However the deployment of LVM on LUKS is considered much more generalizable. One reason for this that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In which case, logical volume management would be layered on top of the hardware encryption - usage of LUKS would be superfluous.<br />
<br />
<br />
==== Creating Disk Partitions ====<br />
<br />
Disk partitions are created using:<br />
<br />
# cfdisk<br />
<br />
This will display a graphical interface for creating disk partitions.<br />
<br />
There are 3 required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*'''/'''<br />
<br />
::An initial boot partition<br />
<br />
:::*'''/boot'''<br />
<br />
::A swap partition<br />
<br />
:::*'''swap'''<br />
<br />
<br />
'''Single Disk Systems'''<br />
<br />
Depending on the system demands, there may be additional partitions desired. These partitions can be individually created at this level by defining separate primary or extended/logical partitions. However if LVM is to be employed, the space unoccupied by /boot and swap should be defined as single large partition which will be divided up later at the logical volume manager level.<br />
<br />
<br />
'''Multiple Disk Systems'''<br />
<br />
In systems that will have multiple harddisk drives, the same options exist as a single disk system. After the creation of the /boot and swap partitions, the remaining free space on physical disks can divided up into their respective partitions at this level, or large partitions can define all free space per physical disk with intent to partition them within the LVM.<br />
<br />
== Configuring LUKS ==<br />
<br />
Creating LUKS partitions with a passphrase is supported by the /arch/setup program. <br />
<br />
This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. <br />
<br />
The steps for accomplishing this through the graphical installer are very similar and can be located in dialogue for manual configuration of the hard drive.<br />
<br />
<br />
<br />
=== Mapping Physical Partitions to LUKS ===<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions and then mount them through the device mapper.<br />
<br />
When creating LUKS partitions they must be associated with a key. <br />
<br />
A key is either a: <br />
<br />
::*Passphrase<br />
::*Keyfile <br />
<br />
It is possible to define up to 8 different keys can be defined per LUKS partition.<br />
<br />
<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
There are many options that cryptsetup with accept, a full list can be reference in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::-c defines the cipher type<br />
::-y prompts for password confirmation on password creation<br />
::-s defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
<br />
In the following examples for creating LUKS partitions we will use AES with XTS, at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup and details about them can be found [[http://en.wikipedia.org/wiki/Block_cipher Wikipedia: BlockCipher]]<br />
<br />
<br />
'''Formating LUKS Partitions'''<br />
<br />
In order to format a desired partition as an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/<partition name><br />
Enter passphrase: <password><br />
Verify passphrase: <password><br />
<br />
<br />
This should be repeated until all partitions except for /boot and possibly swap.<br />
<br />
<br />
Example:<br />
<br />
::*cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2<br />
:::Will create and encrypted root partition using the AES cipher<br />
<br />
<br />
{{Note| If hibernation usage is planned, swap must be encrypted in this fashion. Otherwise if hibernation is not a planned feature for the system, encrypting the swap file will be performed in a alternative manner.}}<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
<br />
'''Unlocking/Mapping LUKS Partitions with the Device Mapper'''<br />
<br />
Once the LUKS partitions have been created it is time to unlock them. <br />
<br />
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that /dev/<partition name> is actually an encrypted device and should be addressed through LUKS using the /dev/mapper/<name> so as not to overwrite the encrypted data. <br />
<br />
<br />
In order to open an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup luksOpen /dev/<partition name> <device-mapper name><br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda2 '''swap'''<br />
::::Once opened the swap partition device address would be '''/dev/mapper/swap''' instead of /dev/sda2<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda3 '''root'''<br />
::::Once opened the root partition device address would be '''/dev/mapper/root''' instead of /dev/sda3<br />
<br />
<br />
{{Note| Since /boot is not encrypted it does not need a device mapped name and will be addressed as /dev/sda1.}}<br />
<br />
<br />
{{Warning| In order to write encrypted data into the partition it must be accessed through the device mapped name.}}<br />
<br />
==== Using LUKS to Format Paritions with a Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
=== Installing the system ===<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Encrypting swap partition ==<br />
Sensitive data stored in memory may be written to swap at any time. If you've gone to the trouble of encrypting your root and home partitions, you should encrypt your swap as well. There are two options here: random encryption on each boot (better security), or the same encryption each time. We won't cover the second option here, as it is pretty much identical to how you set up the /home partition above. Just replace all references to home with swap, and sda5 with sda2.<br />
<br />
Arch Linux provides a convenient way for the first option, which uses dm-crypt directly without LUKS. If you're still in the archsetup process, just switch to a different virtual console (ALT+F2). If you've exited already, the new root will have been unmounted. Use <tt>mount /dev/mapper/root /mnt</tt> to mount it again.<br />
<br />
Now add an entry to the cryptsetup file:<br />
# echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
{{ Tip | Recommended hash algorithms are "whirlpool" (patent free), "sha256", "sha384" or "sha512". Default is "ripemd160" (not recommended).}}<br />
<br />
''[why is it not recommended? only RIPEMD (128bit) was hacked RIPEMD-160 is still safe[https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=83310], isn't it? I heard wirlpool is at least twice as slow. ]''<br />
<br />
{{ Warning | Please take extra care to put the right partition here. The startup script won't ask before overwriting the provided device, destroying '''all''' data on it, ''unless it has a LUKS header'', then it simply won't work.}}<br />
<br />
If you have been following these instructions closely, then in the section "Mapping Partitions" above you put a LUKS header on your swap partition. Erase it with something like the command below, replacing /dev/sda2 with the appropriate swap device:<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
From now on, each time you boot, the partition will be encrypted automatically with a random key, and will then be formated with mkswap.<br />
<br />
Now all you have to do is adjust the corresponding entry in /etc/fstab:<br />
/dev/mapper/swap swap swap defaults 0 0<br />
<br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Encrypted swap with suspend-to-disk support ==<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Storing the key externally (USB stick) ==<br />
=== Preparation for permanent device names ===<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
==== Quick method ====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
=== Generating the keyfile ===<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
=== Storing the keyfile ===<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=118863Dm-crypt2010-10-09T01:32:31Z<p>Vinhsynd: /* Using LUKS to Format Partitions with a Passphrase */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is to simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Installation ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
<code>dd if=/dev/urandom of=/dev/<drive> bs=1M</code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
<code>badblocks -c 10240 -Wsvt random /dev/<drive></code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]] which is suggested reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
<br />
'''How does LVM fit into the overall system?'''<br />
<br />
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKs). It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKs on LVM). However the deployment of LVM on LUKS is considered much more generalizable. One reason for this that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In which case, logical volume management would be layered on top of the hardware encryption - usage of LUKS would be superfluous.<br />
<br />
<br />
==== Creating Disk Partitions ====<br />
<br />
Disk partitions are created using:<br />
<br />
# cfdisk<br />
<br />
This will display a graphical interface for creating disk partitions.<br />
<br />
There are 3 required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*'''/'''<br />
<br />
::An initial boot partition<br />
<br />
:::*'''/boot'''<br />
<br />
::A swap partition<br />
<br />
:::*'''swap'''<br />
<br />
<br />
'''Single Disk Systems'''<br />
<br />
Depending on the system demands, there may be additional partitions desired. These partitions can be individually created at this level by defining separate primary or extended/logical partitions. However if LVM is to be employed, the space unoccupied by /boot and swap should be defined as single large partition which will be divided up later at the logical volume manager level.<br />
<br />
<br />
'''Multiple Disk Systems'''<br />
<br />
In systems that will have multiple harddisk drives, the same options exist as a single disk system. After the creation of the /boot and swap partitions, the remaining free space on physical disks can divided up into their respective partitions at this level, or large partitions can define all free space per physical disk with intent to partition them within the LVM.<br />
<br />
== Configuring LUKS ==<br />
<br />
Creating LUKS partitions with a passphrase is supported by the /arch/setup program. <br />
<br />
This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. <br />
<br />
The steps for accomplishing this through the graphical installer are very similar and can be located in dialogue for manual configuration of the hard drive.<br />
<br />
<br />
<br />
=== Mapping Physical Partitions to LUKS ===<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions and then mount them through the device mapper.<br />
<br />
When creating LUKS partitions they must be associated with a key. <br />
<br />
A key is either a: <br />
<br />
::*Passphrase<br />
::*Keyfile <br />
<br />
It is possible to define up to 8 different keys can be defined per LUKS partition.<br />
<br />
<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
There are many options that cryptsetup with accept, a full list can be reference in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::-c defines the cipher type<br />
::-y prompts for password confirmation on password creation<br />
::-s defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
<br />
In the following examples for creating LUKS partitions we will use AES with XTS, at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup and details about them can be found [[http://en.wikipedia.org/wiki/Block_cipher Wikipedia: BlockCipher]]<br />
<br />
<br />
'''Formating LUKS Partitions'''<br />
<br />
In order to format a desired partition as an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/<partition name><br />
Enter passphrase: <password><br />
Verify passphrase: <password><br />
<br />
<br />
This should be repeated until all partitions except for /boot and possibly swap.<br />
<br />
<br />
Example:<br />
<br />
::*For encrypting the root partition /dev/sda2:<br />
:::cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2 will create and encrypted root partition<br />
<br />
<br />
{{Note| If hibernation usage is planned, swap must be encrypted in this fashion. Otherwise if hibernation is not a planned feature for the system, encrypting the swap file will be performed in a alternative manner.}}<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
<br />
'''Unlocking/Mapping LUKS Partitions with the Device Mapper'''<br />
<br />
Once the LUKS partitions have been created it is time to unlock them. <br />
<br />
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that /dev/<partition name> is actually an encrypted device and should be addressed through LUKS using the /dev/mapper/<name> so as not to overwrite the encrypted data. <br />
<br />
<br />
In order to open an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup luksOpen /dev/<partition name> <device-mapper name><br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda2 '''swap'''<br />
::::Once opened the swap partition device address would be '''/dev/mapper/swap''' instead of /dev/sda2<br />
<br />
<br />
::*cryptsetup luksOpen /dev/sda3 '''root'''<br />
::::Once opened the root partition device address would be '''/dev/mapper/root''' instead of /dev/sda3<br />
<br />
<br />
{{Note| Since /boot is not encrypted it does not need a device mapped name and will be addressed as /dev/sda1.}}<br />
<br />
<br />
{{Warning| In order to write encrypted data into the partition it must be accessed through the device mapped name.}}<br />
<br />
==== Using LUKS to Format Paritions with a Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
=== Installing the system ===<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Encrypting swap partition ==<br />
Sensitive data stored in memory may be written to swap at any time. If you've gone to the trouble of encrypting your root and home partitions, you should encrypt your swap as well. There are two options here: random encryption on each boot (better security), or the same encryption each time. We won't cover the second option here, as it is pretty much identical to how you set up the /home partition above. Just replace all references to home with swap, and sda5 with sda2.<br />
<br />
Arch Linux provides a convenient way for the first option, which uses dm-crypt directly without LUKS. If you're still in the archsetup process, just switch to a different virtual console (ALT+F2). If you've exited already, the new root will have been unmounted. Use <tt>mount /dev/mapper/root /mnt</tt> to mount it again.<br />
<br />
Now add an entry to the cryptsetup file:<br />
# echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
{{ Tip | Recommended hash algorithms are "whirlpool" (patent free), "sha256", "sha384" or "sha512". Default is "ripemd160" (not recommended).}}<br />
<br />
''[why is it not recommended? only RIPEMD (128bit) was hacked RIPEMD-160 is still safe[https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=83310], isn't it? I heard wirlpool is at least twice as slow. ]''<br />
<br />
{{ Warning | Please take extra care to put the right partition here. The startup script won't ask before overwriting the provided device, destroying '''all''' data on it, ''unless it has a LUKS header'', then it simply won't work.}}<br />
<br />
If you have been following these instructions closely, then in the section "Mapping Partitions" above you put a LUKS header on your swap partition. Erase it with something like the command below, replacing /dev/sda2 with the appropriate swap device:<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
From now on, each time you boot, the partition will be encrypted automatically with a random key, and will then be formated with mkswap.<br />
<br />
Now all you have to do is adjust the corresponding entry in /etc/fstab:<br />
/dev/mapper/swap swap swap defaults 0 0<br />
<br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Encrypted swap with suspend-to-disk support ==<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Storing the key externally (USB stick) ==<br />
=== Preparation for permanent device names ===<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
==== Quick method ====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
=== Generating the keyfile ===<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
=== Storing the keyfile ===<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=118860Dm-crypt2010-10-09T01:29:34Z<p>Vinhsynd: /* Using LUKS to Format Partitions with a Passphrase */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is to simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Installation ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
<code>dd if=/dev/urandom of=/dev/<drive> bs=1M</code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
<code>badblocks -c 10240 -Wsvt random /dev/<drive></code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]] which is suggested reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
<br />
'''How does LVM fit into the overall system?'''<br />
<br />
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKs). It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKs on LVM). However the deployment of LVM on LUKS is considered much more generalizable. One reason for this that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In which case, logical volume management would be layered on top of the hardware encryption - usage of LUKS would be superfluous.<br />
<br />
<br />
==== Creating Disk Partitions ====<br />
<br />
Disk partitions are created using:<br />
<br />
# cfdisk<br />
<br />
This will display a graphical interface for creating disk partitions.<br />
<br />
There are 3 required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*'''/'''<br />
<br />
::An initial boot partition<br />
<br />
:::*'''/boot'''<br />
<br />
::A swap partition<br />
<br />
:::*'''swap'''<br />
<br />
<br />
'''Single Disk Systems'''<br />
<br />
Depending on the system demands, there may be additional partitions desired. These partitions can be individually created at this level by defining separate primary or extended/logical partitions. However if LVM is to be employed, the space unoccupied by /boot and swap should be defined as single large partition which will be divided up later at the logical volume manager level.<br />
<br />
<br />
'''Multiple Disk Systems'''<br />
<br />
In systems that will have multiple harddisk drives, the same options exist as a single disk system. After the creation of the /boot and swap partitions, the remaining free space on physical disks can divided up into their respective partitions at this level, or large partitions can define all free space per physical disk with intent to partition them within the LVM.<br />
<br />
== Configuring LUKS ==<br />
<br />
Creating LUKS partitions with a passphrase is supported by the /arch/setup program. <br />
<br />
This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. <br />
<br />
The steps for accomplishing this through the graphical installer are very similar and can be located in dialogue for manual configuration of the hard drive.<br />
<br />
<br />
<br />
=== Mapping Physical Partitions to LUKS ===<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions and then mount them through the device mapper.<br />
<br />
When creating LUKS partitions they must be associated with a key. <br />
<br />
A key is either a: <br />
<br />
::*Passphrase<br />
::*Keyfile <br />
<br />
It is possible to define up to 8 different keys can be defined per LUKS partition.<br />
<br />
<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
There are many options that cryptsetup with accept, a full list can be reference in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::-c defines the cipher type<br />
::-y prompts for password confirmation on password creation<br />
::-s defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
<br />
In the following examples for creating LUKS partitions we will use AES with XTS, at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup and details about them can be found [[http://en.wikipedia.org/wiki/Block_cipher Wikipedia: BlockCipher]]<br />
<br />
<br />
'''Formating LUKS Partitions'''<br />
<br />
In order to format a desired partition as an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/<partition name><br />
Enter passphrase: <password><br />
Verify passphrase: <password><br />
<br />
<br />
This should be repeated until all partitions except for /boot and possibly swap.<br />
<br />
<br />
Example:<br />
<br />
::*For encrypting the root partition /dev/sda2:<br />
:::cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2 will create and encrypted root partition<br />
<br />
<br />
{{Note| If hibernation usage is planned, swap must be encrypted in this fashion. Otherwise if hibernation is not a planned feature for the system, encrypting the swap file will be performed in a alternative manner.}}<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
<br />
'''Unlocking/Mapping LUKS Partitions with the Device Mapper'''<br />
<br />
Once the LUKS partitions have been created it is time to unlock them. <br />
<br />
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that /dev/<partition name> is actually an encrypted device and should be addressed through LUKS using the /dev/mapper/<name> so as not to overwrite the encrypted data. <br />
<br />
<br />
In order to open an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup luksOpen /dev/<partition name> <device-mapper name><br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
<br />
::*/dev/sda2 which is the swap partition name can be mapped to ''''swap''''<br />
::::Once opened the device address would be '''/dev/mapper/swap''' instead of /dev/sda2<br />
<br />
<br />
::*/dev/sda3 which is the root parition name can be mapped to ''''root''''<br />
::::Once opened the device address would be '''/dev/mapper/root''' instead of /dev/sda3<br />
<br />
<br />
{{Note| Since /boot is not encrypted it does not need a device mapped name and will be addressed as /dev/sda1.}}<br />
<br />
<br />
{{Warning| In order to write encrypted data into the partition it must be accessed through the device mapped name.}}<br />
<br />
==== Using LUKS to Format Paritions with a Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
=== Installing the system ===<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Encrypting swap partition ==<br />
Sensitive data stored in memory may be written to swap at any time. If you've gone to the trouble of encrypting your root and home partitions, you should encrypt your swap as well. There are two options here: random encryption on each boot (better security), or the same encryption each time. We won't cover the second option here, as it is pretty much identical to how you set up the /home partition above. Just replace all references to home with swap, and sda5 with sda2.<br />
<br />
Arch Linux provides a convenient way for the first option, which uses dm-crypt directly without LUKS. If you're still in the archsetup process, just switch to a different virtual console (ALT+F2). If you've exited already, the new root will have been unmounted. Use <tt>mount /dev/mapper/root /mnt</tt> to mount it again.<br />
<br />
Now add an entry to the cryptsetup file:<br />
# echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
{{ Tip | Recommended hash algorithms are "whirlpool" (patent free), "sha256", "sha384" or "sha512". Default is "ripemd160" (not recommended).}}<br />
<br />
''[why is it not recommended? only RIPEMD (128bit) was hacked RIPEMD-160 is still safe[https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=83310], isn't it? I heard wirlpool is at least twice as slow. ]''<br />
<br />
{{ Warning | Please take extra care to put the right partition here. The startup script won't ask before overwriting the provided device, destroying '''all''' data on it, ''unless it has a LUKS header'', then it simply won't work.}}<br />
<br />
If you have been following these instructions closely, then in the section "Mapping Partitions" above you put a LUKS header on your swap partition. Erase it with something like the command below, replacing /dev/sda2 with the appropriate swap device:<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
From now on, each time you boot, the partition will be encrypted automatically with a random key, and will then be formated with mkswap.<br />
<br />
Now all you have to do is adjust the corresponding entry in /etc/fstab:<br />
/dev/mapper/swap swap swap defaults 0 0<br />
<br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Encrypted swap with suspend-to-disk support ==<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Storing the key externally (USB stick) ==<br />
=== Preparation for permanent device names ===<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
==== Quick method ====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
=== Generating the keyfile ===<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
=== Storing the keyfile ===<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=118859Dm-crypt2010-10-09T01:28:57Z<p>Vinhsynd: /* Configuring LUKS */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is to simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Installation ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
<code>dd if=/dev/urandom of=/dev/<drive> bs=1M</code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
<code>badblocks -c 10240 -Wsvt random /dev/<drive></code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]] which is suggested reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
<br />
'''How does LVM fit into the overall system?'''<br />
<br />
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKs). It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKs on LVM). However the deployment of LVM on LUKS is considered much more generalizable. One reason for this that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In which case, logical volume management would be layered on top of the hardware encryption - usage of LUKS would be superfluous.<br />
<br />
<br />
==== Creating Disk Partitions ====<br />
<br />
Disk partitions are created using:<br />
<br />
# cfdisk<br />
<br />
This will display a graphical interface for creating disk partitions.<br />
<br />
There are 3 required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*'''/'''<br />
<br />
::An initial boot partition<br />
<br />
:::*'''/boot'''<br />
<br />
::A swap partition<br />
<br />
:::*'''swap'''<br />
<br />
<br />
'''Single Disk Systems'''<br />
<br />
Depending on the system demands, there may be additional partitions desired. These partitions can be individually created at this level by defining separate primary or extended/logical partitions. However if LVM is to be employed, the space unoccupied by /boot and swap should be defined as single large partition which will be divided up later at the logical volume manager level.<br />
<br />
<br />
'''Multiple Disk Systems'''<br />
<br />
In systems that will have multiple harddisk drives, the same options exist as a single disk system. After the creation of the /boot and swap partitions, the remaining free space on physical disks can divided up into their respective partitions at this level, or large partitions can define all free space per physical disk with intent to partition them within the LVM.<br />
<br />
== Configuring LUKS ==<br />
<br />
Creating LUKS partitions with a passphrase is supported by the /arch/setup program. <br />
<br />
This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. <br />
<br />
The steps for accomplishing this through the graphical installer are very similar and can be located in dialogue for manual configuration of the hard drive.<br />
<br />
<br />
<br />
=== Mapping Physical Partitions to LUKS ===<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions and then mount them through the device mapper.<br />
<br />
When creating LUKS partitions they must be associated with a key. <br />
<br />
A key is either a: <br />
<br />
::*Passphrase<br />
::*Keyfile <br />
<br />
It is possible to define up to 8 different keys can be defined per LUKS partition.<br />
<br />
<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
There are many options that cryptsetup with accept, a full list can be reference in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::-c defines the cipher type<br />
::-y prompts for password confirmation on password creation<br />
::-s defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
<br />
In the following examples for creating LUKS partitions we will use AES with XTS, at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup and details about them can be found [[http://en.wikipedia.org/wiki/Block_cipher Wikipedia: BlockCipher]]<br />
<br />
<br />
'''Formating LUKS Partitions'''<br />
<br />
In order to format a desired partition as an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/<partition name><br />
Enter passphrase: <password><br />
Verify passphrase: <password><br />
<br />
<br />
This should be repeated until all partitions except for /boot and possibly swap.<br />
<br />
<br />
Example:<br />
<br />
::*For encrypting the root partition /dev/sda2:<br />
:::cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2 will create and encrypted root partition<br />
<br />
<br />
{{Note| If hibernation usage is planned, swap must be encrypted in this fashion. Otherwise if hibernation is not a planned feature for the system, encrypting the swap file will be performed in a alternative manner.}}<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
<br />
'''Unlocking/Mapping LUKS Partitions with the Device Mapper'''<br />
<br />
Once the LUKS partitions have been created it is time to unlock them. <br />
<br />
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that /dev/<partition name> is actually an encrypted device and should be addressed through LUKS using the /dev/mapper/<name> so as not to overwrite the encrypted data. <br />
<br />
<br />
In order to open an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup luksOpen /dev/<partition name> <device-mapper name><br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
<br />
::*/dev/sda2 which is the swap partition name can be mapped to ''''swap''''<br />
::::Once opened the device address would be '''/dev/mapper/swap''' instead of /dev/sda2<br />
<br />
<br />
::*/dev/sda3 which is the root parition name can be mapped to ''''root''''<br />
::::Once opened the device address would be '''/dev/mapper/root''' instead of /dev/sda3<br />
<br />
<br />
{{Note| Since /boot is not encrypted it does not need a device mapped name and will be addressed as /dev/sda1.}}<br />
<br />
<br />
{{Warning| In order to write encrypted data into the partition it must be accessed through the device mapped name.}}<br />
<br />
==== Using LUKS to Format Paritions with a Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
{{Warning |Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
=== Installing the system ===<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Encrypting swap partition ==<br />
Sensitive data stored in memory may be written to swap at any time. If you've gone to the trouble of encrypting your root and home partitions, you should encrypt your swap as well. There are two options here: random encryption on each boot (better security), or the same encryption each time. We won't cover the second option here, as it is pretty much identical to how you set up the /home partition above. Just replace all references to home with swap, and sda5 with sda2.<br />
<br />
Arch Linux provides a convenient way for the first option, which uses dm-crypt directly without LUKS. If you're still in the archsetup process, just switch to a different virtual console (ALT+F2). If you've exited already, the new root will have been unmounted. Use <tt>mount /dev/mapper/root /mnt</tt> to mount it again.<br />
<br />
Now add an entry to the cryptsetup file:<br />
# echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
{{ Tip | Recommended hash algorithms are "whirlpool" (patent free), "sha256", "sha384" or "sha512". Default is "ripemd160" (not recommended).}}<br />
<br />
''[why is it not recommended? only RIPEMD (128bit) was hacked RIPEMD-160 is still safe[https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=83310], isn't it? I heard wirlpool is at least twice as slow. ]''<br />
<br />
{{ Warning | Please take extra care to put the right partition here. The startup script won't ask before overwriting the provided device, destroying '''all''' data on it, ''unless it has a LUKS header'', then it simply won't work.}}<br />
<br />
If you have been following these instructions closely, then in the section "Mapping Partitions" above you put a LUKS header on your swap partition. Erase it with something like the command below, replacing /dev/sda2 with the appropriate swap device:<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
From now on, each time you boot, the partition will be encrypted automatically with a random key, and will then be formated with mkswap.<br />
<br />
Now all you have to do is adjust the corresponding entry in /etc/fstab:<br />
/dev/mapper/swap swap swap defaults 0 0<br />
<br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Encrypted swap with suspend-to-disk support ==<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Storing the key externally (USB stick) ==<br />
=== Preparation for permanent device names ===<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
==== Quick method ====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
=== Generating the keyfile ===<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
=== Storing the keyfile ===<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=118858Dm-crypt2010-10-09T01:27:15Z<p>Vinhsynd: /* Using LUKS to Format Partitions with a Passphrase */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is to simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Installation ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
<code>dd if=/dev/urandom of=/dev/<drive> bs=1M</code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
<code>badblocks -c 10240 -Wsvt random /dev/<drive></code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]] which is suggested reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
<br />
'''How does LVM fit into the overall system?'''<br />
<br />
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKs). It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKs on LVM). However the deployment of LVM on LUKS is considered much more generalizable. One reason for this that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In which case, logical volume management would be layered on top of the hardware encryption - usage of LUKS would be superfluous.<br />
<br />
<br />
==== Creating Disk Partitions ====<br />
<br />
Disk partitions are created using:<br />
<br />
# cfdisk<br />
<br />
This will display a graphical interface for creating disk partitions.<br />
<br />
There are 3 required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*'''/'''<br />
<br />
::An initial boot partition<br />
<br />
:::*'''/boot'''<br />
<br />
::A swap partition<br />
<br />
:::*'''swap'''<br />
<br />
<br />
'''Single Disk Systems'''<br />
<br />
Depending on the system demands, there may be additional partitions desired. These partitions can be individually created at this level by defining separate primary or extended/logical partitions. However if LVM is to be employed, the space unoccupied by /boot and swap should be defined as single large partition which will be divided up later at the logical volume manager level.<br />
<br />
<br />
'''Multiple Disk Systems'''<br />
<br />
In systems that will have multiple harddisk drives, the same options exist as a single disk system. After the creation of the /boot and swap partitions, the remaining free space on physical disks can divided up into their respective partitions at this level, or large partitions can define all free space per physical disk with intent to partition them within the LVM.<br />
<br />
== Configuring LUKS ==<br />
<br />
Creating LUKS partitions with a passphrase is supported by the /arch/setup program. <br />
<br />
This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. <br />
<br />
The steps for accomplishing this through the graphical installer are very similar and can be located in dialogue for manual configuration of the hard drive.<br />
<br />
<br />
<br />
=== Mapping Physical Partitions to LUKS ===<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions and then mount them through the device mapper.<br />
<br />
When creating LUKS partitions they must be associated with a key. <br />
<br />
A key is either a: <br />
<br />
::*Passphrase<br />
::*Keyfile <br />
<br />
It is possible to define up to 8 different keys can be defined per LUKS partition.<br />
<br />
<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
There are many options that cryptsetup with accept, a full list can be reference in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::-c defines the cipher type<br />
::-y prompts for password confirmation on password creation<br />
::-s defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
<br />
In the following examples for creating LUKS partitions we will use AES with XTS, at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup and details about them can be found [[http://en.wikipedia.org/wiki/Block_cipher Wikipedia: BlockCipher]]<br />
<br />
<br />
'''Formating LUKS Partitions'''<br />
<br />
In order to format a desired partition as an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/<partition name><br />
Enter passphrase: <password><br />
Verify passphrase: <password><br />
<br />
<br />
This should be repeated until all partitions except for /boot and possibly swap.<br />
<br />
<br />
Example:<br />
<br />
::*For encrypting the root partition /dev/sda2:<br />
:::cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2 will create and encrypted root partition<br />
<br />
<br />
{{Note| If hibernation usage is planned, swap must be encrypted in this fashion. Otherwise if hibernation is not a planned feature for the system, encrypting the swap file will be performed in a alternative manner.}}<br />
<br />
<br />
'''Unlocking/Mapping LUKS Partitions with the Device Mapper'''<br />
<br />
Once the LUKS partitions have been created it is time to unlock them. <br />
<br />
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that /dev/<partition name> is actually an encrypted device and should be addressed through LUKS using the /dev/mapper/<name> so as not to overwrite the encrypted data. <br />
<br />
<br />
In order to open an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup luksOpen /dev/<partition name> <device-mapper name><br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
<br />
::*/dev/sda2 which is the swap partition name can be mapped to ''''swap''''<br />
::::Once opened the device address would be '''/dev/mapper/swap''' instead of /dev/sda2<br />
<br />
<br />
::*/dev/sda3 which is the root parition name can be mapped to ''''root''''<br />
::::Once opened the device address would be '''/dev/mapper/root''' instead of /dev/sda3<br />
<br />
<br />
{{Note| Since /boot is not encrypted it does not need a device mapped name and will be addressed as /dev/sda1.}}<br />
<br />
<br />
{{Warning| In order to write encrypted data into the partition it must be accessed through the device mapped name.}}<br />
<br />
==== Using LUKS to Format Paritions with a Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
{{Note|Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
=== Installing the system ===<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Encrypting swap partition ==<br />
Sensitive data stored in memory may be written to swap at any time. If you've gone to the trouble of encrypting your root and home partitions, you should encrypt your swap as well. There are two options here: random encryption on each boot (better security), or the same encryption each time. We won't cover the second option here, as it is pretty much identical to how you set up the /home partition above. Just replace all references to home with swap, and sda5 with sda2.<br />
<br />
Arch Linux provides a convenient way for the first option, which uses dm-crypt directly without LUKS. If you're still in the archsetup process, just switch to a different virtual console (ALT+F2). If you've exited already, the new root will have been unmounted. Use <tt>mount /dev/mapper/root /mnt</tt> to mount it again.<br />
<br />
Now add an entry to the cryptsetup file:<br />
# echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
{{ Tip | Recommended hash algorithms are "whirlpool" (patent free), "sha256", "sha384" or "sha512". Default is "ripemd160" (not recommended).}}<br />
<br />
''[why is it not recommended? only RIPEMD (128bit) was hacked RIPEMD-160 is still safe[https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=83310], isn't it? I heard wirlpool is at least twice as slow. ]''<br />
<br />
{{ Warning | Please take extra care to put the right partition here. The startup script won't ask before overwriting the provided device, destroying '''all''' data on it, ''unless it has a LUKS header'', then it simply won't work.}}<br />
<br />
If you have been following these instructions closely, then in the section "Mapping Partitions" above you put a LUKS header on your swap partition. Erase it with something like the command below, replacing /dev/sda2 with the appropriate swap device:<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
From now on, each time you boot, the partition will be encrypted automatically with a random key, and will then be formated with mkswap.<br />
<br />
Now all you have to do is adjust the corresponding entry in /etc/fstab:<br />
/dev/mapper/swap swap swap defaults 0 0<br />
<br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Encrypted swap with suspend-to-disk support ==<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Storing the key externally (USB stick) ==<br />
=== Preparation for permanent device names ===<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
==== Quick method ====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
=== Generating the keyfile ===<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
=== Storing the keyfile ===<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=118857Dm-crypt2010-10-09T01:26:18Z<p>Vinhsynd: /* Keyfile */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is to simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Installation ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
<code>dd if=/dev/urandom of=/dev/<drive> bs=1M</code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
<code>badblocks -c 10240 -Wsvt random /dev/<drive></code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]] which is suggested reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
<br />
'''How does LVM fit into the overall system?'''<br />
<br />
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKs). It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKs on LVM). However the deployment of LVM on LUKS is considered much more generalizable. One reason for this that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In which case, logical volume management would be layered on top of the hardware encryption - usage of LUKS would be superfluous.<br />
<br />
<br />
==== Creating Disk Partitions ====<br />
<br />
Disk partitions are created using:<br />
<br />
# cfdisk<br />
<br />
This will display a graphical interface for creating disk partitions.<br />
<br />
There are 3 required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*'''/'''<br />
<br />
::An initial boot partition<br />
<br />
:::*'''/boot'''<br />
<br />
::A swap partition<br />
<br />
:::*'''swap'''<br />
<br />
<br />
'''Single Disk Systems'''<br />
<br />
Depending on the system demands, there may be additional partitions desired. These partitions can be individually created at this level by defining separate primary or extended/logical partitions. However if LVM is to be employed, the space unoccupied by /boot and swap should be defined as single large partition which will be divided up later at the logical volume manager level.<br />
<br />
<br />
'''Multiple Disk Systems'''<br />
<br />
In systems that will have multiple harddisk drives, the same options exist as a single disk system. After the creation of the /boot and swap partitions, the remaining free space on physical disks can divided up into their respective partitions at this level, or large partitions can define all free space per physical disk with intent to partition them within the LVM.<br />
<br />
== Configuring LUKS ==<br />
<br />
Creating LUKS partitions with a passphrase is supported by the /arch/setup program. <br />
<br />
This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. <br />
<br />
The steps for accomplishing this through the graphical installer are very similar and can be located in dialogue for manual configuration of the hard drive.<br />
<br />
<br />
<br />
=== Mapping Physical Partitions to LUKS ===<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions and then mount them through the device mapper.<br />
<br />
When creating LUKS partitions they must be associated with a key. <br />
<br />
A key is either a: <br />
<br />
::*Passphrase<br />
::*Keyfile <br />
<br />
It is possible to define up to 8 different keys can be defined per LUKS partition.<br />
<br />
<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
There are many options that cryptsetup with accept, a full list can be reference in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::-c defines the cipher type<br />
::-y prompts for password confirmation on password creation<br />
::-s defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
<br />
In the following examples for creating LUKS partitions we will use AES with XTS, at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup and details about them can be found [[http://en.wikipedia.org/wiki/Block_cipher Wikipedia: BlockCipher]]<br />
<br />
<br />
'''Formating LUKS Partitions'''<br />
<br />
In order to format a desired partition as an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/<partition name><br />
Enter passphrase: <password><br />
Verify passphrase: <password><br />
<br />
<br />
This should be repeated until all partitions except for /boot and possibly swap.<br />
<br />
<br />
Example:<br />
<br />
::*For encrypting the root partition /dev/sda2:<br />
:::cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2 will create and encrypted root partition<br />
<br />
<br />
{{Note| If hibernation usage is planned, swap must be encrypted in this fashion. Otherwise if hibernation is not a planned feature for the system, encrypting the swap file will be performed in a alternative manner.}}<br />
<br />
<br />
'''Unlocking/Mapping LUKS Partitions with the Device Mapper'''<br />
<br />
Once the LUKS partitions have been created it is time to unlock them. <br />
<br />
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that /dev/<partition name> is actually an encrypted device and should be addressed through LUKS using the /dev/mapper/<name> so as not to overwrite the encrypted data. <br />
<br />
<br />
In order to open an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup luksOpen /dev/<partition name> <device-mapper name><br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
<br />
::*/dev/sda2 which is the swap partition name can be mapped to ''''swap''''<br />
::::Once opened the device address would be '''/dev/mapper/swap''' instead of /dev/sda2<br />
<br />
<br />
::*/dev/sda3 which is the root parition name can be mapped to ''''root''''<br />
::::Once opened the device address would be '''/dev/mapper/root''' instead of /dev/sda3<br />
<br />
<br />
Since /boot is not encrypted it does not need a device mapped name and will be addressed as /dev/sda1.<br />
<br />
<br />
{{Warning| In order to write encrypted data into the partition it must be accessed through the device mapped name.}}<br />
<br />
<br />
<br />
==== Using LUKS to Format Paritions with a Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
{{Note|Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
=== Installing the system ===<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Encrypting swap partition ==<br />
Sensitive data stored in memory may be written to swap at any time. If you've gone to the trouble of encrypting your root and home partitions, you should encrypt your swap as well. There are two options here: random encryption on each boot (better security), or the same encryption each time. We won't cover the second option here, as it is pretty much identical to how you set up the /home partition above. Just replace all references to home with swap, and sda5 with sda2.<br />
<br />
Arch Linux provides a convenient way for the first option, which uses dm-crypt directly without LUKS. If you're still in the archsetup process, just switch to a different virtual console (ALT+F2). If you've exited already, the new root will have been unmounted. Use <tt>mount /dev/mapper/root /mnt</tt> to mount it again.<br />
<br />
Now add an entry to the cryptsetup file:<br />
# echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
{{ Tip | Recommended hash algorithms are "whirlpool" (patent free), "sha256", "sha384" or "sha512". Default is "ripemd160" (not recommended).}}<br />
<br />
''[why is it not recommended? only RIPEMD (128bit) was hacked RIPEMD-160 is still safe[https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=83310], isn't it? I heard wirlpool is at least twice as slow. ]''<br />
<br />
{{ Warning | Please take extra care to put the right partition here. The startup script won't ask before overwriting the provided device, destroying '''all''' data on it, ''unless it has a LUKS header'', then it simply won't work.}}<br />
<br />
If you have been following these instructions closely, then in the section "Mapping Partitions" above you put a LUKS header on your swap partition. Erase it with something like the command below, replacing /dev/sda2 with the appropriate swap device:<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
From now on, each time you boot, the partition will be encrypted automatically with a random key, and will then be formated with mkswap.<br />
<br />
Now all you have to do is adjust the corresponding entry in /etc/fstab:<br />
/dev/mapper/swap swap swap defaults 0 0<br />
<br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Encrypted swap with suspend-to-disk support ==<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Storing the key externally (USB stick) ==<br />
=== Preparation for permanent device names ===<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
==== Quick method ====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
=== Generating the keyfile ===<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
=== Storing the keyfile ===<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=118856Dm-crypt2010-10-09T01:25:24Z<p>Vinhsynd: /* Explanation */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is to simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Installation ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
<code>dd if=/dev/urandom of=/dev/<drive> bs=1M</code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
<code>badblocks -c 10240 -Wsvt random /dev/<drive></code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]] which is suggested reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
<br />
'''How does LVM fit into the overall system?'''<br />
<br />
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKs). It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKs on LVM). However the deployment of LVM on LUKS is considered much more generalizable. One reason for this that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In which case, logical volume management would be layered on top of the hardware encryption - usage of LUKS would be superfluous.<br />
<br />
<br />
==== Creating Disk Partitions ====<br />
<br />
Disk partitions are created using:<br />
<br />
# cfdisk<br />
<br />
This will display a graphical interface for creating disk partitions.<br />
<br />
There are 3 required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*'''/'''<br />
<br />
::An initial boot partition<br />
<br />
:::*'''/boot'''<br />
<br />
::A swap partition<br />
<br />
:::*'''swap'''<br />
<br />
<br />
'''Single Disk Systems'''<br />
<br />
Depending on the system demands, there may be additional partitions desired. These partitions can be individually created at this level by defining separate primary or extended/logical partitions. However if LVM is to be employed, the space unoccupied by /boot and swap should be defined as single large partition which will be divided up later at the logical volume manager level.<br />
<br />
<br />
'''Multiple Disk Systems'''<br />
<br />
In systems that will have multiple harddisk drives, the same options exist as a single disk system. After the creation of the /boot and swap partitions, the remaining free space on physical disks can divided up into their respective partitions at this level, or large partitions can define all free space per physical disk with intent to partition them within the LVM.<br />
<br />
== Configuring LUKS ==<br />
<br />
Creating LUKS partitions with a passphrase is supported by the /arch/setup program. <br />
<br />
This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. <br />
<br />
The steps for accomplishing this through the graphical installer are very similar and can be located in dialogue for manual configuration of the hard drive.<br />
<br />
<br />
<br />
=== Mapping Physical Partitions to LUKS ===<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions and then mount them through the device mapper.<br />
<br />
When creating LUKS partitions they must be associated with a key. <br />
<br />
A key is either a: <br />
<br />
::*Passphrase<br />
::*Keyfile <br />
<br />
It is possible to define up to 8 different keys can be defined per LUKS partition.<br />
<br />
<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
There are many options that cryptsetup with accept, a full list can be reference in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::-c defines the cipher type<br />
::-y prompts for password confirmation on password creation<br />
::-s defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
<br />
In the following examples for creating LUKS partitions we will use AES with XTS, at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup and details about them can be found [[http://en.wikipedia.org/wiki/Block_cipher Wikipedia: BlockCipher]]<br />
<br />
<br />
'''Formating LUKS Partitions'''<br />
<br />
In order to format a desired partition as an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/<partition name><br />
Enter passphrase: <password><br />
Verify passphrase: <password><br />
<br />
<br />
This should be repeated until all partitions except for /boot and possibly swap.<br />
<br />
<br />
Example:<br />
<br />
::*For encrypting the root partition /dev/sda2:<br />
:::cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2 will create and encrypted root partition<br />
<br />
<br />
{{Note| If hibernation usage is planned, swap must be encrypted in this fashion. Otherwise if hibernation is not a planned feature for the system, encrypting the swap file will be performed in a alternative manner.}}<br />
<br />
<br />
'''Unlocking/Mapping LUKS Partitions with the Device Mapper'''<br />
<br />
Once the LUKS partitions have been created it is time to unlock them. <br />
<br />
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that /dev/<partition name> is actually an encrypted device and should be addressed through LUKS using the /dev/mapper/<name> so as not to overwrite the encrypted data. <br />
<br />
<br />
In order to open an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup luksOpen /dev/<partition name> <device-mapper name><br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
<br />
::*/dev/sda2 which is the swap partition name can be mapped to ''''swap''''<br />
::::Once opened the device address would be '''/dev/mapper/swap''' instead of /dev/sda2<br />
<br />
<br />
::*/dev/sda3 which is the root parition name can be mapped to ''''root''''<br />
::::Once opened the device address would be '''/dev/mapper/root''' instead of /dev/sda3<br />
<br />
<br />
Since /boot is not encrypted it does not need a device mapped name and will be addressed as /dev/sda1.<br />
<br />
<br />
{{Warning| In order to write encrypted data into the partition it must be accessed through the device mapped name.}}<br />
<br />
<br />
<br />
==== Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
{{Note|Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
<br />
=== Installing the system ===<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Encrypting swap partition ==<br />
Sensitive data stored in memory may be written to swap at any time. If you've gone to the trouble of encrypting your root and home partitions, you should encrypt your swap as well. There are two options here: random encryption on each boot (better security), or the same encryption each time. We won't cover the second option here, as it is pretty much identical to how you set up the /home partition above. Just replace all references to home with swap, and sda5 with sda2.<br />
<br />
Arch Linux provides a convenient way for the first option, which uses dm-crypt directly without LUKS. If you're still in the archsetup process, just switch to a different virtual console (ALT+F2). If you've exited already, the new root will have been unmounted. Use <tt>mount /dev/mapper/root /mnt</tt> to mount it again.<br />
<br />
Now add an entry to the cryptsetup file:<br />
# echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
{{ Tip | Recommended hash algorithms are "whirlpool" (patent free), "sha256", "sha384" or "sha512". Default is "ripemd160" (not recommended).}}<br />
<br />
''[why is it not recommended? only RIPEMD (128bit) was hacked RIPEMD-160 is still safe[https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=83310], isn't it? I heard wirlpool is at least twice as slow. ]''<br />
<br />
{{ Warning | Please take extra care to put the right partition here. The startup script won't ask before overwriting the provided device, destroying '''all''' data on it, ''unless it has a LUKS header'', then it simply won't work.}}<br />
<br />
If you have been following these instructions closely, then in the section "Mapping Partitions" above you put a LUKS header on your swap partition. Erase it with something like the command below, replacing /dev/sda2 with the appropriate swap device:<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
From now on, each time you boot, the partition will be encrypted automatically with a random key, and will then be formated with mkswap.<br />
<br />
Now all you have to do is adjust the corresponding entry in /etc/fstab:<br />
/dev/mapper/swap swap swap defaults 0 0<br />
<br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Encrypted swap with suspend-to-disk support ==<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Storing the key externally (USB stick) ==<br />
=== Preparation for permanent device names ===<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
==== Quick method ====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
=== Generating the keyfile ===<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
=== Storing the keyfile ===<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=118855Dm-crypt2010-10-09T01:24:56Z<p>Vinhsynd: /* Configuring LUKS */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is to simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Installation ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
<code>dd if=/dev/urandom of=/dev/<drive> bs=1M</code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
<code>badblocks -c 10240 -Wsvt random /dev/<drive></code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]] which is suggested reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
<br />
'''How does LVM fit into the overall system?'''<br />
<br />
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKs). It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKs on LVM). However the deployment of LVM on LUKS is considered much more generalizable. One reason for this that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In which case, logical volume management would be layered on top of the hardware encryption - usage of LUKS would be superfluous.<br />
<br />
<br />
==== Creating Disk Partitions ====<br />
<br />
Disk partitions are created using:<br />
<br />
# cfdisk<br />
<br />
This will display a graphical interface for creating disk partitions.<br />
<br />
There are 3 required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*'''/'''<br />
<br />
::An initial boot partition<br />
<br />
:::*'''/boot'''<br />
<br />
::A swap partition<br />
<br />
:::*'''swap'''<br />
<br />
<br />
'''Single Disk Systems'''<br />
<br />
Depending on the system demands, there may be additional partitions desired. These partitions can be individually created at this level by defining separate primary or extended/logical partitions. However if LVM is to be employed, the space unoccupied by /boot and swap should be defined as single large partition which will be divided up later at the logical volume manager level.<br />
<br />
<br />
'''Multiple Disk Systems'''<br />
<br />
In systems that will have multiple harddisk drives, the same options exist as a single disk system. After the creation of the /boot and swap partitions, the remaining free space on physical disks can divided up into their respective partitions at this level, or large partitions can define all free space per physical disk with intent to partition them within the LVM.<br />
<br />
== Configuring LUKS ==<br />
<br />
Creating LUKS partitions with a passphrase is supported by the /arch/setup program. <br />
<br />
This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. <br />
<br />
The steps for accomplishing this through the graphical installer are very similar and can be located in dialogue for manual configuration of the hard drive.<br />
<br />
<br />
<br />
=== Mapping Physical Partitions to LUKS ===<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions and then mount them through the device mapper.<br />
<br />
When creating LUKS partitions they must be associated with a key. <br />
<br />
A key is either a: <br />
<br />
::*Passphrase<br />
::*Keyfile <br />
<br />
It is possible to define up to 8 different keys can be defined per LUKS partition.<br />
<br />
<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
There are many options that cryptsetup with accept, a full list can be reference in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::-c defines the cipher type<br />
::-y prompts for password confirmation on password creation<br />
::-s defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
<br />
In the following examples for creating LUKS partitions we will use AES with XTS, at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup and details about them can be found [[http://en.wikipedia.org/wiki/Block_cipher Wikipedia: BlockCipher]]<br />
<br />
<br />
'''Formating LUKS Partitions'''<br />
<br />
In order to format a desired partition as an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/<partition name><br />
Enter passphrase: <password><br />
Verify passphrase: <password><br />
<br />
<br />
This should be repeated until all partitions except for /boot and possibly swap.<br />
<br />
<br />
Example:<br />
<br />
::*For encrypting the root partition /dev/sda2:<br />
:::cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2 will create and encrypted root partition<br />
<br />
<br />
{{Note| If hibernation usage is planned, swap must be encrypted in this fashion. Otherwise if hibernation is not a planned feature for the system, encrypting the swap file will be performed in a alternative manner.}}<br />
<br />
<br />
'''Unlocking/Mapping LUKS Partitions with the Device Mapper'''<br />
<br />
Once the LUKS partitions have been created it is time to unlock them. <br />
<br />
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that /dev/<partition name> is actually an encrypted device and should be addressed through LUKS using the /dev/mapper/<name> so as not to overwrite the encrypted data. <br />
<br />
<br />
In order to open an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup luksOpen /dev/<partition name> <device-mapper name><br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
<br />
::*/dev/sda2 which is the swap partition name can be mapped to ''''swap''''<br />
::::Once opened the device address would be '''/dev/mapper/swap''' instead of /dev/sda2<br />
<br />
<br />
::*/dev/sda3 which is the root parition name can be mapped to ''''root''''<br />
::::Once opened the device address would be '''/dev/mapper/root''' instead of /dev/sda3<br />
<br />
<br />
Since /boot is not encrypted it does not need a device mapped name and will be addressed as /dev/sda1.<br />
<br />
<br />
{{Warning| In order to write encrypted data into the partition it must be accessed through the device mapped name.}}<br />
<br />
<br />
<br />
==== Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
{{Note|Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
<br />
==== Explanation ====<br />
Now you should have a device called <tt>/dev/mapper/root</tt>, another one called <tt>/dev/mapper/home</tt> and another one called <tt>/dev/mapper/tmp</tt>. These are block devices like any other, but with a neat twist: whenever you write to them, the data is actually written to <tt>/dev/sda3</tt>, <tt>/dev/sda5</tt> or <tt>/dev/sda6</tt> respectively, but it is encrypted first! The only way to access the data on this encrypted partition is to re-create that <tt>/dev/mapper/root</tt>, <tt>/dev/mapper/home</tt> etc. device with cryptsetup each time you boot. With LUKS, you can use <tt>cryptsetup luksAddKey /dev/sda3</tt> to add a new password or <tt>cryptsetup luksDelKey /dev/sda3</tt> to revoke a password. Type <tt>cryptsetup -?</tt> or <tt>man cryptsetup</tt> (once you've booted your new Arch installation) for more info.<br />
<br />
{{Note | With LUKS, if you enter the wrong password, it will reject it. You don't have to worry about it possibly destroying your data.}}<br />
<br />
{{ Note | You might also want to replace /var/tmp/ with a symbolic link to /tmp.}}<br />
<br />
{{ Note | If you've decided to go for option two for encrypted swap (see Encrypted Swap below), you should set up <tt>/dev/mapper/swap</tt> in a similar way as you've just set up <tt>/dev/mapper/home</tt>. See Encrypted Swap below for details.}}<br />
<br />
=== Installing the system ===<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Encrypting swap partition ==<br />
Sensitive data stored in memory may be written to swap at any time. If you've gone to the trouble of encrypting your root and home partitions, you should encrypt your swap as well. There are two options here: random encryption on each boot (better security), or the same encryption each time. We won't cover the second option here, as it is pretty much identical to how you set up the /home partition above. Just replace all references to home with swap, and sda5 with sda2.<br />
<br />
Arch Linux provides a convenient way for the first option, which uses dm-crypt directly without LUKS. If you're still in the archsetup process, just switch to a different virtual console (ALT+F2). If you've exited already, the new root will have been unmounted. Use <tt>mount /dev/mapper/root /mnt</tt> to mount it again.<br />
<br />
Now add an entry to the cryptsetup file:<br />
# echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
{{ Tip | Recommended hash algorithms are "whirlpool" (patent free), "sha256", "sha384" or "sha512". Default is "ripemd160" (not recommended).}}<br />
<br />
''[why is it not recommended? only RIPEMD (128bit) was hacked RIPEMD-160 is still safe[https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=83310], isn't it? I heard wirlpool is at least twice as slow. ]''<br />
<br />
{{ Warning | Please take extra care to put the right partition here. The startup script won't ask before overwriting the provided device, destroying '''all''' data on it, ''unless it has a LUKS header'', then it simply won't work.}}<br />
<br />
If you have been following these instructions closely, then in the section "Mapping Partitions" above you put a LUKS header on your swap partition. Erase it with something like the command below, replacing /dev/sda2 with the appropriate swap device:<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
From now on, each time you boot, the partition will be encrypted automatically with a random key, and will then be formated with mkswap.<br />
<br />
Now all you have to do is adjust the corresponding entry in /etc/fstab:<br />
/dev/mapper/swap swap swap defaults 0 0<br />
<br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Encrypted swap with suspend-to-disk support ==<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Storing the key externally (USB stick) ==<br />
=== Preparation for permanent device names ===<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
==== Quick method ====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
=== Generating the keyfile ===<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
=== Storing the keyfile ===<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=118854Dm-crypt2010-10-09T00:41:06Z<p>Vinhsynd: /* Data Encryption */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is to simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Installation ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
<code>dd if=/dev/urandom of=/dev/<drive> bs=1M</code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
<code>badblocks -c 10240 -Wsvt random /dev/<drive></code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]] which is suggested reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
<br />
'''How does LVM fit into the overall system?'''<br />
<br />
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKs). It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKs on LVM). However the deployment of LVM on LUKS is considered much more generalizable. One reason for this that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In which case, logical volume management would be layered on top of the hardware encryption - usage of LUKS would be superfluous.<br />
<br />
<br />
==== Creating Disk Partitions ====<br />
<br />
Disk partitions are created using:<br />
<br />
# cfdisk<br />
<br />
This will display a graphical interface for creating disk partitions.<br />
<br />
There are 3 required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*'''/'''<br />
<br />
::An initial boot partition<br />
<br />
:::*'''/boot'''<br />
<br />
::A swap partition<br />
<br />
:::*'''swap'''<br />
<br />
<br />
'''Single Disk Systems'''<br />
<br />
Depending on the system demands, there may be additional partitions desired. These partitions can be individually created at this level by defining separate primary or extended/logical partitions. However if LVM is to be employed, the space unoccupied by /boot and swap should be defined as single large partition which will be divided up later at the logical volume manager level.<br />
<br />
<br />
'''Multiple Disk Systems'''<br />
<br />
In systems that will have multiple harddisk drives, the same options exist as a single disk system. After the creation of the /boot and swap partitions, the remaining free space on physical disks can divided up into their respective partitions at this level, or large partitions can define all free space per physical disk with intent to partition them within the LVM.<br />
<br />
== Configuring LUKS ==<br />
<br />
Creating LUKS partitions with a passphrase is supported with the /arch/setup program. This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. The steps for accomplishing this through the graphical installer are very similar and can be located in the manual configuration of hard drive section of the installer.<br />
<br />
<br />
<br />
=== Mapping Physical Partitions to LUKS ===<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions.<br />
<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
<br />
In order to format a desired partition as an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/<partition name><br />
Enter passphrase: mypassword<br />
Verify passphrase: mypassword<br />
<br />
<br />
Then to mount the newly created LUKS partitions:<br />
<br />
# cryptsetup luksOpen /dev/<partition name> <device-mapper name><br />
Enter any LUKS passphrase: mypassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
<br />
==== Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
{{Note|Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
<br />
==== Explanation ====<br />
Now you should have a device called <tt>/dev/mapper/root</tt>, another one called <tt>/dev/mapper/home</tt> and another one called <tt>/dev/mapper/tmp</tt>. These are block devices like any other, but with a neat twist: whenever you write to them, the data is actually written to <tt>/dev/sda3</tt>, <tt>/dev/sda5</tt> or <tt>/dev/sda6</tt> respectively, but it is encrypted first! The only way to access the data on this encrypted partition is to re-create that <tt>/dev/mapper/root</tt>, <tt>/dev/mapper/home</tt> etc. device with cryptsetup each time you boot. With LUKS, you can use <tt>cryptsetup luksAddKey /dev/sda3</tt> to add a new password or <tt>cryptsetup luksDelKey /dev/sda3</tt> to revoke a password. Type <tt>cryptsetup -?</tt> or <tt>man cryptsetup</tt> (once you've booted your new Arch installation) for more info.<br />
<br />
{{Note | With LUKS, if you enter the wrong password, it will reject it. You don't have to worry about it possibly destroying your data.}}<br />
<br />
{{ Note | You might also want to replace /var/tmp/ with a symbolic link to /tmp.}}<br />
<br />
{{ Note | If you've decided to go for option two for encrypted swap (see Encrypted Swap below), you should set up <tt>/dev/mapper/swap</tt> in a similar way as you've just set up <tt>/dev/mapper/home</tt>. See Encrypted Swap below for details.}}<br />
<br />
=== Installing the system ===<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Encrypting swap partition ==<br />
Sensitive data stored in memory may be written to swap at any time. If you've gone to the trouble of encrypting your root and home partitions, you should encrypt your swap as well. There are two options here: random encryption on each boot (better security), or the same encryption each time. We won't cover the second option here, as it is pretty much identical to how you set up the /home partition above. Just replace all references to home with swap, and sda5 with sda2.<br />
<br />
Arch Linux provides a convenient way for the first option, which uses dm-crypt directly without LUKS. If you're still in the archsetup process, just switch to a different virtual console (ALT+F2). If you've exited already, the new root will have been unmounted. Use <tt>mount /dev/mapper/root /mnt</tt> to mount it again.<br />
<br />
Now add an entry to the cryptsetup file:<br />
# echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
{{ Tip | Recommended hash algorithms are "whirlpool" (patent free), "sha256", "sha384" or "sha512". Default is "ripemd160" (not recommended).}}<br />
<br />
''[why is it not recommended? only RIPEMD (128bit) was hacked RIPEMD-160 is still safe[https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=83310], isn't it? I heard wirlpool is at least twice as slow. ]''<br />
<br />
{{ Warning | Please take extra care to put the right partition here. The startup script won't ask before overwriting the provided device, destroying '''all''' data on it, ''unless it has a LUKS header'', then it simply won't work.}}<br />
<br />
If you have been following these instructions closely, then in the section "Mapping Partitions" above you put a LUKS header on your swap partition. Erase it with something like the command below, replacing /dev/sda2 with the appropriate swap device:<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
From now on, each time you boot, the partition will be encrypted automatically with a random key, and will then be formated with mkswap.<br />
<br />
Now all you have to do is adjust the corresponding entry in /etc/fstab:<br />
/dev/mapper/swap swap swap defaults 0 0<br />
<br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Encrypted swap with suspend-to-disk support ==<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Storing the key externally (USB stick) ==<br />
=== Preparation for permanent device names ===<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
==== Quick method ====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
=== Generating the keyfile ===<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
=== Storing the keyfile ===<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=118844Dm-crypt2010-10-08T20:22:39Z<p>Vinhsynd: /* Configuring LUKS */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is to simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Installation ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
<code>dd if=/dev/urandom of=/dev/<drive> bs=1M</code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
<code>badblocks -c 10240 -Wsvt random /dev/<drive></code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]] which is suggested reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
<br />
'''How does LVM fit into the overall system?'''<br />
<br />
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKs). It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKs on LVM). However the deployment of LVM on LUKS is considered much more generalizable. One reason for this that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In which case, logical volume management would be layered on top of the hardware encryption - usage of LUKS would be superfluous.<br />
<br />
<br />
==== Creating Disk Partitions ====<br />
<br />
Disk partitions are created using:<br />
<br />
# cfdisk<br />
<br />
This will display a graphical interface for creating disk partitions.<br />
<br />
There are 3 required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*'''/'''<br />
<br />
::An initial boot partition<br />
<br />
:::*'''/boot'''<br />
<br />
::A swap partition<br />
<br />
:::*'''swap'''<br />
<br />
<br />
'''Single Disk Systems'''<br />
<br />
Depending on the system demands, there may be additional partitions desired. These partitions can be individually created at this level by defining separate primary or extended/logical partitions. However if LVM is to be employed, the space unoccupied by /boot and swap should be defined as single large partition which will be divided up later at the logical volume manager level.<br />
<br />
<br />
'''Multiple Disk Systems'''<br />
<br />
In systems that will have multiple harddisk drives, the same options exist as a single disk system. After the creation of the /boot and swap partitions, the remaining free space on physical disks can divided up into their respective partitions at this level, or large partitions can define all free space per physical disk with intent to partition them within the LVM.<br />
<br />
== Configuring LUKS ==<br />
<br />
Creating LUKS partitions with a passphrase is supported with the /arch/setup program. This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. The steps for accomplishing this through the graphical installer are very similar and can be located in the manual configuration of hard drive section of the installer.<br />
<br />
<br />
<br />
=== Mapping Physical Partitions to LUKS ===<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions.<br />
<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
<br />
In order to format a desired partition as an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/<partition name><br />
Enter passphrase: mypassword<br />
Verify passphrase: mypassword<br />
<br />
<br />
Then to mount the newly created LUKS partitions:<br />
<br />
# cryptsetup luksOpen /dev/<partition name> <device-mapper name><br />
Enter any LUKS passphrase: mypassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
<br />
==== Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
{{Note|Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
<br />
==== Explanation ====<br />
Now you should have a device called <tt>/dev/mapper/root</tt>, another one called <tt>/dev/mapper/home</tt> and another one called <tt>/dev/mapper/tmp</tt>. These are block devices like any other, but with a neat twist: whenever you write to them, the data is actually written to <tt>/dev/sda3</tt>, <tt>/dev/sda5</tt> or <tt>/dev/sda6</tt> respectively, but it is encrypted first! The only way to access the data on this encrypted partition is to re-create that <tt>/dev/mapper/root</tt>, <tt>/dev/mapper/home</tt> etc. device with cryptsetup each time you boot. With LUKS, you can use <tt>cryptsetup luksAddKey /dev/sda3</tt> to add a new password or <tt>cryptsetup luksDelKey /dev/sda3</tt> to revoke a password. Type <tt>cryptsetup -?</tt> or <tt>man cryptsetup</tt> (once you've booted your new Arch installation) for more info.<br />
<br />
{{Note | With LUKS, if you enter the wrong password, it will reject it. You don't have to worry about it possibly destroying your data.}}<br />
<br />
{{ Note | You might also want to replace /var/tmp/ with a symbolic link to /tmp.}}<br />
<br />
{{ Note | If you've decided to go for option two for encrypted swap (see Encrypted Swap below), you should set up <tt>/dev/mapper/swap</tt> in a similar way as you've just set up <tt>/dev/mapper/home</tt>. See Encrypted Swap below for details.}}<br />
<br />
=== Installing the system ===<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Encrypting swap partition ==<br />
Sensitive data stored in memory may be written to swap at any time. If you've gone to the trouble of encrypting your root and home partitions, you should encrypt your swap as well. There are two options here: random encryption on each boot (better security), or the same encryption each time. We won't cover the second option here, as it is pretty much identical to how you set up the /home partition above. Just replace all references to home with swap, and sda5 with sda2.<br />
<br />
Arch Linux provides a convenient way for the first option, which uses dm-crypt directly without LUKS. If you're still in the archsetup process, just switch to a different virtual console (ALT+F2). If you've exited already, the new root will have been unmounted. Use <tt>mount /dev/mapper/root /mnt</tt> to mount it again.<br />
<br />
Now add an entry to the cryptsetup file:<br />
# echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
{{ Tip | Recommended hash algorithms are "whirlpool" (patent free), "sha256", "sha384" or "sha512". Default is "ripemd160" (not recommended).}}<br />
<br />
''[why is it not recommended? only RIPEMD (128bit) was hacked RIPEMD-160 is still safe[https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=83310], isn't it? I heard wirlpool is at least twice as slow. ]''<br />
<br />
{{ Warning | Please take extra care to put the right partition here. The startup script won't ask before overwriting the provided device, destroying '''all''' data on it, ''unless it has a LUKS header'', then it simply won't work.}}<br />
<br />
If you have been following these instructions closely, then in the section "Mapping Partitions" above you put a LUKS header on your swap partition. Erase it with something like the command below, replacing /dev/sda2 with the appropriate swap device:<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
From now on, each time you boot, the partition will be encrypted automatically with a random key, and will then be formated with mkswap.<br />
<br />
Now all you have to do is adjust the corresponding entry in /etc/fstab:<br />
/dev/mapper/swap swap swap defaults 0 0<br />
<br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Encrypted swap with suspend-to-disk support ==<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Storing the key externally (USB stick) ==<br />
=== Preparation for permanent device names ===<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
==== Quick method ====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
=== Generating the keyfile ===<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
=== Storing the keyfile ===<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=118843Dm-crypt2010-10-08T20:20:50Z<p>Vinhsynd: /* Creating Disk Partitions */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is to simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Installation ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
<code>dd if=/dev/urandom of=/dev/<drive> bs=1M</code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
<code>badblocks -c 10240 -Wsvt random /dev/<drive></code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]] which is suggested reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
<br />
'''How does LVM fit into the overall system?'''<br />
<br />
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKs). It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKs on LVM). However the deployment of LVM on LUKS is considered much more generalizable. One reason for this that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In which case, logical volume management would be layered on top of the hardware encryption - usage of LUKS would be superfluous.<br />
<br />
<br />
==== Creating Disk Partitions ====<br />
<br />
Disk partitions are created using:<br />
<br />
# cfdisk<br />
<br />
This will display a graphical interface for creating disk partitions.<br />
<br />
There are 3 required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*'''/'''<br />
<br />
::An initial boot partition<br />
<br />
:::*'''/boot'''<br />
<br />
::A swap partition<br />
<br />
:::*'''swap'''<br />
<br />
<br />
'''Single Disk Systems'''<br />
<br />
Depending on the system demands, there may be additional partitions desired. These partitions can be individually created at this level by defining separate primary or extended/logical partitions. However if LVM is to be employed, the space unoccupied by /boot and swap should be defined as single large partition which will be divided up later at the logical volume manager level.<br />
<br />
<br />
'''Multiple Disk Systems'''<br />
<br />
In systems that will have multiple harddisk drives, the same options exist as a single disk system. After the creation of the /boot and swap partitions, the remaining free space on physical disks can divided up into their respective partitions at this level, or large partitions can define all free space per physical disk with intent to partition them within the LVM.<br />
<br />
== Configuring LUKS ==<br />
<br />
Creating LUKS partitions with a passphrase is supported with the /arch/setup program. This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. The steps for accomplishing this through the graphical installer are very similar and can be located in the manual configuration of hard drive section of the installer.<br />
<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions.<br />
<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
<br />
In order to format a desired partition as an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/<partition name><br />
Enter passphrase: mypassword<br />
Verify passphrase: mypassword<br />
<br />
<br />
Then to mount the newly created LUKS partitions:<br />
<br />
# cryptsetup luksOpen /dev/<partition name> <device-mapper name><br />
Enter any LUKS passphrase: mypassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
<br />
==== Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
{{Note|Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
<br />
==== Explanation ====<br />
Now you should have a device called <tt>/dev/mapper/root</tt>, another one called <tt>/dev/mapper/home</tt> and another one called <tt>/dev/mapper/tmp</tt>. These are block devices like any other, but with a neat twist: whenever you write to them, the data is actually written to <tt>/dev/sda3</tt>, <tt>/dev/sda5</tt> or <tt>/dev/sda6</tt> respectively, but it is encrypted first! The only way to access the data on this encrypted partition is to re-create that <tt>/dev/mapper/root</tt>, <tt>/dev/mapper/home</tt> etc. device with cryptsetup each time you boot. With LUKS, you can use <tt>cryptsetup luksAddKey /dev/sda3</tt> to add a new password or <tt>cryptsetup luksDelKey /dev/sda3</tt> to revoke a password. Type <tt>cryptsetup -?</tt> or <tt>man cryptsetup</tt> (once you've booted your new Arch installation) for more info.<br />
<br />
{{Note | With LUKS, if you enter the wrong password, it will reject it. You don't have to worry about it possibly destroying your data.}}<br />
<br />
{{ Note | You might also want to replace /var/tmp/ with a symbolic link to /tmp.}}<br />
<br />
{{ Note | If you've decided to go for option two for encrypted swap (see Encrypted Swap below), you should set up <tt>/dev/mapper/swap</tt> in a similar way as you've just set up <tt>/dev/mapper/home</tt>. See Encrypted Swap below for details.}}<br />
<br />
=== Installing the system ===<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Encrypting swap partition ==<br />
Sensitive data stored in memory may be written to swap at any time. If you've gone to the trouble of encrypting your root and home partitions, you should encrypt your swap as well. There are two options here: random encryption on each boot (better security), or the same encryption each time. We won't cover the second option here, as it is pretty much identical to how you set up the /home partition above. Just replace all references to home with swap, and sda5 with sda2.<br />
<br />
Arch Linux provides a convenient way for the first option, which uses dm-crypt directly without LUKS. If you're still in the archsetup process, just switch to a different virtual console (ALT+F2). If you've exited already, the new root will have been unmounted. Use <tt>mount /dev/mapper/root /mnt</tt> to mount it again.<br />
<br />
Now add an entry to the cryptsetup file:<br />
# echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
{{ Tip | Recommended hash algorithms are "whirlpool" (patent free), "sha256", "sha384" or "sha512". Default is "ripemd160" (not recommended).}}<br />
<br />
''[why is it not recommended? only RIPEMD (128bit) was hacked RIPEMD-160 is still safe[https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=83310], isn't it? I heard wirlpool is at least twice as slow. ]''<br />
<br />
{{ Warning | Please take extra care to put the right partition here. The startup script won't ask before overwriting the provided device, destroying '''all''' data on it, ''unless it has a LUKS header'', then it simply won't work.}}<br />
<br />
If you have been following these instructions closely, then in the section "Mapping Partitions" above you put a LUKS header on your swap partition. Erase it with something like the command below, replacing /dev/sda2 with the appropriate swap device:<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
From now on, each time you boot, the partition will be encrypted automatically with a random key, and will then be formated with mkswap.<br />
<br />
Now all you have to do is adjust the corresponding entry in /etc/fstab:<br />
/dev/mapper/swap swap swap defaults 0 0<br />
<br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Encrypted swap with suspend-to-disk support ==<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Storing the key externally (USB stick) ==<br />
=== Preparation for permanent device names ===<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
==== Quick method ====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
=== Generating the keyfile ===<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
=== Storing the keyfile ===<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=118842Dm-crypt2010-10-08T20:06:47Z<p>Vinhsynd: /* Creating Partitions */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is to simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Installation ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
<code>dd if=/dev/urandom of=/dev/<drive> bs=1M</code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
<code>badblocks -c 10240 -Wsvt random /dev/<drive></code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]] which is suggested reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
<br />
'''How does LVM fit into the overall system?'''<br />
<br />
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKs). It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKs on LVM). However the deployment of LVM on LUKS is considered much more generalizable. One reason for this that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In which case, logical volume management would be layered on top of the hardware encryption - usage of LUKS would be superfluous.<br />
<br />
<br />
==== Creating Disk Partitions ====<br />
<br />
<br />
<br />
{{Note|Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
== Configuring LUKS ==<br />
<br />
Creating LUKS partitions with a passphrase is supported with the /arch/setup program. This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. The steps for accomplishing this through the graphical installer are very similar and can be located in the manual configuration of hard drive section of the installer.<br />
<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions.<br />
<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
<br />
In order to format a desired partition as an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/<partition name><br />
Enter passphrase: mypassword<br />
Verify passphrase: mypassword<br />
<br />
<br />
Then to mount the newly created LUKS partitions:<br />
<br />
# cryptsetup luksOpen /dev/<partition name> <device-mapper name><br />
Enter any LUKS passphrase: mypassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
<br />
==== Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
{{Note|Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
<br />
==== Explanation ====<br />
Now you should have a device called <tt>/dev/mapper/root</tt>, another one called <tt>/dev/mapper/home</tt> and another one called <tt>/dev/mapper/tmp</tt>. These are block devices like any other, but with a neat twist: whenever you write to them, the data is actually written to <tt>/dev/sda3</tt>, <tt>/dev/sda5</tt> or <tt>/dev/sda6</tt> respectively, but it is encrypted first! The only way to access the data on this encrypted partition is to re-create that <tt>/dev/mapper/root</tt>, <tt>/dev/mapper/home</tt> etc. device with cryptsetup each time you boot. With LUKS, you can use <tt>cryptsetup luksAddKey /dev/sda3</tt> to add a new password or <tt>cryptsetup luksDelKey /dev/sda3</tt> to revoke a password. Type <tt>cryptsetup -?</tt> or <tt>man cryptsetup</tt> (once you've booted your new Arch installation) for more info.<br />
<br />
{{Note | With LUKS, if you enter the wrong password, it will reject it. You don't have to worry about it possibly destroying your data.}}<br />
<br />
{{ Note | You might also want to replace /var/tmp/ with a symbolic link to /tmp.}}<br />
<br />
{{ Note | If you've decided to go for option two for encrypted swap (see Encrypted Swap below), you should set up <tt>/dev/mapper/swap</tt> in a similar way as you've just set up <tt>/dev/mapper/home</tt>. See Encrypted Swap below for details.}}<br />
<br />
=== Installing the system ===<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Encrypting swap partition ==<br />
Sensitive data stored in memory may be written to swap at any time. If you've gone to the trouble of encrypting your root and home partitions, you should encrypt your swap as well. There are two options here: random encryption on each boot (better security), or the same encryption each time. We won't cover the second option here, as it is pretty much identical to how you set up the /home partition above. Just replace all references to home with swap, and sda5 with sda2.<br />
<br />
Arch Linux provides a convenient way for the first option, which uses dm-crypt directly without LUKS. If you're still in the archsetup process, just switch to a different virtual console (ALT+F2). If you've exited already, the new root will have been unmounted. Use <tt>mount /dev/mapper/root /mnt</tt> to mount it again.<br />
<br />
Now add an entry to the cryptsetup file:<br />
# echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
{{ Tip | Recommended hash algorithms are "whirlpool" (patent free), "sha256", "sha384" or "sha512". Default is "ripemd160" (not recommended).}}<br />
<br />
''[why is it not recommended? only RIPEMD (128bit) was hacked RIPEMD-160 is still safe[https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=83310], isn't it? I heard wirlpool is at least twice as slow. ]''<br />
<br />
{{ Warning | Please take extra care to put the right partition here. The startup script won't ask before overwriting the provided device, destroying '''all''' data on it, ''unless it has a LUKS header'', then it simply won't work.}}<br />
<br />
If you have been following these instructions closely, then in the section "Mapping Partitions" above you put a LUKS header on your swap partition. Erase it with something like the command below, replacing /dev/sda2 with the appropriate swap device:<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
From now on, each time you boot, the partition will be encrypted automatically with a random key, and will then be formated with mkswap.<br />
<br />
Now all you have to do is adjust the corresponding entry in /etc/fstab:<br />
/dev/mapper/swap swap swap defaults 0 0<br />
<br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Encrypted swap with suspend-to-disk support ==<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Storing the key externally (USB stick) ==<br />
=== Preparation for permanent device names ===<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
==== Quick method ====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
=== Generating the keyfile ===<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
=== Storing the keyfile ===<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=118841Dm-crypt2010-10-08T20:02:24Z<p>Vinhsynd: /* Partitioning */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is to simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Installation ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
<code>dd if=/dev/urandom of=/dev/<drive> bs=1M</code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
<code>badblocks -c 10240 -Wsvt random /dev/<drive></code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]] which is suggested reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
<br />
'''How does LVM fit into the overall system?'''<br />
<br />
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKs). It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKs on LVM). However the deployment of LVM on LUKS is considered much more generalizable. One reason for this that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In which case, logical volume management would be layered on top of the hardware encryption - usage of LUKS would be superfluous.<br />
<br />
<br />
==== Creating Disk Partitions ====<br />
<br />
<br />
<br />
{{Note|Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
== Configuring LUKS ==<br />
<br />
Creating LUKS partitions with a passphrase is supported with the /arch/setup program. This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. The steps for accomplishing this through the graphical installer are very similar and can be located in the manual configuration of hard drive section of the installer.<br />
<br />
=== Creating Partitions ===<br />
<br />
Disk partitions are created using:<br />
<br />
# cfdisk<br />
<br />
This will display a graphical interface for creating disk partitions.<br />
<br />
There are 3 required partitions for any encrypted system:<br />
<br />
::The root file system<br />
<br />
:::*'''/'''<br />
<br />
::The initial boot partition<br />
<br />
:::*'''/boot'''<br />
<br />
::The swap partition<br />
<br />
:::*'''swap'''<br />
<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions.<br />
<br />
<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
<br />
In order to format a desired partition as an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/<partition name><br />
Enter passphrase: mypassword<br />
Verify passphrase: mypassword<br />
<br />
<br />
Then to mount the newly created LUKS partitions:<br />
<br />
# cryptsetup luksOpen /dev/<partition name> <device-mapper name><br />
Enter any LUKS passphrase: mypassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
<br />
==== Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
==== Explanation ====<br />
Now you should have a device called <tt>/dev/mapper/root</tt>, another one called <tt>/dev/mapper/home</tt> and another one called <tt>/dev/mapper/tmp</tt>. These are block devices like any other, but with a neat twist: whenever you write to them, the data is actually written to <tt>/dev/sda3</tt>, <tt>/dev/sda5</tt> or <tt>/dev/sda6</tt> respectively, but it is encrypted first! The only way to access the data on this encrypted partition is to re-create that <tt>/dev/mapper/root</tt>, <tt>/dev/mapper/home</tt> etc. device with cryptsetup each time you boot. With LUKS, you can use <tt>cryptsetup luksAddKey /dev/sda3</tt> to add a new password or <tt>cryptsetup luksDelKey /dev/sda3</tt> to revoke a password. Type <tt>cryptsetup -?</tt> or <tt>man cryptsetup</tt> (once you've booted your new Arch installation) for more info.<br />
<br />
{{Note | With LUKS, if you enter the wrong password, it will reject it. You don't have to worry about it possibly destroying your data.}}<br />
<br />
{{ Note | You might also want to replace /var/tmp/ with a symbolic link to /tmp.}}<br />
<br />
{{ Note | If you've decided to go for option two for encrypted swap (see Encrypted Swap below), you should set up <tt>/dev/mapper/swap</tt> in a similar way as you've just set up <tt>/dev/mapper/home</tt>. See Encrypted Swap below for details.}}<br />
<br />
=== Installing the system ===<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Encrypting swap partition ==<br />
Sensitive data stored in memory may be written to swap at any time. If you've gone to the trouble of encrypting your root and home partitions, you should encrypt your swap as well. There are two options here: random encryption on each boot (better security), or the same encryption each time. We won't cover the second option here, as it is pretty much identical to how you set up the /home partition above. Just replace all references to home with swap, and sda5 with sda2.<br />
<br />
Arch Linux provides a convenient way for the first option, which uses dm-crypt directly without LUKS. If you're still in the archsetup process, just switch to a different virtual console (ALT+F2). If you've exited already, the new root will have been unmounted. Use <tt>mount /dev/mapper/root /mnt</tt> to mount it again.<br />
<br />
Now add an entry to the cryptsetup file:<br />
# echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
{{ Tip | Recommended hash algorithms are "whirlpool" (patent free), "sha256", "sha384" or "sha512". Default is "ripemd160" (not recommended).}}<br />
<br />
''[why is it not recommended? only RIPEMD (128bit) was hacked RIPEMD-160 is still safe[https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=83310], isn't it? I heard wirlpool is at least twice as slow. ]''<br />
<br />
{{ Warning | Please take extra care to put the right partition here. The startup script won't ask before overwriting the provided device, destroying '''all''' data on it, ''unless it has a LUKS header'', then it simply won't work.}}<br />
<br />
If you have been following these instructions closely, then in the section "Mapping Partitions" above you put a LUKS header on your swap partition. Erase it with something like the command below, replacing /dev/sda2 with the appropriate swap device:<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
From now on, each time you boot, the partition will be encrypted automatically with a random key, and will then be formated with mkswap.<br />
<br />
Now all you have to do is adjust the corresponding entry in /etc/fstab:<br />
/dev/mapper/swap swap swap defaults 0 0<br />
<br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Encrypted swap with suspend-to-disk support ==<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Storing the key externally (USB stick) ==<br />
=== Preparation for permanent device names ===<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
==== Quick method ====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
=== Generating the keyfile ===<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
=== Storing the keyfile ===<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=118839Dm-crypt2010-10-08T19:34:49Z<p>Vinhsynd: /* Configuring LUKS with Standard Partitions */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is to simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Installation ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
<code>dd if=/dev/urandom of=/dev/<drive> bs=1M</code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
<code>badblocks -c 10240 -Wsvt random /dev/<drive></code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]] which is suggested reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
<br />
<br />
{{Note|Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrytped in order to load the kernel and boot the system.}}<br />
<br />
<br />
<br />
For instructions on how to use LUKS with standard partitions, see [[System Encryption with LUKS for dm-crypt#Configuring LUKS | Configuring LUKS with Standard Partitions]].<br />
<br />
For instructions on how to use LUKS with LVM Partitions, see [[System Encryption with LUKS for dm-crypt#Encrypting a LVM setup | Encrypting an LVM Setup]].<br />
<br />
== Configuring LUKS ==<br />
<br />
Creating LUKS partitions with a passphrase is supported with the /arch/setup program. This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. The steps for accomplishing this through the graphical installer are very similar and can be located in the manual configuration of hard drive section of the installer.<br />
<br />
=== Creating Partitions ===<br />
<br />
Disk partitions are created using:<br />
<br />
# cfdisk<br />
<br />
This will display a graphical interface for creating disk partitions.<br />
<br />
There are 3 required partitions for any encrypted system:<br />
<br />
::The root file system<br />
<br />
:::*'''/'''<br />
<br />
::The initial boot partition<br />
<br />
:::*'''/boot'''<br />
<br />
::The swap partition<br />
<br />
:::*'''swap'''<br />
<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions.<br />
<br />
<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
<br />
In order to format a desired partition as an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/<partition name><br />
Enter passphrase: mypassword<br />
Verify passphrase: mypassword<br />
<br />
<br />
Then to mount the newly created LUKS partitions:<br />
<br />
# cryptsetup luksOpen /dev/<partition name> <device-mapper name><br />
Enter any LUKS passphrase: mypassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
<br />
==== Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
==== Explanation ====<br />
Now you should have a device called <tt>/dev/mapper/root</tt>, another one called <tt>/dev/mapper/home</tt> and another one called <tt>/dev/mapper/tmp</tt>. These are block devices like any other, but with a neat twist: whenever you write to them, the data is actually written to <tt>/dev/sda3</tt>, <tt>/dev/sda5</tt> or <tt>/dev/sda6</tt> respectively, but it is encrypted first! The only way to access the data on this encrypted partition is to re-create that <tt>/dev/mapper/root</tt>, <tt>/dev/mapper/home</tt> etc. device with cryptsetup each time you boot. With LUKS, you can use <tt>cryptsetup luksAddKey /dev/sda3</tt> to add a new password or <tt>cryptsetup luksDelKey /dev/sda3</tt> to revoke a password. Type <tt>cryptsetup -?</tt> or <tt>man cryptsetup</tt> (once you've booted your new Arch installation) for more info.<br />
<br />
{{Note | With LUKS, if you enter the wrong password, it will reject it. You don't have to worry about it possibly destroying your data.}}<br />
<br />
{{ Note | You might also want to replace /var/tmp/ with a symbolic link to /tmp.}}<br />
<br />
{{ Note | If you've decided to go for option two for encrypted swap (see Encrypted Swap below), you should set up <tt>/dev/mapper/swap</tt> in a similar way as you've just set up <tt>/dev/mapper/home</tt>. See Encrypted Swap below for details.}}<br />
<br />
=== Installing the system ===<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Encrypting swap partition ==<br />
Sensitive data stored in memory may be written to swap at any time. If you've gone to the trouble of encrypting your root and home partitions, you should encrypt your swap as well. There are two options here: random encryption on each boot (better security), or the same encryption each time. We won't cover the second option here, as it is pretty much identical to how you set up the /home partition above. Just replace all references to home with swap, and sda5 with sda2.<br />
<br />
Arch Linux provides a convenient way for the first option, which uses dm-crypt directly without LUKS. If you're still in the archsetup process, just switch to a different virtual console (ALT+F2). If you've exited already, the new root will have been unmounted. Use <tt>mount /dev/mapper/root /mnt</tt> to mount it again.<br />
<br />
Now add an entry to the cryptsetup file:<br />
# echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
{{ Tip | Recommended hash algorithms are "whirlpool" (patent free), "sha256", "sha384" or "sha512". Default is "ripemd160" (not recommended).}}<br />
<br />
''[why is it not recommended? only RIPEMD (128bit) was hacked RIPEMD-160 is still safe[https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=83310], isn't it? I heard wirlpool is at least twice as slow. ]''<br />
<br />
{{ Warning | Please take extra care to put the right partition here. The startup script won't ask before overwriting the provided device, destroying '''all''' data on it, ''unless it has a LUKS header'', then it simply won't work.}}<br />
<br />
If you have been following these instructions closely, then in the section "Mapping Partitions" above you put a LUKS header on your swap partition. Erase it with something like the command below, replacing /dev/sda2 with the appropriate swap device:<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
From now on, each time you boot, the partition will be encrypted automatically with a random key, and will then be formated with mkswap.<br />
<br />
Now all you have to do is adjust the corresponding entry in /etc/fstab:<br />
/dev/mapper/swap swap swap defaults 0 0<br />
<br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Encrypted swap with suspend-to-disk support ==<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Storing the key externally (USB stick) ==<br />
=== Preparation for permanent device names ===<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
==== Quick method ====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
=== Generating the keyfile ===<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
=== Storing the keyfile ===<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=118766Dm-crypt2010-10-06T14:53:58Z<p>Vinhsynd: /* Configuring LUKS with Standard Partitions */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is to simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Installation ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
<code>dd if=/dev/urandom of=/dev/<drive> bs=1M</code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
<code>badblocks -c 10240 -Wsvt random /dev/<drive></code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]] which is suggested reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
<br />
<br />
{{Note|Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrytped in order to load the kernel and boot the system.}}<br />
<br />
<br />
<br />
For instructions on how to use LUKS with standard partitions, see [[System Encryption with LUKS for dm-crypt#Configuring LUKS | Configuring LUKS with Standard Partitions]].<br />
<br />
For instructions on how to use LUKS with LVM Partitions, see [[System Encryption with LUKS for dm-crypt#Encrypting a LVM setup | Encrypting an LVM Setup]].<br />
<br />
== Configuring LUKS with Standard Partitions ==<br />
<br />
Creating LUKS partitions with a passphrase is supported with the /arch/setup program. This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. The steps for accomplishing this through the graphical installer are very similar and can be located in the manual configuration of hard drive section of the installer.<br />
<br />
=== Creating Partitions ===<br />
<br />
Disk partitions are created using:<br />
<br />
# cfdisk<br />
<br />
This will display a graphical interface for creating disk partitions.<br />
<br />
There are 3 required partitions for any encrypted system:<br />
<br />
::The root file system<br />
<br />
:::*'''/'''<br />
<br />
::The initial boot partition<br />
<br />
:::*'''/boot'''<br />
<br />
::The swap partition<br />
<br />
:::*'''swap'''<br />
<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions.<br />
<br />
<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
<br />
In order to format a desired partition as an encrypted LUKS partition please execute:<br />
<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/<partition name><br />
Enter passphrase: mypassword<br />
Verify passphrase: mypassword<br />
<br />
<br />
Then to mount the newly created LUKS partitions:<br />
<br />
# cryptsetup luksOpen /dev/<partition name> <device-mapper name><br />
Enter any LUKS passphrase: mypassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
<br />
==== Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
==== Explanation ====<br />
Now you should have a device called <tt>/dev/mapper/root</tt>, another one called <tt>/dev/mapper/home</tt> and another one called <tt>/dev/mapper/tmp</tt>. These are block devices like any other, but with a neat twist: whenever you write to them, the data is actually written to <tt>/dev/sda3</tt>, <tt>/dev/sda5</tt> or <tt>/dev/sda6</tt> respectively, but it is encrypted first! The only way to access the data on this encrypted partition is to re-create that <tt>/dev/mapper/root</tt>, <tt>/dev/mapper/home</tt> etc. device with cryptsetup each time you boot. With LUKS, you can use <tt>cryptsetup luksAddKey /dev/sda3</tt> to add a new password or <tt>cryptsetup luksDelKey /dev/sda3</tt> to revoke a password. Type <tt>cryptsetup -?</tt> or <tt>man cryptsetup</tt> (once you've booted your new Arch installation) for more info.<br />
<br />
{{Note | With LUKS, if you enter the wrong password, it will reject it. You don't have to worry about it possibly destroying your data.}}<br />
<br />
{{ Note | You might also want to replace /var/tmp/ with a symbolic link to /tmp.}}<br />
<br />
{{ Note | If you've decided to go for option two for encrypted swap (see Encrypted Swap below), you should set up <tt>/dev/mapper/swap</tt> in a similar way as you've just set up <tt>/dev/mapper/home</tt>. See Encrypted Swap below for details.}}<br />
<br />
=== Installing the system ===<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Encrypting swap partition ==<br />
Sensitive data stored in memory may be written to swap at any time. If you've gone to the trouble of encrypting your root and home partitions, you should encrypt your swap as well. There are two options here: random encryption on each boot (better security), or the same encryption each time. We won't cover the second option here, as it is pretty much identical to how you set up the /home partition above. Just replace all references to home with swap, and sda5 with sda2.<br />
<br />
Arch Linux provides a convenient way for the first option, which uses dm-crypt directly without LUKS. If you're still in the archsetup process, just switch to a different virtual console (ALT+F2). If you've exited already, the new root will have been unmounted. Use <tt>mount /dev/mapper/root /mnt</tt> to mount it again.<br />
<br />
Now add an entry to the cryptsetup file:<br />
# echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
{{ Tip | Recommended hash algorithms are "whirlpool" (patent free), "sha256", "sha384" or "sha512". Default is "ripemd160" (not recommended).}}<br />
<br />
''[why is it not recommended? only RIPEMD (128bit) was hacked RIPEMD-160 is still safe[https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=83310], isn't it? I heard wirlpool is at least twice as slow. ]''<br />
<br />
{{ Warning | Please take extra care to put the right partition here. The startup script won't ask before overwriting the provided device, destroying '''all''' data on it, ''unless it has a LUKS header'', then it simply won't work.}}<br />
<br />
If you have been following these instructions closely, then in the section "Mapping Partitions" above you put a LUKS header on your swap partition. Erase it with something like the command below, replacing /dev/sda2 with the appropriate swap device:<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
From now on, each time you boot, the partition will be encrypted automatically with a random key, and will then be formated with mkswap.<br />
<br />
Now all you have to do is adjust the corresponding entry in /etc/fstab:<br />
/dev/mapper/swap swap swap defaults 0 0<br />
<br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Encrypted swap with suspend-to-disk support ==<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Storing the key externally (USB stick) ==<br />
=== Preparation for permanent device names ===<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
==== Quick method ====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
=== Generating the keyfile ===<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
=== Storing the keyfile ===<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=118764Dm-crypt2010-10-06T14:22:16Z<p>Vinhsynd: /* Partitioning */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is to simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Installation ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
<code>dd if=/dev/urandom of=/dev/<drive> bs=1M</code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
<code>badblocks -c 10240 -Wsvt random /dev/<drive></code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]] which is suggested reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
<br />
<br />
{{Note|Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrytped in order to load the kernel and boot the system.}}<br />
<br />
<br />
<br />
For instructions on how to use LUKS with standard partitions, see [[System Encryption with LUKS for dm-crypt#Configuring LUKS | Configuring LUKS with Standard Partitions]].<br />
<br />
For instructions on how to use LUKS with LVM Partitions, see [[System Encryption with LUKS for dm-crypt#Encrypting a LVM setup | Encrypting an LVM Setup]].<br />
<br />
== Configuring LUKS with Standard Partitions ==<br />
As noted [[#Overwriting|above]] it's recommended for security reasons to overwrite the partition before going any further.<br />
<br />
=== Mapping partitions ===<br />
==== Passphrase ====<br />
Use this to create a password to unlock your encrypted partions with:<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda3<br />
Enter passphrase: mypassword<br />
Verify passphrase: mypassword<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda5<br />
Enter passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda6<br />
Enter passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup luksOpen /dev/sda3 root<br />
Enter any LUKS passphrase: mypassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup luksOpen /dev/sda5 home<br />
Enter any LUKS passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup luksOpen /dev/sda6 tmp<br />
Enter any LUKS passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
==== Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
==== Explanation ====<br />
Now you should have a device called <tt>/dev/mapper/root</tt>, another one called <tt>/dev/mapper/home</tt> and another one called <tt>/dev/mapper/tmp</tt>. These are block devices like any other, but with a neat twist: whenever you write to them, the data is actually written to <tt>/dev/sda3</tt>, <tt>/dev/sda5</tt> or <tt>/dev/sda6</tt> respectively, but it is encrypted first! The only way to access the data on this encrypted partition is to re-create that <tt>/dev/mapper/root</tt>, <tt>/dev/mapper/home</tt> etc. device with cryptsetup each time you boot. With LUKS, you can use <tt>cryptsetup luksAddKey /dev/sda3</tt> to add a new password or <tt>cryptsetup luksDelKey /dev/sda3</tt> to revoke a password. Type <tt>cryptsetup -?</tt> or <tt>man cryptsetup</tt> (once you've booted your new Arch installation) for more info.<br />
<br />
{{Note | With LUKS, if you enter the wrong password, it will reject it. You don't have to worry about it possibly destroying your data.}}<br />
<br />
{{ Note | You might also want to replace /var/tmp/ with a symbolic link to /tmp.}}<br />
<br />
{{ Note | If you've decided to go for option two for encrypted swap (see Encrypted Swap below), you should set up <tt>/dev/mapper/swap</tt> in a similar way as you've just set up <tt>/dev/mapper/home</tt>. See Encrypted Swap below for details.}}<br />
<br />
=== Installing the system ===<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Encrypting swap partition ==<br />
Sensitive data stored in memory may be written to swap at any time. If you've gone to the trouble of encrypting your root and home partitions, you should encrypt your swap as well. There are two options here: random encryption on each boot (better security), or the same encryption each time. We won't cover the second option here, as it is pretty much identical to how you set up the /home partition above. Just replace all references to home with swap, and sda5 with sda2.<br />
<br />
Arch Linux provides a convenient way for the first option, which uses dm-crypt directly without LUKS. If you're still in the archsetup process, just switch to a different virtual console (ALT+F2). If you've exited already, the new root will have been unmounted. Use <tt>mount /dev/mapper/root /mnt</tt> to mount it again.<br />
<br />
Now add an entry to the cryptsetup file:<br />
# echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
{{ Tip | Recommended hash algorithms are "whirlpool" (patent free), "sha256", "sha384" or "sha512". Default is "ripemd160" (not recommended).}}<br />
<br />
''[why is it not recommended? only RIPEMD (128bit) was hacked RIPEMD-160 is still safe[https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=83310], isn't it? I heard wirlpool is at least twice as slow. ]''<br />
<br />
{{ Warning | Please take extra care to put the right partition here. The startup script won't ask before overwriting the provided device, destroying '''all''' data on it, ''unless it has a LUKS header'', then it simply won't work.}}<br />
<br />
If you have been following these instructions closely, then in the section "Mapping Partitions" above you put a LUKS header on your swap partition. Erase it with something like the command below, replacing /dev/sda2 with the appropriate swap device:<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
From now on, each time you boot, the partition will be encrypted automatically with a random key, and will then be formated with mkswap.<br />
<br />
Now all you have to do is adjust the corresponding entry in /etc/fstab:<br />
/dev/mapper/swap swap swap defaults 0 0<br />
<br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Encrypted swap with suspend-to-disk support ==<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Storing the key externally (USB stick) ==<br />
=== Preparation for permanent device names ===<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
==== Quick method ====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
=== Generating the keyfile ===<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
=== Storing the keyfile ===<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=118763Dm-crypt2010-10-06T14:20:54Z<p>Vinhsynd: /* Partitioning */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is to simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Installation ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
<code>dd if=/dev/urandom of=/dev/<drive> bs=1M</code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
<code>badblocks -c 10240 -Wsvt random /dev/<drive></code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]].<br />
<br />
<br />
<br />
{{Note|Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrytped in order to load the kernel and boot the system.}}<br />
<br />
<br />
<br />
For instructions on how to use LUKS with standard partitions, see [[System Encryption with LUKS for dm-crypt#Configuring LUKS | Configuring LUKS with Standard Partitions]].<br />
<br />
For instructions on how to use LUKS with LVM Partitions, see [[System Encryption with LUKS for dm-crypt#Encrypting a LVM setup | Encrypting an LVM Setup]].<br />
<br />
== Configuring LUKS with Standard Partitions ==<br />
As noted [[#Overwriting|above]] it's recommended for security reasons to overwrite the partition before going any further.<br />
<br />
=== Mapping partitions ===<br />
==== Passphrase ====<br />
Use this to create a password to unlock your encrypted partions with:<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda3<br />
Enter passphrase: mypassword<br />
Verify passphrase: mypassword<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda5<br />
Enter passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda6<br />
Enter passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup luksOpen /dev/sda3 root<br />
Enter any LUKS passphrase: mypassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup luksOpen /dev/sda5 home<br />
Enter any LUKS passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup luksOpen /dev/sda6 tmp<br />
Enter any LUKS passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
==== Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
==== Explanation ====<br />
Now you should have a device called <tt>/dev/mapper/root</tt>, another one called <tt>/dev/mapper/home</tt> and another one called <tt>/dev/mapper/tmp</tt>. These are block devices like any other, but with a neat twist: whenever you write to them, the data is actually written to <tt>/dev/sda3</tt>, <tt>/dev/sda5</tt> or <tt>/dev/sda6</tt> respectively, but it is encrypted first! The only way to access the data on this encrypted partition is to re-create that <tt>/dev/mapper/root</tt>, <tt>/dev/mapper/home</tt> etc. device with cryptsetup each time you boot. With LUKS, you can use <tt>cryptsetup luksAddKey /dev/sda3</tt> to add a new password or <tt>cryptsetup luksDelKey /dev/sda3</tt> to revoke a password. Type <tt>cryptsetup -?</tt> or <tt>man cryptsetup</tt> (once you've booted your new Arch installation) for more info.<br />
<br />
{{Note | With LUKS, if you enter the wrong password, it will reject it. You don't have to worry about it possibly destroying your data.}}<br />
<br />
{{ Note | You might also want to replace /var/tmp/ with a symbolic link to /tmp.}}<br />
<br />
{{ Note | If you've decided to go for option two for encrypted swap (see Encrypted Swap below), you should set up <tt>/dev/mapper/swap</tt> in a similar way as you've just set up <tt>/dev/mapper/home</tt>. See Encrypted Swap below for details.}}<br />
<br />
=== Installing the system ===<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Encrypting swap partition ==<br />
Sensitive data stored in memory may be written to swap at any time. If you've gone to the trouble of encrypting your root and home partitions, you should encrypt your swap as well. There are two options here: random encryption on each boot (better security), or the same encryption each time. We won't cover the second option here, as it is pretty much identical to how you set up the /home partition above. Just replace all references to home with swap, and sda5 with sda2.<br />
<br />
Arch Linux provides a convenient way for the first option, which uses dm-crypt directly without LUKS. If you're still in the archsetup process, just switch to a different virtual console (ALT+F2). If you've exited already, the new root will have been unmounted. Use <tt>mount /dev/mapper/root /mnt</tt> to mount it again.<br />
<br />
Now add an entry to the cryptsetup file:<br />
# echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
{{ Tip | Recommended hash algorithms are "whirlpool" (patent free), "sha256", "sha384" or "sha512". Default is "ripemd160" (not recommended).}}<br />
<br />
''[why is it not recommended? only RIPEMD (128bit) was hacked RIPEMD-160 is still safe[https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=83310], isn't it? I heard wirlpool is at least twice as slow. ]''<br />
<br />
{{ Warning | Please take extra care to put the right partition here. The startup script won't ask before overwriting the provided device, destroying '''all''' data on it, ''unless it has a LUKS header'', then it simply won't work.}}<br />
<br />
If you have been following these instructions closely, then in the section "Mapping Partitions" above you put a LUKS header on your swap partition. Erase it with something like the command below, replacing /dev/sda2 with the appropriate swap device:<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
From now on, each time you boot, the partition will be encrypted automatically with a random key, and will then be formated with mkswap.<br />
<br />
Now all you have to do is adjust the corresponding entry in /etc/fstab:<br />
/dev/mapper/swap swap swap defaults 0 0<br />
<br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Encrypted swap with suspend-to-disk support ==<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Storing the key externally (USB stick) ==<br />
=== Preparation for permanent device names ===<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
==== Quick method ====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
=== Generating the keyfile ===<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
=== Storing the keyfile ===<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=118762Dm-crypt2010-10-06T14:13:47Z<p>Vinhsynd: /* Configuring LUKS */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is to simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Installation ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
<code>dd if=/dev/urandom of=/dev/<drive> bs=1M</code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
<code>badblocks -c 10240 -Wsvt random /dev/<drive></code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]].<br />
<br />
<br />
{{Note|Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrytped in order to load the kernel and boot the system.}}<br />
<br />
<br />
For instructions on how to use LUKS with standard partitions, see [[System Encryption with LUKS for dm-crypt#Configuring LUKS | Configuring LUKS with Standard Partitions]].<br />
<br />
For instructions on how to use LUKS with LVM Partitions, see [[System Encryption with LUKS for dm-crypt#Encrypting a LVM setup | Encrypting an LVM Setup]].<br />
<br />
== Configuring LUKS with Standard Partitions ==<br />
As noted [[#Overwriting|above]] it's recommended for security reasons to overwrite the partition before going any further.<br />
<br />
=== Mapping partitions ===<br />
==== Passphrase ====<br />
Use this to create a password to unlock your encrypted partions with:<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda3<br />
Enter passphrase: mypassword<br />
Verify passphrase: mypassword<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda5<br />
Enter passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda6<br />
Enter passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup luksOpen /dev/sda3 root<br />
Enter any LUKS passphrase: mypassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup luksOpen /dev/sda5 home<br />
Enter any LUKS passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup luksOpen /dev/sda6 tmp<br />
Enter any LUKS passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
==== Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
==== Explanation ====<br />
Now you should have a device called <tt>/dev/mapper/root</tt>, another one called <tt>/dev/mapper/home</tt> and another one called <tt>/dev/mapper/tmp</tt>. These are block devices like any other, but with a neat twist: whenever you write to them, the data is actually written to <tt>/dev/sda3</tt>, <tt>/dev/sda5</tt> or <tt>/dev/sda6</tt> respectively, but it is encrypted first! The only way to access the data on this encrypted partition is to re-create that <tt>/dev/mapper/root</tt>, <tt>/dev/mapper/home</tt> etc. device with cryptsetup each time you boot. With LUKS, you can use <tt>cryptsetup luksAddKey /dev/sda3</tt> to add a new password or <tt>cryptsetup luksDelKey /dev/sda3</tt> to revoke a password. Type <tt>cryptsetup -?</tt> or <tt>man cryptsetup</tt> (once you've booted your new Arch installation) for more info.<br />
<br />
{{Note | With LUKS, if you enter the wrong password, it will reject it. You don't have to worry about it possibly destroying your data.}}<br />
<br />
{{ Note | You might also want to replace /var/tmp/ with a symbolic link to /tmp.}}<br />
<br />
{{ Note | If you've decided to go for option two for encrypted swap (see Encrypted Swap below), you should set up <tt>/dev/mapper/swap</tt> in a similar way as you've just set up <tt>/dev/mapper/home</tt>. See Encrypted Swap below for details.}}<br />
<br />
=== Installing the system ===<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Encrypting swap partition ==<br />
Sensitive data stored in memory may be written to swap at any time. If you've gone to the trouble of encrypting your root and home partitions, you should encrypt your swap as well. There are two options here: random encryption on each boot (better security), or the same encryption each time. We won't cover the second option here, as it is pretty much identical to how you set up the /home partition above. Just replace all references to home with swap, and sda5 with sda2.<br />
<br />
Arch Linux provides a convenient way for the first option, which uses dm-crypt directly without LUKS. If you're still in the archsetup process, just switch to a different virtual console (ALT+F2). If you've exited already, the new root will have been unmounted. Use <tt>mount /dev/mapper/root /mnt</tt> to mount it again.<br />
<br />
Now add an entry to the cryptsetup file:<br />
# echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
{{ Tip | Recommended hash algorithms are "whirlpool" (patent free), "sha256", "sha384" or "sha512". Default is "ripemd160" (not recommended).}}<br />
<br />
''[why is it not recommended? only RIPEMD (128bit) was hacked RIPEMD-160 is still safe[https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=83310], isn't it? I heard wirlpool is at least twice as slow. ]''<br />
<br />
{{ Warning | Please take extra care to put the right partition here. The startup script won't ask before overwriting the provided device, destroying '''all''' data on it, ''unless it has a LUKS header'', then it simply won't work.}}<br />
<br />
If you have been following these instructions closely, then in the section "Mapping Partitions" above you put a LUKS header on your swap partition. Erase it with something like the command below, replacing /dev/sda2 with the appropriate swap device:<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
From now on, each time you boot, the partition will be encrypted automatically with a random key, and will then be formated with mkswap.<br />
<br />
Now all you have to do is adjust the corresponding entry in /etc/fstab:<br />
/dev/mapper/swap swap swap defaults 0 0<br />
<br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Encrypted swap with suspend-to-disk support ==<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Storing the key externally (USB stick) ==<br />
=== Preparation for permanent device names ===<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
==== Quick method ====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
=== Generating the keyfile ===<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
=== Storing the keyfile ===<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=118761Dm-crypt2010-10-06T14:13:01Z<p>Vinhsynd: /* Partitioning */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is to simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Installation ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
<code>dd if=/dev/urandom of=/dev/<drive> bs=1M</code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
<code>badblocks -c 10240 -Wsvt random /dev/<drive></code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]].<br />
<br />
<br />
{{Note|Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrytped in order to load the kernel and boot the system.}}<br />
<br />
<br />
For instructions on how to use LUKS with standard partitions, see [[System Encryption with LUKS for dm-crypt#Configuring LUKS | Configuring LUKS with Standard Partitions]].<br />
<br />
For instructions on how to use LUKS with LVM Partitions, see [[System Encryption with LUKS for dm-crypt#Encrypting a LVM setup | Encrypting an LVM Setup]].<br />
<br />
== Configuring LUKS ==<br />
As noted [[#Overwriting|above]] it's recommended for security reasons to overwrite the partition before going any further.<br />
<br />
=== Mapping partitions ===<br />
==== Passphrase ====<br />
Use this to create a password to unlock your encrypted partions with:<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda3<br />
Enter passphrase: mypassword<br />
Verify passphrase: mypassword<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda5<br />
Enter passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda6<br />
Enter passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup luksOpen /dev/sda3 root<br />
Enter any LUKS passphrase: mypassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup luksOpen /dev/sda5 home<br />
Enter any LUKS passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup luksOpen /dev/sda6 tmp<br />
Enter any LUKS passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
==== Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
==== Explanation ====<br />
Now you should have a device called <tt>/dev/mapper/root</tt>, another one called <tt>/dev/mapper/home</tt> and another one called <tt>/dev/mapper/tmp</tt>. These are block devices like any other, but with a neat twist: whenever you write to them, the data is actually written to <tt>/dev/sda3</tt>, <tt>/dev/sda5</tt> or <tt>/dev/sda6</tt> respectively, but it is encrypted first! The only way to access the data on this encrypted partition is to re-create that <tt>/dev/mapper/root</tt>, <tt>/dev/mapper/home</tt> etc. device with cryptsetup each time you boot. With LUKS, you can use <tt>cryptsetup luksAddKey /dev/sda3</tt> to add a new password or <tt>cryptsetup luksDelKey /dev/sda3</tt> to revoke a password. Type <tt>cryptsetup -?</tt> or <tt>man cryptsetup</tt> (once you've booted your new Arch installation) for more info.<br />
<br />
{{Note | With LUKS, if you enter the wrong password, it will reject it. You don't have to worry about it possibly destroying your data.}}<br />
<br />
{{ Note | You might also want to replace /var/tmp/ with a symbolic link to /tmp.}}<br />
<br />
{{ Note | If you've decided to go for option two for encrypted swap (see Encrypted Swap below), you should set up <tt>/dev/mapper/swap</tt> in a similar way as you've just set up <tt>/dev/mapper/home</tt>. See Encrypted Swap below for details.}}<br />
<br />
=== Installing the system ===<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Encrypting swap partition ==<br />
Sensitive data stored in memory may be written to swap at any time. If you've gone to the trouble of encrypting your root and home partitions, you should encrypt your swap as well. There are two options here: random encryption on each boot (better security), or the same encryption each time. We won't cover the second option here, as it is pretty much identical to how you set up the /home partition above. Just replace all references to home with swap, and sda5 with sda2.<br />
<br />
Arch Linux provides a convenient way for the first option, which uses dm-crypt directly without LUKS. If you're still in the archsetup process, just switch to a different virtual console (ALT+F2). If you've exited already, the new root will have been unmounted. Use <tt>mount /dev/mapper/root /mnt</tt> to mount it again.<br />
<br />
Now add an entry to the cryptsetup file:<br />
# echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
{{ Tip | Recommended hash algorithms are "whirlpool" (patent free), "sha256", "sha384" or "sha512". Default is "ripemd160" (not recommended).}}<br />
<br />
''[why is it not recommended? only RIPEMD (128bit) was hacked RIPEMD-160 is still safe[https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=83310], isn't it? I heard wirlpool is at least twice as slow. ]''<br />
<br />
{{ Warning | Please take extra care to put the right partition here. The startup script won't ask before overwriting the provided device, destroying '''all''' data on it, ''unless it has a LUKS header'', then it simply won't work.}}<br />
<br />
If you have been following these instructions closely, then in the section "Mapping Partitions" above you put a LUKS header on your swap partition. Erase it with something like the command below, replacing /dev/sda2 with the appropriate swap device:<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
From now on, each time you boot, the partition will be encrypted automatically with a random key, and will then be formated with mkswap.<br />
<br />
Now all you have to do is adjust the corresponding entry in /etc/fstab:<br />
/dev/mapper/swap swap swap defaults 0 0<br />
<br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Encrypted swap with suspend-to-disk support ==<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Storing the key externally (USB stick) ==<br />
=== Preparation for permanent device names ===<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
==== Quick method ====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
=== Generating the keyfile ===<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
=== Storing the keyfile ===<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=118760Dm-crypt2010-10-06T14:12:28Z<p>Vinhsynd: /* Further tweaks for USB keyfile authentication */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is to simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Installation ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
<code>dd if=/dev/urandom of=/dev/<drive> bs=1M</code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
<code>badblocks -c 10240 -Wsvt random /dev/<drive></code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]].<br />
<br />
<br />
{{Note|Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrytped in order to load the kernel and boot the system.}}<br />
<br />
<br />
For instructions on how to use LUKS with standard partitions, see [[System Encryption with LUKS for dm-crypt#Configuring LUKS | Configuring LUKS with Standard Partitions]].<br />
<br />
For instructions on how to use LUKS with LVM Partitions, see [[System Encryption with LUKS for dm-crypt#Encrypting a LVM setup | Encrypting a LVM Setup]].<br />
<br />
== Configuring LUKS ==<br />
As noted [[#Overwriting|above]] it's recommended for security reasons to overwrite the partition before going any further.<br />
<br />
=== Mapping partitions ===<br />
==== Passphrase ====<br />
Use this to create a password to unlock your encrypted partions with:<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda3<br />
Enter passphrase: mypassword<br />
Verify passphrase: mypassword<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda5<br />
Enter passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda6<br />
Enter passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup luksOpen /dev/sda3 root<br />
Enter any LUKS passphrase: mypassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup luksOpen /dev/sda5 home<br />
Enter any LUKS passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup luksOpen /dev/sda6 tmp<br />
Enter any LUKS passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
==== Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
==== Explanation ====<br />
Now you should have a device called <tt>/dev/mapper/root</tt>, another one called <tt>/dev/mapper/home</tt> and another one called <tt>/dev/mapper/tmp</tt>. These are block devices like any other, but with a neat twist: whenever you write to them, the data is actually written to <tt>/dev/sda3</tt>, <tt>/dev/sda5</tt> or <tt>/dev/sda6</tt> respectively, but it is encrypted first! The only way to access the data on this encrypted partition is to re-create that <tt>/dev/mapper/root</tt>, <tt>/dev/mapper/home</tt> etc. device with cryptsetup each time you boot. With LUKS, you can use <tt>cryptsetup luksAddKey /dev/sda3</tt> to add a new password or <tt>cryptsetup luksDelKey /dev/sda3</tt> to revoke a password. Type <tt>cryptsetup -?</tt> or <tt>man cryptsetup</tt> (once you've booted your new Arch installation) for more info.<br />
<br />
{{Note | With LUKS, if you enter the wrong password, it will reject it. You don't have to worry about it possibly destroying your data.}}<br />
<br />
{{ Note | You might also want to replace /var/tmp/ with a symbolic link to /tmp.}}<br />
<br />
{{ Note | If you've decided to go for option two for encrypted swap (see Encrypted Swap below), you should set up <tt>/dev/mapper/swap</tt> in a similar way as you've just set up <tt>/dev/mapper/home</tt>. See Encrypted Swap below for details.}}<br />
<br />
=== Installing the system ===<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Encrypting swap partition ==<br />
Sensitive data stored in memory may be written to swap at any time. If you've gone to the trouble of encrypting your root and home partitions, you should encrypt your swap as well. There are two options here: random encryption on each boot (better security), or the same encryption each time. We won't cover the second option here, as it is pretty much identical to how you set up the /home partition above. Just replace all references to home with swap, and sda5 with sda2.<br />
<br />
Arch Linux provides a convenient way for the first option, which uses dm-crypt directly without LUKS. If you're still in the archsetup process, just switch to a different virtual console (ALT+F2). If you've exited already, the new root will have been unmounted. Use <tt>mount /dev/mapper/root /mnt</tt> to mount it again.<br />
<br />
Now add an entry to the cryptsetup file:<br />
# echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
{{ Tip | Recommended hash algorithms are "whirlpool" (patent free), "sha256", "sha384" or "sha512". Default is "ripemd160" (not recommended).}}<br />
<br />
''[why is it not recommended? only RIPEMD (128bit) was hacked RIPEMD-160 is still safe[https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=83310], isn't it? I heard wirlpool is at least twice as slow. ]''<br />
<br />
{{ Warning | Please take extra care to put the right partition here. The startup script won't ask before overwriting the provided device, destroying '''all''' data on it, ''unless it has a LUKS header'', then it simply won't work.}}<br />
<br />
If you have been following these instructions closely, then in the section "Mapping Partitions" above you put a LUKS header on your swap partition. Erase it with something like the command below, replacing /dev/sda2 with the appropriate swap device:<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
From now on, each time you boot, the partition will be encrypted automatically with a random key, and will then be formated with mkswap.<br />
<br />
Now all you have to do is adjust the corresponding entry in /etc/fstab:<br />
/dev/mapper/swap swap swap defaults 0 0<br />
<br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Encrypted swap with suspend-to-disk support ==<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Storing the key externally (USB stick) ==<br />
=== Preparation for permanent device names ===<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
==== Quick method ====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
=== Generating the keyfile ===<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
=== Storing the keyfile ===<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=118759Dm-crypt2010-10-06T14:12:11Z<p>Vinhsynd: /* Set System Configuration */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is to simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Installation ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
<code>dd if=/dev/urandom of=/dev/<drive> bs=1M</code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
<code>badblocks -c 10240 -Wsvt random /dev/<drive></code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]].<br />
<br />
<br />
{{Note|Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrytped in order to load the kernel and boot the system.}}<br />
<br />
<br />
For instructions on how to use LUKS with standard partitions, see [[System Encryption with LUKS for dm-crypt#Configuring LUKS | Configuring LUKS with Standard Partitions]].<br />
<br />
For instructions on how to use LUKS with LVM Partitions, see [[System Encryption with LUKS for dm-crypt#Encrypting a LVM setup | Encrypting a LVM Setup]].<br />
<br />
=== Further tweaks for USB keyfile authentication ===<br />
When you're planning to use a keyfile on an USB stick instead of passphrase authentication you have to do some further tweaks in <tt>mkinitcpio.conf</tt>:<br />
To mount the USB device with your keyfile in the boot process add ''usb'' somewhere before ''encrypt'' in the HOOKS variable e.g.<br />
HOOKS=" ... sata '''usb''' usbinput keymap encrypt filesystems ... "<br />
And for a FAT formated USB stick add the following to the MODULES variable<br />
MODULES=" ... '''nls_cp437 vfat''' ... "<br />
<br />
After exiting the installer you can now create a keyfile onto USB stick your for authentication.<br />
This is for example done with the following commands. Check out section [[#Generating the keyfile|Generating the keyfile]] for further details.<br />
<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile<br />
<br />
== Configuring LUKS ==<br />
As noted [[#Overwriting|above]] it's recommended for security reasons to overwrite the partition before going any further.<br />
<br />
=== Mapping partitions ===<br />
==== Passphrase ====<br />
Use this to create a password to unlock your encrypted partions with:<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda3<br />
Enter passphrase: mypassword<br />
Verify passphrase: mypassword<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda5<br />
Enter passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda6<br />
Enter passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup luksOpen /dev/sda3 root<br />
Enter any LUKS passphrase: mypassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup luksOpen /dev/sda5 home<br />
Enter any LUKS passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup luksOpen /dev/sda6 tmp<br />
Enter any LUKS passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
==== Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
==== Explanation ====<br />
Now you should have a device called <tt>/dev/mapper/root</tt>, another one called <tt>/dev/mapper/home</tt> and another one called <tt>/dev/mapper/tmp</tt>. These are block devices like any other, but with a neat twist: whenever you write to them, the data is actually written to <tt>/dev/sda3</tt>, <tt>/dev/sda5</tt> or <tt>/dev/sda6</tt> respectively, but it is encrypted first! The only way to access the data on this encrypted partition is to re-create that <tt>/dev/mapper/root</tt>, <tt>/dev/mapper/home</tt> etc. device with cryptsetup each time you boot. With LUKS, you can use <tt>cryptsetup luksAddKey /dev/sda3</tt> to add a new password or <tt>cryptsetup luksDelKey /dev/sda3</tt> to revoke a password. Type <tt>cryptsetup -?</tt> or <tt>man cryptsetup</tt> (once you've booted your new Arch installation) for more info.<br />
<br />
{{Note | With LUKS, if you enter the wrong password, it will reject it. You don't have to worry about it possibly destroying your data.}}<br />
<br />
{{ Note | You might also want to replace /var/tmp/ with a symbolic link to /tmp.}}<br />
<br />
{{ Note | If you've decided to go for option two for encrypted swap (see Encrypted Swap below), you should set up <tt>/dev/mapper/swap</tt> in a similar way as you've just set up <tt>/dev/mapper/home</tt>. See Encrypted Swap below for details.}}<br />
<br />
=== Installing the system ===<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Encrypting swap partition ==<br />
Sensitive data stored in memory may be written to swap at any time. If you've gone to the trouble of encrypting your root and home partitions, you should encrypt your swap as well. There are two options here: random encryption on each boot (better security), or the same encryption each time. We won't cover the second option here, as it is pretty much identical to how you set up the /home partition above. Just replace all references to home with swap, and sda5 with sda2.<br />
<br />
Arch Linux provides a convenient way for the first option, which uses dm-crypt directly without LUKS. If you're still in the archsetup process, just switch to a different virtual console (ALT+F2). If you've exited already, the new root will have been unmounted. Use <tt>mount /dev/mapper/root /mnt</tt> to mount it again.<br />
<br />
Now add an entry to the cryptsetup file:<br />
# echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
{{ Tip | Recommended hash algorithms are "whirlpool" (patent free), "sha256", "sha384" or "sha512". Default is "ripemd160" (not recommended).}}<br />
<br />
''[why is it not recommended? only RIPEMD (128bit) was hacked RIPEMD-160 is still safe[https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=83310], isn't it? I heard wirlpool is at least twice as slow. ]''<br />
<br />
{{ Warning | Please take extra care to put the right partition here. The startup script won't ask before overwriting the provided device, destroying '''all''' data on it, ''unless it has a LUKS header'', then it simply won't work.}}<br />
<br />
If you have been following these instructions closely, then in the section "Mapping Partitions" above you put a LUKS header on your swap partition. Erase it with something like the command below, replacing /dev/sda2 with the appropriate swap device:<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
From now on, each time you boot, the partition will be encrypted automatically with a random key, and will then be formated with mkswap.<br />
<br />
Now all you have to do is adjust the corresponding entry in /etc/fstab:<br />
/dev/mapper/swap swap swap defaults 0 0<br />
<br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Encrypted swap with suspend-to-disk support ==<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Storing the key externally (USB stick) ==<br />
=== Preparation for permanent device names ===<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
==== Quick method ====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
=== Generating the keyfile ===<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
=== Storing the keyfile ===<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=118758Dm-crypt2010-10-06T14:11:18Z<p>Vinhsynd: /* Partition and Set Encryption */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is to simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Installation ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
<code>dd if=/dev/urandom of=/dev/<drive> bs=1M</code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
<code>badblocks -c 10240 -Wsvt random /dev/<drive></code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*LVM<br />
::*RAID<br />
<br />
LUKS is compatible in systems that require both LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
'''Standard Partitions'''<br />
<br />
These are the partitions that most people are familiar with. They come in 3 flavors, primary partitions, extended partitions, and logical partitions.<br />
<br />
::*Primary Partitions: These are the main partitions recognized by a BIOS. There can be up to 4 of these stored in the MBR.<br />
<br />
::*Extended Partitions: These are primary partitions that also define another partition within themselves they were created to supersede the original 4 partition limit of primary partitions.<br />
<br />
::*Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
<br />
'''LVM: Linux Volume Manager'''<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple harddisk drives and partitions that are not possible with standard partitions. The LVM is covered in detail in the [[LVM | Arch LVM Wiki Page]].<br />
<br />
<br />
{{Note|Irrespective of what partitioning method chosen, the /boot partition must remain separate and unencrytped in order to load the kernel and boot the system.}}<br />
<br />
<br />
For instructions on how to use LUKS with standard partitions, see [[System Encryption with LUKS for dm-crypt#Configuring LUKS | Configuring LUKS with Standard Partitions]].<br />
<br />
For instructions on how to use LUKS with LVM Partitions, see [[System Encryption with LUKS for dm-crypt#Encrypting a LVM setup | Encrypting a LVM Setup]].<br />
<br />
=== Set System Configuration ===<br />
You may configure your system normally, except for a few small changes:<br />
* In <code>/etc/mkinitcpio.conf</code>, add ''encrypt'' to the <code>Hooks=</code>. Make sure it is before <code>lvm2</code> and <code>filesystems</code>. Like this:<br />
HOOKS="base udev autodetect pata scsi sata encrypt lvm2 filesystems"<br />
* In [[GRUB]], <code>/boot/grub/menu.lst</code>, add ''cryptdevice=/dev/sda2:vgroup'' between ''root'' and ''ro'' for both Arch Linux and Arch Linux Fallback.<br />
<br />
=== Further tweaks for USB keyfile authentication ===<br />
When you're planning to use a keyfile on an USB stick instead of passphrase authentication you have to do some further tweaks in <tt>mkinitcpio.conf</tt>:<br />
To mount the USB device with your keyfile in the boot process add ''usb'' somewhere before ''encrypt'' in the HOOKS variable e.g.<br />
HOOKS=" ... sata '''usb''' usbinput keymap encrypt filesystems ... "<br />
And for a FAT formated USB stick add the following to the MODULES variable<br />
MODULES=" ... '''nls_cp437 vfat''' ... "<br />
<br />
After exiting the installer you can now create a keyfile onto USB stick your for authentication.<br />
This is for example done with the following commands. Check out section [[#Generating the keyfile|Generating the keyfile]] for further details.<br />
<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile<br />
<br />
== Configuring LUKS ==<br />
As noted [[#Overwriting|above]] it's recommended for security reasons to overwrite the partition before going any further.<br />
<br />
=== Mapping partitions ===<br />
==== Passphrase ====<br />
Use this to create a password to unlock your encrypted partions with:<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda3<br />
Enter passphrase: mypassword<br />
Verify passphrase: mypassword<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda5<br />
Enter passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda6<br />
Enter passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup luksOpen /dev/sda3 root<br />
Enter any LUKS passphrase: mypassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup luksOpen /dev/sda5 home<br />
Enter any LUKS passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup luksOpen /dev/sda6 tmp<br />
Enter any LUKS passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
==== Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
==== Explanation ====<br />
Now you should have a device called <tt>/dev/mapper/root</tt>, another one called <tt>/dev/mapper/home</tt> and another one called <tt>/dev/mapper/tmp</tt>. These are block devices like any other, but with a neat twist: whenever you write to them, the data is actually written to <tt>/dev/sda3</tt>, <tt>/dev/sda5</tt> or <tt>/dev/sda6</tt> respectively, but it is encrypted first! The only way to access the data on this encrypted partition is to re-create that <tt>/dev/mapper/root</tt>, <tt>/dev/mapper/home</tt> etc. device with cryptsetup each time you boot. With LUKS, you can use <tt>cryptsetup luksAddKey /dev/sda3</tt> to add a new password or <tt>cryptsetup luksDelKey /dev/sda3</tt> to revoke a password. Type <tt>cryptsetup -?</tt> or <tt>man cryptsetup</tt> (once you've booted your new Arch installation) for more info.<br />
<br />
{{Note | With LUKS, if you enter the wrong password, it will reject it. You don't have to worry about it possibly destroying your data.}}<br />
<br />
{{ Note | You might also want to replace /var/tmp/ with a symbolic link to /tmp.}}<br />
<br />
{{ Note | If you've decided to go for option two for encrypted swap (see Encrypted Swap below), you should set up <tt>/dev/mapper/swap</tt> in a similar way as you've just set up <tt>/dev/mapper/home</tt>. See Encrypted Swap below for details.}}<br />
<br />
=== Installing the system ===<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Encrypting swap partition ==<br />
Sensitive data stored in memory may be written to swap at any time. If you've gone to the trouble of encrypting your root and home partitions, you should encrypt your swap as well. There are two options here: random encryption on each boot (better security), or the same encryption each time. We won't cover the second option here, as it is pretty much identical to how you set up the /home partition above. Just replace all references to home with swap, and sda5 with sda2.<br />
<br />
Arch Linux provides a convenient way for the first option, which uses dm-crypt directly without LUKS. If you're still in the archsetup process, just switch to a different virtual console (ALT+F2). If you've exited already, the new root will have been unmounted. Use <tt>mount /dev/mapper/root /mnt</tt> to mount it again.<br />
<br />
Now add an entry to the cryptsetup file:<br />
# echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
{{ Tip | Recommended hash algorithms are "whirlpool" (patent free), "sha256", "sha384" or "sha512". Default is "ripemd160" (not recommended).}}<br />
<br />
''[why is it not recommended? only RIPEMD (128bit) was hacked RIPEMD-160 is still safe[https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=83310], isn't it? I heard wirlpool is at least twice as slow. ]''<br />
<br />
{{ Warning | Please take extra care to put the right partition here. The startup script won't ask before overwriting the provided device, destroying '''all''' data on it, ''unless it has a LUKS header'', then it simply won't work.}}<br />
<br />
If you have been following these instructions closely, then in the section "Mapping Partitions" above you put a LUKS header on your swap partition. Erase it with something like the command below, replacing /dev/sda2 with the appropriate swap device:<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
From now on, each time you boot, the partition will be encrypted automatically with a random key, and will then be formated with mkswap.<br />
<br />
Now all you have to do is adjust the corresponding entry in /etc/fstab:<br />
/dev/mapper/swap swap swap defaults 0 0<br />
<br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Encrypted swap with suspend-to-disk support ==<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Storing the key externally (USB stick) ==<br />
=== Preparation for permanent device names ===<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
==== Quick method ====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
=== Generating the keyfile ===<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
=== Storing the keyfile ===<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=118711Dm-crypt2010-10-05T16:48:38Z<p>Vinhsynd: /* Securely Erase Hard Drive */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is to simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Installation ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Harddisk Drive ===<br />
<br />
Secure erasure of the harddisk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a harddisk drive multiple times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
<br />
'''Why perform secure of erasure of a drive?'''<br />
<br />
There are two types of harddisk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Harddisk Drives'''<br />
<br />
::In harddrives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Harddisk Drives'''<br />
<br />
::Repartitioning or reformatting a used harddrive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straight forward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore harddrives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
<br />
<br />
'''Overwriting a harddisk drive with random data.'''<br />
<br />
There are two sources of random data commonly used for securely overwritting harddisk partitions.<br />
<br />
::*urandom<br />
::*badblocks<br />
<br />
<br />
'''Using urandom'''<br />
<br />
<code>dd if=/dev/urandom of=/dev/<drive> bs=1M</code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note| Using ''/dev/urandom'' will take a long time to completely overwrite a drive with "random" data. In the strictest sense ''/dev/urandom'' is less random than ''/dev/random'' however ''/dev/random'' uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of ''/dev/random'' for overwriting harddisks impractical.}}<br />
<br />
<br />
'''Using badblocks'''<br />
<br />
<code>badblocks -c 10240 -Wsvt random /dev/<drive></code><br />
<br />
Where <code>/dev/<drive></code> is the drive to be encrypted.<br />
<br />
{{Note|The ''badblocks'' overwrites the drive at a much faster rate by generating data that is not truely random.}}<br />
<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a harddisk drive remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=== Partition and Set Encryption ===<br />
Once the drive has been randomized, set up your partitions however you like. If do not plan on using [[LVM]], then read below; if you do want to use [[LVM]], see [[System Encryption with LUKS for dm-crypt#Encrypting a LVM setup | Encrypting a LVM Setup]].<br />
<br />
{{ Warning | Make sure you have a separate unencrypted partition for /boot. If boot is encrypted then you cannot load the kernel.}}<br />
<br />
Once you have finished partitioning, start up the Arch installer. Once you read the ''prepare hard drive'' section, choose ''Manually configure block devices, filesystems and mountpoints''. Set up your partitions as you normally would, but for any partition that you wish to be encrypted, choose <code>dm_crypt</code> in the filesystem dialogue. Once this is done, you'll notice that <code>/dev/mapper/</code> entries have appeared for each of your partitions. Format these as you would your normal partitions. Finally, press 'Done'.<br />
<br />
When you press 'DONE' the installer will create and mount the filesystem configuration automatically. You will be prompted for a LUKS passphrase 3 times (2x to set a new passphrase, 1x to unlock the device).<br />
<br />
You may now select packages and install the system as normal.<br />
<br />
=== Set System Configuration ===<br />
You may configure your system normally, except for a few small changes:<br />
* In <code>/etc/mkinitcpio.conf</code>, add ''encrypt'' to the <code>Hooks=</code>. Make sure it is before <code>lvm2</code> and <code>filesystems</code>. Like this:<br />
HOOKS="base udev autodetect pata scsi sata encrypt lvm2 filesystems"<br />
* In [[GRUB]], <code>/boot/grub/menu.lst</code>, add ''cryptdevice=/dev/sda2:vgroup'' between ''root'' and ''ro'' for both Arch Linux and Arch Linux Fallback.<br />
<br />
=== Further tweaks for USB keyfile authentication ===<br />
When you're planning to use a keyfile on an USB stick instead of passphrase authentication you have to do some further tweaks in <tt>mkinitcpio.conf</tt>:<br />
To mount the USB device with your keyfile in the boot process add ''usb'' somewhere before ''encrypt'' in the HOOKS variable e.g.<br />
HOOKS=" ... sata '''usb''' usbinput keymap encrypt filesystems ... "<br />
And for a FAT formated USB stick add the following to the MODULES variable<br />
MODULES=" ... '''nls_cp437 vfat''' ... "<br />
<br />
After exiting the installer you can now create a keyfile onto USB stick your for authentication.<br />
This is for example done with the following commands. Check out section [[#Generating the keyfile|Generating the keyfile]] for further details.<br />
<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile<br />
<br />
== Configuring LUKS ==<br />
As noted [[#Overwriting|above]] it's recommended for security reasons to overwrite the partition before going any further.<br />
<br />
=== Mapping partitions ===<br />
==== Passphrase ====<br />
Use this to create a password to unlock your encrypted partions with:<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda3<br />
Enter passphrase: mypassword<br />
Verify passphrase: mypassword<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda5<br />
Enter passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda6<br />
Enter passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup luksOpen /dev/sda3 root<br />
Enter any LUKS passphrase: mypassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup luksOpen /dev/sda5 home<br />
Enter any LUKS passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup luksOpen /dev/sda6 tmp<br />
Enter any LUKS passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
==== Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
==== Explanation ====<br />
Now you should have a device called <tt>/dev/mapper/root</tt>, another one called <tt>/dev/mapper/home</tt> and another one called <tt>/dev/mapper/tmp</tt>. These are block devices like any other, but with a neat twist: whenever you write to them, the data is actually written to <tt>/dev/sda3</tt>, <tt>/dev/sda5</tt> or <tt>/dev/sda6</tt> respectively, but it is encrypted first! The only way to access the data on this encrypted partition is to re-create that <tt>/dev/mapper/root</tt>, <tt>/dev/mapper/home</tt> etc. device with cryptsetup each time you boot. With LUKS, you can use <tt>cryptsetup luksAddKey /dev/sda3</tt> to add a new password or <tt>cryptsetup luksDelKey /dev/sda3</tt> to revoke a password. Type <tt>cryptsetup -?</tt> or <tt>man cryptsetup</tt> (once you've booted your new Arch installation) for more info.<br />
<br />
{{Note | With LUKS, if you enter the wrong password, it will reject it. You don't have to worry about it possibly destroying your data.}}<br />
<br />
{{ Note | You might also want to replace /var/tmp/ with a symbolic link to /tmp.}}<br />
<br />
{{ Note | If you've decided to go for option two for encrypted swap (see Encrypted Swap below), you should set up <tt>/dev/mapper/swap</tt> in a similar way as you've just set up <tt>/dev/mapper/home</tt>. See Encrypted Swap below for details.}}<br />
<br />
=== Installing the system ===<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Encrypting swap partition ==<br />
Sensitive data stored in memory may be written to swap at any time. If you've gone to the trouble of encrypting your root and home partitions, you should encrypt your swap as well. There are two options here: random encryption on each boot (better security), or the same encryption each time. We won't cover the second option here, as it is pretty much identical to how you set up the /home partition above. Just replace all references to home with swap, and sda5 with sda2.<br />
<br />
Arch Linux provides a convenient way for the first option, which uses dm-crypt directly without LUKS. If you're still in the archsetup process, just switch to a different virtual console (ALT+F2). If you've exited already, the new root will have been unmounted. Use <tt>mount /dev/mapper/root /mnt</tt> to mount it again.<br />
<br />
Now add an entry to the cryptsetup file:<br />
# echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
{{ Tip | Recommended hash algorithms are "whirlpool" (patent free), "sha256", "sha384" or "sha512". Default is "ripemd160" (not recommended).}}<br />
<br />
''[why is it not recommended? only RIPEMD (128bit) was hacked RIPEMD-160 is still safe[https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=83310], isn't it? I heard wirlpool is at least twice as slow. ]''<br />
<br />
{{ Warning | Please take extra care to put the right partition here. The startup script won't ask before overwriting the provided device, destroying '''all''' data on it, ''unless it has a LUKS header'', then it simply won't work.}}<br />
<br />
If you have been following these instructions closely, then in the section "Mapping Partitions" above you put a LUKS header on your swap partition. Erase it with something like the command below, replacing /dev/sda2 with the appropriate swap device:<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
From now on, each time you boot, the partition will be encrypted automatically with a random key, and will then be formated with mkswap.<br />
<br />
Now all you have to do is adjust the corresponding entry in /etc/fstab:<br />
/dev/mapper/swap swap swap defaults 0 0<br />
<br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Encrypted swap with suspend-to-disk support ==<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Storing the key externally (USB stick) ==<br />
=== Preparation for permanent device names ===<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
==== Quick method ====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
=== Generating the keyfile ===<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
=== Storing the keyfile ===<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=118704Dm-crypt2010-10-05T14:32:44Z<p>Vinhsynd: /* Overview and Preparation */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is to simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Installation ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Securely Erase Hard Drive ===<br />
Repartitioning and formatting your drive will only remove the filesystem metadata and will mostly leave the actual data intact, allowing determined attackers to recover your data using tools like [http://foremost.sourceforge.net/ Foremost]. If your harddisk contained sensitive data from previous use, you might want to overwrite that data. <br />
<br />
{{ Tip | Overwriting your data multiple times or overwriting old files with random data serves no purpose; the original data cannot be recovered once it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/]}}<br />
<br />
While overwriting existing data won't provide you extra protection, if your disk is empty (or otherwise written with 0s), then it can help to fill the disk with random data before partitioning. This helps prevent attackers from seeing your disk layout, which may expose vulnerabilities. To fill your disk with random data use:<br />
# dd if=/dev/urandom of=/dev/<drive> bs=1M<br />
<br />
Where <code>/dev/<drive></code> is the encrypted drive.<br />
{{ Note | The above <code>dd</code> command will take hours. However, you will only every have to do it once. If you have multiple computers, you can have them help to speed up the process by using the '''ncat''' command. [http://en.gentoo-wiki.com/wiki/DM-Crypt_with_LUKS#Filling_the_disk_with_random_data This how-to] explains how to do that.}}<br />
<br />
Using <code>/dev/urandom</code> can take a long time because the CPU must generate the random data from a limited set of entropy. The <code>badblocks</code> command is capable of achieving essentially the same goal as using <code>/dev/urandom</code>, but at a much faster rate by generating data that is not truly random. The following command will be enough to securely erase your drive, albeit at a much faster rate:<br />
# badblocks -c 10240 -s -w -v -t random /dev/<drive><br />
<br />
=== Partition and Set Encryption ===<br />
Once the drive has been randomized, set up your partitions however you like. If do not plan on using [[LVM]], then read below; if you do want to use [[LVM]], see [[System Encryption with LUKS for dm-crypt#Encrypting a LVM setup | Encrypting a LVM Setup]].<br />
<br />
{{ Warning | Make sure you have a separate unencrypted partition for /boot. If boot is encrypted then you cannot load the kernel.}}<br />
<br />
Once you have finished partitioning, start up the Arch installer. Once you read the ''prepare hard drive'' section, choose ''Manually configure block devices, filesystems and mountpoints''. Set up your partitions as you normally would, but for any partition that you wish to be encrypted, choose <code>dm_crypt</code> in the filesystem dialogue. Once this is done, you'll notice that <code>/dev/mapper/</code> entries have appeared for each of your partitions. Format these as you would your normal partitions. Finally, press 'Done'.<br />
<br />
When you press 'DONE' the installer will create and mount the filesystem configuration automatically. You will be prompted for a LUKS passphrase 3 times (2x to set a new passphrase, 1x to unlock the device).<br />
<br />
You may now select packages and install the system as normal.<br />
<br />
=== Set System Configuration ===<br />
You may configure your system normally, except for a few small changes:<br />
* In <code>/etc/mkinitcpio.conf</code>, add ''encrypt'' to the <code>Hooks=</code>. Make sure it is before <code>lvm2</code> and <code>filesystems</code>. Like this:<br />
HOOKS="base udev autodetect pata scsi sata encrypt lvm2 filesystems"<br />
* In [[GRUB]], <code>/boot/grub/menu.lst</code>, add ''cryptdevice=/dev/sda2:vgroup'' between ''root'' and ''ro'' for both Arch Linux and Arch Linux Fallback.<br />
<br />
=== Further tweaks for USB keyfile authentication ===<br />
When you're planning to use a keyfile on an USB stick instead of passphrase authentication you have to do some further tweaks in <tt>mkinitcpio.conf</tt>:<br />
To mount the USB device with your keyfile in the boot process add ''usb'' somewhere before ''encrypt'' in the HOOKS variable e.g.<br />
HOOKS=" ... sata '''usb''' usbinput keymap encrypt filesystems ... "<br />
And for a FAT formated USB stick add the following to the MODULES variable<br />
MODULES=" ... '''nls_cp437 vfat''' ... "<br />
<br />
After exiting the installer you can now create a keyfile onto USB stick your for authentication.<br />
This is for example done with the following commands. Check out section [[#Generating the keyfile|Generating the keyfile]] for further details.<br />
<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile<br />
<br />
== Configuring LUKS ==<br />
As noted [[#Overwriting|above]] it's recommended for security reasons to overwrite the partition before going any further.<br />
<br />
=== Mapping partitions ===<br />
==== Passphrase ====<br />
Use this to create a password to unlock your encrypted partions with:<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda3<br />
Enter passphrase: mypassword<br />
Verify passphrase: mypassword<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda5<br />
Enter passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda6<br />
Enter passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup luksOpen /dev/sda3 root<br />
Enter any LUKS passphrase: mypassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup luksOpen /dev/sda5 home<br />
Enter any LUKS passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup luksOpen /dev/sda6 tmp<br />
Enter any LUKS passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
==== Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
==== Explanation ====<br />
Now you should have a device called <tt>/dev/mapper/root</tt>, another one called <tt>/dev/mapper/home</tt> and another one called <tt>/dev/mapper/tmp</tt>. These are block devices like any other, but with a neat twist: whenever you write to them, the data is actually written to <tt>/dev/sda3</tt>, <tt>/dev/sda5</tt> or <tt>/dev/sda6</tt> respectively, but it is encrypted first! The only way to access the data on this encrypted partition is to re-create that <tt>/dev/mapper/root</tt>, <tt>/dev/mapper/home</tt> etc. device with cryptsetup each time you boot. With LUKS, you can use <tt>cryptsetup luksAddKey /dev/sda3</tt> to add a new password or <tt>cryptsetup luksDelKey /dev/sda3</tt> to revoke a password. Type <tt>cryptsetup -?</tt> or <tt>man cryptsetup</tt> (once you've booted your new Arch installation) for more info.<br />
<br />
{{Note | With LUKS, if you enter the wrong password, it will reject it. You don't have to worry about it possibly destroying your data.}}<br />
<br />
{{ Note | You might also want to replace /var/tmp/ with a symbolic link to /tmp.}}<br />
<br />
{{ Note | If you've decided to go for option two for encrypted swap (see Encrypted Swap below), you should set up <tt>/dev/mapper/swap</tt> in a similar way as you've just set up <tt>/dev/mapper/home</tt>. See Encrypted Swap below for details.}}<br />
<br />
=== Installing the system ===<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Encrypting swap partition ==<br />
Sensitive data stored in memory may be written to swap at any time. If you've gone to the trouble of encrypting your root and home partitions, you should encrypt your swap as well. There are two options here: random encryption on each boot (better security), or the same encryption each time. We won't cover the second option here, as it is pretty much identical to how you set up the /home partition above. Just replace all references to home with swap, and sda5 with sda2.<br />
<br />
Arch Linux provides a convenient way for the first option, which uses dm-crypt directly without LUKS. If you're still in the archsetup process, just switch to a different virtual console (ALT+F2). If you've exited already, the new root will have been unmounted. Use <tt>mount /dev/mapper/root /mnt</tt> to mount it again.<br />
<br />
Now add an entry to the cryptsetup file:<br />
# echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
{{ Tip | Recommended hash algorithms are "whirlpool" (patent free), "sha256", "sha384" or "sha512". Default is "ripemd160" (not recommended).}}<br />
<br />
''[why is it not recommended? only RIPEMD (128bit) was hacked RIPEMD-160 is still safe[https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=83310], isn't it? I heard wirlpool is at least twice as slow. ]''<br />
<br />
{{ Warning | Please take extra care to put the right partition here. The startup script won't ask before overwriting the provided device, destroying '''all''' data on it, ''unless it has a LUKS header'', then it simply won't work.}}<br />
<br />
If you have been following these instructions closely, then in the section "Mapping Partitions" above you put a LUKS header on your swap partition. Erase it with something like the command below, replacing /dev/sda2 with the appropriate swap device:<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
From now on, each time you boot, the partition will be encrypted automatically with a random key, and will then be formated with mkswap.<br />
<br />
Now all you have to do is adjust the corresponding entry in /etc/fstab:<br />
/dev/mapper/swap swap swap defaults 0 0<br />
<br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Encrypted swap with suspend-to-disk support ==<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Storing the key externally (USB stick) ==<br />
=== Preparation for permanent device names ===<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
==== Quick method ====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
=== Generating the keyfile ===<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
=== Storing the keyfile ===<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsyndhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=118703Dm-crypt2010-10-05T14:32:07Z<p>Vinhsynd: /* Overview and Preparation */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|System Encryption with LUKS for dm-crypt}}<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
<br />
::*Preventing unauthorized physical access to private data.<br />
::*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive. Thus reducing the effectiveness of any data encryption system in place.<br />
<br />
<br />
<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
<br />
::*Preventing unauthorized physical access to operating system files<br />
::*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
<br />
::*Attempts to bypass the operating system by inserting a boot CD/USB<br />
::*Copying, modifying, or removing the harddisk drives when the computer is off<br />
<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the /boot partition which must remain unencrypted in order for the machine to properly boot. However system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
<br />
{{Warning | Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What methods are avaliable for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption including:<br />
<br />
<br />
'''loop-AES''' ([http://loop-aes.sourceforge.net/ loop-AES])<br />
<br />
::loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
::However loop-AES is considered less user friendly than other options as it requires non-standard kernel support.<br />
<br />
<br />
'''standard device-mapper encryption''' ([http://www.saout.de/misc/dm-crypt/ dm-crypt])<br />
<br />
::This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
<br />
'''LUKS for dm-crypt''' ([http://code.google.com/p/cryptsetup/ LUKS home page])<br />
<br />
::LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
::Briefly some key features that LUKS provides include:<br />
<br />
:::*Support for either passphrase or keyfiles as encryption keys<br />
:::*Per partition key creation and revocation<br />
:::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key<br />
::*The usage of a proven encryption algorithm<br />
<br />
<br />
'''Key Complexity and Availability'''<br />
<br />
The user provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is to simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
<br />
'''Encryption Algorithm'''<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shutdown. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them extract your encryption key - thus obtaining access to your data.<br />
<br />
<br />
{{Note|System Encryption assume encryption of all mounted partitions this includes all partitions except for /boot - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, tmp, or root filesystems are unencrypted only Data Encryption level of security has been accomplished.}}<br />
<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
<br />
'''Encryption of data partitions on the same physical disk as the system.'''<br />
<br />
The most common form of data encryption is encrypting the /home partition.<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decrease by orders of magnitude when compared to system encryption. The reason for this that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, mlocate will scan all currently mounted file systems regularly and write the list of filenames to /var/lib/mlocate/mlocate.db, which is located in the non-encrypted root or /var partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted /home partition, readily available to assist them in accessing the encrypted data present the disk.<br />
<br />
Some have compared this to reducing the level of security from partition based encryption to filesystem level encryption like [System_Encryption_with_eCryptfs eCryptfs].<br />
<br />
<br />
'''Encryption of data partitions on separate physical disks from the system.'''<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Harddisk Drives or Separate Internal Harddisk Drives<br />
::*CD/DVD/Blue-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB Flash Drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Installation ==<br />
=== Overview and Preparation ===<br />
<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself.<br />
<br />
The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are setup.<br />
<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the harddisk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Securely Erase Hard Drive ===<br />
Repartitioning and formatting your drive will only remove the filesystem metadata and will mostly leave the actual data intact, allowing determined attackers to recover your data using tools like [http://foremost.sourceforge.net/ Foremost]. If your harddisk contained sensitive data from previous use, you might want to overwrite that data. <br />
<br />
{{ Tip | Overwriting your data multiple times or overwriting old files with random data serves no purpose; the original data cannot be recovered once it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/]}}<br />
<br />
While overwriting existing data won't provide you extra protection, if your disk is empty (or otherwise written with 0s), then it can help to fill the disk with random data before partitioning. This helps prevent attackers from seeing your disk layout, which may expose vulnerabilities. To fill your disk with random data use:<br />
# dd if=/dev/urandom of=/dev/<drive> bs=1M<br />
<br />
Where <code>/dev/<drive></code> is the encrypted drive.<br />
{{ Note | The above <code>dd</code> command will take hours. However, you will only every have to do it once. If you have multiple computers, you can have them help to speed up the process by using the '''ncat''' command. [http://en.gentoo-wiki.com/wiki/DM-Crypt_with_LUKS#Filling_the_disk_with_random_data This how-to] explains how to do that.}}<br />
<br />
Using <code>/dev/urandom</code> can take a long time because the CPU must generate the random data from a limited set of entropy. The <code>badblocks</code> command is capable of achieving essentially the same goal as using <code>/dev/urandom</code>, but at a much faster rate by generating data that is not truly random. The following command will be enough to securely erase your drive, albeit at a much faster rate:<br />
# badblocks -c 10240 -s -w -v -t random /dev/<drive><br />
<br />
=== Partition and Set Encryption ===<br />
Once the drive has been randomized, set up your partitions however you like. If do not plan on using [[LVM]], then read below; if you do want to use [[LVM]], see [[System Encryption with LUKS for dm-crypt#Encrypting a LVM setup | Encrypting a LVM Setup]].<br />
<br />
{{ Warning | Make sure you have a separate unencrypted partition for /boot. If boot is encrypted then you cannot load the kernel.}}<br />
<br />
Once you have finished partitioning, start up the Arch installer. Once you read the ''prepare hard drive'' section, choose ''Manually configure block devices, filesystems and mountpoints''. Set up your partitions as you normally would, but for any partition that you wish to be encrypted, choose <code>dm_crypt</code> in the filesystem dialogue. Once this is done, you'll notice that <code>/dev/mapper/</code> entries have appeared for each of your partitions. Format these as you would your normal partitions. Finally, press 'Done'.<br />
<br />
When you press 'DONE' the installer will create and mount the filesystem configuration automatically. You will be prompted for a LUKS passphrase 3 times (2x to set a new passphrase, 1x to unlock the device).<br />
<br />
You may now select packages and install the system as normal.<br />
<br />
=== Set System Configuration ===<br />
You may configure your system normally, except for a few small changes:<br />
* In <code>/etc/mkinitcpio.conf</code>, add ''encrypt'' to the <code>Hooks=</code>. Make sure it is before <code>lvm2</code> and <code>filesystems</code>. Like this:<br />
HOOKS="base udev autodetect pata scsi sata encrypt lvm2 filesystems"<br />
* In [[GRUB]], <code>/boot/grub/menu.lst</code>, add ''cryptdevice=/dev/sda2:vgroup'' between ''root'' and ''ro'' for both Arch Linux and Arch Linux Fallback.<br />
<br />
=== Further tweaks for USB keyfile authentication ===<br />
When you're planning to use a keyfile on an USB stick instead of passphrase authentication you have to do some further tweaks in <tt>mkinitcpio.conf</tt>:<br />
To mount the USB device with your keyfile in the boot process add ''usb'' somewhere before ''encrypt'' in the HOOKS variable e.g.<br />
HOOKS=" ... sata '''usb''' usbinput keymap encrypt filesystems ... "<br />
And for a FAT formated USB stick add the following to the MODULES variable<br />
MODULES=" ... '''nls_cp437 vfat''' ... "<br />
<br />
After exiting the installer you can now create a keyfile onto USB stick your for authentication.<br />
This is for example done with the following commands. Check out section [[#Generating the keyfile|Generating the keyfile]] for further details.<br />
<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile<br />
<br />
== Configuring LUKS ==<br />
As noted [[#Overwriting|above]] it's recommended for security reasons to overwrite the partition before going any further.<br />
<br />
=== Mapping partitions ===<br />
==== Passphrase ====<br />
Use this to create a password to unlock your encrypted partions with:<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda3<br />
Enter passphrase: mypassword<br />
Verify passphrase: mypassword<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda5<br />
Enter passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda6<br />
Enter passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup luksOpen /dev/sda3 root<br />
Enter any LUKS passphrase: mypassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup luksOpen /dev/sda5 home<br />
Enter any LUKS passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup luksOpen /dev/sda6 tmp<br />
Enter any LUKS passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
==== Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda6 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,5,6<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda6 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
==== Explanation ====<br />
Now you should have a device called <tt>/dev/mapper/root</tt>, another one called <tt>/dev/mapper/home</tt> and another one called <tt>/dev/mapper/tmp</tt>. These are block devices like any other, but with a neat twist: whenever you write to them, the data is actually written to <tt>/dev/sda3</tt>, <tt>/dev/sda5</tt> or <tt>/dev/sda6</tt> respectively, but it is encrypted first! The only way to access the data on this encrypted partition is to re-create that <tt>/dev/mapper/root</tt>, <tt>/dev/mapper/home</tt> etc. device with cryptsetup each time you boot. With LUKS, you can use <tt>cryptsetup luksAddKey /dev/sda3</tt> to add a new password or <tt>cryptsetup luksDelKey /dev/sda3</tt> to revoke a password. Type <tt>cryptsetup -?</tt> or <tt>man cryptsetup</tt> (once you've booted your new Arch installation) for more info.<br />
<br />
{{Note | With LUKS, if you enter the wrong password, it will reject it. You don't have to worry about it possibly destroying your data.}}<br />
<br />
{{ Note | You might also want to replace /var/tmp/ with a symbolic link to /tmp.}}<br />
<br />
{{ Note | If you've decided to go for option two for encrypted swap (see Encrypted Swap below), you should set up <tt>/dev/mapper/swap</tt> in a similar way as you've just set up <tt>/dev/mapper/home</tt>. See Encrypted Swap below for details.}}<br />
<br />
=== Installing the system ===<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.}}<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). Encrypt hook is not needed in case any other partition (swap, for example) is encrypted. System initialization scripts (''rc.sysinit'' and ''/etc/crypttab'' among others) take care of those.<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keymap' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note | if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
{{Note | eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.}}<br />
<br />
== Encrypting swap partition ==<br />
Sensitive data stored in memory may be written to swap at any time. If you've gone to the trouble of encrypting your root and home partitions, you should encrypt your swap as well. There are two options here: random encryption on each boot (better security), or the same encryption each time. We won't cover the second option here, as it is pretty much identical to how you set up the /home partition above. Just replace all references to home with swap, and sda5 with sda2.<br />
<br />
Arch Linux provides a convenient way for the first option, which uses dm-crypt directly without LUKS. If you're still in the archsetup process, just switch to a different virtual console (ALT+F2). If you've exited already, the new root will have been unmounted. Use <tt>mount /dev/mapper/root /mnt</tt> to mount it again.<br />
<br />
Now add an entry to the cryptsetup file:<br />
# echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
{{ Tip | Recommended hash algorithms are "whirlpool" (patent free), "sha256", "sha384" or "sha512". Default is "ripemd160" (not recommended).}}<br />
<br />
''[why is it not recommended? only RIPEMD (128bit) was hacked RIPEMD-160 is still safe[https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=83310], isn't it? I heard wirlpool is at least twice as slow. ]''<br />
<br />
{{ Warning | Please take extra care to put the right partition here. The startup script won't ask before overwriting the provided device, destroying '''all''' data on it, ''unless it has a LUKS header'', then it simply won't work.}}<br />
<br />
If you have been following these instructions closely, then in the section "Mapping Partitions" above you put a LUKS header on your swap partition. Erase it with something like the command below, replacing /dev/sda2 with the appropriate swap device:<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
From now on, each time you boot, the partition will be encrypted automatically with a random key, and will then be formated with mkswap.<br />
<br />
Now all you have to do is adjust the corresponding entry in /etc/fstab:<br />
/dev/mapper/swap swap swap defaults 0 0<br />
<br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Encrypted swap with suspend-to-disk support ==<br />
{{Warning | Don't use this setup with a key file, please read about the issue reported here: http://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure}}<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a presistent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br><br />
1. Format the partition you want to use as swap with '''cryptsetup'''. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check result with:<br />
# cryptsetup luksDump /dev/<device><br />
<br />
2. Open the partition in ''/dev/mapper'':<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
3. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
4. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
5. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
6. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
7. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
8. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
9. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Storing the key externally (USB stick) ==<br />
=== Preparation for permanent device names ===<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
==== Quick method ====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
=== Generating the keyfile ===<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
=== Storing the keyfile ===<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll write the key directly between MBR and first partition.<br />
<br />
'''WARNING:''' you should only follow this step if you know what you are doing - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. Grub needs the first 16 sectors (actually, it depends on the type of the file system, so don't rely on this too much), you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your Grub installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Remote unlocking of the root partition ==<br />
If you want to be able to reboot a fully LUKS encrypted system remotely or start it with a Wake-on-LAN service you will need a way to enter a passphrase for the root partition/volume at startup. This can be achived by running the "net" hook along with a ssh server in initrd. Install the [http://aur.archlinux.org/packages.php?ID=31135 dropbear_initrd_encrypt] package from AUR and follow the post installation instructions. Replace the "encrypt" hook with "encryptssh" in /etc/mkinitcpio.conf. Put the "net" hook early in the HOOKS array if your dhcp server takes a long time to assign an IP address.<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you don't know how to set up [[LVM]], then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up [[LVM]] on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important this in setting LVM on '''top''' of encryption is, that you need to have ''encrypt'' hook '''before''' ''lvm2'' hook (and those two before ''filesystems'' hook, but that's repeating). Because they are processed in order.<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda5 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "encrypt" hook in /etc/mkinitcpio.conf '''before''' the "lvm2" hook, if you chose to set up encrypted partition on '''top''' of LVM. Also remember to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
* In <tt>/etc/mkinitcpio.conf</tt> add ''encrypt'' '''before''' ''lvm2'' in the HOOKS variable if you set up LVM on top of the encrypted partition.<br />
<br />
That's it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2'' and ''encrypt'' (in that order) before ''filesystems'' in the HOOKS variable. Again, note that you are setting encryption on '''top''' of LVM.)<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Setup Archlinux on top of raid, LVM2 and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Vinhsynd