[6334] in cryptography@c2.net mail archive
Re: starting up servers that need access to secrets
daemon@ATHENA.MIT.EDU (Ted Lemon)
Wed Jan 5 13:25:06 2000
Message-Id: <200001051601.LAA13970@grosse.manhattan.fugue.com>
To: Rich Salz <salzr@certco.com>
Cc: "Jeffrey M. Smith" <jsmith@purdue.edu>, cryptography@c2.net
In-Reply-To: Message from Rich Salz <salzr@certco.com>
of "Wed, 05 Jan 2000 00:15:21 EST." <Pine.BSI.3.96.1000105000643.13496H-100000@haggis.ma.certco.com>
Date: Wed, 05 Jan 2000 11:01:23 -0500
From: Ted Lemon <mellon@isc.org>
Rich, in the one case in order to steal your key (and thus masquerade
as you) the person has to break into your machine and read a file. In
the other case, the person has to break into your machine and *write*
a *specific* file. While both sorts of attacks are possible, the
first sort of attack is essentially impossible to detect by examining
the system after the fact, whereas the second kind of attack is
relatively easy to detect after the fact.
Many operating systems provide securelevels, where when you increment
the securelevel, you can't subsequently decrement it without
rebooting, and at a certain securelevel, you can't write to files
marked immutable. If you can identify the set of files one or more of
which would have to be modified in order to compromise your key, make
them immutable, and don't listen on the network until the securelevel
is high enough to prevent the modification of immutable files, and you
don't store your key on disk, then you have a pretty credible defense
against a key compromise.
The set of files is large, and the kernel has to not have any bugs
that allow securelevel to be decremented or the immutable flag to be
circumvented, but this is a problem that one can actually approach
solving. Solving the problem of making it impossible for someone to
read an arbitrary file on your system is also solvable, but more
difficult, and less auditable.
Which is a long-winded way of saying that yes, I think it does make a
difference. :'}
_MelloN_
