search

fido-alliance / conformance-test-tools-resources

Certification Test Tools Resources. For security and privacy related issues email tools@certification.fidoalliance.org
https://fidoalliance.org/certification/functional-certification/conformance/
40 stars 14 forks source link

UVM test fails with metadata mentioning multiple matcher protection #730

Closed serianox closed 9 months ago

serianox commented 10 months ago

By submitting this issue you are acknowledging that any information regarding this issue will be publicly available.

If you have privacy concerns, please email conformance-tools@fidoalliance.org

FIRST PRE CHECK

What protocol are you implementing?

NOTE: UAF 1.0 certification have been officially sunset. U2F 1.2 only supported version of U2F.

What is your implementation class?

If you are platform authenticator vendor, please email conformance-tools@fidoalliance.org

What is the version of the tool are you using?

What is the OS and the version are you running?

For desktop tools

For UAF mobile tools

Issue description

When testing an authenticator with the following UVM

82            # array(2)
   83         # array(3)
      01      # unsigned(1) presence_internal
      0A      # unsigned(10) key_protextion_hardware | key_protection_secure_element
      04      # unsigned(4) matcher_protection_on_chip
   83         # array(3)
      19 0800 # unsigned(2048) passcode_external
      0A      # unsigned(10) key_protextion_hardware | key_protection_secure_element
      01      # unsigned(1) matcher_protection_software

The metadata is set accordingly to the following

   "matcherProtection": [
      "software",
      "on_chip"
   ],

The test Metadata-Stmt-1 P-16 fails at ctap2.1-conformance-module/tests/CTAP2/Metadata/Metadata-Stmt-1.js:492 with the following error

AssertionError: "on_chip" flag can not be combined with "software" flag!: expected [ 'software', 'on_chip' ] to not include 'on_chip' at n.eval (eval at compileCode (js/sandbox.js:25:26), :2027:20)

The specification mentions

matcherProtection, of type DOMString[] The list of matcher protections supported by the authenticator. Must be set to the complete list of the supported MATCHER_PROTECTION constant case-sensitive string names defined in the FIDO Registry of Predefined Values [FIDORegistry]. See section "Matcher Protection Types", e.g. "on_chip". This value MUST NOT be empty.

The test expect the list to contain only one element. This is probably a leftover of the MDS2 tests where the values were mutually exclusive.

iirachek commented 9 months ago

@serianox I believe the tests are correct to be expecting only one element, since the values are still indirectly mentioned as being mutually exclusive.

The specification contains the following note below the definition of matcherProtection member of metadata:

If multiple user verification methods ("matchers") are implemented, then this value must reflect the weakest implementation of all user verification methods.

Which means that between "software" and "on_chip" only one should be listed, with "software" being the weakest among them.

Additionally (though not as relevant), in the registry of predefined values the "on_chip" type is noted as:

Mutually exclusive in authenticator metadata with MATCHER_PROTECTION_TEE, MATCHER_PROTECTION_SOFTWARE

serianox commented 9 months ago

@iirachek

I'm not sure what the author wanted. This field is a list, so multiple values are expected (emphasis is from the original text)

Must be set to the complete list of the supported MATCHER_PROTECTION constant

And then right below in a note

If multiple user verification methods ("matchers") are implemented, then this value must reflect the weakest implementation of all user verification methods.

I would assume that ["on_chip", "software"] is perfectly fine and also reflects the weakest implementation because "software" is listed.

But then as you mentioned, the registry states that some values for MATCHER_PROTECTION are mutually exclusive. However, I do think that the value being exclusive is only valid for the bitfields in UAF, not the textual representation of MDS3.

Now, assuming that the values are indeed exclusive, I change my metadata statement to the following since I support passcode_external and presence_internal, 

   "matcherProtection": [
      "software"
   ],

The test fails differently: when verifying the UVM value for 

   83         # array(3)
      01      # unsigned(1) presence_internal
      0A      # unsigned(10) key_protextion_hardware | key_protection_secure_element
      04      # unsigned(4) matcher_protection_on_chip

it expects to find "on_chip" in the list matcherProtection. But since the list contains only one element, the weakest, it can't because only "software" is listed.

Here, I think the test should:

iirachek commented 9 months ago

I've asked internally for additional clarifications regarding this part of the specification. Until then, this issue is on hold.

serianox commented 9 months ago

Thanks. In the meantime I'll dig a bit more and try alternative scenarios.

pheimfido commented 9 months ago

Yes, as mentioned by Illia, this issue has been raised to the FIDO MDS TWG Leadership for feedback and guidance to be provided. We'll update this issue as soon as a resolution is reached. - Paul Heim, Certification Director, FIDO Alliance

iirachek commented 9 months ago

@serianox

In short, your original implementation is correct. The normative clauses and the data type of matcherProtection support multiple entries. Thus for the UVM provided in your question, the correct metadata statement will contain both "on_chip" and "software".

The related tests were updated in the new build (1.7.17) to account for that.

serianox commented 9 months ago

@iirachek Thanks! I've read the PR and it looks good to me. I'll test it tomorrow as soon as possible to give feedbacks.

serianox commented 9 months ago

I apologize for the delay, I had a little setback.

I did test fully and now the test is passing as expected. 👍