search

project-chip / connectedhomeip

Matter (formerly Project CHIP) creates more connections between more objects, simplifying development for manufacturers and increasing compatibility for consumers, guided by the Connectivity Standards Alliance.
https://buildwithmatter.com
Apache License 2.0
7.47k stars 2k forks source link

AddTrustedRootCertificate Command send constraint_error when invalid_command is expected while sending malformed certificate #19839

Closed sowmyassp closed 2 years ago

sowmyassp commented 2 years ago

Problem:

When Arm fail command is sent with malformed Root Certificate in a new fail safe timer period we expect to see INVALID_Command but we are seeing CONSTRAINT_ERROR

Spec Referrence-11.18.7.13 image

Commit used : c60233daaa8ea68b4f1198d640e6f89966363f31

Sequence of Steps: 1.Commission DUT to TH - Success

  1. Send arm-fail-safe commad - Sucess
  2. Send AddTrustedRootCertificate Command with valid root certificate - Success
  3. In a new fail safe timer period send arm-fail-safe command - Success
  4. Send AddTrustedRootCertificate Command with malformed root certificate - Failure(CONSTRAINT_ERROR)

Test platform : Chip-tool - RPI-4, 8GB RAM DUT - RPI - RPI-4, 8GB RAM

Test-plan reference : https://github.com/CHIP-Specifications/chip-test-plans/blob/master/src/devicemanagement.adoc#tc-opcreds-3-1-attribute-nocs-trustedrootcertificates-list-validation-dut-server

PFA Logs: TC-OPCREDS_3.1_cntrl.txt

bzbarsky-apple commented 2 years ago
  1. Send AddTrustedRootCertificate Command with malformed root certificate - Failure(CONSTRAINT_ERROR)

@sowmyassp The spec section being cited above is for the case of a valid new root certificate that: 1) Has the same public key as some existing root certificate. 2) Is not byte for byte identical to that existing root certificate.

So if a malformed root certificate is being sent that spec section does not apply.

But also, the steps shown in the log are:

  1. Arm a fail-safe for 60 seconds. This command is sent at: 
    [1655883147.902968][12348:12356] CHIP:IN: Sending encrypted msg 0xaaaad978bc68 with MessageCounter:186295179 to 0x0000000000000001 (1) at monotonic time: 000000000087735D msec
  2. Add a trusted root certificate.
  3. Arm a fail-safe again for 60 seconds. This command is sent at: 
    [1655883160.848323][12384:12389] CHIP:IN: Sending encrypted msg 0xaaaae5859538 with MessageCounter:205635958 to 0x0000000000000001 (1) at monotonic time: 000000000087A5EF msec

So we arm a fail-safe for 60 seconds, then 13 seconds pass, then we arm for 60 seconds, which just extends the existing non-expired fail-safe. Then we try to add a second root certificate, and the relevant spec bit is:

If a prior AddTrustedRootCertificate command was successfully invoked within the fail-safe timer period, which would cause the new invocation to add a second root certificate within a given fail-safe timer period, then this command SHALL fail with a CONSTRAINT_ERROR status code sent back to the initiator.

which is what happens here.

bzbarsky-apple commented 2 years ago

I read through the test plan, and it looks like this is trying to do step 40 from the test plan? But the steps being carried out above look nothing like the parts of the test plan that come before step 40....

bzbarsky-apple commented 2 years ago

Though following the test plan exactly would run into trouble too. Filed https://github.com/CHIP-Specifications/chip-test-plans/issues/1560