Should Linux wipe memory more often for better security?

Should Linux wipe memory more often for better security?
Secure Home | Search | About
Login Password
Register Now! Lost Password?
 General Computer Security    Post an article   get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content add this group's latest topics to your Google content
Subject Author Date
Should Linux wipe memory more often for better security? plenty900 02-25-2008
Posted by Bernd Felsche on February 27, 2008, 2:21 am
If you were  Registered and logged in, you could reply and use other advanced thread options
phil-news-nospam@ipal.net wrote:

>> It has been known from the beginning that DRAM holds its state a
>> while after power is removed. Thats how it works. There is a
>> circuit that refreshes it every X milliseconds. But it is a big
>> big surprise, at least to me, that data can recovered up to 10
>> minutes afterwards!!?

>> The only real world ramification I can see is that you should
>> completely powerdown your laptop 10 mins before going through a
>> security checkpoint. Or unmount crypt stuff and do a memory wipe.

>So add a RAM wipe right at the end of the halt sequence (in
>addition to other security measures like storing keys in unused
>corners of video card SRAM).

Scrubbing page tables making a good start. Much quicker than the
whole RAM - which could span gigabytes for the well-endowed.

>> As far as servers sitting alone somewhere, or other scenarios.. if
>> someone has physical access to a machine there are all kinds of tricks
>> they can use. I think you need to implement intrusion detection as
>> another poster said, and rigged to explosives for self destruct. ;)

>That, too.

The attack is to boot another (small) operating system to glean the
values.

A custom BIOS/POST would do wonders. Seeing that the classical BIOS
is on the way out, security options can be enhanced on openBIOS or
whatever. e.g. Prevent booting from "unsigned" devices; and forcing
a RAM scrub as part of POST if there's no secure key stored in BIOS.

Not foolproof, but raises the bar a few metres.
--
/"\ Bernd Felsche - Innovative Reckoning, Perth, Western Australia
\ / ASCII ribbon campaign | Great minds discuss ideas;
X against HTML mail | Average minds discuss events;
/ \ and postings | Small minds discuss people. -- Eleanor Roosevelt

Posted by Sebastian G. on February 27, 2008, 10:08 am
If you were  Registered and logged in, you could reply and use other advanced thread options
Bernd Felsche wrote:


>> So add a RAM wipe right at the end of the halt sequence (in
>> addition to other security measures like storing keys in unused
>> corners of video card SRAM).
>
> Scrubbing page tables making a good start. Much quicker than the
> whole RAM - which could span gigabytes for the well-endowed.


Well, what about simply wiping only the cryptographic keys? Which is exactly
what almost any on-the-fly encryption suite under the sun does.

Posted by on February 27, 2008, 12:33 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
| Bernd Felsche wrote:
|
|
|>> So add a RAM wipe right at the end of the halt sequence (in
|>> addition to other security measures like storing keys in unused
|>> corners of video card SRAM).
|>
|> Scrubbing page tables making a good start. Much quicker than the
|> whole RAM - which could span gigabytes for the well-endowed.
|
|
| Well, what about simply wiping only the cryptographic keys? Which is exactly
| what almost any on-the-fly encryption suite under the sun does.

If you know exactly where the keys are, that's what you wipe first. Then
wipe any unencrypted data, if you know where that is. Then wipe everything
else to be sure. All that could happen between output of "System halted"
and the power off action (or the "It is now safe to turn off the power"
output).

The kernel that knows where the keys are could also wipe them the instant
any power loss event is triggered, depending on how long the DC capacitors
can keep things running to accomplish that (hopefully at least a few hundred
instructions).

--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2008-02-27-1129@ipal.net |
|------------------------------------/-------------------------------------|

Posted by Casper H.S. Dik on February 28, 2008, 6:39 am
If you were  Registered and logged in, you could reply and use other advanced thread options

>Bernd Felsche wrote:


>>> So add a RAM wipe right at the end of the halt sequence (in
>>> addition to other security measures like storing keys in unused
>>> corners of video card SRAM).
>>
>> Scrubbing page tables making a good start. Much quicker than the
>> whole RAM - which could span gigabytes for the well-endowed.


>Well, what about simply wiping only the cryptographic keys? Which is exactly
>what almost any on-the-fly encryption suite under the sun does.

You'd still be having some cleartext data around.

But it's exactly why some systems use FIPS 140 level 3 or 4 certified hardware;
the keys are never in the system's DRAM but only exist on the secure
coprocessor.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

Posted by on February 27, 2008, 12:29 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
In comp.os.linux.development.system Bernd Felsche
| phil-news-nospam@ipal.net wrote:
|
|>> It has been known from the beginning that DRAM holds its state a
|>> while after power is removed. Thats how it works. There is a
|>> circuit that refreshes it every X milliseconds. But it is a big
|>> big surprise, at least to me, that data can recovered up to 10
|>> minutes afterwards!!?
|
|>> The only real world ramification I can see is that you should
|>> completely powerdown your laptop 10 mins before going through a
|>> security checkpoint. Or unmount crypt stuff and do a memory wipe.
|
|>So add a RAM wipe right at the end of the halt sequence (in
|>addition to other security measures like storing keys in unused
|>corners of video card SRAM).
|
| Scrubbing page tables making a good start. Much quicker than the
| whole RAM - which could span gigabytes for the well-endowed.

How about a special space set aside in RAM that the kernel is aware of,
which the storing of keys would make use of in lieu of regular RAM.
That way the key can get wiped first, and any unencrypted data in the
rest of RAM can be done later.

I'd also recommend wiping the data with random bits instead of zeros.


|>> As far as servers sitting alone somewhere, or other scenarios.. if
|>> someone has physical access to a machine there are all kinds of tricks
|>> they can use. I think you need to implement intrusion detection as
|>> another poster said, and rigged to explosives for self destruct. ;)
|
|>That, too.
|
| The attack is to boot another (small) operating system to glean the
| values.
|
| A custom BIOS/POST would do wonders. Seeing that the classical BIOS
| is on the way out, security options can be enhanced on openBIOS or
| whatever. e.g. Prevent booting from "unsigned" devices; and forcing
| a RAM scrub as part of POST if there's no secure key stored in BIOS.
|
| Not foolproof, but raises the bar a few metres.

This seems to be an area (because physical access _is_ involved) where
"psuedo-security by obscurity" seems to be needed. I agree that none of
these methods provide excellent protection of data. This is similar to
the issues the music/movie content industry faces ... they have to have
protection of data even where it gets exposed.

How easy would it be to have some addressable memory, even if slower,
implemented via the PCI bus? A plug in PCI card with some genuine SRAM
that loses data the instant the power is lost could be used. Even better
would be to have such a card with crypto hardware in it, so the key never
needs to be read back in to DRAM once stored in the card when the system
boots up and the key is provided by the human user.

Of course there is always that issue of residual data in the clear.

And how easy is it to verify that crypto hardware has no backdoors.

--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2008-02-27-1118@ipal.net |
|------------------------------------/-------------------------------------|

Similar ThreadsPosted
security software for linux and mac July 4, 2007, 1:43 pm
cp fw-1 ngx: no memory for german umlaute January 15, 2006, 5:15 am
Different tools for the same memory capture January 4, 2009, 12:26 pm
Re: Microsoft Internet Explorer COM Object Instantiation Memory Corruption Vulnerability December 15, 2005, 10:03 am
Wipe Outlook Mail Messages January 22, 2006, 12:41 pm
DoD Harddrive Secure Erase Wipe April 2, 2008, 9:37 pm
Software to wipe disk drives on servers and pc January 30, 2008, 4:11 pm
Linux Help September 27, 2006, 7:23 pm
Linux? Which one is the most friendly? May 1, 2005, 3:37 pm
end of linux-nightmares... approachable June 17, 2005, 11:27 am

The site map in XML format XML site map

Contact Us | Privacy Policy