[Cryptech Tech] arm

[Leif Johansson]

> 13 jan 2015 kl. 03:30 skrev Bernd Paysan <bernd at net2o.de>:
> 
> 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.

I'm wondering how much security-fu you get by just having a library for doing simple offset byte-range checks wo actually parsing stuff inside the boundary. Extra checks w parsing done outside the boundary...

> 
> -- 
> 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*
> 
> _______________________________________________
> Tech mailing list
> Tech at cryptech.is
> https://lists.cryptech.is/listinfo/tech