Re: [Anima] Pinning of raw public keys in Constrained Vouchers

[Jim Schaad <[e-mail]>]

> -----Original Message-----
> From: Michael Richardson <[e-mail]>
> Sent: Wednesday, May 29, 2019 8:37 AM
> To: Jim Schaad <[e-mail]>
> Cc: [e-mail]; 'Esko Dijk' <[e-mail]>;
'=?iso-8859-
> 1?Q?'G=F6ran_Selander'?=' <[e-mail]>
> Subject: Re: Pinning of raw public keys in Constrained Vouchers
> 
> 
> Jim Schaad <[e-mail]> wrote:
>     jim> As I remember things:
>     jim> * Adding the random value would make the collision resistance
attack
>     jim> simpler for the registrar.  It has some random bytes that do not
>     jim> have to have any structure to create two different public keys
with
>     jim> the same hash value.
> 
>     >> Sorry, do you mean, simpler for an attack on the registrar?
> 
>     > No, I mean a simpler attack by the registrar.
> 
> Yes, I'd call it the malicious registrar.
> 
> The attack would take an existing (nonceless) voucher that pinned the
device
> to a specific registrar, and then try to create a registrar with a keypair
that
> hashes the same.  This would be used for offline registrars.
> If we pin the public key then this can not happen.
> 
>     > Given that this is a DER encoded item, there is no way for a victim
to
>     > ignore the extra bytes inside of the SPKI structure.   If it does
then then
>     > it is completely incorrectly doing the parsing.  You would not even
be able
>     > to have trailing bytes that might or might not be part of the SPKI
object.
>     > Even if you did BER indefinite length encoding, you would not be
able to
>     > ignore the extra bytes, but you would have bytes to play with as you
can
>     > have different encodings that represent the same output value.
> 
> Are we are agreeing, but using different terms?
> So yes, an attacker could resort to non-DER encoding (BER encoding) to
give
> it bytes to play with. That would be non-DER though.
> My reading of the ASN.1 is that one could include arbitrary additional
> parameters in the algorithm SEQUENCE, (correctly DER encoded) and use
> those bytes to do the pre-image attack... except that it would fail
because
> constrained devices are using memcmp().

No - there are constraints on what can occur in the ANY field (1988 syntax)
that are defined by the OID of the algorithm.  Thus while the structure
allows for arbitrary additional parameters, they are restricted by the
algorithm to a single (usually absent or NULL) value.

> 
>     >> In practice, most constrained implementations avoid DER parsing by
>     >> accepting a known sequence of bytes for the subject-public-key-info
> and
>     >> use memcmp().
>     >> I.e. they are extremely conservative in what they accept, to the
point of
>     >> violating the specification one could argue.
> 
>     jim> I don't know that I would say that this is a violation of the
spec.  You
>     jim> are saying does this match what I expect to see and since it is
DER a
> memcmp
>     jim> is a fine way to do this.
> 
> well, because it locks the list of parameters to be 0.
> 
> AlgorithmIdentifier  ::=  SEQUENCE  {
>         algorithm               OBJECT IDENTIFIER,
>         parameters              ANY DEFINED BY algorithm OPTIONAL  }
> 
> Perhaps we have never extended any, but the extension point is right here.

This is the syntax that I normally use:

AlgorithmIdentifier{ALGORITHM-TYPE, ALGORITHM-TYPE:AlgorithmSet} ::=
        SEQUENCE {
            algorithm   ALGORITHM-TYPE.&id({AlgorithmSet}),
            parameters  ALGORITHM-TYPE.
                   &Params({AlgorithmSet}{@algorithm}) OPTIONAL
        }

Which shows that the extension point is restricted and not completely open.
Use the DER sequence requires that this be checked correctly.

> 
>     >> We make certificates by doing sha256 hashes of the
subject-public-key-
> info
>     >> and other names, and having the CA sign that.  I think that it
makes no
>     >> sense to truncate the hash going into a 256-bit sized signature,
since
>     >. ECDSA signs 256-bit values.   I am not sure how to evaluate the
strengh
> required here.
>     >> It's a CBOR value, so it has a length, and I suppose we could
define a
> way to
>     >> truncate the value in a standard direction, and then decide later.
> 
>     > The first sentence has me slightly worried.  Is the CA computing the
hash
> or
>     > is the hash being provided to the CA?
> 
> I think that in traditional CA processing, we provide the public key (in a
> CSR) to the CA, and it computes the hash.   My point here is that if we
were
> concerned (as I concern myself above) with pre-image attacks against
sha256
> under signature, then we should be concerned about certificates, period
:-)
> 
> I think that we can also intelligently advise pledge to carefully check
the DER
> encoding is minimal, and using memcmp() works very well here.
> Stupider implementation wins here :-)
> 
> 
>     >> I think that a non-truncated hash ought to be as strong as sending
the
> key
>     >> itself, and having two code paths is not a win here.
> 
>     > One attack is a birthday attack.  This is O(2^(n/2)) in terms of
inputs to
>     > be evaluated.  That is if you compute 2^(n/2) hash values you have a
> 50/50
>     > chance of finding a collision.  This means that it takes 2^128
attempts for
>     > a 256-bit hash value, but only 2^64 for a 128-bit hash value, even
if you
>     > truncate as SHA-256 value to 128 bits rather than using a 128-bit
hash
>     > function (such as AES-CBC).   The idea that 64-bit authentication
values
> are
>     > fine is the current thinking in the CoRE and ACE groups as that is
the size
>     > of authentication value that is being used for encryption of items.
Part of
>     > this is based on the assumption that these values are only of
interest for
>     > short term and not historically.  TLS on the other hand is worried
about
>     > long term (i.e. recorded for later use) and thus has gone with
longer
>     > authentication values as a general rule.  In COSE we are saying that
a
>     > truncated hash is fine for identifying certificates, but that is
operating
>     > as a filter rather than an identifier.
> 
> I have not paid enough attention to the HMAC algorithms in COSE... just
> reading rfc8152.  Truncated to 64-bits.  Hmm.  We wouldn't have a keyed-
> hash, just a hash, which makes it more vulnerable to off-line dictionary
> attacks I think.
> But, I think you are perhaps referring to the kid usage?

Look at the hash draft not the RFC -
https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/
> 
> In online uses of the voucher, it has a limited time when it is useful,
and in
> the online usage, there is also a freshness nonce.  So it seems that we
could
> truncate the hash efficiently.  It would be inappropriate to generate
off-line
> nonceless (constrained) vouchers with this method, but I think that is
> something we can write down intelligently.

I would want to read the result, but I think this would be correct.

Jim

> 
> --
> ]               Never tell me the odds!                 | ipv6 mesh
networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect
[
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails
[
> 
> 
> 
> 
> 
> 
> 
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
>