332 lines
9.6 KiB
Markdown
332 lines
9.6 KiB
Markdown
[[!meta title="Cryptoloop - why they are only partial secure"]]
|
|
[[!meta date="2004-03-27"]]
|
|
[[!toc levels=2]]
|
|
|
|
## 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](https://en.wikipedia.org/wiki/Trusted_Computing_Platform_Alliance)! 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.
|