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