[Cryptech Tech] arm

[Rob Austein]

At Mon, 12 Jan 2015 23:33:28 +0100, Bernd Paysan wrote:
> 
> For me, it's still not clear what's the attack vector is here that
> is prevented.  Let's say I do the hash outside, transfer the hash to
> the HSM, and get a signature, what can I do by manipulating the
> hash?  I can get an invalid signature.  That's all.
> 
> If I, on the other hand, manipulate the hashed plaintext, I get a
> correct signature of something that has been manipulated.  That's
> bad.  However, even when I do the hashing on the HSM, I still can
> manipulate the plaintext outside the HSM boundary.

Canonical example, courtesy of Jakob: how would one build an HSM which
enforces a .SE policy of refusing to sign anything but DNSSEC RRsets
with a signature lifetime of less than one year?

AFAIK, there are only two answers:

1) Don't try, or

2) The HSM has to understand DNSSEC RRSIGs well enough to check or
   generate the timestamps.

The check-or-generate decision is a bit of a coin toss, main argument
in favor of only checking in the HSM is that the policy may allow a
range, in which case the HSM's job is just to enforce the range
restriction, not to pick a specific allowed value within the range.

One can phrase equivalent constraints for other protocols (eg, RPKI),
and such constraints are not necessarily limited just to timestamps
(eg, .SE might also want to enforce a restriction that they will only
sign RRsets in the .SE zone, which translates to a restriction on what
value is allowed to appear in the "Signer's Name" field of the RRSIG).