From: Arno Wagner <arno@wagner.name>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] Memory Overwrite Request in cryptsetup
Date: Sat, 27 Oct 2012 13:48:37 +0200 [thread overview]
Message-ID: <20121027114837.GA15345@tansi.org> (raw)
In-Reply-To: <20121027104803.GB1497@fancy-poultry.org>
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@wagner.name
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
prev parent reply other threads:[~2012-10-27 11:48 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-27 4:42 [dm-crypt] Memory Overwrite Request in cryptsetup dave
2012-10-27 10:48 ` Heinz Diehl
2012-10-27 11:48 ` Arno Wagner [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121027114837.GA15345@tansi.org \
--to=arno@wagner.name \
--cc=dm-crypt@saout.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.