-
Notifications
You must be signed in to change notification settings - Fork 165
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ambiguous instructions in the Android Key Attestation Statement Format verification procedure #1980
Comments
After reading Android key attestation related docs, I'm thinking that the key description may have both See the following links: So, the current implementation you've provided is valid per the spec. Our implementation has similar validation logics. |
@Kieun I apologize if my description of the problem was not precise enough. As you correctly pointed out -
As an implementer, it's unclear to me how validation should look.
or
|
First of all, the KeyDescription may have
I'm not a native english speaker, but my interpretation was something like this. |
@Kieun You have provided good clarifications. It has become clear to me. It would be helpful to add a small Note to the specification, for the benefit of others as well. |
Let me verify this with Android experts, but my interpretation is that each security property can be either enforced in software or in TEE, and they can combine independently. E.g. KM_ORIGIN_GENERATED in the teeEnforced would mean the key was generated in the TEE but enforcing that the key is only used for sign ops (KM_PURPOSE_SIGN) could still be enforced by software, and therefore that property would appear in the softwareEnforced field. I don't actually know if that's a valid combination, it at least seems odd. But assuming it is valid then I think the spec is correct. In essence:
I.e. there's no reason for an RP that accepts software enforcement to reject a credential where one of these is actually TEE enforced. I'll double check if this is actually a valid scenario. |
We should poke Arnar in two weeks time about this. |
@arnar please review |
According to: https://w3c.github.io/webauthn/#android-key-attestation
According to the schema,
KeyDescription
can contain 2AuthorizationList
elements:softwareEnforced
andteeEnforced
.And the problem lies in how the specification describes
otherwise use the union of teeEnforced and softwareEnforced
.KeyDescription
can (and probably should) be interpreted as a singular (indivisible) object. From this, it follows that the formulation should be somewhat different:otherwise, the following conditions must be met for either teeEnforced or softwareEnforced.
The following combinations of parameters should be considered valid:
softwareEnforced
:purpose
- ✅validorigin
- ✅validteeEnforced
:purpose
- 🚫invalidorigin
- 🚫invalidsoftwareEnforced
:purpose
- 🚫invalidorigin
- 🚫invalidteeEnforced
:purpose
- ✅validorigin
- ✅validsoftwareEnforced
:purpose
- ✅validorigin
- ✅validteeEnforced
:purpose
- ✅validorigin
- ✅validBecause currently, the wording implies that you can combine
origin
fromsoftwareEnforced
andteeEnforced
, and check that at least one of them contains a valid value, and then do the same forpurpose
.And moreover, this is how it is done in the real world.
https://github.com/webauthn4j/webauthn4j/blob/master/webauthn4j-core/src/main/java/com/webauthn4j/validator/attestation/statement/androidkey/KeyDescriptionValidator.java#L122-L134
This leads to a scenario where such a combination of values
softwareEnforced
:purpose
- ✅validorigin
- 🚫invalidteeEnforced
:purpose
- 🚫invalidorigin
- ✅validwould pass the validation.
If KeyDescription can be interpreted as not a singular (indivisible) object, then the wording can also be changed to something more comprehensible:
otherwise, verify that each of the unions of teeEnforced and softwareEnforced parameter values meet the requirements.
In such case, the scheme outlined above would be considered legitimate.
The text was updated successfully, but these errors were encountered: