[17047] in cryptography@c2.net mail archive
Please forward to cryptography@ list.
daemon@ATHENA.MIT.EDU (Perry E. Metzger)
Sun Mar 13 14:35:07 2005
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
To: cryptography@metzdowd.com
From: "Perry E. Metzger" <perry@piermont.com>
Date: Wed, 09 Mar 2005 08:21:51 -0500
Forwarded at PHK's request.
To: "Perry E. Metzger" <perry@piermont.com>
Subject: Please forward to cryptography@ list.
From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Tue, 08 Mar 2005 14:29:20 +0100
I have read the comments on gbde in the archive of the cryptography@
list and I would like to attach some comments to some of them.
To Ivan Krstic:
One of the unfortunate disadvantages of the complexity of GBDE is
that it is not possible to judge in on a quick glance.
I have ignored Joseph Ashwoods complaints, I found neither facts
in his email nor credenticals for him that could make them useful
to me. I will be happy to consider any substantiated critique from
him.
Rolands preliminary analysis is very interesting and I very much
appreciate him taking time to do it. I have sent my comments to
him in private. Again, I will agree that the complexity does add
to the analysis workload.
Roland may be on to an attack vector which is cheaper than I had
anticipated, but his estimate so far is 2^128 * 2^104 and there are
a couple of not at all trivial tasks he needs to account for still,
and it is not clear what the cost of cul-de-sac searches will be.
Dan Kaminsky raises the point of ghosting at the physical level.
There is nothing reliable GBDE or any other software can do about
that. I talked to one disk-recovery company who said that they
would almost guarantee that they could recover the previous
contents of any sector on any disk (ie: one generation back) and
often they could also find the generation before that. They could
not say if the amount of entropy in the data made a difference,
but they generally had little trouble with compressed images.
David Wagner has once again earned my grattitude for taking time to
look at this, and he raises some very valid points.
The paper was written for the BSDcon conference and in addition to
being on OS-focused rather than crypto-focused audience, this also
imposed a 12 page limit on the paper. For practical reasons I am
restricted to a couple of conferences abroad every year and I have
not had opportunity to present the paper at a venue where a major
revision would be warranted.
I did look into using a stronger keying method for GBDE, but most
of the software I found that could have been used to implement this
would not allow an easy way to override in the cases where qualified
administrator wanted to use an existing or just different keying
infrastructure.
We know from earlier experience that lack of override results in
tools like "expect" being used to chat with the offending code,
and we know how secure that is.
Add to this that public-key software adds significant complexity
and often user/administrator learning curve and the desirability
dropped fast.
In the end I decided that by making GBDE a tool for encrypting a
disk, keyed by a bytestring of arbitrary length, it would be possible
for any and all keying scheme to be put in front of GBDE.
And it is being used. For instance several users have related to
me how they have created some kilobyts of PRNG bits, encrypted them
with their PGP key and use that for a keying scheme.
The "default" keying scheme of using only the entered pass-phrase
is totally inadequate for any but the most trivial use, and I have
made a big point out of this both in section 9.3 in the paper and
in the presentations I have given on GBDE.
Some users have said that all they wanted "for now" was trivial
protection, but would like to have the option of upgrading to
stronger but more cumbersome keying "on moments notice".
In summary I agree with the sentiment that there is a significant
risk of unwise usage, but I do not see it as being GBDE's job to
solve this. What is missing is "front-burner" programs that implement
good keying methods and deliver the "magic" byte string to GBDE
when satisfied with the keying condition.
The threat model for GBDE is a sort of "real world compromise"
roughly covering lost/forgotten laptops, media transportation and
insider snooping.
Stolen/Lost laptops is a bimodal threat, you have random theft
and targeted (industrial) espionage. They strength of your
keying should reflect what your fear.
If data media are transported, "good practice" dictate that the key
and a good hash of the contents should be transmitted using a
sufficiently trusted secondary channel. Keys are often
PRNG data in these scenarios.
Insider snooping or "cleaning lady" attack is the hardest to offer
defense against, because operational patterns will expose the
geometry related hiding on relatively short order. On the other
hand, the geometry hiding adds a pretty solid work factor for
the "cold media" case, so it is still worth it.
Replay and chosen cipher-text attacks are solidly outside the scope
of GBDE. Such attacks are only relevant for GBDE under the
cleaning-lady scenario where the attacker can be pressumed to also
be able to install key-stroke loggers, root-kits and God knows
what else.
In that world, GBDE cannot do anything alone. The only way to
ensure data integrity is by having some sort of off-line secret.
The secret may be just a generation number to be remembered from
session to session, a tripwire like inventory or a complete off-line
backup, but some sort of off-line token is necessary.
That said, apart from a wholesale roll-back of the contents of the
disk, a replay attack will be very tricky to get reliably right for
an attacker unless the cleaning lady knows which exact sector
is interesting.
Chosen cipher text is not protected at all GBDE right now, the IV
to the sector encryption should have been a masterkey field like
the salt. This is an oversight which will be fixed next time the
masterkey format changes.
With respect to laptops: there is no way to secure a laptop if you
do not power it down and remove the battery.
Laptop designs are closed, and we have no way or reason to trust
the significant and often buggy ACPI code which deals with the
entire hardware state to not have backdoors (deliberate or accidental).
At least some laptops have BIOS backdoors by design, but very little
have been revealed about how these works. On one Dell I owned a
time varying 5 character code could be displayed by the BIOS and
Dell could translate this to/generate from this a code which would
result in the BIOS passwords being erased.
Connectivity options like Firewire have modes which allow full
access to all the RAM on the machine, it is not always possible
to disable these modes.
Finally many if not all laptops have JTAG test points on the
motherboard and in some cases in the docking connector. That gives
full 100% unadultered control over the CPU and peripheral chips.
With respect to implementation: I have done my best, but as Djikstra
remarked 40 years ago "I am [...] aware that I have only a small
head, and must live with it.".
The implemntation goes to some length to wipe secrets from RAM, but
for reasons of anti-complexity (and in the case of disk-ghosting:
performance) it has not been a major priority to protect against
attacks on ghost images in RAM or on disk.
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
