RE: Attestation formats

So maybe what I am struggling with is a mismatch of mental models. Here is the way I look at it, LMK if you see it differently:


-          Packed attestation assumes an authenticator generating the structure. So extensions etc. are all well integrated here.

-          TPMs however are basic crypto engines. A real FIDO authenticator would involve a bunch of logic wrapping a TPM (e.g. display for transaction auth). So to make things like extensions meaningful, they would have to come from this part of the authenticator that lies outside the TPM. The TPM would then take this input and sign it. So while the TPM will sign arbitrary things it is the job of the rest of the authenticator to make sure it does not sign invalid statements.

-          Android N is again the entire authenticator. However the attestation format it uses<https://developer.android.com/preview/features/key-attestation.html> relies on X.509 certificates - from the documentation, it appears to me that it effectively generates a new X.509 certificate every time it's asked to attest to a key, and returns that certificate. But it's not clear how or where a transaction authorization would show up (or any other getAssertion extension). It would seem like adding that would require changes to Android itself, along with corresponding changes to the data schema.

Now all that is thinking from the POV of what the *authenticator* does. The attestation format is a lower level still; it is an algorithm parametrized by things that the authenticator knows (e.g. AAGUID) and so even though these things are not passed to the authenticator they are still parameters to the signature.

So maybe the definition of an attestation format becomes:

-          Inputs: AAGUID, signature counter, public key, credential ID, clientDataHash, extensions

-          Output: Attestation statement specified as WebIDL fragment

-          Procedures:

o   Take above inputs, produce a statement

o   Take above inputs and a statement, verify the statement

Is that better?

From: Rolf Lindemann [mailto:rlindemann@noknok.com]
Sent: Friday, July 22, 2016 12:26 PM
To: Vijay Bharadwaj <vijaybh@microsoft.com>; 'Rolf Lindemann' <rlindemann@noknok.com>; 'W3C WebAuthn WG' <public-webauthn@w3.org>
Subject: 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<mailto:vijaybh@microsoft.com>>; 'W3C WebAuthn WG' <public-webauthn@w3.org<mailto:public-webauthn@w3.org>>; 'Rolf Lindemann' <rlindemann@noknok.com<mailto: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