https://wiki.archlinux.org/api.php?action=feedcontributions&user=Airbus001&feedformat=atomArchWiki - User contributions [en]2024-03-29T15:23:39ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=List_of_applications/Internet&diff=217445List of applications/Internet2012-08-11T03:23:53Z<p>Airbus001: /* Graphical */</p>
<hr />
<div><noinclude><br />
[[Category:Applications]]<br />
[[Category:Networking]]<br />
[[it:Common Applications/Internet]]<br />
[[zh-CN:Common Applications/Internet]]<br />
{{Common Applications navigation}}<br />
</noinclude><br />
== Internet ==<br />
{{Note|1=For possibly more up to date selection of applications, try checking the [https://aur.archlinux.org/packages.php?O=0&K=&do_Search=Go&detail=1&C=13&SeB=nd&SB=n&SO=a&PP=50 AUR 'network' category]}}<br />
<br />
=== BitTorrent Clients ===<br />
{{Wikipedia|Comparison of BitTorrent clients}}<br />
<br />
==== Console ====<br />
* {{App|[[aria2]]|lightweight download utility that supports simultaneous adaptive downloading via HTTP(S), FTP, BitTorrent (DHT, PEX, MSE/PE) protocols and MetaLink. Can run as daemon controlled via JSON-RPC & XML-RPC interfaces|http://aria2.sourceforge.net/|{{Pkg|aria2}}}}<br />
* {{App|[[Wikipedia:MLDonkey|MLDonkey]]|multi-protocol P2P client supporting BitTorrent|http://mldonkey.sourceforge.net/|{{Pkg|mldonkey}}}}<br />
* {{App|[[Deluge]]|user-friendly BitTorrent client written in Python and wrapped with PyGTK|http://deluge-torrent.org/|{{Pkg|deluge}}}}<br />
* {{App|[[rTorrent]]|simple and lightweight ncurses BitTorrent client|http://libtorrent.rakshasa.no/|{{Pkg|rtorrent}}}}<br />
* {{App|[[Wikipedia:Transmission (BitTorrent client)|Transmission]]|simple and easy-to-use BitTorrent client with daemon version, GTK+, Qt GUI, web and CLI front-ends|http://transmissionbt.com/|{{Pkg|transmission-cli}}}} {{Aur|transmission-remote-cli}} {{aur|transmission-remote-gtk}} (remote clients work with the daemon in the -cli package)<br />
<br />
==== Graphical ====<br />
* {{App|[[Wikipedia:Vuze|Vuze]]|Feature-rich BitTorrent client written in Java (formerly Azureus)|https://www.vuze.com/|{{AUR|vuze}}}}<br />
* {{App|[[Wikipedia:KTorrent|KTorrent]]|Feature-rich BitTorrent client developed using Qt|http://ktorrent.org/|{{Pkg|ktorrent}}}}<br />
* {{App|[[Wikipedia:qBittorrent|qBittorrent]]|The closest open source (GNU GPL v2 license) equivalent to µtorrent|http://qbittorrent.sourceforge.net/|{{AUR|qbittorrent}}}}<br />
* {{App|[[Wikipedia:Transmission (BitTorrent client)|Transmission]]|simple and easy-to-use BitTorrent client with daemon version, GTK+, Qt GUI, web and CLI front-ends|http://transmissionbt.com/|{{Pkg|transmission-gtk}} {{Pkg|transmission-qt}}}}<br />
* {{App|QTorrent|A Qt BitTorrent client.|http://thegraveyard.org/qtorrent.html|{{Pkg|qtorrent}}}}<br />
<br />
=== eDonkey Clients ===<br />
eDonkey is still the second-largest p2p network (see [http://ipoque.com/en/resources/internet-studies Internet Study 2008/2009]).<br />
* {{App|[[aMule]]|Well-known eDonkey/Kad client with daemon version and GTK, web, and CLI front-ends|http://www.amule.org/|{{Pkg|amule}}}}<br />
<br />
=== eMoney ===<br />
{{Stub}}<br />
<br />
==== Bitcoin ====<br />
* {{App|[[Bitcoin]]|A tool to manage bitcoins, a p2p currency.|Official website : http://bitcoin.org/|{{AUR|bitcoin}}}}<br />
* [[Bitcoin#Mining|List of mining applications]]<br />
<br />
=== Chat Clients ===<br />
{{Wikipedia|Comparison of instant messaging clients}}<br />
<br />
==== Multi-Protocol Clients ====<br />
{{Wikipedia|Comparison of instant messaging clients#Multiprotocol clients}}<br />
<br />
{{Box||All messengers, that support several networks by means of direct connections to them, belong to this section|#E5E5FF|#FCFCFC}}<br />
<br />
Many clients listed here (including Pidgin and all it's forks) support multiple IM networks via [[Wikipedia:libpurple|libpurple]]. Number of networks is huge but they (like any multiprotocol clients) usually have very limited/none support of network-specific features.<br />
===== Console =====<br />
* {{App|Finch|ncurses-based Jabber/aim/etc/etc chat client based on libpurple|http://developer.pidgin.im/wiki/Using%20Finch|{{Pkg|finch}}}}<br />
* {{App|BarnOwl|chat client for the AIM, IRC, Jabber, and Zephyr protocols|http://barnowl.mit.edu/|{{AUR|barnowl}}}}<br />
* {{App|[[Bitlbee]]|way to use other IM to your [[Wikipedia:IRC|IRC]] client|http://bitlbee.org/|{{Pkg|bitlbee}}}}<br />
* {{App|[[Wikipedia:Centericq|CenterIM]]|Fork of CenterICQ, text mode menu- and window-driven IM interface|http://centerim.org/|{{Pkg|centerim}}}}<br />
<br />
===== Graphical =====<br />
* {{App|[[Pidgin]]|multi-protocol instant messaging client|http://pidgin.im/|{{Pkg|pidgin}}}}<br />
* {{App|Pidgin Light|light Pidgin version without gstreamer, tcl, tk, xscreensaver support|http://pidgin.im/|{{AUR|pidgin-light}}}}<br />
* {{App|Carrier|Pidgin fork providing minor GUI enhancements (formerly funpidgin)|http://funpidgin.sourceforge.net/{{Linkrot|2012|03|09}}|{{AUR|carrier}}}}<br />
* {{App|[[Wikipedia:Instantbird|Instantbird]]|multiprotocol chat client using Mozilla's XUL and libpurple.|http://instantbird.com/|{{AUR|instantbird}}}}<br />
* {{App|[[Wikipedia:Emesene|Emesene]]|Python/GTK+ instant messenger for the Windows Live Messenger network, compatible also with Jabber, Facebook and Google Talk|http://emesene.org/|{{Pkg|emesene}}}}<br />
* {{App|[[Wikipedia:Empathy (software)|Empathy]]|GNOME instant messaging client using the [[Wikipedia:Telepathy (software)|Telepathy]] framework|http://live.gnome.org/Empathy|{{Pkg|empathy}}}}<br />
* {{App|[[Wikipedia:Kopete|Kopete]]|user-friendly IM supporting AIM, ICQ, Windows Live Messenger, Yahoo, Jabber, Gadu-Gadu, Novell GroupWise Messenger, and more IM networks|http://kopete.kde.org/|{{Pkg|kdenetwork-kopete}}}}<br />
* {{App|qutIM|simple user-friendly IM supporting ICQ, Jabber, Mail.Ru, IRC and VKontakte messaging|http://qutim.org/|{{AUR|qutim}}}}<br />
* {{App|Galaxium Messenger|messenger application designed for the GNOME desktop|https://code.google.com/p/galaxium/|{{AUR|galaxium}}}}<br />
* {{App|Licq|An instant messaging client for UNIX supporting multiple protocols (currently ICQ, MSN and Jabber).|http://www.licq.org|{{Pkg|licq}}}}<br />
<br />
==== IRC Clients ====<br />
{{Wikipedia|Comparison of Internet Relay Chat clients}}<br />
<br />
===== Console =====<br />
* {{App|[[Irssi]]|Highly-configurable ncurses-based IRC client|http://irssi.org/|{{Pkg|irssi}}}}<br />
* {{App|[[Wikipedia:WeeChat|WeeChat]]|Modular, lightweight ncurses-based IRC client|http://weechat.org/|{{Pkg|weechat}}}}<br />
* {{App|[[Wikipedia:Ii (IRC client)|ii]]|featherweight IRC client, literally `tail -f` the convo and `echo` back your replies|http://tools.suckless.org/ii|{{AUR|ii}}}}<br />
* {{App|ERC|powerful, modular, and extensible IRC client for [[Emacs]]|http://savannah.gnu.org/projects/erc/|{{AUR|erc-git}}}}<br />
* {{App|Ircfs|file system interface to irc written in [http://limbo.cat-v.org Limbo]|http://www.ueber.net/code/r/ircfs|not available}}<br />
* {{App|[[Wikipedia:IrcII|IrcII]]|console-based IRC client - AKA BitchX|http://eterna.com.au/ircii/|{{Pkg|ircii-pana}}}}<br />
* {{App|sic|extremely simple IRC client|http://tools.suckless.org/sic|{{AUR|sic}}}}<br />
* {{App|ScrollZ|An advanced IRC client based on ircII|http://www.scrollz.com/|{{AUR|scrollz}}}}<br />
<br />
===== Graphical =====<br />
* {{App|[[Wikipedia:Konversation|Konversation]]|Qt-based IRC client for the KDE4 desktop|http://konversation.kde.org/|{{Pkg|konversation}}}}<br />
* {{App|[[Wikipedia:KVIrc|KVIrc]]|Qt-based IRC client featuring extensive themes support|http://kvirc.net/|{{Pkg|kvirc}}}}<br />
* {{App|Loqui|A GTK IRC client with only one dependency|https://launchpad.net/loqui|{{AUR|loqui}}}}<br />
* {{App|LostIRC|A simple GTK+ IRC client|http://lostirc.sourceforge.net|{{AUR|lostirc}}}}<br />
* {{App|[[Wikipedia:Smuxi|Smuxi]]|A cross-platform IRC client for the GNOME desktop inspired by Irssi|http://smuxi.org/|{{Pkg|smuxi}}}}<br />
* {{App|[[Wikipedia:XChat|XChat]]|GTK-based IRC client|http://xchat.org/|{{Pkg|xchat}}}}<br />
* {{App|pcw|A frontend for [http://tools.suckless.org/ii ii] that opens a new terminal for each channel (depends on [https://bitbucket.org/emg/srw srw] by default)|https://bitbucket.org/emg/pcw|{{AUR|pcw-hg}}}}<br />
* {{App|[[Wikipedia:Quassel IRC|Quassel]]|A modern, cross-platform, distributed IRC client.|http://quassel-irc.org/|{{Pkg|quassel}}}}<br />
<br />
==== Jabber/XMPP Clients ====<br />
{{Wikipedia|Comparison of instant messaging clients#XMPP clients}}<br />
<br />
===== Console =====<br />
* {{App|Freetalk|A console based Jabber client|https://gnu.org/s/freetalk/|{{Pkg|freetalk}}}}<br />
* {{App|jabber.el|A minimal jabber client for emacs|http://emacs-jabber.sourceforge.net/|{{AUR|emacs-jabber}}}}<br />
* {{App|[[Wikipedia:MCabber|MCabber]]|small Jabber console client, includes features: SSL, PGP, MUC, and UTF8|http://mcabber.com/|{{Pkg|mcabber}}}}<br />
<br />
===== Graphical =====<br />
* {{App|[[Wikipedia:Gajim|Gajim]]|Jabber client written in PyGTK|https://gajim.org/|{{Pkg|gajim}}}}<br />
* {{App|[[Wikipedia:Psi (instant messaging client)|Psi]]|A Qt based Jabber client|http://psi-im.org/|{{Pkg|psi}}}}<br />
* {{App|Psi+|enhanced version of Psi Jabber client|https://code.google.com/p/psi-dev/|{{AUR|psi-plus}}}}<br />
* {{App|Jabbim|A Jabber client written in PyQt.|http://dev.jabbim.cz/jabbim|{{AUR|jabbim-svn}}}}<br />
<br />
==== MSN Clients ====<br />
* {{App|[[Wikipedia:AMSN|aMSN]]|MSN client written in Tcl/Tk|http://amsn-project.net/|{{Pkg|amsn}}}}<br />
* {{App|[[Wikipedia:Emesene|Emesene]]|A pygtk MSN Messenger client|http://blog.emesene.org/|{{Pkg|emesene}}}}<br />
* {{App|[[Wikipedia:Kmess|KMess]]|KMess is a MSN Messenger client for Linux|http://kmess.org/|{{Pkg|kmess}}}}<br />
* {{App|Mercury|Java Based MSN client|http://mercury.im{{Linkrot|2012|02|19}}|{{AUR|mercury}}}}<br />
<br />
=== Pastebin Clients ===<br />
{{wikipedia|Pastebin}}<br />
Pastebin services are often used to paste information into [[IRC_Channel | IRC channels]] to help with troubleshooting. There are services for both text (eg [http://sprunge.us/ sprunge.org], [http://pastie.org/ pastie.org], [http://codepad.org/ codepad.org]) and images (eg [http://imgur.com/ imgur.com], [http://picpaste.com/ picpaste.com]). Pastebin clients allow you to post directy from the cli without using a web browser.<br />
<br />
{{Tip|The sprunge pastebin can be accessed directly via curl: {{bc|<nowiki><command> | curl -F 'sprunge=<-' http://sprunge.us</nowiki>}}<br />
There is also a [https://github.com/robbyrussell/oh-my-zsh/wiki/Usage-of-the-%22sprunge%22-command sprunge plugin] for [https://github.com/robbyrussell/oh-my-zsh/wiki oh-my-zsh] (a configuration tool for the [http://zsh.sourceforge.net/ ZSH] command shell).}}<br />
<br />
{{Tip|Do not use {{ic|pastebin.com}}. It appears to be the most popular site but it is slow, full of adverts, formats the text badly (it will mess up your code) and many people can not even open the site due to aggressive spam filters.}}<br />
<br />
* {{app|Wgetpaste|A bash script that automates pasting to a number of pastebin services. Servers: pastebin.ca, codepad.org, dpaste.com, pastebin.osuosl.org and paste.pocoo.org.|http://wgetpaste.zlin.dk/|{{Pkg|wgetpaste}}}}<br />
* {{app|Curlpaste|A utility to post text files to a number of pastebin sites using curl and Lua. For usage instructions run: curlpaste -h. To change the defaults, edit {{ic|/etc/curlpaste.conf}}. Servers: pastebin.ca, codepad.org, dpaste.com and fpaste.org.|http://github.com/Kiwi/curlpaste/tree/master|{{Pkg|curlpaste}}}}<br />
* {{app|Gist|A commandline interface for the gist.github.com pastebin service.|http://github.com/defunkt/gist|{{AUR|gist}}.}}<br />
* {{app|Vim-gist| A Vim script for gist.| http://www.vim.org/scripts/script.php?script_id&#61;2423 |{{pkg|vim-gist}}}}<br />
* {{app|Haste|A universal pastebin tool, written in Haskell. Servers: hpaste.org, paste2.org, pastebin.com and others.|http://hackage.haskell.org/package/haste|{{AUR|haste}}}}<br />
* {{app|Hg-paste|Paste extension for Mercurial which can send diffs to various pastebin websites for easy sharing. Servers: dpaste.com and dpaste.org.|http://bitbucket.org/sjl/hg-paste|{{AUR|hg-paste}}}}<br />
* {{app|Ix|A client for the ix.io pastebin.|http://ix.io|{{pkg|ix}}}}<br />
* {{app|Npaste-client| A client for the npaste.de pastebin.|http://npaste.de|{{AUR|npaste-client}}}}<br />
* {{app|Fb-client| A client for the paste.xinu.at pastebin.|http://paste.xinu.at|{{pkg|fb-client}}}}<br />
* {{app|Pastebinit| A really small piece of Python that acts as a Pastebin client. Servers: pastebin.ca, rafb.net, slexy.org, fpaste.org, paste2.org, pastey.net, stikked.com, yourpaste.net, gist.github.com, paste.ubuntu.com and paste.debian.net|http://launchpad.net/pastebinit|{{AUR|pastebinit}}}}<br />
* {{app|Vim-paster| A Vim plugin to paste to any pastebin service.|http://eugeneciurana.com/site.php?page&#61;tools|{{AUR|vim-paster}}}}<br />
* {{app|Elmer| A pastebin client similar to wgetpaste and curlpaste, except written in Perl and usable with wget or curl. Servers: codepad.org, rafb.me, sprunge.us, ompldr.org (requires curl).|https://github.com/sudokode/elmer|{{AUR|elmer}}}}<br />
<br />
=== Email clients ===<br />
{{Wikipedia|Comparison of e-mail clients}}<br />
<br />
==== Console ====<br />
* {{App|[[Alpine]]|The Apache-licensed [[Wikipedia:PINE|PINE]] (a tool for reading, sending, and managing electronic messages)|https://washington.edu/alpine|{{Pkg|alpine}}}}<br />
* {{App|[[Wikipedia:Gnus|Gnus]]|mail, nntp, rss client for Emacs.|http://gnus.org/|{{AUR|emacs-gnus-git}}}}<br />
* {{App|[[Wikipedia:mailx|heirloom-mailx]]|A full-featured command-line MUA derived from Berkeley Mail.|http://heirloom.sourceforge.net/mailx.html|{{Pkg|heirloom-mailx}}}}<br />
* {{App|[[Mutt]]|Small but very powerful text-based mail client.|http://www.mutt.org/|{{Pkg|mutt}}}}<br />
* {{App|[[Sup]]|A CLI mail client with very fast searching, tagging, threading and gmail like operation.|http://sup.rubyforge.org/|{{AUR|sup}}}}<br />
* {{App|[[Wikipedia:Wanderlust_(software)|Wanderlust]]|mail, nntp client for Emacs.|http://www.gohome.org/wl/|{{Pkg|wanderlust}}}}<br />
<br />
==== Graphical ====<br />
* {{App|[[Balsa]]|A simple light email client. Part of the Gnome project|http://balsa.gnome.org/|{{Pkg|balsa}}}}<br />
* {{App|[[Wikipedia:Claws Mail|Claws Mail]]|A GTK+ based e-mail client|http://claws-mail.org/|{{Pkg|claws-mail}}}}<br />
* {{App|[[Evolution]]|A mature and feature-rich e-mail client used in GNOME by default|http://projects.gnome.org/evolution/|{{Pkg|evolution}}}}<br />
* {{App|[[Wikipedia:Kmail|Kmail]]|A mature and feature-rich e-mail client part of the KDE project|http://kde.org/applications/internet/kmail/|{{Pkg|kdepim-kmail}}}}<br />
* {{App|Postler|simple desktop mail client built in vala.|http://git.xfce.org/apps/postler|{{AUR|postler}}}}<br />
* {{App|[[Wikipedia:Sylpheed|Sylpheed]]|Lightweight and user-friendly e-mail client (GTK)|http://sylpheed.sraoss.jp/en/|{{Pkg|sylpheed}}}}<br />
* {{App|[[Thunderbird]]|Mozilla's GTK2-based client|http://www.mozilla.org/en-US/thunderbird/|{{Pkg|thunderbird}}}}<br />
* {{App|Trojitá|An IMAP e-mail client.|http://trojita.flaska.net/|{{AUR|trojita}}}}<br />
* {{App|Manitou|A database-driven email system.|http://www.manitou-mail.org/|{{AUR|manitou-ui}}}}<br />
<br />
=== Network Managers ===<br />
* {{App|[[netcfg]]|Network configuration and profile scripts|http://projects.archlinux.org/netcfg.git/|{{Pkg|netcfg}}}}<br />
* {{App|[[Wicd]]|Manages wireless and wired interfaces, requiring fewer dependencies than other network managers. In addition to GUI interfaces, a curses version is also available.|http://wicd.sourceforge.net/|{{Pkg|wicd}}}}<br />
* {{App|[[NetworkManager]]|provides wired, wireless, mobile broadband and OpenVPN detection and configuration allowing automatic connection to a network.|http://projects.gnome.org/NetworkManager/|{{Pkg|networkmanager}}}}<br />
<br />
=== News Aggregators ===<br />
{{Wikipedia|Comparison of feed aggregators}}<br />
<br />
==== Console ====<br />
* {{App|Newsbeuter|A ncurses RSS aggregator with layout and keybinding similar to mutt. Does not use the traditional 3 panes setup|http://newsbeuter.org|{{Pkg|newsbeuter}}}}<br />
* {{App|Snownews|Text mode RSS newsreader|http://kiza.kcore.de/software/snownews/|{{Pkg|snownews}}}}<br />
* {{App|Rawdog|A "RSS Aggregator Without Delusions Of Grandeur" that parses RSS/CDF/Atom feeds into a static HTML page of articles in date order|http://offog.org/code/rawdog.html|{{AUR|rawdog}}}}<br />
* {{App|[[Wikipedia:Gnus|Gnus]]|A mail, nntp, rss client for Emacs|http://gnus.org/|{{AUR|emacs-gnus-git}}}}<br />
* {{App|[[Wikipedia:Canto (news aggregator)|Canto]]|A ncurses RSS aggregator|http://codezen.org/canto/|{{AUR|canto}}}}<br />
<br />
==== Graphical ====<br />
* {{App|Akregator|KDE's news aggregator|http://akregator.kde.org/|{{Pkg|kdepim-akregator}}}}<br />
* {{App|[[Wikipedia:Liferea|Liferea]]|GTK desktop news aggregator for online news feeds and weblogs| http://liferea.sourceforge.net|{{Pkg|liferea}}}}<br />
* {{App|RSS Guard|A (very) tiny RSS & ATOM reader developed using Qt framework|https://code.google.com/p/rss-guard/|{{AUR|rss-guard}}}}<br />
* {{App|[[Wikipedia:RSSOwl|Rssowl]]|powerful aggregator for RSS and Atom feeds, written in Java using Eclipse Rich Client Platform and SWT as a widget toolkit|http://boreal.rssowl.org|{{AUR|rssowl}}}}<br />
* {{App|[[Wikipedia:BlogBridge|BlogBridge]]|excellent java-based aggregator, which gives users the option to synchronize their feeds across multiple computers|http://blogbridge.com|{{AUR|blogbridge}}}}<br />
* {{App|[[Thunderbird]]|A mail client from Mozilla which also functions as a pretty nice news aggregator|https://mozillamessaging.com|{{Pkg|thunderbird}}}}<br />
* {{App|Tickr (formerly News)|GTK-based RSS Reader that displays feeds as a smooth scrolling line on your Desktop, as known from TV stations.|http://newsrssticker.com/|{{AUR|tickr}}}}<br />
* {{App|Urssus|A cross platform GUI News Agregator.|https://code.google.com/p/urssus/|{{AUR|urssus}}}}<br />
<br />
=== Web Browsers ===<br />
{{Wikipedia|Comparison of web browsers}}<br />
<br />
==== Console ====<br />
* {{App|[[Wikipedia:W3m|W3m]]|pager/text-based WWW browser|http://w3m.sourceforge.net/|{{Pkg|w3m}}}}<br />
* {{App|[[Wikipedia:Lynx (web browser)|Lynx]]|text browser for the World Wide Web|http://lynx.isc.org|{{Pkg|lynx}}}}<br />
* {{App|[[Wikipedia:Links (web browser)|Links]]|text WWW browser, similar to Lynx, but with CSS-based rendering|http://links.twibright.com/|{{Pkg|links}}}}<br />
* {{App|[[Wikipedia:ELinks|ELinks]]|advanced and well-established feature-rich text mode web browser (links fork, barely supported since 2009)|http://elinks.or.cz/|{{Pkg|elinks}}}}<br />
<br />
==== Graphical ====<br />
* {{App|[[Wikipedia:Abaco (web browser)|Abaco]]|A multi-page graphical web browser|http://lab-fgb.com/abaco/|{{AUR|abaco}}}}<br />
* {{App|[[Wikipedia:Arora (browser)|Arora]]|A cross platform web browser built using Qt and WebKit|https://code.google.com/p/arora/|{{Pkg|arora}}}}<br />
* {{App|[[Wikipedia:Conkeror|Conkeror]]|A highly programmable web browser, with Emacs-like keybindings, based on Mozilla XULRunner|http://conkeror.org/|{{AUR|conkeror-git}}}}<br />
* {{App|[[Chromium]]|The open-source project behind Google Chrome, a web browser developed by Google that uses the WebKit layout engine and application framework|https://code.google.com/chromium/|{{Pkg|chromium}}}}<br />
* {{App|[[Wikipedia:Dillo|Dillo]]|A small, fast graphical web browser built on FLTK|http://dillo.org/|{{Pkg|dillo}}}}<br />
* {{App|[[Epiphany]]|The default GNOME browser, which uses the webkit rendering engine|http://projects.gnome.org/epiphany/|{{Pkg|epiphany}}}}<br />
* {{App|[[Firefox]]|[https://addons.mozilla.org/firefox/ Extensible] GTK2 browser based on Gecko with fast rendering|https://mozilla.com/firefox|{{Pkg|firefox}}}}<br />
* {{App|Hv3|A minimalist web browser based on tkhtml3|http://tkhtml.tcl.tk/hv3.html|{{AUR|hv3}}}}<br />
* {{App|[[Jumanji]]|A highly customizable and functional web browser|http://pwmt.org/projects/jumanji|{{AUR|jumanji}}}}<br />
* {{App|[[Wikipedia:Kazehakase|Kazehakase]]|A much lighter, but rather feature-lacking alternative to other browsers (GTK2 and Gecko)|http://kazehakase.sourceforge.jp/|{{AUR|kazehakase}}}}<br />
* {{App|dwb| A lightweight web browser based on the webkit engine. Highly customizable, with vi-like shortcuts and tiling layouts. |http://portix.bitbucket.org/dwb/|{{AUR|dwb}}}}<br />
* {{App|[[Wikipedia:Konqueror|Konqueror]]|Qt- and KHTML-based browser. A part of the KDE desktop|http://konqueror.org/|{{Pkg|kdebase-konqueror}}}}<br />
* {{App|[[Luakit]]| A highly configurable, micro-browser framework based on the WebKit web content engine and the GTK+ toolkit. It is very fast, extensible by Lua and licensed under the GNU GPLv3 license|http://luakit.org/projects/luakit/|{{Pkg|luakit}}}}<br />
* {{App|[[Wikipedia:Midori (web browser)|Midori]]| A lightweight web browser based on Gtk and WebKit. Passes the ACID3 test|http://twotoasts.de/index.php?/pages/midori_summary.html|{{Pkg|midori}}}}<br />
* {{App|[[Wikipedia:NetSurf|NetSurf]]| A featherweight browser written in C. Notable is its lack of JavaScript support and fast rendering through its own custom rendering engine|http://netsurf-browser.org|{{Pkg|netsurf}}}}<br />
* {{App|[[Opera]]|Highly customizable browser with focuses on an adherence to web rendering standards|http://opera.com|{{Pkg|opera}}}}<br />
* {{App|QupZilla|A new and very fast open source browser based on WebKit core, written in Qt framework. | http://www.qupzilla.com |{{AUR|qupzilla-git}}}} <br />
* {{App|[[wikipedia:Rekonq|Rekonq]]| A WebKit based web browser for KDE|http://rekonq.kde.org/|{{Pkg|rekonq}}}}<br />
* {{App|Sb|A very lightweight webkit-based browser that uses keybindings to perform most things the URL bar would usually do|https://github.com/mutantturkey/sb/|{{AUR|sb-git}}}} <br />
* {{App|Surf|Another lightweight WebKit-based browser, which follows the [http://suckless.org/philosophy suckless ideology]. Which means, the software is even more lightweight (basically, the browser itself is a single C source file)|http://surf.suckless.org|{{AUR|surf-hg}}}}<br />
* {{App|[[Wikipedia:Uzbl|Uzbl]]|Web interface tools which adhere to the unix philosophy|http://uzbl.org/|{{Pkg|uzbl-browser}}}}<br />
* {{App|[[Vimprobable]]|A browser that behaves like the Vimperator plugin available for Mozilla Firefox. It is based on the WebKit engine (using GTK bindings)|http://vimprobable.org/|{{AUR|vimprobable-git}}}}<br />
<br />
=== Microblogging Clients ===<br />
* {{App|Pino|simple and fast X11 client for Twitter and Identi.ca. It is compiled to native code, which assures small size and speed, and thanks to use of Vala language it can perfectly integrate into your Gnome or XFCE desktop|http://pino-app.appspot.com/|{{AUR|pino}}}}<br />
* {{App|[[Wikipedia:Gwibber|Gwibber]]|open source microblogging client for Linux. It brings the most popular social networking web services to your desktop and gives you the ability to control how you communicate|http://gwibber.com/|{{Pkg|gwibber}}}}<br />
* {{App|[[Wikipedia:Hotot (program)|Hotot]]|lightweight & open source Microblogging Client, coding using Python language and designed for Linux|http://hotot.org|{{AUR|hotot}}}}<br />
* {{App|tyrs|simple client for for Twitter and Identi.ca supporting virtually all its features with nice console UI|http://tyrs.nicosphere.net/|{{AUR|tyrs}}}}<br />
* {{App|Qwit|A cross-platform client for Twitter using the Qt toolkit.|http://code.google.com/p/qwit/|{{AUR|qwit}}}}<br />
* {{App|Choqok|A micro-blogging client for KDE that supports Twitter.com, Identi.ca and opendesktop.org services.|http://choqok.gnufolks.org/|{{Pkg|choqok}}}}<br />
<br />
=== FTP Clients ===<br />
{{Wikipedia|Comparison of FTP client software}}<br />
<br />
* {{App|Filezilla|Fast and reliable FTP, FTPS and SFTP client|http://filezilla-project.org/|{{Pkg|filezilla}}}}<br />
* {{App|curlftp|A filesystem for acessing FTP hosts based on FUSE and libcurl. |http://curlftpfs.sourceforge.net/|{{Pkg|curlftpfs}}}}<br />
* {{App|fuseftp|FTP filesystem written in Perl, using FUSE|http://freshmeat.net/projects/fuseftp/|{{AUR|fuseftp}}}}<br />
* {{App|lftp|Sophisticated command line based FTP client|http://lftp.yar.ru/|{{Pkg|lftp}}}}<br />
* {{App|gftp|A multithreaded ftp client for X|http://gftp.seul.org/|{{Pkg|gftp}}}}<br />
* {{App|tnftp|[[Wikipedia:NetBSD|NetBSD]] FTP client with several advanced features|http://freecode.com/projects/tnftp|{{Pkg|tnftp}}}}<br />
* {{App|[[Wikipedia:FatRat|FatRat]]|A download manager with support for HTTP, FTP, SFTP, BitTorrent, RapidShare and more.|http://fatrat.dolezel.info/|{{Pkg|fatrat}}}}<br />
Some file managers like [[Dolphin]], [[Nautilus]] and [[Thunar]] also provide FTP functionality.</div>Airbus001https://wiki.archlinux.org/index.php?title=Dm-crypt&diff=210987Dm-crypt2012-06-23T03:27:58Z<p>Airbus001: /* Using GPG or OpenSSL Encrypted Keyfiles */</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[ru:System Encryption with LUKS]]<br />
[[zh-CN:System Encryption with LUKS]]<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 />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
==== Data encryption ====<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
*Preventing unauthorized physical access to private data.<br />
*Some confidence in data disposal when discarding obsolete systems.<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 />
==== System encryption ====<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 />
*Preventing unauthorized physical access to operating system files<br />
*Preventing unauthorized physical access to private data that may cached by the system.<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 />
*Attempts to bypass the operating system by inserting a boot CD/USB<br />
*Copying, modifying, or removing the hard disk drives when the computer is off<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the {{ic|/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 />
{{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 Available for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption, including:<br />
<br />
;loop-AES ([http://loop-aes.sourceforge.net/ loop-AES]):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 />
;standard device-mapper encryption ([http://www.saout.de/misc/dm-crypt/ dm-crypt]):This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
;LUKS for dm-crypt ([http://code.google.com/p/cryptsetup/ LUKS]):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 />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key (see [[Wikipedia:Kerckhoffs's principle]])<br />
::*The usage of a proven encryption algorithm<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 />
====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 />
====discard/TRIM support for solid state disks====<br />
<br />
Solid state disk users should be aware that by default, Linux's full-disk encryption mechanisms will ''not'' forward TRIM commands from the filesystem to the underlying disk. The device-mapper maintainers have made it clear that TRIM support will never be enabled by default on dm-crypt devices because of the potential security implications; if TRIM support were enabled, an attacker may be able to tell which blocks have been used, how many blocks have been used, and other information that is exposed directly to the device when a TRIM is issued.<br />
<br />
It may be possible to determine the filesystem utilized by your encrypted device through the data that is leaked by TRIM. Furthermore, any information that may be derived by a profile of block usage may be exposed by enabling TRIM support on an encrypted device.<br />
<br />
As of {{Pkg|linux}} version 3.1, support for dm-crypt TRIM pass-through can be toggled upon device creation or mount with dmsetup. Support for this option also exists in {{Pkg|cryptsetup}} version 1.4.0 and up. To add support during boot, you will need to add "{{ic|:allow-discards}}" to the {{ic|cryptdevice}} option. The option should look like this:<br />
cryptdevice=/dev/mapper/root:root:allow-discards<br />
<br />
For more information, including specific commands and details on dm-crypt TRIM pass-through, see these mailing list threads:<br />
* http://article.gmane.org/gmane.linux.kernel.device-mapper.devel/14134<br />
* http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/5166<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 shut down. 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 to extract your encryption key - thus obtaining access to your data.<br />
<br />
{{Note|System Encryption assumes encryption of all mounted partitions: this includes all partitions except for {{ic|/boot}} - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, {{ic|/tmp}}, or root filesystems are unencrypted, only Data Encryption level of security has been accomplished.}}<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 />
=====Encryption of data partitions on the same physical disk as the system=====<br />
<br />
The most common form of data encryption is encrypting the {{ic|/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 decreased by orders of magnitude when compared to system encryption. The reason for this is 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, {{Pkg|mlocate}} will scan all currently mounted file systems regularly and write the list of filenames to {{ic|/var/lib/mlocate/mlocate.db}}, which is located in the non-encrypted root or {{ic|/var}} partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted {{ic|/home}} partition, readily available to assist them in accessing the encrypted data present on 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|System Encryption with eCryptfs]].<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 Hard Disk Drives or Separate Internal Hard Disk Drives<br />
::*CD/DVD/Blu-Ray Optical Media<br />
::*Magnetic Storage Media<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 set up.<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the hard disk 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 Hard Disk Drive ===<br />
<br />
Secure erasure of the hard disk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a hard disk 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 />
====Why perform secure erasure of a drive?====<br />
<br />
There are two types of hard disk 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 Hard Disk Drives'''<br />
<br />
::In hard drives 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 Hard Disk Drives'''<br />
<br />
::Repartitioning or reformatting a used hard drive 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 straightforward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore hard drives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
====Overwriting a hard disk drive with random data====<br />
<br />
There are two sources of random data commonly used for securely overwriting hard disk partitions.<br />
<br />
::*{{ic|/dev/urandom}}<br />
::*badblocks<br />
<br />
=====Using urandom=====<br />
<br />
#dd if=/dev/urandom of=/dev/<drive> bs=1M<br />
<br />
Where {{ic|/dev/<drive>}} is the drive to be encrypted.<br />
<br />
{{Note| Using {{ic|/dev/urandom}} will take a long time to completely overwrite a drive with "random" data. In the strictest sense, {{ic|/dev/urandom}} is less random than {{ic|/dev/random}}; however, {{ic|/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 {{ic|/dev/random}} for overwriting hard disks impractical.}}<br />
<br />
{{Note| Users may also find that {{ic|/dev/urandom}} takes an excessively long time on large drives of several hundred gigabytes or more (more than twenty-four hours). [[Frandom]] offers a faster alternative.}}<br />
<br />
{{Note|You can retrieve progress of the dd command with this command: {{ic|kill -USR1 $(pidof dd)}}}}<br />
<br />
=====Using badblocks=====<br />
<br />
#badblocks -c 10240 -wsvt random /dev/<drive><br />
<br />
Where {{ic|/dev/<drive>}} is the drive to be encrypted.<br />
<br />
{{Note|The {{ic|badblocks}} command overwrites the drive at a much faster rate by generating data that is not truly random.}}<br />
<br />
See also [[badblocks]].<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a hard disk 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 />
=====After installation=====<br />
Essentially the same effect can be achieved if a file is created on each of the partitions that fills the partition completely '''after''' the system is installed and booted with encrypted partitions mounted. <br />
#dd if=/dev/zero of=/path/to/the/output/file<br />
#rm /path/to/the/input/file<br />
Just make sure that you do that for every partition on the filesystem. This works as encrypted data is indistinguishabe from random, so anone trying to access potential leftover files will just see random data.<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 with systems that require 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 three flavors: primary partitions, extended partitions, and logical partitions.<br />
<br />
;Primary Partitions: These are the normal partitions recognized by the system BIOS. There can be up to four of these stored in the MBR.<br />
<br />
;Extended Partitions: These are primary partitions that also define another partition within themselves. Extended partitions were created to work around the original limit of four primary partitions.<br />
<br />
;Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
====LVM: Logical Volume Manager====<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple hard disk drives and partitions that are not possible with standard partitions. LVM is covered in detail in the [[LVM|Arch Linux LVM Wiki Article]] which is recommended reading prior to continuing with the instructions on setting up LUKS with LVM located below.<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 is that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In this case, logical volume management would be layered on top of the hardware encryption &ndash; usage of LUKS would be superfluous.<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 two required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*{{ic|'''/'''}}<br />
:::*Will be encrypted and store all system and user files ({{ic|/usr}}, {{ic|/bin}}, {{ic|/var}}, {{ic|/home}}, etc.)<br />
<br />
::An initial boot partition<br />
<br />
:::*{{ic|'''/boot'''}}<br />
:::*Will ''not'' be encrypted; the bootloader needs to access the {{ic|/boot}} directory where it will load the initramfs/encryption modules needed to load the rest of the system which ''is'' encrypted (see [[Mkinitcpio]] for details). For this reason, {{ic|/boot}} needs to reside on its own, unencrypted partition.<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 />
=====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 used, the space unoccupied by {{ic|/boot}} and swap should be defined as single large partition which will be divided up later at the LVM level.<br />
<br />
=====Multiple Disk Systems=====<br />
<br />
In systems that will have multiple hard disk drives, the same options exist as a single disk system. After the creation of the {{ic|/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 {{ic|/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 the dialogue for manual configuration of the hard drive.<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 per LUKS partition.<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
{{Note|Using a passphrase to decrypt LUKS partitions automatically from {{ic|/etc/crypttab}} is deprecated: see http://www.mail-archive.com/arch-projects@archlinux.org/msg02115.html}}<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
A full list of options {{ic|cryptsetup}} accepts can be found in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::*{{ic|-c}} defines the cipher type<br />
::*{{ic|-y}} prompts for password confirmation on password creation<br />
::*{{ic|-s}} defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
In the following examples for creating LUKS partitions, we will use the AES cipher in XTS mode; at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup, and details about them can be found here: [[Wikipedia:Block_cipher]]<br />
<br />
'''Formatting LUKS Partitions'''<br />
<br />
First of all make sure the device mapper kernel module is loaded by executing the following: {{ic|# modprobe dm_mod}}<br />
<br />
In order to format a desired partition as an encrypted LUKS partition execute:<br />
{{hc|# cryptsetup -c <cipher> -y -s <key size> luksFormat /dev/<partition name>|<br />
Enter passphrase: <password><br />
Verify passphrase: <password>}}<br />
<br />
This should be repeated for all partitions except for {{ic|/boot}} and possibly swap.<br />
<br />
The example below will create an encrypted root partition using the AES cipher in XTS mode (generally referred to as ''XTS-AES'').<br />
{{bc|cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2}}<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 the chosen partitioning method, the {{ic|/boot}} partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<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 {{ic|/dev/<partition name>}} is actually an encrypted device and should be addressed through LUKS using the {{ic|/dev/mapper/<name>}} so as not to overwrite the encrypted data. <br />
<br />
In order to open an encrypted LUKS partition execute:<br />
{{hc|# cryptsetup luksOpen /dev/<partition name> <device-mapper name>|<br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.}}<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
::*cryptsetup luksOpen /dev/sda2 '''swap'''<br />
::::Once opened, the swap partition device address would be '''{{ic|/dev/mapper/swap}}''' instead of {{ic|/dev/sda2}}.<br />
<br />
::*cryptsetup luksOpen /dev/sda3 '''root'''<br />
::::Once opened, the root partition device address would be '''{{ic|/dev/mapper/root}}''' instead of {{ic|/dev/sda3}}.<br />
<br />
{{Note|Since {{ic|/boot}} is not encrypted, it does not need a device mapped name and will be addressed as {{ic|/dev/sda1}}.}}<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 Partitions with a Keyfile ====<br />
{{Note|This section describes using a plaintext keyfile, if you want to encrypt your keyfile giving you two factor authentication see [https://wiki.archlinux.org/index.php/System_Encryption_with_LUKS#Using_GPG_or_OpenSSL_Encrypted_Keyfiles Section 9] for details, but please still read this section.}}<br />
<br />
'''What is a Keyfile?'''<br />
<br />
A keyfile is any file in which the data contained within it 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 />
{{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 />
'''Why use a Keyfile?'''<br />
<br />
There are many kinds of keyfile. Each type of keyfile used has benefits and disadvantages summarized below:<br />
<br />
:'''keyfile.passphrase:'''<br />
::this is my passphrase I would have typed during boot but I have placed it in a file instead<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 add any security over entering a passphrase during the initial system start.<br />
<br />
:'''keyfile.randomtext:'''<br />
::fjqweifj830149-57 819y4my1- 38t1934yt8-91m 34co3;t8y;9p3y-<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 />
:'''keyfile.binary:'''<br />
::where any binary file, images, text, video could be chosen as the keyfile<br />
<br />
This is a binary file that has been defined as a keyfile. When identifying files as candidates for a keyfile, it is recommended to choose files that are relatively static such as photos, music, video clips. The benefit of these files is that they serve a dual function which can make them harder to identify as keyfiles. Instead of having a text file with a large amount of random text, the keyfile would look like a regular image file or music clip to the casual observer. The disadvantage is that if this file is lost or changed, it will most likely not be possible to access the encrypted volume without a backup passphrase. Additionally, there is a theoretical loss of randomness when compared to a randomly generated text file. This is due to the fact that images, videos and music have some intrinsic relationship between neighboring bits of data that does not exist for a text file. However this is controversial and has never been exploited publicly.<br />
<br />
'''Creating a Keyfile with Random Characters'''<br />
<br />
Here {{ic|dd}} is used to generate a keyfile of 2048 bits of random characters.<br />
<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
The usage of {{ic|dd}} is similar to initially wiping the volume with random data prior to encryption. <br />
<br />
{{Warning|Do not use [[badblocks]] here. It only generate a random pattern which just repeats its randomness over and over again.}}<br />
<br />
'''Creating a new LUKS encrypted partition with a Keyfile'''<br />
<br />
When creating a new LUKS encrypted partition, a keyfile may be associated with the partition on its creation using:<br />
<br />
# cryptsetup -c <desired cipher> -s <key size> luksFormat /dev/<volume to encrypt> '''/path/to/mykeyfile'''<br />
<br />
This is accomplished by appending the bold area to the standard cryptsetup command which defines where the keyfile is located.<br />
<br />
==== Adding Additional Passphrases or Keyfiles to a LUKS Encrypted Partition ====<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 slot 0.<br />
Additional keys will occupy slots 1&ndash;7.<br />
<br />
The addition of new keys to an encrypted partition is accomplished using cryptsetup with the {{ic|luksAddKey}} extension.<br />
<br />
# cryptsetup luksAddKey /dev/<encrypted volume> '''/path/to/mykeyfile'''<br />
<br />
Where {{ic|/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 is important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. {{ic|/dev/sdb1}} 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 {{ic|encrypt}} HOOK in the initcpio finds your keyfile, you must 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 the following:<br />
<br />
{{hc|# ls -l /dev/disk/by-label/|<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1}}<br />
<br />
or<br />
<br />
{{hc|# 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 {{ic|/dev/disk/by-label/Keys}}, or if I had wanted to use the UUID I would find {{ic|/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 ({{ic|sdb1}}, {{ic|sdb2}}, ...) but not to the USB device ({{ic|sdb}}) 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 flash drive with a [[udev]] rule. There is 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 is quickly how it goes.<br />
<br />
Get the serial number from your USB flash drive:<br />
lsusb -v | grep -A 5 Vendor<br />
<br />
Create a udev rule for it by adding the following to a file in {{ic|/etc/udev/rules.d/}}, such as {{ic|8-usbstick.rules}}:<br />
KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"<br />
<br />
Replace {{ic|$SYMLINK}} and {{ic|$SERIAL}} with their respective values. {{ic|%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 {{ic|/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. {{ic|/media/sdb1}}<br />
<br />
The keyfile can be of arbitrary content and size. We will 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 device, 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 {{ic|/etc/mkinitcpio.conf}}, one for the drive's file system and one for the codepage. Further if you created a udev rule, you should tell {{ic|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 is assumed that you use a FAT formatted USB drive. 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 />
Additionally, insert the {{ic|usb}} hook somewhere before the {{ic|encrypt}} hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
If you have a non-US keyboard, it might prove useful to load your keyboard layout before you are prompted to enter the password to unlock the root partition at boot. For this, you will need the {{ic|keymap}} hook before {{ic|encrypt}}.<br />
<br />
Generate a new image (maybe you should backup a copy of your old kernel26.img first):<br />
mkinitcpio -g /boot/initramfs-linux.img<br />
<br />
==== Storing the key as a plain (visible) file ====<br />
Be sure to choose a plain name for your key &ndash; a bit of 'security through obscurity' is always nice ;-). Avoid using dotfiles (hidden files) &ndash; the {{ic|encrypt}} hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your {{ic|/boot/grub/menu.lst}} ([[GRUB]]). It should look something like this:<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes {{ic|/dev/usbstick}} is the FAT partition of your choice. Replace it with {{ic|/dev/disk/by-...}} or whatever your device is.<br />
<br />
That is all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We will write the key directly between the Master Boot Record (MBR) and the first partition.<br />
<br />
{{Warning|You should only follow this step if you know what you are doing -- '''it can cause data loss and damage your partitions or MBR on the stick!'''}}<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 do not rely on this too much), so you would have to replace {{ic|seek<nowiki>=</nowiki>4}} with {{ic|seek<nowiki>=</nowiki>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 />
''Optional''<br />
If you do not know if you have 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 {{ic|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 {{ic|/boot/grub/menu.lst}} file (GRUB); it should look something like this:<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usb:2048:2048<br />
Format for the {{ic|cryptkey}} option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
{{ic|OFFSET}} and {{ic|SIZE}} match in this example, but this is just coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usb:8192:2048<br />
That is all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
=== Encrypting the Swap partition ===<br />
<br />
==== Without suspend-to-disk 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 />
Append a similar line to {{ic|/etc/crypttab}} to set up a randomly encrypted swap partition:<br />
<br />
<device-mapper name> <swap physical partition> SWAP "-c aes-xts-plain -h whirlpool -s 512"<br />
<br />
Where:<br />
<br />
:*{{ic|<device-mapper name>}} represents the name you want to use as label in /etc/fstab<br />
:*{{ic|<swap physical partition>}} should be the ID of the actual partition. <br> {{Warning|You should use IDs here because if there are multiple hard drives installed in the system, their naming order (sda, sdb,...) can occasionally be scrambled upon boot and thus the swap would be created over a valuable file system, destroying its content. {{ic|<nowiki>ls -l /dev/disk/*/* | grep sdl7</nowiki>}} should help you to find the desired partition.}}<br />
:*{{ic|SWAP}} identifies the partition as a swap partition<br />
:*{{ic|-c}} defines a cipher<br />
:*{{ic|-h}} defines a hash algorithm<br />
:*{{ic|-s}} defines the key size<br />
<br />
Example line (where {{ic|/dev/sdl7}} is the physical partition and {{ic|<nowiki>LABEL=swap</nowiki>}} the desired label):<br />
<br />
swap /dev/disk/by-id/scsi-SATA_Hitachi_HDS7220_JK1130YAGX0R1T-part7 SWAP "-c aes-xts-plain -h whirlpool -s 512"<br />
<br />
:Maps {{ic|/dev/sdl7}} to {{ic|/dev/mapper/swap}} as a swap partition which we can now add in {{ic|/etc/fstab}} like a normal swap.<br />
<br />
If the partition chosen for swap was previously a LUKS partition, crypttab will not overwrite the partition to create a swap partition. This is a safety measure to prevent data loss from accidental mis-identification of the swap partition in crypttab. In order to use such a partition the LUKS header must be removed. This can be accomplished with:<br />
<br />
# dd if=/dev/zero of=/dev/sdl7 bs=1M<br />
<br />
==== With suspend-to-disk support ====<br />
{{Warning|Do not use this setup with a key file. Please read about the issue reported [[Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure|here]]}}<br />
<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 pre-existent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before {{ic|/etc/crypttab}} can be used, it is required to create a hook in {{ic|/etc/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 />
* Format the partition you want to use as swap with the {{ic|cryptsetup}} command. For performance reasons, you might want to use different ciphers with different key sizes.<br />
<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check the result with:<br />
<br />
# cryptsetup luksDump /dev/<device><br />
<br />
* Open the partition in {{ic|/dev/mapper}}:<br />
<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
<br />
* Create a swap filesystem inside the mapped partition:<br />
<br />
# mkswap /dev/mapper/swapDevice<br />
<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in {{ic|/etc/crypttab}} which uses this device. Now you have to create a hook to open the swap at boot time.<br />
<br />
* Create a hook file containing the open command:<br />
<br />
{{hc|/lib/initcpio/hooks/openswap|<nowiki><br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
</nowiki>}}<br />
<br />
* Then create and edit the hook setup file:<br />
{{hc|/lib/initcpio/install/openswap|<nowiki><br />
# vim: set ft=sh:<br />
build ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
</nowiki>}}<br />
<br />
* Add the hook {{ic|openswap}} in the {{ic|HOOKS}} array in {{ic|/etc/mkinitcpio.conf}}, before {{ic|filesystem}}, but '''after''' {{ic|encrypt}} which is mandatory as well. Do not forget to add the {{ic|resume}} hook between {{ic|openswap}} and {{ic|filesystem}} as well.<br />
<br />
* Regenerate the boot image:<br />
<br />
# mkinitcpio -p linux<br />
<br />
* Add the mapped partition to {{ic|/etc/fstab}} by adding the following line:<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
<br />
* Set up your system to resume from {{ic|/dev/mapper/swapDevice}}. For example, if you use [[GRUB]] with kernel hibernation support, add {{ic|resume<nowiki>=</nowiki>/dev/mapper/swapDevice}} to the kernel line in {{ic|/boot/grub/menu.lst}}. A line with encrypted root and swap partitions can look like this:<br />
<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
<br />
At boot time, the {{ic|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 are placed '''after''' {{ic|openswap}} in the {{ic|HOOKS}} array. Please note that because of initrd opening swap, there is no entry for swapDevice in {{ic|/etc/crypttab}} needed in this case.<br />
<br />
=== Using a swap file for suspend-to-disk support ===<br />
* Choose a mapped partition (e.g. {{ic|/dev/mapper/rootDevice}}) whose mounted filesystem (e.g. {{ic|/}}) contains enough free space to hold the entire contents of your system's RAM. For example, if your system has 4 GiB RAM, then you need at least that much free space on the mounted filesystem of your chosen mapped partition for the swap file.<br />
<br />
* [[HOW_TO:_Create_swap_file#Swap_file_creation | Create the swap file]] (e.g. {{ic|/swapfile}}) inside the mounted filesystem of your chosen mapped partition. Be sure to activate it with {{ic|swapon}} and also add it to your {{ic|/etc/fstab}} file afterward.<br />
<br />
* Set up your system to resume from your chosen mapped partition. For example, if you use [[GRUB]] with kernel hibernation support, add {{ic|resume<nowiki>=</nowiki>}}''your chosen mapped partition'' and {{ic|resume_offset<nowiki>=</nowiki>}}''see calculation command below'' to the kernel line in {{ic|/boot/grub/menu.lst}}. A line with encrypted root partition can look like this:<br />
<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/rootDevice resume_offset=123456789 ro<br />
<br />
You can calculate the {{ic|resume_offset}} of your swap file like this:<br />
<br />
# filefrag -v /swapfile | awk '{if($1==0){print $3}}'<br />
<br />
* Add the {{ic|resume}} hook to your {{ic|etc/mkinitcpio.conf}} file and [[Mkinitcpio#Image_creation_and_activation|rebuild the image]] afterward:<br />
<br />
HOOKS="... encrypt '''resume''' ... filesystems ..."<br />
<br />
== Installing the system ==<br />
Now that {{ic|/dev/mapper/root}} and {{ic|/dev/mapper/home}} 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 steps and go straight to manual configuration.<br />
Instead of choosing the hardware devices ({{ic|/dev/sdaX}}) directly, you have to select the mapper devices created above.<br />
Choose {{ic|/dev/mapper/root}} for your root and {{ic|/dev/mapper/home}} as {{ic|/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 {{ic|/home}} partition. Make sure you mount {{ic|/dev/sda1}} as the {{ic|/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|The {{ic|encrypt}} hook is only needed if your root partition is a ''LUKS'' partition (or a LUKS partition that needs to be mounted ''before'' root). The {{ic|encrypt}} hook is not needed if any other partition (swap, for example) is encrypted. System initialization scripts ({{ic|/etc/rc.sysinit}} and {{ic|/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 {{ic|/etc/mkinitcpio.conf}}. For detailed information about mkinitcpio and its configuration refer to [[Mkinitcpio]]. You have to make sure that your {{ic|HOOKS}} array in {{ic|/etc/mkinitcpio.conf}} looks something like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the {{ic|encrypt}} hook comes ''before'' the {{ic|filesystems}} hook. 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 {{ic|usb}} before {{ic|encrypt}} because the hooks are run in the order they appear.<br />
If you need support for foreign keymaps for your encryption password, you have to specify the hook {{ic|keymap}} as well. I suggest putting this in {{ic|/etc/mkinitcpio.conf}} immediately before {{ic|encrypt}}.<br />
<br />
If you have a USB keyboard, you will need the {{ic|usbinput}} hook in {{ic|/etc/mkinitcpio.conf}}. Without it, no USB keyboard will work in early userspace.<br />
<br />
If your root partition is a ''LUKS'' partition, add the used filesystem to the {{ic|MODULES}} section.<br />
MODULES="... ext3 ext4 xfs ..."<br />
<br />
=== Install Bootloader ===<br />
'''[[GRUB]]:''' You have to make some small changes to the entries generated by the installer by replacing {{ic|/dev/mapper/root}} with {{ic|/dev/sda3}}. The important point to remember here is to use the same {{ic|cryptdevice}} name you assigned when you initially unlocked your device. In this example, the device name is {{ic|cryptroot}}; customize yours accordingly:<br />
<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:cryptroot root=/dev/mapper/cryptroot ro<br />
initrd /initramfs-linux.img<br />
<br />
For kernels older than 2.6.37, the syntax is:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' Edit the Arch Linux section in {{ic|/etc/lilo.conf}} and include a line for the {{ic|append}} option, over the initrd, with the {{ic|root<nowiki>=</nowiki>/dev/sda3}} parameter. The {{ic|append}} section makes the same kernel line as in GRUB. Also, you can omit the {{ic|root}} option above the {{ic|image}} option. The section looks like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz-linux<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /initramfs-linux.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note|If you want to use a USB flash drive with a keyfile, you have to append the {{ic|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 {{ic|/etc/crypttab}} file so you do not have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. {{ic|/home}}, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
<br />
Add the following line for the {{ic|/home}} partition<br />
{{Note|Using a passphrase to decrypt LUKS partitions automatically from {{ic|/etc/crypttab}} is deprecated: see http://www.mail-archive.com/arch-projects@archlinux.org/msg02115.html}}<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 [[#Adding_Additional_Passphrases_or_Keyfiles_to_a_LUKS_Encrypted_Partition|above]].<br />
Then add the following information to the {{ic|/etc/crypttab}} file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
If you used a USB device to store your keyfile, you should have something like this:<br />
home /dev/sda5 /dev/sd*1/keyfile<br />
<br />
Or if the keyfile was stored in the MBR, it should be like this:<br />
home /dev/sda5 /dev/sd*:2048:2048<br />
<br />
{{Box BLUE|Note:|When reading the keyfile from the MBR it should be {{ic|/dev/sdb}} not {{ic|/dev/sdb1}} but if the key is in the filesystem it should still be {{ic|/dev/sdb1}}.}}<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 a LUKS password. Type it in and everything should boot.<br />
Once you have logged in, have a look at your mounted partitions by typing {{ic|mount}}. You should have {{ic|/dev/mapper/root}} mounted at {{ic|/}} and, if you set up a separate encrypted home partition, {{ic|/dev/mapper/home}} mounted at {{ic|/home}}. If you set up encrypted swap, {{ic|swapon -s}} should have {{ic|/dev/mapper/swap}} 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 is not, simply enter your password and press {{keypress|Enter}}.}}<br />
<br />
== Remote unlocking of the root (or other) 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 achieved by running the {{ic|net}} hook along with an [[SSH]] server in initrd. Install the {{AUR|dropbear_initrd_encrypt}} package from the [[Arch User Repository|AUR]] and follow the post-installation instructions. Replace the {{ic|encrypt}} hook with {{ic|dropbear encryptssh}} in {{ic|/etc/mkinitcpio.conf}}. Put the {{ic|net}} hook early in the HOOKS array if your DHCP server takes a long time to lease IP addresses.<br />
<br />
If you would simply like a nice solution to mount other encrypted partitions (such as {{ic|/home}})remotely, you may want to look at [https://bbs.archlinux.org/viewtopic.php?pid=880484 this forum thread].<br />
<br />
{{Note|Acutally trim will not work with this script because it is not yet updated to the latest encrypt hook, so it is not able to parse {{ic|-–allow-discards}} from {{ic|/boot/grub/menu.lst}}. (Version: dropbear_initrd_encrypt 0.8-16). You won't notice any error when using online discard, but you see an error when you try to use {{ic|fstrim}}.For a temporary solution just add {{ic|-–allow-discards}} to every cryptsetup line of {{ic|/lib/initcpio/install/dropbear}}(1 line) and {{ic|/lib/initcpio/hooks/encryptssh}}(3 lines)}}<br />
<br />
== Backup the cryptheader ==<br />
If the header of your encrypted partition gets destroyed, you will not be able to decrypt your data. Therefore, having a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT backing up the cryptheader, but even so it's a single point of failure!<br />
In short, the problem is that LUKS is not aware of the duplicated cryptheader, which contains the master key which is used to encrypt all files on your partition. Of course this master key 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 master key 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]{{Linkrot|2011|09|05}} for further details on this.<br />
<br />
{{Note|You can also back up 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 />
=== Backup ===<br />
==== Manually ====<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 />
==== Using cryptsetup ====<br />
You can also use the luksHeaderBackup command instead:<br />
cryptsetup luksHeaderBackup /dev/sdaX --header-backup-file ./backup.img<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 />
==== Manually ====<br />
Again, you will need to the same values as when backing up:<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
==== Using cryptsetup ====<br />
Or you can use the luksHeaderRestore command:<br />
cryptsetup luksHeaderRestore /dev/sdaX --header-backup-file ./backup.img<br />
<br />
'''Note:''' All the keyslot areas are overwritten; only active keyslots from the backup file are available after issuing this command.<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 />
First, start by creating an encrypted container!<br />
<br />
dd if=/dev/urandom of=/bigsecret bs=1M count=10<br />
<br />
This will create the file {{ic|bigsecret}} with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node {{ic|/dev/loop0}}, so that we can mount/use our container.<br />
<br />
{{Note|If it gives you the error {{ic|/dev/loop0: No such file or directory}}, you need to first load the kernel module with {{ic|modprobe loop}}. These days (Kernel 3.2) loop devices are created on demand. Ask for a new loop device with {{ic|losetup -f}}.}}<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file.<br />
<br />
{{Note|If you get an error like {{ic|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 {{ic|modprobe dm-mod}}.}}<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the device file {{ic|/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 />
=== Encrypt using a key-file ===<br />
Let us 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 {{ic|/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 encrypting your keyfile using your private GPG key and storing an off-site 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 expand our container file with the size of the data we want to add:<br />
<br />
dd if=/dev/urandom bs=1M count=1024 | cat - >> /bigsecret<br />
<br />
Be careful to really use TWO {{ic|>}}, or you will override your current container!<br />
<br />
You could use {{ic|/dev/zero}} instead of {{ic|/dev/urandom}} to significantly speed up the process, but with {{ic|/dev/zero}} your encrypted filesystems will ''not be as secure''. (A better option to create random data quicker than {{ic|/dev/urandom}} is {{ic|frandom}} [https://aur.archlinux.org/packages.php?ID=9869], available from the [[AUR]]).<br />
<br />
Now we have to map the container to the loop device:<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 do not 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 the {{ic|encrypt}} hook '''before''' the {{ic|lvm2}} hook (and those two before the {{ic|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 set up your LVM volumes and then use them as the base for the encrypted partitions. That means, in short, that you have to set up LVM first. Then follow this guide, but replace all occurrences of {{ic|/dev/sdXy}} in the guide with its LVM counterpart. (E.g.: {{ic|/dev/sda5}} -> {{ic|/dev/<volume group name>/home}}).<br />
<br />
Do not forget to add the {{ic|encrypt}} hook in {{ic|/etc/mkinitcpio.conf}} '''before''' the {{ic|lvm2}} hook, if you chose to set up encrypted partitions on '''top''' of LVM. Also remember to change {{ic|USELVM}} in {{ic|/etc/rc.conf}} to {{ic|"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 partition 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 {{ic|/etc/rc.conf}} set {{ic|USELVM}} to {{ic|"yes"}}<br />
* In {{ic|/etc/mkinitcpio.conf}} add the {{ic|encrypt}} hook '''before''' the {{ic|lvm2}} hook in the {{ic|HOOKS}} array, if you set up LVM on top of the encrypted partition.<br />
<br />
That is 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 {{ic|/lib/initcpio/hooks/encrypt}} (the first one to your {{ic|/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 {{ic|/etc/crypttab}} with an external key file (i.e. the keyfile is not on any internal hard drive 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 the order of {{ic|/etc/fstab}} (at least).<br />
<br />
Of course, if the {{Pkg|cryptsetup}} package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking {{ic|/etc/rc.sysinit}} or similar files. Unlike {{ic|/etc/crypttab}}, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
If you want to do this on a software RAID partition, there is one more thing you need to do. Just setting the {{ic|/dev/mdX}} device in {{ic|/lib/initcpio/hooks/encrypt}} is not enough; the {{ic|encrypt}} hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices are not brought up until after the {{ic|encrypt}} hook is run. You can solve this by putting the RAID array in {{ic|/boot/grub/menu.lst}}, like <br />
kernel /boot/vmlinuz-linux md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID, you will notice the similarities with that setup ;-). [[GRUB]] can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz-linux root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM and dm-crypt manually (short version) ===<br />
<br />
==== Notes ====<br />
If you are smart enough for this, you will be smart enough to ignore/replace LVM-specific things if you do not want to use LVM.<br />
<br />
{{Note|This brief uses reiserfs for some of the partitions, so change this accordingly if you want to use a more "normal" file system, like ext4.}}<br />
<br />
==== Partitioning scheme ====<br />
{{ic|/dev/sda1}} -> {{ic|/boot}}<br />
{{ic|/dev/sda2}} -> LVM<br />
<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 />
<br />
==== Install Arch Linux ====<br />
Run {{ic|/arch/setup}}<br />
<br />
==== Configuration ====<br />
<br />
===== /etc/rc.conf =====<br />
Change {{ic|USELVM<nowiki>=</nowiki>"no"}} to {{ic|USELVM<nowiki>=</nowiki>"yes"}}.<br />
<br />
===== /etc/mkinitcpio.conf =====<br />
Put {{ic|lvm2}} and {{ic|encrypt}} (in that order) before {{ic|filesystems}} in the {{ic|HOOKS}} array. Again, note that you are setting encryption on '''top''' of LVM.)<br />
<br />
if you want install the system on a usb stick, you need to put {{ic|usb}} just after {{ic|udev}}.<br />
<br />
===== /boot/grub/menu.lst =====<br />
Change {{ic|root<nowiki>=</nowiki>/dev/hda3}} to {{ic|root<nowiki>=</nowiki>/dev/lvm/root}}.<br />
<br />
For kernel >= 2.6.30, you should change {{ic|root<nowiki>=</nowiki>/dev/hda3}} to the following:<br />
cryptdevice=/dev/lvm/root:root root=/dev/mapper/root<br />
<br />
if you want install the system on a usb stick, you need to add {{ic|lvmdelay<nowiki>=</nowiki>/dev/mapper/lvm-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 rebooting ====<br />
<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 />
<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on LVM on LUKS ===<br />
Make sure your kernel command line 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 />
==Using GPG or OpenSSL Encrypted Keyfiles==<br />
The following forum posts give instructions to use two factor authentication, gpg or openssl encrypted keyfiles, instead of a plaintext keyfile described earlier in this wiki article [https://bbs.archlinux.org/viewtopic.php?id=120243 System Encryption using LUKS with GPG encrypted keys]:<br />
* GnuPG: [https://bbs.archlinux.org/viewtopic.php?pid=943338#p943338 Post regarding GPG encrypted keys] This post hs the generic instructions.<br />
* OpenSSL: [https://bbs.archlinux.org/viewtopic.php?pid=947805#p947805 Post regarding OpenSSL encrypted keys] This post only has the {{ic|ssldec}} hooks.<br />
<br />
Note that:<br />
* You can follow the above instructions with only two primary partitions one boot partition <br />
(required because of LVM), and one primary LVM partition. Within the LVM partition you can have <br />
as many partitions as you need, but most importantly it should contain at least root, swap, and <br />
home logical volume partitions. This has the added benefit of having only one keyfile for all <br />
your partitions, and having the ability to hibernate your computer (suspend to disk) where the <br />
swap partition is encrypted. If you decide to do so your hooks in {{ic|/etc/mkinitcpio.conf}} <br />
should look like<br />
{{ic|HOOKS&#61;" ... usb usbinput (etwo or ssldec) encrypt(if using openssl) lvm2 resume ... "}}<br />
and you should add to your {{ic|kernel}} line(if using grub, {{ic|/boot/grub/menu.lst}}) or <br />
{{ic|GRUB_CMD_LINE}}(if using grub2, {{ic|/etc/default/grub}}):<br />
{{ic|"resume&#61;/dev/mapper/<VolumeGroupName>-<LVNameOfSwap>"}}<br />
* If you need to temporarily store the unecrypted keyfile somewhere, do not store them on an <br />
unencrytped disk. Even better make sure to store them to RAM such as {{ic|/dev/shm}}.<br />
* If you want to use a GPG encrypted keyfile, you need to use a statically compiled GnuPG version 1.4 or you could edit the hooks and use this AUR package [https://aur.archlinux.org/packages.php?ID=58030 gnupg1]<br />
* It is possible that an update to OpenSSL could break the custom {{ic|ssldec}} mentioned in the second forum post.<br />
<br />
==Securing the unencrypted boot partition==<br />
Referring to an article from the ct-magazine (Issue 3/12, page 146, 01.16.2012 http://www.heise.de/ct/inhalt/2012/03/6/) the following script checks all files under {{ic|/boot}} for changes of SHA-1 hash, inode and occupied blocks on the hard drive. It also checks the MBR.<br />
<br />
The script with installation instructions is available here: ftp://ftp.heise.de/pub/ct/listings/1203-146.zip (Author: Juergen Schmidt, ju at heisec.de; License: GPLv2)<br />
<br />
There is also an AUR package: {{AUR|chkboot}}<br />
<br />
After installation, add {{ic|/usr/local/bin/chkboot.sh &}} to your {{ic|/etc/rc.local}}.<br />
<br />
And as {{ic|/usr/local/bin/chkboot_user.sh}} need to be excuted after login, add it to the autostarts (e.g. under KDE -> System Settings -> Startup and Shutdown -> Autostart)<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Install Arch Linux on top of RAID, LVM2, and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Airbus001https://wiki.archlinux.org/index.php?title=Dm-crypt&diff=209422Dm-crypt2012-06-15T23:20:05Z<p>Airbus001: /* Using GPG or OpenSSL Encrypted Keyfiles */</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[ru:System Encryption with LUKS]]<br />
[[zh-CN:System Encryption with LUKS]]<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 />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
==== Data encryption ====<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
*Preventing unauthorized physical access to private data.<br />
*Some confidence in data disposal when discarding obsolete systems.<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 />
==== System encryption ====<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 />
*Preventing unauthorized physical access to operating system files<br />
*Preventing unauthorized physical access to private data that may cached by the system.<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 />
*Attempts to bypass the operating system by inserting a boot CD/USB<br />
*Copying, modifying, or removing the hard disk drives when the computer is off<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the {{ic|/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 />
{{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 Available for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption, including:<br />
<br />
;loop-AES ([http://loop-aes.sourceforge.net/ loop-AES]):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 />
;standard device-mapper encryption ([http://www.saout.de/misc/dm-crypt/ dm-crypt]):This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
;LUKS for dm-crypt ([http://code.google.com/p/cryptsetup/ LUKS]):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 />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key (see [[Wikipedia:Kerckhoffs's principle]])<br />
::*The usage of a proven encryption algorithm<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 />
====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 />
====discard/TRIM support for solid state disks====<br />
<br />
Solid state disk users should be aware that by default, Linux's full-disk encryption mechanisms will ''not'' forward TRIM commands from the filesystem to the underlying disk. The device-mapper maintainers have made it clear that TRIM support will never be enabled by default on dm-crypt devices because of the potential security implications; if TRIM support were enabled, an attacker may be able to tell which blocks have been used, how many blocks have been used, and other information that is exposed directly to the device when a TRIM is issued.<br />
<br />
It may be possible to determine the filesystem utilized by your encrypted device through the data that is leaked by TRIM. Furthermore, any information that may be derived by a profile of block usage may be exposed by enabling TRIM support on an encrypted device.<br />
<br />
As of {{Pkg|linux}} version 3.1, support for dm-crypt TRIM pass-through can be toggled upon device creation or mount with dmsetup. Support for this option also exists in {{Pkg|cryptsetup}} version 1.4.0 and up. To add support during boot, you will need to add "{{ic|:allow-discards}}" to the {{ic|cryptdevice}} option. The option should look like this:<br />
cryptdevice=/dev/mapper/root:root:allow-discards<br />
<br />
For more information, including specific commands and details on dm-crypt TRIM pass-through, see these mailing list threads:<br />
* http://article.gmane.org/gmane.linux.kernel.device-mapper.devel/14134<br />
* http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/5166<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 shut down. 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 to extract your encryption key - thus obtaining access to your data.<br />
<br />
{{Note|System Encryption assumes encryption of all mounted partitions: this includes all partitions except for {{ic|/boot}} - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, {{ic|/tmp}}, or root filesystems are unencrypted, only Data Encryption level of security has been accomplished.}}<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 />
=====Encryption of data partitions on the same physical disk as the system=====<br />
<br />
The most common form of data encryption is encrypting the {{ic|/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 decreased by orders of magnitude when compared to system encryption. The reason for this is 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, {{Pkg|mlocate}} will scan all currently mounted file systems regularly and write the list of filenames to {{ic|/var/lib/mlocate/mlocate.db}}, which is located in the non-encrypted root or {{ic|/var}} partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted {{ic|/home}} partition, readily available to assist them in accessing the encrypted data present on 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|System Encryption with eCryptfs]].<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 Hard Disk Drives or Separate Internal Hard Disk Drives<br />
::*CD/DVD/Blu-Ray Optical Media<br />
::*Magnetic Storage Media<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 set up.<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the hard disk 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 Hard Disk Drive ===<br />
<br />
Secure erasure of the hard disk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a hard disk 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 />
====Why perform secure erasure of a drive?====<br />
<br />
There are two types of hard disk 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 Hard Disk Drives'''<br />
<br />
::In hard drives 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 Hard Disk Drives'''<br />
<br />
::Repartitioning or reformatting a used hard drive 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 straightforward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore hard drives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
====Overwriting a hard disk drive with random data====<br />
<br />
There are two sources of random data commonly used for securely overwriting hard disk partitions.<br />
<br />
::*{{ic|/dev/urandom}}<br />
::*badblocks<br />
<br />
=====Using urandom=====<br />
<br />
#dd if=/dev/urandom of=/dev/<drive> bs=1M<br />
<br />
Where {{ic|/dev/<drive>}} is the drive to be encrypted.<br />
<br />
{{Note| Using {{ic|/dev/urandom}} will take a long time to completely overwrite a drive with "random" data. In the strictest sense, {{ic|/dev/urandom}} is less random than {{ic|/dev/random}}; however, {{ic|/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 {{ic|/dev/random}} for overwriting hard disks impractical.}}<br />
<br />
{{Note| Users may also find that {{ic|/dev/urandom}} takes an excessively long time on large drives of several hundred gigabytes or more (more than twenty-four hours). [[Frandom]] offers a faster alternative.}}<br />
<br />
{{Note|You can retrieve progress of the dd command with this command: {{ic|kill -USR1 $(pidof dd)}}}}<br />
<br />
=====Using badblocks=====<br />
<br />
#badblocks -c 10240 -wsvt random /dev/<drive><br />
<br />
Where {{ic|/dev/<drive>}} is the drive to be encrypted.<br />
<br />
{{Note|The {{ic|badblocks}} command overwrites the drive at a much faster rate by generating data that is not truly random.}}<br />
<br />
See also [[badblocks]].<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a hard disk 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 />
=====After installation=====<br />
Essentially the same effect can be achieved if a file is created on each of the partitions that fills the partition completely '''after''' the system is installed and booted with encrypted partitions mounted. <br />
#dd if=/dev/zero of=/path/to/the/output/file<br />
#rm /path/to/the/input/file<br />
Just make sure that you do that for every partition on the filesystem. This works as encrypted data is indistinguishabe from random, so anone trying to access potential leftover files will just see random data.<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 with systems that require 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 three flavors: primary partitions, extended partitions, and logical partitions.<br />
<br />
;Primary Partitions: These are the normal partitions recognized by the system BIOS. There can be up to four of these stored in the MBR.<br />
<br />
;Extended Partitions: These are primary partitions that also define another partition within themselves. Extended partitions were created to work around the original limit of four primary partitions.<br />
<br />
;Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
====LVM: Logical Volume Manager====<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple hard disk drives and partitions that are not possible with standard partitions. LVM is covered in detail in the [[LVM|Arch Linux LVM Wiki Article]] which is recommended reading prior to continuing with the instructions on setting up LUKS with LVM located below.<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 is that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In this case, logical volume management would be layered on top of the hardware encryption &ndash; usage of LUKS would be superfluous.<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 two required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*{{ic|'''/'''}}<br />
:::*Will be encrypted and store all system and user files ({{ic|/usr}}, {{ic|/bin}}, {{ic|/var}}, {{ic|/home}}, etc.)<br />
<br />
::An initial boot partition<br />
<br />
:::*{{ic|'''/boot'''}}<br />
:::*Will ''not'' be encrypted; the bootloader needs to access the {{ic|/boot}} directory where it will load the initramfs/encryption modules needed to load the rest of the system which ''is'' encrypted (see [[Mkinitcpio]] for details). For this reason, {{ic|/boot}} needs to reside on its own, unencrypted partition.<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 />
=====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 used, the space unoccupied by {{ic|/boot}} and swap should be defined as single large partition which will be divided up later at the LVM level.<br />
<br />
=====Multiple Disk Systems=====<br />
<br />
In systems that will have multiple hard disk drives, the same options exist as a single disk system. After the creation of the {{ic|/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 {{ic|/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 the dialogue for manual configuration of the hard drive.<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 per LUKS partition.<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
{{Note|Using a passphrase to decrypt LUKS partitions automatically from {{ic|/etc/crypttab}} is deprecated: see http://www.mail-archive.com/arch-projects@archlinux.org/msg02115.html}}<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
A full list of options {{ic|cryptsetup}} accepts can be found in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::*{{ic|-c}} defines the cipher type<br />
::*{{ic|-y}} prompts for password confirmation on password creation<br />
::*{{ic|-s}} defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
In the following examples for creating LUKS partitions, we will use the AES cipher in XTS mode; at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup, and details about them can be found here: [[Wikipedia:Block_cipher]]<br />
<br />
'''Formatting LUKS Partitions'''<br />
<br />
First of all make sure the device mapper kernel module is loaded by executing the following: {{ic|# modprobe dm_mod}}<br />
<br />
In order to format a desired partition as an encrypted LUKS partition execute:<br />
{{hc|# cryptsetup -c <cipher> -y -s <key size> luksFormat /dev/<partition name>|<br />
Enter passphrase: <password><br />
Verify passphrase: <password>}}<br />
<br />
This should be repeated for all partitions except for {{ic|/boot}} and possibly swap.<br />
<br />
The example below will create an encrypted root partition using the AES cipher in XTS mode (generally referred to as ''XTS-AES'').<br />
{{bc|cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2}}<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 the chosen partitioning method, the {{ic|/boot}} partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<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 {{ic|/dev/<partition name>}} is actually an encrypted device and should be addressed through LUKS using the {{ic|/dev/mapper/<name>}} so as not to overwrite the encrypted data. <br />
<br />
In order to open an encrypted LUKS partition execute:<br />
{{hc|# cryptsetup luksOpen /dev/<partition name> <device-mapper name>|<br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.}}<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
::*cryptsetup luksOpen /dev/sda2 '''swap'''<br />
::::Once opened, the swap partition device address would be '''{{ic|/dev/mapper/swap}}''' instead of {{ic|/dev/sda2}}.<br />
<br />
::*cryptsetup luksOpen /dev/sda3 '''root'''<br />
::::Once opened, the root partition device address would be '''{{ic|/dev/mapper/root}}''' instead of {{ic|/dev/sda3}}.<br />
<br />
{{Note|Since {{ic|/boot}} is not encrypted, it does not need a device mapped name and will be addressed as {{ic|/dev/sda1}}.}}<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 Partitions with a Keyfile ====<br />
{{Note|This section describes using a plaintext keyfile, if you want to encrypt your keyfile giving you two factor authentication see [https://wiki.archlinux.org/index.php/System_Encryption_with_LUKS#Using_GPG_or_OpenSSL_Encrypted_Keyfiles Section 9] for details, but please still read this section.}}<br />
<br />
'''What is a Keyfile?'''<br />
<br />
A keyfile is any file in which the data contained within it 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 />
{{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 />
'''Why use a Keyfile?'''<br />
<br />
There are many kinds of keyfile. Each type of keyfile used has benefits and disadvantages summarized below:<br />
<br />
:'''keyfile.passphrase:'''<br />
::this is my passphrase I would have typed during boot but I have placed it in a file instead<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 add any security over entering a passphrase during the initial system start.<br />
<br />
:'''keyfile.randomtext:'''<br />
::fjqweifj830149-57 819y4my1- 38t1934yt8-91m 34co3;t8y;9p3y-<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 />
:'''keyfile.binary:'''<br />
::where any binary file, images, text, video could be chosen as the keyfile<br />
<br />
This is a binary file that has been defined as a keyfile. When identifying files as candidates for a keyfile, it is recommended to choose files that are relatively static such as photos, music, video clips. The benefit of these files is that they serve a dual function which can make them harder to identify as keyfiles. Instead of having a text file with a large amount of random text, the keyfile would look like a regular image file or music clip to the casual observer. The disadvantage is that if this file is lost or changed, it will most likely not be possible to access the encrypted volume without a backup passphrase. Additionally, there is a theoretical loss of randomness when compared to a randomly generated text file. This is due to the fact that images, videos and music have some intrinsic relationship between neighboring bits of data that does not exist for a text file. However this is controversial and has never been exploited publicly.<br />
<br />
'''Creating a Keyfile with Random Characters'''<br />
<br />
Here {{ic|dd}} is used to generate a keyfile of 2048 bits of random characters.<br />
<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
The usage of {{ic|dd}} is similar to initially wiping the volume with random data prior to encryption. <br />
<br />
{{Warning|Do not use [[badblocks]] here. It only generate a random pattern which just repeats its randomness over and over again.}}<br />
<br />
'''Creating a new LUKS encrypted partition with a Keyfile'''<br />
<br />
When creating a new LUKS encrypted partition, a keyfile may be associated with the partition on its creation using:<br />
<br />
# cryptsetup -c <desired cipher> -s <key size> luksFormat /dev/<volume to encrypt> '''/path/to/mykeyfile'''<br />
<br />
This is accomplished by appending the bold area to the standard cryptsetup command which defines where the keyfile is located.<br />
<br />
==== Adding Additional Passphrases or Keyfiles to a LUKS Encrypted Partition ====<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 slot 0.<br />
Additional keys will occupy slots 1&ndash;7.<br />
<br />
The addition of new keys to an encrypted partition is accomplished using cryptsetup with the {{ic|luksAddKey}} extension.<br />
<br />
# cryptsetup luksAddKey /dev/<encrypted volume> '''/path/to/mykeyfile'''<br />
<br />
Where {{ic|/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 is important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. {{ic|/dev/sdb1}} 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 {{ic|encrypt}} HOOK in the initcpio finds your keyfile, you must 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 the following:<br />
<br />
{{hc|# ls -l /dev/disk/by-label/|<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1}}<br />
<br />
or<br />
<br />
{{hc|# 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 {{ic|/dev/disk/by-label/Keys}}, or if I had wanted to use the UUID I would find {{ic|/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 ({{ic|sdb1}}, {{ic|sdb2}}, ...) but not to the USB device ({{ic|sdb}}) 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 flash drive with a [[udev]] rule. There is 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 is quickly how it goes.<br />
<br />
Get the serial number from your USB flash drive:<br />
lsusb -v | grep -A 5 Vendor<br />
<br />
Create a udev rule for it by adding the following to a file in {{ic|/etc/udev/rules.d/}}, such as {{ic|8-usbstick.rules}}:<br />
KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"<br />
<br />
Replace {{ic|$SYMLINK}} and {{ic|$SERIAL}} with their respective values. {{ic|%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 {{ic|/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. {{ic|/media/sdb1}}<br />
<br />
The keyfile can be of arbitrary content and size. We will 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 device, 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 {{ic|/etc/mkinitcpio.conf}}, one for the drive's file system and one for the codepage. Further if you created a udev rule, you should tell {{ic|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 is assumed that you use a FAT formatted USB drive. 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 />
Additionally, insert the {{ic|usb}} hook somewhere before the {{ic|encrypt}} hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
If you have a non-US keyboard, it might prove useful to load your keyboard layout before you are prompted to enter the password to unlock the root partition at boot. For this, you will need the {{ic|keymap}} hook before {{ic|encrypt}}.<br />
<br />
Generate a new image (maybe you should backup a copy of your old kernel26.img first):<br />
mkinitcpio -g /boot/initramfs-linux.img<br />
<br />
==== Storing the key as a plain (visible) file ====<br />
Be sure to choose a plain name for your key &ndash; a bit of 'security through obscurity' is always nice ;-). Avoid using dotfiles (hidden files) &ndash; the {{ic|encrypt}} hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your {{ic|/boot/grub/menu.lst}} ([[GRUB]]). It should look something like this:<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes {{ic|/dev/usbstick}} is the FAT partition of your choice. Replace it with {{ic|/dev/disk/by-...}} or whatever your device is.<br />
<br />
That is all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We will write the key directly between the Master Boot Record (MBR) and the first partition.<br />
<br />
{{Warning|You should only follow this step if you know what you are doing -- '''it can cause data loss and damage your partitions or MBR on the stick!'''}}<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 do not rely on this too much), so you would have to replace {{ic|seek<nowiki>=</nowiki>4}} with {{ic|seek<nowiki>=</nowiki>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 />
''Optional''<br />
If you do not know if you have 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 {{ic|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 {{ic|/boot/grub/menu.lst}} file (GRUB); it should look something like this:<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usb:2048:2048<br />
Format for the {{ic|cryptkey}} option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
{{ic|OFFSET}} and {{ic|SIZE}} match in this example, but this is just coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usb:8192:2048<br />
That is all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
=== Encrypting the Swap partition ===<br />
<br />
==== Without suspend-to-disk 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 />
Append a similar line to {{ic|/etc/crypttab}} to set up a randomly encrypted swap partition:<br />
<br />
<device-mapper name> <swap physical partition> SWAP "-c aes-xts-plain -h whirlpool -s 512"<br />
<br />
Where:<br />
<br />
:*{{ic|<device-mapper name>}} represents the name you want to use as label in /etc/fstab<br />
:*{{ic|<swap physical partition>}} should be the ID of the actual partition. <br> {{Warning|You should use IDs here because if there are multiple hard drives installed in the system, their naming order (sda, sdb,...) can occasionally be scrambled upon boot and thus the swap would be created over a valuable file system, destroying its content. {{ic|<nowiki>ls -l /dev/disk/*/* | grep sdl7</nowiki>}} should help you to find the desired partition.}}<br />
:*{{ic|SWAP}} identifies the partition as a swap partition<br />
:*{{ic|-c}} defines a cipher<br />
:*{{ic|-h}} defines a hash algorithm<br />
:*{{ic|-s}} defines the key size<br />
<br />
Example line (where {{ic|/dev/sdl7}} is the physical partition and {{ic|<nowiki>LABEL=swap</nowiki>}} the desired label):<br />
<br />
swap /dev/disk/by-id/scsi-SATA_Hitachi_HDS7220_JK1130YAGX0R1T-part7 SWAP "-c aes-xts-plain -h whirlpool -s 512"<br />
<br />
:Maps {{ic|/dev/sdl7}} to {{ic|/dev/mapper/swap}} as a swap partition which we can now add in {{ic|/etc/fstab}} like a normal swap.<br />
<br />
If the partition chosen for swap was previously a LUKS partition, crypttab will not overwrite the partition to create a swap partition. This is a safety measure to prevent data loss from accidental mis-identification of the swap partition in crypttab. In order to use such a partition the LUKS header must be removed. This can be accomplished with:<br />
<br />
# dd if=/dev/zero of=/dev/sdl7 bs=1M<br />
<br />
==== With suspend-to-disk support ====<br />
{{Warning|Do not use this setup with a key file. Please read about the issue reported [[Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure|here]]}}<br />
<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 pre-existent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before {{ic|/etc/crypttab}} can be used, it is required to create a hook in {{ic|/etc/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 />
* Format the partition you want to use as swap with the {{ic|cryptsetup}} command. For performance reasons, you might want to use different ciphers with different key sizes.<br />
<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check the result with:<br />
<br />
# cryptsetup luksDump /dev/<device><br />
<br />
* Open the partition in {{ic|/dev/mapper}}:<br />
<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
<br />
* Create a swap filesystem inside the mapped partition:<br />
<br />
# mkswap /dev/mapper/swapDevice<br />
<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in {{ic|/etc/crypttab}} which uses this device. Now you have to create a hook to open the swap at boot time.<br />
<br />
* Create a hook file containing the open command:<br />
<br />
{{hc|/lib/initcpio/hooks/openswap|<nowiki><br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
</nowiki>}}<br />
<br />
* Then create and edit the hook setup file:<br />
{{hc|/lib/initcpio/install/openswap|<nowiki><br />
# vim: set ft=sh:<br />
build ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
</nowiki>}}<br />
<br />
* Add the hook {{ic|openswap}} in the {{ic|HOOKS}} array in {{ic|/etc/mkinitcpio.conf}}, before {{ic|filesystem}}, but '''after''' {{ic|encrypt}} which is mandatory as well. Do not forget to add the {{ic|resume}} hook between {{ic|openswap}} and {{ic|filesystem}} as well.<br />
<br />
* Regenerate the boot image:<br />
<br />
# mkinitcpio -p linux<br />
<br />
* Add the mapped partition to {{ic|/etc/fstab}} by adding the following line:<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
<br />
* Set up your system to resume from {{ic|/dev/mapper/swapDevice}}. For example, if you use [[GRUB]] with kernel hibernation support, add {{ic|resume<nowiki>=</nowiki>/dev/mapper/swapDevice}} to the kernel line in {{ic|/boot/grub/menu.lst}}. A line with encrypted root and swap partitions can look like this:<br />
<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
<br />
At boot time, the {{ic|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 are placed '''after''' {{ic|openswap}} in the {{ic|HOOKS}} array. Please note that because of initrd opening swap, there is no entry for swapDevice in {{ic|/etc/crypttab}} needed in this case.<br />
<br />
=== Using a swap file for suspend-to-disk support ===<br />
* Choose a mapped partition (e.g. {{ic|/dev/mapper/rootDevice}}) whose mounted filesystem (e.g. {{ic|/}}) contains enough free space to hold the entire contents of your system's RAM. For example, if your system has 4 GiB RAM, then you need at least that much free space on the mounted filesystem of your chosen mapped partition for the swap file.<br />
<br />
* [[HOW_TO:_Create_swap_file#Swap_file_creation | Create the swap file]] (e.g. {{ic|/swapfile}}) inside the mounted filesystem of your chosen mapped partition. Be sure to activate it with {{ic|swapon}} and also add it to your {{ic|/etc/fstab}} file afterward.<br />
<br />
* Set up your system to resume from your chosen mapped partition. For example, if you use [[GRUB]] with kernel hibernation support, add {{ic|resume<nowiki>=</nowiki>}}''your chosen mapped partition'' and {{ic|resume_offset<nowiki>=</nowiki>}}''see calculation command below'' to the kernel line in {{ic|/boot/grub/menu.lst}}. A line with encrypted root partition can look like this:<br />
<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/rootDevice resume_offset=123456789 ro<br />
<br />
You can calculate the {{ic|resume_offset}} of your swap file like this:<br />
<br />
# filefrag -v /swapfile | awk '{if($1==0){print $3}}'<br />
<br />
* Add the {{ic|resume}} hook to your {{ic|etc/mkinitcpio.conf}} file and [[Mkinitcpio#Image_creation_and_activation|rebuild the image]] afterward:<br />
<br />
HOOKS="... encrypt '''resume''' ... filesystems ..."<br />
<br />
== Installing the system ==<br />
Now that {{ic|/dev/mapper/root}} and {{ic|/dev/mapper/home}} 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 steps and go straight to manual configuration.<br />
Instead of choosing the hardware devices ({{ic|/dev/sdaX}}) directly, you have to select the mapper devices created above.<br />
Choose {{ic|/dev/mapper/root}} for your root and {{ic|/dev/mapper/home}} as {{ic|/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 {{ic|/home}} partition. Make sure you mount {{ic|/dev/sda1}} as the {{ic|/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|The {{ic|encrypt}} hook is only needed if your root partition is a ''LUKS'' partition (or a LUKS partition that needs to be mounted ''before'' root). The {{ic|encrypt}} hook is not needed if any other partition (swap, for example) is encrypted. System initialization scripts ({{ic|/etc/rc.sysinit}} and {{ic|/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 {{ic|/etc/mkinitcpio.conf}}. For detailed information about mkinitcpio and its configuration refer to [[Mkinitcpio]]. You have to make sure that your {{ic|HOOKS}} array in {{ic|/etc/mkinitcpio.conf}} looks something like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the {{ic|encrypt}} hook comes ''before'' the {{ic|filesystems}} hook. 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 {{ic|usb}} before {{ic|encrypt}} because the hooks are run in the order they appear.<br />
If you need support for foreign keymaps for your encryption password, you have to specify the hook {{ic|keymap}} as well. I suggest putting this in {{ic|/etc/mkinitcpio.conf}} immediately before {{ic|encrypt}}.<br />
<br />
If you have a USB keyboard, you will need the {{ic|usbinput}} hook in {{ic|/etc/mkinitcpio.conf}}. Without it, no USB keyboard will work in early userspace.<br />
<br />
If your root partition is a ''LUKS'' partition, add the used filesystem to the {{ic|MODULES}} section.<br />
MODULES="... ext3 ext4 xfs ..."<br />
<br />
=== Install Bootloader ===<br />
'''[[GRUB]]:''' You have to make some small changes to the entries generated by the installer by replacing {{ic|/dev/mapper/root}} with {{ic|/dev/sda3}}. The important point to remember here is to use the same {{ic|cryptdevice}} name you assigned when you initially unlocked your device. In this example, the device name is {{ic|cryptroot}}; customize yours accordingly:<br />
<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:cryptroot root=/dev/mapper/cryptroot ro<br />
initrd /initramfs-linux.img<br />
<br />
For kernels older than 2.6.37, the syntax is:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' Edit the Arch Linux section in {{ic|/etc/lilo.conf}} and include a line for the {{ic|append}} option, over the initrd, with the {{ic|root<nowiki>=</nowiki>/dev/sda3}} parameter. The {{ic|append}} section makes the same kernel line as in GRUB. Also, you can omit the {{ic|root}} option above the {{ic|image}} option. The section looks like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz-linux<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /initramfs-linux.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note|If you want to use a USB flash drive with a keyfile, you have to append the {{ic|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 {{ic|/etc/crypttab}} file so you do not have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. {{ic|/home}}, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
<br />
Add the following line for the {{ic|/home}} partition<br />
{{Note|Using a passphrase to decrypt LUKS partitions automatically from {{ic|/etc/crypttab}} is deprecated: see http://www.mail-archive.com/arch-projects@archlinux.org/msg02115.html}}<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 [[#Adding_Additional_Passphrases_or_Keyfiles_to_a_LUKS_Encrypted_Partition|above]].<br />
Then add the following information to the {{ic|/etc/crypttab}} file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
If you used a USB device to store your keyfile, you should have something like this:<br />
home /dev/sda5 /dev/sd*1/keyfile<br />
<br />
Or if the keyfile was stored in the MBR, it should be like this:<br />
home /dev/sda5 /dev/sd*:2048:2048<br />
<br />
{{Box BLUE|Note:|When reading the keyfile from the MBR it should be {{ic|/dev/sdb}} not {{ic|/dev/sdb1}} but if the key is in the filesystem it should still be {{ic|/dev/sdb1}}.}}<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 a LUKS password. Type it in and everything should boot.<br />
Once you have logged in, have a look at your mounted partitions by typing {{ic|mount}}. You should have {{ic|/dev/mapper/root}} mounted at {{ic|/}} and, if you set up a separate encrypted home partition, {{ic|/dev/mapper/home}} mounted at {{ic|/home}}. If you set up encrypted swap, {{ic|swapon -s}} should have {{ic|/dev/mapper/swap}} 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 is not, simply enter your password and press {{keypress|Enter}}.}}<br />
<br />
== Remote unlocking of the root (or other) 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 achieved by running the {{ic|net}} hook along with an [[SSH]] server in initrd. Install the {{AUR|dropbear_initrd_encrypt}} package from the [[Arch User Repository|AUR]] and follow the post-installation instructions. Replace the {{ic|encrypt}} hook with {{ic|dropbear encryptssh}} in {{ic|/etc/mkinitcpio.conf}}. Put the {{ic|net}} hook early in the HOOKS array if your DHCP server takes a long time to lease IP addresses.<br />
<br />
If you would simply like a nice solution to mount other encrypted partitions (such as {{ic|/home}})remotely, you may want to look at [https://bbs.archlinux.org/viewtopic.php?pid=880484 this forum thread].<br />
<br />
{{Note|Acutally trim will not work with this script because it is not yet updated to the latest encrypt hook, so it is not able to parse {{ic|-–allow-discards}} from {{ic|/boot/grub/menu.lst}}. (Version: dropbear_initrd_encrypt 0.8-16). You won't notice any error when using online discard, but you see an error when you try to use {{ic|fstrim}}.For a temporary solution just add {{ic|-–allow-discards}} to every cryptsetup line of {{ic|/lib/initcpio/install/dropbear}}(1 line) and {{ic|/lib/initcpio/hooks/encryptssh}}(3 lines)}}<br />
<br />
== Backup the cryptheader ==<br />
If the header of your encrypted partition gets destroyed, you will not be able to decrypt your data. Therefore, having a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT backing up the cryptheader, but even so it's a single point of failure!<br />
In short, the problem is that LUKS is not aware of the duplicated cryptheader, which contains the master key which is used to encrypt all files on your partition. Of course this master key 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 master key 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]{{Linkrot|2011|09|05}} for further details on this.<br />
<br />
{{Note|You can also back up 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 />
=== Backup ===<br />
==== Manually ====<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 />
==== Using cryptsetup ====<br />
You can also use the luksHeaderBackup command instead:<br />
cryptsetup luksHeaderBackup /dev/sdaX --header-backup-file ./backup.img<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 />
==== Manually ====<br />
Again, you will need to the same values as when backing up:<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
==== Using cryptsetup ====<br />
Or you can use the luksHeaderRestore command:<br />
cryptsetup luksHeaderRestore /dev/sdaX --header-backup-file ./backup.img<br />
<br />
'''Note:''' All the keyslot areas are overwritten; only active keyslots from the backup file are available after issuing this command.<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 />
First, start by creating an encrypted container!<br />
<br />
dd if=/dev/urandom of=/bigsecret bs=1M count=10<br />
<br />
This will create the file {{ic|bigsecret}} with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node {{ic|/dev/loop0}}, so that we can mount/use our container.<br />
<br />
{{Note|If it gives you the error {{ic|/dev/loop0: No such file or directory}}, you need to first load the kernel module with {{ic|modprobe loop}}. These days (Kernel 3.2) loop devices are created on demand. Ask for a new loop device with {{ic|losetup -f}}.}}<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file.<br />
<br />
{{Note|If you get an error like {{ic|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 {{ic|modprobe dm-mod}}.}}<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the device file {{ic|/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 />
=== Encrypt using a key-file ===<br />
Let us 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 {{ic|/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 encrypting your keyfile using your private GPG key and storing an off-site 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 expand our container file with the size of the data we want to add:<br />
<br />
dd if=/dev/urandom bs=1M count=1024 | cat - >> /bigsecret<br />
<br />
Be careful to really use TWO {{ic|>}}, or you will override your current container!<br />
<br />
You could use {{ic|/dev/zero}} instead of {{ic|/dev/urandom}} to significantly speed up the process, but with {{ic|/dev/zero}} your encrypted filesystems will ''not be as secure''. (A better option to create random data quicker than {{ic|/dev/urandom}} is {{ic|frandom}} [https://aur.archlinux.org/packages.php?ID=9869], available from the [[AUR]]).<br />
<br />
Now we have to map the container to the loop device:<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 do not 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 the {{ic|encrypt}} hook '''before''' the {{ic|lvm2}} hook (and those two before the {{ic|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 set up your LVM volumes and then use them as the base for the encrypted partitions. That means, in short, that you have to set up LVM first. Then follow this guide, but replace all occurrences of {{ic|/dev/sdXy}} in the guide with its LVM counterpart. (E.g.: {{ic|/dev/sda5}} -> {{ic|/dev/<volume group name>/home}}).<br />
<br />
Do not forget to add the {{ic|encrypt}} hook in {{ic|/etc/mkinitcpio.conf}} '''before''' the {{ic|lvm2}} hook, if you chose to set up encrypted partitions on '''top''' of LVM. Also remember to change {{ic|USELVM}} in {{ic|/etc/rc.conf}} to {{ic|"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 partition 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 {{ic|/etc/rc.conf}} set {{ic|USELVM}} to {{ic|"yes"}}<br />
* In {{ic|/etc/mkinitcpio.conf}} add the {{ic|encrypt}} hook '''before''' the {{ic|lvm2}} hook in the {{ic|HOOKS}} array, if you set up LVM on top of the encrypted partition.<br />
<br />
That is 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 {{ic|/lib/initcpio/hooks/encrypt}} (the first one to your {{ic|/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 {{ic|/etc/crypttab}} with an external key file (i.e. the keyfile is not on any internal hard drive 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 the order of {{ic|/etc/fstab}} (at least).<br />
<br />
Of course, if the {{Pkg|cryptsetup}} package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking {{ic|/etc/rc.sysinit}} or similar files. Unlike {{ic|/etc/crypttab}}, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
If you want to do this on a software RAID partition, there is one more thing you need to do. Just setting the {{ic|/dev/mdX}} device in {{ic|/lib/initcpio/hooks/encrypt}} is not enough; the {{ic|encrypt}} hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices are not brought up until after the {{ic|encrypt}} hook is run. You can solve this by putting the RAID array in {{ic|/boot/grub/menu.lst}}, like <br />
kernel /boot/vmlinuz-linux md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID, you will notice the similarities with that setup ;-). [[GRUB]] can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz-linux root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM and dm-crypt manually (short version) ===<br />
<br />
==== Notes ====<br />
If you are smart enough for this, you will be smart enough to ignore/replace LVM-specific things if you do not want to use LVM.<br />
<br />
{{Note|This brief uses reiserfs for some of the partitions, so change this accordingly if you want to use a more "normal" file system, like ext4.}}<br />
<br />
==== Partitioning scheme ====<br />
{{ic|/dev/sda1}} -> {{ic|/boot}}<br />
{{ic|/dev/sda2}} -> LVM<br />
<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 />
<br />
==== Install Arch Linux ====<br />
Run {{ic|/arch/setup}}<br />
<br />
==== Configuration ====<br />
<br />
===== /etc/rc.conf =====<br />
Change {{ic|USELVM<nowiki>=</nowiki>"no"}} to {{ic|USELVM<nowiki>=</nowiki>"yes"}}.<br />
<br />
===== /etc/mkinitcpio.conf =====<br />
Put {{ic|lvm2}} and {{ic|encrypt}} (in that order) before {{ic|filesystems}} in the {{ic|HOOKS}} array. Again, note that you are setting encryption on '''top''' of LVM.)<br />
<br />
if you want install the system on a usb stick, you need to put {{ic|usb}} just after {{ic|udev}}.<br />
<br />
===== /boot/grub/menu.lst =====<br />
Change {{ic|root<nowiki>=</nowiki>/dev/hda3}} to {{ic|root<nowiki>=</nowiki>/dev/lvm/root}}.<br />
<br />
For kernel >= 2.6.30, you should change {{ic|root<nowiki>=</nowiki>/dev/hda3}} to the following:<br />
cryptdevice=/dev/lvm/root:root root=/dev/mapper/root<br />
<br />
if you want install the system on a usb stick, you need to add {{ic|lvmdelay<nowiki>=</nowiki>/dev/mapper/lvm-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 rebooting ====<br />
<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 />
<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on LVM on LUKS ===<br />
Make sure your kernel command line 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 />
==Using GPG or OpenSSL Encrypted Keyfiles==<br />
The following forum posts give instructions to use two factor authentication, gpg or openssl encrypted keyfiles, instead of a plaintext keyfile described earlier in this wiki article [https://bbs.archlinux.org/viewtopic.php?id=120243 System Encryption using LUKS with GPG encrypted keys]:<br />
* GnuPG: [https://bbs.archlinux.org/viewtopic.php?pid=943338#p943338 Post regarding GPG encrypted keys] This post hs the generic instructions.<br />
* OpenSSL: [https://bbs.archlinux.org/viewtopic.php?pid=947805#p947805 Post regarding OpenSSL encrypted keys] This post only has the {{ic|ssldec}} hooks.<br />
<br />
Note that:<br />
* You can follow the above instructions with only two primary partitions one boot partition <br />
(required because of LVM), and one primary LVM partition. Within the LVM partition you can have <br />
as many partitions as you need, but most importantly it should contain at least root, swap, and <br />
home logical volume partitions. This has the added benefit of having only one keyfile for all <br />
your partitions, and having the ability to hibernate your computer (suspend to disk) where the <br />
swap partition is encrypted. If you decide to do so your hooks in {{ic|/etc/mkinitcpio.conf}} <br />
should look like<br />
{{ic|HOOKS&#61;" ... usb usbinput (etwo or ssldec) encrypt lvm2 resume ... "}}<br />
and you should add to your {{ic|kernel}} line(if using grub, {{ic|/boot/grub/menu.lst}}) or <br />
{{ic|GRUB_CMD_LINE}}(if using grub2, {{ic|/etc/default/grub}}):<br />
{{ic|"resume&#61;/dev/mapper/<VolumeGroupName>-<LVNameOfSwap>"}}<br />
* If you need to temporarily store the unecrypted keyfile somewhere, do not store them on an <br />
unencrytped disk. Even better make sure to store them to RAM such as {{ic|/dev/shm}}.<br />
* If you want to use a GPG encrypted keyfile, you need to use a statically compiled GnuPG version 1.4 or you could edit the hooks and use this AUR package [https://aur.archlinux.org/packages.php?ID=58030 gnupg1]<br />
* It is possible that an update to OpenSSL could break the custom {{ic|ssldec}} mentioned in the second forum post.<br />
<br />
==Securing the unencrypted boot partition==<br />
Referring to an article from the ct-magazine (Issue 3/12, page 146, 01.16.2012 http://www.heise.de/ct/inhalt/2012/03/6/) the following script checks all files under {{ic|/boot}} for changes of SHA-1 hash, inode and occupied blocks on the hard drive. It also checks the MBR.<br />
<br />
The script with installation instructions is available here: ftp://ftp.heise.de/pub/ct/listings/1203-146.zip (Author: Juergen Schmidt, ju at heisec.de; License: GPLv2)<br />
<br />
There is also an AUR package: {{AUR|chkboot}}<br />
<br />
After installation, add {{ic|/usr/local/bin/chkboot.sh &}} to your {{ic|/etc/rc.local}}.<br />
<br />
And as {{ic|/usr/local/bin/chkboot_user.sh}} need to be excuted after login, add it to the autostarts (e.g. under KDE -> System Settings -> Startup and Shutdown -> Autostart)<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Install Arch Linux on top of RAID, LVM2, and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Airbus001https://wiki.archlinux.org/index.php?title=Dm-crypt&diff=209421Dm-crypt2012-06-15T23:18:21Z<p>Airbus001: /* Using GPG or OpenSSL Encrypted Keyfiles */</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[ru:System Encryption with LUKS]]<br />
[[zh-CN:System Encryption with LUKS]]<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 />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
==== Data encryption ====<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
*Preventing unauthorized physical access to private data.<br />
*Some confidence in data disposal when discarding obsolete systems.<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 />
==== System encryption ====<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 />
*Preventing unauthorized physical access to operating system files<br />
*Preventing unauthorized physical access to private data that may cached by the system.<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 />
*Attempts to bypass the operating system by inserting a boot CD/USB<br />
*Copying, modifying, or removing the hard disk drives when the computer is off<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the {{ic|/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 />
{{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 Available for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption, including:<br />
<br />
;loop-AES ([http://loop-aes.sourceforge.net/ loop-AES]):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 />
;standard device-mapper encryption ([http://www.saout.de/misc/dm-crypt/ dm-crypt]):This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
;LUKS for dm-crypt ([http://code.google.com/p/cryptsetup/ LUKS]):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 />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key (see [[Wikipedia:Kerckhoffs's principle]])<br />
::*The usage of a proven encryption algorithm<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 />
====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 />
====discard/TRIM support for solid state disks====<br />
<br />
Solid state disk users should be aware that by default, Linux's full-disk encryption mechanisms will ''not'' forward TRIM commands from the filesystem to the underlying disk. The device-mapper maintainers have made it clear that TRIM support will never be enabled by default on dm-crypt devices because of the potential security implications; if TRIM support were enabled, an attacker may be able to tell which blocks have been used, how many blocks have been used, and other information that is exposed directly to the device when a TRIM is issued.<br />
<br />
It may be possible to determine the filesystem utilized by your encrypted device through the data that is leaked by TRIM. Furthermore, any information that may be derived by a profile of block usage may be exposed by enabling TRIM support on an encrypted device.<br />
<br />
As of {{Pkg|linux}} version 3.1, support for dm-crypt TRIM pass-through can be toggled upon device creation or mount with dmsetup. Support for this option also exists in {{Pkg|cryptsetup}} version 1.4.0 and up. To add support during boot, you will need to add "{{ic|:allow-discards}}" to the {{ic|cryptdevice}} option. The option should look like this:<br />
cryptdevice=/dev/mapper/root:root:allow-discards<br />
<br />
For more information, including specific commands and details on dm-crypt TRIM pass-through, see these mailing list threads:<br />
* http://article.gmane.org/gmane.linux.kernel.device-mapper.devel/14134<br />
* http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/5166<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 shut down. 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 to extract your encryption key - thus obtaining access to your data.<br />
<br />
{{Note|System Encryption assumes encryption of all mounted partitions: this includes all partitions except for {{ic|/boot}} - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, {{ic|/tmp}}, or root filesystems are unencrypted, only Data Encryption level of security has been accomplished.}}<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 />
=====Encryption of data partitions on the same physical disk as the system=====<br />
<br />
The most common form of data encryption is encrypting the {{ic|/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 decreased by orders of magnitude when compared to system encryption. The reason for this is 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, {{Pkg|mlocate}} will scan all currently mounted file systems regularly and write the list of filenames to {{ic|/var/lib/mlocate/mlocate.db}}, which is located in the non-encrypted root or {{ic|/var}} partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted {{ic|/home}} partition, readily available to assist them in accessing the encrypted data present on 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|System Encryption with eCryptfs]].<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 Hard Disk Drives or Separate Internal Hard Disk Drives<br />
::*CD/DVD/Blu-Ray Optical Media<br />
::*Magnetic Storage Media<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 set up.<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the hard disk 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 Hard Disk Drive ===<br />
<br />
Secure erasure of the hard disk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a hard disk 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 />
====Why perform secure erasure of a drive?====<br />
<br />
There are two types of hard disk 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 Hard Disk Drives'''<br />
<br />
::In hard drives 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 Hard Disk Drives'''<br />
<br />
::Repartitioning or reformatting a used hard drive 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 straightforward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore hard drives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
====Overwriting a hard disk drive with random data====<br />
<br />
There are two sources of random data commonly used for securely overwriting hard disk partitions.<br />
<br />
::*{{ic|/dev/urandom}}<br />
::*badblocks<br />
<br />
=====Using urandom=====<br />
<br />
#dd if=/dev/urandom of=/dev/<drive> bs=1M<br />
<br />
Where {{ic|/dev/<drive>}} is the drive to be encrypted.<br />
<br />
{{Note| Using {{ic|/dev/urandom}} will take a long time to completely overwrite a drive with "random" data. In the strictest sense, {{ic|/dev/urandom}} is less random than {{ic|/dev/random}}; however, {{ic|/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 {{ic|/dev/random}} for overwriting hard disks impractical.}}<br />
<br />
{{Note| Users may also find that {{ic|/dev/urandom}} takes an excessively long time on large drives of several hundred gigabytes or more (more than twenty-four hours). [[Frandom]] offers a faster alternative.}}<br />
<br />
{{Note|You can retrieve progress of the dd command with this command: {{ic|kill -USR1 $(pidof dd)}}}}<br />
<br />
=====Using badblocks=====<br />
<br />
#badblocks -c 10240 -wsvt random /dev/<drive><br />
<br />
Where {{ic|/dev/<drive>}} is the drive to be encrypted.<br />
<br />
{{Note|The {{ic|badblocks}} command overwrites the drive at a much faster rate by generating data that is not truly random.}}<br />
<br />
See also [[badblocks]].<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a hard disk 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 />
=====After installation=====<br />
Essentially the same effect can be achieved if a file is created on each of the partitions that fills the partition completely '''after''' the system is installed and booted with encrypted partitions mounted. <br />
#dd if=/dev/zero of=/path/to/the/output/file<br />
#rm /path/to/the/input/file<br />
Just make sure that you do that for every partition on the filesystem. This works as encrypted data is indistinguishabe from random, so anone trying to access potential leftover files will just see random data.<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 with systems that require 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 three flavors: primary partitions, extended partitions, and logical partitions.<br />
<br />
;Primary Partitions: These are the normal partitions recognized by the system BIOS. There can be up to four of these stored in the MBR.<br />
<br />
;Extended Partitions: These are primary partitions that also define another partition within themselves. Extended partitions were created to work around the original limit of four primary partitions.<br />
<br />
;Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
====LVM: Logical Volume Manager====<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple hard disk drives and partitions that are not possible with standard partitions. LVM is covered in detail in the [[LVM|Arch Linux LVM Wiki Article]] which is recommended reading prior to continuing with the instructions on setting up LUKS with LVM located below.<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 is that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In this case, logical volume management would be layered on top of the hardware encryption &ndash; usage of LUKS would be superfluous.<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 two required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*{{ic|'''/'''}}<br />
:::*Will be encrypted and store all system and user files ({{ic|/usr}}, {{ic|/bin}}, {{ic|/var}}, {{ic|/home}}, etc.)<br />
<br />
::An initial boot partition<br />
<br />
:::*{{ic|'''/boot'''}}<br />
:::*Will ''not'' be encrypted; the bootloader needs to access the {{ic|/boot}} directory where it will load the initramfs/encryption modules needed to load the rest of the system which ''is'' encrypted (see [[Mkinitcpio]] for details). For this reason, {{ic|/boot}} needs to reside on its own, unencrypted partition.<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 />
=====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 used, the space unoccupied by {{ic|/boot}} and swap should be defined as single large partition which will be divided up later at the LVM level.<br />
<br />
=====Multiple Disk Systems=====<br />
<br />
In systems that will have multiple hard disk drives, the same options exist as a single disk system. After the creation of the {{ic|/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 {{ic|/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 the dialogue for manual configuration of the hard drive.<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 per LUKS partition.<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
{{Note|Using a passphrase to decrypt LUKS partitions automatically from {{ic|/etc/crypttab}} is deprecated: see http://www.mail-archive.com/arch-projects@archlinux.org/msg02115.html}}<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
A full list of options {{ic|cryptsetup}} accepts can be found in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::*{{ic|-c}} defines the cipher type<br />
::*{{ic|-y}} prompts for password confirmation on password creation<br />
::*{{ic|-s}} defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
In the following examples for creating LUKS partitions, we will use the AES cipher in XTS mode; at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup, and details about them can be found here: [[Wikipedia:Block_cipher]]<br />
<br />
'''Formatting LUKS Partitions'''<br />
<br />
First of all make sure the device mapper kernel module is loaded by executing the following: {{ic|# modprobe dm_mod}}<br />
<br />
In order to format a desired partition as an encrypted LUKS partition execute:<br />
{{hc|# cryptsetup -c <cipher> -y -s <key size> luksFormat /dev/<partition name>|<br />
Enter passphrase: <password><br />
Verify passphrase: <password>}}<br />
<br />
This should be repeated for all partitions except for {{ic|/boot}} and possibly swap.<br />
<br />
The example below will create an encrypted root partition using the AES cipher in XTS mode (generally referred to as ''XTS-AES'').<br />
{{bc|cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2}}<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 the chosen partitioning method, the {{ic|/boot}} partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<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 {{ic|/dev/<partition name>}} is actually an encrypted device and should be addressed through LUKS using the {{ic|/dev/mapper/<name>}} so as not to overwrite the encrypted data. <br />
<br />
In order to open an encrypted LUKS partition execute:<br />
{{hc|# cryptsetup luksOpen /dev/<partition name> <device-mapper name>|<br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.}}<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
::*cryptsetup luksOpen /dev/sda2 '''swap'''<br />
::::Once opened, the swap partition device address would be '''{{ic|/dev/mapper/swap}}''' instead of {{ic|/dev/sda2}}.<br />
<br />
::*cryptsetup luksOpen /dev/sda3 '''root'''<br />
::::Once opened, the root partition device address would be '''{{ic|/dev/mapper/root}}''' instead of {{ic|/dev/sda3}}.<br />
<br />
{{Note|Since {{ic|/boot}} is not encrypted, it does not need a device mapped name and will be addressed as {{ic|/dev/sda1}}.}}<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 Partitions with a Keyfile ====<br />
{{Note|This section describes using a plaintext keyfile, if you want to encrypt your keyfile giving you two factor authentication see [https://wiki.archlinux.org/index.php/System_Encryption_with_LUKS#Using_GPG_or_OpenSSL_Encrypted_Keyfiles Section 9] for details, but please still read this section.}}<br />
<br />
'''What is a Keyfile?'''<br />
<br />
A keyfile is any file in which the data contained within it 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 />
{{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 />
'''Why use a Keyfile?'''<br />
<br />
There are many kinds of keyfile. Each type of keyfile used has benefits and disadvantages summarized below:<br />
<br />
:'''keyfile.passphrase:'''<br />
::this is my passphrase I would have typed during boot but I have placed it in a file instead<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 add any security over entering a passphrase during the initial system start.<br />
<br />
:'''keyfile.randomtext:'''<br />
::fjqweifj830149-57 819y4my1- 38t1934yt8-91m 34co3;t8y;9p3y-<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 />
:'''keyfile.binary:'''<br />
::where any binary file, images, text, video could be chosen as the keyfile<br />
<br />
This is a binary file that has been defined as a keyfile. When identifying files as candidates for a keyfile, it is recommended to choose files that are relatively static such as photos, music, video clips. The benefit of these files is that they serve a dual function which can make them harder to identify as keyfiles. Instead of having a text file with a large amount of random text, the keyfile would look like a regular image file or music clip to the casual observer. The disadvantage is that if this file is lost or changed, it will most likely not be possible to access the encrypted volume without a backup passphrase. Additionally, there is a theoretical loss of randomness when compared to a randomly generated text file. This is due to the fact that images, videos and music have some intrinsic relationship between neighboring bits of data that does not exist for a text file. However this is controversial and has never been exploited publicly.<br />
<br />
'''Creating a Keyfile with Random Characters'''<br />
<br />
Here {{ic|dd}} is used to generate a keyfile of 2048 bits of random characters.<br />
<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
The usage of {{ic|dd}} is similar to initially wiping the volume with random data prior to encryption. <br />
<br />
{{Warning|Do not use [[badblocks]] here. It only generate a random pattern which just repeats its randomness over and over again.}}<br />
<br />
'''Creating a new LUKS encrypted partition with a Keyfile'''<br />
<br />
When creating a new LUKS encrypted partition, a keyfile may be associated with the partition on its creation using:<br />
<br />
# cryptsetup -c <desired cipher> -s <key size> luksFormat /dev/<volume to encrypt> '''/path/to/mykeyfile'''<br />
<br />
This is accomplished by appending the bold area to the standard cryptsetup command which defines where the keyfile is located.<br />
<br />
==== Adding Additional Passphrases or Keyfiles to a LUKS Encrypted Partition ====<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 slot 0.<br />
Additional keys will occupy slots 1&ndash;7.<br />
<br />
The addition of new keys to an encrypted partition is accomplished using cryptsetup with the {{ic|luksAddKey}} extension.<br />
<br />
# cryptsetup luksAddKey /dev/<encrypted volume> '''/path/to/mykeyfile'''<br />
<br />
Where {{ic|/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 is important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. {{ic|/dev/sdb1}} 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 {{ic|encrypt}} HOOK in the initcpio finds your keyfile, you must 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 the following:<br />
<br />
{{hc|# ls -l /dev/disk/by-label/|<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1}}<br />
<br />
or<br />
<br />
{{hc|# 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 {{ic|/dev/disk/by-label/Keys}}, or if I had wanted to use the UUID I would find {{ic|/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 ({{ic|sdb1}}, {{ic|sdb2}}, ...) but not to the USB device ({{ic|sdb}}) 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 flash drive with a [[udev]] rule. There is 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 is quickly how it goes.<br />
<br />
Get the serial number from your USB flash drive:<br />
lsusb -v | grep -A 5 Vendor<br />
<br />
Create a udev rule for it by adding the following to a file in {{ic|/etc/udev/rules.d/}}, such as {{ic|8-usbstick.rules}}:<br />
KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"<br />
<br />
Replace {{ic|$SYMLINK}} and {{ic|$SERIAL}} with their respective values. {{ic|%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 {{ic|/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. {{ic|/media/sdb1}}<br />
<br />
The keyfile can be of arbitrary content and size. We will 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 device, 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 {{ic|/etc/mkinitcpio.conf}}, one for the drive's file system and one for the codepage. Further if you created a udev rule, you should tell {{ic|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 is assumed that you use a FAT formatted USB drive. 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 />
Additionally, insert the {{ic|usb}} hook somewhere before the {{ic|encrypt}} hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
If you have a non-US keyboard, it might prove useful to load your keyboard layout before you are prompted to enter the password to unlock the root partition at boot. For this, you will need the {{ic|keymap}} hook before {{ic|encrypt}}.<br />
<br />
Generate a new image (maybe you should backup a copy of your old kernel26.img first):<br />
mkinitcpio -g /boot/initramfs-linux.img<br />
<br />
==== Storing the key as a plain (visible) file ====<br />
Be sure to choose a plain name for your key &ndash; a bit of 'security through obscurity' is always nice ;-). Avoid using dotfiles (hidden files) &ndash; the {{ic|encrypt}} hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your {{ic|/boot/grub/menu.lst}} ([[GRUB]]). It should look something like this:<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes {{ic|/dev/usbstick}} is the FAT partition of your choice. Replace it with {{ic|/dev/disk/by-...}} or whatever your device is.<br />
<br />
That is all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We will write the key directly between the Master Boot Record (MBR) and the first partition.<br />
<br />
{{Warning|You should only follow this step if you know what you are doing -- '''it can cause data loss and damage your partitions or MBR on the stick!'''}}<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 do not rely on this too much), so you would have to replace {{ic|seek<nowiki>=</nowiki>4}} with {{ic|seek<nowiki>=</nowiki>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 />
''Optional''<br />
If you do not know if you have 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 {{ic|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 {{ic|/boot/grub/menu.lst}} file (GRUB); it should look something like this:<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usb:2048:2048<br />
Format for the {{ic|cryptkey}} option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
{{ic|OFFSET}} and {{ic|SIZE}} match in this example, but this is just coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usb:8192:2048<br />
That is all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
=== Encrypting the Swap partition ===<br />
<br />
==== Without suspend-to-disk 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 />
Append a similar line to {{ic|/etc/crypttab}} to set up a randomly encrypted swap partition:<br />
<br />
<device-mapper name> <swap physical partition> SWAP "-c aes-xts-plain -h whirlpool -s 512"<br />
<br />
Where:<br />
<br />
:*{{ic|<device-mapper name>}} represents the name you want to use as label in /etc/fstab<br />
:*{{ic|<swap physical partition>}} should be the ID of the actual partition. <br> {{Warning|You should use IDs here because if there are multiple hard drives installed in the system, their naming order (sda, sdb,...) can occasionally be scrambled upon boot and thus the swap would be created over a valuable file system, destroying its content. {{ic|<nowiki>ls -l /dev/disk/*/* | grep sdl7</nowiki>}} should help you to find the desired partition.}}<br />
:*{{ic|SWAP}} identifies the partition as a swap partition<br />
:*{{ic|-c}} defines a cipher<br />
:*{{ic|-h}} defines a hash algorithm<br />
:*{{ic|-s}} defines the key size<br />
<br />
Example line (where {{ic|/dev/sdl7}} is the physical partition and {{ic|<nowiki>LABEL=swap</nowiki>}} the desired label):<br />
<br />
swap /dev/disk/by-id/scsi-SATA_Hitachi_HDS7220_JK1130YAGX0R1T-part7 SWAP "-c aes-xts-plain -h whirlpool -s 512"<br />
<br />
:Maps {{ic|/dev/sdl7}} to {{ic|/dev/mapper/swap}} as a swap partition which we can now add in {{ic|/etc/fstab}} like a normal swap.<br />
<br />
If the partition chosen for swap was previously a LUKS partition, crypttab will not overwrite the partition to create a swap partition. This is a safety measure to prevent data loss from accidental mis-identification of the swap partition in crypttab. In order to use such a partition the LUKS header must be removed. This can be accomplished with:<br />
<br />
# dd if=/dev/zero of=/dev/sdl7 bs=1M<br />
<br />
==== With suspend-to-disk support ====<br />
{{Warning|Do not use this setup with a key file. Please read about the issue reported [[Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure|here]]}}<br />
<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 pre-existent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before {{ic|/etc/crypttab}} can be used, it is required to create a hook in {{ic|/etc/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 />
* Format the partition you want to use as swap with the {{ic|cryptsetup}} command. For performance reasons, you might want to use different ciphers with different key sizes.<br />
<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check the result with:<br />
<br />
# cryptsetup luksDump /dev/<device><br />
<br />
* Open the partition in {{ic|/dev/mapper}}:<br />
<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
<br />
* Create a swap filesystem inside the mapped partition:<br />
<br />
# mkswap /dev/mapper/swapDevice<br />
<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in {{ic|/etc/crypttab}} which uses this device. Now you have to create a hook to open the swap at boot time.<br />
<br />
* Create a hook file containing the open command:<br />
<br />
{{hc|/lib/initcpio/hooks/openswap|<nowiki><br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
</nowiki>}}<br />
<br />
* Then create and edit the hook setup file:<br />
{{hc|/lib/initcpio/install/openswap|<nowiki><br />
# vim: set ft=sh:<br />
build ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
</nowiki>}}<br />
<br />
* Add the hook {{ic|openswap}} in the {{ic|HOOKS}} array in {{ic|/etc/mkinitcpio.conf}}, before {{ic|filesystem}}, but '''after''' {{ic|encrypt}} which is mandatory as well. Do not forget to add the {{ic|resume}} hook between {{ic|openswap}} and {{ic|filesystem}} as well.<br />
<br />
* Regenerate the boot image:<br />
<br />
# mkinitcpio -p linux<br />
<br />
* Add the mapped partition to {{ic|/etc/fstab}} by adding the following line:<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
<br />
* Set up your system to resume from {{ic|/dev/mapper/swapDevice}}. For example, if you use [[GRUB]] with kernel hibernation support, add {{ic|resume<nowiki>=</nowiki>/dev/mapper/swapDevice}} to the kernel line in {{ic|/boot/grub/menu.lst}}. A line with encrypted root and swap partitions can look like this:<br />
<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
<br />
At boot time, the {{ic|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 are placed '''after''' {{ic|openswap}} in the {{ic|HOOKS}} array. Please note that because of initrd opening swap, there is no entry for swapDevice in {{ic|/etc/crypttab}} needed in this case.<br />
<br />
=== Using a swap file for suspend-to-disk support ===<br />
* Choose a mapped partition (e.g. {{ic|/dev/mapper/rootDevice}}) whose mounted filesystem (e.g. {{ic|/}}) contains enough free space to hold the entire contents of your system's RAM. For example, if your system has 4 GiB RAM, then you need at least that much free space on the mounted filesystem of your chosen mapped partition for the swap file.<br />
<br />
* [[HOW_TO:_Create_swap_file#Swap_file_creation | Create the swap file]] (e.g. {{ic|/swapfile}}) inside the mounted filesystem of your chosen mapped partition. Be sure to activate it with {{ic|swapon}} and also add it to your {{ic|/etc/fstab}} file afterward.<br />
<br />
* Set up your system to resume from your chosen mapped partition. For example, if you use [[GRUB]] with kernel hibernation support, add {{ic|resume<nowiki>=</nowiki>}}''your chosen mapped partition'' and {{ic|resume_offset<nowiki>=</nowiki>}}''see calculation command below'' to the kernel line in {{ic|/boot/grub/menu.lst}}. A line with encrypted root partition can look like this:<br />
<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/rootDevice resume_offset=123456789 ro<br />
<br />
You can calculate the {{ic|resume_offset}} of your swap file like this:<br />
<br />
# filefrag -v /swapfile | awk '{if($1==0){print $3}}'<br />
<br />
* Add the {{ic|resume}} hook to your {{ic|etc/mkinitcpio.conf}} file and [[Mkinitcpio#Image_creation_and_activation|rebuild the image]] afterward:<br />
<br />
HOOKS="... encrypt '''resume''' ... filesystems ..."<br />
<br />
== Installing the system ==<br />
Now that {{ic|/dev/mapper/root}} and {{ic|/dev/mapper/home}} 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 steps and go straight to manual configuration.<br />
Instead of choosing the hardware devices ({{ic|/dev/sdaX}}) directly, you have to select the mapper devices created above.<br />
Choose {{ic|/dev/mapper/root}} for your root and {{ic|/dev/mapper/home}} as {{ic|/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 {{ic|/home}} partition. Make sure you mount {{ic|/dev/sda1}} as the {{ic|/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|The {{ic|encrypt}} hook is only needed if your root partition is a ''LUKS'' partition (or a LUKS partition that needs to be mounted ''before'' root). The {{ic|encrypt}} hook is not needed if any other partition (swap, for example) is encrypted. System initialization scripts ({{ic|/etc/rc.sysinit}} and {{ic|/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 {{ic|/etc/mkinitcpio.conf}}. For detailed information about mkinitcpio and its configuration refer to [[Mkinitcpio]]. You have to make sure that your {{ic|HOOKS}} array in {{ic|/etc/mkinitcpio.conf}} looks something like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the {{ic|encrypt}} hook comes ''before'' the {{ic|filesystems}} hook. 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 {{ic|usb}} before {{ic|encrypt}} because the hooks are run in the order they appear.<br />
If you need support for foreign keymaps for your encryption password, you have to specify the hook {{ic|keymap}} as well. I suggest putting this in {{ic|/etc/mkinitcpio.conf}} immediately before {{ic|encrypt}}.<br />
<br />
If you have a USB keyboard, you will need the {{ic|usbinput}} hook in {{ic|/etc/mkinitcpio.conf}}. Without it, no USB keyboard will work in early userspace.<br />
<br />
If your root partition is a ''LUKS'' partition, add the used filesystem to the {{ic|MODULES}} section.<br />
MODULES="... ext3 ext4 xfs ..."<br />
<br />
=== Install Bootloader ===<br />
'''[[GRUB]]:''' You have to make some small changes to the entries generated by the installer by replacing {{ic|/dev/mapper/root}} with {{ic|/dev/sda3}}. The important point to remember here is to use the same {{ic|cryptdevice}} name you assigned when you initially unlocked your device. In this example, the device name is {{ic|cryptroot}}; customize yours accordingly:<br />
<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:cryptroot root=/dev/mapper/cryptroot ro<br />
initrd /initramfs-linux.img<br />
<br />
For kernels older than 2.6.37, the syntax is:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' Edit the Arch Linux section in {{ic|/etc/lilo.conf}} and include a line for the {{ic|append}} option, over the initrd, with the {{ic|root<nowiki>=</nowiki>/dev/sda3}} parameter. The {{ic|append}} section makes the same kernel line as in GRUB. Also, you can omit the {{ic|root}} option above the {{ic|image}} option. The section looks like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz-linux<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /initramfs-linux.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note|If you want to use a USB flash drive with a keyfile, you have to append the {{ic|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 {{ic|/etc/crypttab}} file so you do not have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. {{ic|/home}}, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
<br />
Add the following line for the {{ic|/home}} partition<br />
{{Note|Using a passphrase to decrypt LUKS partitions automatically from {{ic|/etc/crypttab}} is deprecated: see http://www.mail-archive.com/arch-projects@archlinux.org/msg02115.html}}<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 [[#Adding_Additional_Passphrases_or_Keyfiles_to_a_LUKS_Encrypted_Partition|above]].<br />
Then add the following information to the {{ic|/etc/crypttab}} file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
If you used a USB device to store your keyfile, you should have something like this:<br />
home /dev/sda5 /dev/sd*1/keyfile<br />
<br />
Or if the keyfile was stored in the MBR, it should be like this:<br />
home /dev/sda5 /dev/sd*:2048:2048<br />
<br />
{{Box BLUE|Note:|When reading the keyfile from the MBR it should be {{ic|/dev/sdb}} not {{ic|/dev/sdb1}} but if the key is in the filesystem it should still be {{ic|/dev/sdb1}}.}}<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 a LUKS password. Type it in and everything should boot.<br />
Once you have logged in, have a look at your mounted partitions by typing {{ic|mount}}. You should have {{ic|/dev/mapper/root}} mounted at {{ic|/}} and, if you set up a separate encrypted home partition, {{ic|/dev/mapper/home}} mounted at {{ic|/home}}. If you set up encrypted swap, {{ic|swapon -s}} should have {{ic|/dev/mapper/swap}} 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 is not, simply enter your password and press {{keypress|Enter}}.}}<br />
<br />
== Remote unlocking of the root (or other) 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 achieved by running the {{ic|net}} hook along with an [[SSH]] server in initrd. Install the {{AUR|dropbear_initrd_encrypt}} package from the [[Arch User Repository|AUR]] and follow the post-installation instructions. Replace the {{ic|encrypt}} hook with {{ic|dropbear encryptssh}} in {{ic|/etc/mkinitcpio.conf}}. Put the {{ic|net}} hook early in the HOOKS array if your DHCP server takes a long time to lease IP addresses.<br />
<br />
If you would simply like a nice solution to mount other encrypted partitions (such as {{ic|/home}})remotely, you may want to look at [https://bbs.archlinux.org/viewtopic.php?pid=880484 this forum thread].<br />
<br />
{{Note|Acutally trim will not work with this script because it is not yet updated to the latest encrypt hook, so it is not able to parse {{ic|-–allow-discards}} from {{ic|/boot/grub/menu.lst}}. (Version: dropbear_initrd_encrypt 0.8-16). You won't notice any error when using online discard, but you see an error when you try to use {{ic|fstrim}}.For a temporary solution just add {{ic|-–allow-discards}} to every cryptsetup line of {{ic|/lib/initcpio/install/dropbear}}(1 line) and {{ic|/lib/initcpio/hooks/encryptssh}}(3 lines)}}<br />
<br />
== Backup the cryptheader ==<br />
If the header of your encrypted partition gets destroyed, you will not be able to decrypt your data. Therefore, having a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT backing up the cryptheader, but even so it's a single point of failure!<br />
In short, the problem is that LUKS is not aware of the duplicated cryptheader, which contains the master key which is used to encrypt all files on your partition. Of course this master key 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 master key 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]{{Linkrot|2011|09|05}} for further details on this.<br />
<br />
{{Note|You can also back up 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 />
=== Backup ===<br />
==== Manually ====<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 />
==== Using cryptsetup ====<br />
You can also use the luksHeaderBackup command instead:<br />
cryptsetup luksHeaderBackup /dev/sdaX --header-backup-file ./backup.img<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 />
==== Manually ====<br />
Again, you will need to the same values as when backing up:<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
==== Using cryptsetup ====<br />
Or you can use the luksHeaderRestore command:<br />
cryptsetup luksHeaderRestore /dev/sdaX --header-backup-file ./backup.img<br />
<br />
'''Note:''' All the keyslot areas are overwritten; only active keyslots from the backup file are available after issuing this command.<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 />
First, start by creating an encrypted container!<br />
<br />
dd if=/dev/urandom of=/bigsecret bs=1M count=10<br />
<br />
This will create the file {{ic|bigsecret}} with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node {{ic|/dev/loop0}}, so that we can mount/use our container.<br />
<br />
{{Note|If it gives you the error {{ic|/dev/loop0: No such file or directory}}, you need to first load the kernel module with {{ic|modprobe loop}}. These days (Kernel 3.2) loop devices are created on demand. Ask for a new loop device with {{ic|losetup -f}}.}}<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file.<br />
<br />
{{Note|If you get an error like {{ic|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 {{ic|modprobe dm-mod}}.}}<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the device file {{ic|/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 />
=== Encrypt using a key-file ===<br />
Let us 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 {{ic|/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 encrypting your keyfile using your private GPG key and storing an off-site 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 expand our container file with the size of the data we want to add:<br />
<br />
dd if=/dev/urandom bs=1M count=1024 | cat - >> /bigsecret<br />
<br />
Be careful to really use TWO {{ic|>}}, or you will override your current container!<br />
<br />
You could use {{ic|/dev/zero}} instead of {{ic|/dev/urandom}} to significantly speed up the process, but with {{ic|/dev/zero}} your encrypted filesystems will ''not be as secure''. (A better option to create random data quicker than {{ic|/dev/urandom}} is {{ic|frandom}} [https://aur.archlinux.org/packages.php?ID=9869], available from the [[AUR]]).<br />
<br />
Now we have to map the container to the loop device:<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 do not 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 the {{ic|encrypt}} hook '''before''' the {{ic|lvm2}} hook (and those two before the {{ic|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 set up your LVM volumes and then use them as the base for the encrypted partitions. That means, in short, that you have to set up LVM first. Then follow this guide, but replace all occurrences of {{ic|/dev/sdXy}} in the guide with its LVM counterpart. (E.g.: {{ic|/dev/sda5}} -> {{ic|/dev/<volume group name>/home}}).<br />
<br />
Do not forget to add the {{ic|encrypt}} hook in {{ic|/etc/mkinitcpio.conf}} '''before''' the {{ic|lvm2}} hook, if you chose to set up encrypted partitions on '''top''' of LVM. Also remember to change {{ic|USELVM}} in {{ic|/etc/rc.conf}} to {{ic|"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 partition 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 {{ic|/etc/rc.conf}} set {{ic|USELVM}} to {{ic|"yes"}}<br />
* In {{ic|/etc/mkinitcpio.conf}} add the {{ic|encrypt}} hook '''before''' the {{ic|lvm2}} hook in the {{ic|HOOKS}} array, if you set up LVM on top of the encrypted partition.<br />
<br />
That is 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 {{ic|/lib/initcpio/hooks/encrypt}} (the first one to your {{ic|/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 {{ic|/etc/crypttab}} with an external key file (i.e. the keyfile is not on any internal hard drive 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 the order of {{ic|/etc/fstab}} (at least).<br />
<br />
Of course, if the {{Pkg|cryptsetup}} package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking {{ic|/etc/rc.sysinit}} or similar files. Unlike {{ic|/etc/crypttab}}, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
If you want to do this on a software RAID partition, there is one more thing you need to do. Just setting the {{ic|/dev/mdX}} device in {{ic|/lib/initcpio/hooks/encrypt}} is not enough; the {{ic|encrypt}} hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices are not brought up until after the {{ic|encrypt}} hook is run. You can solve this by putting the RAID array in {{ic|/boot/grub/menu.lst}}, like <br />
kernel /boot/vmlinuz-linux md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID, you will notice the similarities with that setup ;-). [[GRUB]] can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz-linux root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM and dm-crypt manually (short version) ===<br />
<br />
==== Notes ====<br />
If you are smart enough for this, you will be smart enough to ignore/replace LVM-specific things if you do not want to use LVM.<br />
<br />
{{Note|This brief uses reiserfs for some of the partitions, so change this accordingly if you want to use a more "normal" file system, like ext4.}}<br />
<br />
==== Partitioning scheme ====<br />
{{ic|/dev/sda1}} -> {{ic|/boot}}<br />
{{ic|/dev/sda2}} -> LVM<br />
<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 />
<br />
==== Install Arch Linux ====<br />
Run {{ic|/arch/setup}}<br />
<br />
==== Configuration ====<br />
<br />
===== /etc/rc.conf =====<br />
Change {{ic|USELVM<nowiki>=</nowiki>"no"}} to {{ic|USELVM<nowiki>=</nowiki>"yes"}}.<br />
<br />
===== /etc/mkinitcpio.conf =====<br />
Put {{ic|lvm2}} and {{ic|encrypt}} (in that order) before {{ic|filesystems}} in the {{ic|HOOKS}} array. Again, note that you are setting encryption on '''top''' of LVM.)<br />
<br />
if you want install the system on a usb stick, you need to put {{ic|usb}} just after {{ic|udev}}.<br />
<br />
===== /boot/grub/menu.lst =====<br />
Change {{ic|root<nowiki>=</nowiki>/dev/hda3}} to {{ic|root<nowiki>=</nowiki>/dev/lvm/root}}.<br />
<br />
For kernel >= 2.6.30, you should change {{ic|root<nowiki>=</nowiki>/dev/hda3}} to the following:<br />
cryptdevice=/dev/lvm/root:root root=/dev/mapper/root<br />
<br />
if you want install the system on a usb stick, you need to add {{ic|lvmdelay<nowiki>=</nowiki>/dev/mapper/lvm-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 rebooting ====<br />
<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 />
<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on LVM on LUKS ===<br />
Make sure your kernel command line 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 />
==Using GPG or OpenSSL Encrypted Keyfiles==<br />
The following forum posts give instructions to use two factor authentication, gpg or openssl encrypted keyfiles, instead of a plaintext keyfile described earlier in this wiki article [https://bbs.archlinux.org/viewtopic.php?id=120243 System Encryption using LUKS with GPG encrypted keys]:<br />
* GnuPG: [https://bbs.archlinux.org/viewtopic.php?pid=943338#p943338 Post regarding GPG encrypted keys] This post hs the generic instructions.<br />
* OpenSSL: [https://bbs.archlinux.org/viewtopic.php?pid=947805#p947805 Post regarding OpenSSL encrypted keys] This post only has the {{ic|ssldec}} hooks.<br />
<br />
Note that:<br />
* You can follow the above instructions with only two primary partitions one boot partition <br />
(required because of LVM), and one primary LVM partition. Within the LVM partition you can have <br />
as many partitions as you need, but most importantly it should contain at least root, swap, and <br />
home logical volume partitions. This has the added benefit of having only one keyfile for all <br />
your partitions, and having the ability to hibernate your computer (suspend to disk) where the <br />
swap partition is encrypted. If you decide to do so your hooks in {{ic|/etc/mkinitcpio.conf}} <br />
should look like<br />
{{ic|HOOKS&#61;" ... usb usbinput (etwo or ssldec) encrypt lvm2 resume ... "}}<br />
and you should add to your {{ic|kernel}} line(if using grub, {{ic|/boot/grub/menu.lst}}) or <br />
{{ic|GRUB_CMD_LINE}}(if using grub2, {{ic|/etc/default/grub}}):<br />
{{ic|GRUB_CMD_LINE &#61; "cryptdevice&#61; .... resume&#61;/dev/mapper/<VolumeGroupName>-<LVNameOfSwap>"}}<br />
* If you need to temporarily store the unecrypted keyfile somewhere, do not store them on an <br />
unencrytped disk. Even better make sure to store them to RAM such as {{ic|/dev/shm}}.<br />
* If you want to use a GPG encrypted keyfile, you need to use a statically compiled GnuPG version 1.4 or you could edit the hooks and use this AUR package [https://aur.archlinux.org/packages.php?ID=58030 gnupg1]<br />
* It is possible that an update to OpenSSL could break the custom {{ic|ssldec}} mentioned in the second forum post.<br />
<br />
==Securing the unencrypted boot partition==<br />
Referring to an article from the ct-magazine (Issue 3/12, page 146, 01.16.2012 http://www.heise.de/ct/inhalt/2012/03/6/) the following script checks all files under {{ic|/boot}} for changes of SHA-1 hash, inode and occupied blocks on the hard drive. It also checks the MBR.<br />
<br />
The script with installation instructions is available here: ftp://ftp.heise.de/pub/ct/listings/1203-146.zip (Author: Juergen Schmidt, ju at heisec.de; License: GPLv2)<br />
<br />
There is also an AUR package: {{AUR|chkboot}}<br />
<br />
After installation, add {{ic|/usr/local/bin/chkboot.sh &}} to your {{ic|/etc/rc.local}}.<br />
<br />
And as {{ic|/usr/local/bin/chkboot_user.sh}} need to be excuted after login, add it to the autostarts (e.g. under KDE -> System Settings -> Startup and Shutdown -> Autostart)<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Install Arch Linux on top of RAID, LVM2, and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Airbus001https://wiki.archlinux.org/index.php?title=Dm-crypt&diff=209419Dm-crypt2012-06-15T23:16:51Z<p>Airbus001: /* Using GPG or OpenSSL Encrypted Keyfiles */</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[ru:System Encryption with LUKS]]<br />
[[zh-CN:System Encryption with LUKS]]<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 />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
==== Data encryption ====<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
*Preventing unauthorized physical access to private data.<br />
*Some confidence in data disposal when discarding obsolete systems.<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 />
==== System encryption ====<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 />
*Preventing unauthorized physical access to operating system files<br />
*Preventing unauthorized physical access to private data that may cached by the system.<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 />
*Attempts to bypass the operating system by inserting a boot CD/USB<br />
*Copying, modifying, or removing the hard disk drives when the computer is off<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the {{ic|/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 />
{{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 Available for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption, including:<br />
<br />
;loop-AES ([http://loop-aes.sourceforge.net/ loop-AES]):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 />
;standard device-mapper encryption ([http://www.saout.de/misc/dm-crypt/ dm-crypt]):This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
;LUKS for dm-crypt ([http://code.google.com/p/cryptsetup/ LUKS]):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 />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key (see [[Wikipedia:Kerckhoffs's principle]])<br />
::*The usage of a proven encryption algorithm<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 />
====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 />
====discard/TRIM support for solid state disks====<br />
<br />
Solid state disk users should be aware that by default, Linux's full-disk encryption mechanisms will ''not'' forward TRIM commands from the filesystem to the underlying disk. The device-mapper maintainers have made it clear that TRIM support will never be enabled by default on dm-crypt devices because of the potential security implications; if TRIM support were enabled, an attacker may be able to tell which blocks have been used, how many blocks have been used, and other information that is exposed directly to the device when a TRIM is issued.<br />
<br />
It may be possible to determine the filesystem utilized by your encrypted device through the data that is leaked by TRIM. Furthermore, any information that may be derived by a profile of block usage may be exposed by enabling TRIM support on an encrypted device.<br />
<br />
As of {{Pkg|linux}} version 3.1, support for dm-crypt TRIM pass-through can be toggled upon device creation or mount with dmsetup. Support for this option also exists in {{Pkg|cryptsetup}} version 1.4.0 and up. To add support during boot, you will need to add "{{ic|:allow-discards}}" to the {{ic|cryptdevice}} option. The option should look like this:<br />
cryptdevice=/dev/mapper/root:root:allow-discards<br />
<br />
For more information, including specific commands and details on dm-crypt TRIM pass-through, see these mailing list threads:<br />
* http://article.gmane.org/gmane.linux.kernel.device-mapper.devel/14134<br />
* http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/5166<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 shut down. 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 to extract your encryption key - thus obtaining access to your data.<br />
<br />
{{Note|System Encryption assumes encryption of all mounted partitions: this includes all partitions except for {{ic|/boot}} - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, {{ic|/tmp}}, or root filesystems are unencrypted, only Data Encryption level of security has been accomplished.}}<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 />
=====Encryption of data partitions on the same physical disk as the system=====<br />
<br />
The most common form of data encryption is encrypting the {{ic|/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 decreased by orders of magnitude when compared to system encryption. The reason for this is 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, {{Pkg|mlocate}} will scan all currently mounted file systems regularly and write the list of filenames to {{ic|/var/lib/mlocate/mlocate.db}}, which is located in the non-encrypted root or {{ic|/var}} partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted {{ic|/home}} partition, readily available to assist them in accessing the encrypted data present on 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|System Encryption with eCryptfs]].<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 Hard Disk Drives or Separate Internal Hard Disk Drives<br />
::*CD/DVD/Blu-Ray Optical Media<br />
::*Magnetic Storage Media<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 set up.<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the hard disk 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 Hard Disk Drive ===<br />
<br />
Secure erasure of the hard disk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a hard disk 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 />
====Why perform secure erasure of a drive?====<br />
<br />
There are two types of hard disk 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 Hard Disk Drives'''<br />
<br />
::In hard drives 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 Hard Disk Drives'''<br />
<br />
::Repartitioning or reformatting a used hard drive 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 straightforward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore hard drives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
====Overwriting a hard disk drive with random data====<br />
<br />
There are two sources of random data commonly used for securely overwriting hard disk partitions.<br />
<br />
::*{{ic|/dev/urandom}}<br />
::*badblocks<br />
<br />
=====Using urandom=====<br />
<br />
#dd if=/dev/urandom of=/dev/<drive> bs=1M<br />
<br />
Where {{ic|/dev/<drive>}} is the drive to be encrypted.<br />
<br />
{{Note| Using {{ic|/dev/urandom}} will take a long time to completely overwrite a drive with "random" data. In the strictest sense, {{ic|/dev/urandom}} is less random than {{ic|/dev/random}}; however, {{ic|/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 {{ic|/dev/random}} for overwriting hard disks impractical.}}<br />
<br />
{{Note| Users may also find that {{ic|/dev/urandom}} takes an excessively long time on large drives of several hundred gigabytes or more (more than twenty-four hours). [[Frandom]] offers a faster alternative.}}<br />
<br />
{{Note|You can retrieve progress of the dd command with this command: {{ic|kill -USR1 $(pidof dd)}}}}<br />
<br />
=====Using badblocks=====<br />
<br />
#badblocks -c 10240 -wsvt random /dev/<drive><br />
<br />
Where {{ic|/dev/<drive>}} is the drive to be encrypted.<br />
<br />
{{Note|The {{ic|badblocks}} command overwrites the drive at a much faster rate by generating data that is not truly random.}}<br />
<br />
See also [[badblocks]].<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a hard disk 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 />
=====After installation=====<br />
Essentially the same effect can be achieved if a file is created on each of the partitions that fills the partition completely '''after''' the system is installed and booted with encrypted partitions mounted. <br />
#dd if=/dev/zero of=/path/to/the/output/file<br />
#rm /path/to/the/input/file<br />
Just make sure that you do that for every partition on the filesystem. This works as encrypted data is indistinguishabe from random, so anone trying to access potential leftover files will just see random data.<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 with systems that require 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 three flavors: primary partitions, extended partitions, and logical partitions.<br />
<br />
;Primary Partitions: These are the normal partitions recognized by the system BIOS. There can be up to four of these stored in the MBR.<br />
<br />
;Extended Partitions: These are primary partitions that also define another partition within themselves. Extended partitions were created to work around the original limit of four primary partitions.<br />
<br />
;Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
====LVM: Logical Volume Manager====<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple hard disk drives and partitions that are not possible with standard partitions. LVM is covered in detail in the [[LVM|Arch Linux LVM Wiki Article]] which is recommended reading prior to continuing with the instructions on setting up LUKS with LVM located below.<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 is that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In this case, logical volume management would be layered on top of the hardware encryption &ndash; usage of LUKS would be superfluous.<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 two required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*{{ic|'''/'''}}<br />
:::*Will be encrypted and store all system and user files ({{ic|/usr}}, {{ic|/bin}}, {{ic|/var}}, {{ic|/home}}, etc.)<br />
<br />
::An initial boot partition<br />
<br />
:::*{{ic|'''/boot'''}}<br />
:::*Will ''not'' be encrypted; the bootloader needs to access the {{ic|/boot}} directory where it will load the initramfs/encryption modules needed to load the rest of the system which ''is'' encrypted (see [[Mkinitcpio]] for details). For this reason, {{ic|/boot}} needs to reside on its own, unencrypted partition.<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 />
=====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 used, the space unoccupied by {{ic|/boot}} and swap should be defined as single large partition which will be divided up later at the LVM level.<br />
<br />
=====Multiple Disk Systems=====<br />
<br />
In systems that will have multiple hard disk drives, the same options exist as a single disk system. After the creation of the {{ic|/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 {{ic|/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 the dialogue for manual configuration of the hard drive.<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 per LUKS partition.<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
{{Note|Using a passphrase to decrypt LUKS partitions automatically from {{ic|/etc/crypttab}} is deprecated: see http://www.mail-archive.com/arch-projects@archlinux.org/msg02115.html}}<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
A full list of options {{ic|cryptsetup}} accepts can be found in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::*{{ic|-c}} defines the cipher type<br />
::*{{ic|-y}} prompts for password confirmation on password creation<br />
::*{{ic|-s}} defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
In the following examples for creating LUKS partitions, we will use the AES cipher in XTS mode; at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup, and details about them can be found here: [[Wikipedia:Block_cipher]]<br />
<br />
'''Formatting LUKS Partitions'''<br />
<br />
First of all make sure the device mapper kernel module is loaded by executing the following: {{ic|# modprobe dm_mod}}<br />
<br />
In order to format a desired partition as an encrypted LUKS partition execute:<br />
{{hc|# cryptsetup -c <cipher> -y -s <key size> luksFormat /dev/<partition name>|<br />
Enter passphrase: <password><br />
Verify passphrase: <password>}}<br />
<br />
This should be repeated for all partitions except for {{ic|/boot}} and possibly swap.<br />
<br />
The example below will create an encrypted root partition using the AES cipher in XTS mode (generally referred to as ''XTS-AES'').<br />
{{bc|cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2}}<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 the chosen partitioning method, the {{ic|/boot}} partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<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 {{ic|/dev/<partition name>}} is actually an encrypted device and should be addressed through LUKS using the {{ic|/dev/mapper/<name>}} so as not to overwrite the encrypted data. <br />
<br />
In order to open an encrypted LUKS partition execute:<br />
{{hc|# cryptsetup luksOpen /dev/<partition name> <device-mapper name>|<br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.}}<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
::*cryptsetup luksOpen /dev/sda2 '''swap'''<br />
::::Once opened, the swap partition device address would be '''{{ic|/dev/mapper/swap}}''' instead of {{ic|/dev/sda2}}.<br />
<br />
::*cryptsetup luksOpen /dev/sda3 '''root'''<br />
::::Once opened, the root partition device address would be '''{{ic|/dev/mapper/root}}''' instead of {{ic|/dev/sda3}}.<br />
<br />
{{Note|Since {{ic|/boot}} is not encrypted, it does not need a device mapped name and will be addressed as {{ic|/dev/sda1}}.}}<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 Partitions with a Keyfile ====<br />
{{Note|This section describes using a plaintext keyfile, if you want to encrypt your keyfile giving you two factor authentication see [https://wiki.archlinux.org/index.php/System_Encryption_with_LUKS#Using_GPG_or_OpenSSL_Encrypted_Keyfiles Section 9] for details, but please still read this section.}}<br />
<br />
'''What is a Keyfile?'''<br />
<br />
A keyfile is any file in which the data contained within it 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 />
{{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 />
'''Why use a Keyfile?'''<br />
<br />
There are many kinds of keyfile. Each type of keyfile used has benefits and disadvantages summarized below:<br />
<br />
:'''keyfile.passphrase:'''<br />
::this is my passphrase I would have typed during boot but I have placed it in a file instead<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 add any security over entering a passphrase during the initial system start.<br />
<br />
:'''keyfile.randomtext:'''<br />
::fjqweifj830149-57 819y4my1- 38t1934yt8-91m 34co3;t8y;9p3y-<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 />
:'''keyfile.binary:'''<br />
::where any binary file, images, text, video could be chosen as the keyfile<br />
<br />
This is a binary file that has been defined as a keyfile. When identifying files as candidates for a keyfile, it is recommended to choose files that are relatively static such as photos, music, video clips. The benefit of these files is that they serve a dual function which can make them harder to identify as keyfiles. Instead of having a text file with a large amount of random text, the keyfile would look like a regular image file or music clip to the casual observer. The disadvantage is that if this file is lost or changed, it will most likely not be possible to access the encrypted volume without a backup passphrase. Additionally, there is a theoretical loss of randomness when compared to a randomly generated text file. This is due to the fact that images, videos and music have some intrinsic relationship between neighboring bits of data that does not exist for a text file. However this is controversial and has never been exploited publicly.<br />
<br />
'''Creating a Keyfile with Random Characters'''<br />
<br />
Here {{ic|dd}} is used to generate a keyfile of 2048 bits of random characters.<br />
<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
The usage of {{ic|dd}} is similar to initially wiping the volume with random data prior to encryption. <br />
<br />
{{Warning|Do not use [[badblocks]] here. It only generate a random pattern which just repeats its randomness over and over again.}}<br />
<br />
'''Creating a new LUKS encrypted partition with a Keyfile'''<br />
<br />
When creating a new LUKS encrypted partition, a keyfile may be associated with the partition on its creation using:<br />
<br />
# cryptsetup -c <desired cipher> -s <key size> luksFormat /dev/<volume to encrypt> '''/path/to/mykeyfile'''<br />
<br />
This is accomplished by appending the bold area to the standard cryptsetup command which defines where the keyfile is located.<br />
<br />
==== Adding Additional Passphrases or Keyfiles to a LUKS Encrypted Partition ====<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 slot 0.<br />
Additional keys will occupy slots 1&ndash;7.<br />
<br />
The addition of new keys to an encrypted partition is accomplished using cryptsetup with the {{ic|luksAddKey}} extension.<br />
<br />
# cryptsetup luksAddKey /dev/<encrypted volume> '''/path/to/mykeyfile'''<br />
<br />
Where {{ic|/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 is important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. {{ic|/dev/sdb1}} 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 {{ic|encrypt}} HOOK in the initcpio finds your keyfile, you must 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 the following:<br />
<br />
{{hc|# ls -l /dev/disk/by-label/|<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1}}<br />
<br />
or<br />
<br />
{{hc|# 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 {{ic|/dev/disk/by-label/Keys}}, or if I had wanted to use the UUID I would find {{ic|/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 ({{ic|sdb1}}, {{ic|sdb2}}, ...) but not to the USB device ({{ic|sdb}}) 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 flash drive with a [[udev]] rule. There is 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 is quickly how it goes.<br />
<br />
Get the serial number from your USB flash drive:<br />
lsusb -v | grep -A 5 Vendor<br />
<br />
Create a udev rule for it by adding the following to a file in {{ic|/etc/udev/rules.d/}}, such as {{ic|8-usbstick.rules}}:<br />
KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"<br />
<br />
Replace {{ic|$SYMLINK}} and {{ic|$SERIAL}} with their respective values. {{ic|%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 {{ic|/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. {{ic|/media/sdb1}}<br />
<br />
The keyfile can be of arbitrary content and size. We will 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 device, 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 {{ic|/etc/mkinitcpio.conf}}, one for the drive's file system and one for the codepage. Further if you created a udev rule, you should tell {{ic|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 is assumed that you use a FAT formatted USB drive. 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 />
Additionally, insert the {{ic|usb}} hook somewhere before the {{ic|encrypt}} hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
If you have a non-US keyboard, it might prove useful to load your keyboard layout before you are prompted to enter the password to unlock the root partition at boot. For this, you will need the {{ic|keymap}} hook before {{ic|encrypt}}.<br />
<br />
Generate a new image (maybe you should backup a copy of your old kernel26.img first):<br />
mkinitcpio -g /boot/initramfs-linux.img<br />
<br />
==== Storing the key as a plain (visible) file ====<br />
Be sure to choose a plain name for your key &ndash; a bit of 'security through obscurity' is always nice ;-). Avoid using dotfiles (hidden files) &ndash; the {{ic|encrypt}} hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your {{ic|/boot/grub/menu.lst}} ([[GRUB]]). It should look something like this:<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes {{ic|/dev/usbstick}} is the FAT partition of your choice. Replace it with {{ic|/dev/disk/by-...}} or whatever your device is.<br />
<br />
That is all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We will write the key directly between the Master Boot Record (MBR) and the first partition.<br />
<br />
{{Warning|You should only follow this step if you know what you are doing -- '''it can cause data loss and damage your partitions or MBR on the stick!'''}}<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 do not rely on this too much), so you would have to replace {{ic|seek<nowiki>=</nowiki>4}} with {{ic|seek<nowiki>=</nowiki>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 />
''Optional''<br />
If you do not know if you have 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 {{ic|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 {{ic|/boot/grub/menu.lst}} file (GRUB); it should look something like this:<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usb:2048:2048<br />
Format for the {{ic|cryptkey}} option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
{{ic|OFFSET}} and {{ic|SIZE}} match in this example, but this is just coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usb:8192:2048<br />
That is all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
=== Encrypting the Swap partition ===<br />
<br />
==== Without suspend-to-disk 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 />
Append a similar line to {{ic|/etc/crypttab}} to set up a randomly encrypted swap partition:<br />
<br />
<device-mapper name> <swap physical partition> SWAP "-c aes-xts-plain -h whirlpool -s 512"<br />
<br />
Where:<br />
<br />
:*{{ic|<device-mapper name>}} represents the name you want to use as label in /etc/fstab<br />
:*{{ic|<swap physical partition>}} should be the ID of the actual partition. <br> {{Warning|You should use IDs here because if there are multiple hard drives installed in the system, their naming order (sda, sdb,...) can occasionally be scrambled upon boot and thus the swap would be created over a valuable file system, destroying its content. {{ic|<nowiki>ls -l /dev/disk/*/* | grep sdl7</nowiki>}} should help you to find the desired partition.}}<br />
:*{{ic|SWAP}} identifies the partition as a swap partition<br />
:*{{ic|-c}} defines a cipher<br />
:*{{ic|-h}} defines a hash algorithm<br />
:*{{ic|-s}} defines the key size<br />
<br />
Example line (where {{ic|/dev/sdl7}} is the physical partition and {{ic|<nowiki>LABEL=swap</nowiki>}} the desired label):<br />
<br />
swap /dev/disk/by-id/scsi-SATA_Hitachi_HDS7220_JK1130YAGX0R1T-part7 SWAP "-c aes-xts-plain -h whirlpool -s 512"<br />
<br />
:Maps {{ic|/dev/sdl7}} to {{ic|/dev/mapper/swap}} as a swap partition which we can now add in {{ic|/etc/fstab}} like a normal swap.<br />
<br />
If the partition chosen for swap was previously a LUKS partition, crypttab will not overwrite the partition to create a swap partition. This is a safety measure to prevent data loss from accidental mis-identification of the swap partition in crypttab. In order to use such a partition the LUKS header must be removed. This can be accomplished with:<br />
<br />
# dd if=/dev/zero of=/dev/sdl7 bs=1M<br />
<br />
==== With suspend-to-disk support ====<br />
{{Warning|Do not use this setup with a key file. Please read about the issue reported [[Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure|here]]}}<br />
<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 pre-existent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before {{ic|/etc/crypttab}} can be used, it is required to create a hook in {{ic|/etc/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 />
* Format the partition you want to use as swap with the {{ic|cryptsetup}} command. For performance reasons, you might want to use different ciphers with different key sizes.<br />
<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check the result with:<br />
<br />
# cryptsetup luksDump /dev/<device><br />
<br />
* Open the partition in {{ic|/dev/mapper}}:<br />
<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
<br />
* Create a swap filesystem inside the mapped partition:<br />
<br />
# mkswap /dev/mapper/swapDevice<br />
<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in {{ic|/etc/crypttab}} which uses this device. Now you have to create a hook to open the swap at boot time.<br />
<br />
* Create a hook file containing the open command:<br />
<br />
{{hc|/lib/initcpio/hooks/openswap|<nowiki><br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
</nowiki>}}<br />
<br />
* Then create and edit the hook setup file:<br />
{{hc|/lib/initcpio/install/openswap|<nowiki><br />
# vim: set ft=sh:<br />
build ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
</nowiki>}}<br />
<br />
* Add the hook {{ic|openswap}} in the {{ic|HOOKS}} array in {{ic|/etc/mkinitcpio.conf}}, before {{ic|filesystem}}, but '''after''' {{ic|encrypt}} which is mandatory as well. Do not forget to add the {{ic|resume}} hook between {{ic|openswap}} and {{ic|filesystem}} as well.<br />
<br />
* Regenerate the boot image:<br />
<br />
# mkinitcpio -p linux<br />
<br />
* Add the mapped partition to {{ic|/etc/fstab}} by adding the following line:<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
<br />
* Set up your system to resume from {{ic|/dev/mapper/swapDevice}}. For example, if you use [[GRUB]] with kernel hibernation support, add {{ic|resume<nowiki>=</nowiki>/dev/mapper/swapDevice}} to the kernel line in {{ic|/boot/grub/menu.lst}}. A line with encrypted root and swap partitions can look like this:<br />
<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
<br />
At boot time, the {{ic|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 are placed '''after''' {{ic|openswap}} in the {{ic|HOOKS}} array. Please note that because of initrd opening swap, there is no entry for swapDevice in {{ic|/etc/crypttab}} needed in this case.<br />
<br />
=== Using a swap file for suspend-to-disk support ===<br />
* Choose a mapped partition (e.g. {{ic|/dev/mapper/rootDevice}}) whose mounted filesystem (e.g. {{ic|/}}) contains enough free space to hold the entire contents of your system's RAM. For example, if your system has 4 GiB RAM, then you need at least that much free space on the mounted filesystem of your chosen mapped partition for the swap file.<br />
<br />
* [[HOW_TO:_Create_swap_file#Swap_file_creation | Create the swap file]] (e.g. {{ic|/swapfile}}) inside the mounted filesystem of your chosen mapped partition. Be sure to activate it with {{ic|swapon}} and also add it to your {{ic|/etc/fstab}} file afterward.<br />
<br />
* Set up your system to resume from your chosen mapped partition. For example, if you use [[GRUB]] with kernel hibernation support, add {{ic|resume<nowiki>=</nowiki>}}''your chosen mapped partition'' and {{ic|resume_offset<nowiki>=</nowiki>}}''see calculation command below'' to the kernel line in {{ic|/boot/grub/menu.lst}}. A line with encrypted root partition can look like this:<br />
<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/rootDevice resume_offset=123456789 ro<br />
<br />
You can calculate the {{ic|resume_offset}} of your swap file like this:<br />
<br />
# filefrag -v /swapfile | awk '{if($1==0){print $3}}'<br />
<br />
* Add the {{ic|resume}} hook to your {{ic|etc/mkinitcpio.conf}} file and [[Mkinitcpio#Image_creation_and_activation|rebuild the image]] afterward:<br />
<br />
HOOKS="... encrypt '''resume''' ... filesystems ..."<br />
<br />
== Installing the system ==<br />
Now that {{ic|/dev/mapper/root}} and {{ic|/dev/mapper/home}} 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 steps and go straight to manual configuration.<br />
Instead of choosing the hardware devices ({{ic|/dev/sdaX}}) directly, you have to select the mapper devices created above.<br />
Choose {{ic|/dev/mapper/root}} for your root and {{ic|/dev/mapper/home}} as {{ic|/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 {{ic|/home}} partition. Make sure you mount {{ic|/dev/sda1}} as the {{ic|/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|The {{ic|encrypt}} hook is only needed if your root partition is a ''LUKS'' partition (or a LUKS partition that needs to be mounted ''before'' root). The {{ic|encrypt}} hook is not needed if any other partition (swap, for example) is encrypted. System initialization scripts ({{ic|/etc/rc.sysinit}} and {{ic|/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 {{ic|/etc/mkinitcpio.conf}}. For detailed information about mkinitcpio and its configuration refer to [[Mkinitcpio]]. You have to make sure that your {{ic|HOOKS}} array in {{ic|/etc/mkinitcpio.conf}} looks something like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the {{ic|encrypt}} hook comes ''before'' the {{ic|filesystems}} hook. 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 {{ic|usb}} before {{ic|encrypt}} because the hooks are run in the order they appear.<br />
If you need support for foreign keymaps for your encryption password, you have to specify the hook {{ic|keymap}} as well. I suggest putting this in {{ic|/etc/mkinitcpio.conf}} immediately before {{ic|encrypt}}.<br />
<br />
If you have a USB keyboard, you will need the {{ic|usbinput}} hook in {{ic|/etc/mkinitcpio.conf}}. Without it, no USB keyboard will work in early userspace.<br />
<br />
If your root partition is a ''LUKS'' partition, add the used filesystem to the {{ic|MODULES}} section.<br />
MODULES="... ext3 ext4 xfs ..."<br />
<br />
=== Install Bootloader ===<br />
'''[[GRUB]]:''' You have to make some small changes to the entries generated by the installer by replacing {{ic|/dev/mapper/root}} with {{ic|/dev/sda3}}. The important point to remember here is to use the same {{ic|cryptdevice}} name you assigned when you initially unlocked your device. In this example, the device name is {{ic|cryptroot}}; customize yours accordingly:<br />
<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:cryptroot root=/dev/mapper/cryptroot ro<br />
initrd /initramfs-linux.img<br />
<br />
For kernels older than 2.6.37, the syntax is:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' Edit the Arch Linux section in {{ic|/etc/lilo.conf}} and include a line for the {{ic|append}} option, over the initrd, with the {{ic|root<nowiki>=</nowiki>/dev/sda3}} parameter. The {{ic|append}} section makes the same kernel line as in GRUB. Also, you can omit the {{ic|root}} option above the {{ic|image}} option. The section looks like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz-linux<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /initramfs-linux.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note|If you want to use a USB flash drive with a keyfile, you have to append the {{ic|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 {{ic|/etc/crypttab}} file so you do not have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. {{ic|/home}}, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
<br />
Add the following line for the {{ic|/home}} partition<br />
{{Note|Using a passphrase to decrypt LUKS partitions automatically from {{ic|/etc/crypttab}} is deprecated: see http://www.mail-archive.com/arch-projects@archlinux.org/msg02115.html}}<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 [[#Adding_Additional_Passphrases_or_Keyfiles_to_a_LUKS_Encrypted_Partition|above]].<br />
Then add the following information to the {{ic|/etc/crypttab}} file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
If you used a USB device to store your keyfile, you should have something like this:<br />
home /dev/sda5 /dev/sd*1/keyfile<br />
<br />
Or if the keyfile was stored in the MBR, it should be like this:<br />
home /dev/sda5 /dev/sd*:2048:2048<br />
<br />
{{Box BLUE|Note:|When reading the keyfile from the MBR it should be {{ic|/dev/sdb}} not {{ic|/dev/sdb1}} but if the key is in the filesystem it should still be {{ic|/dev/sdb1}}.}}<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 a LUKS password. Type it in and everything should boot.<br />
Once you have logged in, have a look at your mounted partitions by typing {{ic|mount}}. You should have {{ic|/dev/mapper/root}} mounted at {{ic|/}} and, if you set up a separate encrypted home partition, {{ic|/dev/mapper/home}} mounted at {{ic|/home}}. If you set up encrypted swap, {{ic|swapon -s}} should have {{ic|/dev/mapper/swap}} 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 is not, simply enter your password and press {{keypress|Enter}}.}}<br />
<br />
== Remote unlocking of the root (or other) 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 achieved by running the {{ic|net}} hook along with an [[SSH]] server in initrd. Install the {{AUR|dropbear_initrd_encrypt}} package from the [[Arch User Repository|AUR]] and follow the post-installation instructions. Replace the {{ic|encrypt}} hook with {{ic|dropbear encryptssh}} in {{ic|/etc/mkinitcpio.conf}}. Put the {{ic|net}} hook early in the HOOKS array if your DHCP server takes a long time to lease IP addresses.<br />
<br />
If you would simply like a nice solution to mount other encrypted partitions (such as {{ic|/home}})remotely, you may want to look at [https://bbs.archlinux.org/viewtopic.php?pid=880484 this forum thread].<br />
<br />
{{Note|Acutally trim will not work with this script because it is not yet updated to the latest encrypt hook, so it is not able to parse {{ic|-–allow-discards}} from {{ic|/boot/grub/menu.lst}}. (Version: dropbear_initrd_encrypt 0.8-16). You won't notice any error when using online discard, but you see an error when you try to use {{ic|fstrim}}.For a temporary solution just add {{ic|-–allow-discards}} to every cryptsetup line of {{ic|/lib/initcpio/install/dropbear}}(1 line) and {{ic|/lib/initcpio/hooks/encryptssh}}(3 lines)}}<br />
<br />
== Backup the cryptheader ==<br />
If the header of your encrypted partition gets destroyed, you will not be able to decrypt your data. Therefore, having a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT backing up the cryptheader, but even so it's a single point of failure!<br />
In short, the problem is that LUKS is not aware of the duplicated cryptheader, which contains the master key which is used to encrypt all files on your partition. Of course this master key 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 master key 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]{{Linkrot|2011|09|05}} for further details on this.<br />
<br />
{{Note|You can also back up 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 />
=== Backup ===<br />
==== Manually ====<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 />
==== Using cryptsetup ====<br />
You can also use the luksHeaderBackup command instead:<br />
cryptsetup luksHeaderBackup /dev/sdaX --header-backup-file ./backup.img<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 />
==== Manually ====<br />
Again, you will need to the same values as when backing up:<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
==== Using cryptsetup ====<br />
Or you can use the luksHeaderRestore command:<br />
cryptsetup luksHeaderRestore /dev/sdaX --header-backup-file ./backup.img<br />
<br />
'''Note:''' All the keyslot areas are overwritten; only active keyslots from the backup file are available after issuing this command.<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 />
First, start by creating an encrypted container!<br />
<br />
dd if=/dev/urandom of=/bigsecret bs=1M count=10<br />
<br />
This will create the file {{ic|bigsecret}} with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node {{ic|/dev/loop0}}, so that we can mount/use our container.<br />
<br />
{{Note|If it gives you the error {{ic|/dev/loop0: No such file or directory}}, you need to first load the kernel module with {{ic|modprobe loop}}. These days (Kernel 3.2) loop devices are created on demand. Ask for a new loop device with {{ic|losetup -f}}.}}<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file.<br />
<br />
{{Note|If you get an error like {{ic|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 {{ic|modprobe dm-mod}}.}}<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the device file {{ic|/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 />
=== Encrypt using a key-file ===<br />
Let us 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 {{ic|/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 encrypting your keyfile using your private GPG key and storing an off-site 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 expand our container file with the size of the data we want to add:<br />
<br />
dd if=/dev/urandom bs=1M count=1024 | cat - >> /bigsecret<br />
<br />
Be careful to really use TWO {{ic|>}}, or you will override your current container!<br />
<br />
You could use {{ic|/dev/zero}} instead of {{ic|/dev/urandom}} to significantly speed up the process, but with {{ic|/dev/zero}} your encrypted filesystems will ''not be as secure''. (A better option to create random data quicker than {{ic|/dev/urandom}} is {{ic|frandom}} [https://aur.archlinux.org/packages.php?ID=9869], available from the [[AUR]]).<br />
<br />
Now we have to map the container to the loop device:<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 do not 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 the {{ic|encrypt}} hook '''before''' the {{ic|lvm2}} hook (and those two before the {{ic|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 set up your LVM volumes and then use them as the base for the encrypted partitions. That means, in short, that you have to set up LVM first. Then follow this guide, but replace all occurrences of {{ic|/dev/sdXy}} in the guide with its LVM counterpart. (E.g.: {{ic|/dev/sda5}} -> {{ic|/dev/<volume group name>/home}}).<br />
<br />
Do not forget to add the {{ic|encrypt}} hook in {{ic|/etc/mkinitcpio.conf}} '''before''' the {{ic|lvm2}} hook, if you chose to set up encrypted partitions on '''top''' of LVM. Also remember to change {{ic|USELVM}} in {{ic|/etc/rc.conf}} to {{ic|"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 partition 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 {{ic|/etc/rc.conf}} set {{ic|USELVM}} to {{ic|"yes"}}<br />
* In {{ic|/etc/mkinitcpio.conf}} add the {{ic|encrypt}} hook '''before''' the {{ic|lvm2}} hook in the {{ic|HOOKS}} array, if you set up LVM on top of the encrypted partition.<br />
<br />
That is 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 {{ic|/lib/initcpio/hooks/encrypt}} (the first one to your {{ic|/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 {{ic|/etc/crypttab}} with an external key file (i.e. the keyfile is not on any internal hard drive 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 the order of {{ic|/etc/fstab}} (at least).<br />
<br />
Of course, if the {{Pkg|cryptsetup}} package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking {{ic|/etc/rc.sysinit}} or similar files. Unlike {{ic|/etc/crypttab}}, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
If you want to do this on a software RAID partition, there is one more thing you need to do. Just setting the {{ic|/dev/mdX}} device in {{ic|/lib/initcpio/hooks/encrypt}} is not enough; the {{ic|encrypt}} hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices are not brought up until after the {{ic|encrypt}} hook is run. You can solve this by putting the RAID array in {{ic|/boot/grub/menu.lst}}, like <br />
kernel /boot/vmlinuz-linux md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID, you will notice the similarities with that setup ;-). [[GRUB]] can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz-linux root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM and dm-crypt manually (short version) ===<br />
<br />
==== Notes ====<br />
If you are smart enough for this, you will be smart enough to ignore/replace LVM-specific things if you do not want to use LVM.<br />
<br />
{{Note|This brief uses reiserfs for some of the partitions, so change this accordingly if you want to use a more "normal" file system, like ext4.}}<br />
<br />
==== Partitioning scheme ====<br />
{{ic|/dev/sda1}} -> {{ic|/boot}}<br />
{{ic|/dev/sda2}} -> LVM<br />
<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 />
<br />
==== Install Arch Linux ====<br />
Run {{ic|/arch/setup}}<br />
<br />
==== Configuration ====<br />
<br />
===== /etc/rc.conf =====<br />
Change {{ic|USELVM<nowiki>=</nowiki>"no"}} to {{ic|USELVM<nowiki>=</nowiki>"yes"}}.<br />
<br />
===== /etc/mkinitcpio.conf =====<br />
Put {{ic|lvm2}} and {{ic|encrypt}} (in that order) before {{ic|filesystems}} in the {{ic|HOOKS}} array. Again, note that you are setting encryption on '''top''' of LVM.)<br />
<br />
if you want install the system on a usb stick, you need to put {{ic|usb}} just after {{ic|udev}}.<br />
<br />
===== /boot/grub/menu.lst =====<br />
Change {{ic|root<nowiki>=</nowiki>/dev/hda3}} to {{ic|root<nowiki>=</nowiki>/dev/lvm/root}}.<br />
<br />
For kernel >= 2.6.30, you should change {{ic|root<nowiki>=</nowiki>/dev/hda3}} to the following:<br />
cryptdevice=/dev/lvm/root:root root=/dev/mapper/root<br />
<br />
if you want install the system on a usb stick, you need to add {{ic|lvmdelay<nowiki>=</nowiki>/dev/mapper/lvm-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 rebooting ====<br />
<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 />
<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on LVM on LUKS ===<br />
Make sure your kernel command line 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 />
==Using GPG or OpenSSL Encrypted Keyfiles==<br />
The following forum posts give instructions to use two factor authentication, gpg or openssl encrypted keyfiles, instead of a plaintext keyfile described earlier in this wiki article [https://bbs.archlinux.org/viewtopic.php?id=120243 System Encryption using LUKS with GPG encrypted keys]:<br />
* GnuPG: [https://bbs.archlinux.org/viewtopic.php?pid=943338#p943338 Post regarding GPG encrypted keys] This post hs the generic instructions.<br />
* OpenSSL: [https://bbs.archlinux.org/viewtopic.php?pid=947805#p947805 Post regarding OpenSSL encrypted keys] This post only has the {{ic|ssldec}} hooks.<br />
<br />
Note that:<br />
* You can follow the above instructions with only two primary partitions one boot partition <br />
(required because of LVM), and one primary LVM partition. Within the LVM partition you can have <br />
as many partitions as you need, but most importantly it should contain at least root, swap, and <br />
home logical volume partitions. This has the added benefit of having only one keyfile for all <br />
your partitions, and having the ability to hibernate your computer (suspend to disk) where the <br />
swap partition is encrypted. If you decide to do so your hooks in {{ic|/etc/mkinitcpio.conf}} <br />
should look like<br />
{{ic|HOOKS&#61;" ... usb usbinput ssldec encrypt lvm2 resume ... "}}<br />
and you should add to your {{ic|kernel}} line(if using grub, {{ic|/boot/grub/menu.lst}}) or <br />
{{ic|GRUB_CMD_LINE}}(if using grub2, {{ic|/etc/default/grub}}):<br />
{{ic|GRUB_CMD_LINE &#61; "cryptdevice&#61; .... resume&#61;/dev/mapper/<VolumeGroupName>-<LVNameOfSwap>"}}<br />
* If you need to temporarily store the unecrypted keyfile somewhere, do not store them on an <br />
unencrytped disk. Even better make sure to store them to RAM such as {{ic|/dev/shm}}.<br />
* If you want to use a GPG encrypted keyfile, you need to use a statically compiled GnuPG version 1.4 or you could edit the hooks and use this AUR package [https://aur.archlinux.org/packages.php?ID=58030 gnupg1]<br />
* It is possible that an update to OpenSSL could break the custom {{ic|ssldec}} mentioned in the second forum post.<br />
<br />
==Securing the unencrypted boot partition==<br />
Referring to an article from the ct-magazine (Issue 3/12, page 146, 01.16.2012 http://www.heise.de/ct/inhalt/2012/03/6/) the following script checks all files under {{ic|/boot}} for changes of SHA-1 hash, inode and occupied blocks on the hard drive. It also checks the MBR.<br />
<br />
The script with installation instructions is available here: ftp://ftp.heise.de/pub/ct/listings/1203-146.zip (Author: Juergen Schmidt, ju at heisec.de; License: GPLv2)<br />
<br />
There is also an AUR package: {{AUR|chkboot}}<br />
<br />
After installation, add {{ic|/usr/local/bin/chkboot.sh &}} to your {{ic|/etc/rc.local}}.<br />
<br />
And as {{ic|/usr/local/bin/chkboot_user.sh}} need to be excuted after login, add it to the autostarts (e.g. under KDE -> System Settings -> Startup and Shutdown -> Autostart)<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Install Arch Linux on top of RAID, LVM2, and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Airbus001https://wiki.archlinux.org/index.php?title=Dm-crypt&diff=209418Dm-crypt2012-06-15T23:16:14Z<p>Airbus001: /* Using GPG or OpenSSL Encrypted Keyfiles */</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[ru:System Encryption with LUKS]]<br />
[[zh-CN:System Encryption with LUKS]]<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 />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
==== Data encryption ====<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
*Preventing unauthorized physical access to private data.<br />
*Some confidence in data disposal when discarding obsolete systems.<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 />
==== System encryption ====<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 />
*Preventing unauthorized physical access to operating system files<br />
*Preventing unauthorized physical access to private data that may cached by the system.<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 />
*Attempts to bypass the operating system by inserting a boot CD/USB<br />
*Copying, modifying, or removing the hard disk drives when the computer is off<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the {{ic|/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 />
{{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 Available for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption, including:<br />
<br />
;loop-AES ([http://loop-aes.sourceforge.net/ loop-AES]):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 />
;standard device-mapper encryption ([http://www.saout.de/misc/dm-crypt/ dm-crypt]):This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
;LUKS for dm-crypt ([http://code.google.com/p/cryptsetup/ LUKS]):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 />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key (see [[Wikipedia:Kerckhoffs's principle]])<br />
::*The usage of a proven encryption algorithm<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 />
====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 />
====discard/TRIM support for solid state disks====<br />
<br />
Solid state disk users should be aware that by default, Linux's full-disk encryption mechanisms will ''not'' forward TRIM commands from the filesystem to the underlying disk. The device-mapper maintainers have made it clear that TRIM support will never be enabled by default on dm-crypt devices because of the potential security implications; if TRIM support were enabled, an attacker may be able to tell which blocks have been used, how many blocks have been used, and other information that is exposed directly to the device when a TRIM is issued.<br />
<br />
It may be possible to determine the filesystem utilized by your encrypted device through the data that is leaked by TRIM. Furthermore, any information that may be derived by a profile of block usage may be exposed by enabling TRIM support on an encrypted device.<br />
<br />
As of {{Pkg|linux}} version 3.1, support for dm-crypt TRIM pass-through can be toggled upon device creation or mount with dmsetup. Support for this option also exists in {{Pkg|cryptsetup}} version 1.4.0 and up. To add support during boot, you will need to add "{{ic|:allow-discards}}" to the {{ic|cryptdevice}} option. The option should look like this:<br />
cryptdevice=/dev/mapper/root:root:allow-discards<br />
<br />
For more information, including specific commands and details on dm-crypt TRIM pass-through, see these mailing list threads:<br />
* http://article.gmane.org/gmane.linux.kernel.device-mapper.devel/14134<br />
* http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/5166<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 shut down. 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 to extract your encryption key - thus obtaining access to your data.<br />
<br />
{{Note|System Encryption assumes encryption of all mounted partitions: this includes all partitions except for {{ic|/boot}} - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, {{ic|/tmp}}, or root filesystems are unencrypted, only Data Encryption level of security has been accomplished.}}<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 />
=====Encryption of data partitions on the same physical disk as the system=====<br />
<br />
The most common form of data encryption is encrypting the {{ic|/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 decreased by orders of magnitude when compared to system encryption. The reason for this is 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, {{Pkg|mlocate}} will scan all currently mounted file systems regularly and write the list of filenames to {{ic|/var/lib/mlocate/mlocate.db}}, which is located in the non-encrypted root or {{ic|/var}} partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted {{ic|/home}} partition, readily available to assist them in accessing the encrypted data present on 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|System Encryption with eCryptfs]].<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 Hard Disk Drives or Separate Internal Hard Disk Drives<br />
::*CD/DVD/Blu-Ray Optical Media<br />
::*Magnetic Storage Media<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 set up.<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the hard disk 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 Hard Disk Drive ===<br />
<br />
Secure erasure of the hard disk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a hard disk 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 />
====Why perform secure erasure of a drive?====<br />
<br />
There are two types of hard disk 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 Hard Disk Drives'''<br />
<br />
::In hard drives 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 Hard Disk Drives'''<br />
<br />
::Repartitioning or reformatting a used hard drive 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 straightforward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore hard drives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
====Overwriting a hard disk drive with random data====<br />
<br />
There are two sources of random data commonly used for securely overwriting hard disk partitions.<br />
<br />
::*{{ic|/dev/urandom}}<br />
::*badblocks<br />
<br />
=====Using urandom=====<br />
<br />
#dd if=/dev/urandom of=/dev/<drive> bs=1M<br />
<br />
Where {{ic|/dev/<drive>}} is the drive to be encrypted.<br />
<br />
{{Note| Using {{ic|/dev/urandom}} will take a long time to completely overwrite a drive with "random" data. In the strictest sense, {{ic|/dev/urandom}} is less random than {{ic|/dev/random}}; however, {{ic|/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 {{ic|/dev/random}} for overwriting hard disks impractical.}}<br />
<br />
{{Note| Users may also find that {{ic|/dev/urandom}} takes an excessively long time on large drives of several hundred gigabytes or more (more than twenty-four hours). [[Frandom]] offers a faster alternative.}}<br />
<br />
{{Note|You can retrieve progress of the dd command with this command: {{ic|kill -USR1 $(pidof dd)}}}}<br />
<br />
=====Using badblocks=====<br />
<br />
#badblocks -c 10240 -wsvt random /dev/<drive><br />
<br />
Where {{ic|/dev/<drive>}} is the drive to be encrypted.<br />
<br />
{{Note|The {{ic|badblocks}} command overwrites the drive at a much faster rate by generating data that is not truly random.}}<br />
<br />
See also [[badblocks]].<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a hard disk 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 />
=====After installation=====<br />
Essentially the same effect can be achieved if a file is created on each of the partitions that fills the partition completely '''after''' the system is installed and booted with encrypted partitions mounted. <br />
#dd if=/dev/zero of=/path/to/the/output/file<br />
#rm /path/to/the/input/file<br />
Just make sure that you do that for every partition on the filesystem. This works as encrypted data is indistinguishabe from random, so anone trying to access potential leftover files will just see random data.<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 with systems that require 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 three flavors: primary partitions, extended partitions, and logical partitions.<br />
<br />
;Primary Partitions: These are the normal partitions recognized by the system BIOS. There can be up to four of these stored in the MBR.<br />
<br />
;Extended Partitions: These are primary partitions that also define another partition within themselves. Extended partitions were created to work around the original limit of four primary partitions.<br />
<br />
;Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
====LVM: Logical Volume Manager====<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple hard disk drives and partitions that are not possible with standard partitions. LVM is covered in detail in the [[LVM|Arch Linux LVM Wiki Article]] which is recommended reading prior to continuing with the instructions on setting up LUKS with LVM located below.<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 is that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In this case, logical volume management would be layered on top of the hardware encryption &ndash; usage of LUKS would be superfluous.<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 two required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*{{ic|'''/'''}}<br />
:::*Will be encrypted and store all system and user files ({{ic|/usr}}, {{ic|/bin}}, {{ic|/var}}, {{ic|/home}}, etc.)<br />
<br />
::An initial boot partition<br />
<br />
:::*{{ic|'''/boot'''}}<br />
:::*Will ''not'' be encrypted; the bootloader needs to access the {{ic|/boot}} directory where it will load the initramfs/encryption modules needed to load the rest of the system which ''is'' encrypted (see [[Mkinitcpio]] for details). For this reason, {{ic|/boot}} needs to reside on its own, unencrypted partition.<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 />
=====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 used, the space unoccupied by {{ic|/boot}} and swap should be defined as single large partition which will be divided up later at the LVM level.<br />
<br />
=====Multiple Disk Systems=====<br />
<br />
In systems that will have multiple hard disk drives, the same options exist as a single disk system. After the creation of the {{ic|/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 {{ic|/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 the dialogue for manual configuration of the hard drive.<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 per LUKS partition.<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
{{Note|Using a passphrase to decrypt LUKS partitions automatically from {{ic|/etc/crypttab}} is deprecated: see http://www.mail-archive.com/arch-projects@archlinux.org/msg02115.html}}<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
A full list of options {{ic|cryptsetup}} accepts can be found in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::*{{ic|-c}} defines the cipher type<br />
::*{{ic|-y}} prompts for password confirmation on password creation<br />
::*{{ic|-s}} defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
In the following examples for creating LUKS partitions, we will use the AES cipher in XTS mode; at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup, and details about them can be found here: [[Wikipedia:Block_cipher]]<br />
<br />
'''Formatting LUKS Partitions'''<br />
<br />
First of all make sure the device mapper kernel module is loaded by executing the following: {{ic|# modprobe dm_mod}}<br />
<br />
In order to format a desired partition as an encrypted LUKS partition execute:<br />
{{hc|# cryptsetup -c <cipher> -y -s <key size> luksFormat /dev/<partition name>|<br />
Enter passphrase: <password><br />
Verify passphrase: <password>}}<br />
<br />
This should be repeated for all partitions except for {{ic|/boot}} and possibly swap.<br />
<br />
The example below will create an encrypted root partition using the AES cipher in XTS mode (generally referred to as ''XTS-AES'').<br />
{{bc|cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2}}<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 the chosen partitioning method, the {{ic|/boot}} partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<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 {{ic|/dev/<partition name>}} is actually an encrypted device and should be addressed through LUKS using the {{ic|/dev/mapper/<name>}} so as not to overwrite the encrypted data. <br />
<br />
In order to open an encrypted LUKS partition execute:<br />
{{hc|# cryptsetup luksOpen /dev/<partition name> <device-mapper name>|<br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.}}<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
::*cryptsetup luksOpen /dev/sda2 '''swap'''<br />
::::Once opened, the swap partition device address would be '''{{ic|/dev/mapper/swap}}''' instead of {{ic|/dev/sda2}}.<br />
<br />
::*cryptsetup luksOpen /dev/sda3 '''root'''<br />
::::Once opened, the root partition device address would be '''{{ic|/dev/mapper/root}}''' instead of {{ic|/dev/sda3}}.<br />
<br />
{{Note|Since {{ic|/boot}} is not encrypted, it does not need a device mapped name and will be addressed as {{ic|/dev/sda1}}.}}<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 Partitions with a Keyfile ====<br />
{{Note|This section describes using a plaintext keyfile, if you want to encrypt your keyfile giving you two factor authentication see [https://wiki.archlinux.org/index.php/System_Encryption_with_LUKS#Using_GPG_or_OpenSSL_Encrypted_Keyfiles Section 9] for details, but please still read this section.}}<br />
<br />
'''What is a Keyfile?'''<br />
<br />
A keyfile is any file in which the data contained within it 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 />
{{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 />
'''Why use a Keyfile?'''<br />
<br />
There are many kinds of keyfile. Each type of keyfile used has benefits and disadvantages summarized below:<br />
<br />
:'''keyfile.passphrase:'''<br />
::this is my passphrase I would have typed during boot but I have placed it in a file instead<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 add any security over entering a passphrase during the initial system start.<br />
<br />
:'''keyfile.randomtext:'''<br />
::fjqweifj830149-57 819y4my1- 38t1934yt8-91m 34co3;t8y;9p3y-<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 />
:'''keyfile.binary:'''<br />
::where any binary file, images, text, video could be chosen as the keyfile<br />
<br />
This is a binary file that has been defined as a keyfile. When identifying files as candidates for a keyfile, it is recommended to choose files that are relatively static such as photos, music, video clips. The benefit of these files is that they serve a dual function which can make them harder to identify as keyfiles. Instead of having a text file with a large amount of random text, the keyfile would look like a regular image file or music clip to the casual observer. The disadvantage is that if this file is lost or changed, it will most likely not be possible to access the encrypted volume without a backup passphrase. Additionally, there is a theoretical loss of randomness when compared to a randomly generated text file. This is due to the fact that images, videos and music have some intrinsic relationship between neighboring bits of data that does not exist for a text file. However this is controversial and has never been exploited publicly.<br />
<br />
'''Creating a Keyfile with Random Characters'''<br />
<br />
Here {{ic|dd}} is used to generate a keyfile of 2048 bits of random characters.<br />
<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
The usage of {{ic|dd}} is similar to initially wiping the volume with random data prior to encryption. <br />
<br />
{{Warning|Do not use [[badblocks]] here. It only generate a random pattern which just repeats its randomness over and over again.}}<br />
<br />
'''Creating a new LUKS encrypted partition with a Keyfile'''<br />
<br />
When creating a new LUKS encrypted partition, a keyfile may be associated with the partition on its creation using:<br />
<br />
# cryptsetup -c <desired cipher> -s <key size> luksFormat /dev/<volume to encrypt> '''/path/to/mykeyfile'''<br />
<br />
This is accomplished by appending the bold area to the standard cryptsetup command which defines where the keyfile is located.<br />
<br />
==== Adding Additional Passphrases or Keyfiles to a LUKS Encrypted Partition ====<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 slot 0.<br />
Additional keys will occupy slots 1&ndash;7.<br />
<br />
The addition of new keys to an encrypted partition is accomplished using cryptsetup with the {{ic|luksAddKey}} extension.<br />
<br />
# cryptsetup luksAddKey /dev/<encrypted volume> '''/path/to/mykeyfile'''<br />
<br />
Where {{ic|/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 is important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. {{ic|/dev/sdb1}} 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 {{ic|encrypt}} HOOK in the initcpio finds your keyfile, you must 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 the following:<br />
<br />
{{hc|# ls -l /dev/disk/by-label/|<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1}}<br />
<br />
or<br />
<br />
{{hc|# 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 {{ic|/dev/disk/by-label/Keys}}, or if I had wanted to use the UUID I would find {{ic|/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 ({{ic|sdb1}}, {{ic|sdb2}}, ...) but not to the USB device ({{ic|sdb}}) 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 flash drive with a [[udev]] rule. There is 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 is quickly how it goes.<br />
<br />
Get the serial number from your USB flash drive:<br />
lsusb -v | grep -A 5 Vendor<br />
<br />
Create a udev rule for it by adding the following to a file in {{ic|/etc/udev/rules.d/}}, such as {{ic|8-usbstick.rules}}:<br />
KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"<br />
<br />
Replace {{ic|$SYMLINK}} and {{ic|$SERIAL}} with their respective values. {{ic|%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 {{ic|/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. {{ic|/media/sdb1}}<br />
<br />
The keyfile can be of arbitrary content and size. We will 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 device, 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 {{ic|/etc/mkinitcpio.conf}}, one for the drive's file system and one for the codepage. Further if you created a udev rule, you should tell {{ic|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 is assumed that you use a FAT formatted USB drive. 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 />
Additionally, insert the {{ic|usb}} hook somewhere before the {{ic|encrypt}} hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
If you have a non-US keyboard, it might prove useful to load your keyboard layout before you are prompted to enter the password to unlock the root partition at boot. For this, you will need the {{ic|keymap}} hook before {{ic|encrypt}}.<br />
<br />
Generate a new image (maybe you should backup a copy of your old kernel26.img first):<br />
mkinitcpio -g /boot/initramfs-linux.img<br />
<br />
==== Storing the key as a plain (visible) file ====<br />
Be sure to choose a plain name for your key &ndash; a bit of 'security through obscurity' is always nice ;-). Avoid using dotfiles (hidden files) &ndash; the {{ic|encrypt}} hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your {{ic|/boot/grub/menu.lst}} ([[GRUB]]). It should look something like this:<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes {{ic|/dev/usbstick}} is the FAT partition of your choice. Replace it with {{ic|/dev/disk/by-...}} or whatever your device is.<br />
<br />
That is all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We will write the key directly between the Master Boot Record (MBR) and the first partition.<br />
<br />
{{Warning|You should only follow this step if you know what you are doing -- '''it can cause data loss and damage your partitions or MBR on the stick!'''}}<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 do not rely on this too much), so you would have to replace {{ic|seek<nowiki>=</nowiki>4}} with {{ic|seek<nowiki>=</nowiki>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 />
''Optional''<br />
If you do not know if you have 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 {{ic|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 {{ic|/boot/grub/menu.lst}} file (GRUB); it should look something like this:<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usb:2048:2048<br />
Format for the {{ic|cryptkey}} option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
{{ic|OFFSET}} and {{ic|SIZE}} match in this example, but this is just coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usb:8192:2048<br />
That is all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
=== Encrypting the Swap partition ===<br />
<br />
==== Without suspend-to-disk 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 />
Append a similar line to {{ic|/etc/crypttab}} to set up a randomly encrypted swap partition:<br />
<br />
<device-mapper name> <swap physical partition> SWAP "-c aes-xts-plain -h whirlpool -s 512"<br />
<br />
Where:<br />
<br />
:*{{ic|<device-mapper name>}} represents the name you want to use as label in /etc/fstab<br />
:*{{ic|<swap physical partition>}} should be the ID of the actual partition. <br> {{Warning|You should use IDs here because if there are multiple hard drives installed in the system, their naming order (sda, sdb,...) can occasionally be scrambled upon boot and thus the swap would be created over a valuable file system, destroying its content. {{ic|<nowiki>ls -l /dev/disk/*/* | grep sdl7</nowiki>}} should help you to find the desired partition.}}<br />
:*{{ic|SWAP}} identifies the partition as a swap partition<br />
:*{{ic|-c}} defines a cipher<br />
:*{{ic|-h}} defines a hash algorithm<br />
:*{{ic|-s}} defines the key size<br />
<br />
Example line (where {{ic|/dev/sdl7}} is the physical partition and {{ic|<nowiki>LABEL=swap</nowiki>}} the desired label):<br />
<br />
swap /dev/disk/by-id/scsi-SATA_Hitachi_HDS7220_JK1130YAGX0R1T-part7 SWAP "-c aes-xts-plain -h whirlpool -s 512"<br />
<br />
:Maps {{ic|/dev/sdl7}} to {{ic|/dev/mapper/swap}} as a swap partition which we can now add in {{ic|/etc/fstab}} like a normal swap.<br />
<br />
If the partition chosen for swap was previously a LUKS partition, crypttab will not overwrite the partition to create a swap partition. This is a safety measure to prevent data loss from accidental mis-identification of the swap partition in crypttab. In order to use such a partition the LUKS header must be removed. This can be accomplished with:<br />
<br />
# dd if=/dev/zero of=/dev/sdl7 bs=1M<br />
<br />
==== With suspend-to-disk support ====<br />
{{Warning|Do not use this setup with a key file. Please read about the issue reported [[Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure|here]]}}<br />
<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 pre-existent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before {{ic|/etc/crypttab}} can be used, it is required to create a hook in {{ic|/etc/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 />
* Format the partition you want to use as swap with the {{ic|cryptsetup}} command. For performance reasons, you might want to use different ciphers with different key sizes.<br />
<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check the result with:<br />
<br />
# cryptsetup luksDump /dev/<device><br />
<br />
* Open the partition in {{ic|/dev/mapper}}:<br />
<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
<br />
* Create a swap filesystem inside the mapped partition:<br />
<br />
# mkswap /dev/mapper/swapDevice<br />
<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in {{ic|/etc/crypttab}} which uses this device. Now you have to create a hook to open the swap at boot time.<br />
<br />
* Create a hook file containing the open command:<br />
<br />
{{hc|/lib/initcpio/hooks/openswap|<nowiki><br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
</nowiki>}}<br />
<br />
* Then create and edit the hook setup file:<br />
{{hc|/lib/initcpio/install/openswap|<nowiki><br />
# vim: set ft=sh:<br />
build ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
</nowiki>}}<br />
<br />
* Add the hook {{ic|openswap}} in the {{ic|HOOKS}} array in {{ic|/etc/mkinitcpio.conf}}, before {{ic|filesystem}}, but '''after''' {{ic|encrypt}} which is mandatory as well. Do not forget to add the {{ic|resume}} hook between {{ic|openswap}} and {{ic|filesystem}} as well.<br />
<br />
* Regenerate the boot image:<br />
<br />
# mkinitcpio -p linux<br />
<br />
* Add the mapped partition to {{ic|/etc/fstab}} by adding the following line:<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
<br />
* Set up your system to resume from {{ic|/dev/mapper/swapDevice}}. For example, if you use [[GRUB]] with kernel hibernation support, add {{ic|resume<nowiki>=</nowiki>/dev/mapper/swapDevice}} to the kernel line in {{ic|/boot/grub/menu.lst}}. A line with encrypted root and swap partitions can look like this:<br />
<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
<br />
At boot time, the {{ic|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 are placed '''after''' {{ic|openswap}} in the {{ic|HOOKS}} array. Please note that because of initrd opening swap, there is no entry for swapDevice in {{ic|/etc/crypttab}} needed in this case.<br />
<br />
=== Using a swap file for suspend-to-disk support ===<br />
* Choose a mapped partition (e.g. {{ic|/dev/mapper/rootDevice}}) whose mounted filesystem (e.g. {{ic|/}}) contains enough free space to hold the entire contents of your system's RAM. For example, if your system has 4 GiB RAM, then you need at least that much free space on the mounted filesystem of your chosen mapped partition for the swap file.<br />
<br />
* [[HOW_TO:_Create_swap_file#Swap_file_creation | Create the swap file]] (e.g. {{ic|/swapfile}}) inside the mounted filesystem of your chosen mapped partition. Be sure to activate it with {{ic|swapon}} and also add it to your {{ic|/etc/fstab}} file afterward.<br />
<br />
* Set up your system to resume from your chosen mapped partition. For example, if you use [[GRUB]] with kernel hibernation support, add {{ic|resume<nowiki>=</nowiki>}}''your chosen mapped partition'' and {{ic|resume_offset<nowiki>=</nowiki>}}''see calculation command below'' to the kernel line in {{ic|/boot/grub/menu.lst}}. A line with encrypted root partition can look like this:<br />
<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/rootDevice resume_offset=123456789 ro<br />
<br />
You can calculate the {{ic|resume_offset}} of your swap file like this:<br />
<br />
# filefrag -v /swapfile | awk '{if($1==0){print $3}}'<br />
<br />
* Add the {{ic|resume}} hook to your {{ic|etc/mkinitcpio.conf}} file and [[Mkinitcpio#Image_creation_and_activation|rebuild the image]] afterward:<br />
<br />
HOOKS="... encrypt '''resume''' ... filesystems ..."<br />
<br />
== Installing the system ==<br />
Now that {{ic|/dev/mapper/root}} and {{ic|/dev/mapper/home}} 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 steps and go straight to manual configuration.<br />
Instead of choosing the hardware devices ({{ic|/dev/sdaX}}) directly, you have to select the mapper devices created above.<br />
Choose {{ic|/dev/mapper/root}} for your root and {{ic|/dev/mapper/home}} as {{ic|/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 {{ic|/home}} partition. Make sure you mount {{ic|/dev/sda1}} as the {{ic|/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|The {{ic|encrypt}} hook is only needed if your root partition is a ''LUKS'' partition (or a LUKS partition that needs to be mounted ''before'' root). The {{ic|encrypt}} hook is not needed if any other partition (swap, for example) is encrypted. System initialization scripts ({{ic|/etc/rc.sysinit}} and {{ic|/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 {{ic|/etc/mkinitcpio.conf}}. For detailed information about mkinitcpio and its configuration refer to [[Mkinitcpio]]. You have to make sure that your {{ic|HOOKS}} array in {{ic|/etc/mkinitcpio.conf}} looks something like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the {{ic|encrypt}} hook comes ''before'' the {{ic|filesystems}} hook. 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 {{ic|usb}} before {{ic|encrypt}} because the hooks are run in the order they appear.<br />
If you need support for foreign keymaps for your encryption password, you have to specify the hook {{ic|keymap}} as well. I suggest putting this in {{ic|/etc/mkinitcpio.conf}} immediately before {{ic|encrypt}}.<br />
<br />
If you have a USB keyboard, you will need the {{ic|usbinput}} hook in {{ic|/etc/mkinitcpio.conf}}. Without it, no USB keyboard will work in early userspace.<br />
<br />
If your root partition is a ''LUKS'' partition, add the used filesystem to the {{ic|MODULES}} section.<br />
MODULES="... ext3 ext4 xfs ..."<br />
<br />
=== Install Bootloader ===<br />
'''[[GRUB]]:''' You have to make some small changes to the entries generated by the installer by replacing {{ic|/dev/mapper/root}} with {{ic|/dev/sda3}}. The important point to remember here is to use the same {{ic|cryptdevice}} name you assigned when you initially unlocked your device. In this example, the device name is {{ic|cryptroot}}; customize yours accordingly:<br />
<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:cryptroot root=/dev/mapper/cryptroot ro<br />
initrd /initramfs-linux.img<br />
<br />
For kernels older than 2.6.37, the syntax is:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' Edit the Arch Linux section in {{ic|/etc/lilo.conf}} and include a line for the {{ic|append}} option, over the initrd, with the {{ic|root<nowiki>=</nowiki>/dev/sda3}} parameter. The {{ic|append}} section makes the same kernel line as in GRUB. Also, you can omit the {{ic|root}} option above the {{ic|image}} option. The section looks like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz-linux<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /initramfs-linux.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note|If you want to use a USB flash drive with a keyfile, you have to append the {{ic|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 {{ic|/etc/crypttab}} file so you do not have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. {{ic|/home}}, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
<br />
Add the following line for the {{ic|/home}} partition<br />
{{Note|Using a passphrase to decrypt LUKS partitions automatically from {{ic|/etc/crypttab}} is deprecated: see http://www.mail-archive.com/arch-projects@archlinux.org/msg02115.html}}<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 [[#Adding_Additional_Passphrases_or_Keyfiles_to_a_LUKS_Encrypted_Partition|above]].<br />
Then add the following information to the {{ic|/etc/crypttab}} file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
If you used a USB device to store your keyfile, you should have something like this:<br />
home /dev/sda5 /dev/sd*1/keyfile<br />
<br />
Or if the keyfile was stored in the MBR, it should be like this:<br />
home /dev/sda5 /dev/sd*:2048:2048<br />
<br />
{{Box BLUE|Note:|When reading the keyfile from the MBR it should be {{ic|/dev/sdb}} not {{ic|/dev/sdb1}} but if the key is in the filesystem it should still be {{ic|/dev/sdb1}}.}}<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 a LUKS password. Type it in and everything should boot.<br />
Once you have logged in, have a look at your mounted partitions by typing {{ic|mount}}. You should have {{ic|/dev/mapper/root}} mounted at {{ic|/}} and, if you set up a separate encrypted home partition, {{ic|/dev/mapper/home}} mounted at {{ic|/home}}. If you set up encrypted swap, {{ic|swapon -s}} should have {{ic|/dev/mapper/swap}} 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 is not, simply enter your password and press {{keypress|Enter}}.}}<br />
<br />
== Remote unlocking of the root (or other) 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 achieved by running the {{ic|net}} hook along with an [[SSH]] server in initrd. Install the {{AUR|dropbear_initrd_encrypt}} package from the [[Arch User Repository|AUR]] and follow the post-installation instructions. Replace the {{ic|encrypt}} hook with {{ic|dropbear encryptssh}} in {{ic|/etc/mkinitcpio.conf}}. Put the {{ic|net}} hook early in the HOOKS array if your DHCP server takes a long time to lease IP addresses.<br />
<br />
If you would simply like a nice solution to mount other encrypted partitions (such as {{ic|/home}})remotely, you may want to look at [https://bbs.archlinux.org/viewtopic.php?pid=880484 this forum thread].<br />
<br />
{{Note|Acutally trim will not work with this script because it is not yet updated to the latest encrypt hook, so it is not able to parse {{ic|-–allow-discards}} from {{ic|/boot/grub/menu.lst}}. (Version: dropbear_initrd_encrypt 0.8-16). You won't notice any error when using online discard, but you see an error when you try to use {{ic|fstrim}}.For a temporary solution just add {{ic|-–allow-discards}} to every cryptsetup line of {{ic|/lib/initcpio/install/dropbear}}(1 line) and {{ic|/lib/initcpio/hooks/encryptssh}}(3 lines)}}<br />
<br />
== Backup the cryptheader ==<br />
If the header of your encrypted partition gets destroyed, you will not be able to decrypt your data. Therefore, having a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT backing up the cryptheader, but even so it's a single point of failure!<br />
In short, the problem is that LUKS is not aware of the duplicated cryptheader, which contains the master key which is used to encrypt all files on your partition. Of course this master key 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 master key 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]{{Linkrot|2011|09|05}} for further details on this.<br />
<br />
{{Note|You can also back up 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 />
=== Backup ===<br />
==== Manually ====<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 />
==== Using cryptsetup ====<br />
You can also use the luksHeaderBackup command instead:<br />
cryptsetup luksHeaderBackup /dev/sdaX --header-backup-file ./backup.img<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 />
==== Manually ====<br />
Again, you will need to the same values as when backing up:<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
==== Using cryptsetup ====<br />
Or you can use the luksHeaderRestore command:<br />
cryptsetup luksHeaderRestore /dev/sdaX --header-backup-file ./backup.img<br />
<br />
'''Note:''' All the keyslot areas are overwritten; only active keyslots from the backup file are available after issuing this command.<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 />
First, start by creating an encrypted container!<br />
<br />
dd if=/dev/urandom of=/bigsecret bs=1M count=10<br />
<br />
This will create the file {{ic|bigsecret}} with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node {{ic|/dev/loop0}}, so that we can mount/use our container.<br />
<br />
{{Note|If it gives you the error {{ic|/dev/loop0: No such file or directory}}, you need to first load the kernel module with {{ic|modprobe loop}}. These days (Kernel 3.2) loop devices are created on demand. Ask for a new loop device with {{ic|losetup -f}}.}}<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file.<br />
<br />
{{Note|If you get an error like {{ic|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 {{ic|modprobe dm-mod}}.}}<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the device file {{ic|/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 />
=== Encrypt using a key-file ===<br />
Let us 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 {{ic|/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 encrypting your keyfile using your private GPG key and storing an off-site 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 expand our container file with the size of the data we want to add:<br />
<br />
dd if=/dev/urandom bs=1M count=1024 | cat - >> /bigsecret<br />
<br />
Be careful to really use TWO {{ic|>}}, or you will override your current container!<br />
<br />
You could use {{ic|/dev/zero}} instead of {{ic|/dev/urandom}} to significantly speed up the process, but with {{ic|/dev/zero}} your encrypted filesystems will ''not be as secure''. (A better option to create random data quicker than {{ic|/dev/urandom}} is {{ic|frandom}} [https://aur.archlinux.org/packages.php?ID=9869], available from the [[AUR]]).<br />
<br />
Now we have to map the container to the loop device:<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 do not 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 the {{ic|encrypt}} hook '''before''' the {{ic|lvm2}} hook (and those two before the {{ic|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 set up your LVM volumes and then use them as the base for the encrypted partitions. That means, in short, that you have to set up LVM first. Then follow this guide, but replace all occurrences of {{ic|/dev/sdXy}} in the guide with its LVM counterpart. (E.g.: {{ic|/dev/sda5}} -> {{ic|/dev/<volume group name>/home}}).<br />
<br />
Do not forget to add the {{ic|encrypt}} hook in {{ic|/etc/mkinitcpio.conf}} '''before''' the {{ic|lvm2}} hook, if you chose to set up encrypted partitions on '''top''' of LVM. Also remember to change {{ic|USELVM}} in {{ic|/etc/rc.conf}} to {{ic|"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 partition 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 {{ic|/etc/rc.conf}} set {{ic|USELVM}} to {{ic|"yes"}}<br />
* In {{ic|/etc/mkinitcpio.conf}} add the {{ic|encrypt}} hook '''before''' the {{ic|lvm2}} hook in the {{ic|HOOKS}} array, if you set up LVM on top of the encrypted partition.<br />
<br />
That is 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 {{ic|/lib/initcpio/hooks/encrypt}} (the first one to your {{ic|/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 {{ic|/etc/crypttab}} with an external key file (i.e. the keyfile is not on any internal hard drive 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 the order of {{ic|/etc/fstab}} (at least).<br />
<br />
Of course, if the {{Pkg|cryptsetup}} package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking {{ic|/etc/rc.sysinit}} or similar files. Unlike {{ic|/etc/crypttab}}, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
If you want to do this on a software RAID partition, there is one more thing you need to do. Just setting the {{ic|/dev/mdX}} device in {{ic|/lib/initcpio/hooks/encrypt}} is not enough; the {{ic|encrypt}} hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices are not brought up until after the {{ic|encrypt}} hook is run. You can solve this by putting the RAID array in {{ic|/boot/grub/menu.lst}}, like <br />
kernel /boot/vmlinuz-linux md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID, you will notice the similarities with that setup ;-). [[GRUB]] can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz-linux root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM and dm-crypt manually (short version) ===<br />
<br />
==== Notes ====<br />
If you are smart enough for this, you will be smart enough to ignore/replace LVM-specific things if you do not want to use LVM.<br />
<br />
{{Note|This brief uses reiserfs for some of the partitions, so change this accordingly if you want to use a more "normal" file system, like ext4.}}<br />
<br />
==== Partitioning scheme ====<br />
{{ic|/dev/sda1}} -> {{ic|/boot}}<br />
{{ic|/dev/sda2}} -> LVM<br />
<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 />
<br />
==== Install Arch Linux ====<br />
Run {{ic|/arch/setup}}<br />
<br />
==== Configuration ====<br />
<br />
===== /etc/rc.conf =====<br />
Change {{ic|USELVM<nowiki>=</nowiki>"no"}} to {{ic|USELVM<nowiki>=</nowiki>"yes"}}.<br />
<br />
===== /etc/mkinitcpio.conf =====<br />
Put {{ic|lvm2}} and {{ic|encrypt}} (in that order) before {{ic|filesystems}} in the {{ic|HOOKS}} array. Again, note that you are setting encryption on '''top''' of LVM.)<br />
<br />
if you want install the system on a usb stick, you need to put {{ic|usb}} just after {{ic|udev}}.<br />
<br />
===== /boot/grub/menu.lst =====<br />
Change {{ic|root<nowiki>=</nowiki>/dev/hda3}} to {{ic|root<nowiki>=</nowiki>/dev/lvm/root}}.<br />
<br />
For kernel >= 2.6.30, you should change {{ic|root<nowiki>=</nowiki>/dev/hda3}} to the following:<br />
cryptdevice=/dev/lvm/root:root root=/dev/mapper/root<br />
<br />
if you want install the system on a usb stick, you need to add {{ic|lvmdelay<nowiki>=</nowiki>/dev/mapper/lvm-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 rebooting ====<br />
<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 />
<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on LVM on LUKS ===<br />
Make sure your kernel command line 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 />
==Using GPG or OpenSSL Encrypted Keyfiles==<br />
The following forum posts give instructions to use two factor authentication, gpg or openssl encrypted keyfiles, instead of a plaintext keyfile described earlier in this wiki article [https://bbs.archlinux.org/viewtopic.php?id=120243 System Encryption using LUKS with GPG encrypted keys]:<br />
* GnuPG: [https://bbs.archlinux.org/viewtopic.php?pid=943338#p943338 Post regarding GPG encrypted keys] This post hs the generic instructions.<br />
* OpenSSL: [https://bbs.archlinux.org/viewtopic.php?pid=947805#p947805 Post regarding OpenSSL encrypted keys] This post only has the {{ic|ssldec}} hooks.<br />
<br />
Note that:<br />
* You can follow the above instructions with only two primary partitions one boot partition <br />
(required because of LVM), and one primary LVM partition. Within the LVM partition you can have <br />
as many partitions as you need, but most importantly it should contain at least root, swap, and <br />
home logical volume partitions. This has the added benefit of having only one keyfile for all <br />
your partitions, and having the ability to hibernate your computer (suspend to disk) where the <br />
swap partition is encrypted. If you decide to do so your hooks in {{ic|/etc/mkinitcpio.conf}} <br />
should look like<br />
{{ic|HOOKS&#61;" ... usb usbinput ssldec encrypt lvm2 resume ... "}}<br />
and you should add to your {{ic|kernel}} line(if using grub, {{ic|/boot/grub/menu.lst}}) or <br />
{{ic|GRUB_CMD_LINE}}(if using grub2, {{ic|/etc/default/grub}}):<br />
{{ic|GRUB_CMD_LINE &#61; "cryptdevice&#61; .... resume&#61;/dev/mapper/<VolumeGroupName>-<LVNameOfSwap>"}}<br />
* If you need to temporarily store the unecrypted keyfile somewhere, do not store them on an <br />
unencrytped disk. Even better make sure to store them to RAM such as /dev/shm.<br />
* If you want to use a GPG encrypted keyfile, you need to use a statically compiled GnuPG version 1.4 or you could edit the hooks and use this AUR package [https://aur.archlinux.org/packages.php?ID=58030 gnupg1]<br />
* It is possible that an update to OpenSSL could break the custom {{ic|ssldec}} mentioned in the second forum post.<br />
<br />
==Securing the unencrypted boot partition==<br />
Referring to an article from the ct-magazine (Issue 3/12, page 146, 01.16.2012 http://www.heise.de/ct/inhalt/2012/03/6/) the following script checks all files under {{ic|/boot}} for changes of SHA-1 hash, inode and occupied blocks on the hard drive. It also checks the MBR.<br />
<br />
The script with installation instructions is available here: ftp://ftp.heise.de/pub/ct/listings/1203-146.zip (Author: Juergen Schmidt, ju at heisec.de; License: GPLv2)<br />
<br />
There is also an AUR package: {{AUR|chkboot}}<br />
<br />
After installation, add {{ic|/usr/local/bin/chkboot.sh &}} to your {{ic|/etc/rc.local}}.<br />
<br />
And as {{ic|/usr/local/bin/chkboot_user.sh}} need to be excuted after login, add it to the autostarts (e.g. under KDE -> System Settings -> Startup and Shutdown -> Autostart)<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Install Arch Linux on top of RAID, LVM2, and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Airbus001https://wiki.archlinux.org/index.php?title=Dm-crypt&diff=209411Dm-crypt2012-06-15T22:36:01Z<p>Airbus001: /* Using LUKS to Format Partitions with a Keyfile */</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[ru:System Encryption with LUKS]]<br />
[[zh-CN:System Encryption with LUKS]]<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 />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
==== Data encryption ====<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
*Preventing unauthorized physical access to private data.<br />
*Some confidence in data disposal when discarding obsolete systems.<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 />
==== System encryption ====<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 />
*Preventing unauthorized physical access to operating system files<br />
*Preventing unauthorized physical access to private data that may cached by the system.<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 />
*Attempts to bypass the operating system by inserting a boot CD/USB<br />
*Copying, modifying, or removing the hard disk drives when the computer is off<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the {{ic|/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 />
{{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 Available for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption, including:<br />
<br />
;loop-AES ([http://loop-aes.sourceforge.net/ loop-AES]):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 />
;standard device-mapper encryption ([http://www.saout.de/misc/dm-crypt/ dm-crypt]):This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
;LUKS for dm-crypt ([http://code.google.com/p/cryptsetup/ LUKS]):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 />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key (see [[Wikipedia:Kerckhoffs's principle]])<br />
::*The usage of a proven encryption algorithm<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 />
====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 />
====discard/TRIM support for solid state disks====<br />
<br />
Solid state disk users should be aware that by default, Linux's full-disk encryption mechanisms will ''not'' forward TRIM commands from the filesystem to the underlying disk. The device-mapper maintainers have made it clear that TRIM support will never be enabled by default on dm-crypt devices because of the potential security implications; if TRIM support were enabled, an attacker may be able to tell which blocks have been used, how many blocks have been used, and other information that is exposed directly to the device when a TRIM is issued.<br />
<br />
It may be possible to determine the filesystem utilized by your encrypted device through the data that is leaked by TRIM. Furthermore, any information that may be derived by a profile of block usage may be exposed by enabling TRIM support on an encrypted device.<br />
<br />
As of {{Pkg|linux}} version 3.1, support for dm-crypt TRIM pass-through can be toggled upon device creation or mount with dmsetup. Support for this option also exists in {{Pkg|cryptsetup}} version 1.4.0 and up. To add support during boot, you will need to add "{{ic|:allow-discards}}" to the {{ic|cryptdevice}} option. The option should look like this:<br />
cryptdevice=/dev/mapper/root:root:allow-discards<br />
<br />
For more information, including specific commands and details on dm-crypt TRIM pass-through, see these mailing list threads:<br />
* http://article.gmane.org/gmane.linux.kernel.device-mapper.devel/14134<br />
* http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/5166<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 shut down. 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 to extract your encryption key - thus obtaining access to your data.<br />
<br />
{{Note|System Encryption assumes encryption of all mounted partitions: this includes all partitions except for {{ic|/boot}} - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, {{ic|/tmp}}, or root filesystems are unencrypted, only Data Encryption level of security has been accomplished.}}<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 />
=====Encryption of data partitions on the same physical disk as the system=====<br />
<br />
The most common form of data encryption is encrypting the {{ic|/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 decreased by orders of magnitude when compared to system encryption. The reason for this is 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, {{Pkg|mlocate}} will scan all currently mounted file systems regularly and write the list of filenames to {{ic|/var/lib/mlocate/mlocate.db}}, which is located in the non-encrypted root or {{ic|/var}} partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted {{ic|/home}} partition, readily available to assist them in accessing the encrypted data present on 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|System Encryption with eCryptfs]].<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 Hard Disk Drives or Separate Internal Hard Disk Drives<br />
::*CD/DVD/Blu-Ray Optical Media<br />
::*Magnetic Storage Media<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 set up.<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the hard disk 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 Hard Disk Drive ===<br />
<br />
Secure erasure of the hard disk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a hard disk 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 />
====Why perform secure erasure of a drive?====<br />
<br />
There are two types of hard disk 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 Hard Disk Drives'''<br />
<br />
::In hard drives 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 Hard Disk Drives'''<br />
<br />
::Repartitioning or reformatting a used hard drive 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 straightforward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore hard drives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
====Overwriting a hard disk drive with random data====<br />
<br />
There are two sources of random data commonly used for securely overwriting hard disk partitions.<br />
<br />
::*{{ic|/dev/urandom}}<br />
::*badblocks<br />
<br />
=====Using urandom=====<br />
<br />
#dd if=/dev/urandom of=/dev/<drive> bs=1M<br />
<br />
Where {{ic|/dev/<drive>}} is the drive to be encrypted.<br />
<br />
{{Note| Using {{ic|/dev/urandom}} will take a long time to completely overwrite a drive with "random" data. In the strictest sense, {{ic|/dev/urandom}} is less random than {{ic|/dev/random}}; however, {{ic|/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 {{ic|/dev/random}} for overwriting hard disks impractical.}}<br />
<br />
{{Note| Users may also find that {{ic|/dev/urandom}} takes an excessively long time on large drives of several hundred gigabytes or more (more than twenty-four hours). [[Frandom]] offers a faster alternative.}}<br />
<br />
{{Note|You can retrieve progress of the dd command with this command: {{ic|kill -USR1 $(pidof dd)}}}}<br />
<br />
=====Using badblocks=====<br />
<br />
#badblocks -c 10240 -wsvt random /dev/<drive><br />
<br />
Where {{ic|/dev/<drive>}} is the drive to be encrypted.<br />
<br />
{{Note|The {{ic|badblocks}} command overwrites the drive at a much faster rate by generating data that is not truly random.}}<br />
<br />
See also [[badblocks]].<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a hard disk 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 />
=====After installation=====<br />
Essentially the same effect can be achieved if a file is created on each of the partitions that fills the partition completely '''after''' the system is installed and booted with encrypted partitions mounted. <br />
#dd if=/dev/zero of=/path/to/the/output/file<br />
#rm /path/to/the/input/file<br />
Just make sure that you do that for every partition on the filesystem. This works as encrypted data is indistinguishabe from random, so anone trying to access potential leftover files will just see random data.<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 with systems that require 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 three flavors: primary partitions, extended partitions, and logical partitions.<br />
<br />
;Primary Partitions: These are the normal partitions recognized by the system BIOS. There can be up to four of these stored in the MBR.<br />
<br />
;Extended Partitions: These are primary partitions that also define another partition within themselves. Extended partitions were created to work around the original limit of four primary partitions.<br />
<br />
;Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
====LVM: Logical Volume Manager====<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple hard disk drives and partitions that are not possible with standard partitions. LVM is covered in detail in the [[LVM|Arch Linux LVM Wiki Article]] which is recommended reading prior to continuing with the instructions on setting up LUKS with LVM located below.<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 is that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In this case, logical volume management would be layered on top of the hardware encryption &ndash; usage of LUKS would be superfluous.<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 two required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*{{ic|'''/'''}}<br />
:::*Will be encrypted and store all system and user files ({{ic|/usr}}, {{ic|/bin}}, {{ic|/var}}, {{ic|/home}}, etc.)<br />
<br />
::An initial boot partition<br />
<br />
:::*{{ic|'''/boot'''}}<br />
:::*Will ''not'' be encrypted; the bootloader needs to access the {{ic|/boot}} directory where it will load the initramfs/encryption modules needed to load the rest of the system which ''is'' encrypted (see [[Mkinitcpio]] for details). For this reason, {{ic|/boot}} needs to reside on its own, unencrypted partition.<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 />
=====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 used, the space unoccupied by {{ic|/boot}} and swap should be defined as single large partition which will be divided up later at the LVM level.<br />
<br />
=====Multiple Disk Systems=====<br />
<br />
In systems that will have multiple hard disk drives, the same options exist as a single disk system. After the creation of the {{ic|/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 {{ic|/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 the dialogue for manual configuration of the hard drive.<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 per LUKS partition.<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
{{Note|Using a passphrase to decrypt LUKS partitions automatically from {{ic|/etc/crypttab}} is deprecated: see http://www.mail-archive.com/arch-projects@archlinux.org/msg02115.html}}<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
A full list of options {{ic|cryptsetup}} accepts can be found in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::*{{ic|-c}} defines the cipher type<br />
::*{{ic|-y}} prompts for password confirmation on password creation<br />
::*{{ic|-s}} defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
In the following examples for creating LUKS partitions, we will use the AES cipher in XTS mode; at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup, and details about them can be found here: [[Wikipedia:Block_cipher]]<br />
<br />
'''Formatting LUKS Partitions'''<br />
<br />
First of all make sure the device mapper kernel module is loaded by executing the following: {{ic|# modprobe dm_mod}}<br />
<br />
In order to format a desired partition as an encrypted LUKS partition execute:<br />
{{hc|# cryptsetup -c <cipher> -y -s <key size> luksFormat /dev/<partition name>|<br />
Enter passphrase: <password><br />
Verify passphrase: <password>}}<br />
<br />
This should be repeated for all partitions except for {{ic|/boot}} and possibly swap.<br />
<br />
The example below will create an encrypted root partition using the AES cipher in XTS mode (generally referred to as ''XTS-AES'').<br />
{{bc|cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2}}<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 the chosen partitioning method, the {{ic|/boot}} partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<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 {{ic|/dev/<partition name>}} is actually an encrypted device and should be addressed through LUKS using the {{ic|/dev/mapper/<name>}} so as not to overwrite the encrypted data. <br />
<br />
In order to open an encrypted LUKS partition execute:<br />
{{hc|# cryptsetup luksOpen /dev/<partition name> <device-mapper name>|<br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.}}<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
::*cryptsetup luksOpen /dev/sda2 '''swap'''<br />
::::Once opened, the swap partition device address would be '''{{ic|/dev/mapper/swap}}''' instead of {{ic|/dev/sda2}}.<br />
<br />
::*cryptsetup luksOpen /dev/sda3 '''root'''<br />
::::Once opened, the root partition device address would be '''{{ic|/dev/mapper/root}}''' instead of {{ic|/dev/sda3}}.<br />
<br />
{{Note|Since {{ic|/boot}} is not encrypted, it does not need a device mapped name and will be addressed as {{ic|/dev/sda1}}.}}<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 Partitions with a Keyfile ====<br />
{{Note|This section describes using a plaintext keyfile, if you want to encrypt your keyfile giving you two factor authentication see [https://wiki.archlinux.org/index.php/System_Encryption_with_LUKS#Using_GPG_or_OpenSSL_Encrypted_Keyfiles Section 9] for details, but please still read this section.}}<br />
<br />
'''What is a Keyfile?'''<br />
<br />
A keyfile is any file in which the data contained within it 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 />
{{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 />
'''Why use a Keyfile?'''<br />
<br />
There are many kinds of keyfile. Each type of keyfile used has benefits and disadvantages summarized below:<br />
<br />
:'''keyfile.passphrase:'''<br />
::this is my passphrase I would have typed during boot but I have placed it in a file instead<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 add any security over entering a passphrase during the initial system start.<br />
<br />
:'''keyfile.randomtext:'''<br />
::fjqweifj830149-57 819y4my1- 38t1934yt8-91m 34co3;t8y;9p3y-<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 />
:'''keyfile.binary:'''<br />
::where any binary file, images, text, video could be chosen as the keyfile<br />
<br />
This is a binary file that has been defined as a keyfile. When identifying files as candidates for a keyfile, it is recommended to choose files that are relatively static such as photos, music, video clips. The benefit of these files is that they serve a dual function which can make them harder to identify as keyfiles. Instead of having a text file with a large amount of random text, the keyfile would look like a regular image file or music clip to the casual observer. The disadvantage is that if this file is lost or changed, it will most likely not be possible to access the encrypted volume without a backup passphrase. Additionally, there is a theoretical loss of randomness when compared to a randomly generated text file. This is due to the fact that images, videos and music have some intrinsic relationship between neighboring bits of data that does not exist for a text file. However this is controversial and has never been exploited publicly.<br />
<br />
'''Creating a Keyfile with Random Characters'''<br />
<br />
Here {{ic|dd}} is used to generate a keyfile of 2048 bits of random characters.<br />
<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
The usage of {{ic|dd}} is similar to initially wiping the volume with random data prior to encryption. <br />
<br />
{{Warning|Do not use [[badblocks]] here. It only generate a random pattern which just repeats its randomness over and over again.}}<br />
<br />
'''Creating a new LUKS encrypted partition with a Keyfile'''<br />
<br />
When creating a new LUKS encrypted partition, a keyfile may be associated with the partition on its creation using:<br />
<br />
# cryptsetup -c <desired cipher> -s <key size> luksFormat /dev/<volume to encrypt> '''/path/to/mykeyfile'''<br />
<br />
This is accomplished by appending the bold area to the standard cryptsetup command which defines where the keyfile is located.<br />
<br />
==== Adding Additional Passphrases or Keyfiles to a LUKS Encrypted Partition ====<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 slot 0.<br />
Additional keys will occupy slots 1&ndash;7.<br />
<br />
The addition of new keys to an encrypted partition is accomplished using cryptsetup with the {{ic|luksAddKey}} extension.<br />
<br />
# cryptsetup luksAddKey /dev/<encrypted volume> '''/path/to/mykeyfile'''<br />
<br />
Where {{ic|/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 is important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. {{ic|/dev/sdb1}} 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 {{ic|encrypt}} HOOK in the initcpio finds your keyfile, you must 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 the following:<br />
<br />
{{hc|# ls -l /dev/disk/by-label/|<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1}}<br />
<br />
or<br />
<br />
{{hc|# 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 {{ic|/dev/disk/by-label/Keys}}, or if I had wanted to use the UUID I would find {{ic|/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 ({{ic|sdb1}}, {{ic|sdb2}}, ...) but not to the USB device ({{ic|sdb}}) 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 flash drive with a [[udev]] rule. There is 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 is quickly how it goes.<br />
<br />
Get the serial number from your USB flash drive:<br />
lsusb -v | grep -A 5 Vendor<br />
<br />
Create a udev rule for it by adding the following to a file in {{ic|/etc/udev/rules.d/}}, such as {{ic|8-usbstick.rules}}:<br />
KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"<br />
<br />
Replace {{ic|$SYMLINK}} and {{ic|$SERIAL}} with their respective values. {{ic|%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 {{ic|/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. {{ic|/media/sdb1}}<br />
<br />
The keyfile can be of arbitrary content and size. We will 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 device, 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 {{ic|/etc/mkinitcpio.conf}}, one for the drive's file system and one for the codepage. Further if you created a udev rule, you should tell {{ic|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 is assumed that you use a FAT formatted USB drive. 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 />
Additionally, insert the {{ic|usb}} hook somewhere before the {{ic|encrypt}} hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
If you have a non-US keyboard, it might prove useful to load your keyboard layout before you are prompted to enter the password to unlock the root partition at boot. For this, you will need the {{ic|keymap}} hook before {{ic|encrypt}}.<br />
<br />
Generate a new image (maybe you should backup a copy of your old kernel26.img first):<br />
mkinitcpio -g /boot/initramfs-linux.img<br />
<br />
==== Storing the key as a plain (visible) file ====<br />
Be sure to choose a plain name for your key &ndash; a bit of 'security through obscurity' is always nice ;-). Avoid using dotfiles (hidden files) &ndash; the {{ic|encrypt}} hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your {{ic|/boot/grub/menu.lst}} ([[GRUB]]). It should look something like this:<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes {{ic|/dev/usbstick}} is the FAT partition of your choice. Replace it with {{ic|/dev/disk/by-...}} or whatever your device is.<br />
<br />
That is all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We will write the key directly between the Master Boot Record (MBR) and the first partition.<br />
<br />
{{Warning|You should only follow this step if you know what you are doing -- '''it can cause data loss and damage your partitions or MBR on the stick!'''}}<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 do not rely on this too much), so you would have to replace {{ic|seek<nowiki>=</nowiki>4}} with {{ic|seek<nowiki>=</nowiki>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 />
''Optional''<br />
If you do not know if you have 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 {{ic|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 {{ic|/boot/grub/menu.lst}} file (GRUB); it should look something like this:<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usb:2048:2048<br />
Format for the {{ic|cryptkey}} option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
{{ic|OFFSET}} and {{ic|SIZE}} match in this example, but this is just coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usb:8192:2048<br />
That is all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
=== Encrypting the Swap partition ===<br />
<br />
==== Without suspend-to-disk 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 />
Append a similar line to {{ic|/etc/crypttab}} to set up a randomly encrypted swap partition:<br />
<br />
<device-mapper name> <swap physical partition> SWAP "-c aes-xts-plain -h whirlpool -s 512"<br />
<br />
Where:<br />
<br />
:*{{ic|<device-mapper name>}} represents the name you want to use as label in /etc/fstab<br />
:*{{ic|<swap physical partition>}} should be the ID of the actual partition. <br> {{Warning|You should use IDs here because if there are multiple hard drives installed in the system, their naming order (sda, sdb,...) can occasionally be scrambled upon boot and thus the swap would be created over a valuable file system, destroying its content. {{ic|<nowiki>ls -l /dev/disk/*/* | grep sdl7</nowiki>}} should help you to find the desired partition.}}<br />
:*{{ic|SWAP}} identifies the partition as a swap partition<br />
:*{{ic|-c}} defines a cipher<br />
:*{{ic|-h}} defines a hash algorithm<br />
:*{{ic|-s}} defines the key size<br />
<br />
Example line (where {{ic|/dev/sdl7}} is the physical partition and {{ic|<nowiki>LABEL=swap</nowiki>}} the desired label):<br />
<br />
swap /dev/disk/by-id/scsi-SATA_Hitachi_HDS7220_JK1130YAGX0R1T-part7 SWAP "-c aes-xts-plain -h whirlpool -s 512"<br />
<br />
:Maps {{ic|/dev/sdl7}} to {{ic|/dev/mapper/swap}} as a swap partition which we can now add in {{ic|/etc/fstab}} like a normal swap.<br />
<br />
If the partition chosen for swap was previously a LUKS partition, crypttab will not overwrite the partition to create a swap partition. This is a safety measure to prevent data loss from accidental mis-identification of the swap partition in crypttab. In order to use such a partition the LUKS header must be removed. This can be accomplished with:<br />
<br />
# dd if=/dev/zero of=/dev/sdl7 bs=1M<br />
<br />
==== With suspend-to-disk support ====<br />
{{Warning|Do not use this setup with a key file. Please read about the issue reported [[Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure|here]]}}<br />
<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 pre-existent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before {{ic|/etc/crypttab}} can be used, it is required to create a hook in {{ic|/etc/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 />
* Format the partition you want to use as swap with the {{ic|cryptsetup}} command. For performance reasons, you might want to use different ciphers with different key sizes.<br />
<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check the result with:<br />
<br />
# cryptsetup luksDump /dev/<device><br />
<br />
* Open the partition in {{ic|/dev/mapper}}:<br />
<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
<br />
* Create a swap filesystem inside the mapped partition:<br />
<br />
# mkswap /dev/mapper/swapDevice<br />
<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in {{ic|/etc/crypttab}} which uses this device. Now you have to create a hook to open the swap at boot time.<br />
<br />
* Create a hook file containing the open command:<br />
<br />
{{hc|/lib/initcpio/hooks/openswap|<nowiki><br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
</nowiki>}}<br />
<br />
* Then create and edit the hook setup file:<br />
{{hc|/lib/initcpio/install/openswap|<nowiki><br />
# vim: set ft=sh:<br />
build ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
</nowiki>}}<br />
<br />
* Add the hook {{ic|openswap}} in the {{ic|HOOKS}} array in {{ic|/etc/mkinitcpio.conf}}, before {{ic|filesystem}}, but '''after''' {{ic|encrypt}} which is mandatory as well. Do not forget to add the {{ic|resume}} hook between {{ic|openswap}} and {{ic|filesystem}} as well.<br />
<br />
* Regenerate the boot image:<br />
<br />
# mkinitcpio -p linux<br />
<br />
* Add the mapped partition to {{ic|/etc/fstab}} by adding the following line:<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
<br />
* Set up your system to resume from {{ic|/dev/mapper/swapDevice}}. For example, if you use [[GRUB]] with kernel hibernation support, add {{ic|resume<nowiki>=</nowiki>/dev/mapper/swapDevice}} to the kernel line in {{ic|/boot/grub/menu.lst}}. A line with encrypted root and swap partitions can look like this:<br />
<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
<br />
At boot time, the {{ic|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 are placed '''after''' {{ic|openswap}} in the {{ic|HOOKS}} array. Please note that because of initrd opening swap, there is no entry for swapDevice in {{ic|/etc/crypttab}} needed in this case.<br />
<br />
=== Using a swap file for suspend-to-disk support ===<br />
* Choose a mapped partition (e.g. {{ic|/dev/mapper/rootDevice}}) whose mounted filesystem (e.g. {{ic|/}}) contains enough free space to hold the entire contents of your system's RAM. For example, if your system has 4 GiB RAM, then you need at least that much free space on the mounted filesystem of your chosen mapped partition for the swap file.<br />
<br />
* [[HOW_TO:_Create_swap_file#Swap_file_creation | Create the swap file]] (e.g. {{ic|/swapfile}}) inside the mounted filesystem of your chosen mapped partition. Be sure to activate it with {{ic|swapon}} and also add it to your {{ic|/etc/fstab}} file afterward.<br />
<br />
* Set up your system to resume from your chosen mapped partition. For example, if you use [[GRUB]] with kernel hibernation support, add {{ic|resume<nowiki>=</nowiki>}}''your chosen mapped partition'' and {{ic|resume_offset<nowiki>=</nowiki>}}''see calculation command below'' to the kernel line in {{ic|/boot/grub/menu.lst}}. A line with encrypted root partition can look like this:<br />
<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/rootDevice resume_offset=123456789 ro<br />
<br />
You can calculate the {{ic|resume_offset}} of your swap file like this:<br />
<br />
# filefrag -v /swapfile | awk '{if($1==0){print $3}}'<br />
<br />
* Add the {{ic|resume}} hook to your {{ic|etc/mkinitcpio.conf}} file and [[Mkinitcpio#Image_creation_and_activation|rebuild the image]] afterward:<br />
<br />
HOOKS="... encrypt '''resume''' ... filesystems ..."<br />
<br />
== Installing the system ==<br />
Now that {{ic|/dev/mapper/root}} and {{ic|/dev/mapper/home}} 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 steps and go straight to manual configuration.<br />
Instead of choosing the hardware devices ({{ic|/dev/sdaX}}) directly, you have to select the mapper devices created above.<br />
Choose {{ic|/dev/mapper/root}} for your root and {{ic|/dev/mapper/home}} as {{ic|/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 {{ic|/home}} partition. Make sure you mount {{ic|/dev/sda1}} as the {{ic|/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|The {{ic|encrypt}} hook is only needed if your root partition is a ''LUKS'' partition (or a LUKS partition that needs to be mounted ''before'' root). The {{ic|encrypt}} hook is not needed if any other partition (swap, for example) is encrypted. System initialization scripts ({{ic|/etc/rc.sysinit}} and {{ic|/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 {{ic|/etc/mkinitcpio.conf}}. For detailed information about mkinitcpio and its configuration refer to [[Mkinitcpio]]. You have to make sure that your {{ic|HOOKS}} array in {{ic|/etc/mkinitcpio.conf}} looks something like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the {{ic|encrypt}} hook comes ''before'' the {{ic|filesystems}} hook. 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 {{ic|usb}} before {{ic|encrypt}} because the hooks are run in the order they appear.<br />
If you need support for foreign keymaps for your encryption password, you have to specify the hook {{ic|keymap}} as well. I suggest putting this in {{ic|/etc/mkinitcpio.conf}} immediately before {{ic|encrypt}}.<br />
<br />
If you have a USB keyboard, you will need the {{ic|usbinput}} hook in {{ic|/etc/mkinitcpio.conf}}. Without it, no USB keyboard will work in early userspace.<br />
<br />
If your root partition is a ''LUKS'' partition, add the used filesystem to the {{ic|MODULES}} section.<br />
MODULES="... ext3 ext4 xfs ..."<br />
<br />
=== Install Bootloader ===<br />
'''[[GRUB]]:''' You have to make some small changes to the entries generated by the installer by replacing {{ic|/dev/mapper/root}} with {{ic|/dev/sda3}}. The important point to remember here is to use the same {{ic|cryptdevice}} name you assigned when you initially unlocked your device. In this example, the device name is {{ic|cryptroot}}; customize yours accordingly:<br />
<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:cryptroot root=/dev/mapper/cryptroot ro<br />
initrd /initramfs-linux.img<br />
<br />
For kernels older than 2.6.37, the syntax is:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' Edit the Arch Linux section in {{ic|/etc/lilo.conf}} and include a line for the {{ic|append}} option, over the initrd, with the {{ic|root<nowiki>=</nowiki>/dev/sda3}} parameter. The {{ic|append}} section makes the same kernel line as in GRUB. Also, you can omit the {{ic|root}} option above the {{ic|image}} option. The section looks like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz-linux<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /initramfs-linux.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note|If you want to use a USB flash drive with a keyfile, you have to append the {{ic|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 {{ic|/etc/crypttab}} file so you do not have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. {{ic|/home}}, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
<br />
Add the following line for the {{ic|/home}} partition<br />
{{Note|Using a passphrase to decrypt LUKS partitions automatically from {{ic|/etc/crypttab}} is deprecated: see http://www.mail-archive.com/arch-projects@archlinux.org/msg02115.html}}<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 [[#Adding_Additional_Passphrases_or_Keyfiles_to_a_LUKS_Encrypted_Partition|above]].<br />
Then add the following information to the {{ic|/etc/crypttab}} file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
If you used a USB device to store your keyfile, you should have something like this:<br />
home /dev/sda5 /dev/sd*1/keyfile<br />
<br />
Or if the keyfile was stored in the MBR, it should be like this:<br />
home /dev/sda5 /dev/sd*:2048:2048<br />
<br />
{{Box BLUE|Note:|When reading the keyfile from the MBR it should be {{ic|/dev/sdb}} not {{ic|/dev/sdb1}} but if the key is in the filesystem it should still be {{ic|/dev/sdb1}}.}}<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 a LUKS password. Type it in and everything should boot.<br />
Once you have logged in, have a look at your mounted partitions by typing {{ic|mount}}. You should have {{ic|/dev/mapper/root}} mounted at {{ic|/}} and, if you set up a separate encrypted home partition, {{ic|/dev/mapper/home}} mounted at {{ic|/home}}. If you set up encrypted swap, {{ic|swapon -s}} should have {{ic|/dev/mapper/swap}} 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 is not, simply enter your password and press {{keypress|Enter}}.}}<br />
<br />
== Remote unlocking of the root (or other) 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 achieved by running the {{ic|net}} hook along with an [[SSH]] server in initrd. Install the {{AUR|dropbear_initrd_encrypt}} package from the [[Arch User Repository|AUR]] and follow the post-installation instructions. Replace the {{ic|encrypt}} hook with {{ic|dropbear encryptssh}} in {{ic|/etc/mkinitcpio.conf}}. Put the {{ic|net}} hook early in the HOOKS array if your DHCP server takes a long time to lease IP addresses.<br />
<br />
If you would simply like a nice solution to mount other encrypted partitions (such as {{ic|/home}})remotely, you may want to look at [https://bbs.archlinux.org/viewtopic.php?pid=880484 this forum thread].<br />
<br />
{{Note|Acutally trim will not work with this script because it is not yet updated to the latest encrypt hook, so it is not able to parse {{ic|-–allow-discards}} from {{ic|/boot/grub/menu.lst}}. (Version: dropbear_initrd_encrypt 0.8-16). You won't notice any error when using online discard, but you see an error when you try to use {{ic|fstrim}}.For a temporary solution just add {{ic|-–allow-discards}} to every cryptsetup line of {{ic|/lib/initcpio/install/dropbear}}(1 line) and {{ic|/lib/initcpio/hooks/encryptssh}}(3 lines)}}<br />
<br />
== Backup the cryptheader ==<br />
If the header of your encrypted partition gets destroyed, you will not be able to decrypt your data. Therefore, having a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT backing up the cryptheader, but even so it's a single point of failure!<br />
In short, the problem is that LUKS is not aware of the duplicated cryptheader, which contains the master key which is used to encrypt all files on your partition. Of course this master key 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 master key 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]{{Linkrot|2011|09|05}} for further details on this.<br />
<br />
{{Note|You can also back up 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 />
=== Backup ===<br />
==== Manually ====<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 />
==== Using cryptsetup ====<br />
You can also use the luksHeaderBackup command instead:<br />
cryptsetup luksHeaderBackup /dev/sdaX --header-backup-file ./backup.img<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 />
==== Manually ====<br />
Again, you will need to the same values as when backing up:<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
==== Using cryptsetup ====<br />
Or you can use the luksHeaderRestore command:<br />
cryptsetup luksHeaderRestore /dev/sdaX --header-backup-file ./backup.img<br />
<br />
'''Note:''' All the keyslot areas are overwritten; only active keyslots from the backup file are available after issuing this command.<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 />
First, start by creating an encrypted container!<br />
<br />
dd if=/dev/urandom of=/bigsecret bs=1M count=10<br />
<br />
This will create the file {{ic|bigsecret}} with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node {{ic|/dev/loop0}}, so that we can mount/use our container.<br />
<br />
{{Note|If it gives you the error {{ic|/dev/loop0: No such file or directory}}, you need to first load the kernel module with {{ic|modprobe loop}}. These days (Kernel 3.2) loop devices are created on demand. Ask for a new loop device with {{ic|losetup -f}}.}}<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file.<br />
<br />
{{Note|If you get an error like {{ic|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 {{ic|modprobe dm-mod}}.}}<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the device file {{ic|/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 />
=== Encrypt using a key-file ===<br />
Let us 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 {{ic|/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 encrypting your keyfile using your private GPG key and storing an off-site 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 expand our container file with the size of the data we want to add:<br />
<br />
dd if=/dev/urandom bs=1M count=1024 | cat - >> /bigsecret<br />
<br />
Be careful to really use TWO {{ic|>}}, or you will override your current container!<br />
<br />
You could use {{ic|/dev/zero}} instead of {{ic|/dev/urandom}} to significantly speed up the process, but with {{ic|/dev/zero}} your encrypted filesystems will ''not be as secure''. (A better option to create random data quicker than {{ic|/dev/urandom}} is {{ic|frandom}} [https://aur.archlinux.org/packages.php?ID=9869], available from the [[AUR]]).<br />
<br />
Now we have to map the container to the loop device:<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 do not 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 the {{ic|encrypt}} hook '''before''' the {{ic|lvm2}} hook (and those two before the {{ic|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 set up your LVM volumes and then use them as the base for the encrypted partitions. That means, in short, that you have to set up LVM first. Then follow this guide, but replace all occurrences of {{ic|/dev/sdXy}} in the guide with its LVM counterpart. (E.g.: {{ic|/dev/sda5}} -> {{ic|/dev/<volume group name>/home}}).<br />
<br />
Do not forget to add the {{ic|encrypt}} hook in {{ic|/etc/mkinitcpio.conf}} '''before''' the {{ic|lvm2}} hook, if you chose to set up encrypted partitions on '''top''' of LVM. Also remember to change {{ic|USELVM}} in {{ic|/etc/rc.conf}} to {{ic|"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 partition 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 {{ic|/etc/rc.conf}} set {{ic|USELVM}} to {{ic|"yes"}}<br />
* In {{ic|/etc/mkinitcpio.conf}} add the {{ic|encrypt}} hook '''before''' the {{ic|lvm2}} hook in the {{ic|HOOKS}} array, if you set up LVM on top of the encrypted partition.<br />
<br />
That is 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 {{ic|/lib/initcpio/hooks/encrypt}} (the first one to your {{ic|/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 {{ic|/etc/crypttab}} with an external key file (i.e. the keyfile is not on any internal hard drive 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 the order of {{ic|/etc/fstab}} (at least).<br />
<br />
Of course, if the {{Pkg|cryptsetup}} package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking {{ic|/etc/rc.sysinit}} or similar files. Unlike {{ic|/etc/crypttab}}, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
If you want to do this on a software RAID partition, there is one more thing you need to do. Just setting the {{ic|/dev/mdX}} device in {{ic|/lib/initcpio/hooks/encrypt}} is not enough; the {{ic|encrypt}} hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices are not brought up until after the {{ic|encrypt}} hook is run. You can solve this by putting the RAID array in {{ic|/boot/grub/menu.lst}}, like <br />
kernel /boot/vmlinuz-linux md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID, you will notice the similarities with that setup ;-). [[GRUB]] can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz-linux root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM and dm-crypt manually (short version) ===<br />
<br />
==== Notes ====<br />
If you are smart enough for this, you will be smart enough to ignore/replace LVM-specific things if you do not want to use LVM.<br />
<br />
{{Note|This brief uses reiserfs for some of the partitions, so change this accordingly if you want to use a more "normal" file system, like ext4.}}<br />
<br />
==== Partitioning scheme ====<br />
{{ic|/dev/sda1}} -> {{ic|/boot}}<br />
{{ic|/dev/sda2}} -> LVM<br />
<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 />
<br />
==== Install Arch Linux ====<br />
Run {{ic|/arch/setup}}<br />
<br />
==== Configuration ====<br />
<br />
===== /etc/rc.conf =====<br />
Change {{ic|USELVM<nowiki>=</nowiki>"no"}} to {{ic|USELVM<nowiki>=</nowiki>"yes"}}.<br />
<br />
===== /etc/mkinitcpio.conf =====<br />
Put {{ic|lvm2}} and {{ic|encrypt}} (in that order) before {{ic|filesystems}} in the {{ic|HOOKS}} array. Again, note that you are setting encryption on '''top''' of LVM.)<br />
<br />
if you want install the system on a usb stick, you need to put {{ic|usb}} just after {{ic|udev}}.<br />
<br />
===== /boot/grub/menu.lst =====<br />
Change {{ic|root<nowiki>=</nowiki>/dev/hda3}} to {{ic|root<nowiki>=</nowiki>/dev/lvm/root}}.<br />
<br />
For kernel >= 2.6.30, you should change {{ic|root<nowiki>=</nowiki>/dev/hda3}} to the following:<br />
cryptdevice=/dev/lvm/root:root root=/dev/mapper/root<br />
<br />
if you want install the system on a usb stick, you need to add {{ic|lvmdelay<nowiki>=</nowiki>/dev/mapper/lvm-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 rebooting ====<br />
<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 />
<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on LVM on LUKS ===<br />
Make sure your kernel command line 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 />
==Using GPG or OpenSSL Encrypted Keyfiles==<br />
The following forum posts give instructions to use two factor authentication, gpg or openssl encrypted keyfiles [https://bbs.archlinux.org/viewtopic.php?id=120243 System Encryption using LUKS with GPG encrypted keys]:<br />
* GnuPG: [https://bbs.archlinux.org/viewtopic.php?pid=943338#p943338 Post regarding GPG encrypted keys]<br />
* OpenSSL: [https://bbs.archlinux.org/viewtopic.php?pid=947805#p947805 Post regarding OpenSSL encrypted keys]<br />
<br />
Note that:<br />
* If you want to use a GPG encrypted keyfile, you need to use a statically compiled GnuPG version 1.4 or you could edit the hooks and use this AUR package [https://aur.archlinux.org/packages.php?ID=58030 gnupg1]<br />
* It is possible that an update to OpenSSL could break the custom {{ic|ssldec}} mentioned in the second forum post.<br />
<br />
==Securing the unencrypted boot partition==<br />
Referring to an article from the ct-magazine (Issue 3/12, page 146, 01.16.2012 http://www.heise.de/ct/inhalt/2012/03/6/) the following script checks all files under {{ic|/boot}} for changes of SHA-1 hash, inode and occupied blocks on the hard drive. It also checks the MBR.<br />
<br />
The script with installation instructions is available here: ftp://ftp.heise.de/pub/ct/listings/1203-146.zip (Author: Juergen Schmidt, ju at heisec.de; License: GPLv2)<br />
<br />
There is also an AUR package: {{AUR|chkboot}}<br />
<br />
After installation, add {{ic|/usr/local/bin/chkboot.sh &}} to your {{ic|/etc/rc.local}}.<br />
<br />
And as {{ic|/usr/local/bin/chkboot_user.sh}} need to be excuted after login, add it to the autostarts (e.g. under KDE -> System Settings -> Startup and Shutdown -> Autostart)<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Install Arch Linux on top of RAID, LVM2, and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Airbus001https://wiki.archlinux.org/index.php?title=Dm-crypt&diff=209410Dm-crypt2012-06-15T22:33:42Z<p>Airbus001: /* Using LUKS to Format Partitions with a Keyfile */</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[ru:System Encryption with LUKS]]<br />
[[zh-CN:System Encryption with LUKS]]<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 />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
==== Data encryption ====<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
*Preventing unauthorized physical access to private data.<br />
*Some confidence in data disposal when discarding obsolete systems.<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 />
==== System encryption ====<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 />
*Preventing unauthorized physical access to operating system files<br />
*Preventing unauthorized physical access to private data that may cached by the system.<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 />
*Attempts to bypass the operating system by inserting a boot CD/USB<br />
*Copying, modifying, or removing the hard disk drives when the computer is off<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the {{ic|/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 />
{{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 Available for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption, including:<br />
<br />
;loop-AES ([http://loop-aes.sourceforge.net/ loop-AES]):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 />
;standard device-mapper encryption ([http://www.saout.de/misc/dm-crypt/ dm-crypt]):This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
;LUKS for dm-crypt ([http://code.google.com/p/cryptsetup/ LUKS]):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 />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key (see [[Wikipedia:Kerckhoffs's principle]])<br />
::*The usage of a proven encryption algorithm<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 />
====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 />
====discard/TRIM support for solid state disks====<br />
<br />
Solid state disk users should be aware that by default, Linux's full-disk encryption mechanisms will ''not'' forward TRIM commands from the filesystem to the underlying disk. The device-mapper maintainers have made it clear that TRIM support will never be enabled by default on dm-crypt devices because of the potential security implications; if TRIM support were enabled, an attacker may be able to tell which blocks have been used, how many blocks have been used, and other information that is exposed directly to the device when a TRIM is issued.<br />
<br />
It may be possible to determine the filesystem utilized by your encrypted device through the data that is leaked by TRIM. Furthermore, any information that may be derived by a profile of block usage may be exposed by enabling TRIM support on an encrypted device.<br />
<br />
As of {{Pkg|linux}} version 3.1, support for dm-crypt TRIM pass-through can be toggled upon device creation or mount with dmsetup. Support for this option also exists in {{Pkg|cryptsetup}} version 1.4.0 and up. To add support during boot, you will need to add "{{ic|:allow-discards}}" to the {{ic|cryptdevice}} option. The option should look like this:<br />
cryptdevice=/dev/mapper/root:root:allow-discards<br />
<br />
For more information, including specific commands and details on dm-crypt TRIM pass-through, see these mailing list threads:<br />
* http://article.gmane.org/gmane.linux.kernel.device-mapper.devel/14134<br />
* http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/5166<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 shut down. 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 to extract your encryption key - thus obtaining access to your data.<br />
<br />
{{Note|System Encryption assumes encryption of all mounted partitions: this includes all partitions except for {{ic|/boot}} - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, {{ic|/tmp}}, or root filesystems are unencrypted, only Data Encryption level of security has been accomplished.}}<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 />
=====Encryption of data partitions on the same physical disk as the system=====<br />
<br />
The most common form of data encryption is encrypting the {{ic|/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 decreased by orders of magnitude when compared to system encryption. The reason for this is 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, {{Pkg|mlocate}} will scan all currently mounted file systems regularly and write the list of filenames to {{ic|/var/lib/mlocate/mlocate.db}}, which is located in the non-encrypted root or {{ic|/var}} partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted {{ic|/home}} partition, readily available to assist them in accessing the encrypted data present on 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|System Encryption with eCryptfs]].<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 Hard Disk Drives or Separate Internal Hard Disk Drives<br />
::*CD/DVD/Blu-Ray Optical Media<br />
::*Magnetic Storage Media<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 set up.<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the hard disk 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 Hard Disk Drive ===<br />
<br />
Secure erasure of the hard disk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a hard disk 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 />
====Why perform secure erasure of a drive?====<br />
<br />
There are two types of hard disk 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 Hard Disk Drives'''<br />
<br />
::In hard drives 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 Hard Disk Drives'''<br />
<br />
::Repartitioning or reformatting a used hard drive 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 straightforward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore hard drives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
====Overwriting a hard disk drive with random data====<br />
<br />
There are two sources of random data commonly used for securely overwriting hard disk partitions.<br />
<br />
::*{{ic|/dev/urandom}}<br />
::*badblocks<br />
<br />
=====Using urandom=====<br />
<br />
#dd if=/dev/urandom of=/dev/<drive> bs=1M<br />
<br />
Where {{ic|/dev/<drive>}} is the drive to be encrypted.<br />
<br />
{{Note| Using {{ic|/dev/urandom}} will take a long time to completely overwrite a drive with "random" data. In the strictest sense, {{ic|/dev/urandom}} is less random than {{ic|/dev/random}}; however, {{ic|/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 {{ic|/dev/random}} for overwriting hard disks impractical.}}<br />
<br />
{{Note| Users may also find that {{ic|/dev/urandom}} takes an excessively long time on large drives of several hundred gigabytes or more (more than twenty-four hours). [[Frandom]] offers a faster alternative.}}<br />
<br />
{{Note|You can retrieve progress of the dd command with this command: {{ic|kill -USR1 $(pidof dd)}}}}<br />
<br />
=====Using badblocks=====<br />
<br />
#badblocks -c 10240 -wsvt random /dev/<drive><br />
<br />
Where {{ic|/dev/<drive>}} is the drive to be encrypted.<br />
<br />
{{Note|The {{ic|badblocks}} command overwrites the drive at a much faster rate by generating data that is not truly random.}}<br />
<br />
See also [[badblocks]].<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a hard disk 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 />
=====After installation=====<br />
Essentially the same effect can be achieved if a file is created on each of the partitions that fills the partition completely '''after''' the system is installed and booted with encrypted partitions mounted. <br />
#dd if=/dev/zero of=/path/to/the/output/file<br />
#rm /path/to/the/input/file<br />
Just make sure that you do that for every partition on the filesystem. This works as encrypted data is indistinguishabe from random, so anone trying to access potential leftover files will just see random data.<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 with systems that require 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 three flavors: primary partitions, extended partitions, and logical partitions.<br />
<br />
;Primary Partitions: These are the normal partitions recognized by the system BIOS. There can be up to four of these stored in the MBR.<br />
<br />
;Extended Partitions: These are primary partitions that also define another partition within themselves. Extended partitions were created to work around the original limit of four primary partitions.<br />
<br />
;Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
====LVM: Logical Volume Manager====<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple hard disk drives and partitions that are not possible with standard partitions. LVM is covered in detail in the [[LVM|Arch Linux LVM Wiki Article]] which is recommended reading prior to continuing with the instructions on setting up LUKS with LVM located below.<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 is that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In this case, logical volume management would be layered on top of the hardware encryption &ndash; usage of LUKS would be superfluous.<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 two required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*{{ic|'''/'''}}<br />
:::*Will be encrypted and store all system and user files ({{ic|/usr}}, {{ic|/bin}}, {{ic|/var}}, {{ic|/home}}, etc.)<br />
<br />
::An initial boot partition<br />
<br />
:::*{{ic|'''/boot'''}}<br />
:::*Will ''not'' be encrypted; the bootloader needs to access the {{ic|/boot}} directory where it will load the initramfs/encryption modules needed to load the rest of the system which ''is'' encrypted (see [[Mkinitcpio]] for details). For this reason, {{ic|/boot}} needs to reside on its own, unencrypted partition.<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 />
=====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 used, the space unoccupied by {{ic|/boot}} and swap should be defined as single large partition which will be divided up later at the LVM level.<br />
<br />
=====Multiple Disk Systems=====<br />
<br />
In systems that will have multiple hard disk drives, the same options exist as a single disk system. After the creation of the {{ic|/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 {{ic|/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 the dialogue for manual configuration of the hard drive.<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 per LUKS partition.<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
{{Note|Using a passphrase to decrypt LUKS partitions automatically from {{ic|/etc/crypttab}} is deprecated: see http://www.mail-archive.com/arch-projects@archlinux.org/msg02115.html}}<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
A full list of options {{ic|cryptsetup}} accepts can be found in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::*{{ic|-c}} defines the cipher type<br />
::*{{ic|-y}} prompts for password confirmation on password creation<br />
::*{{ic|-s}} defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
In the following examples for creating LUKS partitions, we will use the AES cipher in XTS mode; at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup, and details about them can be found here: [[Wikipedia:Block_cipher]]<br />
<br />
'''Formatting LUKS Partitions'''<br />
<br />
First of all make sure the device mapper kernel module is loaded by executing the following: {{ic|# modprobe dm_mod}}<br />
<br />
In order to format a desired partition as an encrypted LUKS partition execute:<br />
{{hc|# cryptsetup -c <cipher> -y -s <key size> luksFormat /dev/<partition name>|<br />
Enter passphrase: <password><br />
Verify passphrase: <password>}}<br />
<br />
This should be repeated for all partitions except for {{ic|/boot}} and possibly swap.<br />
<br />
The example below will create an encrypted root partition using the AES cipher in XTS mode (generally referred to as ''XTS-AES'').<br />
{{bc|cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2}}<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 the chosen partitioning method, the {{ic|/boot}} partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<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 {{ic|/dev/<partition name>}} is actually an encrypted device and should be addressed through LUKS using the {{ic|/dev/mapper/<name>}} so as not to overwrite the encrypted data. <br />
<br />
In order to open an encrypted LUKS partition execute:<br />
{{hc|# cryptsetup luksOpen /dev/<partition name> <device-mapper name>|<br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.}}<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
::*cryptsetup luksOpen /dev/sda2 '''swap'''<br />
::::Once opened, the swap partition device address would be '''{{ic|/dev/mapper/swap}}''' instead of {{ic|/dev/sda2}}.<br />
<br />
::*cryptsetup luksOpen /dev/sda3 '''root'''<br />
::::Once opened, the root partition device address would be '''{{ic|/dev/mapper/root}}''' instead of {{ic|/dev/sda3}}.<br />
<br />
{{Note|Since {{ic|/boot}} is not encrypted, it does not need a device mapped name and will be addressed as {{ic|/dev/sda1}}.}}<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 Partitions with a Keyfile ====<br />
{{Note|This section describes using a plaintext keyfile, if you want to encrypt your keyfile giving you two factor authentication see [https://wiki.archlinux.org/index.php/System_Encryption_with_LUKS#Using_GPG_or_OpenSSL_Encrypted_Keyfiles Section 9].}}<br />
<br />
'''What is a Keyfile?'''<br />
<br />
A keyfile is any file in which the data contained within it 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 />
{{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 />
'''Why use a Keyfile?'''<br />
<br />
There are many kinds of keyfile. Each type of keyfile used has benefits and disadvantages summarized below:<br />
<br />
:'''keyfile.passphrase:'''<br />
::this is my passphrase I would have typed during boot but I have placed it in a file instead<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 add any security over entering a passphrase during the initial system start.<br />
<br />
:'''keyfile.randomtext:'''<br />
::fjqweifj830149-57 819y4my1- 38t1934yt8-91m 34co3;t8y;9p3y-<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 />
:'''keyfile.binary:'''<br />
::where any binary file, images, text, video could be chosen as the keyfile<br />
<br />
This is a binary file that has been defined as a keyfile. When identifying files as candidates for a keyfile, it is recommended to choose files that are relatively static such as photos, music, video clips. The benefit of these files is that they serve a dual function which can make them harder to identify as keyfiles. Instead of having a text file with a large amount of random text, the keyfile would look like a regular image file or music clip to the casual observer. The disadvantage is that if this file is lost or changed, it will most likely not be possible to access the encrypted volume without a backup passphrase. Additionally, there is a theoretical loss of randomness when compared to a randomly generated text file. This is due to the fact that images, videos and music have some intrinsic relationship between neighboring bits of data that does not exist for a text file. However this is controversial and has never been exploited publicly.<br />
<br />
'''Creating a Keyfile with Random Characters'''<br />
<br />
Here {{ic|dd}} is used to generate a keyfile of 2048 bits of random characters.<br />
<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
The usage of {{ic|dd}} is similar to initially wiping the volume with random data prior to encryption. <br />
<br />
{{Warning|Do not use [[badblocks]] here. It only generate a random pattern which just repeats its randomness over and over again.}}<br />
<br />
'''Creating a new LUKS encrypted partition with a Keyfile'''<br />
<br />
When creating a new LUKS encrypted partition, a keyfile may be associated with the partition on its creation using:<br />
<br />
# cryptsetup -c <desired cipher> -s <key size> luksFormat /dev/<volume to encrypt> '''/path/to/mykeyfile'''<br />
<br />
This is accomplished by appending the bold area to the standard cryptsetup command which defines where the keyfile is located.<br />
<br />
==== Adding Additional Passphrases or Keyfiles to a LUKS Encrypted Partition ====<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 slot 0.<br />
Additional keys will occupy slots 1&ndash;7.<br />
<br />
The addition of new keys to an encrypted partition is accomplished using cryptsetup with the {{ic|luksAddKey}} extension.<br />
<br />
# cryptsetup luksAddKey /dev/<encrypted volume> '''/path/to/mykeyfile'''<br />
<br />
Where {{ic|/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 is important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. {{ic|/dev/sdb1}} 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 {{ic|encrypt}} HOOK in the initcpio finds your keyfile, you must 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 the following:<br />
<br />
{{hc|# ls -l /dev/disk/by-label/|<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1}}<br />
<br />
or<br />
<br />
{{hc|# 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 {{ic|/dev/disk/by-label/Keys}}, or if I had wanted to use the UUID I would find {{ic|/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 ({{ic|sdb1}}, {{ic|sdb2}}, ...) but not to the USB device ({{ic|sdb}}) 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 flash drive with a [[udev]] rule. There is 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 is quickly how it goes.<br />
<br />
Get the serial number from your USB flash drive:<br />
lsusb -v | grep -A 5 Vendor<br />
<br />
Create a udev rule for it by adding the following to a file in {{ic|/etc/udev/rules.d/}}, such as {{ic|8-usbstick.rules}}:<br />
KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"<br />
<br />
Replace {{ic|$SYMLINK}} and {{ic|$SERIAL}} with their respective values. {{ic|%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 {{ic|/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. {{ic|/media/sdb1}}<br />
<br />
The keyfile can be of arbitrary content and size. We will 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 device, 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 {{ic|/etc/mkinitcpio.conf}}, one for the drive's file system and one for the codepage. Further if you created a udev rule, you should tell {{ic|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 is assumed that you use a FAT formatted USB drive. 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 />
Additionally, insert the {{ic|usb}} hook somewhere before the {{ic|encrypt}} hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
If you have a non-US keyboard, it might prove useful to load your keyboard layout before you are prompted to enter the password to unlock the root partition at boot. For this, you will need the {{ic|keymap}} hook before {{ic|encrypt}}.<br />
<br />
Generate a new image (maybe you should backup a copy of your old kernel26.img first):<br />
mkinitcpio -g /boot/initramfs-linux.img<br />
<br />
==== Storing the key as a plain (visible) file ====<br />
Be sure to choose a plain name for your key &ndash; a bit of 'security through obscurity' is always nice ;-). Avoid using dotfiles (hidden files) &ndash; the {{ic|encrypt}} hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your {{ic|/boot/grub/menu.lst}} ([[GRUB]]). It should look something like this:<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes {{ic|/dev/usbstick}} is the FAT partition of your choice. Replace it with {{ic|/dev/disk/by-...}} or whatever your device is.<br />
<br />
That is all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We will write the key directly between the Master Boot Record (MBR) and the first partition.<br />
<br />
{{Warning|You should only follow this step if you know what you are doing -- '''it can cause data loss and damage your partitions or MBR on the stick!'''}}<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 do not rely on this too much), so you would have to replace {{ic|seek<nowiki>=</nowiki>4}} with {{ic|seek<nowiki>=</nowiki>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 />
''Optional''<br />
If you do not know if you have 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 {{ic|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 {{ic|/boot/grub/menu.lst}} file (GRUB); it should look something like this:<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usb:2048:2048<br />
Format for the {{ic|cryptkey}} option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
{{ic|OFFSET}} and {{ic|SIZE}} match in this example, but this is just coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usb:8192:2048<br />
That is all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
=== Encrypting the Swap partition ===<br />
<br />
==== Without suspend-to-disk 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 />
Append a similar line to {{ic|/etc/crypttab}} to set up a randomly encrypted swap partition:<br />
<br />
<device-mapper name> <swap physical partition> SWAP "-c aes-xts-plain -h whirlpool -s 512"<br />
<br />
Where:<br />
<br />
:*{{ic|<device-mapper name>}} represents the name you want to use as label in /etc/fstab<br />
:*{{ic|<swap physical partition>}} should be the ID of the actual partition. <br> {{Warning|You should use IDs here because if there are multiple hard drives installed in the system, their naming order (sda, sdb,...) can occasionally be scrambled upon boot and thus the swap would be created over a valuable file system, destroying its content. {{ic|<nowiki>ls -l /dev/disk/*/* | grep sdl7</nowiki>}} should help you to find the desired partition.}}<br />
:*{{ic|SWAP}} identifies the partition as a swap partition<br />
:*{{ic|-c}} defines a cipher<br />
:*{{ic|-h}} defines a hash algorithm<br />
:*{{ic|-s}} defines the key size<br />
<br />
Example line (where {{ic|/dev/sdl7}} is the physical partition and {{ic|<nowiki>LABEL=swap</nowiki>}} the desired label):<br />
<br />
swap /dev/disk/by-id/scsi-SATA_Hitachi_HDS7220_JK1130YAGX0R1T-part7 SWAP "-c aes-xts-plain -h whirlpool -s 512"<br />
<br />
:Maps {{ic|/dev/sdl7}} to {{ic|/dev/mapper/swap}} as a swap partition which we can now add in {{ic|/etc/fstab}} like a normal swap.<br />
<br />
If the partition chosen for swap was previously a LUKS partition, crypttab will not overwrite the partition to create a swap partition. This is a safety measure to prevent data loss from accidental mis-identification of the swap partition in crypttab. In order to use such a partition the LUKS header must be removed. This can be accomplished with:<br />
<br />
# dd if=/dev/zero of=/dev/sdl7 bs=1M<br />
<br />
==== With suspend-to-disk support ====<br />
{{Warning|Do not use this setup with a key file. Please read about the issue reported [[Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure|here]]}}<br />
<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 pre-existent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before {{ic|/etc/crypttab}} can be used, it is required to create a hook in {{ic|/etc/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 />
* Format the partition you want to use as swap with the {{ic|cryptsetup}} command. For performance reasons, you might want to use different ciphers with different key sizes.<br />
<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check the result with:<br />
<br />
# cryptsetup luksDump /dev/<device><br />
<br />
* Open the partition in {{ic|/dev/mapper}}:<br />
<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
<br />
* Create a swap filesystem inside the mapped partition:<br />
<br />
# mkswap /dev/mapper/swapDevice<br />
<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in {{ic|/etc/crypttab}} which uses this device. Now you have to create a hook to open the swap at boot time.<br />
<br />
* Create a hook file containing the open command:<br />
<br />
{{hc|/lib/initcpio/hooks/openswap|<nowiki><br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
</nowiki>}}<br />
<br />
* Then create and edit the hook setup file:<br />
{{hc|/lib/initcpio/install/openswap|<nowiki><br />
# vim: set ft=sh:<br />
build ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
</nowiki>}}<br />
<br />
* Add the hook {{ic|openswap}} in the {{ic|HOOKS}} array in {{ic|/etc/mkinitcpio.conf}}, before {{ic|filesystem}}, but '''after''' {{ic|encrypt}} which is mandatory as well. Do not forget to add the {{ic|resume}} hook between {{ic|openswap}} and {{ic|filesystem}} as well.<br />
<br />
* Regenerate the boot image:<br />
<br />
# mkinitcpio -p linux<br />
<br />
* Add the mapped partition to {{ic|/etc/fstab}} by adding the following line:<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
<br />
* Set up your system to resume from {{ic|/dev/mapper/swapDevice}}. For example, if you use [[GRUB]] with kernel hibernation support, add {{ic|resume<nowiki>=</nowiki>/dev/mapper/swapDevice}} to the kernel line in {{ic|/boot/grub/menu.lst}}. A line with encrypted root and swap partitions can look like this:<br />
<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
<br />
At boot time, the {{ic|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 are placed '''after''' {{ic|openswap}} in the {{ic|HOOKS}} array. Please note that because of initrd opening swap, there is no entry for swapDevice in {{ic|/etc/crypttab}} needed in this case.<br />
<br />
=== Using a swap file for suspend-to-disk support ===<br />
* Choose a mapped partition (e.g. {{ic|/dev/mapper/rootDevice}}) whose mounted filesystem (e.g. {{ic|/}}) contains enough free space to hold the entire contents of your system's RAM. For example, if your system has 4 GiB RAM, then you need at least that much free space on the mounted filesystem of your chosen mapped partition for the swap file.<br />
<br />
* [[HOW_TO:_Create_swap_file#Swap_file_creation | Create the swap file]] (e.g. {{ic|/swapfile}}) inside the mounted filesystem of your chosen mapped partition. Be sure to activate it with {{ic|swapon}} and also add it to your {{ic|/etc/fstab}} file afterward.<br />
<br />
* Set up your system to resume from your chosen mapped partition. For example, if you use [[GRUB]] with kernel hibernation support, add {{ic|resume<nowiki>=</nowiki>}}''your chosen mapped partition'' and {{ic|resume_offset<nowiki>=</nowiki>}}''see calculation command below'' to the kernel line in {{ic|/boot/grub/menu.lst}}. A line with encrypted root partition can look like this:<br />
<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/rootDevice resume_offset=123456789 ro<br />
<br />
You can calculate the {{ic|resume_offset}} of your swap file like this:<br />
<br />
# filefrag -v /swapfile | awk '{if($1==0){print $3}}'<br />
<br />
* Add the {{ic|resume}} hook to your {{ic|etc/mkinitcpio.conf}} file and [[Mkinitcpio#Image_creation_and_activation|rebuild the image]] afterward:<br />
<br />
HOOKS="... encrypt '''resume''' ... filesystems ..."<br />
<br />
== Installing the system ==<br />
Now that {{ic|/dev/mapper/root}} and {{ic|/dev/mapper/home}} 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 steps and go straight to manual configuration.<br />
Instead of choosing the hardware devices ({{ic|/dev/sdaX}}) directly, you have to select the mapper devices created above.<br />
Choose {{ic|/dev/mapper/root}} for your root and {{ic|/dev/mapper/home}} as {{ic|/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 {{ic|/home}} partition. Make sure you mount {{ic|/dev/sda1}} as the {{ic|/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|The {{ic|encrypt}} hook is only needed if your root partition is a ''LUKS'' partition (or a LUKS partition that needs to be mounted ''before'' root). The {{ic|encrypt}} hook is not needed if any other partition (swap, for example) is encrypted. System initialization scripts ({{ic|/etc/rc.sysinit}} and {{ic|/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 {{ic|/etc/mkinitcpio.conf}}. For detailed information about mkinitcpio and its configuration refer to [[Mkinitcpio]]. You have to make sure that your {{ic|HOOKS}} array in {{ic|/etc/mkinitcpio.conf}} looks something like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the {{ic|encrypt}} hook comes ''before'' the {{ic|filesystems}} hook. 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 {{ic|usb}} before {{ic|encrypt}} because the hooks are run in the order they appear.<br />
If you need support for foreign keymaps for your encryption password, you have to specify the hook {{ic|keymap}} as well. I suggest putting this in {{ic|/etc/mkinitcpio.conf}} immediately before {{ic|encrypt}}.<br />
<br />
If you have a USB keyboard, you will need the {{ic|usbinput}} hook in {{ic|/etc/mkinitcpio.conf}}. Without it, no USB keyboard will work in early userspace.<br />
<br />
If your root partition is a ''LUKS'' partition, add the used filesystem to the {{ic|MODULES}} section.<br />
MODULES="... ext3 ext4 xfs ..."<br />
<br />
=== Install Bootloader ===<br />
'''[[GRUB]]:''' You have to make some small changes to the entries generated by the installer by replacing {{ic|/dev/mapper/root}} with {{ic|/dev/sda3}}. The important point to remember here is to use the same {{ic|cryptdevice}} name you assigned when you initially unlocked your device. In this example, the device name is {{ic|cryptroot}}; customize yours accordingly:<br />
<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:cryptroot root=/dev/mapper/cryptroot ro<br />
initrd /initramfs-linux.img<br />
<br />
For kernels older than 2.6.37, the syntax is:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' Edit the Arch Linux section in {{ic|/etc/lilo.conf}} and include a line for the {{ic|append}} option, over the initrd, with the {{ic|root<nowiki>=</nowiki>/dev/sda3}} parameter. The {{ic|append}} section makes the same kernel line as in GRUB. Also, you can omit the {{ic|root}} option above the {{ic|image}} option. The section looks like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz-linux<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /initramfs-linux.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note|If you want to use a USB flash drive with a keyfile, you have to append the {{ic|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 {{ic|/etc/crypttab}} file so you do not have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. {{ic|/home}}, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
<br />
Add the following line for the {{ic|/home}} partition<br />
{{Note|Using a passphrase to decrypt LUKS partitions automatically from {{ic|/etc/crypttab}} is deprecated: see http://www.mail-archive.com/arch-projects@archlinux.org/msg02115.html}}<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 [[#Adding_Additional_Passphrases_or_Keyfiles_to_a_LUKS_Encrypted_Partition|above]].<br />
Then add the following information to the {{ic|/etc/crypttab}} file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
If you used a USB device to store your keyfile, you should have something like this:<br />
home /dev/sda5 /dev/sd*1/keyfile<br />
<br />
Or if the keyfile was stored in the MBR, it should be like this:<br />
home /dev/sda5 /dev/sd*:2048:2048<br />
<br />
{{Box BLUE|Note:|When reading the keyfile from the MBR it should be {{ic|/dev/sdb}} not {{ic|/dev/sdb1}} but if the key is in the filesystem it should still be {{ic|/dev/sdb1}}.}}<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 a LUKS password. Type it in and everything should boot.<br />
Once you have logged in, have a look at your mounted partitions by typing {{ic|mount}}. You should have {{ic|/dev/mapper/root}} mounted at {{ic|/}} and, if you set up a separate encrypted home partition, {{ic|/dev/mapper/home}} mounted at {{ic|/home}}. If you set up encrypted swap, {{ic|swapon -s}} should have {{ic|/dev/mapper/swap}} 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 is not, simply enter your password and press {{keypress|Enter}}.}}<br />
<br />
== Remote unlocking of the root (or other) 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 achieved by running the {{ic|net}} hook along with an [[SSH]] server in initrd. Install the {{AUR|dropbear_initrd_encrypt}} package from the [[Arch User Repository|AUR]] and follow the post-installation instructions. Replace the {{ic|encrypt}} hook with {{ic|dropbear encryptssh}} in {{ic|/etc/mkinitcpio.conf}}. Put the {{ic|net}} hook early in the HOOKS array if your DHCP server takes a long time to lease IP addresses.<br />
<br />
If you would simply like a nice solution to mount other encrypted partitions (such as {{ic|/home}})remotely, you may want to look at [https://bbs.archlinux.org/viewtopic.php?pid=880484 this forum thread].<br />
<br />
{{Note|Acutally trim will not work with this script because it is not yet updated to the latest encrypt hook, so it is not able to parse {{ic|-–allow-discards}} from {{ic|/boot/grub/menu.lst}}. (Version: dropbear_initrd_encrypt 0.8-16). You won't notice any error when using online discard, but you see an error when you try to use {{ic|fstrim}}.For a temporary solution just add {{ic|-–allow-discards}} to every cryptsetup line of {{ic|/lib/initcpio/install/dropbear}}(1 line) and {{ic|/lib/initcpio/hooks/encryptssh}}(3 lines)}}<br />
<br />
== Backup the cryptheader ==<br />
If the header of your encrypted partition gets destroyed, you will not be able to decrypt your data. Therefore, having a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT backing up the cryptheader, but even so it's a single point of failure!<br />
In short, the problem is that LUKS is not aware of the duplicated cryptheader, which contains the master key which is used to encrypt all files on your partition. Of course this master key 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 master key 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]{{Linkrot|2011|09|05}} for further details on this.<br />
<br />
{{Note|You can also back up 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 />
=== Backup ===<br />
==== Manually ====<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 />
==== Using cryptsetup ====<br />
You can also use the luksHeaderBackup command instead:<br />
cryptsetup luksHeaderBackup /dev/sdaX --header-backup-file ./backup.img<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 />
==== Manually ====<br />
Again, you will need to the same values as when backing up:<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
==== Using cryptsetup ====<br />
Or you can use the luksHeaderRestore command:<br />
cryptsetup luksHeaderRestore /dev/sdaX --header-backup-file ./backup.img<br />
<br />
'''Note:''' All the keyslot areas are overwritten; only active keyslots from the backup file are available after issuing this command.<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 />
First, start by creating an encrypted container!<br />
<br />
dd if=/dev/urandom of=/bigsecret bs=1M count=10<br />
<br />
This will create the file {{ic|bigsecret}} with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node {{ic|/dev/loop0}}, so that we can mount/use our container.<br />
<br />
{{Note|If it gives you the error {{ic|/dev/loop0: No such file or directory}}, you need to first load the kernel module with {{ic|modprobe loop}}. These days (Kernel 3.2) loop devices are created on demand. Ask for a new loop device with {{ic|losetup -f}}.}}<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file.<br />
<br />
{{Note|If you get an error like {{ic|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 {{ic|modprobe dm-mod}}.}}<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the device file {{ic|/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 />
=== Encrypt using a key-file ===<br />
Let us 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 {{ic|/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 encrypting your keyfile using your private GPG key and storing an off-site 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 expand our container file with the size of the data we want to add:<br />
<br />
dd if=/dev/urandom bs=1M count=1024 | cat - >> /bigsecret<br />
<br />
Be careful to really use TWO {{ic|>}}, or you will override your current container!<br />
<br />
You could use {{ic|/dev/zero}} instead of {{ic|/dev/urandom}} to significantly speed up the process, but with {{ic|/dev/zero}} your encrypted filesystems will ''not be as secure''. (A better option to create random data quicker than {{ic|/dev/urandom}} is {{ic|frandom}} [https://aur.archlinux.org/packages.php?ID=9869], available from the [[AUR]]).<br />
<br />
Now we have to map the container to the loop device:<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 do not 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 the {{ic|encrypt}} hook '''before''' the {{ic|lvm2}} hook (and those two before the {{ic|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 set up your LVM volumes and then use them as the base for the encrypted partitions. That means, in short, that you have to set up LVM first. Then follow this guide, but replace all occurrences of {{ic|/dev/sdXy}} in the guide with its LVM counterpart. (E.g.: {{ic|/dev/sda5}} -> {{ic|/dev/<volume group name>/home}}).<br />
<br />
Do not forget to add the {{ic|encrypt}} hook in {{ic|/etc/mkinitcpio.conf}} '''before''' the {{ic|lvm2}} hook, if you chose to set up encrypted partitions on '''top''' of LVM. Also remember to change {{ic|USELVM}} in {{ic|/etc/rc.conf}} to {{ic|"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 partition 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 {{ic|/etc/rc.conf}} set {{ic|USELVM}} to {{ic|"yes"}}<br />
* In {{ic|/etc/mkinitcpio.conf}} add the {{ic|encrypt}} hook '''before''' the {{ic|lvm2}} hook in the {{ic|HOOKS}} array, if you set up LVM on top of the encrypted partition.<br />
<br />
That is 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 {{ic|/lib/initcpio/hooks/encrypt}} (the first one to your {{ic|/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 {{ic|/etc/crypttab}} with an external key file (i.e. the keyfile is not on any internal hard drive 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 the order of {{ic|/etc/fstab}} (at least).<br />
<br />
Of course, if the {{Pkg|cryptsetup}} package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking {{ic|/etc/rc.sysinit}} or similar files. Unlike {{ic|/etc/crypttab}}, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
If you want to do this on a software RAID partition, there is one more thing you need to do. Just setting the {{ic|/dev/mdX}} device in {{ic|/lib/initcpio/hooks/encrypt}} is not enough; the {{ic|encrypt}} hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices are not brought up until after the {{ic|encrypt}} hook is run. You can solve this by putting the RAID array in {{ic|/boot/grub/menu.lst}}, like <br />
kernel /boot/vmlinuz-linux md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID, you will notice the similarities with that setup ;-). [[GRUB]] can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz-linux root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM and dm-crypt manually (short version) ===<br />
<br />
==== Notes ====<br />
If you are smart enough for this, you will be smart enough to ignore/replace LVM-specific things if you do not want to use LVM.<br />
<br />
{{Note|This brief uses reiserfs for some of the partitions, so change this accordingly if you want to use a more "normal" file system, like ext4.}}<br />
<br />
==== Partitioning scheme ====<br />
{{ic|/dev/sda1}} -> {{ic|/boot}}<br />
{{ic|/dev/sda2}} -> LVM<br />
<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 />
<br />
==== Install Arch Linux ====<br />
Run {{ic|/arch/setup}}<br />
<br />
==== Configuration ====<br />
<br />
===== /etc/rc.conf =====<br />
Change {{ic|USELVM<nowiki>=</nowiki>"no"}} to {{ic|USELVM<nowiki>=</nowiki>"yes"}}.<br />
<br />
===== /etc/mkinitcpio.conf =====<br />
Put {{ic|lvm2}} and {{ic|encrypt}} (in that order) before {{ic|filesystems}} in the {{ic|HOOKS}} array. Again, note that you are setting encryption on '''top''' of LVM.)<br />
<br />
if you want install the system on a usb stick, you need to put {{ic|usb}} just after {{ic|udev}}.<br />
<br />
===== /boot/grub/menu.lst =====<br />
Change {{ic|root<nowiki>=</nowiki>/dev/hda3}} to {{ic|root<nowiki>=</nowiki>/dev/lvm/root}}.<br />
<br />
For kernel >= 2.6.30, you should change {{ic|root<nowiki>=</nowiki>/dev/hda3}} to the following:<br />
cryptdevice=/dev/lvm/root:root root=/dev/mapper/root<br />
<br />
if you want install the system on a usb stick, you need to add {{ic|lvmdelay<nowiki>=</nowiki>/dev/mapper/lvm-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 rebooting ====<br />
<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 />
<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on LVM on LUKS ===<br />
Make sure your kernel command line 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 />
==Using GPG or OpenSSL Encrypted Keyfiles==<br />
The following forum posts give instructions to use two factor authentication, gpg or openssl encrypted keyfiles [https://bbs.archlinux.org/viewtopic.php?id=120243 System Encryption using LUKS with GPG encrypted keys]:<br />
* GnuPG: [https://bbs.archlinux.org/viewtopic.php?pid=943338#p943338 Post regarding GPG encrypted keys]<br />
* OpenSSL: [https://bbs.archlinux.org/viewtopic.php?pid=947805#p947805 Post regarding OpenSSL encrypted keys]<br />
<br />
Note that:<br />
* If you want to use a GPG encrypted keyfile, you need to use a statically compiled GnuPG version 1.4 or you could edit the hooks and use this AUR package [https://aur.archlinux.org/packages.php?ID=58030 gnupg1]<br />
* It is possible that an update to OpenSSL could break the custom {{ic|ssldec}} mentioned in the second forum post.<br />
<br />
==Securing the unencrypted boot partition==<br />
Referring to an article from the ct-magazine (Issue 3/12, page 146, 01.16.2012 http://www.heise.de/ct/inhalt/2012/03/6/) the following script checks all files under {{ic|/boot}} for changes of SHA-1 hash, inode and occupied blocks on the hard drive. It also checks the MBR.<br />
<br />
The script with installation instructions is available here: ftp://ftp.heise.de/pub/ct/listings/1203-146.zip (Author: Juergen Schmidt, ju at heisec.de; License: GPLv2)<br />
<br />
There is also an AUR package: {{AUR|chkboot}}<br />
<br />
After installation, add {{ic|/usr/local/bin/chkboot.sh &}} to your {{ic|/etc/rc.local}}.<br />
<br />
And as {{ic|/usr/local/bin/chkboot_user.sh}} need to be excuted after login, add it to the autostarts (e.g. under KDE -> System Settings -> Startup and Shutdown -> Autostart)<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Install Arch Linux on top of RAID, LVM2, and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Airbus001https://wiki.archlinux.org/index.php?title=Dm-crypt&diff=209406Dm-crypt2012-06-15T22:32:41Z<p>Airbus001: /* Using LUKS to Format Partitions with a Keyfile */</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[ru:System Encryption with LUKS]]<br />
[[zh-CN:System Encryption with LUKS]]<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 />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
==== Data encryption ====<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
*Preventing unauthorized physical access to private data.<br />
*Some confidence in data disposal when discarding obsolete systems.<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 />
==== System encryption ====<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 />
*Preventing unauthorized physical access to operating system files<br />
*Preventing unauthorized physical access to private data that may cached by the system.<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 />
*Attempts to bypass the operating system by inserting a boot CD/USB<br />
*Copying, modifying, or removing the hard disk drives when the computer is off<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the {{ic|/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 />
{{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 Available for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption, including:<br />
<br />
;loop-AES ([http://loop-aes.sourceforge.net/ loop-AES]):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 />
;standard device-mapper encryption ([http://www.saout.de/misc/dm-crypt/ dm-crypt]):This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
;LUKS for dm-crypt ([http://code.google.com/p/cryptsetup/ LUKS]):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 />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key (see [[Wikipedia:Kerckhoffs's principle]])<br />
::*The usage of a proven encryption algorithm<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 />
====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 />
====discard/TRIM support for solid state disks====<br />
<br />
Solid state disk users should be aware that by default, Linux's full-disk encryption mechanisms will ''not'' forward TRIM commands from the filesystem to the underlying disk. The device-mapper maintainers have made it clear that TRIM support will never be enabled by default on dm-crypt devices because of the potential security implications; if TRIM support were enabled, an attacker may be able to tell which blocks have been used, how many blocks have been used, and other information that is exposed directly to the device when a TRIM is issued.<br />
<br />
It may be possible to determine the filesystem utilized by your encrypted device through the data that is leaked by TRIM. Furthermore, any information that may be derived by a profile of block usage may be exposed by enabling TRIM support on an encrypted device.<br />
<br />
As of {{Pkg|linux}} version 3.1, support for dm-crypt TRIM pass-through can be toggled upon device creation or mount with dmsetup. Support for this option also exists in {{Pkg|cryptsetup}} version 1.4.0 and up. To add support during boot, you will need to add "{{ic|:allow-discards}}" to the {{ic|cryptdevice}} option. The option should look like this:<br />
cryptdevice=/dev/mapper/root:root:allow-discards<br />
<br />
For more information, including specific commands and details on dm-crypt TRIM pass-through, see these mailing list threads:<br />
* http://article.gmane.org/gmane.linux.kernel.device-mapper.devel/14134<br />
* http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/5166<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 shut down. 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 to extract your encryption key - thus obtaining access to your data.<br />
<br />
{{Note|System Encryption assumes encryption of all mounted partitions: this includes all partitions except for {{ic|/boot}} - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, {{ic|/tmp}}, or root filesystems are unencrypted, only Data Encryption level of security has been accomplished.}}<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 />
=====Encryption of data partitions on the same physical disk as the system=====<br />
<br />
The most common form of data encryption is encrypting the {{ic|/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 decreased by orders of magnitude when compared to system encryption. The reason for this is 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, {{Pkg|mlocate}} will scan all currently mounted file systems regularly and write the list of filenames to {{ic|/var/lib/mlocate/mlocate.db}}, which is located in the non-encrypted root or {{ic|/var}} partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted {{ic|/home}} partition, readily available to assist them in accessing the encrypted data present on 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|System Encryption with eCryptfs]].<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 Hard Disk Drives or Separate Internal Hard Disk Drives<br />
::*CD/DVD/Blu-Ray Optical Media<br />
::*Magnetic Storage Media<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 set up.<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the hard disk 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 Hard Disk Drive ===<br />
<br />
Secure erasure of the hard disk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a hard disk 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 />
====Why perform secure erasure of a drive?====<br />
<br />
There are two types of hard disk 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 Hard Disk Drives'''<br />
<br />
::In hard drives 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 Hard Disk Drives'''<br />
<br />
::Repartitioning or reformatting a used hard drive 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 straightforward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore hard drives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
====Overwriting a hard disk drive with random data====<br />
<br />
There are two sources of random data commonly used for securely overwriting hard disk partitions.<br />
<br />
::*{{ic|/dev/urandom}}<br />
::*badblocks<br />
<br />
=====Using urandom=====<br />
<br />
#dd if=/dev/urandom of=/dev/<drive> bs=1M<br />
<br />
Where {{ic|/dev/<drive>}} is the drive to be encrypted.<br />
<br />
{{Note| Using {{ic|/dev/urandom}} will take a long time to completely overwrite a drive with "random" data. In the strictest sense, {{ic|/dev/urandom}} is less random than {{ic|/dev/random}}; however, {{ic|/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 {{ic|/dev/random}} for overwriting hard disks impractical.}}<br />
<br />
{{Note| Users may also find that {{ic|/dev/urandom}} takes an excessively long time on large drives of several hundred gigabytes or more (more than twenty-four hours). [[Frandom]] offers a faster alternative.}}<br />
<br />
{{Note|You can retrieve progress of the dd command with this command: {{ic|kill -USR1 $(pidof dd)}}}}<br />
<br />
=====Using badblocks=====<br />
<br />
#badblocks -c 10240 -wsvt random /dev/<drive><br />
<br />
Where {{ic|/dev/<drive>}} is the drive to be encrypted.<br />
<br />
{{Note|The {{ic|badblocks}} command overwrites the drive at a much faster rate by generating data that is not truly random.}}<br />
<br />
See also [[badblocks]].<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a hard disk 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 />
=====After installation=====<br />
Essentially the same effect can be achieved if a file is created on each of the partitions that fills the partition completely '''after''' the system is installed and booted with encrypted partitions mounted. <br />
#dd if=/dev/zero of=/path/to/the/output/file<br />
#rm /path/to/the/input/file<br />
Just make sure that you do that for every partition on the filesystem. This works as encrypted data is indistinguishabe from random, so anone trying to access potential leftover files will just see random data.<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 with systems that require 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 three flavors: primary partitions, extended partitions, and logical partitions.<br />
<br />
;Primary Partitions: These are the normal partitions recognized by the system BIOS. There can be up to four of these stored in the MBR.<br />
<br />
;Extended Partitions: These are primary partitions that also define another partition within themselves. Extended partitions were created to work around the original limit of four primary partitions.<br />
<br />
;Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
====LVM: Logical Volume Manager====<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple hard disk drives and partitions that are not possible with standard partitions. LVM is covered in detail in the [[LVM|Arch Linux LVM Wiki Article]] which is recommended reading prior to continuing with the instructions on setting up LUKS with LVM located below.<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 is that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In this case, logical volume management would be layered on top of the hardware encryption &ndash; usage of LUKS would be superfluous.<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 two required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*{{ic|'''/'''}}<br />
:::*Will be encrypted and store all system and user files ({{ic|/usr}}, {{ic|/bin}}, {{ic|/var}}, {{ic|/home}}, etc.)<br />
<br />
::An initial boot partition<br />
<br />
:::*{{ic|'''/boot'''}}<br />
:::*Will ''not'' be encrypted; the bootloader needs to access the {{ic|/boot}} directory where it will load the initramfs/encryption modules needed to load the rest of the system which ''is'' encrypted (see [[Mkinitcpio]] for details). For this reason, {{ic|/boot}} needs to reside on its own, unencrypted partition.<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 />
=====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 used, the space unoccupied by {{ic|/boot}} and swap should be defined as single large partition which will be divided up later at the LVM level.<br />
<br />
=====Multiple Disk Systems=====<br />
<br />
In systems that will have multiple hard disk drives, the same options exist as a single disk system. After the creation of the {{ic|/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 {{ic|/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 the dialogue for manual configuration of the hard drive.<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 per LUKS partition.<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
{{Note|Using a passphrase to decrypt LUKS partitions automatically from {{ic|/etc/crypttab}} is deprecated: see http://www.mail-archive.com/arch-projects@archlinux.org/msg02115.html}}<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
A full list of options {{ic|cryptsetup}} accepts can be found in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::*{{ic|-c}} defines the cipher type<br />
::*{{ic|-y}} prompts for password confirmation on password creation<br />
::*{{ic|-s}} defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
In the following examples for creating LUKS partitions, we will use the AES cipher in XTS mode; at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup, and details about them can be found here: [[Wikipedia:Block_cipher]]<br />
<br />
'''Formatting LUKS Partitions'''<br />
<br />
First of all make sure the device mapper kernel module is loaded by executing the following: {{ic|# modprobe dm_mod}}<br />
<br />
In order to format a desired partition as an encrypted LUKS partition execute:<br />
{{hc|# cryptsetup -c <cipher> -y -s <key size> luksFormat /dev/<partition name>|<br />
Enter passphrase: <password><br />
Verify passphrase: <password>}}<br />
<br />
This should be repeated for all partitions except for {{ic|/boot}} and possibly swap.<br />
<br />
The example below will create an encrypted root partition using the AES cipher in XTS mode (generally referred to as ''XTS-AES'').<br />
{{bc|cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2}}<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 the chosen partitioning method, the {{ic|/boot}} partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<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 {{ic|/dev/<partition name>}} is actually an encrypted device and should be addressed through LUKS using the {{ic|/dev/mapper/<name>}} so as not to overwrite the encrypted data. <br />
<br />
In order to open an encrypted LUKS partition execute:<br />
{{hc|# cryptsetup luksOpen /dev/<partition name> <device-mapper name>|<br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.}}<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
::*cryptsetup luksOpen /dev/sda2 '''swap'''<br />
::::Once opened, the swap partition device address would be '''{{ic|/dev/mapper/swap}}''' instead of {{ic|/dev/sda2}}.<br />
<br />
::*cryptsetup luksOpen /dev/sda3 '''root'''<br />
::::Once opened, the root partition device address would be '''{{ic|/dev/mapper/root}}''' instead of {{ic|/dev/sda3}}.<br />
<br />
{{Note|Since {{ic|/boot}} is not encrypted, it does not need a device mapped name and will be addressed as {{ic|/dev/sda1}}.}}<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 Partitions with a Keyfile ====<br />
{{Note|This section describes using a plaintext keyfile, if you want to encrypt your keyfile giving you two factor authentication see section 9.}}<br />
<br />
'''What is a Keyfile?'''<br />
<br />
A keyfile is any file in which the data contained within it 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 />
{{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 />
'''Why use a Keyfile?'''<br />
<br />
There are many kinds of keyfile. Each type of keyfile used has benefits and disadvantages summarized below:<br />
<br />
:'''keyfile.passphrase:'''<br />
::this is my passphrase I would have typed during boot but I have placed it in a file instead<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 add any security over entering a passphrase during the initial system start.<br />
<br />
:'''keyfile.randomtext:'''<br />
::fjqweifj830149-57 819y4my1- 38t1934yt8-91m 34co3;t8y;9p3y-<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 />
:'''keyfile.binary:'''<br />
::where any binary file, images, text, video could be chosen as the keyfile<br />
<br />
This is a binary file that has been defined as a keyfile. When identifying files as candidates for a keyfile, it is recommended to choose files that are relatively static such as photos, music, video clips. The benefit of these files is that they serve a dual function which can make them harder to identify as keyfiles. Instead of having a text file with a large amount of random text, the keyfile would look like a regular image file or music clip to the casual observer. The disadvantage is that if this file is lost or changed, it will most likely not be possible to access the encrypted volume without a backup passphrase. Additionally, there is a theoretical loss of randomness when compared to a randomly generated text file. This is due to the fact that images, videos and music have some intrinsic relationship between neighboring bits of data that does not exist for a text file. However this is controversial and has never been exploited publicly.<br />
<br />
'''Creating a Keyfile with Random Characters'''<br />
<br />
Here {{ic|dd}} is used to generate a keyfile of 2048 bits of random characters.<br />
<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
The usage of {{ic|dd}} is similar to initially wiping the volume with random data prior to encryption. <br />
<br />
{{Warning|Do not use [[badblocks]] here. It only generate a random pattern which just repeats its randomness over and over again.}}<br />
<br />
'''Creating a new LUKS encrypted partition with a Keyfile'''<br />
<br />
When creating a new LUKS encrypted partition, a keyfile may be associated with the partition on its creation using:<br />
<br />
# cryptsetup -c <desired cipher> -s <key size> luksFormat /dev/<volume to encrypt> '''/path/to/mykeyfile'''<br />
<br />
This is accomplished by appending the bold area to the standard cryptsetup command which defines where the keyfile is located.<br />
<br />
==== Adding Additional Passphrases or Keyfiles to a LUKS Encrypted Partition ====<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 slot 0.<br />
Additional keys will occupy slots 1&ndash;7.<br />
<br />
The addition of new keys to an encrypted partition is accomplished using cryptsetup with the {{ic|luksAddKey}} extension.<br />
<br />
# cryptsetup luksAddKey /dev/<encrypted volume> '''/path/to/mykeyfile'''<br />
<br />
Where {{ic|/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 is important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. {{ic|/dev/sdb1}} 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 {{ic|encrypt}} HOOK in the initcpio finds your keyfile, you must 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 the following:<br />
<br />
{{hc|# ls -l /dev/disk/by-label/|<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1}}<br />
<br />
or<br />
<br />
{{hc|# 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 {{ic|/dev/disk/by-label/Keys}}, or if I had wanted to use the UUID I would find {{ic|/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 ({{ic|sdb1}}, {{ic|sdb2}}, ...) but not to the USB device ({{ic|sdb}}) 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 flash drive with a [[udev]] rule. There is 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 is quickly how it goes.<br />
<br />
Get the serial number from your USB flash drive:<br />
lsusb -v | grep -A 5 Vendor<br />
<br />
Create a udev rule for it by adding the following to a file in {{ic|/etc/udev/rules.d/}}, such as {{ic|8-usbstick.rules}}:<br />
KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"<br />
<br />
Replace {{ic|$SYMLINK}} and {{ic|$SERIAL}} with their respective values. {{ic|%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 {{ic|/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. {{ic|/media/sdb1}}<br />
<br />
The keyfile can be of arbitrary content and size. We will 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 device, 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 {{ic|/etc/mkinitcpio.conf}}, one for the drive's file system and one for the codepage. Further if you created a udev rule, you should tell {{ic|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 is assumed that you use a FAT formatted USB drive. 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 />
Additionally, insert the {{ic|usb}} hook somewhere before the {{ic|encrypt}} hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
If you have a non-US keyboard, it might prove useful to load your keyboard layout before you are prompted to enter the password to unlock the root partition at boot. For this, you will need the {{ic|keymap}} hook before {{ic|encrypt}}.<br />
<br />
Generate a new image (maybe you should backup a copy of your old kernel26.img first):<br />
mkinitcpio -g /boot/initramfs-linux.img<br />
<br />
==== Storing the key as a plain (visible) file ====<br />
Be sure to choose a plain name for your key &ndash; a bit of 'security through obscurity' is always nice ;-). Avoid using dotfiles (hidden files) &ndash; the {{ic|encrypt}} hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your {{ic|/boot/grub/menu.lst}} ([[GRUB]]). It should look something like this:<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes {{ic|/dev/usbstick}} is the FAT partition of your choice. Replace it with {{ic|/dev/disk/by-...}} or whatever your device is.<br />
<br />
That is all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We will write the key directly between the Master Boot Record (MBR) and the first partition.<br />
<br />
{{Warning|You should only follow this step if you know what you are doing -- '''it can cause data loss and damage your partitions or MBR on the stick!'''}}<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 do not rely on this too much), so you would have to replace {{ic|seek<nowiki>=</nowiki>4}} with {{ic|seek<nowiki>=</nowiki>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 />
''Optional''<br />
If you do not know if you have 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 {{ic|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 {{ic|/boot/grub/menu.lst}} file (GRUB); it should look something like this:<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usb:2048:2048<br />
Format for the {{ic|cryptkey}} option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
{{ic|OFFSET}} and {{ic|SIZE}} match in this example, but this is just coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usb:8192:2048<br />
That is all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
=== Encrypting the Swap partition ===<br />
<br />
==== Without suspend-to-disk 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 />
Append a similar line to {{ic|/etc/crypttab}} to set up a randomly encrypted swap partition:<br />
<br />
<device-mapper name> <swap physical partition> SWAP "-c aes-xts-plain -h whirlpool -s 512"<br />
<br />
Where:<br />
<br />
:*{{ic|<device-mapper name>}} represents the name you want to use as label in /etc/fstab<br />
:*{{ic|<swap physical partition>}} should be the ID of the actual partition. <br> {{Warning|You should use IDs here because if there are multiple hard drives installed in the system, their naming order (sda, sdb,...) can occasionally be scrambled upon boot and thus the swap would be created over a valuable file system, destroying its content. {{ic|<nowiki>ls -l /dev/disk/*/* | grep sdl7</nowiki>}} should help you to find the desired partition.}}<br />
:*{{ic|SWAP}} identifies the partition as a swap partition<br />
:*{{ic|-c}} defines a cipher<br />
:*{{ic|-h}} defines a hash algorithm<br />
:*{{ic|-s}} defines the key size<br />
<br />
Example line (where {{ic|/dev/sdl7}} is the physical partition and {{ic|<nowiki>LABEL=swap</nowiki>}} the desired label):<br />
<br />
swap /dev/disk/by-id/scsi-SATA_Hitachi_HDS7220_JK1130YAGX0R1T-part7 SWAP "-c aes-xts-plain -h whirlpool -s 512"<br />
<br />
:Maps {{ic|/dev/sdl7}} to {{ic|/dev/mapper/swap}} as a swap partition which we can now add in {{ic|/etc/fstab}} like a normal swap.<br />
<br />
If the partition chosen for swap was previously a LUKS partition, crypttab will not overwrite the partition to create a swap partition. This is a safety measure to prevent data loss from accidental mis-identification of the swap partition in crypttab. In order to use such a partition the LUKS header must be removed. This can be accomplished with:<br />
<br />
# dd if=/dev/zero of=/dev/sdl7 bs=1M<br />
<br />
==== With suspend-to-disk support ====<br />
{{Warning|Do not use this setup with a key file. Please read about the issue reported [[Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure|here]]}}<br />
<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 pre-existent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before {{ic|/etc/crypttab}} can be used, it is required to create a hook in {{ic|/etc/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 />
* Format the partition you want to use as swap with the {{ic|cryptsetup}} command. For performance reasons, you might want to use different ciphers with different key sizes.<br />
<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check the result with:<br />
<br />
# cryptsetup luksDump /dev/<device><br />
<br />
* Open the partition in {{ic|/dev/mapper}}:<br />
<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
<br />
* Create a swap filesystem inside the mapped partition:<br />
<br />
# mkswap /dev/mapper/swapDevice<br />
<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in {{ic|/etc/crypttab}} which uses this device. Now you have to create a hook to open the swap at boot time.<br />
<br />
* Create a hook file containing the open command:<br />
<br />
{{hc|/lib/initcpio/hooks/openswap|<nowiki><br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
</nowiki>}}<br />
<br />
* Then create and edit the hook setup file:<br />
{{hc|/lib/initcpio/install/openswap|<nowiki><br />
# vim: set ft=sh:<br />
build ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
</nowiki>}}<br />
<br />
* Add the hook {{ic|openswap}} in the {{ic|HOOKS}} array in {{ic|/etc/mkinitcpio.conf}}, before {{ic|filesystem}}, but '''after''' {{ic|encrypt}} which is mandatory as well. Do not forget to add the {{ic|resume}} hook between {{ic|openswap}} and {{ic|filesystem}} as well.<br />
<br />
* Regenerate the boot image:<br />
<br />
# mkinitcpio -p linux<br />
<br />
* Add the mapped partition to {{ic|/etc/fstab}} by adding the following line:<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
<br />
* Set up your system to resume from {{ic|/dev/mapper/swapDevice}}. For example, if you use [[GRUB]] with kernel hibernation support, add {{ic|resume<nowiki>=</nowiki>/dev/mapper/swapDevice}} to the kernel line in {{ic|/boot/grub/menu.lst}}. A line with encrypted root and swap partitions can look like this:<br />
<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
<br />
At boot time, the {{ic|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 are placed '''after''' {{ic|openswap}} in the {{ic|HOOKS}} array. Please note that because of initrd opening swap, there is no entry for swapDevice in {{ic|/etc/crypttab}} needed in this case.<br />
<br />
=== Using a swap file for suspend-to-disk support ===<br />
* Choose a mapped partition (e.g. {{ic|/dev/mapper/rootDevice}}) whose mounted filesystem (e.g. {{ic|/}}) contains enough free space to hold the entire contents of your system's RAM. For example, if your system has 4 GiB RAM, then you need at least that much free space on the mounted filesystem of your chosen mapped partition for the swap file.<br />
<br />
* [[HOW_TO:_Create_swap_file#Swap_file_creation | Create the swap file]] (e.g. {{ic|/swapfile}}) inside the mounted filesystem of your chosen mapped partition. Be sure to activate it with {{ic|swapon}} and also add it to your {{ic|/etc/fstab}} file afterward.<br />
<br />
* Set up your system to resume from your chosen mapped partition. For example, if you use [[GRUB]] with kernel hibernation support, add {{ic|resume<nowiki>=</nowiki>}}''your chosen mapped partition'' and {{ic|resume_offset<nowiki>=</nowiki>}}''see calculation command below'' to the kernel line in {{ic|/boot/grub/menu.lst}}. A line with encrypted root partition can look like this:<br />
<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/rootDevice resume_offset=123456789 ro<br />
<br />
You can calculate the {{ic|resume_offset}} of your swap file like this:<br />
<br />
# filefrag -v /swapfile | awk '{if($1==0){print $3}}'<br />
<br />
* Add the {{ic|resume}} hook to your {{ic|etc/mkinitcpio.conf}} file and [[Mkinitcpio#Image_creation_and_activation|rebuild the image]] afterward:<br />
<br />
HOOKS="... encrypt '''resume''' ... filesystems ..."<br />
<br />
== Installing the system ==<br />
Now that {{ic|/dev/mapper/root}} and {{ic|/dev/mapper/home}} 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 steps and go straight to manual configuration.<br />
Instead of choosing the hardware devices ({{ic|/dev/sdaX}}) directly, you have to select the mapper devices created above.<br />
Choose {{ic|/dev/mapper/root}} for your root and {{ic|/dev/mapper/home}} as {{ic|/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 {{ic|/home}} partition. Make sure you mount {{ic|/dev/sda1}} as the {{ic|/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|The {{ic|encrypt}} hook is only needed if your root partition is a ''LUKS'' partition (or a LUKS partition that needs to be mounted ''before'' root). The {{ic|encrypt}} hook is not needed if any other partition (swap, for example) is encrypted. System initialization scripts ({{ic|/etc/rc.sysinit}} and {{ic|/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 {{ic|/etc/mkinitcpio.conf}}. For detailed information about mkinitcpio and its configuration refer to [[Mkinitcpio]]. You have to make sure that your {{ic|HOOKS}} array in {{ic|/etc/mkinitcpio.conf}} looks something like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the {{ic|encrypt}} hook comes ''before'' the {{ic|filesystems}} hook. 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 {{ic|usb}} before {{ic|encrypt}} because the hooks are run in the order they appear.<br />
If you need support for foreign keymaps for your encryption password, you have to specify the hook {{ic|keymap}} as well. I suggest putting this in {{ic|/etc/mkinitcpio.conf}} immediately before {{ic|encrypt}}.<br />
<br />
If you have a USB keyboard, you will need the {{ic|usbinput}} hook in {{ic|/etc/mkinitcpio.conf}}. Without it, no USB keyboard will work in early userspace.<br />
<br />
If your root partition is a ''LUKS'' partition, add the used filesystem to the {{ic|MODULES}} section.<br />
MODULES="... ext3 ext4 xfs ..."<br />
<br />
=== Install Bootloader ===<br />
'''[[GRUB]]:''' You have to make some small changes to the entries generated by the installer by replacing {{ic|/dev/mapper/root}} with {{ic|/dev/sda3}}. The important point to remember here is to use the same {{ic|cryptdevice}} name you assigned when you initially unlocked your device. In this example, the device name is {{ic|cryptroot}}; customize yours accordingly:<br />
<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:cryptroot root=/dev/mapper/cryptroot ro<br />
initrd /initramfs-linux.img<br />
<br />
For kernels older than 2.6.37, the syntax is:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' Edit the Arch Linux section in {{ic|/etc/lilo.conf}} and include a line for the {{ic|append}} option, over the initrd, with the {{ic|root<nowiki>=</nowiki>/dev/sda3}} parameter. The {{ic|append}} section makes the same kernel line as in GRUB. Also, you can omit the {{ic|root}} option above the {{ic|image}} option. The section looks like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz-linux<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /initramfs-linux.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note|If you want to use a USB flash drive with a keyfile, you have to append the {{ic|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 {{ic|/etc/crypttab}} file so you do not have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. {{ic|/home}}, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
<br />
Add the following line for the {{ic|/home}} partition<br />
{{Note|Using a passphrase to decrypt LUKS partitions automatically from {{ic|/etc/crypttab}} is deprecated: see http://www.mail-archive.com/arch-projects@archlinux.org/msg02115.html}}<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 [[#Adding_Additional_Passphrases_or_Keyfiles_to_a_LUKS_Encrypted_Partition|above]].<br />
Then add the following information to the {{ic|/etc/crypttab}} file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
If you used a USB device to store your keyfile, you should have something like this:<br />
home /dev/sda5 /dev/sd*1/keyfile<br />
<br />
Or if the keyfile was stored in the MBR, it should be like this:<br />
home /dev/sda5 /dev/sd*:2048:2048<br />
<br />
{{Box BLUE|Note:|When reading the keyfile from the MBR it should be {{ic|/dev/sdb}} not {{ic|/dev/sdb1}} but if the key is in the filesystem it should still be {{ic|/dev/sdb1}}.}}<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 a LUKS password. Type it in and everything should boot.<br />
Once you have logged in, have a look at your mounted partitions by typing {{ic|mount}}. You should have {{ic|/dev/mapper/root}} mounted at {{ic|/}} and, if you set up a separate encrypted home partition, {{ic|/dev/mapper/home}} mounted at {{ic|/home}}. If you set up encrypted swap, {{ic|swapon -s}} should have {{ic|/dev/mapper/swap}} 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 is not, simply enter your password and press {{keypress|Enter}}.}}<br />
<br />
== Remote unlocking of the root (or other) 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 achieved by running the {{ic|net}} hook along with an [[SSH]] server in initrd. Install the {{AUR|dropbear_initrd_encrypt}} package from the [[Arch User Repository|AUR]] and follow the post-installation instructions. Replace the {{ic|encrypt}} hook with {{ic|dropbear encryptssh}} in {{ic|/etc/mkinitcpio.conf}}. Put the {{ic|net}} hook early in the HOOKS array if your DHCP server takes a long time to lease IP addresses.<br />
<br />
If you would simply like a nice solution to mount other encrypted partitions (such as {{ic|/home}})remotely, you may want to look at [https://bbs.archlinux.org/viewtopic.php?pid=880484 this forum thread].<br />
<br />
{{Note|Acutally trim will not work with this script because it is not yet updated to the latest encrypt hook, so it is not able to parse {{ic|-–allow-discards}} from {{ic|/boot/grub/menu.lst}}. (Version: dropbear_initrd_encrypt 0.8-16). You won't notice any error when using online discard, but you see an error when you try to use {{ic|fstrim}}.For a temporary solution just add {{ic|-–allow-discards}} to every cryptsetup line of {{ic|/lib/initcpio/install/dropbear}}(1 line) and {{ic|/lib/initcpio/hooks/encryptssh}}(3 lines)}}<br />
<br />
== Backup the cryptheader ==<br />
If the header of your encrypted partition gets destroyed, you will not be able to decrypt your data. Therefore, having a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT backing up the cryptheader, but even so it's a single point of failure!<br />
In short, the problem is that LUKS is not aware of the duplicated cryptheader, which contains the master key which is used to encrypt all files on your partition. Of course this master key 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 master key 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]{{Linkrot|2011|09|05}} for further details on this.<br />
<br />
{{Note|You can also back up 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 />
=== Backup ===<br />
==== Manually ====<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 />
==== Using cryptsetup ====<br />
You can also use the luksHeaderBackup command instead:<br />
cryptsetup luksHeaderBackup /dev/sdaX --header-backup-file ./backup.img<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 />
==== Manually ====<br />
Again, you will need to the same values as when backing up:<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
==== Using cryptsetup ====<br />
Or you can use the luksHeaderRestore command:<br />
cryptsetup luksHeaderRestore /dev/sdaX --header-backup-file ./backup.img<br />
<br />
'''Note:''' All the keyslot areas are overwritten; only active keyslots from the backup file are available after issuing this command.<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 />
First, start by creating an encrypted container!<br />
<br />
dd if=/dev/urandom of=/bigsecret bs=1M count=10<br />
<br />
This will create the file {{ic|bigsecret}} with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node {{ic|/dev/loop0}}, so that we can mount/use our container.<br />
<br />
{{Note|If it gives you the error {{ic|/dev/loop0: No such file or directory}}, you need to first load the kernel module with {{ic|modprobe loop}}. These days (Kernel 3.2) loop devices are created on demand. Ask for a new loop device with {{ic|losetup -f}}.}}<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file.<br />
<br />
{{Note|If you get an error like {{ic|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 {{ic|modprobe dm-mod}}.}}<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the device file {{ic|/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 />
=== Encrypt using a key-file ===<br />
Let us 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 {{ic|/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 encrypting your keyfile using your private GPG key and storing an off-site 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 expand our container file with the size of the data we want to add:<br />
<br />
dd if=/dev/urandom bs=1M count=1024 | cat - >> /bigsecret<br />
<br />
Be careful to really use TWO {{ic|>}}, or you will override your current container!<br />
<br />
You could use {{ic|/dev/zero}} instead of {{ic|/dev/urandom}} to significantly speed up the process, but with {{ic|/dev/zero}} your encrypted filesystems will ''not be as secure''. (A better option to create random data quicker than {{ic|/dev/urandom}} is {{ic|frandom}} [https://aur.archlinux.org/packages.php?ID=9869], available from the [[AUR]]).<br />
<br />
Now we have to map the container to the loop device:<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 do not 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 the {{ic|encrypt}} hook '''before''' the {{ic|lvm2}} hook (and those two before the {{ic|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 set up your LVM volumes and then use them as the base for the encrypted partitions. That means, in short, that you have to set up LVM first. Then follow this guide, but replace all occurrences of {{ic|/dev/sdXy}} in the guide with its LVM counterpart. (E.g.: {{ic|/dev/sda5}} -> {{ic|/dev/<volume group name>/home}}).<br />
<br />
Do not forget to add the {{ic|encrypt}} hook in {{ic|/etc/mkinitcpio.conf}} '''before''' the {{ic|lvm2}} hook, if you chose to set up encrypted partitions on '''top''' of LVM. Also remember to change {{ic|USELVM}} in {{ic|/etc/rc.conf}} to {{ic|"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 partition 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 {{ic|/etc/rc.conf}} set {{ic|USELVM}} to {{ic|"yes"}}<br />
* In {{ic|/etc/mkinitcpio.conf}} add the {{ic|encrypt}} hook '''before''' the {{ic|lvm2}} hook in the {{ic|HOOKS}} array, if you set up LVM on top of the encrypted partition.<br />
<br />
That is 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 {{ic|/lib/initcpio/hooks/encrypt}} (the first one to your {{ic|/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 {{ic|/etc/crypttab}} with an external key file (i.e. the keyfile is not on any internal hard drive 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 the order of {{ic|/etc/fstab}} (at least).<br />
<br />
Of course, if the {{Pkg|cryptsetup}} package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking {{ic|/etc/rc.sysinit}} or similar files. Unlike {{ic|/etc/crypttab}}, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
If you want to do this on a software RAID partition, there is one more thing you need to do. Just setting the {{ic|/dev/mdX}} device in {{ic|/lib/initcpio/hooks/encrypt}} is not enough; the {{ic|encrypt}} hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices are not brought up until after the {{ic|encrypt}} hook is run. You can solve this by putting the RAID array in {{ic|/boot/grub/menu.lst}}, like <br />
kernel /boot/vmlinuz-linux md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID, you will notice the similarities with that setup ;-). [[GRUB]] can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz-linux root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM and dm-crypt manually (short version) ===<br />
<br />
==== Notes ====<br />
If you are smart enough for this, you will be smart enough to ignore/replace LVM-specific things if you do not want to use LVM.<br />
<br />
{{Note|This brief uses reiserfs for some of the partitions, so change this accordingly if you want to use a more "normal" file system, like ext4.}}<br />
<br />
==== Partitioning scheme ====<br />
{{ic|/dev/sda1}} -> {{ic|/boot}}<br />
{{ic|/dev/sda2}} -> LVM<br />
<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 />
<br />
==== Install Arch Linux ====<br />
Run {{ic|/arch/setup}}<br />
<br />
==== Configuration ====<br />
<br />
===== /etc/rc.conf =====<br />
Change {{ic|USELVM<nowiki>=</nowiki>"no"}} to {{ic|USELVM<nowiki>=</nowiki>"yes"}}.<br />
<br />
===== /etc/mkinitcpio.conf =====<br />
Put {{ic|lvm2}} and {{ic|encrypt}} (in that order) before {{ic|filesystems}} in the {{ic|HOOKS}} array. Again, note that you are setting encryption on '''top''' of LVM.)<br />
<br />
if you want install the system on a usb stick, you need to put {{ic|usb}} just after {{ic|udev}}.<br />
<br />
===== /boot/grub/menu.lst =====<br />
Change {{ic|root<nowiki>=</nowiki>/dev/hda3}} to {{ic|root<nowiki>=</nowiki>/dev/lvm/root}}.<br />
<br />
For kernel >= 2.6.30, you should change {{ic|root<nowiki>=</nowiki>/dev/hda3}} to the following:<br />
cryptdevice=/dev/lvm/root:root root=/dev/mapper/root<br />
<br />
if you want install the system on a usb stick, you need to add {{ic|lvmdelay<nowiki>=</nowiki>/dev/mapper/lvm-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 rebooting ====<br />
<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 />
<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on LVM on LUKS ===<br />
Make sure your kernel command line 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 />
==Using GPG or OpenSSL Encrypted Keyfiles==<br />
The following forum posts give instructions to use two factor authentication, gpg or openssl encrypted keyfiles [https://bbs.archlinux.org/viewtopic.php?id=120243 System Encryption using LUKS with GPG encrypted keys]:<br />
* GnuPG: [https://bbs.archlinux.org/viewtopic.php?pid=943338#p943338 Post regarding GPG encrypted keys]<br />
* OpenSSL: [https://bbs.archlinux.org/viewtopic.php?pid=947805#p947805 Post regarding OpenSSL encrypted keys]<br />
<br />
Note that:<br />
* If you want to use a GPG encrypted keyfile, you need to use a statically compiled GnuPG version 1.4 or you could edit the hooks and use this AUR package [https://aur.archlinux.org/packages.php?ID=58030 gnupg1]<br />
* It is possible that an update to OpenSSL could break the custom {{ic|ssldec}} mentioned in the second forum post.<br />
<br />
==Securing the unencrypted boot partition==<br />
Referring to an article from the ct-magazine (Issue 3/12, page 146, 01.16.2012 http://www.heise.de/ct/inhalt/2012/03/6/) the following script checks all files under {{ic|/boot}} for changes of SHA-1 hash, inode and occupied blocks on the hard drive. It also checks the MBR.<br />
<br />
The script with installation instructions is available here: ftp://ftp.heise.de/pub/ct/listings/1203-146.zip (Author: Juergen Schmidt, ju at heisec.de; License: GPLv2)<br />
<br />
There is also an AUR package: {{AUR|chkboot}}<br />
<br />
After installation, add {{ic|/usr/local/bin/chkboot.sh &}} to your {{ic|/etc/rc.local}}.<br />
<br />
And as {{ic|/usr/local/bin/chkboot_user.sh}} need to be excuted after login, add it to the autostarts (e.g. under KDE -> System Settings -> Startup and Shutdown -> Autostart)<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Install Arch Linux on top of RAID, LVM2, and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Airbus001https://wiki.archlinux.org/index.php?title=Dm-crypt&diff=208622Dm-crypt2012-06-15T05:53:36Z<p>Airbus001: /* Securing the unencrypted boot partition */</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[ru:System Encryption with LUKS]]<br />
[[zh-CN:System Encryption with LUKS]]<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 />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
==== Data encryption ====<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
*Preventing unauthorized physical access to private data.<br />
*Some confidence in data disposal when discarding obsolete systems.<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 />
==== System encryption ====<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 />
*Preventing unauthorized physical access to operating system files<br />
*Preventing unauthorized physical access to private data that may cached by the system.<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 />
*Attempts to bypass the operating system by inserting a boot CD/USB<br />
*Copying, modifying, or removing the hard disk drives when the computer is off<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the {{ic|/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 />
{{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 Available for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption, including:<br />
<br />
;loop-AES ([http://loop-aes.sourceforge.net/ loop-AES]):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 />
;standard device-mapper encryption ([http://www.saout.de/misc/dm-crypt/ dm-crypt]):This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
;LUKS for dm-crypt ([http://code.google.com/p/cryptsetup/ LUKS]):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 />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key (see [[Wikipedia:Kerckhoffs's principle]])<br />
::*The usage of a proven encryption algorithm<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 />
====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 />
====discard/TRIM support for solid state disks====<br />
<br />
Solid state disk users should be aware that by default, Linux's full-disk encryption mechanisms will ''not'' forward TRIM commands from the filesystem to the underlying disk. The device-mapper maintainers have made it clear that TRIM support will never be enabled by default on dm-crypt devices because of the potential security implications; if TRIM support were enabled, an attacker may be able to tell which blocks have been used, how many blocks have been used, and other information that is exposed directly to the device when a TRIM is issued.<br />
<br />
It may be possible to determine the filesystem utilized by your encrypted device through the data that is leaked by TRIM. Furthermore, any information that may be derived by a profile of block usage may be exposed by enabling TRIM support on an encrypted device.<br />
<br />
As of {{Pkg|linux}} version 3.1, support for dm-crypt TRIM pass-through can be toggled upon device creation or mount with dmsetup. Support for this option also exists in {{Pkg|cryptsetup}} version 1.4.0 and up. To add support during boot, you will need to add "{{ic|:allow-discards}}" to the {{ic|cryptdevice}} option. The option should look like this:<br />
cryptdevice=/dev/mapper/root:root:allow-discards<br />
<br />
For more information, including specific commands and details on dm-crypt TRIM pass-through, see these mailing list threads:<br />
* http://article.gmane.org/gmane.linux.kernel.device-mapper.devel/14134<br />
* http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/5166<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 shut down. 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 to extract your encryption key - thus obtaining access to your data.<br />
<br />
{{Note|System Encryption assumes encryption of all mounted partitions: this includes all partitions except for {{ic|/boot}} - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, {{ic|/tmp}}, or root filesystems are unencrypted, only Data Encryption level of security has been accomplished.}}<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 />
=====Encryption of data partitions on the same physical disk as the system=====<br />
<br />
The most common form of data encryption is encrypting the {{ic|/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 decreased by orders of magnitude when compared to system encryption. The reason for this is 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, {{Pkg|mlocate}} will scan all currently mounted file systems regularly and write the list of filenames to {{ic|/var/lib/mlocate/mlocate.db}}, which is located in the non-encrypted root or {{ic|/var}} partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted {{ic|/home}} partition, readily available to assist them in accessing the encrypted data present on 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|System Encryption with eCryptfs]].<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 Hard Disk Drives or Separate Internal Hard Disk Drives<br />
::*CD/DVD/Blu-Ray Optical Media<br />
::*Magnetic Storage Media<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 set up.<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the hard disk 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 Hard Disk Drive ===<br />
<br />
Secure erasure of the hard disk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a hard disk 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 />
====Why perform secure erasure of a drive?====<br />
<br />
There are two types of hard disk 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 Hard Disk Drives'''<br />
<br />
::In hard drives 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 Hard Disk Drives'''<br />
<br />
::Repartitioning or reformatting a used hard drive 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 straightforward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore hard drives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
====Overwriting a hard disk drive with random data====<br />
<br />
There are two sources of random data commonly used for securely overwriting hard disk partitions.<br />
<br />
::*{{ic|/dev/urandom}}<br />
::*badblocks<br />
<br />
=====Using urandom=====<br />
<br />
#dd if=/dev/urandom of=/dev/<drive> bs=1M<br />
<br />
Where {{ic|/dev/<drive>}} is the drive to be encrypted.<br />
<br />
{{Note| Using {{ic|/dev/urandom}} will take a long time to completely overwrite a drive with "random" data. In the strictest sense, {{ic|/dev/urandom}} is less random than {{ic|/dev/random}}; however, {{ic|/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 {{ic|/dev/random}} for overwriting hard disks impractical.}}<br />
<br />
{{Note| Users may also find that {{ic|/dev/urandom}} takes an excessively long time on large drives of several hundred gigabytes or more (more than twenty-four hours). [[Frandom]] offers a faster alternative.}}<br />
<br />
{{Note|You can retrieve progress of the dd command with this command: {{ic|kill -USR1 $(pidof dd)}}}}<br />
<br />
=====Using badblocks=====<br />
<br />
#badblocks -c 10240 -wsvt random /dev/<drive><br />
<br />
Where {{ic|/dev/<drive>}} is the drive to be encrypted.<br />
<br />
{{Note|The {{ic|badblocks}} command overwrites the drive at a much faster rate by generating data that is not truly random.}}<br />
<br />
See also [[badblocks]].<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a hard disk 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 />
=====After installation=====<br />
Essentially the same effect can be achieved if a file is created on each of the partitions that fills the partition completely '''after''' the system is installed and booted with encrypted partitions mounted. <br />
#dd if=/dev/zero of=/path/to/the/output/file<br />
#rm /path/to/the/input/file<br />
Just make sure that you do that for every partition on the filesystem. This works as encrypted data is indistinguishabe from random, so anone trying to access potential leftover files will just see random data.<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 with systems that require 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 three flavors: primary partitions, extended partitions, and logical partitions.<br />
<br />
;Primary Partitions: These are the normal partitions recognized by the system BIOS. There can be up to four of these stored in the MBR.<br />
<br />
;Extended Partitions: These are primary partitions that also define another partition within themselves. Extended partitions were created to work around the original limit of four primary partitions.<br />
<br />
;Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
====LVM: Logical Volume Manager====<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple hard disk drives and partitions that are not possible with standard partitions. LVM is covered in detail in the [[LVM|Arch Linux LVM Wiki Article]] which is recommended reading prior to continuing with the instructions on setting up LUKS with LVM located below.<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 is that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In this case, logical volume management would be layered on top of the hardware encryption &ndash; usage of LUKS would be superfluous.<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 two required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*{{ic|'''/'''}}<br />
:::*Will be encrypted and store all system and user files ({{ic|/usr}}, {{ic|/bin}}, {{ic|/var}}, {{ic|/home}}, etc.)<br />
<br />
::An initial boot partition<br />
<br />
:::*{{ic|'''/boot'''}}<br />
:::*Will ''not'' be encrypted; the bootloader needs to access the {{ic|/boot}} directory where it will load the initramfs/encryption modules needed to load the rest of the system which ''is'' encrypted (see [[Mkinitcpio]] for details). For this reason, {{ic|/boot}} needs to reside on its own, unencrypted partition.<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 />
=====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 used, the space unoccupied by {{ic|/boot}} and swap should be defined as single large partition which will be divided up later at the LVM level.<br />
<br />
=====Multiple Disk Systems=====<br />
<br />
In systems that will have multiple hard disk drives, the same options exist as a single disk system. After the creation of the {{ic|/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 {{ic|/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 the dialogue for manual configuration of the hard drive.<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 per LUKS partition.<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
{{Note|Using a passphrase to decrypt LUKS partitions automatically from {{ic|/etc/crypttab}} is deprecated: see http://www.mail-archive.com/arch-projects@archlinux.org/msg02115.html}}<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
A full list of options {{ic|cryptsetup}} accepts can be found in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::*{{ic|-c}} defines the cipher type<br />
::*{{ic|-y}} prompts for password confirmation on password creation<br />
::*{{ic|-s}} defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
In the following examples for creating LUKS partitions, we will use the AES cipher in XTS mode; at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup, and details about them can be found here: [[Wikipedia:Block_cipher]]<br />
<br />
'''Formatting LUKS Partitions'''<br />
<br />
First of all make sure the device mapper kernel module is loaded by executing the following: {{ic|# modprobe dm_mod}}<br />
<br />
In order to format a desired partition as an encrypted LUKS partition execute:<br />
{{hc|# cryptsetup -c <cipher> -y -s <key size> luksFormat /dev/<partition name>|<br />
Enter passphrase: <password><br />
Verify passphrase: <password>}}<br />
<br />
This should be repeated for all partitions except for {{ic|/boot}} and possibly swap.<br />
<br />
The example below will create an encrypted root partition using the AES cipher in XTS mode (generally referred to as ''XTS-AES'').<br />
{{bc|cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2}}<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 the chosen partitioning method, the {{ic|/boot}} partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<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 {{ic|/dev/<partition name>}} is actually an encrypted device and should be addressed through LUKS using the {{ic|/dev/mapper/<name>}} so as not to overwrite the encrypted data. <br />
<br />
In order to open an encrypted LUKS partition execute:<br />
{{hc|# cryptsetup luksOpen /dev/<partition name> <device-mapper name>|<br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.}}<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
::*cryptsetup luksOpen /dev/sda2 '''swap'''<br />
::::Once opened, the swap partition device address would be '''{{ic|/dev/mapper/swap}}''' instead of {{ic|/dev/sda2}}.<br />
<br />
::*cryptsetup luksOpen /dev/sda3 '''root'''<br />
::::Once opened, the root partition device address would be '''{{ic|/dev/mapper/root}}''' instead of {{ic|/dev/sda3}}.<br />
<br />
{{Note|Since {{ic|/boot}} is not encrypted, it does not need a device mapped name and will be addressed as {{ic|/dev/sda1}}.}}<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 Partitions with a Keyfile ====<br />
<br />
'''What is a Keyfile?'''<br />
<br />
A keyfile is any file in which the data contained within it 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 />
{{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 />
'''Why use a Keyfile?'''<br />
<br />
There are many kinds of keyfile. Each type of keyfile used has benefits and disadvantages summarized below:<br />
<br />
:'''keyfile.passphrase:'''<br />
::this is my passphrase I would have typed during boot but I have placed it in a file instead<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 add any security over entering a passphrase during the initial system start.<br />
<br />
:'''keyfile.randomtext:'''<br />
::fjqweifj830149-57 819y4my1- 38t1934yt8-91m 34co3;t8y;9p3y-<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 />
:'''keyfile.binary:'''<br />
::where any binary file, images, text, video could be chosen as the keyfile<br />
<br />
This is a binary file that has been defined as a keyfile. When identifying files as candidates for a keyfile, it is recommended to choose files that are relatively static such as photos, music, video clips. The benefit of these files is that they serve a dual function which can make them harder to identify as keyfiles. Instead of having a text file with a large amount of random text, the keyfile would look like a regular image file or music clip to the casual observer. The disadvantage is that if this file is lost or changed, it will most likely not be possible to access the encrypted volume without a backup passphrase. Additionally, there is a theoretical loss of randomness when compared to a randomly generated text file. This is due to the fact that images, videos and music have some intrinsic relationship between neighboring bits of data that does not exist for a text file. However this is controversial and has never been exploited publicly.<br />
<br />
'''Creating a Keyfile with Random Characters'''<br />
<br />
Here {{ic|dd}} is used to generate a keyfile of 2048 bits of random characters.<br />
<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
The usage of {{ic|dd}} is similar to initially wiping the volume with random data prior to encryption. <br />
<br />
{{Warning|Do not use [[badblocks]] here. It only generate a random pattern which just repeats its randomness over and over again.}}<br />
<br />
'''Creating a new LUKS encrypted partition with a Keyfile'''<br />
<br />
When creating a new LUKS encrypted partition, a keyfile may be associated with the partition on its creation using:<br />
<br />
# cryptsetup -c <desired cipher> -s <key size> luksFormat /dev/<volume to encrypt> '''/path/to/mykeyfile'''<br />
<br />
This is accomplished by appending the bold area to the standard cryptsetup command which defines where the keyfile is located.<br />
<br />
==== Adding Additional Passphrases or Keyfiles to a LUKS Encrypted Partition ====<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 slot 0.<br />
Additional keys will occupy slots 1&ndash;7.<br />
<br />
The addition of new keys to an encrypted partition is accomplished using cryptsetup with the {{ic|luksAddKey}} extension.<br />
<br />
# cryptsetup luksAddKey /dev/<encrypted volume> '''/path/to/mykeyfile'''<br />
<br />
Where {{ic|/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 is important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. {{ic|/dev/sdb1}} 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 {{ic|encrypt}} HOOK in the initcpio finds your keyfile, you must 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 the following:<br />
<br />
{{hc|# ls -l /dev/disk/by-label/|<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1}}<br />
<br />
or<br />
<br />
{{hc|# 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 {{ic|/dev/disk/by-label/Keys}}, or if I had wanted to use the UUID I would find {{ic|/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 ({{ic|sdb1}}, {{ic|sdb2}}, ...) but not to the USB device ({{ic|sdb}}) 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 flash drive with a [[udev]] rule. There is 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 is quickly how it goes.<br />
<br />
Get the serial number from your USB flash drive:<br />
lsusb -v | grep -A 5 Vendor<br />
<br />
Create a udev rule for it by adding the following to a file in {{ic|/etc/udev/rules.d/}}, such as {{ic|8-usbstick.rules}}:<br />
KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"<br />
<br />
Replace {{ic|$SYMLINK}} and {{ic|$SERIAL}} with their respective values. {{ic|%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 {{ic|/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. {{ic|/media/sdb1}}<br />
<br />
The keyfile can be of arbitrary content and size. We will 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 device, 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 {{ic|/etc/mkinitcpio.conf}}, one for the drive's file system and one for the codepage. Further if you created a udev rule, you should tell {{ic|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 is assumed that you use a FAT formatted USB drive. 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 />
Additionally, insert the {{ic|usb}} hook somewhere before the {{ic|encrypt}} hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
If you have a non-US keyboard, it might prove useful to load your keyboard layout before you are prompted to enter the password to unlock the root partition at boot. For this, you will need the {{ic|keymap}} hook before {{ic|encrypt}}.<br />
<br />
Generate a new image (maybe you should backup a copy of your old kernel26.img first):<br />
mkinitcpio -g /boot/initramfs-linux.img<br />
<br />
==== Storing the key as a plain (visible) file ====<br />
Be sure to choose a plain name for your key &ndash; a bit of 'security through obscurity' is always nice ;-). Avoid using dotfiles (hidden files) &ndash; the {{ic|encrypt}} hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your {{ic|/boot/grub/menu.lst}} ([[GRUB]]). It should look something like this:<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes {{ic|/dev/usbstick}} is the FAT partition of your choice. Replace it with {{ic|/dev/disk/by-...}} or whatever your device is.<br />
<br />
That is all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We will write the key directly between the Master Boot Record (MBR) and the first partition.<br />
<br />
{{Warning|You should only follow this step if you know what you are doing -- '''it can cause data loss and damage your partitions or MBR on the stick!'''}}<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 do not rely on this too much), so you would have to replace {{ic|seek<nowiki>=</nowiki>4}} with {{ic|seek<nowiki>=</nowiki>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 />
''Optional''<br />
If you do not know if you have 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 {{ic|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 {{ic|/boot/grub/menu.lst}} file (GRUB); it should look something like this:<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usb:2048:2048<br />
Format for the {{ic|cryptkey}} option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
{{ic|OFFSET}} and {{ic|SIZE}} match in this example, but this is just coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usb:8192:2048<br />
That is all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
=== Encrypting the Swap partition ===<br />
<br />
==== Without suspend-to-disk 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 />
Append a similar line to {{ic|/etc/crypttab}} to set up a randomly encrypted swap partition:<br />
<br />
<device-mapper name> <swap physical partition> SWAP "-c aes-xts-plain -h whirlpool -s 512"<br />
<br />
Where:<br />
<br />
:*{{ic|<device-mapper name>}} represents the name you want to use as label in /etc/fstab<br />
:*{{ic|<swap physical partition>}} should be the ID of the actual partition. <br> {{Warning|You should use IDs here because if there are multiple hard drives installed in the system, their naming order (sda, sdb,...) can occasionally be scrambled upon boot and thus the swap would be created over a valuable file system, destroying its content. {{ic|<nowiki>ls -l /dev/disk/*/* | grep sdl7</nowiki>}} should help you to find the desired partition.}}<br />
:*{{ic|SWAP}} identifies the partition as a swap partition<br />
:*{{ic|-c}} defines a cipher<br />
:*{{ic|-h}} defines a hash algorithm<br />
:*{{ic|-s}} defines the key size<br />
<br />
Example line (where {{ic|/dev/sdl7}} is the physical partition and {{ic|<nowiki>LABEL=swap</nowiki>}} the desired label):<br />
<br />
swap /dev/disk/by-id/scsi-SATA_Hitachi_HDS7220_JK1130YAGX0R1T-part7 SWAP "-c aes-xts-plain -h whirlpool -s 512"<br />
<br />
:Maps {{ic|/dev/sdl7}} to {{ic|/dev/mapper/swap}} as a swap partition which we can now add in {{ic|/etc/fstab}} like a normal swap.<br />
<br />
If the partition chosen for swap was previously a LUKS partition, crypttab will not overwrite the partition to create a swap partition. This is a safety measure to prevent data loss from accidental mis-identification of the swap partition in crypttab. In order to use such a partition the LUKS header must be removed. This can be accomplished with:<br />
<br />
# dd if=/dev/zero of=/dev/sdl7 bs=1M<br />
<br />
==== With suspend-to-disk support ====<br />
{{Warning|Do not use this setup with a key file. Please read about the issue reported [[Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure|here]]}}<br />
<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 pre-existent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before {{ic|/etc/crypttab}} can be used, it is required to create a hook in {{ic|/etc/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 />
* Format the partition you want to use as swap with the {{ic|cryptsetup}} command. For performance reasons, you might want to use different ciphers with different key sizes.<br />
<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check the result with:<br />
<br />
# cryptsetup luksDump /dev/<device><br />
<br />
* Open the partition in {{ic|/dev/mapper}}:<br />
<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
<br />
* Create a swap filesystem inside the mapped partition:<br />
<br />
# mkswap /dev/mapper/swapDevice<br />
<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in {{ic|/etc/crypttab}} which uses this device. Now you have to create a hook to open the swap at boot time.<br />
<br />
* Create a hook file containing the open command:<br />
<br />
{{hc|/lib/initcpio/hooks/openswap|<nowiki><br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
</nowiki>}}<br />
<br />
* Then create and edit the hook setup file:<br />
{{hc|/lib/initcpio/install/openswap|<nowiki><br />
# vim: set ft=sh:<br />
build ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
</nowiki>}}<br />
<br />
* Add the hook {{ic|openswap}} in the {{ic|HOOKS}} array in {{ic|/etc/mkinitcpio.conf}}, before {{ic|filesystem}}, but '''after''' {{ic|encrypt}} which is mandatory as well. Do not forget to add the {{ic|resume}} hook between {{ic|openswap}} and {{ic|filesystem}} as well.<br />
<br />
* Regenerate the boot image:<br />
<br />
# mkinitcpio -p linux<br />
<br />
* Add the mapped partition to {{ic|/etc/fstab}} by adding the following line:<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
<br />
* Set up your system to resume from {{ic|/dev/mapper/swapDevice}}. For example, if you use [[GRUB]] with kernel hibernation support, add {{ic|resume<nowiki>=</nowiki>/dev/mapper/swapDevice}} to the kernel line in {{ic|/boot/grub/menu.lst}}. A line with encrypted root and swap partitions can look like this:<br />
<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
<br />
At boot time, the {{ic|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 are placed '''after''' {{ic|openswap}} in the {{ic|HOOKS}} array. Please note that because of initrd opening swap, there is no entry for swapDevice in {{ic|/etc/crypttab}} needed in this case.<br />
<br />
=== Using a swap file for suspend-to-disk support ===<br />
* Choose a mapped partition (e.g. {{ic|/dev/mapper/rootDevice}}) whose mounted filesystem (e.g. {{ic|/}}) contains enough free space to hold the entire contents of your system's RAM. For example, if your system has 4 GiB RAM, then you need at least that much free space on the mounted filesystem of your chosen mapped partition for the swap file.<br />
<br />
* [[HOW_TO:_Create_swap_file#Swap_file_creation | Create the swap file]] (e.g. {{ic|/swapfile}}) inside the mounted filesystem of your chosen mapped partition. Be sure to activate it with {{ic|swapon}} and also add it to your {{ic|/etc/fstab}} file afterward.<br />
<br />
* Set up your system to resume from your chosen mapped partition. For example, if you use [[GRUB]] with kernel hibernation support, add {{ic|resume<nowiki>=</nowiki>}}''your chosen mapped partition'' and {{ic|resume_offset<nowiki>=</nowiki>}}''see calculation command below'' to the kernel line in {{ic|/boot/grub/menu.lst}}. A line with encrypted root partition can look like this:<br />
<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/rootDevice resume_offset=123456789 ro<br />
<br />
You can calculate the {{ic|resume_offset}} of your swap file like this:<br />
<br />
# filefrag -v /swapfile | awk '{if($1==0){print $3}}'<br />
<br />
* Add the {{ic|resume}} hook to your {{ic|etc/mkinitcpio.conf}} file and [[Mkinitcpio#Image_creation_and_activation|rebuild the image]] afterward:<br />
<br />
HOOKS="... encrypt '''resume''' ... filesystems ..."<br />
<br />
== Installing the system ==<br />
Now that {{ic|/dev/mapper/root}} and {{ic|/dev/mapper/home}} 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 steps and go straight to manual configuration.<br />
Instead of choosing the hardware devices ({{ic|/dev/sdaX}}) directly, you have to select the mapper devices created above.<br />
Choose {{ic|/dev/mapper/root}} for your root and {{ic|/dev/mapper/home}} as {{ic|/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 {{ic|/home}} partition. Make sure you mount {{ic|/dev/sda1}} as the {{ic|/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|The {{ic|encrypt}} hook is only needed if your root partition is a ''LUKS'' partition (or a LUKS partition that needs to be mounted ''before'' root). The {{ic|encrypt}} hook is not needed if any other partition (swap, for example) is encrypted. System initialization scripts ({{ic|/etc/rc.sysinit}} and {{ic|/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 {{ic|/etc/mkinitcpio.conf}}. For detailed information about mkinitcpio and its configuration refer to [[Mkinitcpio]]. You have to make sure that your {{ic|HOOKS}} array in {{ic|/etc/mkinitcpio.conf}} looks something like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the {{ic|encrypt}} hook comes ''before'' the {{ic|filesystems}} hook. 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 {{ic|usb}} before {{ic|encrypt}} because the hooks are run in the order they appear.<br />
If you need support for foreign keymaps for your encryption password, you have to specify the hook {{ic|keymap}} as well. I suggest putting this in {{ic|/etc/mkinitcpio.conf}} immediately before {{ic|encrypt}}.<br />
<br />
If you have a USB keyboard, you will need the {{ic|usbinput}} hook in {{ic|/etc/mkinitcpio.conf}}. Without it, no USB keyboard will work in early userspace.<br />
<br />
If your root partition is a ''LUKS'' partition, add the used filesystem to the {{ic|MODULES}} section.<br />
MODULES="... ext3 ext4 xfs ..."<br />
<br />
=== Install Bootloader ===<br />
'''[[GRUB]]:''' You have to make some small changes to the entries generated by the installer by replacing {{ic|/dev/mapper/root}} with {{ic|/dev/sda3}}. The important point to remember here is to use the same {{ic|cryptdevice}} name you assigned when you initially unlocked your device. In this example, the device name is {{ic|cryptroot}}; customize yours accordingly:<br />
<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:cryptroot root=/dev/mapper/cryptroot ro<br />
initrd /initramfs-linux.img<br />
<br />
For kernels older than 2.6.37, the syntax is:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' Edit the Arch Linux section in {{ic|/etc/lilo.conf}} and include a line for the {{ic|append}} option, over the initrd, with the {{ic|root<nowiki>=</nowiki>/dev/sda3}} parameter. The {{ic|append}} section makes the same kernel line as in GRUB. Also, you can omit the {{ic|root}} option above the {{ic|image}} option. The section looks like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz-linux<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /initramfs-linux.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note|If you want to use a USB flash drive with a keyfile, you have to append the {{ic|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 {{ic|/etc/crypttab}} file so you do not have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. {{ic|/home}}, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
<br />
Add the following line for the {{ic|/home}} partition<br />
{{Note|Using a passphrase to decrypt LUKS partitions automatically from {{ic|/etc/crypttab}} is deprecated: see http://www.mail-archive.com/arch-projects@archlinux.org/msg02115.html}}<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 [[#Adding_Additional_Passphrases_or_Keyfiles_to_a_LUKS_Encrypted_Partition|above]].<br />
Then add the following information to the {{ic|/etc/crypttab}} file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
If you used a USB device to store your keyfile, you should have something like this:<br />
home /dev/sda5 /dev/sd*1/keyfile<br />
<br />
Or if the keyfile was stored in the MBR, it should be like this:<br />
home /dev/sda5 /dev/sd*:2048:2048<br />
<br />
{{Box BLUE|Note:|When reading the keyfile from the MBR it should be {{ic|/dev/sdb}} not {{ic|/dev/sdb1}} but if the key is in the filesystem it should still be {{ic|/dev/sdb1}}.}}<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 a LUKS password. Type it in and everything should boot.<br />
Once you have logged in, have a look at your mounted partitions by typing {{ic|mount}}. You should have {{ic|/dev/mapper/root}} mounted at {{ic|/}} and, if you set up a separate encrypted home partition, {{ic|/dev/mapper/home}} mounted at {{ic|/home}}. If you set up encrypted swap, {{ic|swapon -s}} should have {{ic|/dev/mapper/swap}} 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 is not, simply enter your password and press {{keypress|Enter}}.}}<br />
<br />
== Remote unlocking of the root (or other) 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 achieved by running the {{ic|net}} hook along with an [[SSH]] server in initrd. Install the {{AUR|dropbear_initrd_encrypt}} package from the [[Arch User Repository|AUR]] and follow the post-installation instructions. Replace the {{ic|encrypt}} hook with {{ic|dropbear encryptssh}} in {{ic|/etc/mkinitcpio.conf}}. Put the {{ic|net}} hook early in the HOOKS array if your DHCP server takes a long time to lease IP addresses.<br />
<br />
If you would simply like a nice solution to mount other encrypted partitions (such as {{ic|/home}})remotely, you may want to look at [https://bbs.archlinux.org/viewtopic.php?pid=880484 this forum thread].<br />
<br />
{{Note|Acutally trim will not work with this script because it is not yet updated to the latest encrypt hook, so it is not able to parse {{ic|-–allow-discards}} from {{ic|/boot/grub/menu.lst}}. (Version: dropbear_initrd_encrypt 0.8-16). You won't notice any error when using online discard, but you see an error when you try to use {{ic|fstrim}}.For a temporary solution just add {{ic|-–allow-discards}} to every cryptsetup line of {{ic|/lib/initcpio/install/dropbear}}(1 line) and {{ic|/lib/initcpio/hooks/encryptssh}}(3 lines)}}<br />
<br />
== Backup the cryptheader ==<br />
If the header of your encrypted partition gets destroyed, you will not be able to decrypt your data. Therefore, having a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT backing up the cryptheader, but even so it's a single point of failure!<br />
In short, the problem is that LUKS is not aware of the duplicated cryptheader, which contains the master key which is used to encrypt all files on your partition. Of course this master key 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 master key 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]{{Linkrot|2011|09|05}} for further details on this.<br />
<br />
{{Note|You can also back up 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 />
=== Backup ===<br />
==== Manually ====<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 />
==== Using cryptsetup ====<br />
You can also use the luksHeaderBackup command instead:<br />
cryptsetup luksHeaderBackup /dev/sdaX --header-backup-file ./backup.img<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 />
==== Manually ====<br />
Again, you will need to the same values as when backing up:<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
==== Using cryptsetup ====<br />
Or you can use the luksHeaderRestore command:<br />
cryptsetup luksHeaderRestore /dev/sdaX --header-backup-file ./backup.img<br />
<br />
'''Note:''' All the keyslot areas are overwritten; only active keyslots from the backup file are available after issuing this command.<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 />
First, start by creating an encrypted container!<br />
<br />
dd if=/dev/urandom of=/bigsecret bs=1M count=10<br />
<br />
This will create the file {{ic|bigsecret}} with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node {{ic|/dev/loop0}}, so that we can mount/use our container.<br />
<br />
{{Note|If it gives you the error {{ic|/dev/loop0: No such file or directory}}, you need to first load the kernel module with {{ic|modprobe loop}}. These days (Kernel 3.2) loop devices are created on demand. Ask for a new loop device with {{ic|losetup -f}}.}}<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file.<br />
<br />
{{Note|If you get an error like {{ic|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 {{ic|modprobe dm-mod}}.}}<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the device file {{ic|/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 />
=== Encrypt using a key-file ===<br />
Let us 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 {{ic|/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 encrypting your keyfile using your private GPG key and storing an off-site 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 expand our container file with the size of the data we want to add:<br />
<br />
dd if=/dev/urandom bs=1M count=1024 | cat - >> /bigsecret<br />
<br />
Be careful to really use TWO {{ic|>}}, or you will override your current container!<br />
<br />
You could use {{ic|/dev/zero}} instead of {{ic|/dev/urandom}} to significantly speed up the process, but with {{ic|/dev/zero}} your encrypted filesystems will ''not be as secure''. (A better option to create random data quicker than {{ic|/dev/urandom}} is {{ic|frandom}} [https://aur.archlinux.org/packages.php?ID=9869], available from the [[AUR]]).<br />
<br />
Now we have to map the container to the loop device:<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 do not 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 the {{ic|encrypt}} hook '''before''' the {{ic|lvm2}} hook (and those two before the {{ic|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 set up your LVM volumes and then use them as the base for the encrypted partitions. That means, in short, that you have to set up LVM first. Then follow this guide, but replace all occurrences of {{ic|/dev/sdXy}} in the guide with its LVM counterpart. (E.g.: {{ic|/dev/sda5}} -> {{ic|/dev/<volume group name>/home}}).<br />
<br />
Do not forget to add the {{ic|encrypt}} hook in {{ic|/etc/mkinitcpio.conf}} '''before''' the {{ic|lvm2}} hook, if you chose to set up encrypted partitions on '''top''' of LVM. Also remember to change {{ic|USELVM}} in {{ic|/etc/rc.conf}} to {{ic|"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 partition 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 {{ic|/etc/rc.conf}} set {{ic|USELVM}} to {{ic|"yes"}}<br />
* In {{ic|/etc/mkinitcpio.conf}} add the {{ic|encrypt}} hook '''before''' the {{ic|lvm2}} hook in the {{ic|HOOKS}} array, if you set up LVM on top of the encrypted partition.<br />
<br />
That is 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 {{ic|/lib/initcpio/hooks/encrypt}} (the first one to your {{ic|/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 {{ic|/etc/crypttab}} with an external key file (i.e. the keyfile is not on any internal hard drive 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 the order of {{ic|/etc/fstab}} (at least).<br />
<br />
Of course, if the {{Pkg|cryptsetup}} package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking {{ic|/etc/rc.sysinit}} or similar files. Unlike {{ic|/etc/crypttab}}, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
If you want to do this on a software RAID partition, there is one more thing you need to do. Just setting the {{ic|/dev/mdX}} device in {{ic|/lib/initcpio/hooks/encrypt}} is not enough; the {{ic|encrypt}} hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices are not brought up until after the {{ic|encrypt}} hook is run. You can solve this by putting the RAID array in {{ic|/boot/grub/menu.lst}}, like <br />
kernel /boot/vmlinuz-linux md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID, you will notice the similarities with that setup ;-). [[GRUB]] can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz-linux root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM and dm-crypt manually (short version) ===<br />
<br />
==== Notes ====<br />
If you are smart enough for this, you will be smart enough to ignore/replace LVM-specific things if you do not want to use LVM.<br />
<br />
{{Note|This brief uses reiserfs for some of the partitions, so change this accordingly if you want to use a more "normal" file system, like ext4.}}<br />
<br />
==== Partitioning scheme ====<br />
{{ic|/dev/sda1}} -> {{ic|/boot}}<br />
{{ic|/dev/sda2}} -> LVM<br />
<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 />
<br />
==== Install Arch Linux ====<br />
Run {{ic|/arch/setup}}<br />
<br />
==== Configuration ====<br />
<br />
===== /etc/rc.conf =====<br />
Change {{ic|USELVM<nowiki>=</nowiki>"no"}} to {{ic|USELVM<nowiki>=</nowiki>"yes"}}.<br />
<br />
===== /etc/mkinitcpio.conf =====<br />
Put {{ic|lvm2}} and {{ic|encrypt}} (in that order) before {{ic|filesystems}} in the {{ic|HOOKS}} array. Again, note that you are setting encryption on '''top''' of LVM.)<br />
<br />
if you want install the system on a usb stick, you need to put {{ic|usb}} just after {{ic|udev}}.<br />
<br />
===== /boot/grub/menu.lst =====<br />
Change {{ic|root<nowiki>=</nowiki>/dev/hda3}} to {{ic|root<nowiki>=</nowiki>/dev/lvm/root}}.<br />
<br />
For kernel >= 2.6.30, you should change {{ic|root<nowiki>=</nowiki>/dev/hda3}} to the following:<br />
cryptdevice=/dev/lvm/root:root root=/dev/mapper/root<br />
<br />
if you want install the system on a usb stick, you need to add {{ic|lvmdelay<nowiki>=</nowiki>/dev/mapper/lvm-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 rebooting ====<br />
<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 />
<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on LVM on LUKS ===<br />
Make sure your kernel command line 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 />
==Using GPG or OpenSSL Encrypted Keyfiles==<br />
The following forum posts give instructions to use two factor authentication, gpg or openssl encrypted keyfiles [https://bbs.archlinux.org/viewtopic.php?id=120243 System Encryption using LUKS with GPG encrypted keys]:<br />
* GnuPG: [https://bbs.archlinux.org/viewtopic.php?pid=943338#p943338 Post regarding GPG encrypted keys]<br />
* OpenSSL: [https://bbs.archlinux.org/viewtopic.php?pid=947805#p947805 Post regarding OpenSSL encrypted keys]<br />
<br />
Note that:<br />
* If you want to use a GPG encrypted keyfile, you need to use a statically compiled GnuPG version 1.4 or you could edit the hooks and use this AUR package [https://aur.archlinux.org/packages.php?ID=58030 gnupg1]<br />
* It is possible that an update to OpenSSL could break the custom {{ic|ssldec}} mentioned in the second forum post.<br />
<br />
==Securing the unencrypted boot partition==<br />
Referring to an article from the ct-magazine (Issue 3/12, page 146, 01.16.2012 http://www.heise.de/ct/inhalt/2012/03/6/) the following script checks all files under {{ic|/boot}} for changes of SHA-1 hash, inode and occupied blocks on the hard drive. It also checks the MBR.<br />
<br />
The script with installation instructions is available here: ftp://ftp.heise.de/pub/ct/listings/1203-146.zip (Author: Juergen Schmidt, ju at heisec.de; License: GPLv2)<br />
<br />
There is also an AUR package: {{AUR|chkboot}}<br />
<br />
After installation, add {{ic|/usr/local/bin/chkboot.sh &}} to your {{ic|/etc/rc.local}}.<br />
<br />
And as {{ic|/usr/local/bin/chkboot_user.sh}} need to be excuted after login, add it to the autostarts (e.g. under KDE -> System Settings -> Startup and Shutdown -> Autostart)<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Install Arch Linux on top of RAID, LVM2, and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>Airbus001https://wiki.archlinux.org/index.php?title=Udev&diff=208621Udev2012-06-15T05:34:11Z<p>Airbus001: /* Other */</p>
<hr />
<div>[[Category:Hardware detection and troubleshooting]]<br />
[[cs:Udev]]<br />
[[es:Udev]]<br />
[[it:Udev]]<br />
[[ru:Udev]]<br />
[[zh-CN:Udev]]<br />
[[zh-TW:Udev]]<br />
{{Temporary i18n}}<br />
{{Lowercase title}}<br />
<br />
{{ic|udev}} replaces the functionality of both {{Ic|hotplug}} and {{Ic|hwdetect}}.<br />
<br />
''"udev is the device manager for the Linux kernel. Primarily, it manages device nodes in {{ic|/dev}}. It is the successor of devfs and hotplug, which means that it handles the {{ic|/dev}} directory and all user space actions when adding/removing devices, including firmware load."'' Source: [[Wikipedia:Udev|Wikipedia article]]<br />
<br />
udev loads kernel modules by utilizing coding parallelism to provide a potential performance advantage versus loading these modules serially. The modules are therefore loaded asynchronously. The inherent disadvantage of this method is that udev does not always load modules in the same order on each boot. If the machine has multiple block devices, this may manifest itself in the form of device nodes changing designations randomly. For example, if the machine has two hard drives, {{ic|/dev/sda}} may randomly become {{ic|/dev/sdb}}. See below for more info on this.<br />
<br />
{{Note|1=Systemd and udev have been merged upstream. Udev will now be part of a package called {{pkg|systemd-tools}}. This package contains several other standalone tools which can be used without systemd. See [http://www.archlinux.org/news/systemd-tools-replaces-udev/ the announcement].}}<br />
<br />
== About udev rules ==<br />
udev rules written by the administrator go in {{ic|/etc/udev/rules.d/}}, their file name has to end with {{ic|.rules}}. The udev rules shipped with various packages are found in {{ic|/usr/lib/udev/rules.d/}}. If there are two files by the same name under {{ic|/usr/lib}} and {{ic|/etc}}, the ones in {{ic|/etc}} take precedence.<br />
<br />
If you want to learn how to write udev rules, see [http://www.reactivated.net/writing_udev_rules.html Writing udev rules].<br />
<br />
To get a list of all of the attributes of a device you can use to write rules, run this command:<br />
# udevadm info -a -n [device name]<br />
<br />
Replace {{ic|[device name]}} with the device present in the system, such as {{ic|/dev/sda}} or {{ic|/dev/ttyUSB0}}.<br />
<br />
udev automatically detects changes to rules files, so changes take effect immediately without requiring udev to be restarted. However, the rules are not re-triggered automatically on already existing devices, so hot-pluggable devices, such as USB devices, will probably have to be reconnected for the new rules to take effect.<br />
<br />
== UDisks ==<br />
Simply [[pacman|install]] the {{pkg|udisks}} package, and all of your media should be automatically mounted in [[GNOME]] and [[KDE]] SC 4.6. There is no need for any additional rules this way.<br />
As an extra bonus you can remove [[HAL]] if you were only using that for auto mounting purposes.<br />
<br />
=== Automounting UDisks Wrappers ===<br />
A UDisks wrapper has the advantage of being very easy to install and needing no (or minimal) configuration. The wrapper will automatically mount things like CDs and flash drives.<br />
<br />
* [http://igurublog.wordpress.com/downloads/script-devmon/ devmon] - {{AUR|devmon}} is a configuration-less Bash wrapper script for udisks which automatically mounts optical discs and removable drives. It can also selectively automatically start applications or execute commands after mounting, ignore specified devices and volume labels, and unmount removable drives. A git version called {{AUR|devmon-git}} is also available.<br />
* [[udiskie]] - Written in Python. Enables automatic mounting and unmounting by any user.<br />
* {{AUR|udisksevt}} - Written in Haskell. Enables automatic mounting by any user. Designed to be integrated with {{AUR|traydevice}}.<br />
* {{AUR|udisksvm}} - A Python script which uses the udisks dbus interface and {{AUR|traydevice}} to automatically mount removable media and to control in GUI, with mouse clicks in systray, the un-mounting and re-mounting of disks or the ejection of optical disks.<br />
<br />
=== UDisks Shell Functions ===<br />
While UDisks includes a simple method of (un)mounting devices via command-line, it can be tiresome to type the commands out each time. These shell functions will generally shorten and ease command-line usage.<br />
<br />
* [https://bbs.archlinux.org/viewtopic.php?id=109307 udisks_functions] - Written for Bash.<br />
* [https://bbs.archlinux.org/viewtopic.php?id=117674 bashmount] - {{AUR|bashmount}} is a menu-driven Bash script with a configuration file that makes it easy to configure and extend.<br />
<br />
==Other==<br />
* [https://aur.archlinux.org/packages.php?ID=52272 ldm] - A lightweight device mounter [https://bbs.archlinux.org/viewtopic.php?id=125918]<br />
<br />
* You can easily automount and eject removable devices with the combination of [http://www.archlinux.org/packages/extra/x86_64/pmount/ pmount], [http://www.archlinux.org/packages/extra/x86_64/udisks2/ udisks2] , and [http://www.archlinux.org/packages/community/x86_64/spacefm/ spacefm]. Note you have to run spacefm in daemon mode with {{ic|spacefm -d &}} in your startup scripts, {{ic|~/.xinitrc}} or {{ic|~/.xsession}}, to get automounting. You can also mount internal disks by adding them to {{ic|/etc/pmount.allow}}.<br />
<br />
==Tips and tricks==<br />
<br />
=== Accessing Firmware Programmers and USB Virtual Comm Devices ===<br />
The following ruleset will allow normal users (within the "users" group) the ability to access the [http://www.ladyada.net/make/usbtinyisp/ USBtinyISP] USB programmer for AVR microcontrollers and a generic (SiLabs [http://www.silabs.com/products/interface/usbtouart CP2102]) USB to UART adapter and the [http://www.atmel.com/tools/AVRDRAGON.aspx?tab=overview Atmel AVR Dragon] programmer. Adjust the permissions accordingly. Verified as of 2010-02-11.<br />
<br />
{{hc|/etc/udev/rules.d/50-embedded_devices.rules|2=<nowiki><br />
# USBtinyISP Programmer rules<br />
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1781", ATTRS{idProduct}=="0c9f", GROUP="users", MODE="0666"<br />
SUBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="0479", GROUP="users", MODE="0666"<br />
# USBasp Programmer rules http://www.fischl.de/usbasp/<br />
SUBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05dc", GROUP="users", MODE="0666"<br />
<br />
# Mdfly.com Generic (SiLabs CP2102) 3.3v/5v USB VComm adapter<br />
SUBSYSTEMS=="usb", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", GROUP="users", MODE="0666"<br />
<br />
#Atmel AVR Dragon (dragon_isp) rules<br />
SUBSYSTEM=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2107", GROUP="users", MODE="0666"<br />
</nowiki>}}<br />
<br />
=== Execute on USB Insert ===<br />
See [[Execute_on_usb_insert|execute on usb insert]] article or the [http://igurublog.wordpress.com/downloads/script-devmon/ devmon wrapper script].<br />
<br />
=== Mount internal drives as a normal user ===<br />
If you want to mount an internal drive in KDE or Gnome (maybe on other Desktop Environments too) as a normal user (without the need to type your superuser password), you just have to create the following file in [[PolicyKit]] Local Authority:<br />
{{hc|/etc/polkit-1/localauthority/50-local.d/50-filesystem-mount-system-internal.pkla|2=<nowiki><br />
[Mount a system-internal device]<br />
Identity=*<br />
Action=org.freedesktop.udisks.filesystem-mount-system-internal<br />
ResultActive=yes<br />
</nowiki>}}<br />
{{Note|You might need to replace 'udisks' with 'udisks2' in case the newer version is used.}}<br />
<br />
=== Mark internal SATA-Ports as eSATA-Ports ===<br />
If you connected a eSATA bay or an other eSATA adapter the system will still recognize this disk as an internal SATA drive. Gnome and KDE will ask you for your root password all the time. The following rule will mark the specified SATA-Port as an external eSATA-Port. With that, a normal Gnome user can connect their eSATA drives to that port like a USB drive, without any root password and so on.<br />
<br />
{{hc|/etc/udev/rules.d/10-esata.rules|2=<nowiki><br />
DEVPATH=="/devices/pci0000:00/0000:00:1f.2/host4/*", ENV{UDISKS_SYSTEM_INTERNAL}="0"<br />
</nowiki>}}<br />
<br />
{{Note| The DEVPATH can be found after connection the eSata drive with the following command (replace sdb to your needs):<br />
<br />
# find /sys/devices/ -name sdb<br />
/sys/devices/pci0000:00/0000:00:1f.2/host4/target4:0:0/4:0:0:0/block/sdb<br />
<br />
}}<br />
<br />
=== Setting static device names ===<br />
Because udev loads all modules asynchronously, they are initialized in a different order. This can result in devices randomly switching names. Udev rule can be added to use static device names.<br />
<br />
==== Network device ====<br />
For example, with two network cards, you may notice a switching of designations between {{Ic|eth0}} and {{Ic|eth1}}.<br />
<br />
One method for network card ordering is to use the udev-sanctioned method of statically-naming each interface. Create the following file to bind the MAC address of each of your cards to a certain interface name:<br />
{{hc|/etc/udev/rules.d/10-network.rules|2=<nowiki><br />
SUBSYSTEM=="net", ATTR{address}=="aa:bb:cc:dd:ee:ff", NAME="lan0"<br />
SUBSYSTEM=="net", ATTR{address}=="ff:ee:dd:cc:bb:aa", NAME="wlan0"<br />
</nowiki>}}<br />
<br />
A couple things to note:<br />
* To get the MAC address of each card, use this command: {{Ic|<nowiki>udevadm info -a -p /sys/class/net/<yourdevice> | grep address | tr [A-Z] [a-z]</nowiki>}}<br />
* Make sure to use the lower-case hex values in your udev rules. It doesn't like upper-case.<br />
* Some people have problems naming their interfaces after the old style: eth0, eth1, etc. Try something like "lan" or "wlan" if you experience this problem.<br />
<br />
Don't forget to update your {{ic|/etc/rc.conf}} and other configuration files using the old ethX notation!<br />
<br />
{{Note|With a recent version of udev, this problem should be solved automatically thanks to the {{ic|/usr/lib/udev/write_net_rules}} program which runs the {{ic|75-persistent-net-generator.rules}} script which produces a {{ic|70-persistent-net.rules}}.}}<br />
<br />
==== iscsi device ====<br />
Test the output from scsi_id:<br />
/usr/lib/udev/scsi_id --whitelisted --replace-whitespace --device=/dev/sdb<br />
3600601607db11e0013ab5a8e371ce111<br />
<br />
{{hc|/etc/udev/rules.d/75-iscsi.rules|<nowiki><br />
# the iscsi device rules<br />
# this will create an iscsi device for each of the targets<br />
KERNEL=="sd*", SUBSYSTEM=="block", PROGRAM="/usr/lib/udev/scsi_id --whitelisted --replace-whitespace /dev/$name", RESULT=="3600601607db11e0013ab5a8e371ce111",<br />
NAME="isda"<br />
</nowiki>}}<br />
<br />
== Troubleshooting ==<br />
=== Blacklisting Modules ===<br />
In rare cases, udev can make mistakes and load the wrong modules. To prevent it from doing this, you can blacklist modules. Once blacklisted, udev will never load that module. See [[blacklisting]]. Not at boot-time ''or'' later on when a hotplug event is received (eg, you plug in your USB flash drive).<br />
<br />
=== udevd hangs at boot ===<br />
After migrating to LDAP or updating an LDAP-backed system udevd can hang at boot at the message "Starting UDev Daemon". This is usually caused by udevd trying to look up a name from LDAP but failing, because the network is not up yet. The solution is to ensure that all system group names are present locally.<br />
<br />
Extract the group names referenced in udev rules and the group names actually present on the system:<br />
<br />
# fgrep -r GROUP /etc/udev/rules.d/ /usr/lib/udev/rules.d | perl -nle '/GROUP\s*=\s*"(.*?)"/ && print $1;' | sort | uniq > udev_groups<br />
# cut -f1 -d: /etc/gshadow /etc/group | sort | uniq > present_groups<br />
<br />
To see the differences, do a side-by-side diff:<br />
<br />
# diff -y present_groups udev_groups<br />
...<br />
network <<br />
nobody <<br />
ntp <<br />
optical optical<br />
power | pcscd<br />
rfkill <<br />
root root<br />
scanner scanner<br />
smmsp <<br />
storage storage<br />
...<br />
<br />
In this case, the pcscd group is for some reason not present in the system. Add the missing groups:<br />
<br />
# groupadd pcscd<br />
<br />
Also, make sure local resources are looked up before resorting to LDAP. {{ic|/etc/nsswitch.conf}} should contain the line<br />
<br />
group: files ldap<br />
<br />
=== Known Problems with Hardware ===<br />
==== BusLogic devices can be broken and will cause a freeze during startup ====<br />
This is a kernel bug and no fix has been provided yet.<br />
<br />
==== Some devices, that should be treated as removable, are not ====<br />
Create a custom udev rule, setting {{ic|UDISKS_SYSTEM_INTERNAL<nowiki>=</nowiki>0}}. For more details, see the manpage of udisks.<br />
<br />
=== Known Problems with Auto-Loading ===<br />
==== CPU frequency modules ====<br />
The current detection method for the various CPU frequency controllers is inadequate, so this has been omitted from the auto-loading process for the time being. To use [[CPU Frequency Scaling]], load the proper module explicitly in your {{Ic|MODULES}} array in {{ic|/etc/rc.conf}}. Further reading: [[rc.conf]].<br />
<br />
==== Sound Problems or Some Modules Not Loaded Automatically ====<br />
Some users have traced this problem to old entries in {{ic|/etc/modprobe.d/sound.conf}}. Try cleaning that file out and trying again.<br />
{{Note|Since {{Ic|udev>&#61;171}}, the OSS emulation modules ({{Ic|snd_seq_oss, snd_pcm_oss, snd_mixer_oss}}) are not automatically loaded by default.}}<br />
<br />
=== Known Problems for Custom Kernel Users ===<br />
==== Udev doesn't start at all ====<br />
Make sure you have a kernel version later than or equal to 2.6.32. Earlier kernels do not have the necessary uevent stuff that udev needs for auto-loading.<br />
<br />
=== IDE CD/DVD-drive support ===<br />
Starting with version 170, udev doesn't support CD-ROM/DVD-ROM drives, which are loaded as traditional IDE drives with the {{Ic|ide_cd_mod}} module and show up as {{ic|/dev/hd*}}. The drive remains usable for tools which access the hardware directly, like cdparanoia, but is invisible for higher userspace programs, like KDE.<br />
<br />
A cause for the loading of the ide_cd_mod module prior to others, like sr_mod, could be e.g. that you have for some reason the module piix loaded with your initramfs. In that case you can just replace it with ata_piix in your {{ic|/etc/mkinitcpio.conf}}.<br />
<br />
=== Optical Drives Have Group ID Set To Disk ===<br />
If the group ID of your optical drive is set to ''disk'' and you want to have it set to ''optical'' you have to create a custom udev rule:<br />
{{hc|/etc/udev/rules.d|2=# permissions for IDE CD devices<br />
SUBSYSTEMS=="ide", KERNEL=="hd[a-z]", ATTR{removable}=="1", ATTRS{media}=="cdrom*", GROUP="optical"<br />
<br />
# permissions for SCSI CD devices<br />
SUBSYSTEMS=="scsi", KERNEL=="s[rg][0-9]*", ATTRS{type}=="5", GROUP="optical"}}<br />
<br />
==See also==<br />
* [http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html Udev Homepage]<br />
* [http://www.linux.com/news/hardware/peripherals/180950-udev An Introduction to Udev]<br />
* [http://vger.kernel.org/vger-lists.html#linux-hotplug Udev mailing list information]</div>Airbus001https://wiki.archlinux.org/index.php?title=XDM&diff=204594XDM2012-06-12T18:06:23Z<p>Airbus001: /* XDM loops back to itself after login */</p>
<hr />
<div>[[Category:Display managers]]<br />
{{i18n|XDM}}<br />
{{Article summary start}}<br />
{{Article summary text|XDM is the X Display Manager.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Display Manager}}<br />
{{Article summary end}}<br />
<br />
From [http://www.xfree86.org/current/xdm.1.html XDM manual page]:<br />
<br />
:''Xdm manages a collection of X displays, which may be on the local host or remote servers. The design of xdm was guided by the needs of X terminals as well as The Open Group standard XDMCP, the X Display Manager Control Protocol. Xdm provides services similar to those provided by init, getty and login on character terminals: prompting for login name and password, authenticating the user, and running a "session."''<br />
<br />
XDM provides a simple and straightforward graphical login prompt.<br />
<br />
==Installation==<br />
<br />
Install {{Pkg|xorg-xdm}}, available in the [[Official Repositories]].<br />
<br />
Use default launch script '''~/.xsession'''<br />
Make the {{ic|~/.xsession}} file executable.<br />
$ cp /etc/skel/.xsession /etc/skel/.xinitrc ~ # use default launch script<br />
Or use a simple line (assume your favorite windows manager is 'openbox')<br />
$ echo exec openbox > ~/.xsession <br />
$ chmod 744 ~/.xsession<br />
<br />
If you would also like to use an Arch Linux theme for XDM, you can optionally install the {{Pkg|xdm-archlinux}} package, also available in the Official Repositories.<br />
<br />
See [[Display Manager]] for additional information.<br />
<br />
==Background wallpaper==<br />
<br />
Here are some tips to make [[XDM]] look nicer:<br />
<br />
* Install the Quick Image Viewer:<br />
{{bc|# pacman -S qiv}}<br />
<br />
* Make a directory to store background images. (e.g. {{ic|/root/backgrounds}} or {{ic|/usr/local/share/backgrounds}})<br />
<br />
* Place your images in the directory. If you do not have any try [http://www.digitalblasphemy.com/] for starters.<br />
<br />
* Edit {{ic|/etc/X11/xdm/Xsetup_0}}. Change the {{ic|xconsole}} command to:<br />
/usr/bin/qiv -zr /root/backgrounds/*<br />
<br />
* Edit {{ic|/etc/X11/xdm/Xresources}}. Add/replace the following defines:<br />
xlogin'''greetFont: -adobe-helvetica-bold-o-normal--20-'''-'''-'''-'''-'''-iso8859-1<br />
xlogin'''font: -adobe-helvetica-medium-r-normal--14-'''-'''-'''-'''-'''-iso8859-1<br />
xlogin'''promptFont: -adobe-helvetica-bold-r-normal--14-'''-'''-'''-'''-'''-iso8859-1<br />
xlogin'''failFont: -adobe-helvetica-bold-r-normal--14-'''-'''-'''-'''-'''-iso8859-1<br />
xlogin*frameWidth: 1<br />
xlogin*innerFramesWidth: 1<br />
xlogin*logoPadding: 0<br />
xlogin*geometry: 300x175-0-0<br />
Comment out the logo defines:<br />
#xlogin*logoFileName: /usr/X11R6/lib/X11/xdm/pixmaps/xorg.xpm<br />
#xlogin*logoFileName: /usr/X11R6/lib/X11/xdm/pixmaps/xorg-bw.xpm<br />
<br />
For the exact meaning of the definitions, see the man page of xdm.<br />
<br />
* Update {{ic|/etc/pacman.conf}} so the changes do not get erased:<br />
~NoUpgrade = etc/X11/xdm/Xsetup_0 etc/X11/xdm/Xresources<br />
<br />
The changes will now give you a random wallpaper image and move the login prompt to the bottom-right edge of the screen.<br />
<br />
==Multiple X sessions & Login in the window==<br />
<br />
With the [[Xdmcp]] enable, you can easily run multiple X sessions simultaneously on the same machine.<br />
{{bc|# X -query ip_xdmcp_server :2 }}<br />
<br />
This will launch the second session, in window you need {{Pkg|xorg-server-xephyr}}<br />
{{bc|# Xephyr -query this_machine_ip :2 }}<br />
<br />
==Troubleshooting==<br />
<br />
===XDM loops back to itself after login===<br />
<br />
The current version of the {{Pkg|xorg-xdm}} package, available in the [[Official Repositories]] is patched to register sessions with [[ConsoleKit]] by default. If ConsoleKit is not running, XDM will fail to succesfully launch an X session. [[D-Bus]] can be used invoke ConsoleKit when called upon by XDM.<br />
<br />
Make sure that the {{pkg|dbus}} package, available in the [[Official Repositories]] is [[pacman|installed]] and then make sure {{ic|dbus}} is included in the {{ic|[[Daemon#Starting_on_Boot|DAEMONS]]}} array in {{ic|/etc/[[rc.conf]]}}.<br />
<br />
Also, make sure that you are actually starting your window manager, for example with the command {{ic|xmonad}} in {{ic|~/.xsession}}, and that {{ic|~/.xsession}} has the correct permissions of {{ic|774}}.<br />
<br />
===XDM does not update login records===<br />
<br />
The vanilla config of XDM calls {{ic|/etc/X11/xdm/GiveConsolve}} for the startup of display :0, whereas otherwise it calls {{ic|/etc/X11/xdm/Xstartup}}. Since only the latter contains a call to {{ic|/usr/bin/sessreg}}, the login record {{ic|/var/run/utmp}} is not updated for a login on display :0. As a consequence, the output of {{ic|who}} does not necessarily list the user after login through XDM. This was already discussed in the bug report [https://bugs.archlinux.org/task/26395 FS#26395].<br />
<br />
As a simple fix, append the following line to {{ic|/etc/X11/xdm/GiveConsole}}:<br />
exec /usr/bin/sessreg -a -w /var/log/wtmp -u /var/run/utmp -x /etc/X11/xdm/Xservers -l $DISPLAY -h "" $USER<br />
<br />
This change also enables the {{ic|getuser}} function presented in [[Acpid#Getting_user_name_of_the_current_display|Acpid]] to work.</div>Airbus001https://wiki.archlinux.org/index.php?title=XDM&diff=204593XDM2012-06-12T18:05:46Z<p>Airbus001: /* XDM loops back to itself after login */</p>
<hr />
<div>[[Category:Display managers]]<br />
{{i18n|XDM}}<br />
{{Article summary start}}<br />
{{Article summary text|XDM is the X Display Manager.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Display Manager}}<br />
{{Article summary end}}<br />
<br />
From [http://www.xfree86.org/current/xdm.1.html XDM manual page]:<br />
<br />
:''Xdm manages a collection of X displays, which may be on the local host or remote servers. The design of xdm was guided by the needs of X terminals as well as The Open Group standard XDMCP, the X Display Manager Control Protocol. Xdm provides services similar to those provided by init, getty and login on character terminals: prompting for login name and password, authenticating the user, and running a "session."''<br />
<br />
XDM provides a simple and straightforward graphical login prompt.<br />
<br />
==Installation==<br />
<br />
Install {{Pkg|xorg-xdm}}, available in the [[Official Repositories]].<br />
<br />
Use default launch script '''~/.xsession'''<br />
Make the {{ic|~/.xsession}} file executable.<br />
$ cp /etc/skel/.xsession /etc/skel/.xinitrc ~ # use default launch script<br />
Or use a simple line (assume your favorite windows manager is 'openbox')<br />
$ echo exec openbox > ~/.xsession <br />
$ chmod 744 ~/.xsession<br />
<br />
If you would also like to use an Arch Linux theme for XDM, you can optionally install the {{Pkg|xdm-archlinux}} package, also available in the Official Repositories.<br />
<br />
See [[Display Manager]] for additional information.<br />
<br />
==Background wallpaper==<br />
<br />
Here are some tips to make [[XDM]] look nicer:<br />
<br />
* Install the Quick Image Viewer:<br />
{{bc|# pacman -S qiv}}<br />
<br />
* Make a directory to store background images. (e.g. {{ic|/root/backgrounds}} or {{ic|/usr/local/share/backgrounds}})<br />
<br />
* Place your images in the directory. If you do not have any try [http://www.digitalblasphemy.com/] for starters.<br />
<br />
* Edit {{ic|/etc/X11/xdm/Xsetup_0}}. Change the {{ic|xconsole}} command to:<br />
/usr/bin/qiv -zr /root/backgrounds/*<br />
<br />
* Edit {{ic|/etc/X11/xdm/Xresources}}. Add/replace the following defines:<br />
xlogin'''greetFont: -adobe-helvetica-bold-o-normal--20-'''-'''-'''-'''-'''-iso8859-1<br />
xlogin'''font: -adobe-helvetica-medium-r-normal--14-'''-'''-'''-'''-'''-iso8859-1<br />
xlogin'''promptFont: -adobe-helvetica-bold-r-normal--14-'''-'''-'''-'''-'''-iso8859-1<br />
xlogin'''failFont: -adobe-helvetica-bold-r-normal--14-'''-'''-'''-'''-'''-iso8859-1<br />
xlogin*frameWidth: 1<br />
xlogin*innerFramesWidth: 1<br />
xlogin*logoPadding: 0<br />
xlogin*geometry: 300x175-0-0<br />
Comment out the logo defines:<br />
#xlogin*logoFileName: /usr/X11R6/lib/X11/xdm/pixmaps/xorg.xpm<br />
#xlogin*logoFileName: /usr/X11R6/lib/X11/xdm/pixmaps/xorg-bw.xpm<br />
<br />
For the exact meaning of the definitions, see the man page of xdm.<br />
<br />
* Update {{ic|/etc/pacman.conf}} so the changes do not get erased:<br />
~NoUpgrade = etc/X11/xdm/Xsetup_0 etc/X11/xdm/Xresources<br />
<br />
The changes will now give you a random wallpaper image and move the login prompt to the bottom-right edge of the screen.<br />
<br />
==Multiple X sessions & Login in the window==<br />
<br />
With the [[Xdmcp]] enable, you can easily run multiple X sessions simultaneously on the same machine.<br />
{{bc|# X -query ip_xdmcp_server :2 }}<br />
<br />
This will launch the second session, in window you need {{Pkg|xorg-server-xephyr}}<br />
{{bc|# Xephyr -query this_machine_ip :2 }}<br />
<br />
==Troubleshooting==<br />
<br />
===XDM loops back to itself after login===<br />
<br />
The current version of the {{Pkg|xorg-xdm}} package, available in the [[Official Repositories]] is patched to register sessions with [[ConsoleKit]] by default. If ConsoleKit is not running, XDM will fail to succesfully launch an X session. [[D-Bus]] can be used invoke ConsoleKit when called upon by XDM.<br />
<br />
Make sure that the {{pkg|dbus}} package, available in the [[Official Repositories]] is [[pacman|installed]] and then make sure {{ic|dbus}} is included in the {{ic|[[Daemon#Starting_on_Boot|DAEMONS]]}} array in {{ic|/etc/[[rc.conf]]}}.<br />
<br />
Also, make sure that you are actually starting your window manager, for example with the command {{ic|xmonad}} in {{ic|~/.xsession}}, and that {{ic|~/.xsession}} has the correct permissions(774).<br />
<br />
===XDM does not update login records===<br />
<br />
The vanilla config of XDM calls {{ic|/etc/X11/xdm/GiveConsolve}} for the startup of display :0, whereas otherwise it calls {{ic|/etc/X11/xdm/Xstartup}}. Since only the latter contains a call to {{ic|/usr/bin/sessreg}}, the login record {{ic|/var/run/utmp}} is not updated for a login on display :0. As a consequence, the output of {{ic|who}} does not necessarily list the user after login through XDM. This was already discussed in the bug report [https://bugs.archlinux.org/task/26395 FS#26395].<br />
<br />
As a simple fix, append the following line to {{ic|/etc/X11/xdm/GiveConsole}}:<br />
exec /usr/bin/sessreg -a -w /var/log/wtmp -u /var/run/utmp -x /etc/X11/xdm/Xservers -l $DISPLAY -h "" $USER<br />
<br />
This change also enables the {{ic|getuser}} function presented in [[Acpid#Getting_user_name_of_the_current_display|Acpid]] to work.</div>Airbus001