rootninja

How to create an encrypted volume on top of a regular file system in Fedora using ecryptfs.

Install ecryptfs if it’s not already on your system.

$ sudo yum install ecryptfs-utils

If you want to use a key and a password, follow the next set of steps. If you just want to use a password, you can skip the ecryptfs-manager section and jump right to making the directory.

$ sudo ecryptfs-manager

eCryptfs key management menu
-------------------------------
        1. Add passphrase key to keyring
        2. Add public key to keyring
        3. Generate new public/private keypair
        4. Exit

Make selection:

Generate a new public/private keypair

Select key type to use for newly created files:
 1) openssl
Selection:

Choose openssl, accept the default path to write out the key.pem file.

SSL key file path [/home/ninja/.ecryptfs/pki/openssl/key.pem]:

Choose a passphrase if you want (something you know), or just leave it blank to rely solely on the key (something you have).

Passphrase:
Returning to main menu

Exit the management menu.

Now make and mount the encrypted volume.

Create a directory where you want to store encrypted data. I’ll make a folder called crypt_vol in my home directory.

$ mkdir ~/encrypted_vol

$ sudo mount -t ecryptfs ~/crypt_vol ~/crypt_vol

Select key type to use for newly created files:
 1) openssl
 2) passphrase
 3) tspi
Selection:

Choose your key.pem location, if you created it with the default, you can just hit enter here because it should be the default here too.

PEM key file [/home/ninja/.ecryptfs/pki/openssl/key.pem]:

Now you have to provide the password you used when you made the public/private keypair. If you didn’t create a password, choose openssl_passwd and just leave it empty. (the default option below)

Method of providing the passphrase:
 1) openssl_passwd: Enter on Console
 2) openssl_passwd_file: File Containing Passphrase
 3) openssl_passwd_fd: File Descriptor for File Containing Passphrase
Selection [openssl_passwd]:
Passphrase:

Choose your favorite encryption cipher, aes…

Select cipher:
 1) aes: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
 2) blowfish: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
 3) des3_ede: blocksize = 8; min keysize = 24; max keysize = 24 (not loaded)
 4) cast6: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
 5) cast5: blocksize = 8; min keysize = 5; max keysize = 16 (not loaded)
Selection [aes]:

Pick the default key size of 16.

Select key bytes:
 1) 16
 2) 32
 3) 24
Selection [16]:

If you want to store a mix of encrypted and unencrypted files under the same area, choose plaintext passthrough, otherwise choose the default, no. I suggest an all or nothing approach, as it can get confusing as to which files are encrypted especially when they’re binary! (With ascii text files you can just cat a file and tell if it’s encrypted or not.)

Enable plaintext passthrough (y/n) [n]:

The first time you create and mount something, you will get this message:

WARNING: Based on the contents of [/root/.ecryptfs/sig-cache.txt],
it looks like you have never mounted with this key
before. This could mean that you have typed your
passphrase wrong.

Would you like to proceed with the mount (yes/no)? yes
Would you like to append sig [fa0757b1] to
[/home/ninja/.ecryptfs/sig-cache.txt] yes

If all went well, you’ll see one last message before returning to your shell.

Successfully appended new sig to user sig cache file
Mounted eCryptfs

Now when you check your mounts, you should see the encrypted volume overlaying one of your other file systems. In my case, I have an ext3 home partition with the encrypted volume on part of it. Anything you put under /home/ninja/crypt_vol will be encrypted. When you unmount crypt_vol, you will still be able to see the directories and file names, but the contents of everything will be scrambled.

/dev/sda4 on /home type ext3 (rw)
/home/ninja/crypt_vol on /home/ninja/crypt_vol type ecryptfs
(rw,ecryptfs_sig=fa0757b1,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs,)

Since i’m not using a password at all, i’ll move the key.pem to a remote mount and link it back in place, or i’ll make the pki directory a mount point on some remote disk (via nfs probably). If the computer ever gets stolen, the encrypted volume will not be mountable. This is just one example of how to use keys and/or passphrases to protect your encrypted data. If you’re not going to put the key.pem on a remote mount or provide a passphrase, you should consider the encryption worthless since anyone using your machine will be able to find your key and mount the volume after a little searching around.

Linux, howto, security ecryptfs, encryption, fedora, key, mount, pki, private, public

If you submit an SSL certificate request for your Apache/Lighttpd web server to a Certificate Authority (CA) on a Windows Domain Controller, you might have to convert your resulting binary DER formatted Security Certificate into PEM so Apache or Lighttpd can understand it.

Convert a certificate from DER to PEM

# openssl x509 –in input.crt –inform DER –out output.crt –outform PEM

Convert a certificate from PEM to DER

# openssl x509 –in input.crt –inform PEM –out output.crt –outform DER

Convert a key from DER to PEM

# openssl rsa –in input.key –inform DER –out output.key –outform PEM

Convert a key from PEM to DER

# openssl rsa –in input.key –inform PEM –out output.key –outform DER

If you’re using Lighttpd, concatenate the key and pem cert so they’re both in one file. If your key has a password (openssl probably forced you to supply a password when you created the request), then you need to strip the password from it first unless you don’t mind having to supply the password every time you start the web server. I know most people don’t stop/start their server very often, but what about in a power failure, or in a remote location?

# openssl rsa -in server.key.original -out server.key.nopass
Enter pass phrase for server.key.original:
writing RSA key

howto, security certificate, der, key, openssl, pem, RSA, ssl, x509

This doesn’t have to be complicated at all.  This was what I did on my ldap servers:

That’s it!  No messing with the CA.pl script or running multiple openssl commands for requests, signings, password stripping, and catting keys/crts together.  I tested my LDAP implementation like this and it worked like a charm.  Having a copy of both certificates located at /etc/openldap/cacerts/ on both machines worked for me.  When I set up clients, I put the certs in their cacerts directory and they work just fine with start tls.  If you’re doing this for an openldap implementation, you can make sure it’s working using “ldapsearch -x -ZZ” which requires your encryption to work.

http://blog.rootninja.com/wp-content/uploads/2008/09/rootninja_80×151.jpg“>http://blog.rootninja.com/wp-content/uploads/2008/09/rootninja_80×151.jpg” alt=”root|ninja” width=”80″ height=”15″ />

Linux cert, key, ldap, openldap, openssl, pki, self-signed certificate, ssl, tls