AW: Attestation formats

Hi Vijay,

 

> how are extensions supported on the TPM and Android formats? Or are they
not supported at all

Don't remember the TPM rawData format, but in the case of Android "N", the
rawData is a DER encoded X.509 certificate structure.  Extensions could be
added as (additional) certificate extensions.

 

> It seems to me that every scheme is capable of signing arbitrary rawData,
since every scheme takes in a challenge to sign

There could be a misunderstanding here.

At this time the "rawData" is the to-be-signed object, i.e. the structure
which (from a security perspective) must be (and is) controlled by the
authenticators.

Authenticators *do not* sign arbitrary hash values with the attestation key.
This applies to TPMs, Android "N" and Authenticators implementing "packed"
attestation.

BUT: there is a well-defined slot for the clientDataHash in the rawData (in
all cases).

 

Extensions (to be meaningful) would have to be understood (and controlled)
by the Authenticator.  Otherwise it is just another slot in the clientData
which was used to compute the clientDataHash provided by the calling app.

 

 

Since TPMs and Android "N" are out there, I don't see a way to modify their
internal data structures.  SO in my opinion we have to accept some different
rawData formats in attestation.

 

Kind regards,

   Rolf

 

Von: Vijay Bharadwaj [mailto:vijaybh@microsoft.com] 
Gesendet: Freitag, 22. Juli 2016 18:21
An: Rolf Lindemann; 'W3C WebAuthn WG'
Betreff: RE: Attestation formats

 

That seems reasonable at a high level, but I still have the question - how
are extensions supported on the TPM and Android formats? Or are they not
supported at all?

 

It seems to me that every scheme is capable of signing arbitrary rawData,
since every scheme takes in a challenge to sign, and the rawData could for
example be hashed into the challenge. That would also make for uniform
support of things like extensions across all formats.

 

The way the spec is currently written, it seems like every new attestation
format can similarly describe its own support for all these things, which
seems like a recipe for long-term inconsistency.

 

From: Rolf Lindemann [mailto:rlindemann@noknok.com] 
Sent: Friday, July 22, 2016 12:06 AM
To: Vijay Bharadwaj <vijaybh@microsoft.com>; 'W3C WebAuthn WG'
<public-webauthn@w3.org>; 'Rolf Lindemann' <rlindemann@noknok.com>
Subject: AW: Attestation formats

 

Hi Vijay,

 

the rawData is always generated by the authenticator.

In the initial attestation section, there was a single JSON
attestationStatement structure and different rawData formats (one for
packed, one for TPMs and one for SafetyNet).

The idea was to replace the SafetyNet one by Android "N" HW key attestation.

In that case we would have 3 different but similarly capable rawData
structures.

Note that at this time, the TPMs are *not* generating packed attestation nor
des Android "N" generate it (even though it supports HW attestation).

 

>From a security perspective, the attestation rawData structure needs to be
controlled and signed by the Authenticator (or its crypto kernel). 

 

I don't think that "A method to take in a rawData in the above format and
produce a signature" makes much sense as it suggests to get an arbitrary
rawData object signed.

 

I would propose the following:

1.       Remove the SafetyNet thing at this offers substantially different
security guarantees than all others and replace it by Android "N"
attestation.

2.       Define a single attestationStatmeent (JSON) structure.

3.       Keep the different attestation rawData formats (i.e. Android "N",
TPM and "packed".

4.       Potentially add more rawData formats (by the registry approach) if
this cannot be avoided in order to supports other plaforms.

 

Kind regards,

    Rolf

 

Von: Vijay Bharadwaj [mailto:vijaybh@microsoft.com] 
Gesendet: Freitag, 22. Juli 2016 08:19
An: W3C WebAuthn WG; Rolf Lindemann
Betreff: Attestation formats

 

I was looking through the attestation formats and it seems to me that this
area could use some cleanup. All the formats are defined in very different
ways and it's not clear that all of them are equally capable. For instance
none of the formats other than packed are able to deal with extensions at
all. Also, Android attestation is quite weird in that it extends the
ClientData with fields that really should be authenticator-attested.

 

I would like to revise this section significantly, and organize it as
follows:

-          In the core spec, define the rawData format for packed
attestation as the thing that is always generated by the authenticator. This
could even be extended by the above (Android) fields if necessary.

-          Define an attestation format as consisting of the following
things:

o   A method to take in a rawData in the above format and produce a
signature

o   A method to verify the above signature

-          Rewrite the attestation formats section in the above format

 

This would also allow for adding new attestation formats in the future by
taking a registry approach, as Giri had suggested.

 

What do others think? If we have some momentum around this idea I can do up
a PR by early next week.

 

--

-Vijay