Encrypted Swap

Encrypted Swap

[David Spreen]

Hey there,
I was just searching for swap-encryption-solutions in the lkml-archive.
Did I get the point saying ther's no way to do swap encryption
in linux right now? (Well, a swapfile in an encrypted kerneli
partition r something like that is not really what I want to
do I think).

so long...

David
-- 
  __          _              | David "netzwurm" Spreen      Kiel, Germany
 / _|___  ___| |__  __ _ _ _ | http://www.netzwurm.cc/      david@spreen.de
|  _/ _ \/ _ \ '_ \/ _` | '_|| gnupg key (on keyservers):   C8B6823A
|_| \___/\___/_.__/\__,_|_|  | CellPhone:                   +49 173 3874061

Re: Encrypted Swap

[Justin Guyett]

On Tue, 7 Aug 2001, David Spreen wrote:

> I was just searching for swap-encryption-solutions in the lkml-archive.
> Did I get the point saying ther's no way to do swap encryption
> in linux right now? (Well, a swapfile in an encrypted kerneli
> partition r something like that is not really what I want to
> do I think).

What's the benefit?  Sure, attackers have to know that encrypted swap is
in use, and have to be able to find the key in memory, but they already
can do both if they're root, and non-root can't [shouldn't be able to]
read swap devices on a properly secured machine.  Swap isn't meant for
storage across reboots/remounts, which is the only reason I can think of
for using encrypted loopback.  Once it's mounted, unless you have to enter
the password for every write, or unless it locks after some period of
inactivity (locking swap and requiring the password to unlock it sounds
like a fun proposition when the vm needs to swap), it's insecure until
it's locked/unmounted again.  Unmounting swap in a running system isn't
typical behavior.


justin

Re: Encrypted Swap

[Chris Wedgwood]

On Mon, Aug 06, 2001 at 08:56:15PM -0700, Justin Guyett wrote:

    What's the benefit?

See the Usenix Security Symposium proceedings from last year.


  --cw

(btw... if anyone is going to be at Usenix this yes and wants to meet
up, let me know!)

Re: Encrypted Swap

[Steve VanDevender]

Justin Guyett writes:
 > On Tue, 7 Aug 2001, David Spreen wrote:
 > 
 > > I was just searching for swap-encryption-solutions in the lkml-archive.
 > > Did I get the point saying ther's no way to do swap encryption
 > > in linux right now? (Well, a swapfile in an encrypted kerneli
 > > partition r something like that is not really what I want to
 > > do I think).
 > 
 > What's the benefit?  Sure, attackers have to know that encrypted swap is
 > in use, and have to be able to find the key in memory, but they already
 > can do both if they're root, and non-root can't [shouldn't be able to]
 > read swap devices on a properly secured machine.  Swap isn't meant for
 > storage across reboots/remounts, which is the only reason I can think of
 > for using encrypted loopback.  Once it's mounted, unless you have to enter
 > the password for every write, or unless it locks after some period of
 > inactivity (locking swap and requiring the password to unlock it sounds
 > like a fun proposition when the vm needs to swap), it's insecure until
 > it's locked/unmounted again.  Unmounting swap in a running system isn't
 > typical behavior.

It does prevent one means of recovering possibly security-critical
information for attackers who do have physical access to the machine.

The obvious approach to me would to generate a random session key at
boot time and use that for encrypting/decrypting swap pages.  If the
machine is unplugged and the disk pulled out, then the swap area on that
disk could not be recovered the attacker, who presumably is prevented by
other security measures from gaining root on the machine before it's
unplugged to try to get that session key out of the kernel.  I haven't
studied this problem, though, so the real solution may be quite a bit
more clever.

Re: Encrypted Swap

[John Polyakov]

Hello.

On Mon, 6 Aug 2001 21:12:16 -0700
Steve VanDevender <stevev@efn.org> wrote:

SV> Justin Guyett writes:
>> On Tue, 7 Aug 2001, David Spreen wrote:
>> 
>> > I was just searching for swap-encryption-solutions in the lkml-archive.
>> > Did I get the point saying ther's no way to do swap encryption
>> > in linux right now? (Well, a swapfile in an encrypted kerneli
>> > partition r something like that is not really what I want to
>> > do I think).
>> 
>> What's the benefit?  Sure, attackers have to know that encrypted swap is
>> in use, and have to be able to find the key in memory, but they already
>> can do both if they're root, and non-root can't [shouldn't be able to]
>> read swap devices on a properly secured machine.  Swap isn't meant for
>> storage across reboots/remounts, which is the only reason I can think of
>> for using encrypted loopback.  Once it's mounted, unless you have to enter
>> the password for every write, or unless it locks after some period of
>> inactivity (locking swap and requiring the password to unlock it sounds
>> like a fun proposition when the vm needs to swap), it's insecure until
>> it's locked/unmounted again.  Unmounting swap in a running system isn't
>> typical behavior.

SV> It does prevent one means of recovering possibly security-critical
SV> information for attackers who do have physical access to the machine.

Hmmm, if you have PHYSICAL access to the machine, you can simply reboot and type 
"linux init=/bin/sh" and after it simply cat /etc/shadow and run John The Ripper....
Am i wrong?

SV> The obvious approach to me would to generate a random session key at
SV> boot time and use that for encrypting/decrypting swap pages.  If the
SV> machine is unplugged and the disk pulled out, then the swap area on that
SV> disk could not be recovered the attacker, who presumably is prevented by
SV> other security measures from gaining root on the machine before it's
SV> unplugged to try to get that session key out of the kernel.  I haven't
SV> studied this problem, though, so the real solution may be quite a bit
SV> more clever.
SV> -
SV> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
SV> the body of a message to majordomo@vger.kernel.org
SV> More majordomo info at  http://vger.kernel.org/majordomo-info.html
SV> Please read the FAQ at  http://www.tux.org/lkml/

---
WBR. //s0mbre

Re: Encrypted Swap

[Chris Wedgwood]

On Tue, Aug 07, 2001 at 08:23:12AM +0400, John Polyakov wrote:

    Hmmm, if you have PHYSICAL access to the machine, you can simply
    reboot and type "linux init=/bin/sh" and after it simply cat
    /etc/shadow and run John The Ripper....  Am i wrong?

And if email stored their is encrypted via some means, and you don't
have they key...



  --cw

Re: Encrypted Swap

[Garett Spencley]

> Hmmm, if you have PHYSICAL access to the machine, you can simply reboot and type
> "linux init=/bin/sh" and after it simply cat /etc/shadow and run John The Ripper....
> Am i wrong?

Yes. Generally speaking if you have physical access to a machine then you
have root.

Heck why bother trying to crack the passwords when you can just boot up
with a root disk and access any file on the hard drive that you want? If
you want to use the machine for malicious purposes while it's running then
just install a back door.

So as someone else earlier in the thread mentioned, any secure set up
would not allow non-root users to access swap while the machine's running.
And if you can get at the hard drive physically while the machine is not
running then why bother screwing with swap when you have root anyway?

However, writing this got me thinking: you could potentialy go
through swap if you're after keys for encrypted files...

-- 
Garett Spencley

I encourage you to encrypt e-mail sent to me using PGP
My public key is available on PGP key servers (http://keyservers.net)
Key fingerprint: 8062 1A46 9719 C929 578C BB4E 7799 EC1A AB12 D3B9

Re: Encrypted Swap

[Ryan Mack]

Apparently some of you have missed the point.  Currently, the only way to
write any form of encryption application is to have it run setuid root so
it can lock pages in RAM.  Otherwise, files (or keys) that are encrypted
on disk may be left in an unencrypted state on swap, allowing for
potential recovery by anyone with hardware access.  Encrypted swap makes
locking pages unnecessary, which relieves many sysadmins from the anxiety
of having yet-another-setuid application installed on their server in
addition to freeing up additional pages to be swapped.

Many of you seem to think that having hardware access forfeits any
expected security, however this is not the case.  Data in hardware RAM is
not accessible to anyone but the user and root at the time the application
is running.  If the system is physically compromised, there is little way
I can think of to take root without having to at least reboot the
computer, thus destroying the unencrypted contents of RAM.

Personally, I don't run out of actual RAM often, thus keeping my swap-file
on an encrypted loopback is satisfactory.  I would imagine that this
incurs a significant overhead which may be unacceptable for swap-heavy
systems.  If Linux supported encrypted swap directly, it would reduce this
overhead by eliminating the fs layer from memory access.  I think this
would be a good thing, and should probably be suggested to the
international kernel group, since they're probably the most interested.

-Ryan

Re: Encrypted Swap

[John Polyakov]

Hello.

On Mon, 6 Aug 2001 22:55:19 -0700 (PDT)
Ryan Mack <rmack@mackman.net> wrote:

RM> Apparently some of you have missed the point.  Currently, the only way
to
RM> write any form of encryption application is to have it run setuid root
so
RM> it can lock pages in RAM.  Otherwise, files (or keys) that are
encrypted
RM> on disk may be left in an unencrypted state on swap, allowing for
RM> potential recovery by anyone with hardware access.  Encrypted swap
makes
RM> locking pages unnecessary, which relieves many sysadmins from the
anxiety
RM> of having yet-another-setuid application installed on their server in
RM> addition to freeing up additional pages to be swapped.

Hmmm, let us suppose, that i copy your crypted partition per bit to my
disk.
After it I will disassemble your decrypt programm and will find a key....

In any case, if anyone have crypted data, he MUST decrypt them.
And for it he MUST have some key.
If this is a software key, it MUST NOT be encrypted( it's obviously,
becouse in other case, what will decrypt this key?) and anyone, who have
PHYSICAL access to the machine, can get this key.
Am I wrong?


RM> -Ryan

---
WBR. //s0mbre

Re: Encrypted Swap

[Rob Landley]

On Tuesday 07 August 2001 02:27, John Polyakov wrote:

> Hmmm, let us suppose, that i copy your crypted partition per bit to my
> disk.
> After it I will disassemble your decrypt programm and will find a key....

First of all, if the machine has a decent UPS than an administrator can be 
required to manually restart it with a key disk or some such.  Unix boxen 
with batter backups don't go down much for anything short of a hardware 
failure they wouldn't automatically reboot their way past anyway, and if it 
DOES go down you have a choice between availability or security.

But if you DO want automatic reboots of a network connected box (LAN 
perhaps), you could always have a key locally stored on the hard drive that 
is NOT the one to unlock the local filesystem, but instead the key (set of 
keys) required to talk to some server to get the local filesystem's key via 
an encrypted session.  That way if the machine is compromised and this is 
noticed quickly enough (meaning a yank-and-run job won't do it, especially if 
the server's checking in with the client fairly regularly), that machine's 
access to the server can be switched off.  (And that server may be on a LAN 
rather than the internet; you can't move the box too far while you physically 
molest it...)  Of course this just relocates part of your vulnerability (to 
the central keyserver: cue mark twain "put all your eggs in one basket and 
WATCH THAT BASKET"), but requiring someone to physically crack TWO boxes to 
get your data (keyserver and encrypted client box) is bound to add a LITTLE 
extra security.  And having the central keyserver allows key rotation...  
Yeah you've got to expect they'll snoop your network traffic somehow, but 
this is the basic problem cryptography was designed to address in the first 
place, and having the key without root on the box doesn't do them too much 
good either...

And in the "central keyserver" plus "clients with USB" case you can have 
somebody manning the keyserver 24/7 and manually checking and approving all 
reboots, which should almost never happen anyway...

> In any case, if anyone have crypted data, he MUST decrypt them.
> And for it he MUST have some key.
> If this is a software key, it MUST NOT be encrypted( it's obviously,
> becouse in other case, what will decrypt this key?) and anyone, who have
> PHYSICAL access to the machine, can get this key.
> Am I wrong?

I can think of scenarios where "must" doesn't apply here.  I've never 
personally been that paranoid, but the feds pay people to be clinically 
certifiable 24/7.  (Okay, find people who are clinically certifiable and then 
hire them to do something nominally productive with it...)

> RM> -Ryan

Rob

Re: Encrypted Swap

[Christopher E. Brown]

On Mon, 6 Aug 2001, Rob Landley wrote:
>
> I can think of scenarios where "must" doesn't apply here.  I've never
> personally been that paranoid, but the feds pay people to be clinically
> certifiable 24/7.  (Okay, find people who are clinically certifiable and then
> hire them to do something nominally productive with it...)


	But sir I had to hit the scram button and set off the thermite
charges in order to preserve data security.  The purple spiders and
the dust bunnies were in league, and offing a fiendish infiltration
plot against the United Protectorate, gOD, and the CPU!  If I had not
we would have an army of cutefuzzycyberdustbunnies rampaging down the
information superhighways in a yellow steam locomotive!

Re: Encrypted Swap

[Joel Jaeggli]

can't pull over now, this is bat country...

joelja

On Tue, 7 Aug 2001, Christopher E. Brown wrote:

>
>
> On Mon, 6 Aug 2001, Rob Landley wrote:
> >
> > I can think of scenarios where "must" doesn't apply here.  I've never
> > personally been that paranoid, but the feds pay people to be clinically
> > certifiable 24/7.  (Okay, find people who are clinically certifiable and then
> > hire them to do something nominally productive with it...)
>
>
> 	But sir I had to hit the scram button and set off the thermite
> charges in order to preserve data security.  The purple spiders and
> the dust bunnies were in league, and offing a fiendish infiltration
> plot against the United Protectorate, gOD, and the CPU!  If I had not
> we would have an army of cutefuzzycyberdustbunnies rampaging down the
> information superhighways in a yellow steam locomotive!
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

-- 
--------------------------------------------------------------------------
Joel Jaeggli				       joelja@darkwing.uoregon.edu
Academic User Services			     consult@gladstone.uoregon.edu
     PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E
--------------------------------------------------------------------------
It is clear that the arm of criticism cannot replace the criticism of
arms.  Karl Marx -- Introduction to the critique of Hegel's Philosophy of
the right, 1843.

Re: Encrypted Swap

[Crutcher Dunnavant]

++ 07/08/01 10:27 +0400 - John Polyakov:
> Hello.
> 
> On Mon, 6 Aug 2001 22:55:19 -0700 (PDT)
> Ryan Mack <rmack@mackman.net> wrote:
> 
> RM> Apparently some of you have missed the point.  Currently, the only way
> to
> RM> write any form of encryption application is to have it run setuid root
> so
> RM> it can lock pages in RAM.  Otherwise, files (or keys) that are
> encrypted
> RM> on disk may be left in an unencrypted state on swap, allowing for
> RM> potential recovery by anyone with hardware access.  Encrypted swap
> makes
> RM> locking pages unnecessary, which relieves many sysadmins from the
> anxiety
> RM> of having yet-another-setuid application installed on their server in
> RM> addition to freeing up additional pages to be swapped.
> 
> Hmmm, let us suppose, that i copy your crypted partition per bit to my
> disk.
> After it I will disassemble your decrypt programm and will find a key....
> 
> In any case, if anyone have crypted data, he MUST decrypt them.
> And for it he MUST have some key.
> If this is a software key, it MUST NOT be encrypted( it's obviously,
> becouse in other case, what will decrypt this key?) and anyone, who have
> PHYSICAL access to the machine, can get this key.
> Am I wrong?

Yes, you are wrong. The encryption key for the swap space can be created
at boot time. We can wait for the hardware to give us enough entropy
into the random number gen, and make a key. Then we mount the swap
space, and all reads/writes go through that key. But the key is never
recorded. The swap data is gone, even to legitimate users of the system,
after a reboot.

It is thus perfectly reasonable to wish to encrypt swap. In addition,
there are good reasons to move in the direction of a non-All-Powerful
root user. This is what the work in capabilities begins to approach.
So simply waving your hands and saying that root can see it, so what
does it matter, is not a long term solution to the problem.

-- 
Crutcher        <crutcher@datastacks.com>
GCS d--- s+:>+:- a-- C++++$ UL++++$ L+++$>++++ !E PS+++ PE Y+ PGP+>++++
    R-(+++) !tv(+++) b+(++++) G+ e>++++ h+>++ r* y+>*$

Re: Encrypted Swap

[Evgeny Polyakov]

Hello.

On Tue, 7 Aug 2001 02:41:01 -0400
Crutcher Dunnavant <crutcher@datastacks.com> wrote:

CD> ++ 07/08/01 10:27 +0400 - John Polyakov:
>> Hello.
>> 
>> On Mon, 6 Aug 2001 22:55:19 -0700 (PDT)
>> Ryan Mack <rmack@mackman.net> wrote:
>> 
>> RM> Apparently some of you have missed the point.  Currently, the only way
>> to
>> RM> write any form of encryption application is to have it run setuid root
>> so
>> RM> it can lock pages in RAM.  Otherwise, files (or keys) that are
>> encrypted
>> RM> on disk may be left in an unencrypted state on swap, allowing for
>> RM> potential recovery by anyone with hardware access.  Encrypted swap
>> makes
>> RM> locking pages unnecessary, which relieves many sysadmins from the
>> anxiety
>> RM> of having yet-another-setuid application installed on their server in
>> RM> addition to freeing up additional pages to be swapped.
>> 
>> Hmmm, let us suppose, that i copy your crypted partition per bit to my
>> disk.
>> After it I will disassemble your decrypt programm and will find a key....
>> 
>> In any case, if anyone have crypted data, he MUST decrypt them.
>> And for it he MUST have some key.
>> If this is a software key, it MUST NOT be encrypted( it's obviously,
>> becouse in other case, what will decrypt this key?) and anyone, who have
>> PHYSICAL access to the machine, can get this key.
>> Am I wrong?

CD> Yes, you are wrong. The encryption key for the swap space can be created
CD> at boot time. We can wait for the hardware to give us enough entropy
CD> into the random number gen, and make a key. Then we mount the swap
CD> space, and all reads/writes go through that key. But the key is never
CD> recorded. The swap data is gone, even to legitimate users of the system,
CD> after a reboot.

And what program will access to timer or any other clock or any other hardware?
What programm will generate this key?
This program and key generation algorithm can not be encrypted.
Yes?
If this is true, we read this one and generate our key.
Am wrong again?

P.S. We don't look at the e-cards and other removable devices, isn't it?

CD> It is thus perfectly reasonable to wish to encrypt swap. In addition,
CD> there are good reasons to move in the direction of a non-All-Powerful
CD> root user. This is what the work in capabilities begins to approach.
CD> So simply waving your hands and saying that root can see it, so what
CD> does it matter, is not a long term solution to the problem.

CD> Crutcher        <crutcher@datastacks.com>
CD> GCS d--- s+:>+:- a-- C++++$ UL++++$ L+++$>++++ !E PS+++ PE Y+ PGP+>++++
CD> R-(+++) !tv(+++) b+(++++) G+ e>++++ h+>++ r* y+>*$

---
WBR. //s0mbre

Re: Encrypted Swap

[Ryan Mack]

> Hmmm, let us suppose, that i copy your crypted partition per bit to my
> disk.
> After it I will disassemble your decrypt programm and will find a key....
>
> In any case, if anyone have crypted data, he MUST decrypt them.
> And for it he MUST have some key.
> If this is a software key, it MUST NOT be encrypted( it's obviously,
> becouse in other case, what will decrypt this key?) and anyone, who have
> PHYSICAL access to the machine, can get this key.
> Am I wrong?

I think the point you are missing is that encrypted swap only needs to be
accessible for one power cycle.  Thus the computer can generate a key at
swapon using a cryptographically strong random number source.  The key is
kept in RAM.  When the computer powercycles again, the old key is lost
from RAM, and a new key is generated.  The old key, and thus the old
encrypted contents of swap, are permenently lost.

-Ryan

Re: Encrypted Swap

[Evgeny Polyakov]

Hello.

On Mon, 6 Aug 2001 23:45:33 -0700 (PDT)
Ryan Mack <rmack@mackman.net> wrote:

>> Hmmm, let us suppose, that i copy your crypted partition per bit to my
>> disk.
>> After it I will disassemble your decrypt programm and will find a key....
>>
>> In any case, if anyone have crypted data, he MUST decrypt them.
>> And for it he MUST have some key.
>> If this is a software key, it MUST NOT be encrypted( it's obviously,
>> becouse in other case, what will decrypt this key?) and anyone, who have
>> PHYSICAL access to the machine, can get this key.
>> Am I wrong?

RM> I think the point you are missing is that encrypted swap only needs to be
RM> accessible for one power cycle.  Thus the computer can generate a key at
No, computer can not do this.
This will do some program,and this program is not crypted.
Yes?
We disassemle this program, get algorithm and regenerate a key in evil machine?
Am i wrong?

P.S. off-topic What algorithm do you want to use to regenerate a key for once crypted data?
I don't know anyone, or i can't understand your point of view.

RM> -Ryan

---
WBR. //s0mbre

Re: Encrypted Swap

[Sean Hunter]

On Tue, Aug 07, 2001 at 11:08:38AM +0400, Evgeny Polyakov wrote:
> Hello.
> 
> On Mon, 6 Aug 2001 23:45:33 -0700 (PDT)
> Ryan Mack <rmack@mackman.net> wrote:
> 
> >> Hmmm, let us suppose, that i copy your crypted partition per bit to my
> >> disk.
> >> After it I will disassemble your decrypt programm and will find a key....
> >>
> >> In any case, if anyone have crypted data, he MUST decrypt them.
> >> And for it he MUST have some key.
> >> If this is a software key, it MUST NOT be encrypted( it's obviously,
> >> becouse in other case, what will decrypt this key?) and anyone, who have
> >> PHYSICAL access to the machine, can get this key.
> >> Am I wrong?
> 
> RM> I think the point you are missing is that encrypted swap only needs to be
> RM> accessible for one power cycle.  Thus the computer can generate a key at
> No, computer can not do this.

This is nonsense.  Of course the computer can do this.  This is exactly what we
already do for TCP sequence numbers, disk UUIDS, and many other things.
Granted, we need a little more initial entropy, but the principle has already
been established.

Remember that this is not the same as a crypted filesystem in that no user
(even root) need ever have any access to the key.  That's important.  Because
the swapspace is essentially wiped at powerup, the system can happily gen a new
key every boot, crypt away and never let the users know the key at all.

> This will do some program,and this program is not crypted.
> Yes?

So what?  The program can utilise entropy present in the system by reading from
/dev/random and generate a cryptographically-strong key.  Just because you know
my algorithm doesn't mean you've broken my code.  That is the essense of proper
cryptography- that knowlege of the algo doesn't break it.

> We disassemle this program, get algorithm and regenerate a key in evil machine?
> Am i wrong?

Of course you are wrong.  Try this pseudo-code:

1)READ X BYTES FROM STRONG RANDOM SOURCE
2)KEEP IT IN MEMORY AND USE IT AS KEY
3)USE STRONG SYMMETRICAL CYPHER TO ENCRYPT WRITES TO SWAP AND DECRYPT WRITES FROM 
SWAP

Right, now you, (as black hat) have physically stolen my machine.  Remember
that in order to do that you need to turn the power off.  You know my
algorithim for key generation: how do you recover the key?

You can't, because the key only ever lived in RAM and that RAM has been
discharged.

Can you get my key by looking at the algorithm?  No, of course you can't.

Can you get the key by looking at the swap space?  No you can't unless he can
reverse the encryption algorithm.  I assuming we're not going to use ROT13 here.

Can you recover the contents of the swap without the key?  No you can't unless
the encryption algo is broken.

> 
> P.S. off-topic What algorithm do you want to use to regenerate a key for once crypted data?
> I don't know anyone, or i can't understand your point of view.

You don't.  Swap is only good for one power-cycle anyway, regardless of
encryption.  As such, the legitimate user won't ever need to regenerate the
key.  Since black hat can't root, they can't get the key (assuming physical
security is OK), and after reboot they can't recover the contents of the swap
space because it is encrypted.  So even if they nick the machine/drive/whatever
they can't get the swap contents after the power has been cycled and the key
lost.

Sean

Re: Encrypted Swap

[Ben Ford]

Sean Hunter wrote:

>You don't.  Swap is only good for one power-cycle anyway, regardless of
>encryption.  As such, the legitimate user won't ever need to regenerate the
>key.  Since black hat can't root, they can't get the key (assuming physical
>security is OK), and after reboot they can't recover the contents of the swap
>space because it is encrypted.  So even if they nick the machine/drive/whatever
>they can't get the swap contents after the power has been cycled and the key
>lost.
>

Until someone figures out how to dump the key to disk.

-- 
Please note - If you do not have the same beliefs as we do, you are
going to burn in Hell forever.

RE: Encrypted Swap

[Kevin Krieser]

I guess you don't want to run a laptop computer, or even on a good UPS,
since you could just steal the UPS too, and leave the computer running :)

-----Original Message-----
From: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Sean Hunter
Sent: Tuesday, August 07, 2001 2:23 AM
To: Evgeny Polyakov
Cc: Ryan Mack; linux-kernel@vger.kernel.org
Subject: Re: Encrypted Swap


Right, now you, (as black hat) have physically stolen my machine.  Remember
that in order to do that you need to turn the power off.  You know my
algorithim for key generation: how do you recover the key?

RE: Encrypted Swap

[Richard B. Johnson]

On Tue, 7 Aug 2001, Kevin Krieser wrote:

> I guess you don't want to run a laptop computer, or even on a good UPS,
> since you could just steal the UPS too, and leave the computer running :)
> 
> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org
> [mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Sean Hunter
> Sent: Tuesday, August 07, 2001 2:23 AM
> To: Evgeny Polyakov
> Cc: Ryan Mack; linux-kernel@vger.kernel.org
> Subject: Re: Encrypted Swap
> 
> 
> Right, now you, (as black hat) have physically stolen my machine.  Remember
> that in order to do that you need to turn the power off.  You know my
> algorithim for key generation: how do you recover the key?
> 

A kind word and a gun?

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re[2]: Encrypted Swap

[s0mbre]

Hello.

KK> I guess you don't want to run a laptop computer, or even on a good UPS,
KK> since you could just steal the UPS too, and leave the computer running :)

KK> -----Original Message-----
KK> From: linux-kernel-owner@vger.kernel.org
KK> [mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Sean Hunter
KK> Sent: Tuesday, August 07, 2001 2:23 AM
KK> To: Evgeny Polyakov
KK> Cc: Ryan Mack; linux-kernel@vger.kernel.org
KK> Subject: Re: Encrypted Swap


KK> Right, now you, (as black hat) have physically stolen my machine.  Remember
KK> that in order to do that you need to turn the power off.  You know my
KK> algorithim for key generation: how do you recover the key?

"But, as you are aware, there are other way to get information.  And
with a pair of pliers and a blowtorch.."
(c) Chris Wedgwood


---
WBR. //s0mbre

Re[2]: Encrypted Swap (random off-topic snippet)

[Dr. Kelsey Hudson]

On Tue, 7 Aug 2001, s0mbre wrote:

> "But, as you are aware, there are other way to get information.  And
> with a pair of pliers and a blowtorch.."
> (c) Chris Wedgwood

I do believe that's an excerpt from a line from the movie "Pulp Fiction,"
written and directed by Quentin Tarrantino.

The full line is (if memory serves me right):

"What now? I'll tell you what now. I'm gonna get me some hard,
 pipe-hittin' n***as, and they're gonna go to work on mr.
 soon-to-be-livin'-the-rest-of-his-short-ass-life-in-agonizing-pain
 rapist here with a pair of pliers and a blowtorch. That's what now."

I really shouldn't pollute the list like this.

 Kelsey Hudson                                           khudson@ctica.com
 Software Engineer
 Compendium Technologies, Inc                               (619) 725-0771
---------------------------------------------------------------------------

Re: Encrypted Swap (random off-topic snippet)

[Michael H. Warfield]

On Tue, Aug 07, 2001 at 07:24:50PM -0700, Dr. Kelsey Hudson wrote:
> I really shouldn't pollute the list like this.

	Perfect.  :-)

	It's what we, sometimes, refer to as "rubber hose security"
and what Bruce Schneier has been heard to refer to as "rubber hose
cryptography".  You grap someone and beat the #$@#$# out of them with
a rubber hose till they tell you what they want to know.  The BEST we
can hope for is to raise the secuity to the point where they (whoever
"THEY" are) can do no better than that.  :-/  If we HAVEN'T raised it
that far, we still have more we can, and should, do.


>  Kelsey Hudson                                           khudson@ctica.com
>  Software Engineer
>  Compendium Technologies, Inc                               (619) 725-0771
> ---------------------------------------------------------------------------

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  (The Mad Wizard)      |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

RE: Encrypted Swap

[Ignacio Vazquez-Abrams]

On Tue, 7 Aug 2001, Kevin Krieser wrote:

> I guess you don't want to run a laptop computer, or even on a good UPS,
> since you could just steal the UPS too, and leave the computer running :)

**BEEEEP** *Beeep* *beep*

"Uh oh, someone's stolen the computer again!"

"Damn, that's the THIRD time this week!"

-- 
Ignacio Vazquez-Abrams  <ignacio@openservices.net>

Re: Encrypted Swap

[Ryan Mack]

> No, computer can not do this.
> This will do some program,and this program is not crypted.
> Yes?
> We disassemle this program, get algorithm and regenerate a key in evil machine?
> Am i wrong?

Any algoritm can be reproduced, yes, but a strong random number source
cannot.  See my other email for an example of such.

> P.S. off-topic What algorithm do you want to use to regenerate a key for once crypted data?
> I don't know anyone, or i can't understand your point of view.

If the algorithm is strong enough, the only method is a brute force search
of the entire keyspace, which in the case of a 2048 bit key would take
much longer than the age of the universe, even using a billion times the
total computational power of the earth.  Simple algoritms are subject to
frequency analysis and other more subtle analysis.  Pick up a copy of
"Applied Cryptography" by Bruce Schneier for a generaly overview of the
field.

Re: Encrypted Swap

[Jeffrey Considine]

> >> Hmmm, let us suppose, that i copy your crypted partition per bit to my
> >> disk.
> >> After it I will disassemble your decrypt programm and will find a key....
> >>
> >> In any case, if anyone have crypted data, he MUST decrypt them.
> >> And for it he MUST have some key.
> >> If this is a software key, it MUST NOT be encrypted( it's obviously,
> >> becouse in other case, what will decrypt this key?) and anyone, who have
> >> PHYSICAL access to the machine, can get this key.
> >> Am I wrong?

The key can be locked into memory. Locking just the key is better than
running setuid root to lock the whole application.

> RM> I think the point you are missing is that encrypted swap only needs to be
> RM> accessible for one power cycle.  Thus the computer can generate a key at
> No, computer can not do this.
> This will do some program,and this program is not crypted.
> Yes?
> We disassemle this program, get algorithm and regenerate a key in evil machine?
> Am i wrong?

Waiting for entropy (mentionned by RM I think) would take care of
this. However, I imagine it takes a while to build up enough random
bits, especially if no users are logged on and the network isn't
up. Stalling for entropy before setting up the swap partition is
probably not a good idea. Switching keys from predictable to really
random or delaying encryption sounds expensive and/or messy and would
leave a small window right after booting where the swap file could be
decrypted relatively easily.

Perhaps a cheaper alternative that wouldn't really slow down most
applications would be to add a flag set by a system call toggling
whether the page was encrypted in the swap file. That way most
applications don't see a performance difference. If the flag was
inheritable, the security paranoid could use a shell or wrapper to set
it and run everything through that.

jef

Re: Encrypted Swap

[Crutcher Dunnavant]

++ 07/08/01 11:08 +0400 - Evgeny Polyakov:
> Hello.
> RM> accessible for one power cycle.  Thus the computer can generate a key at
> No, computer can not do this.
> This will do some program,and this program is not crypted.
> Yes?
> We disassemle this program, get algorithm and regenerate a key in evil machine?
> Am i wrong?
> 
> P.S. off-topic What algorithm do you want to use to regenerate a key for once crypted data?
> I don't know anyone, or i can't understand your point of view.

The weakness here is in the seed we use for generating the encryption
key. This is not a fatal weakness. There are several scenarios:

a) the environment is trusted at boot. It has not been compromised, yet.
   In this scenario, the random state stored for the RG is pretty
chaotic; and we can read it in to initialize the RG, then immediatly
wipe it from disk. Assuming we are good about clearing the data, it
cannot be recovered; and the RG can be trusted to give us a good key.

In this scenario, you can not recover the key.

b) the environment is not trusted at boot. someone might have a dump of
the harddrive already, and is waiting to take a second dump.
   If we wish, we can write algorithms which induce chaos into the RG by
thrashing the page table, the cache, and the harddrives. We could devote
a second or two on boot to doing this, and get a few thousand bytes of
entropy from the /physical/ chaos we'd be playing with.
   Alternatively, physical RG devices exist; and are rather easy to
make. We install a device designed to be pyhsically chaotic, and write a
driver for it which constantly seeds the RG. This would give us very
good chaos.

In this scenario, you can not recover the key.

Do not assume that, since random number generation is patently
impossible with an algorithm; that it is impossible with a computer.
Computers /are/ machines, and minute timing differences, or devices
designed for the purpose, can be used to pull chaos out of the physical
world, and into our algorithms. In addition information which was once
predictable, but has been destroyed along with its sources, is still
lost to you.

-- 
Crutcher        <crutcher@datastacks.com>
GCS d--- s+:>+:- a-- C++++$ UL++++$ L+++$>++++ !E PS+++ PE Y+ PGP+>++++
    R-(+++) !tv(+++) b+(++++) G+ e>++++ h+>++ r* y+>*$

Re: Encrypted Swap

[Peter Wächtler]

Evgeny Polyakov wrote:
> 
> Hello.
> 
> On Mon, 6 Aug 2001 23:45:33 -0700 (PDT)
> Ryan Mack <rmack@mackman.net> wrote:
> 
> >> Hmmm, let us suppose, that i copy your crypted partition per bit to my
> >> disk.
> >> After it I will disassemble your decrypt programm and will find a key....
> >>
> >> In any case, if anyone have crypted data, he MUST decrypt them.
> >> And for it he MUST have some key.
> >> If this is a software key, it MUST NOT be encrypted( it's obviously,
> >> becouse in other case, what will decrypt this key?) and anyone, who have
> >> PHYSICAL access to the machine, can get this key.
> >> Am I wrong?
> 
> RM> I think the point you are missing is that encrypted swap only needs to be
> RM> accessible for one power cycle.  Thus the computer can generate a key at
> No, computer can not do this.
> This will do some program,and this program is not crypted.
> Yes?
> We disassemle this program, get algorithm and regenerate a key in evil machine?
> Am i wrong?
> 
> P.S. off-topic What algorithm do you want to use to regenerate a key for once crypted data?
> I don't know anyone, or i can't understand your point of view.
> 

The key genaration relies on good random numbers from a strong random
generator.
You won't be able to produce the same key twice.

Of course you can argue, that you can still manipulate the machine -
perhaps
even disabling the encryption completely or turn the random numbers into
predictable ones. But then you have to "attack" the machine at least two
times: 
a) to manipulate the machine and later 
b) to try to retrieve the data that's not "encrypted" anymore (at least
you are 
able to "decrypt" it).

So your effort grows significantly. You steal a notebook, shit: don't
have a key.
You have to manipulate it first, wait and then steal it. This is not so
simple -
but of course not completely impossible.

Re: Encrypted Swap

[Michael Bacarella]

> Apparently some of you have missed the point.  Currently, the only way to
> write any form of encryption application is to have it run setuid root so
> it can lock pages in RAM.  Otherwise, files (or keys) that are encrypted
> on disk may be left in an unencrypted state on swap, allowing for
> potential recovery by anyone with hardware access.  Encrypted swap makes
> locking pages unnecessary, which relieves many sysadmins from the anxiety
> of having yet-another-setuid application installed on their server in
> addition to freeing up additional pages to be swapped.

Not to trivialize your burden as a sys admin, but if you don't think
you're going to run into swap often (not quoted), and feel that it's
a security hazard... why not disable swap entirely?

If a system dips into swap, maybe it doesn't have enough RAM.
And if security is that important to you, dropping the cash on the
additional RAM should be a non-issue.

Besides, who can argue against more RAM?

-- 
Michael Bacarella <mbac@nyct.net>
Technical Staff / System Development,
New York Connect.Net, Ltd.

Re: Encrypted Swap

[Holger Lubitz]

Ryan Mack proclaimed:
> is running.  If the system is physically compromised, there is little way
> I can think of to take root without having to at least reboot the
> computer, thus destroying the unencrypted contents of RAM.

This is a myth. RAM survives rebooting, even after a quick power cycle
most cells will probably still be ok. And with todays memory sizes, it
would take a noticable amount of time to initialize all of it to a given
value, so most systems don't do it (just testing some bytes of every
megabyte instead).

Holger

Re: Encrypted Swap

[Richard B. Johnson]

On Fri, 17 Aug 2001, Holger Lubitz wrote:

> Ryan Mack proclaimed:
> > is running.  If the system is physically compromised, there is little way
> > I can think of to take root without having to at least reboot the
> > computer, thus destroying the unencrypted contents of RAM.
> 
> This is a myth. RAM survives rebooting, even after a quick power cycle
> most cells will probably still be ok. And with todays memory sizes, it
> would take a noticable amount of time to initialize all of it to a given
> value, so most systems don't do it (just testing some bytes of every
> megabyte instead).
> 
> Holger
> -

Errrm no. All BIOS that anybody would use write all memory found when
initializing the SDRAM controller. They need to because nothing,
refresh, precharge, (or if you've got it, parity/crc) will work
until every cell is exercised. A "warm-boot" is different. However,
if you hit the reset or the power switch, nothing in RAM survives.

The BIOS procedure necessary to size RAM, and find out what sticks
are in what slots, is quite a memory-distructor itself. With SDRAM
controllers, after the reset, all memory addresses are ignored.
A write to memory writes to ALL memory plus the controller itself.
You typically set up the controller by writing some commands to
address 0. Once there is a power-up, the BIOS must delay at least
100 us before trying to initialize the SDRAM controller. The
"all banks precharge" command connects all banks together and
anything they contained is lost forever. This is the first command
necessary to initialize the SDRAM controller. All the command bits
are driven as 12 bits and they are sinked by every cell on every
chip because the all-banks precharge hooked them together. So, even
if by some magic the cells had survived the power-cycle, the lowest
12 bits in every long-word will now be corrupted by the initialization
commands that follow.

The so-called "quick" memory test just doesn't test the memory which
typically involves setting/resetting/checking every bit in memory. The
initialiation, sizing and the zeroing still occurs.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re: Encrypted Swap

[Holger Lubitz]

"Richard B. Johnson" proclaimed:

> Errrm no. All BIOS that anybody would use write all memory found when
> initializing the SDRAM controller. They need to because nothing,
> refresh, precharge, (or if you've got it, parity/crc) will work
> until every cell is exercised. A "warm-boot" is different. However,
> if you hit the reset or the power switch, nothing in RAM survives.

Then this may have changed with SDRAM. However, back in my Amiga days it
was pretty common to just reset the machine and rip whatever was left in
the memory (DRAM). If memory serves me right, some people put in reset
protection (by pointing the reset vector to some code that cleared the
memory), which could be fooled by hardware reset or power cycling.

Holger

Re: Encrypted Swap

[Gerhard Mack]

On Fri, 17 Aug 2001, Holger Lubitz wrote:

> "Richard B. Johnson" proclaimed:
> 
> > Errrm no. All BIOS that anybody would use write all memory found when
> > initializing the SDRAM controller. They need to because nothing,
> > refresh, precharge, (or if you've got it, parity/crc) will work
> > until every cell is exercised. A "warm-boot" is different. However,
> > if you hit the reset or the power switch, nothing in RAM survives.
> 
> Then this may have changed with SDRAM. However, back in my Amiga days it
> was pretty common to just reset the machine and rip whatever was left in
> the memory (DRAM). If memory serves me right, some people put in reset
> protection (by pointing the reset vector to some code that cleared the
> memory), which could be fooled by hardware reset or power cycling.
> 

My Apple IIc's manual recommended waiting 15 seconds before turning the
machine back on in order to wait for the memory to clear.  I wonder how
long SDRAM lasts if actually removed instead of letting the BIOS clear it
on boot.

	Gerhard


--
Gerhard Mack

gmack@innerfire.net

<>< As a computer I find your faith in technology amusing.

Re: Encrypted Swap

[Richard B. Johnson]

On Fri, 17 Aug 2001, Holger Lubitz wrote:

> "Richard B. Johnson" proclaimed:
> 
> > Errrm no. All BIOS that anybody would use write all memory found when
> > initializing the SDRAM controller. They need to because nothing,
> > refresh, precharge, (or if you've got it, parity/crc) will work
> > until every cell is exercised. A "warm-boot" is different. However,
> > if you hit the reset or the power switch, nothing in RAM survives.
> 
> Then this may have changed with SDRAM. However, back in my Amiga days it
> was pretty common to just reset the machine and rip whatever was left in
> the memory (DRAM). If memory serves me right, some people put in reset
> protection (by pointing the reset vector to some code that cleared the
> memory), which could be fooled by hardware reset or power cycling.
> 
> Holger

Yes, even in the early PC-XT and PC/AT, where the DMA controller was
used for refresh, it was quite possible to reset the machine and
have RAM contents (except for the first 1 megabyte) remain untouched.
The first 1 megabyte was cleared, actually the first 640k, because
the boot code depended upon this. It didn't clear RAM used for
temporary variables.

But, now-days, you can't reset the machine without killing whatever
is in RAM.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re: Encrypted Swap

[Adrian Cox]

Richard B. Johnson wrote:
> Errrm no. All BIOS that anybody would use write all memory found when
> initializing the SDRAM controller. They need to because nothing,
> refresh, precharge, (or if you've got it, parity/crc) will work
> until every cell is exercised. A "warm-boot" is different. However,
> if you hit the reset or the power switch, nothing in RAM survives.

This does not match my experience building SDRAM based embedded systems. 
Initialising SDRAM simply tells the chips what CAS latency to use, and 
does not erase the contents. SDRAM is fully functional before you have 
written to every cell.

It's possible that JEDEC standards recommend that boot firmware should 
erase the contents, and it is certainly necessary to erase before 
enabling ECC or parity error detection.

-- 
Adrian Cox   http://www.humboldt.co.uk/

Re: Encrypted Swap

[Richard B. Johnson]

On Fri, 17 Aug 2001, Adrian Cox wrote:

> Richard B. Johnson wrote:
> > Errrm no. All BIOS that anybody would use write all memory found when
> > initializing the SDRAM controller. They need to because nothing,
> > refresh, precharge, (or if you've got it, parity/crc) will work
> > until every cell is exercised. A "warm-boot" is different. However,
> > if you hit the reset or the power switch, nothing in RAM survives.
> 
> This does not match my experience building SDRAM based embedded systems. 
> Initialising SDRAM simply tells the chips what CAS latency to use, and 
> does not erase the contents. SDRAM is fully functional before you have 
> written to every cell.
> 
> It's possible that JEDEC standards recommend that boot firmware should 
> erase the contents, and it is certainly necessary to erase before 
> enabling ECC or parity error detection.
> 

Snippet from SDRAM initialization in BIOS........

;-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
;
;	This is a cold boot so set up the SDRAM Controller. I do not
;	do "auto-sizing" because the size of the installed RAM is known.
;
	XOR	EAX,EAX				; Zero
	MOV	SS,AX				; Clear segment registers
	MOV	ES,AX				; except DS = MCR_SEG
	MOV	FS,AX
	MOV	GS,AX
	MOV	EBP,EAX				; SS=EBP=EAX=0
	MOV	SP,0FFFEH			; Just park it somewere
	MOV	BYTE PTR DS:[DRCCTL],01H	; Refresh disable
	MOV	[EBP],EAX			; This forces the command out
	MOV	BYTE PTR DS:[DRCCTL],02H	; All banks precharge
	MOV	[EBP],EAX			; This forces the command out

** At this instant, you just killed everything in RAM with precharge **

;
IF	(RAM_SIZE EQ 128)
;-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
;
;	All banks enabled, 64 meg size each (128 megabytes).
;
	MOV	 BYTE PTR DS:[DRCTMCTL], 01EH
	MOV	 WORD PTR DS:[DRCCFG], 09999H
	MOV	DWORD PTR DS:[DRCBENDADR], 0A0989088H
ELSEIF	(RAM_SIZE EQ 64)
;-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
;
;	One bank enabled, 64 meg size.
;
	MOV	 BYTE PTR DS:[DRCTMCTL], 01EH
	MOV	 WORD PTR DS:[DRCCFG], 00909H
	MOV	DWORD PTR DS:[DRCBENDADR], 000900088H

ELSEIF	(RAM_SIZE EQ 32)
;-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
;
;	Analogic memory mezzanine, 32 meg size.
;	Eight, 4 megabyte blocks.
;
	MOV	 BYTE PTR DS:[DRCTMCTL], 01EH
	MOV	 WORD PTR DS:[DRCCFG], 08888H
	MOV	DWORD PTR DS:[DRCBENDADR], 08884H
ELSE
	%OUT	RAM Size not correctly defined.
	.ERR1
ENDIF
;-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
;
;	Two auto-refreshes.
;
	MOV	BYTE PTR DS:[DRCCTL],04H
	MOV	[EBP],EAX
	MOV	[EBP],EAX
;
;	Load mode register command.
;
	MOV	BYTE PTR DS:[DRCCTL],03H
	MOV	[EBP],EAX			; This forces the command out
;
;	Back to normal mode, refresh enable 15.6 us.
;
	MOV	BYTE PTR DS:[DRCCTL],18H
	MOV	[EBP],EAX			; This forces the command out
;
;	Okay, RAM should be working. Clear low 1 megabyte and try it.
;


I think you forgot what you did when setting up the SDRAM controller.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

RE: Encrypted Swap

[Jacob Alifrangis]

Is vger.rutgers.edu still valid?

I keep getting bounced messages from it.

is there anotehr place for the mailing lists now?

Re: Encrypted Swap

[Adrian Cox]

Richard B. Johnson wrote:
> 
> ** At this instant, you just killed everything in RAM with precharge **

I've done a bit more reading. The documentation I have here suggests the 
precharge doesn't erase all of memory.  Precharge copies from the sense 
amplifiers back into the current row. The erasure is a result of the 
sense amplifiers losing their contents faster than the memory cells, but 
even so only one of the 2^12 rows gets erased.
-- 
Adrian Cox   http://www.humboldt.co.uk/

Re: Encrypted Swap

[Nicholas Knight]

On Friday 17 August 2001 10:36 am, Adrian Cox wrote:
> Richard B. Johnson wrote:
> > ** At this instant, you just killed everything in RAM with precharge
> > **
>
> I've done a bit more reading. The documentation I have here suggests
> the precharge doesn't erase all of memory.  Precharge copies from the
> sense amplifiers back into the current row. The erasure is a result of
> the sense amplifiers losing their contents faster than the memory
> cells, but even so only one of the 2^12 rows gets erased.

Now that we've established that SDRAM doesn't neccisarily get erased from 
rebooting, does anyone know how long it takes for SDRAM to clear after 
losing power? It seems to me that the fact that the RAM isn't neccisarily 
wiped by the BIOS at boot is less important than wether or not shutting 
down the system and having it shut down for 10 minutes causes the RAM to 
be cleared so that any intruder/thief would be unable to get the 
information neccisary to decrypt the swap...

Re: Encrypted Swap

[Richard B. Johnson]

On Fri, 17 Aug 2001, Nicholas Knight wrote:

> On Friday 17 August 2001 10:36 am, Adrian Cox wrote:
> > Richard B. Johnson wrote:
> > > ** At this instant, you just killed everything in RAM with precharge
> > > **
> >
> > I've done a bit more reading. The documentation I have here suggests
> > the precharge doesn't erase all of memory.  Precharge copies from the
> > sense amplifiers back into the current row. The erasure is a result of
> > the sense amplifiers losing their contents faster than the memory
> > cells, but even so only one of the 2^12 rows gets erased.
> 
> Now that we've established that SDRAM doesn't neccisarily get erased from 
> rebooting, does anyone know how long it takes for SDRAM to clear after 
> losing power? It seems to me that the fact that the RAM isn't neccisarily 
> wiped by the BIOS at boot is less important than wether or not shutting 
> down the system and having it shut down for 10 minutes causes the RAM to 
> be cleared so that any intruder/thief would be unable to get the 
> information neccisary to decrypt the swap...

We've established no such thing. In fact, you can't properly initialize
SDRAM memory without writing something to it. Further, reading SDRAM
after a power-on or a reset, will result in all 1s (0xffffffff) because
the SDRAM controller isn't even connected to the RAM. Further, in the
process of connecting it up (logically), the lowest 15 bits of all
SDRAM commands will end up being written to every chip. With SDRAM,
data are normally clocked in/out, once the precharge command is
executed, it's not even clocked. It works like this:

(1) Put a memory controller command in a controller register.
(2) Attempt to write RAM (anywhere), that makes the controller read
    and acccept the command.
(3) Continue with all commands. The last enables refresh.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re: Encrypted Swap

[Adrian Cox]

Richard B. Johnson wrote:
> We've established no such thing. In fact, you can't properly initialize
> SDRAM memory without writing something to it. 

After all of this theory it was time to do some experiments. I modified 
the BIOS on my current PowerPC system to compare memory against a test 
pattern (I chose 0x31415926 incrementing by 0x27182817) over the address 
range 0x0 to 0x100000. This pattern has approximately 50% 1s and 50% 0s.

On pressing the reset button, I got 100% of bits holding the same value. 
If I turn the power off for 20s, I get approximately 90% of bits holding 
the same value. After a minute, it's dropped to the 50% level, which I 
take as random.

For added fun, I then tried turning off, pulling out the DIMM, plugging 
it into the other slot, and turning back on. 97% of the bits had the 
original value. So one attack we must consider is the attacker removing 
power, ripping the DIMM out, and plugging it into a special DIMM reading 
device.

Your descriptions on how memory is started look very machine specific. 
On mine (Motorola MPC107) I write the number of row bits, column bits, 
and internal banks to the memory controller, along with the CAS latency. 
I then set MEMGO, and the memory controller precharges each bank.
-- 
Adrian Cox   http://www.humboldt.co.uk/

Re: Encrypted Swap

[Eric W. Biederman]

Adrian Cox <adrian@humboldt.co.uk> writes:

> Richard B. Johnson wrote:
> > We've established no such thing. In fact, you can't properly initialize
> > SDRAM memory without writing something to it.
> 
> After all of this theory it was time to do some experiments. I modified the BIOS
> 
> on my current PowerPC system to compare memory against a test pattern (I chose
> 0x31415926 incrementing by 0x27182817) over the address range 0x0 to
> 0x100000. This pattern has approximately 50% 1s and 50% 0s.

I'm curious was this embedded system or was it a stock PowerPC.  I
don't know of any off the shelf machines that come with BIOS source code.
 
> On pressing the reset button, I got 100% of bits holding the same value. If I
> turn the power off for 20s, I get approximately 90% of bits holding the same
> value. After a minute, it's dropped to the 50% level, which I take as random.

As another data point, I earlier tried a similiar experiment by
accident.  In that case I forgot to enable ram refresh.   And then
read and wrote patterns to the SDRAM.  In that case I could find one
or two bits wrong (but 99.99% of them correct), after only a second or
two.

> For added fun, I then tried turning off, pulling out the DIMM, plugging it into
> the other slot, and turning back on. 97% of the bits had the original value. So
> one attack we must consider is the attacker removing power, ripping the DIMM
> out, and plugging it into a special DIMM reading device.
> 
> Your descriptions on how memory is started look very machine specific. On mine
> (Motorola MPC107) I write the number of row bits, column bits, and internal
> banks to the memory controller, along with the CAS latency. I then set MEMGO,
> and the memory controller precharges each bank.

Ah you have one of the nice memory controllers.  On some you have
to do the prefreshs & co manually on others the memory controller will
do it for you.

The result here is interesting.  So while you don't loose everything
on powerdown.  About a minute after power down you do.  Not perfect
but it should be good enough to consider RAM self deleting in most
cases.  Except for the reset case which could prove very dangerous.  

For any of these attacks to prove workable you need to get a hold of
the machine while the power is still on.

So the attacker has two way to attack your machine.  Attempt to break
in while it is still running.  Put in a minimal boot cd and press
reset and see how much is recovered.  Generally breaking should prove
the more fruitful course, but the fact that reset preseves all of the
memory, means it simply is not safe for someone to have physical
access to your machine while the power is on.

Or do you read this differently?

Eric

Re: Encrypted Swap

[Adrian Cox]

Eric W. Biederman wrote:
  > I'm curious was this embedded system or was it a stock PowerPC.  I don't
  >  know of any off the shelf machines that come with BIOS source code.

It's a custom embedded system.  The designers have a few details and a
picture (the BIOS runs on cases 1 and 3) here:
http://www.varisys.co.uk/custom.html

The BIOS code is at
http://www.humboldt.co.uk/gbios.html

The BIOS is actually scriptable in TCL (Python or Perl wouldn't fit in 
the ROM). I'll port the latest version back to the Sandpoint reference 
platform soon.

  > So the attacker has two way to attack your machine.  Attempt to break
  > in while it is still running.  Put in a minimal boot cd and press
  > reset and see how much is recovered.  Generally breaking should prove
  > the more fruitful course, but the fact that reset preseves all of the
  > memory, means it simply is not safe for someone to have physical
  > access to your machine while the power is on.

Approximately true. If you have ECC memory then it will have to be 
cleared in the BIOS, because of write-back caching. The first time you 
write to a memory location, the processor reads in the whole cache line 
containing that information. If the memory wasn't cleared, the ECC codes 
for the data are wrong, and you get an unrecoverable ECC error 
interrupt. What actually happens probably depends on the BIOS version.


-- 
Adrian Cox   http://www.humboldt.co.uk/

Re: Encrypted Swap

[Richard B. Johnson]

On Sat, 18 Aug 2001, Adrian Cox wrote:

> Richard B. Johnson wrote:
> > We've established no such thing. In fact, you can't properly initialize
> > SDRAM memory without writing something to it. 
> 
> After all of this theory it was time to do some experiments. I modified 
> the BIOS on my current PowerPC system to compare memory against a test 
> pattern (I chose 0x31415926 incrementing by 0x27182817) over the address 
> range 0x0 to 0x100000. This pattern has approximately 50% 1s and 50% 0s.
> 
> On pressing the reset button, I got 100% of bits holding the same value. 
> If I turn the power off for 20s, I get approximately 90% of bits holding 
> the same value. After a minute, it's dropped to the 50% level, which I 
> take as random.
> 
> For added fun, I then tried turning off, pulling out the DIMM, plugging 
> it into the other slot, and turning back on. 97% of the bits had the 
> original value. So one attack we must consider is the attacker removing 
> power, ripping the DIMM out, and plugging it into a special DIMM reading 
> device.
> 
> Your descriptions on how memory is started look very machine specific. 
> On mine (Motorola MPC107) I write the number of row bits, column bits, 
> and internal banks to the memory controller, along with the CAS latency. 
> I then set MEMGO, and the memory controller precharges each bank.
> -- 
> Adrian Cox   http://www.humboldt.co.uk/
> 

Look. I have a boundary-scan probe hardware debugger. I can set
a breakpoint anywhere on my SC520 evaluation board and on the
target which as been in production for 1/2 year. It uses SDRAM
and, as I stated, SDRAM will lose its information as part of
the required initialization sequence. This is not theory. This
is fact.

Your idea of removing the RAM from the board and reading it
from a RAM-reader may actually show some valid data. However,
it is well thown that physical access to a machine or its
components while the power is applied and the machine is
running eliminates any possibility of security anyway.
You just keep the machine on its UPS and carry it away.

The "feds" just compile and install a module to look at
anything they want.

If you want some kind of security, you need to at least
hit the reset button before the feds carry it away.
The normal initialization of SDRAM will wipe out whatever
it has, and you can't get it back on-line without this
sequence.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re: Encrypted Swap

[Helge Hafting]

"Richard B. Johnson" wrote:
[...]
> If you want some kind of security, you need to at least
> hit the reset button before the feds carry it away.
> The normal initialization of SDRAM will wipe out whatever
> it has, and you can't get it back on-line without this
> sequence.

This initialization may be a requirement, that don't mean
it is going to happen.  Someone might crack your machine
and burn a new bios for you without RAM initialization.
Then they physically break in and take the box when
they believe there's something worth stealing in it.
(I.e. something interesting is on the disk, and the
decryption keys is in memory.)

Non-erasable bioses can of course be replaced too.
This can be done "live", as modern os'es don't use
the bios much after booting anyway.

Helge Hafting

Re: Encrypted Swap

[Ian Stirling]

<snip>
> Your idea of removing the RAM from the board and reading it
> from a RAM-reader may actually show some valid data. However,
> it is well thown that physical access to a machine or its
> components while the power is applied and the machine is
> running eliminates any possibility of security anyway.
> You just keep the machine on its UPS and carry it away.

Are there any current CPUs that can treat RAM as very fast swap, 
and be set up so that before writing a page of RAM from cache, it
gets encrypted (obviously not designed for this)
Essentially, the only data on the system that's in clear is initial boot
code, and on-chip cache.
Obviously, performance would suffer, going from Gb/s to Mb/s.

Re: Encrypted Swap

[Andreas Bombe]

On Fri, Aug 17, 2001 at 03:30:47PM -0400, Richard B. Johnson wrote:
> We've established no such thing. In fact, you can't properly initialize
> SDRAM memory without writing something to it. Further, reading SDRAM
> after a power-on or a reset, will result in all 1s (0xffffffff) because
> the SDRAM controller isn't even connected to the RAM. Further, in the
> process of connecting it up (logically), the lowest 15 bits of all
> SDRAM commands will end up being written to every chip. With SDRAM,
> data are normally clocked in/out, once the precharge command is
> executed, it's not even clocked. It works like this:

You keep referring to some unspecified SDRAM controller.  The
interesting part however is the SDRAM itself.

> (1) Put a memory controller command in a controller register.

Don't you probably mean a SDRAM command to be sent out by the
controller?

> (2) Attempt to write RAM (anywhere), that makes the controller read
>     and acccept the command.

That's just controller specific then.  It seems made to be
accessed from a CPU, which has just the limited "address & read/write"
interface.

The write obviously just triggers the command sequence but does no real
write.  It can't do a real write since that's illegal with no open
banks.  There are controllers with dedicated command inputs requiring no
write trigger, but these aren't meant to be directly connected to a CPU.

> (3) Continue with all commands. The last enables refresh.

That's your controller.  The recommended SDRAM powerup sequence is:

1. Apply power and start clock. Attempt to maintain a NOP condition at
   the inputs.
2. Maintain stable power, stable clock, and NOP input conditions for a
   minimum of 200 uS.
3. Issue precharge commands for all banks of the device.
4. Issue 8 or more autorefresh commands.
5. Issue a mode register set command to initialize the mode register.

That's all.  The controller has to be configured to work with the values
written to the mode registers, of course, but that is a separate issue.

There is no intentional data erasing in the configuration sequence
outlined above.  Missing refresh may lose some data and precharge all
banks may write back wrong data to the rows in question.  Whether the
firmware then sets out to clear RAM contents or not is the question
worth looking at, AFAIR the PC BIOS may or may not, there is no
standard.

-- 
Andreas E. Bombe <andreas.bombe@munich.netsurf.de>    DSA key 0x04880A44

Re: Encrypted Swap

[Andreas Dilger]

On Aug 17, 2001  11:51 -0700, Nicholas Knight wrote:
> Now that we've established that SDRAM doesn't neccisarily get erased from 
> rebooting, does anyone know how long it takes for SDRAM to clear after 
> losing power? It seems to me that the fact that the RAM isn't neccisarily 
> wiped by the BIOS at boot is less important than wether or not shutting 
> down the system and having it shut down for 10 minutes causes the RAM to 
> be cleared so that any intruder/thief would be unable to get the 
> information neccisary to decrypt the swap...

Hmm, it was my understanding that all PC BIOSes DO zero out memory,
although this is not necessarily a requirement of the hardware.  The
reason I say this is because one of the features of the Linux BIOS
project is to allow crashdump analysis after a reboot, by pulling
the dump from the RAM after a reboot.  You apparently are not able
to do this with normal PC BIOSes because they clear the RAM after
a reset.

That said, I'm not sure what the requirements of different kinds of
RAM chips are for initialization, so there may not be a REQUIREMENT
to clear the memory, but rather it is part of the nebulous "PC spec".

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: Encrypted Swap

[Maciej Zenczykowski]

> However, writing this got me thinking: you could potentialy go
> through swap if you're after keys for encrypted files...

So I have physical access -> I have root -> I install a kernel with
keyboard monitoring utilities -> clean up after myself and reboot -> all I
need to do now is wait...

Or am I missing something?

MaZe.

Re: Encrypted Swap

[Steve VanDevender]

John Polyakov writes:
 > Hmmm, if you have PHYSICAL access to the machine, you can simply reboot and type 
 > "linux init=/bin/sh" and after it simply cat /etc/shadow and run John The Ripper....
 > Am i wrong?

You can password-protect LILO to prevent others from giving it their own
boot options.  Similarly you can password-protect single-user mode so
either a deliberate shutdown-and-reboot to single-user mode, or an
attempt to induce the machine to go into single-user mode, will prevent
others from getting at the single-user root shell.

Re: Encrypted Swap

[Crutcher Dunnavant]

++ 07/08/01 00:34 -0700 - Steve VanDevender:
> John Polyakov writes:
>  > Hmmm, if you have PHYSICAL access to the machine, you can simply reboot and type 
>  > "linux init=/bin/sh" and after it simply cat /etc/shadow and run John The Ripper....
>  > Am i wrong?
> 
> You can password-protect LILO to prevent others from giving it their own
> boot options.  Similarly you can password-protect single-user mode so
> either a deliberate shutdown-and-reboot to single-user mode, or an
> attempt to induce the machine to go into single-user mode, will prevent
> others from getting at the single-user root shell.

Hmm. Physical access. Hammer. Take drive.

-- 
Crutcher        <crutcher@datastacks.com>
GCS d--- s+:>+:- a-- C++++$ UL++++$ L+++$>++++ !E PS+++ PE Y+ PGP+>++++
    R-(+++) !tv(+++) b+(++++) G+ e>++++ h+>++ r* y+>*$

Re: Encrypted Swap

[Garett Spencley]

On Tue, 7 Aug 2001, Steve VanDevender wrote:

> John Polyakov writes:
>  > Hmmm, if you have PHYSICAL access to the machine, you can simply reboot and type
>  > "linux init=/bin/sh" and after it simply cat /etc/shadow and run John The Ripper....
>  > Am i wrong?
>
> You can password-protect LILO to prevent others from giving it their own
> boot options.  Similarly you can password-protect single-user mode so
> either a deliberate shutdown-and-reboot to single-user mode, or an
> attempt to induce the machine to go into single-user mode, will prevent
> others from getting at the single-user root shell.

Yeah but then you can boot up the machine with a root disk and mount
whatever partition you want. If the machine doesn't have a floppy or
cd-rom you can always install one temporarily. Or if it's just data you're
after you can just steal the damn hard drive.

As I said earlier, if you have physical access to the system you have
root. The only way to prevent this is to lock the computer in a secure
room (ie: make sure you can't get in from the cieling or whatever) and
place a security guard at the door.

However after hearing some arguments I am now all for the idea
of encrypting swap for some set-ups. However, it should be optional
since not everyone needs it.

-- 
Garett Spencley

I encourage you to encrypt e-mail sent to me using PGP
My public key is available on PGP key servers (http://keyservers.net)
Key fingerprint: 8062 1A46 9719 C929 578C BB4E 7799 EC1A AB12 D3B9

Re: Encrypted Swap

[Helge Hafting]

Steve VanDevender wrote:
> 
> Justin Guyett writes:
>  > On Tue, 7 Aug 2001, David Spreen wrote:
>  >
>  > > I was just searching for swap-encryption-solutions in the lkml-archive.
>  > > Did I get the point saying ther's no way to do swap encryption
>  > > in linux right now? (Well, a swapfile in an encrypted kerneli
>  > > partition r something like that is not really what I want to
>  > > do I think).
>  >
>  > What's the benefit?  
[...] 
> It does prevent one means of recovering possibly security-critical
> information for attackers who do have physical access to the machine.

The encrypted swap device protects against the guy who steals the
harddisk.  It doesn't really protect against someone with physical
access though.

I can remove RAM live, and read it in another device.  Or replace
the cpu with an interface that simply reads all the RAM
addresses.  Sure, I'll leave a crashed machine, but I have
your precious data.  A smp machine might even survive the
cpu replacement and continue with one less cpu and
a frozen process.

Having the RAM contents will of course provide what I need to
decrypt the swap device and all mounted filesystems too.



Helge Hafting

Re: Encrypted Swap

[Crutcher Dunnavant]

++ 07/08/01 09:49 +0200 - Helge Hafting:
> Steve VanDevender wrote:
> I can remove RAM live, and read it in another device.  Or replace
> the cpu with an interface that simply reads all the RAM
> addresses.  Sure, I'll leave a crashed machine, but I have
> your precious data.  A smp machine might even survive the
> cpu replacement and continue with one less cpu and
> a frozen process.

Eek. I dont think I'm gonna sleep well on this one.
Umm, tamper-crash cases that kill the power?

-- 
Crutcher        <crutcher@datastacks.com>
GCS d--- s+:>+:- a-- C++++$ UL++++$ L+++$>++++ !E PS+++ PE Y+ PGP+>++++
    R-(+++) !tv(+++) b+(++++) G+ e>++++ h+>++ r* y+>*$

Re: Encrypted Swap

[Helge Hafting]

Crutcher Dunnavant wrote:
> 
> ++ 07/08/01 09:49 +0200 - Helge Hafting:
> > Steve VanDevender wrote:
> > I can remove RAM live, and read it in another device.  Or replace
> 
> Eek. I dont think I'm gonna sleep well on this one.
> Umm, tamper-crash cases that kill the power?

It's all about how well you protect the machine
versus how easy I can get around it.  Yanking a RAM chip
and inserting it in another pc running dos isn't hard,
with physical access.  

Killing the power isn't enough,
I have a few seconds to get the chip and can smash the
case open with force.  You need a self-destruct
device in a safe, or guards.  

A relatively cheap way might be a custom pci
card with a self-destruct RAM bank for
storing the decryption keys.  Opening the 
safe cause the card to zero the RAM.  

The key(s) exists only in this special
RAM, and processor registers during
decryption.

Helge Hafting

Re: Encrypted Swap

[Wichert Akkerman]

In article <3B6FB378.6BAD9A21@idb.hist.no>,
Helge Hafting  <helgehaf@idb.hist.no> wrote:
>A relatively cheap way might be a custom pci
>card with a self-destruct RAM bank for
>storing the decryption keys.  Opening the 
>safe cause the card to zero the RAM.  

You can do that with most PC hardware these days as well, mainboards
have an enclosure sensor you can hook up for that.

Wichert.


-- 
  _________________________________________________________________
 /       Nothing is fool-proof to a sufficiently talented fool     \
| wichert@wiggy.net                   http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: Encrypted Swap

[Chris Wedgwood]

On Tue, Aug 07, 2001 at 11:23:04AM +0200, Helge Hafting wrote:

    A relatively cheap way might be a custom pci
    card with a self-destruct RAM bank for
    storing the decryption keys.  Opening the
    safe cause the card to zero the RAM.

Custom PCI card?  You can already buy such beasts (the tamper on them
presently has no pins on it, just vacant pads, but you could attach it
to a case if you wanted).





  --cw

Re: Encrypted Swap

[Alan Cox]

> On Tue, Aug 07, 2001 at 11:23:04AM +0200, Helge Hafting wrote:
>     A relatively cheap way might be a custom pci
>     card with a self-destruct RAM bank for
>     storing the decryption keys.  Opening the
>     safe cause the card to zero the RAM.
> 
> Custom PCI card?  You can already buy such beasts (the tamper on them
> presently has no pins on it, just vacant pads, but you could attach it
> to a case if you wanted).

Since several people have asked me directly about the IBM thing

	http://www-124.ibm.com/developerworks/oss/4758/index.html

And no I've no idea how much they cost, but since it says 'and talk to a
4758 PCI specialist' I suspect its not $25 a shot 8)

Re: Encrypted Swap

[Chris Wedgwood]

On Tue, Aug 07, 2001 at 05:54:56PM +0100, Alan Cox wrote:

    Since several people have asked me directly about the IBM thing

    	http://www-124.ibm.com/developerworks/oss/4758/index.html

    And no I've no idea how much they cost, but since it says 'and
    talk to a 4758 PCI specialist' I suspect its not $25 a shot 8)

Nah, only about $2500 US --- at RSA 2001 we did a demo of Linux
running inside one.  Even the pointy heads at IBM were impressed!



  --cw

Re: Encrypted Swap

[Brian May]

>>>>> "Steve" == Steve VanDevender <stevev@efn.org> writes:

    Steve> The obvious approach to me would to generate a random
    Steve> session key at boot time and use that for
    Steve> encrypting/decrypting swap pages.  If the machine is
    Steve> unplugged and the disk pulled out, then the swap area on
    Steve> that disk could not be recovered the attacker, who

Example: disk is faulty and will no longer work. How do you guarantee
that nobody will be able to read it after you toss it out OR return it
to the manufacturer to claim for warranty?

(of course, encrypting swap space is only part of the solution, here
you need to encrypt everything).
-- 
Brian May <bam@snoopy.apana.org.au>

Re: Encrypted Swap

[Joel Jaeggli]

On 7 Aug 2001, Brian May wrote:
>
> Example: disk is faulty and will no longer work. How do you guarantee
> that nobody will be able to read it after you toss it out OR return it
> to the manufacturer to claim for warranty?

if it's bad you should think nothing of taking the dewalt cordless, and
putting a hole through the platters and the case...

> (of course, encrypting swap space is only part of the solution, here
> you need to encrypt everything).

It's clear that reiserfs is headed that direction.

You can already mount an encrypted filesystem via the loopback interface.
and there's no particular reason why you actually need swap in the
first place. There are certianly valid reasons why you want swap (not
enough memory for example) but enough ram to run without swap is a pretty
attainable target on your average desktop machine these days if you want
it(512MB is about $100 US in two dimms)

-- 
--------------------------------------------------------------------------
Joel Jaeggli				       joelja@darkwing.uoregon.edu
Academic User Services			     consult@gladstone.uoregon.edu
     PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E
--------------------------------------------------------------------------
It is clear that the arm of criticism cannot replace the criticism of
arms.  Karl Marx -- Introduction to the critique of Hegel's Philosophy of
the right, 1843.

Re: Encrypted Swap

[Chris Wedgwood]

On Tue, Aug 07, 2001 at 07:48:11AM -0700, Joel Jaeggli wrote:

    > Example: disk is faulty and will no longer work. How do you guarantee
    > that nobody will be able to read it after you toss it out OR return it
    > to the manufacturer to claim for warranty?

I'm told people do actually buy dead hard-drives that are returned for
RMA purposes.  I wonder that they do with them? :)

    if it's bad you should think nothing of taking the dewalt cordless, and
    putting a hole through the platters and the case...

A hole wouldn't suffice, you would best destroy the platters
completely (grid off the surface or melt them down).  Or better still,
both.




  --cw

Re: Encrypted Swap

[Joel Jaeggli]

It'll stop anything short of a scanning tunneling, or atomic force
microscope. if somebody with access to one of those, and the time to
recover that data wants access to your bits, you're screwed since they're
likely to tap your phone put cameras in your house and so on, I try not to
be invovled in activitiess which result in that sort of attention. ;)
the jagged metal bits and the gapping jagged hole will make short work of
any sort of magnetic head and the surface of platters if you entertain
spinning the thing...

 On Wed, 8 Aug 2001, Chris Wedgwood wrote:
>
> A hole wouldn't suffice, you would best destroy the platters
> completely (grid off the surface or melt them down).  Or better still,
> both.
>
>
>
>
>   --cw
>

-- 
--------------------------------------------------------------------------
Joel Jaeggli				       joelja@darkwing.uoregon.edu
Academic User Services			     consult@gladstone.uoregon.edu
     PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E
--------------------------------------------------------------------------
It is clear that the arm of criticism cannot replace the criticism of
arms.  Karl Marx -- Introduction to the critique of Hegel's Philosophy of
the right, 1843.

Re: Encrypted Swap

[Florian Weimer]

Joel Jaeggli <joelja@darkwing.uoregon.edu> writes:

> It'll stop anything short of a scanning tunneling, or atomic force
> microscope.

I don't think you need extremly advanced technology to recover data
(or even overwritten data) from damaged hard disks.  In some cases,
the only thing which has to be done is an electronic replacement.
Scanning the surface of individual magnetic disks for information is
probably out of the reach of the typical thief, but such service
doesn't cost a fortune anymore either.

-- 
Florian Weimer 	                  Florian.Weimer@RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

[OT] Cold, Dead Hard drives (was: Encrypted Swap)

[Stephen Satchell]

At 03:59 AM 8/8/01 +1200, Chris Wedgwood wrote:
>I'm told people do actually buy dead hard-drives that are returned for
>RMA purposes.  I wonder that they do with them? :)

The obvious answer:  take five drives and find parts for a good drive, and 
resell the drive as a refurb.

Not-so-obvious answer:  Take the dead drive as-is, package with Microsoft 
Operating System of your choice, and then auction the bundle on 
eBay.  (Dead motherboards are good for this, too.)  This is to satisfy an 
asinine rule that someone at Microsoft cooked up.

Most bogus answer:  Dump them off the coast of Florida and make an 
artificial reef.  This is what Core International, a hard drive 
distributor, claimed it was doing with trade-ins during an '80s promotion 
for drives to replace the infamous CMI 20 hard drive that IBM was shipping 
in its IBM PC AT (you know, that blazing 6-MHz 286 system that was supposed 
to revolutionize the Charlie Chaplan office environment).

Most useful answer:  Disassemble drive.  Use head field magnets on the 
fridge.  Use platters as coasters (I have a set of coated ones from a dead 
drive, and uncoated ones rejected during manufacturing that Micronet 
Technologies gave away as party favors one year).

And THAT should close this branch of the thread tree nicely...

Satch

Re: Encrypted Swap

[Dr. Kelsey Hudson]

On 7 Aug 2001, Brian May wrote:

> Example: disk is faulty and will no longer work. How do you guarantee
> that nobody will be able to read it after you toss it out OR return it
> to the manufacturer to claim for warranty?

Most people paranoid with security (US DOD, NSA, etc.) have protocol
regarding disks with classified data on them: Once classified, always
classified. A failed disk still under warranty must forfiet that warranty
to ensure data integrity. If the disk is no longer useful (eg that 575MB
disk out of the SPARCstation 2 in the corner) then it is to be destroyed
with fire and the remains slagged.

> (of course, encrypting swap space is only part of the solution, here
> you need to encrypt everything).

Encrypting everything is what DISA decided they would do with the DII COE
operating environment for Windows NT and Solaris. DISA's solution under NT
was to zero the swapfile at system shutdown as well as use an encryption
scheme similar to what has been referred to earlier in this thread. The
solution under Solaris was to do encryption only. I'm not going to go into
detail about it, but basically, everything but the filesystems on-disk
have been encrypted. DII COE is not available for public consumption as
well as export outside the US. Besides, I pity anyone who's forced to use
it. It really is a miserable thing to be forced to use.

 Kelsey Hudson                                           khudson@ctica.com
 Software Engineer
 Compendium Technologies, Inc                               (619) 725-0771
---------------------------------------------------------------------------

Re: Encrypted Swap

[Ian Stirling]

> 
> On Tue, 7 Aug 2001, David Spreen wrote:
> 
> > I was just searching for swap-encryption-solutions in the lkml-archive.
> > Did I get the point saying ther's no way to do swap encryption
> > in linux right now? (Well, a swapfile in an encrypted kerneli
> > partition r something like that is not really what I want to
> > do I think).
> 
> What's the benefit?  Sure, attackers have to know that encrypted swap is
> in use, and have to be able to find the key in memory, but they already
> can do both if they're root, and non-root can't [shouldn't be able to]
> read swap devices on a properly secured machine.  Swap isn't meant for

Consider a laptop.
It normally mounts data and swap encrypted.
it requires a passphrase to login to a user which has access to
the encrypted filesystem.

When the laptop is closed, or on an inactivity timeout, it halts normal
processing, encrypts all RAM, and then invokes the "save to disk" mechanism.

Data can only be stolen if the operator cannot shut the laptop, 
and the attacker does not do so, or if the operator can be coerced
to reveal the key.

What would be even nicer would be a way to checkpoint in a secure
manner all processes tainted by accessing a secure device.

Re: Encrypted Swap

[Andrea Arcangeli]

On Tue, Aug 07, 2001 at 04:28:10AM +0200, David Spreen wrote:
> Hey there,
> I was just searching for swap-encryption-solutions in the lkml-archive.
> Did I get the point saying ther's no way to do swap encryption
> in linux right now? (Well, a swapfile in an encrypted kerneli
> partition r something like that is not really what I want to
> do I think).

cryptoloop on the blkdev or filebacked should work just fine. However it
will increase memory pressure and it increases the probability for a
deadlock (but normal 2.4 swap activities can deadlock anyways if you do
the math).

Andrea

swap & deadlocks [was Re: Encrypted Swap]

[Pavel Machek]

Hi!

> > I was just searching for swap-encryption-solutions in the lkml-archive.
> > Did I get the point saying ther's no way to do swap encryption
> > in linux right now? (Well, a swapfile in an encrypted kerneli
> > partition r something like that is not really what I want to
> > do I think).
> 
> cryptoloop on the blkdev or filebacked should work just fine. However it
> will increase memory pressure and it increases the probability for a
> deadlock (but normal 2.4 swap activities can deadlock anyways if you do
> the math).

Can you show me the math? I guess this should be fixed...
								Pavel
OTOH if it is not fixed, I can forget about nbd swap deadlocks --they too
happen only seldom ;-)

-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.