{"id":272,"date":"2011-02-02T14:56:00","date_gmt":"2011-02-02T12:56:00","guid":{"rendered":"https:\/\/www.fussylogic.co.uk\/blog\/?p=272"},"modified":"2012-08-31T09:23:05","modified_gmt":"2012-08-31T08:23:05","slug":"ecryptfs-on-debian-howto","status":"publish","type":"post","link":"https:\/\/www.fussylogic.co.uk\/blog\/?p=272","title":{"rendered":"eCryptFS On Debian Howto"},"content":{"rendered":"<p>This article explains how to get a stacked encrypted directory using the ecryptfs Linux kernel driver, and to transparently automount that directory using the ecryptfs PAM module.<\/p>\n<p>Being \u00e2\u20ac\u0153stacked\u00e2\u20ac\u009d means that the real storage is provided by your existing file system in a nominated directory. That directory is decrypted on the fly once the ecryptfs filesystem is mounted and provides a virtual decrypted view of that storage at the mount point.<\/p>\n<p>Use of the PAM module means that the encrypted directory is secured on your login password.<\/p>\n<h3 id=\"ecryptfs\">Ecryptfs<\/h3>\n<p>Ecryptfs doesn\u00e2\u20ac\u2122t use your login password as the decryption key (if it did, then root could gain access to it by changing your password to something root knows). Instead the login password is used to decrypt your mount passphrase.<\/p>\n<p>Three directories are used<\/p>\n<ul>\n<li>.ecryptfs\/ configuration directory<\/li>\n<li>.Private\/ raw encrypted real files<\/li>\n<li>Private\/ mount point for virtual file system which is the decrypted version of .Private\/<\/li>\n<\/ul>\n<h3 id=\"pam-recap\">PAM Recap<\/h3>\n<ul>\n<li><em>account<\/em> modules are called to check that the requesting account actually exists and is valid. This might include checks for account expiration of time of day access limits.<\/li>\n<li><em>auth<\/em> modules verify the users identity \u00e2\u20ac\u201d they might do this by requesting and checking a password<\/li>\n<li><em>password<\/em> modules are called when <em>updating<\/em> the password.<\/li>\n<li><em>session<\/em> modules are called to perform actions at the beginning and end of a session. A session being defined as starting after the user successfully authenticates.<\/li>\n<\/ul>\n<h3 id=\"installation\">Installation<\/h3>\n<pre><code>apt-get install ecryptfs-utils\n<\/code><\/pre>\n<p>This will automatically pull in libecryptfs0. It will also automatically add the PAM module to<\/p>\n<ul>\n<li>\/etc\/pam.d\/common-account (although this is commented out)<\/li>\n<li>\/etc\/pam.d\/common-auth<\/li>\n<li>\/etc\/pam.d\/common-password<\/li>\n<li>\/etc\/pam.d\/common-session<\/li>\n<li>\/etc\/pam.d\/common-session-noninteractive<\/li>\n<\/ul>\n<p>The <em>auth<\/em> ecryptfs PAM module takes a copy of the password used to log in. The <em>session<\/em> ecryptfs PAM module uses that password to unwrap the mount passphrase for the encrypted directory, and mount the plaintext virtual directory; similarly it unmounts that directory on logout. The <em>password<\/em> module rewraps the mount passphrase when the user changes their own password (note it doesn\u00e2\u20ac\u2122t do this when root changes the user\u00e2\u20ac\u2122s password).<\/p>\n<h3 id=\"setup\">Setup<\/h3>\n<p>You begin by running the following when logged in with your user account:<\/p>\n<pre><code>$ ecryptfs-setup-private\nEnter your login passphrase: \nEnter your mount passphrase [leave blank to generate one]: \nEnter your mount passphrase (again): \n\n************************************************************************\nYOU SHOULD RECORD YOUR MOUNT PASSPHRASE AND STORE IT IN A SAFE LOCATION.\n  ecryptfs-unwrap-passphrase ~\/.ecryptfs\/wrapped-passphrase\nTHIS WILL BE REQUIRED IF YOU NEED TO RECOVER YOUR DATA AT A LATER TIME.\n************************************************************************\n\n\nDone configuring.\n\nTesting mount\/write\/umount\/read...\nTesting succeeded.\n\nLogout, and log back in to begin using your encrypted directory.\n<\/code><\/pre>\n<p>First you enter your login password. ecryptfs will use this to wrap the mount passphrase, which you can also specify should you wish, or leave blank to generate something suitable.<\/p>\n<p>This process will generate the following:<\/p>\n<pre><code>Private\/\n|-- Access-Your-Private-Data.desktop -&gt; \/usr\/share\/ecryptfs-utils\/ecryptfs-mount-private.desktop\n`-- README.txt -&gt; \/usr\/share\/ecryptfs-utils\/ecryptfs-mount-private.txt\n.Private\/\n.ecryptfs\/\n|-- auto-mount\n|-- auto-umount\n|-- Private.mnt\n|-- Private.sig\n`-- wrapped-passphrase\n<\/code><\/pre>\n<p>Your mount passphrase is stored in .ecryptfs\/wrapped-passphrase in an encrypted form. You can use your login password to decrypt it, which you enter when prompted:<\/p>\n<pre><code>$ ecryptfs-unwrap-passphrase .ecryptfs\/wrapped-passphrase \nPassphrase: \nf1da8c3eb8a2d13bd327f74c6fb47c91\n<\/code><\/pre>\n<p>Here I\u00e2\u20ac\u2122ve used a generated mount passphrase as I don\u00e2\u20ac\u2122t expect to ever have to type it, other than under very rare circumstances.<\/p>\n<p>Next time you log in the PAM module will automatically mount .Private\/ over Private\/ but you can do the same thing manually from the command line like this<\/p>\n<pre><code>$ ecryptfs-mount-private \nEnter your login passphrase:\nInserted auth tok with sig [551b13b8dcd852e6] into the user session keyring\n<\/code><\/pre>\n<p>This will hide the real Private\/ directory with an ecryptfs mount<\/p>\n<pre><code>$ mount\n\/home\/user\/.Private on \/home\/user\/Private type ecryptfs (ecryptfs_sig=551b13b8dcd852e6,ecryptfs_fnek_sig=6a55078f86383f67,ecryptfs_cipher=aes,ecryptfs_key_bytes=16)\n<\/code><\/pre>\n<p>The directory will be automatically unmounted when you log out, but you can umount manually with:<\/p>\n<pre><code>$ ecryptfs-umount-private\n<\/code><\/pre>\n<p>Note: that the passphrase is not unwrapped when the administrator tries to log in as you:<\/p>\n<pre><code>$ sudo su - user\nkeyctl_search: Required key not available\nPerhaps try the interactive 'ecryptfs-mount-private'\n<\/code><\/pre>\n<p>In this case, because root doesn\u00e2\u20ac\u2122t know the literal password, he is merely using his superuser status to login as \u00e2\u20ac\u0153user\u00e2\u20ac\u009d, the wrapping password isn\u00e2\u20ac\u2122t available so the encrypted directory is not available.<\/p>\n<h3 id=\"updating\">Updating<\/h3>\n<p>When you change your login password, the wrapping password should be updated by the <em>password<\/em> module of the PAM ecryptfs driver. However, if it is not automatically changed at the same time, say because the administrator changed your password rather than you personally, you will have to be able to rewrap your mount passphrase manually.<\/p>\n<p>This is easily done like this:<\/p>\n<pre><code>$ ecryptfs-rewrap-passphrase ~\/.ecryptfs\/wrapped-passphrase\nOld wrapping passphrase: \nNew wrapping passphrase: \n<\/code><\/pre>\n<p>Be careful typing your new password, you will not be asked for it twice. Note that this is <em>not<\/em> the mount passphrase it is your login password.<\/p>\n<h3 id=\"warnings\">Warnings<\/h3>\n<p>Given that root can do anything on the system, the above is no guarantee of security. It would be trivial for root to install a \u00e2\u20ac\u0153login\u00e2\u20ac\u009d program that simply emailed him a copy of your password, so you still have to have a certain level of trust in your administrator.<\/p>\n<p>Also be aware that while you are logged in your encrypted directory is visible to your user account. The administrator could choose to assume your identity at that moment and could still see your encrypted data.<\/p>\n<p>Further, an attacker who gains access to your account while you are logged in can do the same.<\/p>\n<p>In short: encryption won\u00e2\u20ac\u2122t do much to protect a live attack. It will protect you if your computer is stolen, as the data will be inaccessible without the key phrase.<\/p>\n<h3 id=\"manual-directories\">Manual Directories<\/h3>\n<p>Should you wish to make an encrypted directory other than .Private\/ you can do it manually. It\u00e2\u20ac\u2122s simple but not as automated as using ecryptfs-setup-private:<\/p>\n<pre><code>$ mkdir encrypted-source\n$ chmod 700 encrypted-source\n$ mkdir encrypted-dest\n$ sudo mount -t ecryptfs encrypted-source encrypted-dest\nPassphrase: \nSelect cipher: \n 1) aes: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)\n 2) blowfish: blocksize = 16; min keysize = 16; max keysize = 56 (not loaded)\n 3) des3_ede: blocksize = 8; min keysize = 24; max keysize = 24 (not loaded)\n 4) cast6: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)\n 5) cast5: blocksize = 8; min keysize = 5; max keysize = 16 (not loaded)\nSelection [aes]:  \nSelect key bytes: \n 1) 16\n 2) 32\n 3) 24\nSelection [16]: \nEnable plaintext passthrough (y\/n) [n]: \nEnable filename encryption (y\/n) [n]: y\nAttempting to mount with the following options:\n  ecryptfs_unlink_sigs\n  ecryptfs_key_bytes=16\n  ecryptfs_cipher=aes\n  ecryptfs_sig=d7284afb87fef554\nWARNING: Based on the contents of [\/root\/.ecryptfs\/sig-cache.txt],\nit looks like you have never mounted with this key \nbefore. This could mean that you have typed your \npassphrase wrong.\n\nWould you like to proceed with the mount (yes\/no)? : yes\nWould you like to append sig [d7284afb87fef554] to\n[\/root\/.ecryptfs\/sig-cache.txt] \nin order to avoid this warning in the future (yes\/no)? : no\nNot adding sig to user sig cache file; continuing with mount.\nMounted eCryptfs\n<\/code><\/pre>\n<p>Note that defaults were accepts apart from \u00e2\u20ac\u0153Enable filename encryption\u00e2\u20ac\u009d, which you should enable.<\/p>\n<p>You can, should you wish, use an overlay mount and mount the encrypted directory on itself. This will hide the underlying encrypted directory from the filesystem.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>This article explains how to get a stacked encrypted directory using the ecryptfs Linux kernel driver, and to transparently automount that directory using the ecryptfs PAM module. Being \u00e2\u20ac\u0153stacked\u00e2\u20ac\u009d means that the real storage is provided by your existing file system in a nominated directory. That directory is decrypted on the fly once the ecryptfs\u2026 <span class=\"read-more\"><a href=\"https:\/\/www.fussylogic.co.uk\/blog\/?p=272\">Read More &raquo;<\/a><\/span><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[12,13,14,6],"_links":{"self":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts\/272"}],"collection":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=272"}],"version-history":[{"count":4,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts\/272\/revisions"}],"predecessor-version":[{"id":590,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts\/272\/revisions\/590"}],"wp:attachment":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=272"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=272"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=272"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}