NSLU2-Linux
view · edit · print · history

HowTo.CreateAnEncryptedFilesystem History

Hide minor edits - Show changes to markup

August 12, 2008, at 09:03 PM by fcarolo -- fixed false wikilnks
Changed line 205 from:

With the cryptsetup package from Debian/Etch you can also easily set up an encrypted fileserver. And with the CryptoNAS (http://cryptonas.org) you have a nice webinterface for managing all the disks. But encryption is very slow (~700KB/s). Update: ARM packages are now available for CryptoNAS?.

to:

With the cryptsetup package from Debian/Etch you can also easily set up an encrypted fileserver. And with the CryptoNAS (http://cryptonas.org) you have a nice webinterface for managing all the disks. But encryption is very slow (~700KB/s). Update: ARM packages are now available for CryptoNAS.

August 09, 2008, at 08:49 PM by friscosystemausfallorg -- Update: CryptoNAS ARM package now available
Changed line 205 from:

With the cryptsetup package from Debian/Etch you can also easily set up an encrypted fileserver. And with the CryptoNAS (http://cryptonas.org) you have a nice webinterface for managing all the disks. But encryption is very slow (~700KB/s). Update: there are currently no arm packages available for CryptoNAS?.

to:

With the cryptsetup package from Debian/Etch you can also easily set up an encrypted fileserver. And with the CryptoNAS (http://cryptonas.org) you have a nice webinterface for managing all the disks. But encryption is very slow (~700KB/s). Update: ARM packages are now available for CryptoNAS?.

January 02, 2008, at 11:17 AM by me -- cryptobox/nas name change, update
Changed line 205 from:

With the cryptsetup package from Debian/Etch you can also easily set up an encrypted fileserver. And with the CryptoBox (http://cryptobox.org) you have a nice webinterface for managing all the disks. But encryption is very slow (~700KB/s).

to:

With the cryptsetup package from Debian/Etch you can also easily set up an encrypted fileserver. And with the CryptoNAS (http://cryptonas.org) you have a nice webinterface for managing all the disks. But encryption is very slow (~700KB/s). Update: there are currently no arm packages available for CryptoNAS?.

August 08, 2007, at 11:32 PM by Harald Biehl -- ipkg --install kernel-module-loop
Added lines 36-38:

(loop.tar.gz didn't work for me, i used ipkg --install kernel-module-loop and it works fine. HB)

August 08, 2007, at 11:04 PM by Harald Biehl -- copy loop.o to /lib/modules
Changed lines 34-35 from:

Log on as root and copy your downloaded losetup into /opt/sbin

to:

Log on as root and copy your downloaded losetup into /opt/sbin and loop.o into /lib/modules

May 15, 2007, at 02:19 PM by fcarolo -- fixed false wiki links
Changed lines 5-6 from:

So you've got your wizzy slug serving all your data, hosting all your MP3s?, pictures and maybe even videos. Then the worst happens, some guy breaks into your home.

to:

So you've got your wizzy slug serving all your data, hosting all your MP3s, pictures and maybe even videos. Then the worst happens, some guy breaks into your home.

Changed lines 9-11 from:

Before you know it, your harddisk containing your MP3s?, pictures and all that private data is being sold at a local pub.

to:

Before you know it, your harddisk containing your MP3s, pictures and all that private data is being sold at a local pub.

Changed lines 28-29 from:

You NSLU2 need to be running uNSLUng v6.x or OpenSLUG?.

to:

You NSLU2 need to be running uNSLUng v6.x or OpenSLUG.

Changed line 45 from:

Create a file of random data. This will be the container of the encrypted filing system (change count to be the size of the filing system in MBytes?, i.e. in this case am creating a 100MByte container)...[@

to:

Create a file of random data. This will be the container of the encrypted filing system (change count to be the size of the filing system in MBytes, i.e. in this case am creating a 100MByte container)...[@

Changed line 198 from:

Using Debian/Etch LE also AES128? via loopback works (with unslung you wont get it work unfortunately yet).

to:

Using Debian/Etch LE also AES128 via loopback works (with unslung you wont get it work unfortunately yet).

Changed line 202 from:

With the cryptsetup package from Debian/Etch you can also easily set up an encrypted fileserver. And with the CryptoBox? (http://cryptobox.org) you have a nice webinterface for managing all the disks. But encryption is very slow (~700KB/s).

to:

With the cryptsetup package from Debian/Etch you can also easily set up an encrypted fileserver. And with the CryptoBox (http://cryptobox.org) you have a nice webinterface for managing all the disks. But encryption is very slow (~700KB/s).

May 11, 2007, at 11:56 PM by me -- usage of cryptsetup
Changed lines 199-202 from:

Speed is roughly 1.1 MB/sec over a network. That is still quite workable, though it might get tight for video streaming in HQ.

to:

Speed is roughly 1.1 MB/sec over a network. That is still quite workable, though it might get tight for video streaming in HQ.

Another way is using "cryptsetup"

With the cryptsetup package from Debian/Etch you can also easily set up an encrypted fileserver. And with the CryptoBox? (http://cryptobox.org) you have a nice webinterface for managing all the disks. But encryption is very slow (~700KB/s).

February 11, 2007, at 06:07 PM by mas -- spelling
Changed lines 197-198 from:

''And AES also works: Using Debian/Etch LE also AES128? via loopback works (not with the unslung modules unfortunately).

to:

And AES also works:

Using Debian/Etch LE also AES128? via loopback works (with unslung you wont get it work unfortunately yet).

February 11, 2007, at 06:06 PM by mas -- AES addition
Added lines 196-199:

''And AES also works: Using Debian/Etch LE also AES128? via loopback works (not with the unslung modules unfortunately). Speed is roughly 1.1 MB/sec over a network. That is still quite workable, though it might get tight for video streaming in HQ.

April 23, 2006, at 08:31 PM by JamesCC --
Changed line 91 from:

losetup –d /dev/loop0

to:

losetup -d /dev/loop0

Changed lines 123-124 from:

grep –l hello /home/clearfile /home/cryptfile grep –l afile /home/clearfile /home/cryptfile

to:

grep -l hello /home/clearfile /home/cryptfile grep -l afile /home/clearfile /home/cryptfile

Changed line 135 from:

Control. Just copying between two files on /dev/sdb1 (or /dev/sda1) ...

to:

Control. Just copying between two directories both on a native file system...

Changed line 163 from:

$ time cp c:/file .

to:

$ time cp c:/file n:/

Changed line 167 from:

$ time cp file c:/

to:

$ time cp n:/file c:/

Changed line 170 from:

Test 3. Reading and writing across network. Clearfile mounted on loopback.

to:

Test 3. Reading and writing across network. Clearfile mounted on loopback (not encrypted)...

Changed line 173 from:

$ time cp c:/file .

to:

$ time cp c:/file n:/Encrypted

Changed line 178 from:

$ time cp file c:/

to:

$ time cp n:/Encrypted/file c:/

Changed line 182 from:

Test 4. Reading and writing across network. Cryptfile mounted on loopback (XOR).

to:

Test 4. Reading and writing across network. Cryptfile mounted on loopback (XOR)...

Changed line 185 from:

$ time cp c:/file .

to:

$ time cp c:/file n:/Encrypted

Changed line 190 from:

$ time cp file c:/

to:

$ time cp n:/Encrypted/file c:/

April 23, 2006, at 08:23 PM by JamesCC --
Changed lines 7-8 from:

He doesn’t recognise the slug and probably discards that as something too technical to bother with, but he does recognise the attached USB harddisk. He’s seen those in PC world he knows he can probably get some money for that.

to:

He doesn’t recognise the slug and probably discards that as something too technical to bother with, but he does recognise the attached USB harddisk. He’s seen those in PC World he knows he can probably get some money for that.

Changed lines 19-25 from:

Use a loopback device on an uNSLUng v6 slug to mount a file (yes this doesn’t need to be an openslug). We will use XOR encryption which is fast, and easy to protect the filing system in the file. You will need to mount this filing system using the command line, but this only needs to be done when the slug is rebooted (with only two commands).

XOR encryption is weak, and can be easily broken by people looking to crack it. The method of encryption only protects against speculative attacks, that is people who will plug in your harddisk just to see what is there. You need to be technical and know something about cryptoanalysis to break it. For me this will guard against 99.999% of situations (most thieves aren’t really after your data, they want to make money from selling your stuff).

XOR encryption is fast, is easy to implement. Remember the slug is not a Pentium, we don’t have a lot of CPU cycles to play with. With a little work, other more secure encryption algorithms could be used (this is being done with openslug devices), but probably at a very noticeable performance hit.

to:

Use a loopback device on an uNSLUng v6 slug to mount a file (yes this doesn’t need to be an openslug). We will use XOR encryption which is fast, and easy to protect the filing system in the file. You will need to mount this filing system using the command line, but this only needs to be done when the slug is rebooted (with only two commands).

XOR encryption is weak, and can be easily broken by people looking to crack it. The method of encryption only protects against speculative attacks, that is people who will plug in your harddisk just to see what is there. You need to be technical and know something about cryptoanalysis to break it. For me this will guard against 99.999% of situations (most thieves aren’t really after your data, they want to make money from selling your stuff).

XOR encryption is fast, is easy to implement. Remember the slug is not a Pentium, we don’t have a lot of CPU cycles to play with. With a little work, other more secure encryption algorithms could be used (this is being done with openslug devices), but probably at a very noticeable performance hit.

Changed line 30 from:

You need a command called losetup. I couldn’t find this in any packages for the uNSLUng release (it's not in busybox or unix coreutils pkg), but you can find it here on the Yahoo nslu2-linux website...

to:

You need a command called losetup. I couldn’t find this in any packages for the uNSLUng release (it's not in busybox or unix coreutils pkg), but you can find it here on the Yahoo nslu2-linux website...

Changed line 51 from:

Setup the loop device (the –e 1 selects xor encryption)...[@

to:

Setup the loop device (the –e 1 selects xor encryption)...[@

Changed lines 53-55 from:

@]...And enter your password (you are asked only once – make sure it is right).

Create your filing system (this shouldn’t take more than a minute or two as it doesn’t need to parse the whole container file)...[@

to:

@]...And enter your password (you are asked only once – make sure it is right).

Create your filing system (this shouldn’t take more than a minute or two as it doesn’t need to parse the whole container file)...[@

Changed lines 61-62 from:

@](if you are worried about spindown of harddisks, you may wish to pass the –noat (no access time) option as well)

to:

@](if you are worried about spindown of harddisks, you may wish to pass the –noat (no access time) option as well)

Changed line 68 from:

ln –s /mnt/loopback encrypted

to:

ln –s /mnt/loopback encrypted

Changed lines 80-82 from:

(this seems to automatically disconnect the loopback device, i.e. you don’t need to do losetup –d /dev/loop0)

to:

(this seems to automatically disconnect the loopback device, i.e. you don’t need to do losetup –d /dev/loop0)

Changed line 91 from:

losetup –d /dev/loop0

to:

losetup –d /dev/loop0

Changed line 117 from:

losetup /dev/loop0 /home/clearfile # note no –e option

to:

losetup /dev/loop0 /home/clearfile # note no –e option

Changed lines 123-124 from:

grep –l hello /home/clearfile /home/cryptfile grep –l afile /home/clearfile /home/cryptfile

to:

grep –l hello /home/clearfile /home/cryptfile grep –l afile /home/clearfile /home/cryptfile

Changed lines 131-135 from:

I’ve not done an extensive test, but my experience shows that read and write performance on my system appears to be about halved. I have a slug that has been modified to OverClockTheSlug (i.e. running at full speed).

My test to was to copy a 50Mbytes file full of random bytes (random is important as there appears to be some speed up with files with zeros in them). This is done via a terminal on the slug itself to eliminate network effects (I wanted to assess the impact of the XOR operation). Look at the first time (real) as I’m not sure I trust the values returned by user and (in particular) sys.

Control. Just copying between two files on /dev/sdb1 (or /dev/sda1) ...[@

to:

I’ve not done extensive tests, but my experience shows that read and write performance with XOR loopback is incurs a delay of 1 second for every 2Mbytes of data. I have a slug that has been modified to OverClockTheSlug (i.e. running at full speed).

My test to was to copy a 50Mbytes file full of random bytes (random is important as there appears to be some speed up with files with zeros in them). For the first set of tests, this is done via a terminal on the slug itself to eliminate network effects (I wanted to assess the impact of the XOR operation). The second set are over my 100Mbit network.

Control. Just copying between two files on /dev/sdb1 (or /dev/sda1) ... [@

Changed line 138 from:

real 0m12.072s user 0m0.050s sys 0m5.430s

to:

real 0m12.072s

Changed lines 143-144 from:

real 0m13.679s user 0m0.100s sys 0m4.880s

to:

real 0m13.679s

Changed line 146 from:

real 0m13.480s user 0m0.050s sys 0m5.370s

to:

real 0m13.480s

Changed lines 151-152 from:

real 0m34.888s user 0m0.040s sys 0m5.040s

to:

real 0m34.888s

Changed line 154 from:

real 0m36.775s user 0m0.090s sys 0m4.150s

to:

real 0m36.775s

Added lines 157-196:

And here are the results over my 100Mbit network...

Control. Just reading and writing across the network (NSLU2 drive is on N:) to/from native filesystem.

James Covey-Crump@Custard /cygdrive/n
$ time cp c:/file .
real    1m25.097s

James Covey-Crump@Custard /cygdrive/n
$ time cp file c:/
real    0m9.533s

Test 3. Reading and writing across network. Clearfile mounted on loopback.

James Covey-Crump@Custard /cygdrive/n/Encrypted
$ time cp c:/file .
real    1m27.015s
(extra 1.91s - 25Mbytes/s for loopback WRITING)

James Covey-Crump@Custard /cygdrive/n/Encrypted
$ time cp file c:/
real    0m10.925s
(extra 1.42s - 35Mbytes/s for loopback READING)

Test 4. Reading and writing across network. Cryptfile mounted on loopback (XOR).

James Covey-Crump@Custard /cygdrive/n/Encrypted
$ time cp c:/file .
real    1m49.958s
(extra 24.86s - 2Mbytes/s for XOR and loopback WRITING)

James Covey-Crump@Custard /cygdrive/n/Encrypted
$ time cp file c:/
real    0m34.855s
(extra 25.32s - 2Mbytes/s for XOR and loopback READING)

This suggests to me that using loopback has little affect on speed, but the NSLU can only XOR at 2Mbytes a second.

April 22, 2006, at 05:07 PM by JamesCC --
Changed lines 32-33 from:

(credit goes to hd_de_2000). This program (found in most distributions of linux) is used to setup loopback devices. You need it to setup the encryption options.

to:

(credit goes to Helmut Dersch). This program (found in most distributions of linux) is used to setup loopback devices. You need it to setup the encryption options.

Deleted line 89:
Changed lines 92-94 from:

@]...before starting again (you obviously don’t need to insmod loop again)

to:

@]...before repeating the losetup and mount commands.

Changed lines 133-134 from:

My test to was to copy a 50Mbytes file full of random bytes (random is important as there appears to be some speed up with files with zeros in them). This is done via a terminal on the slug itself to eliminate network effects. Look at the first time (real) as I’m not sure I trust the values returned by user and (in particular) sys.

to:

My test to was to copy a 50Mbytes file full of random bytes (random is important as there appears to be some speed up with files with zeros in them). This is done via a terminal on the slug itself to eliminate network effects (I wanted to assess the impact of the XOR operation). Look at the first time (real) as I’m not sure I trust the values returned by user and (in particular) sys.

April 22, 2006, at 11:45 AM by JamesCC --
Changed lines 61-62 from:

@](you may wish to pass the –noat option as well)

to:

@](if you are worried about spindown of harddisks, you may wish to pass the –noat (no access time) option as well)

April 22, 2006, at 11:43 AM by JamesCC --
Changed line 45 from:

Create a file of random data. This will be the container of the encrypted filing system (change count to be the size of the filing system divided by 1Kbytes, i.e. in this case am creating a 4MByte container)...[@

to:

Create a file of random data. This will be the container of the encrypted filing system (change count to be the size of the filing system in MBytes?, i.e. in this case am creating a 100MByte container)...[@

April 22, 2006, at 11:09 AM by JamesCC --
Changed lines 89-90 from:

]@

to:

@]

Changed lines 98-101 from:

Backing up is very strongly recommended for encrypted filing systems. Lots of things can go wrong. As operations are more complicated, there is a possibility of a risk of typos in commands, or maybe even crashes, and then of course the more likely possibility that you forget a password.

You can backup your system as normal, however you are likely to have made the container files be very large (to allow lots of room for storage). As a result your backup jobs could become much longer (as when you update a file in the container, the whole container file has now changed). A better policy is not to backup your container files, but instead to backup the contents of the containers via the mounted point (i.e. backup /mnt/loopback as used above).

to:

Backing up is very strongly recommended for encrypted filing systems. Lots of things can go wrong. As operations are more complicated, there is a possibility of typos in commands, or maybe even crashes (seems reliable to me, but I've not tested it for long). Then of course the more likely possibility that you forget a password or do something daft to the container file.

You can backup your system as normal, however you are likely to have made the container files be very large (to allow lots of room for storage). As a result your backup jobs could become much longer (as when you update a file in the container, the whole container file has now changed and is then copied across). A better policy is not to backup your container files, but instead to backup the contents of the containers via the mounted point (i.e. backup /mnt/loopback as used above).

Added line 108:
Changed lines 148-149 from:

(no difference)

to:
Changed lines 156-157 from:

(just over twice as long)

to:
April 22, 2006, at 11:04 AM by JamesCC --
Changed lines 28-29 from:

You need a command called losetup. I couldn’t find this in any packages for the uNSLUng release. You can find it here (yahoo message... 8537). This program (found in most distributions of linux) is used to setup loopback devices. You need it to setup the encryption options.

to:

You NSLU2 need to be running uNSLUng v6.x or OpenSLUG?.

You need a command called losetup. I couldn’t find this in any packages for the uNSLUng release (it's not in busybox or unix coreutils pkg), but you can find it here on the Yahoo nslu2-linux website... http://groups.yahoo.com/group/nslu2-linux/message/8537 (credit goes to hd_de_2000). This program (found in most distributions of linux) is used to setup loopback devices. You need it to setup the encryption options.

Changed lines 57-58 from:

@]

to:

@](unnervingly I did experience one crash here, but after a reboot it was fine).

Changed line 67 from:

Make links to it from your existing accounts / samba shares. cd to your accound or share[@

to:

Make links to it from your existing accounts / samba shares. cd to your accound or share and...[@

Changed line 91 from:

If you got the password wrong you will get an error when trying to mount. You will need to then.. [@

to:

If you got the password wrong you will get an error when trying to mount. You will need to then need to disconnect the loopback device by... [@

Changed lines 98-101 from:

Backing up is very strongly recommended for encrypted filing systems. Lots of things can go wrong. These start with the fact the operations are more complicated leading the risk of typos in commands, or maybe even crashes, and of course there is always the risk of forgetting a password.

You can backup your system as normal, however as the container files will be very large. As a result your backup jobs could become much longer (as when you update a file in the container, the whole container file has now changed). A better policy is not to backup your container files, but instead to backup the contents of the container via the mounted point (i.e. backup /mnt/loopback as used above).

to:

Backing up is very strongly recommended for encrypted filing systems. Lots of things can go wrong. As operations are more complicated, there is a possibility of a risk of typos in commands, or maybe even crashes, and then of course the more likely possibility that you forget a password.

You can backup your system as normal, however you are likely to have made the container files be very large (to allow lots of room for storage). As a result your backup jobs could become much longer (as when you update a file in the container, the whole container file has now changed). A better policy is not to backup your container files, but instead to backup the contents of the containers via the mounted point (i.e. backup /mnt/loopback as used above).

Changed line 125 from:

]@

to:

@]

Changed lines 131-132 from:

I’ve not done an extensive test, but my experience shows that read and write performance on my system appears to be about halved. I have a slug that has been modified to be “overclocked” (i.e. running at full speed).

to:

I’ve not done an extensive test, but my experience shows that read and write performance on my system appears to be about halved. I have a slug that has been modified to OverClockTheSlug (i.e. running at full speed).

Changed line 135 from:

Control. Just copying between two files on /dev/sdb1...[@

to:

Control. Just copying between two files on /dev/sdb1 (or /dev/sda1) ...[@

Changed line 140 from:

Test 1. Copying to and from the container via the loopback device without XOR encryption...[@

to:

Test 1. Copying to and from the container via the loopback device without XOR encryption...[@

Changed lines 147-148 from:

Test 2. Copying to and from the (encrypted) container via the loopback device with XOR encryption...[@

to:

(no difference)

Test 2. Copying to and from the (encrypted) container via the loopback device with XOR encryption...[@

Changed lines 156-157 from:
to:

(just over twice as long)

April 22, 2006, at 10:45 AM by JamesCC --
Changed line 72 from:

To unmount the encrypted filing system.[@

to:

To unmount the encrypted filing system...[@

Changed line 81 from:

insmod loop

to:

[@insmod loop

Changed lines 85-86 from:

If you got the password wrong you will get an error when trying to mount. You will need to then…

to:

]@

If you got the password wrong you will get an error when trying to mount. You will need to then.. [@

Changed lines 89-91 from:

..before starting again (you obviously don’t need to insmod loop again)

to:

@]...before starting again (you obviously don’t need to insmod loop again)

Changed lines 103-104 from:

Well here was my little test…

to:

Well here was my little test... [@

Changed line 121 from:
to:

]@

Changed line 131 from:

Control. Just copying between two files on /dev/sdb1…

to:

Control. Just copying between two files on /dev/sdb1...[@

Changed lines 134-136 from:

Test 1. Copying to and from the container via the loopback device without XOR encryption…

to:

@]

Test 1. Copying to and from the container via the loopback device without XOR encryption...[@

Changed lines 142-144 from:

Test 2. Copying to and from the (encrypted) container via the loopback device with XOR encryption…

to:

@]

Test 2. Copying to and from the (encrypted) container via the loopback device with XOR encryption...[@

Changed lines 150-151 from:
to:

@]

April 22, 2006, at 10:43 AM by JamesCC --
Changed line 32 from:

You will need to…

to:

You will need to...[@

Changed lines 34-36 from:

… to install the loop module, that is to install the loopback feature into the kernel.

to:

@]... to install the loop module, that is to install the loopback feature into the kernel.

Changed line 41 from:

Create a file of random data. This will be the container of the encrypted filing system (change count to be the size of the filing system divided by 1Kbytes, i.e. in this case am creating a 4MByte container)…

to:

Create a file of random data. This will be the container of the encrypted filing system (change count to be the size of the filing system divided by 1Kbytes, i.e. in this case am creating a 4MByte container)...[@

Changed lines 43-44 from:
to:

@]

Changed line 47 from:

Setup the loop device (the –e 1 selects xor encryption)…

to:

Setup the loop device (the –e 1 selects xor encryption)...[@

Changed lines 49-51 from:

And enter your password (you are asked only once – make sure it is right).

Create your filing system (this shouldn’t take more than a minute or two as it doesn’t need to parse the whole container file)…

to:

@]...And enter your password (you are asked only once – make sure it is right).

Create your filing system (this shouldn’t take more than a minute or two as it doesn’t need to parse the whole container file)...[@

Changed lines 53-54 from:

Mount the new (encrypted) filing system…

to:

@]

Mount the new (encrypted) filing system...[@

Changed lines 57-59 from:

(you may wish to pass the –noat option as well)

Check everything is ok

to:

@](you may wish to pass the –noat option as well)

Check everything is ok[@

Changed lines 61-63 from:

Make links to it from your existing accounts / samba shares. cd to your accound or share

to:

@]

Make links to it from your existing accounts / samba shares. cd to your accound or share[@

Changed lines 65-66 from:
to:

@]

Changed line 72 from:

To unmount the encrypted filing system.

to:

To unmount the encrypted filing system.[@

Changed lines 74-77 from:

(this seems to automatically disconnect the loopback device, i.e. you don’t need to do losetup –d /dev/loop0)

to:

@]

(this seems to automatically disconnect the loopback device, i.e. you don’t need to do losetup –d /dev/loop0)

April 22, 2006, at 10:36 AM by JamesCC --
Changed lines 1-4 from:

Creating an encrypted filesystem on uNSLUg (or OpenSlug for that matter)

Why?

to:

Creating an encrypted filesystem on uNSLUg (or OpenSlug for that matter)

Why?

Changed lines 12-13 from:

What to do about it

to:

What to do about it

Changed lines 17-18 from:

How: The Objective

to:

How: The Objective

Changed lines 26-27 from:

Get all you need

to:

Get all you need

Changed lines 37-38 from:

Creating a system

to:

Creating a system

Changed lines 67-68 from:

Unmounting

to:

Unmounting

Changed lines 75-76 from:

Upon next bootup (or to remount after unmounting)

to:

Upon next bootup (or to remount after unmounting)

Changed lines 87-88 from:

A comment on Backing Up

to:

A comment on Backing Up

Changed lines 96-97 from:

Does it work?

to:

Does it work?

Changed lines 120-121 from:

Performance

to:

Performance

April 22, 2006, at 10:33 AM by JamesCC -- Creating an encrypted filesystem on uNSLUg (or OpenSlug for that matter)
Added lines 1-146:

Creating an encrypted filesystem on uNSLUg (or OpenSlug for that matter)

Why?

So you've got your wizzy slug serving all your data, hosting all your MP3s?, pictures and maybe even videos. Then the worst happens, some guy breaks into your home.

He doesn’t recognise the slug and probably discards that as something too technical to bother with, but he does recognise the attached USB harddisk. He’s seen those in PC world he knows he can probably get some money for that.

Before you know it, your harddisk containing your MP3s?, pictures and all that private data is being sold at a local pub.

What to do about it

Well you can add a measure of protection by using a encrypted file system. Only you can access the information on the disk via a password (or key).

How: The Objective

Use a loopback device on an uNSLUng v6 slug to mount a file (yes this doesn’t need to be an openslug). We will use XOR encryption which is fast, and easy to protect the filing system in the file. You will need to mount this filing system using the command line, but this only needs to be done when the slug is rebooted (with only two commands).

XOR encryption is weak, and can be easily broken by people looking to crack it. The method of encryption only protects against speculative attacks, that is people who will plug in your harddisk just to see what is there. You need to be technical and know something about cryptoanalysis to break it. For me this will guard against 99.999% of situations (most thieves aren’t really after your data, they want to make money from selling your stuff).

XOR encryption is fast, is easy to implement. Remember the slug is not a Pentium, we don’t have a lot of CPU cycles to play with. With a little work, other more secure encryption algorithms could be used (this is being done with openslug devices), but probably at a very noticeable performance hit.

Get all you need

You need a command called losetup. I couldn’t find this in any packages for the uNSLUng release. You can find it here (yahoo message... 8537). This program (found in most distributions of linux) is used to setup loopback devices. You need it to setup the encryption options.

Log on as root and copy your downloaded losetup into /opt/sbin

You will need to… insmod loop … to install the loop module, that is to install the loopback feature into the kernel.

Creating a system

Create mount point for the new encrypted filing system mkdir /mnt/loopback

Create a file of random data. This will be the container of the encrypted filing system (change count to be the size of the filing system divided by 1Kbytes, i.e. in this case am creating a 4MByte container)… dd if=/dev/urandom of=/home/cryptfile bs=1M count=100

Warning! This can take some time to create as /dev/urandom is not that fast. You may wish to log in on another session to monitor its progress (it took 15/20mins for my 1Gbyte file to be made).

Setup the loop device (the –e 1 selects xor encryption)… losetup -e 1 /dev/loop0 /home/cryptfile And enter your password (you are asked only once – make sure it is right).

Create your filing system (this shouldn’t take more than a minute or two as it doesn’t need to parse the whole container file)… mkfs.ext3 /dev/loop0

Mount the new (encrypted) filing system… mount -t ext3 /dev/loop0 /mnt/loopback/ (you may wish to pass the –noat option as well)

Check everything is ok ls /mnt/loopback/

Make links to it from your existing accounts / samba shares. cd to your accound or share ln –s /mnt/loopback encrypted

All done.

Unmounting

To unmount the encrypted filing system. umount /mnt/loopback/

(this seems to automatically disconnect the loopback device, i.e. you don’t need to do losetup –d /dev/loop0)

Upon next bootup (or to remount after unmounting)

insmod loop losetup -e 1 /dev/loop0 /home/cryptfile (enter your password) mount -t ext3 /dev/loop0 /mnt/loopback/

If you got the password wrong you will get an error when trying to mount. You will need to then… losetup –d /dev/loop0 ..before starting again (you obviously don’t need to insmod loop again)

A comment on Backing Up

Backing up is very strongly recommended for encrypted filing systems. Lots of things can go wrong. These start with the fact the operations are more complicated leading the risk of typos in commands, or maybe even crashes, and of course there is always the risk of forgetting a password.

You can backup your system as normal, however as the container files will be very large. As a result your backup jobs could become much longer (as when you update a file in the container, the whole container file has now changed). A better policy is not to backup your container files, but instead to backup the contents of the container via the mounted point (i.e. backup /mnt/loopback as used above).

Of course you may wish to add encryption to what you are backing up and thankfully there are two loopback devices (so you can use two at once, /dev/loop0 and /dev/loop1).

Does it work?

Well here was my little test…

dd if=/dev/urandom of=/home/cryptfile bs=4096 count=1024 losetup -e 1 /dev/loop0 /home/cryptfile mkfs.ext3 /dev/loop0 mount -t ext3 /dev/loop0 /mnt/loopback/ echo hello > /mnt/loopback/afile umount /mnt/loopback/

dd if=/dev/zero of=/home/clearfile bs=4096 count=1024 losetup /dev/loop0 /home/clearfile # note no –e option mkfs.ext3 /dev/loop0 mount -t ext3 /dev/loop0 /mnt/loopback/ echo hello > /mnt/loopback/afile umount /mnt/loopback/

grep –l hello /home/clearfile /home/cryptfile grep –l afile /home/clearfile /home/cryptfile

(notice that you only see the data in the clearfile and not the cryptfile)

Performance

I’ve not done an extensive test, but my experience shows that read and write performance on my system appears to be about halved. I have a slug that has been modified to be “overclocked” (i.e. running at full speed).

My test to was to copy a 50Mbytes file full of random bytes (random is important as there appears to be some speed up with files with zeros in them). This is done via a terminal on the slug itself to eliminate network effects. Look at the first time (real) as I’m not sure I trust the values returned by user and (in particular) sys.

Control. Just copying between two files on /dev/sdb1… [root@CC-NAS1?] home> time cp test/file test/file2 real 0m12.072s user 0m0.050s sys 0m5.430s

Test 1. Copying to and from the container via the loopback device without XOR encryption… [root@CC-NAS1?] home> time cp test/file /mnt/loopback/file2 real 0m13.679s user 0m0.100s sys 0m4.880s

[root@CC-NAS1?] home> time cp /mnt/loopback/file2 test/file real 0m13.480s user 0m0.050s sys 0m5.370s

Test 2. Copying to and from the (encrypted) container via the loopback device with XOR encryption… [root@CC-NAS1?] home> time cp test/file /mnt/loopback/file2 real 0m34.888s user 0m0.040s sys 0m5.040s

[root@CC-NAS1?] home> time cp /mnt/loopback/file2 test/file real 0m36.775s user 0m0.090s sys 0m4.150s

view · edit · print · history · Last edited by fcarolo.
Based on work by friscosystemausfallorg, me, Harald Biehl, fcarolo, mas, and JamesCC.
Originally by JamesCC.
Page last modified on August 12, 2008, at 09:03 PM