On Oct 16, 2012, at 5:52 AM, Robert Kisteleki <[email protected]> wrote:
> The attacker's point is not to *steal* the key, but to *sign* something with > it; most likely a hash or such. If I can inject a hash-to-be-signed into the > to-be-signed queue, then I won, I don't really care about the key itself. > Sure, if I actually have a copy of the key, then it's way easier :-) but as > you say, HSMs can prevent that. And, as some of others of us say, systems that act like HSMs can prevent that as well. >> Also note that there are possible weaknesses with even an HSM, depending >> on how backups are made. These can be worked around with procedure and >> extra layers of security (cameras, access logs, ...). > > It's possible to come up with bad escrow mechanisms, which leave the key > vulnerable. That's just bad engineering, it's got nothing to do with HSMs. > However, a properly designed procedure with enough support from the HSM will > defend against this. The same is true for systems that act like HSMs. The two security properties of an HSM that prevents the attack scenario of "the attacker has the private key and can therefore sign arbitrary messages" are "the private key cannot be extracted by the HSM" and "the HSM only signs messages given to it". A properly-designed software system where no logged-in user can ever see the the private key, nor affect the messages that are signed, has the same properties. There is a real question about whether HSMs or systems that act like HSMs have side-channel attacks that would leak the private key. --Paul Hoffman _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
