[148071] in cryptography@c2.net mail archive
Re: [Cryptography] suggestions for very very early initialization
daemon@ATHENA.MIT.EDU (Jerry Leichter)
Thu Nov 7 13:41:47 2013
X-Original-To: cryptography@metzdowd.com
From: Jerry Leichter <leichter@lrw.com>
In-Reply-To: <527B302D.4030803@av8n.com>
Date: Thu, 7 Nov 2013 07:01:05 -0500
To: John Denker <jsd@av8n.com>
Cc: Cryptography <cryptography@metzdowd.com>, RNG mlist <rng@lists.bitrot.info>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
On Nov 7, 2013, at 1:16 AM, John Denker wrote:
>> I can think of one simple example: A CD Linux image
>> used precisely to conduct operations we want to keep secure. For
>> example, there's a suggestion that small businesses use exactly such
>> a thing to do their on-line banking, as their usual systems are way
>> too vulnerable to various kinds of malware (and small businesses have
>> been subject to attacks that bankrupted them). The CD itself can't
>> carry a seed, as it will be re-used repeatedly. It has to come up
>> quickly, and on pretty much any hardware, to be useful. You could
>> probably get something like Turbid in there - but there are plenty of
>> CD's around already that have little if anything.
> =
> That's too contrived to hold my interest. Here's why:
> =
> In most cases, the best advice is this:
> =
> If you feel the urge to use
> read-only media and nothing else,
> lie down until the feeling goes away. =
We really don't need this kind of dismissive advice. There are plenty of p=
eople out there who need the best solution we can devise, given limitations=
on what they have available to them.
> In the vast majority of cases, anything the small business owner
> could do with a "Live CD" could be done more conveniently =96 and =
> much more securely =96 using a USB flash drive. You can still boot =
> from a read-only partition if you choose, while still having a =
> read/write partition for storing seeds and other stuff that should =
> persist from one boot to the next.
*Nothing* should persist from one boot to the next. That's exactly the poi=
nt of using a read-only image: Even if session n is hit by malware that co=
mpletely compromises it, session n+1 will come up completely clean. Assume=
we're very disciplined and resist the urge to put anything on the read/wri=
te partition other than a random seed - anything more could potentially tri=
gger some bug that carries the infection on to the next session. If an inf=
ected session n can leave behind a known random seed, we've reduced the pro=
blem for the attacker to that of a completely read-only system. So we *sti=
ll* need some solution in that case.
BTW, what's this "read-only partition" you speak of? Something enforced by=
the OS, which might get compromised? Or are we talking some special USB f=
lash drive that enforces the read-only state? Got a source for those? I'v=
e never seen one. (SD memory cards have a write-protect notch on the side,=
but the protection is enforced by software on the host, and in any case is=
all-or-nothing.)
> [Other suggestions involving a VM and a guest system]
a) "The best is the enemy of the good"
b) Is this even "best"? The proposed system is *much* more complex, and h=
as a *much* larger attack surface. Attacks against host systems from guest=
s have appeared in the past, and will likely continue to appear. "Having t=
he advantages of a read/write file system" almost means "having the liabili=
ties of a read/write file system."
A very simple, physically non-modifiable, one-purpose system is ideal from =
a security point of view. The ideal hardware base on which to run it provi=
des a good, non-modifiable source of randomness. ("Non-modifiable" isn't q=
uite the right term: After a boot, the source must be unpredictable even t=
o someone who had innermost-level access prior to the boot. And of course =
there's a need for other controls to guarantee that the code actually boote=
d is the code on the CD, nothing more and nothing less: Modified BIOS's an=
d such make any attempt at a software solution pointless, though actual fie=
lded attacks at this level have been rare.) If you have the necessary hard=
ware, fantastic, use it. If you don't, you should do the best you can.
-- Jerry
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
