At 12:00 -0400 4/21/09, Andrew Sullivan wrote:
On Tue, Apr 21, 2009 at 11:45:18AM -0400, Edward Lewis wrote:
Suppose that I tightly constrain who reads the database.
Suppose you do. Then you still have the problem of escalation attacks.
HSMs are designed to make such attacks impossible: the key simply
won't come out. That's a better answer than, "I've set it up so that
just about nobody can get to the key", since privilege escalation in
database systems is exactly the place good attackers work. I notice
in passing that a certain large company who recently bought Sun no
longer makes "unbreakable" claims loudly and in public.
Hmmm, this doesn't apply... To be fair, I don't want to dive into
the details of what I see. Thus the justification of my reaction
here is not going to be convincing.
Trying to fudge around a bit for the justification, the database and
the key are not linked "in series", they are both are behind the some
of the same fortifications. "Breaking the database" security won't
make getting to the key any easier, i.e., the database does not
contain the information needed to access the key.
In a way, I figure - "if you can read my private key, I have larger
issues to deal with."
At the IEPG meeting in, umm, not SF, but in, umm, where was, oh,
Minneapolis, I mentioned that the "value in protecting the private
key is a function of the cost of rolling to a new key." If the key
is a SEP, it's the cost of rolling it through the trust anchor
repositories, if the key is a lowly ZSK, then it's more or less just
the liability for goofing up. It's not like someone reading the key
is going to unlock encrypted state secrets and such.
I should add too that the impact of someone reading the key and
someone reverse-engineering (guessing) the key is essentially the
same. The latter is a different cause though - "luck" or weak choice
of a key pair that succumbs to a key dictionary attack. (HSMs are
not there so much for that unless they have an enhanced way to choose
"random" numbers - which some do advertise.)
I guess the equation is - the cost of an HSM vs. the value of saving
one's operations from key "exposure." (Not the same as a forged
response.)
Sorry if it sounds like I'm just talking in circles. But I can't see
the very vulnerability that an HSM addresses as being likely enough
to be worth addressing given all the other vulnerabilities.
(Finally, my mantra here. HSMs are not total wastes. HSMs do add
value. But just not universally needed/incrementally valuable.)
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar You can leave a voice message at +1-571-434-5468
Getting everything you want is easy if you don't want much.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
