Re: Memory Overwrite Request in cryptsetup

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jist for reference, this is about this document:
http://www.trustedcomputinggroup.org/files/temp/6452209B-1D09-3519-AD815636FC36C5CF/Platform%20Reset%20Attack%20Mitigation%20Specification.pdf


On Sat, Oct 27, 2012 at 12:48:03PM +0200, Heinz Diehl wrote:
> On 27.10.2012, dave wrote: 
> 
> > Any plans to comply with TCG Platform Reset Attack Mitigation?
> 
> Why should this be neccessary? Unless you are a target for one of the
> big agencies (which 99.99% of us certainly isn't, and which would raise
> completely different problems than keys stored in memory for a few
> seconds), it doesn't make sense to me.

I agree on that. It is also out of scope, because cryptsetup
is not the platform. That would be something to be done by
the kernel crypto implelentation.
 
> To carry out this kind of attack, you need physical access to the
> computer, and there's only a very small timeframe. How real is it that
> people are just around the corner waiting to attack your machine? If
> they would wait, they could actually do it now, while the machine is
> turned on.

I do not think that you can actually prevent this attack
on an unmodified PC. It seems to require an UEFI bios.
On some systems is may be enough just to run a memory
test at the start though and/or prevent booting from
external media.

But the "TCG Platform Reset Attack Mitigation" is useless 
anyways, it does not really mitigate the attack beacuse it 
sees it with a far to narrow focus. The vulnerability is not 
that "you can boot some tool reading memory contents". The 
vulnerability is that keys may remain in memory after a forced 
system stop or reboot. 

The main problem that I see is that with physical access,
you can do things that software cannot prevent. Just rip out 
the memory modules directly, no warning to the system, and 
read them in an external reader. Maybe short-out the 12V PSU 
lines directly before so there is absolutely nothing the system 
can do. The shortening could be done with a small device 
containing a few modern power-MOSFETs and bring down CPU 
voltage in a few microseconds, i.e. no time to do anything
and a modern PC does not have a fast enough sensor for 
the voltages anyways. The CPU will just be knocked out
with no warning.

This is another solution specified by people that do not 
understand that to be secure you have to look at the 
complete attack surface. These people missed that this 
is not a software problem. 

This ''mitigation'' offers protection against a very specific 
and very small group of attackers only, namely those that are 
competent to force a PC to boot from their boot media 
(requires opening of the PC and changing of boot media if 
the PC is secured reasonably against booting external media,
i.e. external media are switched off in the BIOS) but at the 
same time are not competent to remove a memory module.

At the same time, the memory module removal is the far better
attack, as you can cool them down, extending bit-lifetime
massively and thereby making any attack much, much more
reliable. Any competent attacker with physical access will
go for memory removal IMO.

What would be needed is an effective (!) chassis intrusion
detection solution that triggers the key wipe within the
10ms a standard PC PSU will keep the power up when mains
voltage fails. That is going to be either very hard to do 
or pretty expensive. 

Pretty expensive, you can buy: There are safes with cooling
and cabeling break-outs intended to store running servers
in them. The better ones have a number of sensors and
will interrupt power on tampering. 

Very hard probably means you have to design it yourself, 
so that the attacker cannot evaluate its weaknesses
beforehand. Anything mass-produced or generally available
will have weaknesses that allow a competent attacker to 
bypass it.


Anyways, this ''mitigation'' is useless in practice as 
its very specific attacker model will usually not appply. 


Arno
-- 
Arno Wagner,    Dr. sc. techn., Dipl. Inform.,   Email: arno@xxxxxxxxxxx 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
One of the painful things about our time is that those who feel certainty 
are stupid, and those with any imagination and understanding are filled 
with doubt and indecision. -- Bertrand Russell 
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt


[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux