[Cryptech Tech] arm

[Bernd Paysan]

Am Montag, 12. Januar 2015, 17:54:41 schrieb 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.

I see.  It fits with the "HSM controlled time" example I gave.  You probaly 
don't want to limit your check to the delta-t, because an attacker could just 
pre-sign certificates for the next 30 years, when you don't use an RTC to 
check against plausible range.

I'm quite likely thinking too muh in net2o terms: in net2o, the signature 
algorithm takes a hash of whatever you want to be signed, then feeds a block 
with signature and expiration time into that hash, and signs that; so a 
signature always consists of the interval plus the actual signature; and you 
can't separate that by signing something where the signature time and 
expiration date is already embedded.

This makes sure the signature part doesn't have to know how the rest of the 
message is structured.

> 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).

I would advocate against parsing more complex data types (think of ASN1) 
inside the ultra-secure boundary, because with bugs in the parser, you can 0wn 
the HSM.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
net2o ID: kQusJzA;7*?t=uy at X}1GWr!+0qqp_Cn176t4(dQ*