Hi,
My boss wanted to have the filesystem on which our proprietery software is
installed to be encrypted to make copying more difficult. And it does just
that. It's not impossible to hack into the system.
This here patch will make the kernel use a default passphrase (compiled into
the kernel or cryptoloop.ko module) when you set up a cryptoloop device with:
losetup -e aes -p 0 /dev/loop0 /path/to/your/encrypted-filesystem </dev/null
The passphrase can of course be read from the bzImage with dd if=bzImage
ibs=<compressed image offset> skip=1 | gunzip -c | strings - | less
But all that takes some searching. And the passphrase is also XOR-ed with the
first 32 bytes of /dev/nvram. If it is compiled as a module, the passphrase
is even easier to read.
The added configuration option depends on CONFIG_BLK_DEV_CRYPTOLOOP and
CONFIG_NVRAM.
The chances of breaking anything else when the option is not activated looks
like exactly zero to me.
But I have been known to be wrong. From time to time.
The affected files are: drivers/block/Kconfig and drivers/block/cryptoloop.c
The kernel source version is linux-2.6.9 (vanilla).
Comments/improvements are welcome. My /dev/null device will be happy to
process your flames.
Signed-off-by: Nico Augustijn <[email protected]>
--
Please note:
- Email address is a private one, not a corporate one.
- I am not a member of the linux-kernel email list, so all replies only sent
to the list will not be received by yours truly.
----------------------- begin patch -----------------------
--- drivers/block/cryptoloop.c.org 2004-10-20 13:26:14.000000000 +0200
+++ drivers/block/cryptoloop.c 2004-10-25 11:16:56.000000000 +0200
@@ -26,6 +26,9 @@
#include <linux/crypto.h>
#include <linux/blkdev.h>
#include <linux/loop.h>
+#ifdef CONFIG_USE_CRYPTOLOOP_DEFAULTPASSPHRASE
+ #include <linux/nvram.h>
+#endif
#include <asm/semaphore.h>
#include <asm/uaccess.h>
@@ -46,6 +49,48 @@ cryptoloop_init(struct loop_device *lo,
char *cmsp = cms; /* c-m string pointer */
struct crypto_tfm *tfm = NULL;
+
+#ifdef CONFIG_USE_CRYPTOLOOP_DEFAULTPASSPHRASE
+#if (!defined(CONFIG_CRYPTOLOOP_DEFAULTPASSPHRASE))
+ #error Cannot build kernel with NULL or empty default passphrase
+#endif
+ int n;
+ static struct loop_info64 default_info;
+
+ /* Need a copy or we're gonna be writing to a read-only location. */
+ memcpy(&default_info, info, sizeof(struct loop_info64));
+
+ /* Test if all characters of the encryption key are zero.
+ * This would indicate no key was given with 'losetup'. */
+ for (n = 0; n < info->lo_encrypt_key_size; n++)
+ if (info->lo_encrypt_key[n] != 0)
+ break;
+ /* If above loop was not broken, we can assume no key was given. */
+ if (n == info->lo_encrypt_key_size)
+ {
+ char passphrase[] = CONFIG_CRYPTOLOOP_DEFAULTPASSPHRASE;
+ int passphraselen;
+
+ /* Need this only for debugging purposes
+ printk(KERN_NOTICE "cryptoloop: Using default passphrase.\n"); */
+
+ passphraselen = strlen(passphrase);
+ /* Some bonehead might try an empty passphrase.
+ * So then we just use the terminating null character. */
+ if (passphraselen == 0)
+ passphraselen = 1;
+
+ default_info.lo_encrypt_key_size = LO_KEY_SIZE;
+ for (n = 0; n < LO_KEY_SIZE; n++)
+ /* Read a byte from NVRAM, and XOR that with 'n'th char
+ * of the default passphrase and make sure we don't try
+ * to read beyond the end of the passphrase */
+ default_info.lo_encrypt_key[n] =
+ nvram_read_byte(n) ^ passphrase[n % passphraselen];
+
+ }
+#endif
+
/* encryption breaks for non sector aligned offsets */
if (info->lo_offset % LOOP_IV_SECTOR_SIZE)
@@ -63,9 +108,14 @@ cryptoloop_init(struct loop_device *lo,
if (tfm == NULL)
return -EINVAL;
+#ifdef CONFIG_USE_CRYPTOLOOP_DEFAULTPASSPHRASE
+ err = tfm->crt_u.cipher.cit_setkey(tfm, default_info.lo_encrypt_key,
+ default_info.lo_encrypt_key_size);
+#else
err = tfm->crt_u.cipher.cit_setkey(tfm, info->lo_encrypt_key,
info->lo_encrypt_key_size);
-
+#endif
+
if (err != 0)
goto out_free_tfm;
--- drivers/block/Kconfig.org 2004-10-20 13:27:13.000000000 +0200
+++ drivers/block/Kconfig 2004-10-25 12:23:34.000000000 +0200
@@ -265,6 +265,37 @@ config BLK_DEV_CRYPTOLOOP
instead, which can be configured to be on-disk compatible with the
cryptoloop device.
+config USE_CRYPTOLOOP_DEFAULTPASSPHRASE
+ bool "Use default passphrase for cryptoloop"
+ depends on BLK_DEV_CRYPTOLOOP && NVRAM
+ ---help---
+ *** CAUTION ***
+ DO NOT USE UNLESS YOU REALLY KNOW WHAT YOU ARE DOING!!
+
+ If you are configuring your kernel to run on an unattended or
+ embedded system, you can enter a default passphrase for your
+ encrypted filesystems here.
+ This makes it more difficult (but NOT impossible) to copy data
+ from your encrypted filesystems.
+ Since this option also reads data from your MB's nvram,
+ YOU SHOULD NEVER CHANGE YOUR CMOS SETTINGS WHEN USING THIS OPTION.
+ Because CMOS settings are often written into the nvram.
+ In order for this option to work you should also set CONFIG_NVRAM,
+ the /dev/nvram driver in character devices.
+ This will also make the filesystem usable only with the specific
+ version of the MB with the specific nvram settings on which the
+ filesystem was created.
+
+config CRYPTOLOOP_DEFAULTPASSPHRASE
+ string "Default cryptoloop passphrase"
+ depends on USE_CRYPTOLOOP_DEFAULTPASSPHRASE
+ ---help---
+ Enter your default passphrase for encrypted filesystems here.
+ The minimum recommended length is 16 characters, the max is 32.
+ Any characters beyond 32 will be ignored.
+ It is also recommended that you use a really garbled passphrase
+ since it will be visible in the output of 'strings bzImage'.
+
config BLK_DEV_NBD
tristate "Network block device support"
depends on NET
----------------------- end patch -----------------------
On Mon, 25 Oct 2004 13:54:31 +0200, "Nico Augustijn." said:
> But all that takes some searching. And the passphrase is also XOR-ed with the
> first 32 bytes of /dev/nvram.
So if something touches the first 32 bytes of NVRAM, your data evaporates?
Is this considered a desirable result?
[email protected] wrote:
> On Mon, 25 Oct 2004 13:54:31 +0200, "Nico Augustijn." said:
>
>
>>But all that takes some searching. And the passphrase is also XOR-ed with the
>>first 32 bytes of /dev/nvram.
>
>
> So if something touches the first 32 bytes of NVRAM, your data evaporates?
>
> Is this considered a desirable result?
I don't have any feelings about this patch, but it seems to me that you
could always store the contents of the nvram somewhere "safe" (you could
even write them down and take it to a safe deposit box in a bank :) ),
and, if those contents happen to change, you could always write them
again...
Just my 0.02 euros,
--
Paulo Marques - http://www.grupopie.com
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
On Mon, 25 Oct 2004 18:33:43 BST, Paulo Marques said:
> I don't have any feelings about this patch, but it seems to me that you
> could always store the contents of the nvram somewhere "safe" (you could
> even write them down and take it to a safe deposit box in a bank :) ),
> and, if those contents happen to change, you could always write them
> again...
That's assuming that your machine will even *boot* correctly and cleanly if the
contents of the NVRAM are put back.
And if you're doing the "write it down and type it in again" thing, you might
as well just use a passphrase, as it's defeating the whole concept of
using /dev/nvram to xor against....
[email protected] wrote:
> On Mon, 25 Oct 2004 18:33:43 BST, Paulo Marques said:
>
>
>>I don't have any feelings about this patch, but it seems to me that you
>>could always store the contents of the nvram somewhere "safe" (you could
>>even write them down and take it to a safe deposit box in a bank :) ),
>>and, if those contents happen to change, you could always write them
>>again...
I really didn't want to pursue this further, but...
> That's assuming that your machine will even *boot* correctly and cleanly if the
> contents of the NVRAM are put back.
You can always boot with a rescue CD or something, assuming that you
don't have a stupid file system (I think there is none in Linux) that
mounts even with the wrong magic number and trashes the block device
contents.
(why would you need confidential information to boot in the first place?)
> And if you're doing the "write it down and type it in again" thing, you might
> as well just use a passphrase, as it's defeating the whole concept of
> using /dev/nvram to xor against....
No it is not. You would just type in again *if* the contents of nvram
got lost which shouldn't happen in the first place (or at least happen
rarely).
This is a "just in case" scenario, not a everytime scenario liake the
passphrase approach.
As I said before, I have no strong feelings about this patch, I just
don't like to see things defeated over false arguments...
--
Paulo Marques - http://www.grupopie.com
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
On Monday 25 October 2004 19:19, you wrote:
> On Mon, 25 Oct 2004 13:54:31 +0200, "Nico Augustijn." said:
> > But all that takes some searching. And the passphrase is also XOR-ed with
> > the first 32 bytes of /dev/nvram.
>
> So if something touches the first 32 bytes of NVRAM, your data evaporates?
>
> Is this considered a desirable result?
Yes. In this case it is very much a desirable result.
As this patch is meant (as far as I am concerned) for embedded systems only, I
really don't want people to muck about with the BIOS settings (primary boot
device, for instance).
On Mon, 25 Oct 2004 19:23:35 BST, Paulo Marques said:
> (why would you need confidential information to boot in the first place?)
The problem is not that the info in the NVRAM is "confidential",
but that most of it is "configuration".
Really sucks if you recable your SCSI controllers, the default boot disk
changes from controller 4, device 5, to controller 2, device 3 - and you
have to go and re-cable the OLD way, find the rescue CD, and fix /etc/fstab
so that you can boot in the same config that you installed the software?
Either that, or forever lose the use of "default boot device", and
have to specify it on every single boot if you want the software to work.
That *really* sucks if it's a rack-mount in a colo, you need to get physical
access to reboot....
> No it is not. You would just type in again *if* the contents of nvram
> got lost which shouldn't happen in the first place (or at least happen
> rarely).
So you change IRQ9 from level to edge trigger, or change "default boot order"
from "floppy, cd, hard drive" to "floppy, cd, hard drive, network", and
suddenly your software evaporates?
That certainly violates the Principle of Least Surprise, and why I asked
if it was an intended effect.
On Mon, 25 Oct 2004 20:57:57 +0200, Nico Augustijn said:
> > Is this considered a desirable result?
> Yes. In this case it is very much a desirable result.
> As this patch is meant (as far as I am concerned) for embedded systems only, I
> really don't want people to muck about with the BIOS settings (primary boot
> device, for instance).
+config USE_CRYPTOLOOP_DEFAULTPASSPHRASE
+ bool "Use default passphrase for cryptoloop"
+ depends on BLK_DEV_CRYPTOLOOP && NVRAM
In that case, you probably wanted:
depends on BLK_DEV_CRYPTOLOOP && NVRAM && EMBEDDED
default n
It's just *too* fragile otherwise.
Remember - just because you don't want people to muck with the BIOS settings
doesn't mean that they won't. And when they do, they probably won't remember
the warning they may or may not have read closely when they built the
kernel many moons ago.....
>This here patch will make the kernel use a default passphrase (compiled into
>the kernel or cryptoloop.ko module) when you set up a cryptoloop device with:
Suppose I break in via ssh:
I could load the module (if applicable), and find the address of the function
or variable in System.map, extract the static passphrase, and well. Then?
Jan Engelhardt
--
Gesellschaft f?r Wissenschaftliche Datenverarbeitung
Am Fassberg, 37077 G?ttingen, http://www.gwdg.de
[email protected] wrote:
> On Mon, 25 Oct 2004 19:23:35 BST, Paulo Marques said:
>
>
>>(why would you need confidential information to boot in the first place?)
>
>
> The problem is not that the info in the NVRAM is "confidential",
> but that most of it is "configuration".
I can why we were disagreeing, then.
I was assuming that these bytes were otherwise unused, because this
didn't make any sense to me otherwise.
If they are used for BIOS configuration, then I completely agree with
you. Sorry for the noise.
--
Paulo Marques - http://www.grupopie.com
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
[email protected] wrote:
> On Mon, 25 Oct 2004 19:23:35 BST, Paulo Marques said:
>
>
>>(why would you need confidential information to boot in the first place?)
>
>
> The problem is not that the info in the NVRAM is "confidential",
> but that most of it is "configuration".
>
> Really sucks if you recable your SCSI controllers, the default boot disk
> changes from controller 4, device 5, to controller 2, device 3 - and you
> have to go and re-cable the OLD way, find the rescue CD, and fix /etc/fstab
> so that you can boot in the same config that you installed the software?
>
> Either that, or forever lose the use of "default boot device", and
> have to specify it on every single boot if you want the software to work.
> That *really* sucks if it's a rack-mount in a colo, you need to get physical
> access to reboot....
>
>
>>No it is not. You would just type in again *if* the contents of nvram
>>got lost which shouldn't happen in the first place (or at least happen
>>rarely).
>
>
> So you change IRQ9 from level to edge trigger, or change "default boot order"
> from "floppy, cd, hard drive" to "floppy, cd, hard drive, network", and
> suddenly your software evaporates?
>
> That certainly violates the Principle of Least Surprise, and why I asked
> if it was an intended effect.
It depends on the intent of the encryption. If the purpose is the
protect the data, then this is acceptable. In some cases it is more
important to protect the data than to preserve them.
More to the point, I thought there was a small section of nvram reserved
to local system use, which the BIOS should not change. The appropriate
manual is 100 miles away, I have no time to google. Beside which someone
will pop up with the answer before I could look ;-)
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
On Tue, Oct 26, 2004 at 08:17:53AM +0200, Jan Engelhardt wrote:
> >This here patch will make the kernel use a default passphrase (compiled
into
> >the kernel or cryptoloop.ko module) when you set up a cryptoloop device
with:
>
> Suppose I break in via ssh:
> I could load the module (if applicable), and find the address of the
> function or variable in System.map, extract the static passphrase, and
> well. Then?
Ahem.
The point you are making is rather moot. Because if you manage to get a
shell on the system, the data can readily be copied because the encrypted
filesystem is supposed to be mounted.
Unless I miss your point.
And once you are in the system there are easier ways to obtain the
passphrase than the one you described above. As I clearly stated earlier,
it is merely more difficult to obtain the encrypted data. It is _not_
impossible. It took me approximately 4 hours to break into the system
myself. I bet there's people around who can do it in less than 1 hour.
Some of you might then ask: "What's the point of it then anyway?"
Well, I am probably capable of creating a much better solution with almost
unbreakable encryption. My boss just won't allow me the time for this.
This patch took me about a day to write. It's the best I could come up
with in such a short time.
Nico Augustijn.
[remainder of message deleted]
Nico Augustijn wrote:
> On Tue, Oct 26, 2004 at 08:17:53AM +0200, Jan Engelhardt wrote:
>
>>>This here patch will make the kernel use a default passphrase (compiled
>
> into
>
>>>the kernel or cryptoloop.ko module) when you set up a cryptoloop device
>
> with:
>
>>Suppose I break in via ssh:
>>I could load the module (if applicable), and find the address of the
>>function or variable in System.map, extract the static passphrase, and
>>well. Then?
>
>
> Ahem.
> The point you are making is rather moot. Because if you manage to get a
> shell on the system, the data can readily be copied because the encrypted
> filesystem is supposed to be mounted.
> Unless I miss your point.
>
> And once you are in the system there are easier ways to obtain the
> passphrase than the one you described above. As I clearly stated earlier,
> it is merely more difficult to obtain the encrypted data. It is _not_
> impossible. It took me approximately 4 hours to break into the system
> myself. I bet there's people around who can do it in less than 1 hour.
>
> Some of you might then ask: "What's the point of it then anyway?"
> Well, I am probably capable of creating a much better solution with almost
> unbreakable encryption. My boss just won't allow me the time for this.
> This patch took me about a day to write. It's the best I could come up
> with in such a short time.
And this provides another level of protection, which makes it useful. It
stops the casual thief who steals your laptop, and that's the most
likely exposure. If you expect you system to be secure against
government agencies or serious industrial espionage, this is pretty much
worthless, better crypto would be needed, encrypted swap, etc.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me