Encrypted Swap

Encrypted Swap

[David Maynor]

The recovery of deleted information is a large danger, esp to certain 
government agencies and other people who really care that the information 
the have is never seen, but implementing such features in the kernel seems 
the wrong place to do it. In addition to the swap space, in order to be 
effective, you would need to keep the memory in an encrypted state, as well 
as your disk. Just encrypting your swap would be akin to ssh to a machine, 
telneting to another machine, then sshing to a 3rd machine. Since your 
transfer between machine one and two is in the clear, you entire security 
model at that point is comprised. Just encrypting your swap leaves the info 
vulnerable in other places.
	My suggestion is instead of worrying about the swap space, or the tmp 
space, worry about an entire OS security posture(eg. filesystem, memory, 
boot). So if a machine is stolen or comprised, there is an onion of 
security protecting you, not just one or two things.

David Maynor

Re: Encrypted Swap

[Rik van Riel]

On Tue, 7 Aug 2001, David Maynor wrote:

> 	My suggestion is instead of worrying about the swap space, or the tmp
> space, worry about an entire OS security posture(eg. filesystem, memory,
> boot). So if a machine is stolen or comprised, there is an onion of
> security protecting you, not just one or two things.

What you are saying above suspiciously sounds like:

	"I want an onion, lets leave out the layers!"

If you really want an onion, I suspect encrypted
swap will be a useful layer to have as part of your
onion...

Rik
--
Executive summary of a recent Microsoft press release:
   "we are concerned about the GNU General Public License (GPL)"


		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com/

Re: Encrypted Swap

[Ted Unangst]

On Sat, 18 Aug 2001, Eric W. Biederman wrote:

> 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.

if the machine is on, and you can get close to it, it's probably easier
just to use tempest radiation.  it will also work at a distance, so it's
more likely to be a threat than grabbing RAM chips.  a few points:

1.  not everyone is going to bring their James Bond RAM Reader (tm) into
your building to extract data.  a hardcore data thief, maybe, but it's not
common equipment.  everyone will have access to an IDE or SCSI disk
reader.

2.  RAM has a short window of oppurtunity.  whatever it turns out to be,
RAM degrades faster than disk.  it's not going to last while you drive it
home, unless you have a RAM refresher plugged in the cigarette lighter.

3.  encrypted swap is meant for a different threat model.  you assume that
the attacker might have access to the box at night or over a weekend,
while you're away.  RAM will be off.  if you think someone might be trying
to steal your RAM, you need better physical security.





--
"I am a great mayor; I am an upstanding Christian man; I am an
intelligent man; I am a deeply educated man; I am a humble man."
      - M. Barry, Mayor of Washington, DC

Re: Encrypted Swap

[Mr. James W. Laferriere]

	Hello Ted ,  Thank you for bring us back on topic .  I found the
	disertations on memory a tad enlightening .  But I was very
	interested in the original thread of encrypting swap .
		Twyl , JimL

On Sat, 18 Aug 2001, Ted Unangst wrote:
> On Sat, 18 Aug 2001, Eric W. Biederman wrote:
> > 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.
>
> if the machine is on, and you can get close to it, it's probably easier
> just to use tempest radiation.  it will also work at a distance, so it's
> more likely to be a threat than grabbing RAM chips.  a few points:
>
> 1.  not everyone is going to bring their James Bond RAM Reader (tm) into
> your building to extract data.  a hardcore data thief, maybe, but it's not
> common equipment.  everyone will have access to an IDE or SCSI disk
> reader.
>
> 2.  RAM has a short window of oppurtunity.  whatever it turns out to be,
> RAM degrades faster than disk.  it's not going to last while you drive it
> home, unless you have a RAM refresher plugged in the cigarette lighter.
>
> 3.  encrypted swap is meant for a different threat model.  you assume that
> the attacker might have access to the box at night or over a weekend,
> while you're away.  RAM will be off.  if you think someone might be trying
> to steal your RAM, you need better physical security.
       +------------------------------------------------------------------+
       | James   W.   Laferriere | System    Techniques | Give me VMS     |
       | Network        Engineer |     P.O. Box 854     |  Give me Linux  |
       | babydr@baby-dragons.com | Coudersport PA 16915 |   only  on  AXP |
       +------------------------------------------------------------------+

Re: Encrypted Swap

[Helge Hafting]

Ted Unangst wrote:

> 1.  not everyone is going to bring their James Bond RAM Reader (tm) into
> your building to extract data.  a hardcore data thief, maybe, but it's not
> common equipment.  everyone will have access to an IDE or SCSI disk
> reader.
> 
Everybody has access to a RAM reader.  It is called a "pc".  Bring
one that has battery power and spare slots to plug the stolen
modules into.  You don't need Q to do this.

> 2.  RAM has a short window of oppurtunity.  whatever it turns out to be,
> RAM degrades faster than disk.  it's not going to last while you drive it
> home, unless you have a RAM refresher plugged in the cigarette lighter.

Again, a pc with a 12v adapter is the poor man's in-car ram refresher.
:-)

> 3.  encrypted swap is meant for a different threat model.  you assume that
> the attacker might have access to the box at night or over a weekend,
> while you're away.  RAM will be off.  if you think someone might be trying
> to steal your RAM, you need better physical security.

Exactly.

Helge Hafting

RE: Encrypted Swap

[David Christensen]

> > 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.

Most modern firmware does NOT clear memory during POST, it takes too long.
Certain compatibility areas are usually cleared (such as the 1st megabyte)
but the rest is
left as is, except for a few read/writes (usually on a megabyte boundary).
The 
exception to this rule is ECC systems.  They have to be written to make sure
the 
ECC information is correct.  

SDRAM memory sizing is usually done by reading an EEPROM on the SDRAM DIMM.
The BIOS doesn't need to guess the correct timing values, it simply reads
the EEPROM and programs the memory controller.  In the case of a BIOS that
doesn't use EEPROM you might lose data as the BIOS iteratively tries 
different memory timings and tests if they work.

I have done work implementing ACPI S3 (suspend-to-RAM) in DOS by simply
hitting 
the RESET button and restoring the memory controller settings.  The contents
of 
RAM have always been valid.

David Christensen

RE: Encrypted Swap

[Richard B. Johnson]

On Fri, 17 Aug 2001, David Christensen 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.
> 
> Most modern firmware does NOT clear memory during POST, it takes too long.
> Certain compatibility areas are usually cleared (such as the 1st megabyte)
> but the rest is
> left as is, except for a few read/writes (usually on a megabyte boundary).
> The 
> exception to this rule is ECC systems.  They have to be written to make sure
> the 
> ECC information is correct.  
> 
> SDRAM memory sizing is usually done by reading an EEPROM on the SDRAM DIMM.
> The BIOS doesn't need to guess the correct timing values, it simply reads
> the EEPROM and programs the memory controller.  In the case of a BIOS that
> doesn't use EEPROM you might lose data as the BIOS iteratively tries 
> different memory timings and tests if they work.
> 
> I have done work implementing ACPI S3 (suspend-to-RAM) in DOS by simply
> hitting 
> the RESET button and restoring the memory controller settings.  The contents
> of 
> RAM have always been valid.
> 
> David Christensen
> 

I just posted working SDRAM controller initialization code. The SDRAM
controller must be initialized in a specific step-by-step manner or
else you don't even get to "restoring the memory controller settings".


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

[Eric W. Biederman]

"Richard B. Johnson" <root@chaos.analogic.com> writes:

> On Fri, 17 Aug 2001, David Christensen wrote:
> 
> > > > Ryan Mack proclaimed:
> > Most modern firmware does NOT clear memory during POST, it takes too long.

Clearing memory on most machines takes a 1s or less.  Think of memory
fill rates at the 800MB/s level.  Most BIOS's seem to clear some of
the memory but I haven't read their code to see what they are doing.

> > Certain compatibility areas are usually cleared (such as the 1st megabyte)
> > but the rest is
> > left as is, except for a few read/writes (usually on a megabyte boundary).
> > The 
> > exception to this rule is ECC systems.  They have to be written to make sure
> > the 
> > ECC information is correct.  
Correct.

> > SDRAM memory sizing is usually done by reading an EEPROM on the SDRAM DIMM.
> > The BIOS doesn't need to guess the correct timing values, it simply reads
> > the EEPROM and programs the memory controller.  In the case of a BIOS that
> > doesn't use EEPROM you might lose data as the BIOS iteratively tries 
> > different memory timings and tests if they work.

This would totally depend on your controller.  But different timings
shouldn't affect your memory cells just the read/write paths to your
memory.

> > I have done work implementing ACPI S3 (suspend-to-RAM) in DOS by simply
> > hitting 
> > the RESET button and restoring the memory controller settings.  The contents
> > of 
> > RAM have always been valid.

Hmm.  That sounds a little risky.  I have measured single bit errors
occuring as early as 1s after writing the data without somekind of
refresh running.

> > David Christensen
> > 
> 
> I just posted working SDRAM controller initialization code. The SDRAM
> controller must be initialized in a specific step-by-step manner or
> else you don't even get to "restoring the memory controller settings".

Comments frequently don't match the code.  And how the SDRAM controller
must be initialized totally depends on the chipset and vendor.  SDRAM
itself must be initialized in a specific matter.  

But for the case of a warm reset there is not need to reset the SDRAM
controller.  Memory really only needs to be cleared in the case when
some form of error checking is being used.

Personally I think writing such code carries more credibility then
simply posting it anyway....

Eric

Re: Encrypted Swap

[Dan Hollis]

On 17 Aug 2001, Eric W. Biederman wrote:
> Clearing memory on most machines takes a 1s or less.  Think of memory
> fill rates at the 800MB/s level.  Most BIOS's seem to clear some of
> the memory but I haven't read their code to see what they are doing.

Ive measured rates far lower than that, at least for SDRAM.

http://bani.anime.net/memspeed/

-Dan

-- 
[-] Omae no subete no kichi wa ore no mono da. [-]

Re: Encrypted Swap

[Eric W. Biederman]

Dan Hollis <goemon@anime.net> writes:

> On 17 Aug 2001, Eric W. Biederman wrote:
> > Clearing memory on most machines takes a 1s or less.  Think of memory
> > fill rates at the 800MB/s level.  Most BIOS's seem to clear some of
> > the memory but I haven't read their code to see what they are doing.
> 
> Ive measured rates far lower than that, at least for SDRAM.

Hmm.  The numbers were off the top of my head and I've been messing
with DDR SDRAM quite a bit so I may have doubled it.   Hmm.

Nope.  I was remember something close to the typical streams numbers
on an Athlon with DDR SDRAM.  Since those are read-modify-write
numbers they should be close to the write numbers for normal SDRAM.

With a PII/PIII and PC100 SDRAM I have measured about 640 MB/s writes.

> http://bani.anime.net/memspeed/

However just looking at your numbers, I would guess that there is
something off.  Read numbers should almost always be worse then write
numbers on SDRAM, because reads have a latency between the command and
the first data cycle.  Writes do not have that delay.  

Compare what you have to streams.  But those numbers from Memtest.c
don't look correct at all.

Eric

Re: Encrypted Swap

[Nicholas Knight]

On Saturday 18 August 2001 02:52 am, Eric W. Biederman wrote:
> Dan Hollis <goemon@anime.net> writes:
> > On 17 Aug 2001, Eric W. Biederman wrote:
> > > Clearing memory on most machines takes a 1s or less.  Think of
> > > memory fill rates at the 800MB/s level.  Most BIOS's seem to clear
> > > some of the memory but I haven't read their code to see what they
> > > are doing.
> >
> > Ive measured rates far lower than that, at least for SDRAM.
>
> Hmm.  The numbers were off the top of my head and I've been messing
> with DDR SDRAM quite a bit so I may have doubled it.   Hmm.
>
> Nope.  I was remember something close to the typical streams numbers
> on an Athlon with DDR SDRAM.  Since those are read-modify-write
> numbers they should be close to the write numbers for normal SDRAM.
>
> With a PII/PIII and PC100 SDRAM I have measured about 640 MB/s writes.
>

I'm not sure where you're pulling these numbers from, but being a 
hardcore FPS gamer, I can tell you from experience, PC100 SDRAM does NOT 
hit 640MB/sec! Esspecialy not on a PII! PC100 SDRAM on my current 800Mhz 
non-tbird Athlon currently peaks near 250MB/sec

Re: Encrypted Swap

[Eric W. Biederman]

Nicholas Knight <tegeran@home.com> writes:

> On Saturday 18 August 2001 02:52 am, Eric W. Biederman wrote:
> > Dan Hollis <goemon@anime.net> writes:
> > > On 17 Aug 2001, Eric W. Biederman wrote:
> > > > Clearing memory on most machines takes a 1s or less.  Think of
> > > > memory fill rates at the 800MB/s level.  Most BIOS's seem to clear
> > > > some of the memory but I haven't read their code to see what they
> > > > are doing.
> > >
> > > Ive measured rates far lower than that, at least for SDRAM.
> >
> > Hmm.  The numbers were off the top of my head and I've been messing
> > with DDR SDRAM quite a bit so I may have doubled it.   Hmm.
> >
> > Nope.  I was remember something close to the typical streams numbers
> > on an Athlon with DDR SDRAM.  Since those are read-modify-write
> > numbers they should be close to the write numbers for normal SDRAM.
> >
> > With a PII/PIII and PC100 SDRAM I have measured about 640 MB/s writes.
> >
> 
> I'm not sure where you're pulling these numbers from, but being a 
> hardcore FPS gamer, I can tell you from experience, PC100 SDRAM does NOT 
> hit 640MB/sec! Esspecialy not on a PII! PC100 SDRAM on my current 800Mhz 
> non-tbird Athlon currently peaks near 250MB/sec

The actual tests results are somewhere at the office, but the figures are
in the right ballbark.  I'm not saying this is a common case, or easy
to get.  640 maybe be a little high but I know it was over 600MB/s. 
With carefully tuned code this is what you can get.  

Basically setting up an MTRR that does write-combining, on the area of
memory you are talking about so that you do not go through the cache.
Then something like ``xorl %eax, %eax; movl $0x1000000; rep stosl''
should achieve that kind of fill rate.  I have watched it on a logic
analyzer connected to instrumented DIMMs.  So I know it was making all
of the way to the RAM.  

You should be able to make it to SDRAM through the cache at this kind
of speed as well, but that wasn't the case I was interested at the
time I made the test.

When I performed the experiment I know it was a processor running the
P6 core and running on the l440GX motherboard, and that the memory
was PC100.

Between 600MB/s and 700MB/s is the theoretical peak of writes
on PC100 SDRAM.  So you can't do much better.  On the other hand you
should be coming much closer than 250MB/s.

The actually calculation for PC100 SDRAM using a burst length of 8 and
never refreshing goes like this.   There is one additional clock used
for the command byte on the SDRAM bus.
100*1000*1000hz * 8 bytes per clock * 8/9 / (1024*1024)  == 678 MB/s


Eric

Re: Encrypted Swap

[Richard B. Johnson]

On 17 Aug 2001, Eric W. Biederman wrote:

> "Richard B. Johnson" <root@chaos.analogic.com> writes:
> 
> > On Fri, 17 Aug 2001, David Christensen wrote:
> > 
> > > > > Ryan Mack proclaimed:
> > > Most modern firmware does NOT clear memory during POST, it takes too long.
> 
> Clearing memory on most machines takes a 1s or less.  Think of memory
> fill rates at the 800MB/s level.  Most BIOS's seem to clear some of
> the memory but I haven't read their code to see what they are doing.
> 
> > > Certain compatibility areas are usually cleared (such as the 1st megabyte)
> > > but the rest is
> > > left as is, except for a few read/writes (usually on a megabyte boundary).
> > > The 
> > > exception to this rule is ECC systems.  They have to be written to make sure
> > > the 
> > > ECC information is correct.  
> Correct.
> 
> > > SDRAM memory sizing is usually done by reading an EEPROM on the SDRAM DIMM.
> > > The BIOS doesn't need to guess the correct timing values, it simply reads
> > > the EEPROM and programs the memory controller.  In the case of a BIOS that
> > > doesn't use EEPROM you might lose data as the BIOS iteratively tries 
> > > different memory timings and tests if they work.
> 
> This would totally depend on your controller.  But different timings
> shouldn't affect your memory cells just the read/write paths to your
> memory.
> 
> > > I have done work implementing ACPI S3 (suspend-to-RAM) in DOS by simply
> > > hitting 
> > > the RESET button and restoring the memory controller settings.  The contents
> > > of 
> > > RAM have always been valid.
> 
> Hmm.  That sounds a little risky.  I have measured single bit errors
> occuring as early as 1s after writing the data without somekind of
> refresh running.
> 
> > > David Christensen
> > > 
> > 
> > I just posted working SDRAM controller initialization code. The SDRAM
> > controller must be initialized in a specific step-by-step manner or
> > else you don't even get to "restoring the memory controller settings".
> 
> Comments frequently don't match the code.  And how the SDRAM controller
> must be initialized totally depends on the chipset and vendor.  SDRAM
> itself must be initialized in a specific matter.  
> 

That's what I said, and the comments match the code.

> But for the case of a warm reset there is not need to reset the SDRAM
> controller.  Memory really only needs to be cleared in the case when
> some form of error checking is being used.
>

Memory needs to be written (with anything). It must be written before
it's used so that there are no "almost" logic levels within the cells.

The parasitic currents from having some cells "just barely on" will
totally screw up data retention in other cells. If anybody ever
writes memory initialization software that doesn't perform this
extremely important step, they just don't know what the hell they are
doing and will contribute towards a poor reputation for software
engineering.

> Personally I think writing such code carries more credibility then
> simply posting it anyway....
> 

Well I wrote the code. And I have written SDRAM initialization code
for many chip-sets.

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

[Eric W. Biederman]

"Richard B. Johnson" <root@chaos.analogic.com> writes:

> On 17 Aug 2001, Eric W. Biederman wrote:
> 
> > "Richard B. Johnson" <root@chaos.analogic.com> writes:
> > 
> > > 
> > > I just posted working SDRAM controller initialization code. The SDRAM
> > > controller must be initialized in a specific step-by-step manner or
> > > else you don't even get to "restoring the memory controller settings".
> > 
> > Comments frequently don't match the code.  And how the SDRAM controller
> > must be initialized totally depends on the chipset and vendor.  SDRAM
> > itself must be initialized in a specific matter.  
> > 
> 
> That's what I said, and the comments match the code.

Apologies, I saw it was masm formatted code and assumed it was a
snippet taken from one of the pirated award BIOS's.   

I wasn't saying that I though the comments didn't match the code but
rather that I simply don't trust comments as a general rule.

Now actually reading through the code is when I attach your 
argument.  Precharge does not clear memory.  It is part of the refresh
process and gets executed as a normal part of memory operation, besides
being part of the SDRAM initialization.  Precharge does not clear the
memory.

And then you don't have the code to clear the memory, and only a
comment about clearing the low 1 megabyte of memory.  That is a
comment not matchine the code snippet at least.

 
> > But for the case of a warm reset there is not need to reset the SDRAM
> > controller.  Memory really only needs to be cleared in the case when
> > some form of error checking is being used.
> >
> 
> Memory needs to be written (with anything). It must be written before
> it's used so that there are no "almost" logic levels within the cells.
> 
> The parasitic currents from having some cells "just barely on" will
> totally screw up data retention in other cells. If anybody ever
> writes memory initialization software that doesn't perform this
> extremely important step, they just don't know what the hell they are
> doing and will contribute towards a poor reputation for software
> engineering.

I can see how this could physically be, but I don't believe this
is a real situtation.  Memory is continuously losing it's contents,
and the refresh cycles are upping the value.   So if refresh is
operating correctly I can't see how this could occur for more than one
refresh cycle.

Further I have reviewed the SDRAM data sheets from two different
manufaturers and they don't mention anything about initializing the
contents of SDRAM.

Further if the question is what an attacker can do.  Even if it isn't
a part of normal operation having a modified BIOS that doesn't clear
the memory is perfectly reasonable, to get your secure information.

> > Personally I think writing such code carries more credibility then
> > simply posting it anyway....
> > 
> 
> Well I wrote the code. And I have written SDRAM initialization code
> for many chip-sets.

I feel like taking a cheap shot right now and saying you are currently
contributing to a poor reputation for software engineer.  But in this
case the posted code snippet is correct, so I see no failure in the
code.  Just in understanding an unimportant bit of trivia of the
low-level hardware operation.  That really doesn't matter unless you
manufacture a design memory controller.

I can't currenly claim many chip-sets under my belt currently.  But I
certainly understand how this works as well.

Eric

Re: encrypted swap

[David Spreen]

On Tue, Aug 07, 2001 at 10:23:15PM +0300, Dan Podeanu wrote:
> There, you have the swap encrypted, up and running. Of course, if you need
> more fancy encryption than the default, XOR or DES, get the crypto patch.
> You only need to have a script that does the stuff, that runs when the
> system boots, without shutdown scripts (in case of power/battery failure

Okay, even if I get the password from /dev/urandom this sounds like a 
solution for people who don't use much swapspace. Because I
have to recreate the swapfs everytime I am booting.

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

[Torrey Hoffman]

David Maynor wrote:

[...]
> I am saying if you are worried about such things, 
> then start with projects that would not require a 
> hardware crypto card to make i useable.

And earlier wrote:

[...]
> I can't really see the advantage of encrypted swap. 
> At the point it would become effective, the attacker 
> is already on the machine (from remote access or the 
> have physical access) and then its not if you can keep 
> them from getting the info, its only a matter of when.

Wait a second.  Encrypted swap is useful and effective in 
some situations that do not require a hardware crypto card.

Imagine you have:
- a Linux laptop with a small amount of RAM
- Email and important documents encrypted on disk, either
  with GPG / PGP or with an encrypted /home partition.
- Documents and email are decrypted, viewed, and edited by 
  applications, not all of which are SUID root, so 
  unencrypted data might be swapped out.

This is hardly a far-fetched example.

Now that laptop is stolen at an airport. The thief decides
to try to improve his take by grabbing useful information
from documents.  The encrypted documents are untouchable,
of course.  It _doesn't matter_ that the thief has the
hardware, the decryption key is protected by a passphrase
which is _nowhere_ on the hard drive.

The only place that sensitive, unencrypted data could be
on such a machine is in swap.  In fact, it is _likely_ to
be in swap.

Encrypted swap solves this _particular_ problem nicely, 
does it not?  

Torrey

Re: encrypted swap

[Thomas Pornin]

In article <D52B19A7284D32459CF20D579C4B0C0211C9A8@mail0.myrio.com> you write:
> Now that laptop is stolen at an airport.

This is indeed the target of choice for a disk-encrypting software.
But you need to encipher three zones:
-- the swap space, as you stated
-- the whole filesystem itself, because you do not know if your favorite
word-processor won't create temporary files (well, maybe you can
limit yourself to /home and /tmp)
-- the zone that the machine uses for the "suspend to disk" option ;
and I guess that one will be tricky. A potential solution, which covers
also the "suspend to memory" option, is to encipher all data in physical
memory when there is a suspend operation. Only the kernel, including
the code wich asks for the deciphering key, remains clear.

About performance: modern cryptosystem on modern cpus run at about
2 cycles per bit of data.


	--Thomas Pornin

RE: encrypted swap

[Dan Podeanu]

> Now that laptop is stolen at an airport. The thief decides
> to try to improve his take by grabbing useful information
> from documents.  The encrypted documents are untouchable,
> of course.  It _doesn't matter_ that the thief has the
> hardware, the decryption key is protected by a passphrase
> which is _nowhere_ on the hard drive.
>
> The only place that sensitive, unencrypted data could be
> on such a machine is in swap.  In fact, it is _likely_ to
> be in swap.
>
> Encrypted swap solves this _particular_ problem nicely,
> does it not?

You got it bit.. wrong. Or, non-specific. If you assume that your laptop
is stolen while its powered, then encrypted swap won't help you (strings
/proc/kcore & the likes). If its going to be stolen while its offline, you
can have your shutdown scripts blank the swap partition and the boot
scripts call mkswap on it.

Or, somehow better & safer (or, explain the drawback):

spiral:~# dd if=/dev/zero of=/swap bs=1024k count=16
16+0 records in
16+0 records out
spiral:~# losetup -e DES /dev/loop0 /swap
Password:
Init (up to 16 hex digits):
spiral:~# mkswap /dev/loop0
Setting up swapspace version 1, size = 16773120 bytes
spiral:~# swapon /dev/loop0
spiral:~# cat /proc/swaps
Filename                        Type            Size    Used    Priority
/dev/loop0                      partition       16376   0       -3

There, you have the swap encrypted, up and running. Of course, if you need
more fancy encryption than the default, XOR or DES, get the crypto patch.
You only need to have a script that does the stuff, that runs when the
system boots, without shutdown scripts (in case of power/battery failure
these might not be executed, hence the swap would not be wiped). Of
course, you'll need to enter the losetup password upon booting, which
might prove annoying (then again, if kernel would provide swap
encryption, the only way to make it non-decryptable would be for you to
enter a password, same drawback actually).

Cheers,
Dan.

Re: encrypted swap

[Andreas Dilger]

Dan writes:
> Or, somehow better & safer (or, explain the drawback):
> 
> spiral:~# dd if=/dev/zero of=/swap bs=1024k count=16
> 16+0 records in
> 16+0 records out
> spiral:~# losetup -e DES /dev/loop0 /swap
> Password:
> Init (up to 16 hex digits):
> spiral:~# mkswap /dev/loop0
> Setting up swapspace version 1, size = 16773120 bytes
> spiral:~# swapon /dev/loop0
> spiral:~# cat /proc/swaps
> Filename                        Type            Size    Used    Priority
> /dev/loop0                      partition       16376   0       -3
> 
> Of course, you'll need to enter the losetup password upon booting, which
> might prove annoying

Actually, since you don't care about the old contents of swap on each
boot, just have something like:

losetup -e AES /dev/loop0 /swap < /dev/random

then you get a random password each boot, which is strong because it
uses the full 256 character passwords, as opposed to passwords that
people can easily use/remember.

You would likely need something more along the lines of (I don't know
what input format losetup actually needs):

dd if=/dev/random bs=1 count=16 | od -tx4 | \
    awk '/0000000/ { print $2 $3 $4 $5 }' | losetup -e AES -p0 /dev/loop0 /swap

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

[Marty Poulin]

From: "Dan Podeanu" <pdan@spiral.extreme.ro>
> /proc/kcore & the likes). If its going to be stolen while its offline, you
> can have your shutdown scripts blank the swap partition and the boot
> scripts call mkswap on it.

Assuming that the notebook was shutdown correctly is a big assumption.  The
notebook could run out of power or freeze-up and if the user is not able to
immediately able to restart the computer the swap is all laid out with a
ribbon.

No I have to agree that a more elegant solution to this is encrypt
everything and require the user to input the password whenever the system
boots or returns from suspend.

Marty Poulin
vandal@playnet.com
Lead Programmer
Host/Client Communications
Playnet Inc./Cornered Rat Software

Re: encrypted swap

[David Wagner]

Dan Podeanu  wrote:
>If its going to be stolen while its offline, you
>can have your shutdown scripts blank the swap partition [...]

Erasing data, once written, is deceptively difficult.
See Peter Gutmann's excellent paper on the subject at
http://www.usenix.org/publications/library/proceedings/sec96/gutmann.html

It turns out that the easiest way to solve this problem is to make sure
you only ever write to the swap partition in encrypted form, and then when
you want to erase it securely, just throw away the key used to encrypt it.
(You have to securely erase this key, but it is much easier to erase
this key securely, because it is shorter and because you can arrange
that it only resides in RAM.)

It is critical that you choose a new encryption key each time you boot.
(Requiring users to enter in passphrases manually is unlikely to work well.)

Re: encrypted swap

[D. Stimits]

David Wagner wrote:
> 
> Dan Podeanu  wrote:
> >If its going to be stolen while its offline, you
> >can have your shutdown scripts blank the swap partition [...]
> 
> Erasing data, once written, is deceptively difficult.
> See Peter Gutmann's excellent paper on the subject at
> http://www.usenix.org/publications/library/proceedings/sec96/gutmann.html
> 
> It turns out that the easiest way to solve this problem is to make sure
> you only ever write to the swap partition in encrypted form, and then when
> you want to erase it securely, just throw away the key used to encrypt it.
> (You have to securely erase this key, but it is much easier to erase
> this key securely, because it is shorter and because you can arrange
> that it only resides in RAM.)
> 
> It is critical that you choose a new encryption key each time you boot.
> (Requiring users to enter in passphrases manually is unlikely to work well.)

You could easily create a pass phrase that is a combination of a user
defined pass, and a random device generation. During suspend of the
laptop, you could force it to forget only the user defined portion, and
ask that it get re-entered on resume. Keyboard snooping would only
provide a small part of the key; though it would aid attacks to know
part of the key, each reboot would invalidate the per-session key, and
each suspend or boot would also invalidate the user key (the user could
choose a different user key each boot, but that key would remain in
effect for the remainder of the boot; one could be so devious as to also
force the user key portion to pass a one-way hash, like MD5, against a
permanent pass file, if the permanent pass file was not itself on an
encrypted partition).

D. Stimits, stimits@idcomm.com

> -
> 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/

Re: encrypted swap

[Pavel Machek]

Hi!

> > Now that laptop is stolen at an airport. The thief decides
> > to try to improve his take by grabbing useful information
> > from documents.  The encrypted documents are untouchable,
> > of course.  It _doesn't matter_ that the thief has the
> > hardware, the decryption key is protected by a passphrase
> > which is _nowhere_ on the hard drive.
> >
> > The only place that sensitive, unencrypted data could be
> > on such a machine is in swap.  In fact, it is _likely_ to
> > be in swap.
> >
> > Encrypted swap solves this _particular_ problem nicely,
> > does it not?
> 
> You got it bit.. wrong. Or, non-specific. If you assume that your laptop
> is stolen while its powered, then encrypted swap won't help you (strings
> /proc/kcore & the likes). If its going to be stolen while its offline, you
> can have your shutdown scripts blank the swap partition and the boot
> scripts call mkswap on it.
> 
> Or, somehow better & safer (or, explain the drawback):
> 
> spiral:~# dd if=/dev/zero of=/swap bs=1024k count=16
> 16+0 records in
> 16+0 records out
> spiral:~# losetup -e DES /dev/loop0 /swap
> Password:
> Init (up to 16 hex digits):
> spiral:~# mkswap /dev/loop0
> Setting up swapspace version 1, size = 16773120 bytes
> spiral:~# swapon /dev/loop0
> spiral:~# cat /proc/swaps
> Filename                        Type            Size    Used    Priority
> /dev/loop0                      partition       16376   0       -3
> 
> There, you have the swap encrypted, up and running. Of course, if
> you need

You have your swap encrypted, but I'm not sure for how long you'll see
it running before it deadlocks. Unless -e DES and loop were designed
for use with swap (were they?), this is tricky. Does anyone know if
swapping over loop is safe?

> more fancy encryption than the default, XOR or DES, get the crypto patch.
> You only need to have a script that does the stuff, that runs when the
> system boots, without shutdown scripts (in case of power/battery failure
> these might not be executed, hence the swap would not be wiped). Of
> course, you'll need to enter the losetup password upon booting, which
> might prove annoying (then again, if kernel would provide swap
> encryption, the only way to make it non-decryptable would be for you to
> enter a password, same drawback actually).

You could generate random password each boot. Should work well enough.

								Pavel
-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org

RE: encrypted swap

[Justin Guyett]

On Tue, 7 Aug 2001, Torrey Hoffman wrote:

> Imagine you have:
> - a Linux laptop with a small amount of RAM
> - Email and important documents encrypted on disk, either
>   with GPG / PGP or with an encrypted /home partition.
> - Documents and email are decrypted, viewed, and edited by
>   applications, not all of which are SUID root, so
>   unencrypted data might be swapped out.
>
> Now that laptop is stolen at an airport. The thief decides
> to try to improve his take by grabbing useful information
> from documents.  The encrypted documents are untouchable,
> of course.  It _doesn't matter_ that the thief has the
> hardware, the decryption key is protected by a passphrase
> which is _nowhere_ on the hard drive.

As someone just pointed out, if the laptop's suspended, the password for
encrypted swap pretty much has to be in ram, unless you're going to add
hooks in resume such that before anything even starts running again
(possible?) it prompts for the decryption password.  Otherwise, you can't
block swap access, and if the data's encrypted, seems like that will crash
the machine.

With encryption boards, what's to stop either hackers with root or people
with physical access from simply dumping everything sent across the bus to
the encryption card, unless your whole [embedded] computer is tamper-
resistant, the kernel doesn't accept loadable modules, and has been proven
secure.  The only thing that doesn't have to be attack-resistant is the
hd, since it only ever sees encrypted data.

And of course, "tamper-resistant", not "tamper-proof".  I wouldn't bet
very much money against the NSA being able to get at least some data out
of the ibm card.


justin

Re: encrypted swap

[Alan Cox]

> And of course, "tamper-resistant", not "tamper-proof".  I wouldn't bet
> very much money against the NSA being able to get at least some data out
> of the ibm card.

Im sure they can. In fact in some cases you have to ask the NSA to let you
posess one. No lock is secure against sufficient force. Once it gets to the
point its more efficient to blow up your building in a mysterious accident
than steal your data you've kind of lost anyway

Alan

Re: encrypted swap

[Bill Rugolsky Jr.]

On Tue, Aug 07, 2001 at 12:48:34PM -0700, Justin Guyett wrote:
> As someone just pointed out, if the laptop's suspended, the password for
> encrypted swap pretty much has to be in ram, unless you're going to add
> hooks in resume such that before anything even starts running again
> (possible?) it prompts for the decryption password.  Otherwise, you can't
> block swap access, and if the data's encrypted, seems like that will crash
> the machine.

Well, one can suspend the machine with swsusp, and supply a passphrase
as a kernel boot option.  It is essential to overwrite all copies of that string,
of course. :-)

Regards,

  Bill Rugolsky

encrypted swap

[David Maynor]

>
>This is not about paranoia, this is about stolen notebooks.
>
>(And you can't easily add hundreds of megabytes to such systems
>usually.)

Then you can use a hardware token so that the machine will not boot at all 
with out it present or write an encrypted super block, but I can't really 
see the advantage of encrypted swap. At the point it would become 
effective, the attacker is already on the machine (from remote access or 
the have physical access) and then its not if you can keep them from 
getting the info, its only a matter of when.

Re: encrypted swap

[Florian Weimer]

David Maynor <david.maynor@oit.gatech.edu> writes:

> Then you can use a hardware token so that the machine will not boot at
> all with out it present or write an encrypted super block, but I can't
> really see the advantage of encrypted swap.

This doesn't anything.  Simply connect the hard disk to another
computer.

> At the point it would become effective, the attacker is already on
> the machine (from remote access or the have physical access) and
> then its not if you can keep them from getting the info, its only a
> matter of when.

The machine has got an encrypted file system, of course (perhaps /usr
is not encrypted, but /home certainly is).

-- 
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

encrypted swap

[David Maynor]

But is the 10% perf hit really gaining you anything, expect to quell your 
paranoia. What is next, an encrypted /proc so that possible attackers can't 
gain information about running processes?

David Maynor

Re: encrypted swap

[Florian Weimer]

David Maynor <david.maynor@oit.gatech.edu> writes:

> But is the 10% perf hit really gaining you anything, expect to quell
> your paranoia. What is next, an encrypted /proc so that possible
> attackers can't gain information about running processes?

This is not about paranoia, this is about stolen notebooks.

(And you can't easily add hundreds of megabytes to such systems
usually.)

-- 
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

Re: encrypted swap

[Joel Jaeggli]

On 7 Aug 2001, Florian Weimer wrote:

> David Maynor <david.maynor@oit.gatech.edu> writes:
>
> > But is the 10% perf hit really gaining you anything, expect to quell
> > your paranoia. What is next, an encrypted /proc so that possible
> > attackers can't gain information about running processes?
>
> This is not about paranoia, this is about stolen notebooks.
>
> (And you can't easily add hundreds of megabytes to such systems
> usually.)

yeah, that's true, but on older ones (like my toshiba portege 3010 which
has the system maximum of 96MB ) you may not be able to afford the
performance hit either(pentium 266,dma mode0 or pio disk,430tx chipset
and all it's attendant memory performance issues with more than 64mb).

on a more modern unit (like my toshiba 2805 which has 384MB) the
performance hit probably isn't a big deal but I probably don't need swap
that much either.

joelja

>

-- 
--------------------------------------------------------------------------
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

[Garett Spencley]

On Tue, 7 Aug 2001, David Maynor wrote:

> But is the 10% perf hit really gaining you anything, expect to quell your
> paranoia. What is next, an encrypted /proc so that possible attackers can't
> gain information about running processes?
>
> David Maynor

Actually the openwall (http://www.openwall.com/linux) security patches do
something similar to this. I'm not actually sure if they encrypt it or
they just prevent read access to it by normal users but the effect is
the same. It can be a desirable security feature.

-- 
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

[David Spreen]

On Tue, Aug 07, 2001 at 11:06:36AM -0400, David Maynor wrote:
> But is the 10% perf hit really gaining you anything, expect to quell your 
> paranoia. What is next, an encrypted /proc so that possible attackers can't 
> gain information about running processes?

This was not the point. I you don't care about your data on disks which
maybe stolen (for example in notebooks) this is okay for me. 
My question was only if there's an existing implementation of this.
10 - 30% performance problems are quite acceptable for 
good privacy aren't they?

So if I understood you guys correctly it would be possible by
getting random-data at boottime and use them to build a key
(for example with the algorythms from the kerneli patch), which
will be used to encrypt the swapped out data right?

Would be cool to hear from some others who are interested in 
such an implementation of crypted swap, maybe we could start
something like that.

Btw. one of the BSDs uses encrypted swap too iirc, how did they
implement?

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

[Helge Hafting]

David Maynor wrote:
> 
> But is the 10% perf hit really gaining you anything, expect to quell your
> paranoia. What is next, an encrypted /proc so that possible attackers can't
> gain information about running processes?

You can compile a kernel without /proc if you want to.

Helge Hafting

encrypted swap

[David Maynor]

 >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 is a should-if debate, in my opinion. That is, not if you can do it, 
but should you. Has anybody thought of the performance hit that you would 
take encrypting your swap?

David Maynor

Re: encrypted swap

[Billy Harvey]

> This is a should-if debate, in my opinion. That is, not if you can do it, 
> but should you. Has anybody thought of the performance hit that you would 
> take encrypting your swap?
> 
> David Maynor

Insignificant I'd think.  Disk is already thousands of times slower than
RAM.  Ever needing to swap at all is a huge penalty - if the crypto adds
10% system access time to that (a long time for RAM and hardly anything
for disk), who'd notice?

Billy

Re: encrypted swap

[Chris Wedgwood]

On Tue, Aug 07, 2001 at 10:37:57AM -0400, David Maynor wrote:

    This is a should-if debate, in my opinion. That is, not if you can
    do it, but should you. Has anybody thought of the performance hit
    that you would take encrypting your swap?

Yes, and people have written papers about it.


If you use hardware, the difference is insignificant.  In software,
it's measurable (maybe a 30% hit) but still quite acceptable. See the
Usenix Security Symposium Proceedings for 2000 (I'm too lazy to find
the paper myself).



  --cw

Re: Encrypted Swap

[Alan Cox]

> 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.  

IBM sell crypto PCI cards with anti tamper environments, they have
development drivers on their oss site too

Re: Encrypted Swap

[Crutcher Dunnavant]

++ 07/08/01 15:17 +0100 - Alan Cox:
> > 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.  
> 
> IBM sell crypto PCI cards with anti tamper environments, they have
> development drivers on their oss site too

Ohh. Some college buddies and I were considering the difficulty involved from
making a pci card with an onboard giger counter and radiatian source (say, from
a smoke detector) wrapped up in some lead.

Sure, there are simpler ways to build chaotic circuits, but a radioactive
peripheral is cool!

-- 
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

[Chris Wedgwood]

On Tue, Aug 07, 2001 at 11:16:35AM -0400, Crutcher Dunnavant wrote:

    Ohh. Some college buddies and I were considering the difficulty
    involved from making a pci card with an onboard giger counter and
    radiatian source (say, from a smoke detector) wrapped up in some
    lead.

    Sure, there are simpler ways to build chaotic circuits, but a
    radioactive peripheral is cool!

Why?  There are plenty of cards out that that have hardware and more.
The one in the machine I presently use is limited to 1Mbit/second of
data from a noise-diode (fed through various functions in hardware to
further obfuscate the data).




  --cw

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

[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

[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

[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

[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 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

[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: 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

[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

[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

[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

[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

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

[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