attestationObject is readonly?

[Việt NB]

Can the attestationObject be modified? The idea is that after the authentication device creates the attestationObject, can an attacker decode the attestationObject and modify or create a cloned attestationObject with altered information such as rpId...?

[My1]

if you have an actual attestation (meaning that it isnt using the "none" format) not really, stuff is signed in there, especially the AuthenticatorData, which contains challenge, RPID etc. possibly even twice (once by the attestation cert private key, once by the credential private key).

one thing that I am actually surprised about is that on attestation none, not even the credential key signs the registration, so the authenticator data inside the attestation object is basically free to modify as you see fit.

the none attestation should in my opinion at the very least have contained a signature over the Authdata using the credential pubkey, or be a separate object similar to assertion so that attestation signs the authdata

On the other hand, changing the RPID would not really help anyway as the keys on authenticators are origin bound and on assertion (aka logging in) while you don't have attestation data anymore, you DO have an assertion signature using the credential pubkey.

Regards

Am Fr., 15. März 2024 um 09:55 Uhr schrieb Việt NB <vietl...@gmail.com>:

Can the attestationObject be modified? The idea is that after the authentication device creates the attestationObject, can an attacker decode the attestationObject and modify or create a cloned attestationObject with altered information such as rpId...?

--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/1afbe907-9d52-4112-8782-7d8549f4281en%40fidoalliance.org.

[John Bradley]

The reason it is not signed by the authentication key is that none was something the browsers came up with to insert after they strip an attestation.  

Attestation is not optional in ctap 1, 2.0 or 2.1.  The attestation key always signs.   Browsers/Platforms were concerned about possible correlation and discrimination by exposing the AAGUID to the RP, and opted to strip the attestation or insert a self signed one on some platforms if the rp diden’t explicitly ask for an attestation in the request and the user consent to releasing adicional info.  

We did add none to ctap 2.2 but it is too late to change the format.    We could develop some new format that could be post quantum safe or zero knowledge etc.    That was why we added passing the attestation formats supported by the verifier to CTAP2.2

Sent from my iPhone

On Mar 15, 2024, at 6:37 AM, My1 <teamhyd...@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CACHSkNpEn4pcLtFgngdicHbHE9ebD5Pk7OcymMFEfPeELes4Nw%40mail.gmail.com.

[Emil Lundberg]

one thing that I am actually surprised about is that on attestation none, not even the credential key signs the registration, so the authenticator data inside the attestation object is basically free to modify as you see fit.
the none attestation should in my opinion at the very least have contained a signature over the Authdata using the credential pubkey

This is self attestation, which is supported by the "packed" attestation statement format.

BUT: it's important to note that a self attestation can also be modified, because the credential public key can simply be replaced along with a new "attestation" signature. See also Security Considerations: §13.4.4. Attestation Limitations.

This is also part of the reason why "none" attestation is the default, instead of self attestation which was the default in the early L1 drafts - a self attestation really doesn't mean very much. It was decided that no attestation at all is preferable to a meaningless attestation, to reduce the risk of mistaking a meaningless attestation for a meaningful one.

Emil Lundberg

Senior Software Engineer | Yubico

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CACHSkNpEn4pcLtFgngdicHbHE9ebD5Pk7OcymMFEfPeELes4Nw%40mail.gmail.com.

[My1]

@Emil @John 

I don't know the exact history of WebAuthn I just remember that at least in the U2F Era Browsers replaced the attestation with a generic one.

on the point of meaningless vs meaningful and self attestation (which I have seen, but I just thought as sending a claim along like an AAGUID), 2 points:

1) self attestation apparently doesnt always work if the RP isnt prepared for it (as the older verifier function would just see format packed, and no x5c, and just aborts as it does not know what to do) and if your client does not have a "remove attestation" feature, have fun registering your Device. I have the Mooltipass which was the first Device I had owned with self attestation (as it does not have a measure to protect an attestation key from the user) and stumbled for a while even on some more major sites like Google (it has got better over time, obviously)

2) while yes it doesnt really mean a lot, it at the very least means that someone somewhere actually has a key that actually works on this challenge, RPID and all and that the registration actually acknowledges the challenge and all. (while I do not know much about the ECDAA method, it at the very least offers a level of integrity, it obviously should not be seen as an actual attestation and shouldn't have any real attestation "statements" inside, as they cannot really be verified (an AAGUID if provided could at the very least give some help to the user as it helps knowing what kind of device it is when managing them, but should not have any value aside from that.

3) Passing the formats you know is very nice, not sure how that relates to CTAP (as CTAP2 devices always used packed/none [although no idea who cuts the attestation away] and CTAP1 devices always u2f, and other formats (apple,android-*,tpm) came from other methods like Cross Device and Platform which iirc are not exactly CTAP-anything), rather than WebAuthn, but at the very least the client could just throw out unsupported

Regards.

Am Fr., 15. März 2024 um 12:16 Uhr schrieb John Bradley <ve7...@ve7jtb.com>:

The reason it is not signed by the authentication key is that none was something the browsers came up with to insert after they strip an attestation.  

Attestation is not optional in ctap 1, 2.0 or 2.1.  The attestation key always signs.   Browsers/Platforms were concerned about possible correlation and discrimination by exposing the AAGUID to the RP, and opted to strip the attestation or insert a self signed one on some platforms if the rp diden’t explicitly ask for an attestation in the request and the user consent to releasing adicional info.  

We did add none to ctap 2.2 but it is too late to change the format.    We could develop some new format that could be post quantum safe or zero knowledge etc.    That was why we added passing the attestation formats supported by the verifier to CTAP2.2

Sent from my iPhone

On Mar 15, 2024, at 6:37 AM, My1 <teamhyd...@gmail.com> wrote:



if you have an actual attestation (meaning that it isnt using the "none" format) not really, stuff is signed in there, especially the AuthenticatorData, which contains challenge, RPID etc. possibly even twice (once by the attestation cert private key, once by the credential private key).

one thing that I am actually surprised about is that on attestation none, not even the credential key signs the registration, so the authenticator data inside the attestation object is basically free to modify as you see fit.

the none attestation should in my opinion at the very least have contained a signature over the Authdata using the credential pubkey, or be a separate object similar to assertion so that attestation signs the authdata

On the other hand, changing the RPID would not really help anyway as the keys on authenticators are origin bound and on assertion (aka logging in) while you don't have attestation data anymore, you DO have an assertion signature using the credential pubkey.

Regards

Am Fr., 15. März 2024 um 09:55 Uhr schrieb Việt NB <vietl...@gmail.com>:

Can the attestationObject be modified? The idea is that after the authentication device creates the attestationObject, can an attacker decode the attestationObject and modify or create a cloned attestationObject with altered information such as rpId...?

--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/1afbe907-9d52-4112-8782-7d8549f4281en%40fidoalliance.org.

--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CACHSkNpEn4pcLtFgngdicHbHE9ebD5Pk7OcymMFEfPeELes4Nw%40mail.gmail.com.