Should Linux wipe memory more often for better security?
Turns out, DHS, which has been spying illegally for some years now,
has found a way to read DRAM data *after powerdown* -- presumably
it would work after normal shutdown or sudden power loss.
> Turns out, DHS, which has been spying illegally for some years
> now, has found a way to read DRAM data *after powerdown* --
> presumably it would work after normal shutdown or sudden power
> loss.
>
> http://www.nytimes.com/2008/02/22/te...in&oref=slogin
There's a discussion running about that in the german NG
de.sci.electronics
It boiled down to the following: Most modern Motherboards have an
intrusion switch detector, some MoBos even have intrusion
sensors (LDR, Vibration Switch etc.).
They can trigger actions that go from a simple ACPI event, and
can go up to calling code, that has been installed through EFI
(on boards that have EFI).
Now, all you've to do is using those IDS and unmount all
encrypted volumes if such sensors get triggerd -- and wipe the
keys from memory afterwards. You can also use temperature
sensors, to detect a "chill attack".
And last but not least there's one use for TCPA in the end: One
of the goals of TCPA was/is, that the CPU can have the memory
encrypted transparently. The crypto stuff should happen on the
L1 cache level.
Wolfgang Draxinger
--
E-Mail address works, Jabber: hexarith@jabber.org, ICQ: 134682867
Re: Should Linux wipe memory more often for better security?
plenty900@yahoo.com wrote in
news:b03617a5-3543-43d7-84e6-32910fe2b82b@q33g2000hsh.googlegroups.com:
> Turns out, DHS, which has been spying illegally for some years now,
> has found a way to read DRAM data *after powerdown* -- presumably
> it would work after normal shutdown or sudden power loss.
>
> http://www.nytimes.com/2008/02/22/te..._r=2&ei=5087&e
> m=&en=13d01f43eefefaeb&ex=1203915600&pagewanted=pr int&oref=slogin&oref=
> slogin
Re: Should Linux wipe memory more often for better security?
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.
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. ;)
Re: Should Linux wipe memory more often for better security?
In comp.os.linux.development.system shimp <example@nobody.com> 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).
| 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.
How about a low bandwidth LAN over the power lines via tap in the PSU.
Each node can cryptographically authenticate itself. If a configured
set of required nodes can no longer be reached, memory gets wiped on
certain machines with critical data.
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2008-02-26-2351@ipal.net |
|------------------------------------/-------------------------------------|
>> 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
Re: Should Linux wipe memory more often for better security?
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.
Re: Should Linux wipe memory more often for better security?
In comp.os.linux.development.system Bernd Felsche <bernie@innovative.iinet.net.au> wrote:
| phil-news-nospam@ipal.net wrote:
|>shimp <example@nobody.com> 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 |
|------------------------------------/-------------------------------------|
Re: Should Linux wipe memory more often for better security?
In comp.os.linux.development.system Sebastian G. <seppi@seppig.de> wrote:
| 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 |
|------------------------------------/-------------------------------------|
Re: Should Linux wipe memory more often for better security?
phil-news-nospam@ipal.net wrote:
> In comp.os.linux.development.system Bernd Felsche <bernie@innovative.iinet.net.au> wrote:
> | phil-news-nospam@ipal.net wrote:
> |>shimp <example@nobody.com> 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.
Being able to mark pages as 'i need to be wiped' by the kernel would be
cool. Then again the only sure thing is to wipe all memory. Developer
make mistakes, software has design flaws. Best to wipe it all.
>
> 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.
Hmm that gives me an idea. I bet someone right now today could create a
little battery powered piggyback board that sits between your
motherboard and your RAM modules. It could detect powerdown and do the wipe.
Re: Should Linux wipe memory more often for better security?
In comp.os.linux.development.system shimp <example@nobody.com> wrote:
| phil-news-nospam@ipal.net wrote:
|> In comp.os.linux.development.system Bernd Felsche <bernie@innovative.iinet.net.au> wrote:
|> | phil-news-nospam@ipal.net wrote:
|> |>shimp <example@nobody.com> 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.
|
| Being able to mark pages as 'i need to be wiped' by the kernel would be
| cool. Then again the only sure thing is to wipe all memory. Developer
| make mistakes, software has design flaws. Best to wipe it all.
I agree. But maybe we can have some means to designate priority for cases
when CPU operating time might be very limited because AC power to PSU is
gone.
|> 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.
|
|
| Hmm that gives me an idea. I bet someone right now today could create a
| little battery powered piggyback board that sits between your
| motherboard and your RAM modules. It could detect powerdown and do the wipe.
Or maybe a PCI card with DMA?
It could also have a header to attach intrusion detectors and do a system
reset at the same time.
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2008-02-27-1454@ipal.net |
|------------------------------------/-------------------------------------|
Re: Should Linux wipe memory more often for better security?
>
> |> 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.
> |
> |
> | Hmm that gives me an idea. I bet someone right now today could create a
> | little battery powered piggyback board that sits between your
> | motherboard and your RAM modules. It could detect powerdown and do the wipe.
>
> Or maybe a PCI card with DMA?
>
> It could also have a header to attach intrusion detectors and do a system
> reset at the same time.
>
That would be nice if you could just buy a PCI card and plug it in. But
Im afraid it would have to power the northbridge at least, and maybe the
processor as well. I dunno. I'm not a motherboard engineer. ;D
Hmmm we have ECC RAM, so im sure the industry could create some secure
RAM if there was demand. Short all bits on poweroff.
p.s. The incognito livecd, which has been around for awhile, does do a
memory wipe at shutdown. So kudos to them.
Re: Should Linux wipe memory more often for better security?
On Feb 27, 9:29 am, phil-news-nos...@ipal.net wrote:
> I'd also recommend wiping the data with random bits instead of zeros.
Why? To protect against possible even more bizarre, even more
hypothetical attacks? This attack is so bizarre, it's barely worth
doing much of anything about.
Re: Should Linux wipe memory more often for better security?
David Schwartz <davids@webmaster.com> writes:
> On Feb 27, 9:29 am, phil-news-nos...@ipal.net wrote:
>
>> I'd also recommend wiping the data with random bits instead of zeros.
>
> Why? To protect against possible even more bizarre, even more
> hypothetical attacks?
Even if there were residual patterns left after overwriting with
zeros, which I doubt, it wouldn't matter. When powered up again, the
memory will read as zeros, assuming it is done before it randomises
again. If this wasn't the case, DRAM wouldn't work at all. Besides,
such traces of previous data would fade much quicker, and the time
window for this attack is small enough as it is.
> This attack is so bizarre, it's barely worth doing much of anything
> about.
Re: Should Linux wipe memory more often for better security?
In comp.os.linux.development.system shimp <example@nobody.com> wrote:
|>
|> |> 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.
|> |
|> |
|> | Hmm that gives me an idea. I bet someone right now today could create a
|> | little battery powered piggyback board that sits between your
|> | motherboard and your RAM modules. It could detect powerdown and do the wipe.
|>
|> Or maybe a PCI card with DMA?
|>
|> It could also have a header to attach intrusion detectors and do a system
|> reset at the same time.
|>
|
| That would be nice if you could just buy a PCI card and plug it in. But
| Im afraid it would have to power the northbridge at least, and maybe the
| processor as well. I dunno. I'm not a motherboard engineer. ;D
There is a brief instant of time a few thousand cycles can be done.
Maybe that's enough time to wipe a critical page.
| Hmmm we have ECC RAM, so im sure the industry could create some secure
| RAM if there was demand. Short all bits on poweroff.
SRAM. Instead of storing data in a little charged capacitor, it is stored
in the state of a flip flop that has no state without any power. This is
not a good choice for the whole system. But it would be for a small amount
of memory used to store security critical data.
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2008-02-27-2312@ipal.net |
|------------------------------------/-------------------------------------|
Re: Should Linux wipe memory more often for better security?
In comp.os.linux.development.system David Schwartz <davids@webmaster.com> wrote:
| On Feb 27, 9:29 am, phil-news-nos...@ipal.net wrote:
|
|> I'd also recommend wiping the data with random bits instead of zeros.
|
| Why? To protect against possible even more bizarre, even more
| hypothetical attacks? This attack is so bizarre, it's barely worth
| doing much of anything about.
It's to confuse analysis after the fact. If the wipe is incomplete, it
is easy to see where the wipe ends and the data begins. With random bits
it is harder.
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2008-02-27-2316@ipal.net |
|------------------------------------/-------------------------------------|
Re: Should Linux wipe memory more often for better security?
Måns Rullgård <mans@mansr.com> writes:
> David Schwartz <davids@webmaster.com> writes:
>> On Feb 27, 9:29 am, phil-news-nos...@ipal.net wrote:
>>> I'd also recommend wiping the data with random bits instead of zeros.
>>
>> Why? To protect against possible even more bizarre, even more
>> hypothetical attacks?
>
> Even if there were residual patterns left after overwriting with
> zeros, which I doubt, it wouldn't matter. When powered up again, the
> memory will read as zeros, assuming it is done before it randomises
> again. If this wasn't the case, DRAM wouldn't work at all. Besides,
> such traces of previous data would fade much quicker, and the time
> window for this attack is small enough as it is.
>
>> This attack is so bizarre, it's barely worth doing much of anything
>> about.
>
> Yes, being abducted by aliens seems more likely.
I have just yesterday been required to read through a long marketing
text trying to sell TPM-based 'security solutions' (software) because
it is (claimed to be) immune against reading keys still available from
RAM. Assuming that it is, this is still complete ********, because the
protected data itself needs to reside in RAM in decrypted form if it
is supposed to be used by software for anything, so 'reading the
decryption key' isn't even necessary to access the data.
But that's presumably already to technical and to complicated for
quite a few people ...
> |> I'd also recommend wiping the data with random bits instead of zeros.
> |
> | Why? To protect against possible even more bizarre, even more
> | hypothetical attacks? This attack is so bizarre, it's barely worth
> | doing much of anything about.
>
> It's to confuse analysis after the fact. If the wipe is incomplete,
> it is easy to see where the wipe ends and the data begins. With
> random bits it is harder.
I wouldn't count on that. That would require that the data itself is
just as random-looking as the PRNG's output, which is almost never the
case, and if it is, then wiping isn't necessary anyway.
The whole concept is flawed. It's not the operating system's
responsibility to decide, which parts of the memory contain sensitive
data. On the other hand, a background daemon, which runs very (!)
nicely, could wipe unused memory. The usefulness of this is
questionable, though, since attacks against the live RAM will be attacks
against running applications anyway.
Re: Should Linux wipe memory more often for better security?
"Sebastian G." <seppi@seppig.de> writes:
>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.
Re: Should Linux wipe memory more often for better security?
In article <fq632k$e8f$01$1@news.t-online.com>,
Ertugrul Söylemez <es@ertes.de> wrote:
>It's not the operating system's
>responsibility to decide, which parts of the memory contain sensitive
>data.
On the other hand, mandatory access controls such as those provided by
SELinux at least provide a framework that could allow the OS to know
the relative sensitivities of data in RAM. Preserving the MAC label
of freed-but-not-erased RAM would assure that the information is
available to prioritize an emergency memory wipe.
Re: Should Linux wipe memory more often for better security?
In comp.os.linux.development.system Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
| I have just yesterday been required to read through a long marketing
| text trying to sell TPM-based 'security solutions' (software) because
| it is (claimed to be) immune against reading keys still available from
| RAM. Assuming that it is, this is still complete ********, because the
| protected data itself needs to reside in RAM in decrypted form if it
| is supposed to be used by software for anything, so 'reading the
| decryption key' isn't even necessary to access the data.
Yes, the currently decrypted data is exposed. But at least it is limited
to just that data. With the key, the entire disk is exposed.
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2008-03-01-2128@ipal.net |
|------------------------------------/-------------------------------------|