How feasible is it to create an mlock(1) utility, that would allow
priveleged users to execute a daemon such that none of the memory the
daemon allocates will ever be swapped out?
ntp daemon does mlock(2) internally, for example, but IMHO this is
really a policy decision that could be moved out of the app.
Unfortunately I am VM-ignorant as always ;-)
Jeff
Jeff Garzik wrote:
>
> How feasible is it to create an mlock(1) utility, that would allow
> priveleged users to execute a daemon such that none of the memory the
> daemon allocates will ever be swapped out?
>
> ntp daemon does mlock(2) internally, for example, but IMHO this is
> really a policy decision that could be moved out of the app.
>
> Unfortunately I am VM-ignorant as always ;-)
>
> Jeff
>
I think it would be pretty easy to do. Since mlock(2) operates on the
calling processes vma tree you'd need an interface to the kernel that
let you specify a child process and an address range to lock. Then in
the kernel you'd need to translate the pid into task struct and
replicate the functionality of sys_mlock without the assumption that
current points to the task that you're modifying. Sounds like something
you could do pretty easy with a proc file in fact.
Neil
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
/***************************************************
*Neil Horman
*Software Engineer
*Red Hat, Inc.
*[email protected]
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
***************************************************/
Neil Horman wrote:
> Jeff Garzik wrote:
>
>>
>> How feasible is it to create an mlock(1) utility, that would allow
>> priveleged users to execute a daemon such that none of the memory the
>> daemon allocates will ever be swapped out?
>>
>> ntp daemon does mlock(2) internally, for example, but IMHO this is
>> really a policy decision that could be moved out of the app.
>>
>> Unfortunately I am VM-ignorant as always ;-)
>>
>> Jeff
>>
>
> I think it would be pretty easy to do. Since mlock(2) operates on the
> calling processes vma tree you'd need an interface to the kernel that
> let you specify a child process and an address range to lock. Then in
> the kernel you'd need to translate the pid into task struct and
> replicate the functionality of sys_mlock without the assumption that
> current points to the task that you're modifying. Sounds like something
> you could do pretty easy with a proc file in fact.
>
>
> Neil
>
>>
>>
>> -
Clarification: didn't mean to say child process there. Any process
would be modifiable with this interface I think.
Neil
--
/***************************************************
*Neil Horman
*Software Engineer
*Red Hat, Inc.
*[email protected]
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
***************************************************/
* Jeff Garzik ([email protected]) wrote:
>
> How feasible is it to create an mlock(1) utility, that would allow
> priveleged users to execute a daemon such that none of the memory the
> daemon allocates will ever be swapped out?
1. Doesn't require privilege, just proper rlimits ;-)
2. Problem is the execve(2) that the mlock(1) program would have to call.
This blows away the mappings which contain the locking info. Unless you
were thinking of promoting something akin to VM_LOCKED from the ->mm
def_flags to a per task flag.
> ntp daemon does mlock(2) internally, for example, but IMHO this is
> really a policy decision that could be moved out of the app.
Hard to say if it's a policy decision outside the scope of the app.
Esp. if the app knows it needs to not be swapped. Either something that
has realtime needs, or more specifically, privacy needs. Don't need to
mlock all of gpg to ensure key data never hits swap.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
Jeff Garzik wrote:
>
> How feasible is it to create an mlock(1) utility, that would allow
> priveleged users to execute a daemon such that none of the memory the
> daemon allocates will ever be swapped out?
>
> ntp daemon does mlock(2) internally, for example, but IMHO this is
> really a policy decision that could be moved out of the app.
>
> Unfortunately I am VM-ignorant as always ;-)
I think you should be able to do this if you make a suid binary that
calls mlockall(MCL_CURRENT|MCL_FUTURE)
drops capabilities
exec()s the desired app
Note that fork()'d children are not locked, and that the apps may segfault if
they try to write to newly allocated memory and there is no more left. It will
still be possible to segfault on newly allocated stack as well. However, once
the app aquires memory, it will not be paged out.
Chris
On Fri, 2004-09-24 at 16:15, Neil Horman wrote:
> Jeff Garzik wrote:
> >
> > How feasible is it to create an mlock(1) utility, that would allow
> > priveleged users to execute a daemon such that none of the memory the
> > daemon allocates will ever be swapped out?
> >
> > ntp daemon does mlock(2) internally, for example, but IMHO this is
> > really a policy decision that could be moved out of the app.
> >
> > Unfortunately I am VM-ignorant as always ;-)
> >
>
> I think it would be pretty easy to do. Since mlock(2) operates on the
> calling processes vma tree you'd need an interface to the kernel that
> let you specify a child process and an address range to lock. Then in
> the kernel you'd need to translate the pid into task struct and
> replicate the functionality of sys_mlock without the assumption that
> current points to the task that you're modifying. Sounds like something
> you could do pretty easy with a proc file in fact.
>
Is this really a good idea? I suspect it would be abused. For example,
people would mlock mozilla or openoffice to keep it from being paged out
overnight when updatedb runs, where the real solution is to fix the
problem with the VM that causes updatedb to force other apps to swap
out.
Making it harder to use mlock ensures that only apps that REALLY need it
will use it, time-critical stuff like ntpd and jackd.
Lee
Lee Revell wrote:
> Is this really a good idea? I suspect it would be abused. For example,
> people would mlock mozilla or openoffice to keep it from being paged out
> overnight when updatedb runs, where the real solution is to fix the
> problem with the VM that causes updatedb to force other apps to swap
> out.
Use /proc/swappiness for this
It definitely helped for me. I set it really low, around '10' or so.
Jeff
On Fri, 2004-09-24 at 16:33, Jeff Garzik wrote:
> Lee Revell wrote:
> > Is this really a good idea? I suspect it would be abused. For example,
> > people would mlock mozilla or openoffice to keep it from being paged out
> > overnight when updatedb runs, where the real solution is to fix the
> > problem with the VM that causes updatedb to force other apps to swap
> > out.
>
> Use /proc/swappiness for this
>
> It definitely helped for me. I set it really low, around '10' or so.
>
Yeah, this never bugged me much but some people hate this behavior. I
set it to 0, works fine.
My point is that people will abuse mlock(1). Maybe that is not our
concern. But, the current users of mlock have to know what they are
doing to some extent. Like the ntpd example, it doesn't mlock ALL it's
memory, just the portion that can't be swapped out due to realtime
constraints.
Lee
* Chris Friesen ([email protected]) wrote:
> Chris Wright wrote:
>
> > 2. Problem is the execve(2) that the mlock(1) program would have to call.
> > This blows away the mappings which contain the locking info.
>
> Does it? The man page said it isn't inherited on fork(), but why wouldn't it
> be inherited on exec()?
The info is stored in the memory mapping info that's necessarily blown
away at execve(2) because that's where you are overlaying a new image.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
Chris Wright wrote:
> 2. Problem is the execve(2) that the mlock(1) program would have to call.
> This blows away the mappings which contain the locking info.
Does it? The man page said it isn't inherited on fork(), but why wouldn't it be
inherited on exec()?
Chris
Chris Wright wrote:
> The info is stored in the memory mapping info that's necessarily blown
> away at execve(2) because that's where you are overlaying a new image.
Yeah, I just saw that on the man page for mlockall.
I though maybe it was stored on the task struct or something.
Chris
* Chris Friesen ([email protected]) wrote:
> Chris Wright wrote:
>
> > The info is stored in the memory mapping info that's necessarily blown
> > away at execve(2) because that's where you are overlaying a new image.
>
> Yeah, I just saw that on the man page for mlockall.
It's required for SUSv3 (mlock too).
> I though maybe it was stored on the task struct or something.
Nope, default from MCL_FUTURE is ->mm->def_flags otherwise it's per
vma->vm_flags.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
Jeff Garzik <[email protected]> wrote:
>
> How feasible is it to create an mlock(1) utility, that would allow
> priveleged users to execute a daemon such that none of the memory the
> daemon allocates will ever be swapped out?
It used to be the case that mlockall(MCL_FUTURE) was inherited across fork,
which would do what you want.
But that was a bug and we fixed it a couple of years back, sadly.
I guess we could add a new mlockall mode which _is_ inherited across fork.
On Gwe, 2004-09-24 at 21:22, Chris Wright wrote:
> Hard to say if it's a policy decision outside the scope of the app.
> Esp. if the app knows it needs to not be swapped. Either something that
> has realtime needs, or more specifically, privacy needs. Don't need to
> mlock all of gpg to ensure key data never hits swap.
Keys are a different case anyway. We can swap them if we have encrypted
swap (hardware or software) and we could use the crypto lib just to
crypt some pages in swap although that might be complex. As such a
MAP_CRYPT seems better than mlock. If we don't have cryptable swap then
fine its mlock.
* Alan Cox ([email protected]) wrote:
> On Gwe, 2004-09-24 at 21:22, Chris Wright wrote:
> > Hard to say if it's a policy decision outside the scope of the app.
> > Esp. if the app knows it needs to not be swapped. Either something that
> > has realtime needs, or more specifically, privacy needs. Don't need to
> > mlock all of gpg to ensure key data never hits swap.
>
> Keys are a different case anyway. We can swap them if we have encrypted
> swap (hardware or software) and we could use the crypto lib just to
> crypt some pages in swap although that might be complex. As such a
> MAP_CRYPT seems better than mlock. If we don't have cryptable swap then
> fine its mlock.
Yeah, sounds nice. This is still very much an app specific policy, not
something that a helper such as mlock(1) would solve.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
Chris Wright wrote:
> * Alan Cox ([email protected]) wrote:
>
>>On Gwe, 2004-09-24 at 21:22, Chris Wright wrote:
>>
>>>Hard to say if it's a policy decision outside the scope of the app.
>>>Esp. if the app knows it needs to not be swapped. Either something that
>>>has realtime needs, or more specifically, privacy needs. Don't need to
>>>mlock all of gpg to ensure key data never hits swap.
>>
>>Keys are a different case anyway. We can swap them if we have encrypted
>>swap (hardware or software) and we could use the crypto lib just to
>>crypt some pages in swap although that might be complex. As such a
>>MAP_CRYPT seems better than mlock. If we don't have cryptable swap then
>>fine its mlock.
>
>
> Yeah, sounds nice. This is still very much an app specific policy, not
> something that a helper such as mlock(1) would solve.
It's all app-specific policy. mlock(1) allows the sysadmin to apply
app-specific policy on top of whatever app-specific policy the engineer
has chosen to hardcode into his app.
A smart sysadmin that knows the working set of his _local configuration_
of a given app is sometimes in a better position to make a decision
about mlockall(2) than the engineer.
Jeff
On Friday 24 September 2004 13:41, Chris Friesen wrote:
> Chris Wright wrote:
> > 2. Problem is the execve(2) that the mlock(1) program would have to call.
> > This blows away the mappings which contain the locking info.
>
> Does it? The man page said it isn't inherited on fork(), but why wouldn't
> it be inherited on exec()?
>
From my mlock(2) manpage:
"...they are guaranteed to stay in RAM until the pages are unlocked by munlock
or munlockall, until the pages are unmapped via munmap, or until the process
terminates or starts another program with exec."
-Ryan
On Fri, Sep 24, 2004 at 10:07:25PM +0100, Alan Cox wrote:
> Keys are a different case anyway. We can swap them if we have encrypted
> swap (hardware or software) and we could use the crypto lib just to
> crypt some pages in swap although that might be complex. As such a
> MAP_CRYPT seems better than mlock. If we don't have cryptable swap then
> fine its mlock.
I really like encrypted swap, it should already work fine, I think we
should make it the default. The cpu cost during swapping should be
really not significant. It's needed anyways for running suspend on a
laptop (currently suspend dumps into the swap the cleartext key of any
cryptoloop device, making cryptoloop pretty much useless). And the good
thing is that it won't even need to ask for a password.
* Jeff Garzik ([email protected]) wrote:
> Chris Wright wrote:
> > * Alan Cox ([email protected]) wrote:
> > >On Gwe, 2004-09-24 at 21:22, Chris Wright wrote:
> >>>Hard to say if it's a policy decision outside the scope of the app.
> >>>Esp. if the app knows it needs to not be swapped. Either something that
> >>>has realtime needs, or more specifically, privacy needs. Don't need to
> >>>mlock all of gpg to ensure key data never hits swap.
> >>
> >>Keys are a different case anyway. We can swap them if we have encrypted
> >>swap (hardware or software) and we could use the crypto lib just to
> >>crypt some pages in swap although that might be complex. As such a
> >>MAP_CRYPT seems better than mlock. If we don't have cryptable swap then
> >>fine its mlock.
> >
> > Yeah, sounds nice. This is still very much an app specific policy, not
> > something that a helper such as mlock(1) would solve.
>
> It's all app-specific policy. mlock(1) allows the sysadmin to apply
> app-specific policy on top of whatever app-specific policy the engineer
> has chosen to hardcode into his app.
>
> A smart sysadmin that knows the working set of his _local configuration_
> of a given app is sometimes in a better position to make a decision
> about mlockall(2) than the engineer.
OK, that's fine. I just wanted to highlight some situations
where it's preferable to leave that hardcoded in the application.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
Hi.
On Sat, 2004-09-25 at 08:59, Andrea Arcangeli wrote:
> On Fri, Sep 24, 2004 at 10:07:25PM +0100, Alan Cox wrote:
> > Keys are a different case anyway. We can swap them if we have encrypted
> > swap (hardware or software) and we could use the crypto lib just to
> > crypt some pages in swap although that might be complex. As such a
> > MAP_CRYPT seems better than mlock. If we don't have cryptable swap then
> > fine its mlock.
>
> I really like encrypted swap, it should already work fine, I think we
> should make it the default. The cpu cost during swapping should be
> really not significant. It's needed anyways for running suspend on a
> laptop (currently suspend dumps into the swap the cleartext key of any
> cryptoloop device, making cryptoloop pretty much useless). And the good
> thing is that it won't even need to ask for a password.
I plan on making a plugin for suspend2 that will use the cryptoapi to
encrypt the data. One of the problems with encrypting the swap partition
wholesale is that suspend implementations need to check whether the
image exists and get some unencrypted metadata before beginning to read
the image proper. Currently, they all store the location of the metadata
in the swap header. If that's encrypted, how will they know whether the
image exists. If we're working on an abstraction of swap (transparent
[en|de]cryption), will the actual header still be visible? Will it be
able to be set up early enough in the boot sequence for resuming? (That
later shouldn't be a problem for suspend2 as it lets you set things up
in an initrd before resuming).
Regards,
Nigel
In article <[email protected]> you wrote:
> laptop (currently suspend dumps into the swap the cleartext key of any
> cryptoloop device, making cryptoloop pretty much useless). And the good
> thing is that it won't even need to ask for a password.
Where would you store the key for the suspend image without asking?
Gruss
Bernd
--
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/
Hi.
On Sat, 2004-09-25 at 09:59, Bernd Eckenfels wrote:
> In article <[email protected]> you wrote:
> > laptop (currently suspend dumps into the swap the cleartext key of any
> > cryptoloop device, making cryptoloop pretty much useless). And the good
> > thing is that it won't even need to ask for a password.
>
> Where would you store the key for the suspend image without asking?
You should really reply-to-all, not just to LKML. I've added the
original recipients back.
I have to admit that I'm not sure. I haven't begun to try to write the
support yet, or even look at how the other implementations do
encryption. (Pointers welcome!) I assume there should be some option to
save it in a file and get it via the initrd, and/or perhaps require the
user to type in a passphrase at the lilo prompt.
>From what I have seen, random keys are sometimes chosen. I guess the
point there is not so much to protect access to the image as to obscure
it? If so, the existing compression support in suspend2 probably helps
satisfy this requirement.
Regards,
Nigel
* Andrew Morton ([email protected]) wrote:
> Jeff Garzik <[email protected]> wrote:
> >
> > How feasible is it to create an mlock(1) utility, that would allow
> > priveleged users to execute a daemon such that none of the memory the
> > daemon allocates will ever be swapped out?
>
> It used to be the case that mlockall(MCL_FUTURE) was inherited across fork,
> which would do what you want.
>
> But that was a bug and we fixed it a couple of years back, sadly.
>
> I guess we could add a new mlockall mode which _is_ inherited across fork.
Here's a simple (bit ugly) hack that does it (esp. the exec part).
Seems to miss one page, probably from the arguments or so. Not sure if
it's worth pursuing, but here it is ;-)
$ ./mlock /bin/cat /proc/self/status | grep Vm
VmSize: 3436 kB
VmLck: 3432 kB
VmRSS: 3436 kB
VmData: 144 kB
VmStk: 8 kB
VmExe: 13 kB
VmLib: 1195 kB
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
===== fs/binfmt_elf.c 1.88 vs edited =====
--- 1.88/fs/binfmt_elf.c 2004-09-22 13:34:05 -07:00
+++ edited/fs/binfmt_elf.c 2004-09-24 17:15:53 -07:00
@@ -83,6 +83,9 @@
#define BAD_ADDR(x) ((unsigned long)(x) > TASK_SIZE)
+#define MCL_FOREVER 4
+#define PF_MEMLOCK 0x00400000
+
static int set_brk(unsigned long start, unsigned long end)
{
start = ELF_PAGEALIGN(start);
@@ -704,7 +707,7 @@
current->mm->end_code = 0;
current->mm->mmap = NULL;
current->flags &= ~PF_FORKNOEXEC;
- current->mm->def_flags = def_flags;
+ current->mm->def_flags = (current->flags & PF_MEMLOCK) ? VM_LOCKED : 0;
/* Do this immediately, since STACK_TOP as used in setup_arg_pages
may depend on the personality. */
===== mm/mlock.c 1.9 vs edited =====
--- 1.9/mm/mlock.c 2004-08-23 01:15:25 -07:00
+++ edited/mm/mlock.c 2004-09-24 16:07:16 -07:00
@@ -8,6 +8,8 @@
#include <linux/mman.h>
#include <linux/mm.h>
+#define MCL_FOREVER 4
+#define PF_MEMLOCK 0x00400000
static int mlock_fixup(struct vm_area_struct * vma,
unsigned long start, unsigned long end, unsigned int newflags)
@@ -150,6 +152,9 @@
def_flags = VM_LOCKED;
current->mm->def_flags = def_flags;
+ if (flags & MCL_FOREVER)
+ current->flags |= PF_MEMLOCK;
+
error = 0;
for (vma = current->mm->mmap; vma ; vma = vma->vm_next) {
unsigned int newflags;
@@ -170,7 +175,7 @@
int ret = -EINVAL;
down_write(¤t->mm->mmap_sem);
- if (!flags || (flags & ~(MCL_CURRENT | MCL_FUTURE)))
+ if (!flags || (flags & ~(MCL_CURRENT | MCL_FUTURE | MCL_FOREVER)))
goto out;
lock_limit = current->rlim[RLIMIT_MEMLOCK].rlim_cur;
On Sat, Sep 25, 2004 at 09:46:22AM +1000, Nigel Cunningham wrote:
> I plan on making a plugin for suspend2 that will use the cryptoapi to
> encrypt the data. One of the problems with encrypting the swap partition
> wholesale is that suspend implementations need to check whether the
> image exists and get some unencrypted metadata before beginning to read
> the image proper. Currently, they all store the location of the metadata
> in the swap header. If that's encrypted, how will they know whether the
> image exists. If we're working on an abstraction of swap (transparent
> [en|de]cryption), will the actual header still be visible? Will it be
> able to be set up early enough in the boot sequence for resuming? (That
> later shouldn't be a problem for suspend2 as it lets you set things up
> in an initrd before resuming).
My current idea is to have two passwords. the fist if for the swap
device and suspend shouldn't care about it, the end user won't care
about it either, it'll be always different, it will be choosed randomly
by userspace while booting the machine.
the second password has to be asked somehow both during suspend and
later during resume too. Users not using suspend/resume will not notice
the difference but they will stop risking dumping their credit card
into the swap partition in cleartext thanks to the primary random
password. (that is good value even for desktop users, that may
eventually sell their HD thinking they were safe because they used SSL
to transfer the information).
We could use the cryptoloop or dm-crypto and everything would work fine
if we were ok to re-run mkswap after every reboot (right after choosing
the random password). But it sounds just simpler to leave the swap
header in cleartext. The swap header and the swap metadata in general,
are the only thing that can be written in cleartext safely.
So when suspend kicks in, it will have only to write by hand into the
swap device, using the a secondary password asked to the user by the
suspend procedure. This will be the only password asked to the user.
Resume will then ask the user for the same password again. It'd be also
nice to waste 4k of swap space have a check to know if the resume
password is ok and to avoid a kernel crash if I do a typo ;). Not being
able to resume is still nicer than a potentially (though very unlikely)
fs-corrupting kernel crash.
This I believe should work safely. As far as suspend is concerned we
could also use cryptoloop instead of interfacing swap directly with
cryptoapi, then suspend should simply overwrite the swap header and
resume should reistantiate it (could even be saved in encrypted form in
another suspend-block), but then we'd need to run mkswap every boot and
that's not nice. Leaving the swap metadata in cleartext sounds a lot
nicer to avoid mkswap and to still choose random swap password at every
reboot.
> On Sat, 2004-09-25 at 09:59, Bernd Eckenfels wrote:
> > In article <[email protected]> you wrote:
> > > laptop (currently suspend dumps into the swap the cleartext key of any
> > > cryptoloop device, making cryptoloop pretty much useless). And the good
> > > thing is that it won't even need to ask for a password.
> >
> > Where would you store the key for the suspend image without asking?
when I've said you will not be asked for a password, I meant during
boot. my desktop machine will never annoy me asking me for a swap
password. Of course on the laptop (but _only_ on the laptop, since I
never use suspend on anything by the laptop) suspend/resume will have to
ask for a password for suspend/resume to work safely (this secondary
password choosen by the user, will encrypt the primary random swap
password). This should be safe.
On Sat, Sep 25, 2004 at 10:25:44AM +1000, Nigel Cunningham wrote:
> Hi.
>
> You should really reply-to-all, not just to LKML. I've added the
> original recipients back.
>
> I have to admit that I'm not sure. I haven't begun to try to write the
> support yet, or even look at how the other implementations do
> encryption. (Pointers welcome!) I assume there should be some option to
> save it in a file and get it via the initrd, and/or perhaps require the
> user to type in a passphrase at the lilo prompt.
saving it to the disk is not safe. It really has to be choosen by the
user. Maybe for suspend we could try to search for active cryptoloops
or dm-crypt, and re-use the same password, to avoid asking the user.
That would be ok. But resume definitely has to ask to the user.
I doubt we can make it with lilo/grub, if we do that we should probably
nuke it somehow from /proc/cmdline, allowing all users in the system to
see the cleartext password doesn't sound secure enough. More likely the
kernel should stop and ask the user to type something and then read the
swap header and find a magic-check block and see if the password can
decrypt the magic block.
> >From what I have seen, random keys are sometimes chosen. I guess the
> point there is not so much to protect access to the image as to obscure
> it? If so, the existing compression support in suspend2 probably helps
> satisfy this requirement.
random keys are exactly fine, but only for the swap usage on a desktop
machine (the one I mentioned above, where the user will not be asked for
a password), but it's not ok for suspend/resume, suspend/resume needs
a regular password asked to the user both at suspend time and at resume
time.
On Sat, 25 Sep 2004, Andrea Arcangeli wrote:
>
> We could use the cryptoloop or dm-crypto and everything would work fine
> if we were ok to re-run mkswap after every reboot (right after choosing
> the random password). But it sounds just simpler to leave the swap
> header in cleartext. The swap header and the swap metadata in general,
> are the only thing that can be written in cleartext safely.
>
if you don't do a -c mkswap runs fast enough that it shouldn't be a
problem to do it every boot.
David Lang
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
On Sat, Sep 25, 2004 at 03:07:59AM +0200, Andrea Arcangeli wrote:
> about it either, it'll be always different, it will be choosed randomly
> by userspace while booting the machine.
^^^^^^^^^^^^
while the above would work fine too, I'm starting thinking it's simpler
and cleaner to make it completely transparent to userspace, we can
choose the random key within sys_swapon, userspace will only have to
tweak if to enable the crypto-swap feature or not before calling swapon
(maybe via sysctl).
Chris Wright <[email protected]> wrote:
>
> Here's a simple (bit ugly) hack that does it (esp. the exec part).
Seems complicated. IIRC it's just a matter of propagating a suitable flag
in oldmm->def_flags into the new mm in copy_mm().
On Fri, Sep 24, 2004 at 06:21:27PM -0700, David Lang wrote:
> if you don't do a -c mkswap runs fast enough that it shouldn't be a
> problem to do it every boot.
yep, speed isn't my worry, my worry is a misconfigured /etc/fstab wiping
out a filesystem...
If I didn't worry about wiping out a filesystem, then using cryptoloop
would be easier than to interface cryptoapi inside the swap methods to
leave the header in cleartext, so that it can be still checked for a
magic number before starting writing into it. (plus interfacing swap
with cryptoapi makes suspend/resume life easier too)
* Andrew Morton ([email protected]) wrote:
> Chris Wright <[email protected]> wrote:
> >
> > Here's a simple (bit ugly) hack that does it (esp. the exec part).
>
> Seems complicated. IIRC it's just a matter of propagating a suitable flag
> in oldmm->def_flags into the new mm in copy_mm().
For fork. Not exec. W/out smth for exec, then a utility that does
equiv of MCL_FUTRE + exec won't work.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
On Sat, 25 Sep 2004 03:30:13 +0200, Andrea Arcangeli said:
> On Fri, Sep 24, 2004 at 06:21:27PM -0700, David Lang wrote:
> > if you don't do a -c mkswap runs fast enough that it shouldn't be a
> > problem to do it every boot.
>
> yep, speed isn't my worry, my worry is a misconfigured /etc/fstab wiping
> out a filesystem...
If the mkswap doesn't nuke the filesystem, the first time we actually
send a page to swap will do the job. Plus, there's more chance of paging
on a filesystem and managing to *not* notice, if we merely corrupt data
by dropping an essentially random 4K page on top of 4K of file data and
manage to not hit any metadata.
Maybe have mkswap check the partition table and not do it if the partition
isn't id=82 (Linux swap) unless -f is specified? Not sure what to do if
the space is a loop or LVM device though.....
On Fri, Sep 24, 2004 at 09:46:59PM -0400, [email protected] wrote:
> On Sat, 25 Sep 2004 03:30:13 +0200, Andrea Arcangeli said:
> > On Fri, Sep 24, 2004 at 06:21:27PM -0700, David Lang wrote:
> > > if you don't do a -c mkswap runs fast enough that it shouldn't be a
> > > problem to do it every boot.
> >
> > yep, speed isn't my worry, my worry is a misconfigured /etc/fstab wiping
> > out a filesystem...
>
> If the mkswap doesn't nuke the filesystem, the first time we actually
> send a page to swap will do the job. Plus, there's more chance of paging
how can a page be sent to swap if sys_swapon refuses to run? The whole
point of avoiding running mkswap is to forbid sys_swapon to run.
> Maybe have mkswap check the partition table and not do it if the partition
> isn't id=82 (Linux swap) unless -f is specified? Not sure what to do if
> the space is a loop or LVM device though.....
or also if you mkswap on the whole device without partitions.
doing crypto-swap with cryptoapi inside the swap layer (without using
cryptoloop and dm-crypt) with a transparently randomly choosen password
and the metadata written in cleartext sounds just a lot cleaner and
safer.
In article <[email protected]> you wrote:
> If the mkswap doesn't nuke the filesystem, the first time we actually
> send a page to swap will do the job.
You do not send a page to a device with no swap signature, and you do not
attach swap in a cryptoloop without a valid content.
Gruss
Bernd
--
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/
On Sat, 25 Sep 2004 04:15:01 +0200, Andrea Arcangeli said:
> On Fri, Sep 24, 2004 at 09:46:59PM -0400, [email protected] wrote:
> > On Sat, 25 Sep 2004 03:30:13 +0200, Andrea Arcangeli said:
> > > On Fri, Sep 24, 2004 at 06:21:27PM -0700, David Lang wrote:
> > > > if you don't do a -c mkswap runs fast enough that it shouldn't be a
> > > > problem to do it every boot.
> > >
> > > yep, speed isn't my worry, my worry is a misconfigured /etc/fstab wiping
> > > out a filesystem...
> >
> > If the mkswap doesn't nuke the filesystem, the first time we actually
> > send a page to swap will do the job. Plus, there's more chance of paging
>
> how can a page be sent to swap if sys_swapon refuses to run? The whole
> point of avoiding running mkswap is to forbid sys_swapon to run.
I think we're actually in what the IETF sometimes calls 'violent agreement' -
what I meant was that if a misconfigured /etc/fstab marked a file system
as 'swap', then even if it survived the 'mkswap', the subsequent swapping
would finish the job...
But as you noted in an earlier posting, having the metadata in cleartext
so sys_swapon can tell what's going on and skipping the mkswap entirely is
a better solution..
> > Maybe have mkswap check the partition table and not do it if the partition
> > isn't id=82 (Linux swap) unless -f is specified? Not sure what to do if
> > the space is a loop or LVM device though.....
>
> or also if you mkswap on the whole device without partitions.
"Linux is designed to give you enough rope to shoot yourself in the foot with" ;)
I'll let somebody else worry about how paranoid mkswap should be before
requiring a -f flag.
> doing crypto-swap with cryptoapi inside the swap layer (without using
> cryptoloop and dm-crypt) with a transparently randomly choosen password
> and the metadata written in cleartext sounds just a lot cleaner and
> safer.
Yes, that does sound like a sane idea, and also addresses at least *most* of
the issues with swsusp and swap not stepping on each other's toes (as the
header is in cleartext so they both can read it). That still leaves the
swsusp crew having to save their key securely - but that's easily done if
you have cryptoapi handy. Only ugly part is having to read a passphrase
from the keyboard at suspend and resume (trying to implement "suspend on
close lid" gets.. ummm.. interesting ;)
On Fri, Sep 24, 2004 at 10:46:32PM -0400, [email protected] wrote:
> I think we're actually in what the IETF sometimes calls 'violent agreement' -
> what I meant was that if a misconfigured /etc/fstab marked a file system
> as 'swap', then even if it survived the 'mkswap', the subsequent swapping
> would finish the job...
indeed, I got it now ;)
> But as you noted in an earlier posting, having the metadata in cleartext
> so sys_swapon can tell what's going on and skipping the mkswap entirely is
> a better solution..
Yep.
> > or also if you mkswap on the whole device without partitions.
>
> "Linux is designed to give you enough rope to shoot yourself in the foot with" ;)
eheh ;)
> Yes, that does sound like a sane idea, and also addresses at least *most* of
> the issues with swsusp and swap not stepping on each other's toes (as the
exactly ;)
> header is in cleartext so they both can read it). That still leaves the
> swsusp crew having to save their key securely - but that's easily done if
> you have cryptoapi handy. Only ugly part is having to read a passphrase
> from the keyboard at suspend and resume (trying to implement "suspend on
> close lid" gets.. ummm.. interesting ;)
that's it yes.
I don't even think "save their key securely" (I mean saving anything
related to the swapsuspend encryption key on disk) is needed. A mixture
of a on-disk key + passphrase would not be more secure than a simple
"passphrase" alone, because the on-disk key would be in cleartext and
readable from the attacker. the only usable key is the one in the user memory,
it cannot be saved in the computer anywhere. Peraphs for additional
security (and to avoid having to type and remember it) one could use an
usb pen to store and fetch the key... but then I leave the fun to the
usb folks since to do that usb should kick off before resume overwrites
the kernel image ;)
On Sat, 25 Sep 2004 04:58:48 +0200, Andrea Arcangeli said:
> I don't even think "save their key securely" (I mean saving anything
> related to the swapsuspend encryption key on disk) is needed. A mixture
> of a on-disk key + passphrase would not be more secure than a simple
> "passphrase" alone, because the on-disk key would be in cleartext and
> readable from the attacker. the only usable key is the one in the user memory,
> it cannot be saved in the computer anywhere. Peraphs for additional
> security (and to avoid having to type and remember it) one could use an
> usb pen to store and fetch the key... but then I leave the fun to the
> usb folks since to do that usb should kick off before resume overwrites
> the kernel image ;)
Well, obviously saving the actual key on the disk is a losing idea, but saving
"key hashed by passphrase" would work (similar to how PGP or SSH don't save the
actual key, but rather the key hashed by something).
I suspect that having the *entire* key be the passphrase remembered by the user
is also a non-starter security-wise (unless we do something like Jari Ruusu's
loop-AES stuff does and forces a minimim 20-char passphrase) - there's going to
be all too many blocks in the swsusp area that are "known plaintext" and easily
brute-forceable for most passphrases that users are likely to actually use.
So in order to make it at all secure, we really need to save on the disk
a key with O(128 bits) of entropy, perturbed by enough bits that are *not*
to be found anywhere on the machine so that it isn't a slam-dunk for an attacker.
Do any of the crypto experts lurking have ideas/opinions on just how many
bits we need to store externally (be it in a USB dongle, a thumbprint, a
passphrase, whatever)?
On Fri, Sep 24, 2004 at 11:29:58PM -0400, [email protected] wrote:
> loop-AES stuff does and forces a minimim 20-char passphrase) - there's going to
> be all too many blocks in the swsusp area that are "known plaintext" and easily
well, it's not a filesystem with superblock at fixed location for
example, the data location and contents is mostly random, or certainly
not a "known plaintext". Brute forcing cryptoloop is probably a joke
compared to brute forcing cryptoswap. But I sure agree a more secure
method is welcome (if it exists ;)
My point is simply that if the hashed key is stored in a known location
(and it has to, or the resume procedure couldn't find it either), the
same brute force plaintext attack would work on the hashed key too
(perhaps slower). Or am I missing something about crypto here? Is it the
induced slowdown what provides higher protection? the algorithm is one
way anyways, so it's not that the hash is the one that prevents
reversing it from the plaintext. Brute force is still against the
passphrase and nothing else, hence the same complexity (though slower
with an additional hash to compute plus lots more bits of key for each
brute-force try).
with GPG and SSH the real powerful thing is that the attacker has no
access to your .gnupg and .ssh directory with the private secret keys,
but if he had access, brute forcing it shouldn't be more difficult than
brute forcing a single passphrase, if the private key is known the only
unknown bits that provides security are the ones of your passphrase.
But again, I may be missing something about crypto here, corrections
welcome so I can learn too ;).
> So in order to make it at all secure, we really need to save on the disk
> a key with O(128 bits) of entropy, perturbed by enough bits that are *not*
> to be found anywhere on the machine so that it isn't a slam-dunk for an attacker.
if they're "not to be found anywhere", how can resume find them? ;)
> Do any of the crypto experts lurking have ideas/opinions on just how many
> bits we need to store externally (be it in a USB dongle, a thumbprint, a
> passphrase, whatever)?
I think as many as we can, since I'm afraid it's the only protection we
get. But here we've the huge advantage of not having known plaintext in
known places on disk.
On Sat, 25 Sep 2004 06:07:10 +0200, Andrea Arcangeli said:
> On Fri, Sep 24, 2004 at 11:29:58PM -0400, [email protected] wrote:
> > loop-AES stuff does and forces a minimim 20-char passphrase) - there's goin
g to
> > be all too many blocks in the swsusp area that are "known plaintext" and ea
sily
>
> well, it's not a filesystem with superblock at fixed location for
> example, the data location and contents is mostly random, or certainly
> not a "known plaintext".
I'm sure there's enough pages that live at magic addresses that end up at
predictable/identifiable locations on the disk to supply enough "known
plaintext". Remember - the attacker only has to find *one* crypto-block sized
set of bits - even with a 256-bit algo, they only have to find 32 consecutive
bytes that they can identify or reconstruct.
Howdy.
On Sat, 2004-09-25 at 11:07, Andrea Arcangeli wrote:
> We could use the cryptoloop or dm-crypto and everything would work fine
> if we were ok to re-run mkswap after every reboot (right after choosing
> the random password). But it sounds just simpler to leave the swap
> header in cleartext. The swap header and the swap metadata in general,
> are the only thing that can be written in cleartext safely.
>
> So when suspend kicks in, it will have only to write by hand into the
> swap device, using the a secondary password asked to the user by the
> suspend procedure. This will be the only password asked to the user.
Yes, that's exactly what I was thinking too: header & metadata in plain
text, data proper encrypted. Fits perfectly with suspend's current modus
operandi too.
> Resume will then ask the user for the same password again. It'd be also
> nice to waste 4k of swap space have a check to know if the resume
> password is ok and to avoid a kernel crash if I do a typo ;). Not being
> able to resume is still nicer than a potentially (though very unlikely)
> fs-corrupting kernel crash.
There must be some way of being able to check the password is correct
without compromising security by encrypting static text and storing it
at a known location! Darned if I know what it is though.
> This I believe should work safely. As far as suspend is concerned we
> could also use cryptoloop instead of interfacing swap directly with
> cryptoapi, then suspend should simply overwrite the swap header and
> resume should reistantiate it (could even be saved in encrypted form in
> another suspend-block), but then we'd need to run mkswap every boot and
> that's not nice. Leaving the swap metadata in cleartext sounds a lot
> nicer to avoid mkswap and to still choose random swap password at every
> reboot.
Perhaps it will help here to say that suspend plays nicely with swapping
at the moment. All of the implementations use the normal swap allocation
routines to get and free the pages they write to, and they also only
change (reverseably) the ten-character header on the header page (not
the data itself). (The SWAP-SPACE or SWAPSPACE2 sig). You thus don't
have to re-mkswap after suspending. Writing the image is done using
submit_bio, not the swapspace specific routines.
Regards,
Nigel
On Sat, Sep 25, 2004 at 10:21:21PM +1000, Nigel Cunningham wrote:
> There must be some way of being able to check the password is correct
> without compromising security by encrypting static text and storing it
> at a known location! Darned if I know what it is though.
good point! Maybe we can pick random signed chars in a 4k block and
guarantee their sum is always -123456. Would that be secure against
plaintext attack right? It's more like a checksum than a magic number,
but it should be a lot more secure than the "double" typo probability
(and this way the password will be asked only once during resume).
Generating those random numbers will not be the easiest thing though.
[email protected] wrote:
> On Sat, 25 Sep 2004 04:58:48 +0200, Andrea Arcangeli said:
>
>
>>I don't even think "save their key securely" (I mean saving anything
>>related to the swapsuspend encryption key on disk) is needed. A mixture
>>of a on-disk key + passphrase would not be more secure than a simple
>>"passphrase" alone, because the on-disk key would be in cleartext and
>>readable from the attacker. the only usable key is the one in the user memory,
>>it cannot be saved in the computer anywhere. Peraphs for additional
>>security (and to avoid having to type and remember it) one could use an
>>usb pen to store and fetch the key... but then I leave the fun to the
>>usb folks since to do that usb should kick off before resume overwrites
>>the kernel image ;)
>
>
> Well, obviously saving the actual key on the disk is a losing idea, but saving
> "key hashed by passphrase" would work (similar to how PGP or SSH don't save the
> actual key, but rather the key hashed by something).
>
> I suspect that having the *entire* key be the passphrase remembered by the user
> is also a non-starter security-wise (unless we do something like Jari Ruusu's
> loop-AES stuff does and forces a minimim 20-char passphrase) - there's going to
> be all too many blocks in the swsusp area that are "known plaintext" and easily
> brute-forceable for most passphrases that users are likely to actually use.
>
> So in order to make it at all secure, we really need to save on the disk
> a key with O(128 bits) of entropy, perturbed by enough bits that are *not*
> to be found anywhere on the machine so that it isn't a slam-dunk for an attacker.
>
> Do any of the crypto experts lurking have ideas/opinions on just how many
> bits we need to store externally (be it in a USB dongle, a thumbprint, a
> passphrase, whatever)?
>
Not really a crypto expert, but... use a random session key, at least
128 bits. Encrypt _that_ with the passphrase or whatever, eliminating
any known plaintext. Since this decryption is only done once at bootup,
we don't care how slow it may be, so use an iterated scheme (like
Blowfish crypt). That way the user could dial it to take 500ms or so on
the local machine to try a passphrase, making weak passphrases a lot
harder to bruteforce. Or the kernel should iteratively encrypt it at
suspend for some fixed time, then store the iteration count.
So long as suspend/resume is supported, there's a risk that someone
captures a suspended system and steals a disk image. Later they force
the owner to reveal the passphrase. Now they can see not only the
useful contents of memory but any old stuff that's been sitting in swap
since the last reboot (like PGP keys). This could be avoided by making
the system somewhat forward-secret: generate a random key per vma and
zero it out of RAM when the vma goes away (assuming the vma is the right
unit for it). If the IVs are chosen based on position in the swap
device then there should be very little overhead.
--Andy
Andrea Arcangeli wrote:
> random keys are exactly fine, but only for the swap usage on a desktop
> machine (the one I mentioned above, where the user will not be asked for
> a password), but it's not ok for suspend/resume, suspend/resume needs
> a regular password asked to the user both at suspend time and at resume
> time.
Why not ask on every boot? (and yes, the passphrase could be stored on a
fixed disk location - hashed with a function of sufficient complexity
and number of bits, just to warn the user if he does a typo, couldn't
it?). If suspend is working, you basically never reboot. So why ask on
suspend _and_ resume? This also solves the "suspend on lid close" issue.
And a resume is - in the beginning - a boot, so just ask early enough
(maybe the bootloader could do this?)
I'm not a crypto expert at all, just thinking loud...
Stefan
Hi.
On Mon, 2004-09-27 at 16:16, Stefan Seyfried wrote:
> Andrea Arcangeli wrote:
>
> > random keys are exactly fine, but only for the swap usage on a desktop
> > machine (the one I mentioned above, where the user will not be asked for
> > a password), but it's not ok for suspend/resume, suspend/resume needs
> > a regular password asked to the user both at suspend time and at resume
> > time.
>
> Why not ask on every boot? (and yes, the passphrase could be stored on a
> fixed disk location - hashed with a function of sufficient complexity
> and number of bits, just to warn the user if he does a typo, couldn't
> it?). If suspend is working, you basically never reboot. So why ask on
> suspend _and_ resume? This also solves the "suspend on lid close" issue.
>
> And a resume is - in the beginning - a boot, so just ask early enough
> (maybe the bootloader could do this?)
>
> I'm not a crypto expert at all, just thinking loud...
I loved Andrea's compare-the-checksum idea, but don't see why the
passphrase is needed both times either. Then again I have zero
experience with encryption. In fact, I care so much about security that
I don't have a root password and have sudo without a password :>
Regards,
Nigel
--
Nigel Cunningham
Pastoral Worker
Christian Reformed Church of Tuggeranong
PO Box 1004, Tuggeranong, ACT 2901
Many today claim to be tolerant. True tolerance, however, can cope with others
being intolerant.
On Mon, Sep 27, 2004 at 08:16:43AM +0200, Stefan Seyfried wrote:
> Andrea Arcangeli wrote:
>
> > random keys are exactly fine, but only for the swap usage on a desktop
> > machine (the one I mentioned above, where the user will not be asked for
> > a password), but it's not ok for suspend/resume, suspend/resume needs
> > a regular password asked to the user both at suspend time and at resume
> > time.
>
> Why not ask on every boot? (and yes, the passphrase could be stored on a
> fixed disk location - hashed with a function of sufficient complexity
> and number of bits, just to warn the user if he does a typo, couldn't
> it?). If suspend is working, you basically never reboot. So why ask on
> suspend _and_ resume? This also solves the "suspend on lid close" issue.
because I never use suspend/resume on my desktop, I never shutdown my
desktop. I don't see why should I spend time typing a password when
there's no need to. Every single guy out there will complain at linux
hanging during boot asking for password before reaching kdm.
I figured out how to make the swap encryption completely transparent to
userspace, and even to swap suspend, so I think it's much better than
having userspace asking the user for a password, or userspace choosing a
random password.
> And a resume is - in the beginning - a boot, so just ask early enough
> (maybe the bootloader could do this?)
yes, but the bootloader passes the paramters via /proc/cmdline, and it's
not nice to show the password in cleartext there.
So I think it'd generally safer to have the kernel asking for a password
during resume.
You're right that if we'd be asking users for a password at every
swapon, we wouldn't need to ask the password during suspend, but then
every single machine would hang during boot asking for a password, I
much prefer the machine to hang in suspend and resume only and it looks
much nicer to do all swap encryption completely transparent to userspace.
Userspace/yast will only know how to turn it on/off via a sysctl.
userspace may also want to learn about suspend/resume encryption.
Keep in mind the password cannot be stored on the harddisk, or it would
be trivial to find it for an attacker stoling the laptop.
suspend/resume is just unusable for me on the laptop until we fix the
crypto issues.
On Mon, Sep 27, 2004 at 08:32:43PM +1000, Nigel Cunningham wrote:
> I loved Andrea's compare-the-checksum idea, but don't see why the
> passphrase is needed both times either. Then again I have zero
> experience with encryption. In fact, I care so much about security that
> I don't have a root password and have sudo without a password :>
I also have sudo without password of course, the issue here is only
about somebody stoling your harddisk. I'm fine about having zero local
security and blocking everything with the firewall as far as it's me
owning the machine ;).
I have encrypted data in my harddisk, and I simply cannot use suspend
that would dump into the swap partition the cleartext password making my
encryption void (plus it increases the probability to dump credit card
numbers or kwallet entries into the swap, but that's a separate problem
not really related to suspend).
Basically to avoid to type the password during suspend, we'd need an
algorihtm that encrypts with a public key stored on the harddisk and
restore with the private key that sits only on a human brain. The
public key would be stored on the harddisk and it would be used by
suspend to write to the swap partition. the resume password would be
asked to the user and used to decrypt the data. I think it should work
fine in theory.
However AFIK those public/private key algorithms only works securely with tons of
bits (a lot more than with a symmetic encryption), so I don't see how
can an human could possibly remeber such a long private key by memory. I
guess to make it work you'd need an USB pen to store it and unplug it
(then you'd have to be careful not to lose the USB pen). So I think it's
much simpler to use symmetric crypto (like cryptoloop) and to ask the
password during suspend too.
Andrea Arcangeli wrote:
> On Mon, Sep 27, 2004 at 08:16:43AM +0200, Stefan Seyfried wrote:
>>Why not ask on every boot? (and yes, the passphrase could be stored on a
> because I never use suspend/resume on my desktop, I never shutdown my
> desktop. I don't see why should I spend time typing a password when
> there's no need to. Every single guy out there will complain at linux
> hanging during boot asking for password before reaching kdm.
Well, there is more than one use case -> probably we need more than one
implementation :-)
> I figured out how to make the swap encryption completely transparent to
> userspace, and even to swap suspend, so I think it's much better than
> having userspace asking the user for a password, or userspace choosing a
> random password.
That's fine for the never-enter-a-password case, but for the
suspend-case, it's not so good since i want to close the lid and pack
away the notebook. Two scenarios, two implementations.
>
>
>>And a resume is - in the beginning - a boot, so just ask early enough
>>(maybe the bootloader could do this?)
>
> yes, but the bootloader passes the paramters via /proc/cmdline, and it's
> not nice to show the password in cleartext there.
We could mask it in /proc/cmdline or think of other mechanisms for
passing the secret. Or just ask from the initramfs and start resuming
after that.
> Keep in mind the password cannot be stored on the harddisk, or it would
> be trivial to find it for an attacker stoling the laptop.
> suspend/resume is just unusable for me on the laptop until we fix the
> crypto issues.
Well, as long as you need your entire $HOME or / encrypted, it's not
easy. If you just need e.g. /secret/ encrypted userspace could umount it
before suspend and remount it after resume (we also lock X etc, adding a
umount / mount should be trivial).
--
Stefan Seyfried, QA / R&D Team Mobile Devices, SUSE LINUX AG N?rnberg.
"Any ideas, John?"
"Well, surrounding them's out."
On Mon, Sep 27, 2004 at 04:34:54PM +0200, Stefan Seyfried wrote:
> That's fine for the never-enter-a-password case, but for the
> suspend-case, it's not so good since i want to close the lid and pack
> away the notebook. Two scenarios, two implementations.
Your "close-lid with suspend-to-disk" without ever asking password in
suspend is fundamentally unfixable, unless you use public key
encryption, but for it to be secure you've to store in your brain and
type >128 chars at every resume...
Probably the next best thing you can do is to ask a preventive suspend
password during boot, for the suspend-capable-machines. That would be
more reasonable since I'd leave it disabled on my desktop.
> Well, as long as you need your entire $HOME or / encrypted, it's not
> easy. If you just need e.g. /secret/ encrypted userspace could umount it
> before suspend and remount it after resume (we also lock X etc, adding a
> umount / mount should be trivial).
losetup -d would probably do the trick if it clears the buffer where the
password sits before the kfree (that should be checked, not obvious that
it does it).
But it's not secure anyways without encryption since the memory freed by
mozilla where the credit card was, could be dumped into the swap space
if it was only partially reused as slab etc.. I mean, even normal
swapping is insecure on a laptop, but suspend make it worse.
the "freed" memory in linux can always contain sensitive data, and we
guarantee to never make it visible to anyone, and you're safe after you
shutdown the machine and the ram loses power. Good applications using
mlock should always clear the memory before releasing it to the
operative system, but most apps don't even use mlock and they relay on
the OS to be secure (and even the ones using mlock may not always clear
it before freeing it, even the oom killer could break that assumption).
Andrea Arcangeli wrote:
> On Mon, Sep 27, 2004 at 04:34:54PM +0200, Stefan Seyfried wrote:
> Your "close-lid with suspend-to-disk" without ever asking password in
> suspend is fundamentally unfixable, unless you use public key
or unless i enter it on every boot.
> Probably the next best thing you can do is to ask a preventive suspend
> password during boot, for the suspend-capable-machines. That would be
> more reasonable since I'd leave it disabled on my desktop.
or just enter the cryptoswap password on every boot / resume :-)
--
Stefan Seyfried, QA / R&D Team Mobile Devices, SUSE LINUX AG N?rnberg.
"Any ideas, John?"
"Well, surrounding them's out."
On Mon, Sep 27, 2004 at 05:25:06PM +0200, Stefan Seyfried wrote:
> Andrea Arcangeli wrote:
> >On Mon, Sep 27, 2004 at 04:34:54PM +0200, Stefan Seyfried wrote:
>
> >Your "close-lid with suspend-to-disk" without ever asking password in
> >suspend is fundamentally unfixable, unless you use public key
>
> or unless i enter it on every boot.
yes.
> >Probably the next best thing you can do is to ask a preventive suspend
> >password during boot, for the suspend-capable-machines. That would be
> >more reasonable since I'd leave it disabled on my desktop.
>
> or just enter the cryptoswap password on every boot / resume :-)
but I don't need to, so I'd leave it disabled instead.
I'd also really leave the two things separated. There's no reason the
user should ever know the cryptoswap password. it only needs to know the
suspend/resume password. This way the cryptoswap password can be
choosen very big randomly and in turn with a lot more random bits than
what an user could remember by memory.
So you should only consider asking a "preventive" suspend password,
never the cryptoswap password, the latter will be transparent to the
user. suspend will automatically store safely the cryptoswap password on
disk, so you shouldn't even notice the swap methods are encrypting data.
> Basically to avoid to type the password during suspend, we'd need an
> algorihtm that encrypts with a public key stored on the harddisk and
> restore with the private key that sits only on a human brain. The
> public key would be stored on the harddisk and it would be used by
> suspend to write to the swap partition. the resume password would be
> asked to the user and used to decrypt the data. I think it should work
> fine in theory.
>
> However AFIK those public/private key algorithms only works securely with
> tons of bits (a lot more than with a symmetic encryption), so I don't see
> how can an human could possibly remeber such a long private key by memory.
> I guess to make it work you'd need an USB pen to store it and unplug it
> (then you'd have to be careful not to lose the USB pen). So I think it's
> much simpler to use symmetric crypto (like cryptoloop) and to ask the
> password during suspend too.
You may do it like ssh: encrypt the private key with a symmetric cypher using
a key based on a passphrase and store it on disk (of course this is only as
secure as your passphrase).
On suspend: generate a symmetric-key KS, save memory to harddisk encrypted
with KS, append the KS enrypted with the public key A_PUB. append the private
encrypted key A_PRIV_ENCR_BASED_ON_PASSPHRASE (which is stored on the
harddisk). On resume user must type in passphrase, then we can decrypt
A_PRIV_ENCR_BASED_ON_PASSPHRASE and get A_PRIV, decrypt KS and so decrypt
saved memory.
Greetings,
Wolfgang Walter
--
Wolfgang Walter
Studentenwerk M?nchen
Anstalt des ?ffentlichen Rechts
EDV
Leopoldstra?e 15
80802 M?nchen
Hi.
On Tue, 2004-09-28 at 00:16, Andrea Arcangeli wrote:
> On Mon, Sep 27, 2004 at 08:16:43AM +0200, Stefan Seyfried wrote:
> > Andrea Arcangeli wrote:
> >
> > > random keys are exactly fine, but only for the swap usage on a desktop
> > > machine (the one I mentioned above, where the user will not be asked for
> > > a password), but it's not ok for suspend/resume, suspend/resume needs
> > > a regular password asked to the user both at suspend time and at resume
> > > time.
> >
> > Why not ask on every boot? (and yes, the passphrase could be stored on a
> > fixed disk location - hashed with a function of sufficient complexity
> > and number of bits, just to warn the user if he does a typo, couldn't
> > it?). If suspend is working, you basically never reboot. So why ask on
> > suspend _and_ resume? This also solves the "suspend on lid close" issue.
>
> because I never use suspend/resume on my desktop, I never shutdown my
> desktop. I don't see why should I spend time typing a password when
> there's no need to. Every single guy out there will complain at linux
> hanging during boot asking for password before reaching kdm.
>
> I figured out how to make the swap encryption completely transparent to
> userspace, and even to swap suspend, so I think it's much better than
> having userspace asking the user for a password, or userspace choosing a
> random password.
The public/private key idea makes good sense to me.
> > And a resume is - in the beginning - a boot, so just ask early enough
> > (maybe the bootloader could do this?)
>
> yes, but the bootloader passes the paramters via /proc/cmdline, and it's
> not nice to show the password in cleartext there.
If this password is only needed when resuming, that's not an issue
because the command line given when resuming will be lost when the
original kernel data is copied back.
> suspend/resume is just unusable for me on the laptop until we fix the
> crypto issues.
There's already compression support. It's simpler to reverse, of course,
but it doesn't help?
Regards,
Nigel
On Tue, Sep 28, 2004 at 08:22:41AM +1000, Nigel Cunningham wrote:
> > because I never use suspend/resume on my desktop, I never shutdown my
> > desktop. I don't see why should I spend time typing a password when
> > there's no need to. Every single guy out there will complain at linux
> > hanging during boot asking for password before reaching kdm.
> >
> > I figured out how to make the swap encryption completely transparent to
> > userspace, and even to swap suspend, so I think it's much better than
> > having userspace asking the user for a password, or userspace choosing a
> > random password.
>
> The public/private key idea makes good sense to me.
yes for suspend/resume it should work. it will have the only advantage
of not having to ask the password during suspend or during boot, it will
only ask the "resueme" password during resume and the first time you
create the public key for resume to write it in the harddisk encrypted
with such passphrase as . as usual it'll be as Wolfgang suggested.
But why did you quote the above? for cryptoswap it cannot work, for
cryptoswap there's no reason to ever ask the user to anything and it
must read and write all the time anyways, it's not like suspend
write-only and resume read-only, a problem where public/private
encryption can fit.
> > yes, but the bootloader passes the paramters via /proc/cmdline, and it's
> > not nice to show the password in cleartext there.
>
> If this password is only needed when resuming, that's not an issue
> because the command line given when resuming will be lost when the
> original kernel data is copied back.
my point is that you would not be allowed to give anyone ssh access to
your machine (assuming you trust local security). If he gets ssh access,
then he could as well stole the laptop and read the encrypted data.
But if calling set_fs(KERNEL_DS); sys_read(0) sounds troublesome, you
could also erase the password from the cmdline, and you would still
pass the passphrase via bootloader. I'd recommend not to make it visible
to userspace.
> There's already compression support. It's simpler to reverse, of course,
> but it doesn't help?
that should be trivial to reverse, no?
Hi!
> > There must be some way of being able to check the password is correct
> > without compromising security by encrypting static text and storing it
> > at a known location! Darned if I know what it is though.
>
> good point! Maybe we can pick random signed chars in a 4k block and
> guarantee their sum is always -123456. Would that be secure against
> plaintext attack right? It's more like a checksum than a magic number,
> but it should be a lot more secure than the "double" typo probability
> (and this way the password will be asked only once during resume).
> Generating those random numbers will not be the easiest thing though.
Actually, better solution probably is to encrypt 32-bit zero.
Then, you have 1:2^32 probability of accepting wrong password, still
if you try to brute-force it, you'll find many possible passwords.
If you are paranoid, encrypt 16-bit zero....
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
(Stupid Idea Warning... 8-)
The top-n reasons (mentioned) to want to have your swap encrypted involve things like
dealing with a stolen/sold drive or someone using a boot CD to peak into your swapped
data. To a great extent this sort of thing would be semi-automagic with a (cringing)
DRM chip. (This is not a pro-trusted-computing thing, as if I don't have the keys to
my machine, it isn't really my machine, IMHO.)
The truth of the matter is that, on the intel platform at least, you have the CPU ID.
You also have the unique serial number burned into clock chips by the manufacturer on
both Intel and many other platforms. As always milage may varry.
You also have the GUUIDs that you can write into ext2/3 file systems etc.
And you have your kernel boot command line.
There is "enough" data in that pile to create a sufficiently unique key for matching
the various users various needs.
So I would say that it should be possible to create a meta-boot-block that could be
written to the swap in a well-known location that would (re)generate the key based on
the local config.
This wouldn't have cryptographic closure in most cases, but it *would* prevent all
but the most determined from abusing a restore.
Consider the "typical default" Intel meta-boot-block; it would combine[1] at least
the checksum of the boot command line, the GUUID of the selected root file system,
the clock serial number and the CPU0 serial number to create the swap/restore key.
If the kernel image checksum were available that would be good too. Reguardless,
this default minimal key generation would prevent the swap space from being
accessible to all the various "easy" alternate boot methodologies. You would never
"restore" using a different file system or invocation args, nor would you restore if
you separated the drive from the mother board.
So why the meta-boot-block?
1) Being a little (4k) applet, the application itself could contain entropy data.
That is, if you aren't doing a restore, you wouldn't use the boot-block at all. So
for each non-restore boot you could have completely different entropy value that was
never recorded outside of active kernel ram.
2) The meta-boot-block would only be written upon (attempted) suspend. So the
meta-boot-block location would not normally contain the key-generating code and data.
So a power-switch-event couldn't be used to compromise the swap image. That gets you
as close as possible to the orderly start and end states of the OS before you are in
the key-saving business.
3) [maybe really 2a] since the boot block isn't written until the last moment, if the
swap structures are themselves encoded, any swap image from the drive would be
useless to a non-restart inspection of the swap by any means. So for systems where
suspend never happens, the swap is "always" cryptographically secure.
4) If the meta-boot-block is created at the last moment, and destroyed on startup,
the absence of a well-signed (it _would_ need some sort of checksum) block would be
authoritative of the absence of an opportunity to restore. That is, if the
meta-boot-block region doesn't checksum then you *know* you cannot restore. [If you
somehow have a good boot block but it doesn't decode the swap headers then you know
the boot block is stale, so old-blocks, when combined with regular-boot selection of
entropy is self-correcting.] It would, of course, be important to destroy the
boot-block area after reading it to keep the restore-session as secure as the
first-run session.
5) Different installations could use different boot-block applets to match their own
need. If you have a cool security chip you could use a custom security-chip based
meta-boot-block while most of us would just use the base model that "makes sure" that
the restore/decode is happening on our own hardware using the same root and the same
startup args etc. That is, the default would be good enough for most of us. People
who want a boot/restore password could have that via yet another boot block.
6) People who don't want restore at all could have the "null" boot block that
produces the "don't bother" null key (e.g. "return 0;" as the text of the function
etc.) without having to build a no-meta-boot kernel.
7) Since it is a "smidgen of code", individual implementations could be made that
looked for just about anything. 4k (one typical swap block) is actually a good bit
of space, so one could even have this thing check a dongle or stripe-load a disk
region (a-la gump) and run a longer bunch of text or data (possibly lifted out of the
"wherever it got swapped to" part of the swap space. That is, a much longer datum
could be hidden-in-plain-sight by allocating a region of uninitialized memory and
then saving over it plain-text "wherever it landed in the swap image" some necessary
additional code or data or god knows what else.
As I said this isn't secure against someone who has all the vital information about
your computer and had the skill to dummy-up a kernel that would provide the bogus
information to itself. (e.g. their kernel set up to "fake" all your IDs and serial
numbers.) But it would produce an image that would keep "most" leaks and virtually
all mistakes from happening. So all the "boot from CD and take a peak", or "pull the
power cord, steal the disk, and do forensics" attacks would be nicely thwarted.
Someone with more crypto knowledge could probably perfect this into a far-less stupid
idea, but I think the basic premise is sound without being "too complex to be
workable".
[1] The Composition operation would involve a one-way hash of chosen datum. The hash
would be run against the system IDs and invocation information, probably with some
other entropy value(s) added in, when the kernel starts. That is, during a
non-restore startup the kernel would "manufacture" a meta-boot-block in-situ and run
it to produce a key, it would then initialize the swap space, effectively destroying
the old swap and any old boot block. On suspend, the kernel would write that block
to the meta-boot-block region of the primary swap device (or similar). On restore,
the saved block would be restored and checked. If it checked out, and the key it
produced "properly decoded" the swap headers, then the block region would be erased
and restore would continue using that block. If the block didn't check out or didn't
decode the swap headers, then the kernel goes back to the non-restore boot sequence
and manufactures a new key-generation-block (so that a system cannot be attacked by
installing a trivial key-generation-block in a swap partition).
Rob White
Casabyte, Inc.
-----Original Message-----
From: [email protected] [mailto:[email protected]]
On Behalf Of Andrea Arcangeli
Sent: Friday, September 24, 2004 6:27 PM
To: Nigel Cunningham
Cc: Alan Cox; Chris Wright; Jeff Garzik; Linux Kernel Mailing List; Andrew Morton
Subject: Re: mlock(1)
On Sat, Sep 25, 2004 at 03:07:59AM +0200, Andrea Arcangeli wrote:
> about it either, it'll be always different, it will be choosed randomly
> by userspace while booting the machine.
^^^^^^^^^^^^
while the above would work fine too, I'm starting thinking it's simpler
and cleaner to make it completely transparent to userspace, we can
choose the random key within sys_swapon, userspace will only have to
tweak if to enable the crypto-swap feature or not before calling swapon
(maybe via sysctl).
Hi.
On Tue, 2004-09-28 at 08:43, Andrea Arcangeli wrote:
> On Tue, Sep 28, 2004 at 08:22:41AM +1000, Nigel Cunningham wrote:
> > > I figured out how to make the swap encryption completely transparent to
> > > userspace, and even to swap suspend, so I think it's much better than
> > > having userspace asking the user for a password, or userspace choosing a
> > > random password.
> >
> But why did you quote the above? for cryptoswap it cannot work, for
> cryptoswap there's no reason to ever ask the user to anything and it
> must read and write all the time anyways, it's not like suspend
> write-only and resume read-only, a problem where public/private
> encryption can fit.
I think I was a bit confused. Sorry.
> > > yes, but the bootloader passes the paramters via /proc/cmdline, and it's
> > > not nice to show the password in cleartext there.
> >
> > If this password is only needed when resuming, that's not an issue
> > because the command line given when resuming will be lost when the
> > original kernel data is copied back.
>
> my point is that you would not be allowed to give anyone ssh access to
> your machine (assuming you trust local security). If he gets ssh access,
> then he could as well stole the laptop and read the encrypted data.
Don't follow, sorry. Perhaps I'm being thick!
> But if calling set_fs(KERNEL_DS); sys_read(0) sounds troublesome, you
> could also erase the password from the cmdline, and you would still
> pass the passphrase via bootloader. I'd recommend not to make it visible
> to userspace.
>
> > There's already compression support. It's simpler to reverse, of course,
> > but it doesn't help?
>
> that should be trivial to reverse, no?
Yes, it would be.
Regards,
Nigel
--
Nigel Cunningham
Pastoral Worker
Christian Reformed Church of Tuggeranong
PO Box 1004, Tuggeranong, ACT 2901
Many today claim to be tolerant. True tolerance, however, can cope with others
being intolerant.
On Tue, Sep 28, 2004 at 03:03:44PM -0700, Robert White wrote:
> (Stupid Idea Warning... 8-)
>
> The top-n reasons (mentioned) to want to have your swap encrypted involve things like
> dealing with a stolen/sold drive or someone using a boot CD to peak into your swapped
The stolen/sold drive is a subset of the stolen/sold laptop/desktop
instead. In such case they would get access to all your hardware info.
-----Original Message-----
From: [email protected] [mailto:[email protected]]
On Behalf Of Andrea Arcangeli
Sent: Tuesday, September 28, 2004 3:15 PM
To: Robert White
Cc: 'Nigel Cunningham'; 'Alan Cox'; 'Chris Wright'; 'Jeff Garzik'; 'Linux Kernel
Mailing List'; 'Andrew Morton'
Subject: Re: mlock(1)
> On Tue, Sep 28, 2004 at 03:03:44PM -0700, Robert White wrote:
> > (Stupid Idea Warning... 8-)
> >
> > The top-n reasons (mentioned) to want to have your swap encrypted involve things
> > like
> > dealing with a stolen/sold drive or someone using a boot CD to peak into your
> > swapped
> The stolen/sold drive is a subset of the stolen/sold laptop/desktop
> instead. In such case they would get access to all your hardware info.
If you are concerned about the stolen laptop scenario you would use the (theoretical)
boot block that required a boot/restore password, or read the password out of your
bios or something. No zero-password/pass-device restore has any right to be expected
to be any more secure than walking away from a running console. So if you suspend
your computer with you X sessions running and your screen unlocked, when you restore
you will be left just as exposed as if you just walked away from the running box
anyway. If your X session (whtever) is smart enough to note the passage of time and
ask for a password then that is exactly how safe you will be, but the computer *was*
just restored. [yes, I know I am missing part of your point in the above, hence the
below... 8-)]
As stated, the idea is pretty basic, but if you have a computer you are worried might
be stolen and compromised at this level, you presumably have set your bios passwords
and such. If the "non-time" section of the bios config ram is one of the composition
key elements, the act of clearing the bios to clear the boot password would
invalidate the data that the key generation block uses to recreate the key.
If you use a restore-password block because you are even more paranoid, then they
would need that password.
A "normal" investigator using a normal level of attack would be thwarted.
It's like your house keys, you house is secure unless someone steals your keys... So
sure, someone could prep a special program to compromise the default boot block by
siphoning out the meta-boot-block data, the bios config data, the CPU ID, and root
file system GUUID, the boot command line, and the clock serial number and recreate
the cryptoswap key and then rig up a special swap probe program or specialty kernel
to run the restore etc if they new to do this first-thing (e.g. if they stole the
laptop or computer with the express intent of doing this so they didn't even try to
boot it once before beginning the attempt) but if they did this, you have a bigger
problem than having your laptop stolen... 8-)
But for that "casually" stolen laptop or computer, if they boot from a CD (having
this mecanisim) or use alternate boot parameters, or restore once and the hit the
power switch because they couldn't trigger the suspend, the swap image is scrambled.
If they use the system "vergin", without changing a thing, then they will get your
normal boot, which is no more or less secure than you have set it up to be via the
front door services (login. FTP, etc).
If they steal your server computer (that never goes to suspend because it is your
server) and they can't trick it into suspending itself first (e.g. they pull the plug
and run with it) then the key generator block was never written from ram to swap, so
your swap was "completely encrypted" because, while they have all your static IDs and
configurations they *don't* have the entropy value that was used to write the swap
image because the meta-boot-block was never written to anything, and again you are
only as exposed as the rest of your security has left you.
I know it is all kinds of not-perfect, but it *is* extensible and it is pretty darn
good.
And being extensible, you could have your very-own secret, home-made
key-generation-block template that you wrote yourself that nobody else in the world
knows about and makes restore (swap decryption) predicate on anything your heart can
envision and you can provide in a timly manner during startup... Like the
super-secret RFID tag in your favorite pair of wall-mart sneakers.
Also, the attacker gets only one chance not to screw up because the non-decrypt
startup sequence destroys the original key generation block and reinitializes the
swap headers. (Yes, he could save the swap image and try again but that is a long
brute-force cycle. 8-)
So it is not perfect, and I suspect it could be rendered even better by the thoughts
of other/better crypto types than myself (e.g. most anybody 8-), but I think you will
find it a lot more secure than you might think after just one read.
Rob White,
Casabyte, Inc.
On Llu, 2004-09-27 at 15:16, Andrea Arcangeli wrote:
> because I never use suspend/resume on my desktop, I never shutdown my
> desktop. I don't see why should I spend time typing a password when
> there's no need to. Every single guy out there will complain at linux
> hanging during boot asking for password before reaching kdm.
So attempt a decrypt with a null password before asking.
> > And a resume is - in the beginning - a boot, so just ask early enough
> > (maybe the bootloader could do this?)
We are very limited as to which bits the bootloader can do
unfortunately.
On Tue, 28 Sep 2004 16:26:16 -0700, Robert White <[email protected]> wrote:
> If you are concerned about the stolen laptop scenario you would use the (theoretical)
> boot block that required a boot/restore password
[ This is not a flame honestly. Just some points about your idea. ]
I don't see in your argument how this is meant to be cryptographically
secure. Nor do I see from any of the original mail an idea which does
anything more than offer a fake promise of security to those who are
willing to assume only dumb criminals steal their laptop. This is
worse than no security at all and renders the idea of encrypting swap
completely useless.
> or read the password out of your bios or something.
This assumes some kind of trusted BIOS running on the machine which
can obtain this password in some secure fashion - but we don't have
this on most laptops. You pointed out the idea of DRM and noted that
this is in fact quite horrible and I agree :-).
> No zero-password/pass-device restore has any right to be expected
> to be any more secure than walking away from a running console.
I fail to see anything wrong with the asking password approach - if I
use a Microsoft box of evil(TM) then it'll ask me for a password on
boot and on restore, most folks are happy to type their password in to
any box which asks for one (whether or not the actual password dialog
box) so they'll be happy to do so here. Just like having xscreensaver
or xlock come on when you resume your laptop.
> As stated, the idea is pretty basic, but if you have a computer you are worried might
> be stolen and compromised at this level, you presumably have set your bios passwords
> and such. If the "non-time" section of the bios config ram is one of the composition
> key elements, the act of clearing the bios to clear the boot password would
> invalidate the data that the key generation block uses to recreate the key.
Yes great. But:
1). I open the laptop up (I'm allowed to do that if I've already nicked it :P).
2). I take a copy of the BIOS.
3). I replace the BIOS with a hardware configuration (however done -
perhaps hot swapping chips, perhaps some simple logic device helps me)
in which the original BIOS is available once booting begins.
4). That part of the security model was just destroyed.
You can't trust anything you read from hardware. Ever. Perhaps you
might choose to trust hardware containing burried memory under layers
of metal (thus introducing an expense element to obtaining it with a
tunneling electron microscope) which required some public key/other
mechanism for communication that didn't just allow raw access to it.
> A "normal" investigator using a normal level of attack would be thwarted.
That's not the point. Once a method exists for obtaining information
from stolen laptops, that ends up not far from a simple google search
near you.
> It's like your house keys, you house is secure unless someone steals your keys...
I think the difference here is that if your house is broken in to, you
presumably know what might have been stolen, but if your laptop is
stolen it might be harder to guess exactly what can be retreived from
it afterwards. Personally I'm not currently paranoid enough to use
encryption on the laptop but might do so when I have some free time to
get around to it.
When my laptop went back to Apple I didn't do anything more than a
simple delete on the files within it (so they could have grabbed bits
of data from it or troganed it - but I do have copies so I can create
checksums of the files which were on it), but I'm just not that
worried that they secretly have a super villan on their repair team
who'd try something on ;-).
The point is however - if I do decide to use encryption to protect
some of my personal data (and I don't care about credit cards - if my
laptop is nicked then I can cancel the card) then I want to be sure
that the mechanism is actually sound. There's no point to any system
which simply claims to be secure (like certain USB devices) but isn't.
> But for that "casually" stolen laptop or computer, if they boot from a CD (having
> this mecanisim) or use alternate boot parameters, or restore once and the hit the
> power switch because they couldn't trigger the suspend, the swap image is scrambled.
> If they use the system "vergin", without changing a thing, then they will get your
> normal boot, which is no more or less secure than you have set it up to be via the
> front door services (login. FTP, etc).
I see your point but don't think it's good to assume anything about an
attacker. While it's unlikely that someone is going to have the
technical expertise to thwart your model, I'd only want to use
something which relied on more than attacker knowledge. The reality is
however that someone stealing my laptop will see an xscreensaver,
reboot, possibly see Linux booting and then get really confused
because a). it's a Mac so it's not one of those PC things that you can
stick a bootleg Windows XP on. b). It's a Mac running something weird
so it'll need a copy of that Mac software thing to make it work. They
might be smart enough to visit a bookshop and read the page in the
Hayes Apple manual on removing the hard disk before flogging it on
ebay "for parts".
> And being extensible, you could have your very-own secret, home-made
> key-generation-block template that you wrote yourself that nobody else in the world
> knows about and makes restore (swap decryption) predicate on anything your heart can
> envision and you can provide in a timly manner during startup... Like the
> super-secret RFID tag in your favorite pair of wall-mart sneakers.
...or my tux boxers. They'd have to be very determined to go there for
my passphrase.
> Also, the attacker gets only one chance not to screw up because the non-decrypt
> startup sequence destroys the original key generation block and reinitializes the
> swap headers. (Yes, he could save the swap image and try again but that is a long
> brute-force cycle. 8-)
First thing I'd do when messing with a laptop would be to take a copy
of the disk.
> but I think you will find it a lot more secure than you might think after just one read.
I'll read it again and see what I missed then - you're probably right there.
Jon.
On Mon, Sep 27, 2004 at 02:31:39PM +0100, Alan Cox wrote:
> On Llu, 2004-09-27 at 15:16, Andrea Arcangeli wrote:
> > because I never use suspend/resume on my desktop, I never shutdown my
> > desktop. I don't see why should I spend time typing a password when
> > there's no need to. Every single guy out there will complain at linux
> > hanging during boot asking for password before reaching kdm.
>
> So attempt a decrypt with a null password before asking.
Not sure to understand, sorry. I was talking about the cryptoswap above.
there's no reason to type a password from userspace as far as cryptoswap
is concerned, nor to attempt a decrypt. A long random key choosen by the
kernel is more secure, that will be a single key used for both encrypt
and decrypt, and it'll always work.
On Mer, 2004-09-29 at 02:16, Jon Masters wrote:
> I don't see in your argument how this is meant to be cryptographically
> secure. Nor do I see from any of the original mail an idea which does
> anything more than offer a fake promise of security to those who are
> willing to assume only dumb criminals steal their laptop. This is
> worse than no security at all and renders the idea of encrypting swap
> completely useless.
Most criminals are dumb. That means a boot screen that says
"Property of Dave Miller, if found please leave anywhere in Tahoe"
"Password:"
and a boot/bios password will defeat them and may get the laptop dumped
back where it can be recovered.
Thus don't rule out the value of the deterrent It isnt appropriate if
you leave national secrets on the train like all our finest government
employees keep doing obviously.
> 1). I open the laptop up (I'm allowed to do that if I've already nicked it :P).
> 2). I take a copy of the BIOS.
> 3). I replace the BIOS with a hardware configuration (however done -
> perhaps hot swapping chips, perhaps some simple logic device helps me)
> in which the original BIOS is available once booting begins.
> 4). That part of the security model was just destroyed.
This threat level is why secure systems people use smartcards for the
encryption keys and related processing. Just don't leave the smartcard
on the train!
(Sorry I am using outlook here at work by corporate mandate so my responses are
tediously at the top... 8-)
I guess the first question to ask is who or what are you actually protecting the
laptop against, what is their level of commitment, and what on the laptop are you
trying to protect.
So here are my assumptions for the model:
1) You have set your laptop not to boot from CD etc, and protected that option with a
"bios settings password".
2) You are making intelligent decisions about "how secure" your computer needs to be.
3) The thing(s) we are trying to protect in the swap space are the ram images of the
running programs (etc) because the running system is secure to some acceptable
degree.
4) The system doesn't have to be "perfect" (because none are) it just has to be
"better" than the amount of effort the attacker is willing to expend.
5) Once the system is running again, security isn't "our problem" with respect to
ingress. That is, we cannot really protect against a hardware-level attack (like the
"monitor boards" that can halt a CPU and let you read through memory using the add-in
card.
6) Once the system is running again, security isn't "our problem" with respect to the
software that is now "restored"; that is, if you are running "gaping security hole
2007" on the active screen when you initiate suspend, when the laptop is resumed it
is Sombody Else's Problem(TM) to lock the screen or kill the app or something.
7) Not everybody feels the same need for the same level of security. There are
people who think their data is worth a power-on password, some would only presume it
is worth a "resume" password, and some think a locking screen-saver is an onerous
burden. So the "measured response" has to be one that each user must be able to live
with. That is, there *IS* nothing wrong with requiring a resume password... except
for the people who don't think their data is worth the hassle.
8) This is *NOT* a general startup security solution, it is targeted to
cyptographically encoding swap and preventing some of the most obvious restore
boo-boos. That is, there is no attempt in _this_ code to keep a user away from the
login prompt etc.
9) It is desireable to know that when you resume a kernel (etc) that you are resuming
the same kernel, and that it was resumed on the same box, etc.
10) A smart guy with a good soldering iron and an eprom burner and a bunch of time
will be able to defeat any of this because he can simply read the memory of the live
system by adding in any piece of hardware that can do a bus-fetch. (e.g. PCI
bus-mastering etc).
11) In a system that never has to "resume from suspend" you can create a unique
cryptoswap key at every boot and then throw it away.
12) Any "restore" methodology can be attacked by definition because the attacker can
probably contrive to get an executable into the FS image of something "long enough"
to run the setuid program he added to the disassembled system. So without a
cryptographical file system, you don't get *too* much from restore protection.
13) The "worst case" of a failed authentication run is a normal boot, so the storage
requirements are *quite* ephemeral.
14) The only "real" goal for a protected restore is to attempt to make sure that the
restore operation is taking place in a context that is identical to the context of
the suspend. So your real goal is to try to make sure that this boot is just like
the last.
15) This would only be one link in a secure chain. The weakest link is preventing
low-level hardware access.
16) It is pretty safe to assume that the average non-government-agency
non-industrial-espionage "involuntary computer reassignment" will not involve someone
who knows how replace the clock chip without losing the bios config contained
there-in. (etc.)
... That Said ... 8-)
You mis-apprehend (or I mis-communicate 8-) the key generation a bit.
In a system that never does a "resume" the meta-boot-block key generation tidbit
never reaches the disk. A region of memory is filled with a template bit of code
which reads ranges of memory and disk, combines the data read with a bit of entropy,
and, for the thorough, asks the user for a password. The data thus harvested is used
to compose a key. The clever bit is that the entropy is added to the block
externally before it is invoked to do its job. So we have this little applet that we
use once and set aside.
If follows that on any box that "never" does a suspend operation, you get a random
key for your cryptoswap at every boot, and that key is never saved anywhere. (So a
feature, but at fairly high cost... 8-)
During a system suspend, the "last thing" that happens is that the applet block is
saved to the swap system in a known place.
It is instantly and admittedly obvious that a person could take apart the computer
and harvest this block and all the other regions of memory [if they are static] and
create a complete key, and then use this key. So the "default" level of security
will not keep the NSA or a good pre-made hardware assault out of this computer's
saved/suspended swap space image. It will however thwart any attacker who doesn't
have the tools to harvest all the hardware information and then compose a new
computer using the old one.
You have to sort of run the model in your head...
CPU ID fetch: static means.
Clock Chip etched serial number: static location.
Bios Data: static location with identical bios setup password and maybe boot
password.
Invocation Command Line: so no funky trick arguments.
Same root device: (mistake proofing, not so much anti-theft. 8-)
["heck maybe" the Bios Image Checksum or whatever to prevent hanky panky?]
Unique Entropy: from the meta-block.
On the other hand, for anything short of a really smart guy with a soldering iron, we
now "know", as part of our restore, that we are using our CPU, our clock chip, our
bios configuration (so, if set, our setup and our boot passwords) and our root file
system and boot arguments (so no lilo-time override or installer disk). That's a
heck of a lot of the chain "verified" for us as part of the "do we restore or
reboot?" task.
OK, so, you know, "pretty good", keeps out most of the script kiddies and anybody who
isn't willing to physically ruin the box... Yea, if you knew the version of linux
that the box used and some of the memory map bits and you restored the bios image
that you already saved right after boot, you might be able to make a custom kernel
and get the box to restore.
The important thing is that the system is "pretty good" and is extensible because the
text part of the template can be replaced, or selected from one of several
compiled-in options, by each admin at non-restore boot time. (You *would* probably
have to reboot to change templates, as the system is "on the wrong side of the fence"
with respect to loaded modules and remapped memory when the meta-boot-block text is
invoked.)
So with "just" a configuration change, the user may "switch" to the template that
demands a password from the keyboard (and then reboot). Now you have moved up "one
notch" in the world, but you haven't had to change your kernel out or anything.
If you are adding safety instead of security maybe you compose a block that also
checksums the sector of the disk that "just happens" to contain your /etc/fstab.
Maybe you want to write your own boot-block-template that reads a pluggable dongle
that will act as a key. Again, no change to core kernel semantics, just a different
4k template, but now that template needs the hardware dongle you carry in your pocket
to make the swap key. But it doesn't need it all the time, just when you boot, so
you can put it in, boot, then take it out. It's not even a sophisticated device; you
don't have to run a smart card algo, just read some region of a prom or something.
You *could* run a smart-card algo though, if you had the room.
And like a chained boot loader, the text could load in a bigger program "hidden" on
your disk to run an arbitrarily large task. That would be very advanced 8-), but now
you have room to make a specialty smart-card or biometric check.
The fact of the matter is that this is "broken glass" security and detection. That
is, if you break the glass by failing to have all the "sensitive" elements aligned
for even one boot attempt, the swap images are invalidated and lost forever. (Yes,
as admitted, it is imperfect, but its imperfections are quite stable and it can fit
nicely into a "security strategy".) (Yes, you could save the swap image before you
try, and then restore it if it didn't work and try again, but that restore ups the
brute-force single iteration cost fantastically.)
Finally, it is notable that a thief could keep suspending and resuming the laptop for
ever. If they always did an orderly suspend, they would always get an orderly resume.
That's the point. That's also a good reason *not* to have your power button trigger
a suspend, use an app... And if you don't have a locking screen saver, then you
didn't do your part of the "securing my system" task.
Why the chain?
So if you want to "resume" your swap regions contain the secret key needed to use
your _encrypted_ file system. If you have "broken glass" security on your swap
encrypted swap space, then you can easily resume and still be quite safe. If the
thief "breaks the glass" by doing a bad suspend or a bogus resume, all the doors come
down automatically, which is about as much as you can expect for "safe resume"
protection.
And as mentioned before, if you never suspend, the whole thing hides its
default-configured head, and you never knew it was there, and the key for your swap
is never saved; so after any kind of outage or shutdown other than a resume, your
sensitive data was scrambled by a key that will never see the light of day again (as
long as your entropy wasn't "return 0;" 8-).
So someone who breaks into your office and steals the company server, better be ready
to haul it off without unplugging it from your UPS.
Some of the features are very like "trusted computing", in that we are keeping track
of key box-specific configuration and hardware information in the name of "known
state" but we *want* known state for a safe resume anyway. Still the default only
needs to go so far to be effective enough to be very useful. The advanced person can
easily add passwords and dongles and who knows what other kind of box or platform
specific nonsense, all without having to alter the kernel intrinsics or semantics.
Rob White,
Casabyte, Inc.
-----Original Message-----
From: Jon Masters [mailto:[email protected]]
Sent: Tuesday, September 28, 2004 6:16 PM
To: Robert White
Cc: Andrea Arcangeli; Nigel Cunningham; Alan Cox; Chris Wright; Jeff Garzik; Linux
Kernel Mailing List; Andrew Morton
Subject: Re: mlock(1)
On Tue, 28 Sep 2004 16:26:16 -0700, Robert White <[email protected]> wrote:
> If you are concerned about the stolen laptop scenario you would use the
(theoretical)
> boot block that required a boot/restore password
[ This is not a flame honestly. Just some points about your idea. ]
I don't see in your argument how this is meant to be cryptographically
secure. Nor do I see from any of the original mail an idea which does
anything more than offer a fake promise of security to those who are
willing to assume only dumb criminals steal their laptop. This is
worse than no security at all and renders the idea of encrypting swap
completely useless.
> or read the password out of your bios or something.
This assumes some kind of trusted BIOS running on the machine which
can obtain this password in some secure fashion - but we don't have
this on most laptops. You pointed out the idea of DRM and noted that
this is in fact quite horrible and I agree :-).
> No zero-password/pass-device restore has any right to be expected
> to be any more secure than walking away from a running console.
I fail to see anything wrong with the asking password approach - if I
use a Microsoft box of evil(TM) then it'll ask me for a password on
boot and on restore, most folks are happy to type their password in to
any box which asks for one (whether or not the actual password dialog
box) so they'll be happy to do so here. Just like having xscreensaver
or xlock come on when you resume your laptop.
> As stated, the idea is pretty basic, but if you have a computer you are worried
might
> be stolen and compromised at this level, you presumably have set your bios
passwords
> and such. If the "non-time" section of the bios config ram is one of the
composition
> key elements, the act of clearing the bios to clear the boot password would
> invalidate the data that the key generation block uses to recreate the key.
Yes great. But:
1). I open the laptop up (I'm allowed to do that if I've already nicked it :P).
2). I take a copy of the BIOS.
3). I replace the BIOS with a hardware configuration (however done -
perhaps hot swapping chips, perhaps some simple logic device helps me)
in which the original BIOS is available once booting begins.
4). That part of the security model was just destroyed.
You can't trust anything you read from hardware. Ever. Perhaps you
might choose to trust hardware containing burried memory under layers
of metal (thus introducing an expense element to obtaining it with a
tunneling electron microscope) which required some public key/other
mechanism for communication that didn't just allow raw access to it.
> A "normal" investigator using a normal level of attack would be thwarted.
That's not the point. Once a method exists for obtaining information
from stolen laptops, that ends up not far from a simple google search
near you.
> It's like your house keys, you house is secure unless someone steals your keys...
I think the difference here is that if your house is broken in to, you
presumably know what might have been stolen, but if your laptop is
stolen it might be harder to guess exactly what can be retreived from
it afterwards. Personally I'm not currently paranoid enough to use
encryption on the laptop but might do so when I have some free time to
get around to it.
When my laptop went back to Apple I didn't do anything more than a
simple delete on the files within it (so they could have grabbed bits
of data from it or troganed it - but I do have copies so I can create
checksums of the files which were on it), but I'm just not that
worried that they secretly have a super villan on their repair team
who'd try something on ;-).
The point is however - if I do decide to use encryption to protect
some of my personal data (and I don't care about credit cards - if my
laptop is nicked then I can cancel the card) then I want to be sure
that the mechanism is actually sound. There's no point to any system
which simply claims to be secure (like certain USB devices) but isn't.
> But for that "casually" stolen laptop or computer, if they boot from a CD (having
> this mecanisim) or use alternate boot parameters, or restore once and the hit the
> power switch because they couldn't trigger the suspend, the swap image is
scrambled.
> If they use the system "vergin", without changing a thing, then they will get your
> normal boot, which is no more or less secure than you have set it up to be via the
> front door services (login. FTP, etc).
I see your point but don't think it's good to assume anything about an
attacker. While it's unlikely that someone is going to have the
technical expertise to thwart your model, I'd only want to use
something which relied on more than attacker knowledge. The reality is
however that someone stealing my laptop will see an xscreensaver,
reboot, possibly see Linux booting and then get really confused
because a). it's a Mac so it's not one of those PC things that you can
stick a bootleg Windows XP on. b). It's a Mac running something weird
so it'll need a copy of that Mac software thing to make it work. They
might be smart enough to visit a bookshop and read the page in the
Hayes Apple manual on removing the hard disk before flogging it on
ebay "for parts".
> And being extensible, you could have your very-own secret, home-made
> key-generation-block template that you wrote yourself that nobody else in the world
> knows about and makes restore (swap decryption) predicate on anything your heart
can
> envision and you can provide in a timly manner during startup... Like the
> super-secret RFID tag in your favorite pair of wall-mart sneakers.
...or my tux boxers. They'd have to be very determined to go there for
my passphrase.
> Also, the attacker gets only one chance not to screw up because the non-decrypt
> startup sequence destroys the original key generation block and reinitializes the
> swap headers. (Yes, he could save the swap image and try again but that is a long
> brute-force cycle. 8-)
First thing I'd do when messing with a laptop would be to take a copy
of the disk.
> but I think you will find it a lot more secure than you might think after just one
read.
I'll read it again and see what I missed then - you're probably right there.
Jon.
On Tue, 28 Sep 2004 20:46:20 -0700, Robert White <[email protected]> wrote:
> (Sorry I am using outlook here at work by corporate mandate so my responses are
> tediously at the top... 8-)
Ouch. I thought even Outlook had the option to change posting form.
> I guess the first question to ask is who or what are you actually protecting the
> laptop against, what is their level of commitment, and what on the laptop are you
> trying to protect.
If I choose to use encryption on my laptop then I want to be sure it
has a foundation rather than relying on attacker ability - otherwise
there's always a risk those government agents Alan mentioned will come
to rely upon something like this some day believing it to be safe
(because they're more than capable enough to leave these things in
London taxis :P).
> 1) You have set your laptop not to boot from CD etc, and protected that option with a
> "bios settings password".
That's useless though because someone can trivially get around that -
it's why I don't use BIOS passwords by default.
> 2) You are making intelligent decisions about "how secure" your computer needs to be.
Sure. In my case I don't currently do anything as the risk assessment
goes something like ``it hardly ever leaves my sight and I'm happy to
kick the guy trying to nick it if necessary''.
> 4) The system doesn't have to be "perfect" (because none are) it just has to be
> "better" than the amount of effort the attacker is willing to expend.
I just don't like the idea of designing something that's known to be
flawed - someone would publish a set of instructions for getting
around it. Just like you don't need to know how to create complex bus
analyzers to do funky stuff with the xbox now that's all been
published and made publically available.
My sole point here really is that it's worth asking for a password
that the user actually has to type in themself. It's trivial to do and
most users are more than happy to do it - you can tie the password in
to some function of their user password if necessary and set this all
up for suspend when they first login to their desktop. I don't see the
difficulty here.
> 10) A smart guy with a good soldering iron and an eprom burner and a bunch of time
> will be able to defeat any of this because he can simply read the memory of the live
> system by adding in any piece of hardware that can do a bus-fetch. (e.g. PCI
> bus-mastering etc).
But it'll be harder for him to defeat a system in which I've given a
password to login to my desktop which has been hashed and used to
encrypt the saved system state. I think Microsoft use the user
password as part of their EFS implementation - but in any case there's
no need for overkill when users are happy to type in a password on
login.
> In a system that never does a "resume" the meta-boot-block key generation tidbit
> never reaches the disk.
I care only about the part of the discussion relating to the save/restore cycle.
> During a system suspend, the "last thing" that happens is that the applet block is
> saved to the swap system in a known place.
> It is instantly and admittedly obvious that a person could take apart the computer
> and harvest this block and all the other regions of memory
So it's completely useless to me at least - I'd rather continue to use
nothing :-).
> CPU ID fetch: static means.
Luckily I don't have one of these in my laptop, but I do have a serial
number - so you'd need a generic mechanism for getting whatever unique
ID is available.
> On the other hand, for anything short of a really smart guy with a soldering iron, we
> now "know", as part of our restore, that we are using our CPU, our clock chip, our
> bios configuration (so, if set, our setup and our boot passwords) and our root file
> system and boot arguments (so no lilo-time override or installer disk).
So it's great for verifying a restore, but it's not secure :-).
> So with "just" a configuration change, the user may "switch" to the template that
> demands a password from the keyboard (and then reboot). Now you have moved up "one
> notch" in the world, but you haven't had to change your kernel out or anything.
Yes ok. That would be ok perhaps but it still sounds like massive overkill.
> The fact of the matter is that this is "broken glass" security and detection.
So it's not worth using anything more than Alan's suggestion of a
warning message - this is massive overkill when a simple password
prompt is fine for those wishing to encrypt or otherwise just give a
warning. I don't even bother with this because my laptop has a
hardware sleep that doesn't need to save memory state to disk, and the
average attacker will take one look at my laptop and they won't
possibly understand how to use it ;-).
My worry is that when you create ellaborate security systems that are
fundamentally flawed, then you get people believing they are more
secure than they really are. Yes that's a people problem but it's also
a good reason not to try to push this kind of idea too hard. Feel free
to implement it of course - I might even use the passphrase
configuration.
Cheers,
Jon.
On Tue, 2004-09-28 at 23:46, Robert White wrote:
> (Sorry I am using outlook here at work by corporate mandate so my responses are
> tediously at the top... 8-)
Can't you just hit Ctrl-End to go to the end of the message, and start
typing there?
Lee
Lee wrote to Robert:
> Can't you just hit Ctrl-End to go to the end of the message, and start
> typing there?
He'd better do some drastic trimming and proper '> ' quoting then, or
most of us will never sort through the mess to find his comments.
If he's going to drag along the entire several page text of the previous
post, with no '> ' markers, then top posting is preferrable, in my book,
to bottom posting.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[email protected]> 1.650.933.1373
Hi!
> > That's fine for the never-enter-a-password case, but for the
> > suspend-case, it's not so good since i want to close the lid and pack
> > away the notebook. Two scenarios, two implementations.
>
> Your "close-lid with suspend-to-disk" without ever asking password in
> suspend is fundamentally unfixable, unless you use public key
> encryption, but for it to be secure you've to store in your brain and
> type >128 chars at every resume...
?? You can store private key on harddrive and encrypt it by
symmetric crypto. No need for that huge passphrases.
> But it's not secure anyways without encryption since the memory freed by
> mozilla where the credit card was, could be dumped into the swap space
> if it was only partially reused as slab etc.. I mean, even normal
> swapping is insecure on a laptop, but suspend make it worse.
I believe this should be fixed, first. Then we can work on suspend/resume...
Pavel
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
On Tue, Sep 28, 2004 at 10:48:50AM +0200, Pavel Machek wrote:
> Hi!
>
> > > There must be some way of being able to check the password is correct
> > > without compromising security by encrypting static text and storing it
> > > at a known location! Darned if I know what it is though.
> >
> > good point! Maybe we can pick random signed chars in a 4k block and
> > guarantee their sum is always -123456. Would that be secure against
> > plaintext attack right? It's more like a checksum than a magic number,
> > but it should be a lot more secure than the "double" typo probability
> > (and this way the password will be asked only once during resume).
> > Generating those random numbers will not be the easiest thing though.
>
> Actually, better solution probably is to encrypt 32-bit zero.
>
> Then, you have 1:2^32 probability of accepting wrong password, still
> if you try to brute-force it, you'll find many possible passwords.
this is just the first step an attacker needs to rule out all the
impossible passwords and extend the crack to the other known bits. I
don't think it's secure. My suggestion OTOH sounds completely secure
(though much harder to implement).
Hi!
> > > > There must be some way of being able to check the password is correct
> > > > without compromising security by encrypting static text and storing it
> > > > at a known location! Darned if I know what it is though.
> > >
> > > good point! Maybe we can pick random signed chars in a 4k block and
> > > guarantee their sum is always -123456. Would that be secure against
> > > plaintext attack right? It's more like a checksum than a magic number,
> > > but it should be a lot more secure than the "double" typo probability
> > > (and this way the password will be asked only once during resume).
> > > Generating those random numbers will not be the easiest thing though.
> >
> > Actually, better solution probably is to encrypt 32-bit zero.
> >
> > Then, you have 1:2^32 probability of accepting wrong password, still
> > if you try to brute-force it, you'll find many possible passwords.
>
> this is just the first step an attacker needs to rule out all the
> impossible passwords and extend the crack to the other known bits. I
> don't think it's secure. My suggestion OTOH sounds completely secure
> (though much harder to implement).
Actually if your cipher is not resistant to known plaintext attack,
you have other problems anyway. There's a lot of nearly-lnown data
(like name of process with pid 1) that single 32bit zero is no problem.
So I'm not compromising anything...
Pavel
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
On Thu, Sep 30, 2004 at 08:54:47PM +0200, Pavel Machek wrote:
> Actually if your cipher is not resistant to known plaintext attack,
AFIK the only way to make it resistent to a brute force is to make it
slow, like adding lots of bits of salt.
> you have other problems anyway. There's a lot of nearly-lnown data
> (like name of process with pid 1) that single 32bit zero is no problem.
You could fix that later, by changing the offset randomly before writing
it to disk.
My point is very simple, that is if you leave a zero as part of the API,
then you're making things less secure.
Hi!
> > Actually if your cipher is not resistant to known plaintext attack,
>
> AFIK the only way to make it resistent to a brute force is to make it
> slow, like adding lots of bits of salt.
No. If you want it resistent to brute force, use big key. Actually 128bit should be enough.
If user's password has at least 128 bits of entropy, you should be safe, too.
salt only helps with "lets create 1TB of all common encrypted passwords" attack.
> My point is very simple, that is if you leave a zero as part of the API,
> then you're making things less secure.
This is same as saying that starting encrypted email with
"Hi!" is bad idea. It is not. Don't worry about brute-force, it is not
practical. (Okay, you probably should not limit password length to 8 chars).
Pavel
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
On Thu, Sep 30, 2004 at 07:42:44PM +0200, Andrea Arcangeli wrote:
> >
> > Actually, better solution probably is to encrypt 32-bit zero.
> >
> > Then, you have 1:2^32 probability of accepting wrong password, still
> > if you try to brute-force it, you'll find many possible passwords.
>
> this is just the first step an attacker needs to rule out all the
> impossible passwords and extend the crack to the other known bits. I
> don't think it's secure. My suggestion OTOH sounds completely secure
> (though much harder to implement).
PGP actually uses a similiar techinique (80 bits of randomness, with bytes 9+10
being repeats of 7+8) to check for bad decrypts. With 16 bits of checksum, the
attacker only is able to eliminate about (2^16-1)/2^16 of the keys, which seems
like a lot, but only reduces the keylength by 16 bits. If you're using
reasonably sized keys (>=128 bits) that's not a problem because the remaining
keyspace is still much larger than the set of likely passphrases (even quite
good passphrases rarely get over 80 or 90 bits of entropy).
-Jack