Introduction

What is a cryptoloop?

It's a method to encrypt data written to a storage device:

 _________________________
 | applications like vim |
 -------------------------
          ^
          | i/o with files
          |
          v
 _______________________
 | filesystem like xfs |
 -----------------------
          ^
          | i/o with blocks
          |
          v
    _____________
    | cryptoloop | en/decrypts data
    -------------
          ^
          | 
          |
          v
 ________________
 | block device | writes physically
 ----------------

What is it used for?

It's used to achieve higher security. For instance, if you lose your laptop or it gets stolen, nobody will be able to read your (sensitive) data.

Some buzzwords...

You may want to know what cryptoloop uses, how it works. I don't really want to explain that here, but I'll give you some buzzwords you can lookup:

• Linux Kernel v2.6
• Cryptographic API
• Blowfish,AES,MD5,SHA384 and SHA512, ...

Conditions and use-cases

I'll now show you in which situations you can/may use cryptoloop.

regular file

Howto do it:

Create a regular file:

scice% dd if=/dev/urandom of=testcrypt bs=1024 count=1024 1024+0 records in 1024+0 records out 1048576 bytes transferred in 0.059929 seconds (17496971 bytes/sec)

Setup the loop device and enter the password used for encryption:

scice# /sbin/losetup -e blowfish /dev/loop/1 testcrypt Password:

And now access the loop like a standard block device:

scice# mkfs.xfs /dev/loop/1 meta-data=/dev/loop/1 isize=256 agcount=1, agsize=4096 blks = sectsz=512 data = bsize=4096 blocks=4096, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=1200, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0

Look at the cryptoloop:

scice# file -s /dev/loop/1 /dev/loop/1: SGI XFS filesystem data (blksz 4096, inosz 256, v2 dirs)

And look at the file:

scice# file testcrypt testcrypt: data

Remove the cryptoloop:

scice# losetup -d /dev/loop/1

When you mount your encrypted file, you need to specify the password:

scice# mount testcrypt /mnt/ -o loop,encryption=blowfish Password:

So far, so good. You can have as many encrypted loops as loopback devices you have (normally 8).

Benefits: - you can hide your encrypted data within your home (attention: security by obscurity!) - you can create many encrypted files

Disadvantages: - indirect access - slower than partitions / raw devices

optional partition

Having filesystems on files is ugly, as you enforce indirection (application->filesystem->cryptoloop->file->filesystem->blockdevice instead of application->filesystem->cryptoloop->blockdevice).

If you don't have much data which is seldom accessed, you may use an unused partition for that case. Simply replace testcrypt from above with the appropriate partition.

Benefits: - if you don't name the partition in /etc/fstab, perhaps nobody will ever guess you have an encrypted data partition (attention: security by obscurity!) - faster than regular files

Disadvantages: - not very comfortable, as you cannot just type 'mount /mnt/data' - you need to pay attention that you only write to /mnt/data and don't have a prior version on an unencrypted medium, as it is generally possible to restore 'deleted' files

home partition

You may want to generally keep all data on your home directories encrypted. Use this entry in fstab to achieve it:

/dev/discs/disc0/part4 /home xfs loop,encryption=blowfish 0 0

Benefits: - faster than regular files - very comfortable - transparent to your users

Disadvantages: - your data is secured, but do you really know that 'vi' is still vi and not a program calling cp and then vi?

root partition

If you want to encrypt your root (/) partition, you need to pay attention!

To understand why, I give you a small explanation about how booting works:

___________________
| hardware checks | like BIOS on x86
-------------------
         ^
         |
         v
___________________
|    bootloader   | like grub,lilo,milo
-------------------
         ^
         |
         v
___________________
|      kernel     | Linux hopefully
-------------------
         ^
         |
         v
___________________
| (sysV) init      | or cinit, minit or runit,
-------------------  which all are loaded from the root filesystem

First of all, the bootloader needs to be readable (== unencrypted) for the basic i/o system. This is normally no problem, as the bootloader is found in the MBR of a harddisk (at least partially, enough to start).

Then the bootloader needs to find its data/configuration files and after that it needs to find the kernel.

Normally this is achieved by using an unencrypted /boot partition, which contains the other bootloader parts and the kernel.

When the kernel finished initalizing, it needs to find (a variant of) init. Well, it cannot find init, because init is encrypted. To be able to read the root (and init), we'll need a ramdisk containing losetup, which reads a password and creates a loop device.

Ramdisks are checked before the kernel tries to load init, so this works pretty good.

You can then check from your now decrypted root, that /boot didn't change (with md5sum or tripwire for example). If it changed you can stop booting.

Benefits: - most parts of the system are encrypted

Disadvantages: - needs a ramdisk - need to pay attention, when you make changes to /boot (when updating the kernel for instance)

whole system + unencrypted external device

You could put the /boot partition on a USB Stick, a r/o CDROM.

Benefits: - you have no unencrypted data on your computer

Disadvantages: - you always need to pay attention to carry the external medium with you - same as above

Problems / insecurity

partial encryption

Well, you always have some unencrypted data. Especially the bootloader, your kernel and your ramdisk cannot be encrypted (correct me when I'm wrong).

fake system

If somebody gets access to your system, he may replace your unencrypted data and place his faked versions. I've name faked version with a 'F' prefix.

attack possibilities

points

I'll assume the attacker cannot decrypt our cryptoloop data. So he has to attack

• the bootloader
• the kernel
• the ramdisk

replacements

First he could try to replace the bootloader. The Fbootloader could possibly load a Fkernel which has a modified cryptoloop module.

Secondly he could try just to replace the kernel with Fkernel, again having modified the cryptoloop module.

At last he could replace the contents of the ramdisk. This Framdisk could contain a modified losetup.

sniff and copy

Let's assume the attacker modified the bootloader and the kernel. You enter the password and the kernel boots up your standard init. Your checksum checking program (like md5sum, see above) detects that the kernel is modified.

If you've got luck the kernel module didn't configure your network opened a connection to the net. If it did, you password is gone and you'll need to recreate your cryptoloop (this is not really difficult: losetup the raw device again, with the new password. dd if=/dev/oldloop of=/dev/newloop).

Assume the attacker replaced your ramdisk, too. Now the attacker modified LOSETUP! Doesn't really matter you think? Well, let's see:

You enter the password for your root partition. Flosetup doesn't exit normally, instead it mounts your root and replaces your system libs and unmounts the root after that. Your checksum program loads the Flib and the md5sum function returns always the same value. Your check-script then assumes that the ramdisk, the kernel and the bootloader are unmodified and starts the system. As the libs are modified, the connect() call could try to connect to a password collecting host and to the one specified.

Flosetup could even have modified anything. This includes your check-script, /etc/shadow, /sbin/init and so on.

You cannot trust the integrity of your system anymore.

change encrypted checksums

Oh, and it would be much easier just to replace the cached checksums on the encrypted root.

Solutions

Secure unencrypted data

A way to have secure cryptoloops is to do what's described in 2.5. You must keep your unencrypted data secure. This means that you got to wear at always.

Get a real system [tm]

The other choice would be to have a 'trusted' system, which is able to read encrypted MBRs/bootloader.

On x86 you could possibly replace your BIOS with a Linux kernel, which is able to boot from cryptoloop, in the ROM,

This does not mean you should use TCPA! With TCPA you give away the right to modify your computer to companies like Intel.

Summary

You have a protection against someone reading your data, as long as your laptop/computer is 'trusted'. This means, whenever someone is able to modify the unencrypted part(s), your cryptoloop data could be modified.