Matter examples Device Attestation

[rlk0]

I built and ran the Matter Light Bulb example for Thread and was able to commission it into Home Assistant with no issues. However, when I tired the Matter Temperature Sensor example, during commissioning, I got an "Uncertified Device" warning and at the very last stage, it failed to add to Home Assistant (not unexpected for an Uncertified Device). So why does one example result in a certified device and the other not?

Also, the documentation states: "The Matter samples in the nRF Connect SDK include temporary Device Attestation with data for testing purposes." It is not clear however, where this information for each example is kept. I do not see it in the example directories, so I assume it is being pulled in from elsewhere, but from where and how?

I am using the nRF7002DK for testing, not using WiFi, but Thread (effectively just using the nRF5340). NRF SDK version is v3.2.1 developing on Windows 11.

[AHaug]

Hi,

It's worth mentioning that both examples are uncertified as they are provided in the SDK, and the difference seems to me to be w.r.t how the HA ecosystem treats the devices, i.e

• For the Light Bulb sample, Home Assistant is willing to proceed despite the device using test / uncertified credentials (it may only show a soft warning or none at all).
• For the Temperature Sensor sample, Home Assistant shows an “Uncertified Device” warning and then refuses to complete commissioning with the test credentials provided in the sample

Also, the documentation states: "The Matter samples in the nRF Connect SDK include temporary Device Attestation with data for testing purposes." It is not clear however, where this information for each example is kept. I do not see it in the example directories, so I assume it is being pulled in from elsewhere, but from where and how?

Correct, all Matter samples use temporary/test Device Attestation data by default, i.e they “include temporary Device Attestation with data for testing purposes.” Ref. [DA overview]

The attestation data is part of the factory data set generated/merged at build time. When you enable factory data support (CONFIG_CHIP_FACTORY_DATA=y and SB_CONFIG_MATTER_FACTORY_DATA_GENERATE=y), the build system automatically creates a factory data blob and merges it into the final firmware. [Building with factory data]. For each sample, the resulting onboarding info (QR, payload, manual code) is written to factory_data.png and factory_data.txt in the build directory, and this payload “also includes test Device Attestation, with test Certification Declaration, Product ID, and Vendor ID.” [Light bulb testing; Temp sensor testing]

The default values for factory data parameters (including vendor/product IDs, etc.) are defined in the Matter nRF Connect Kconfig, not in each example directory. [Factory data Kconfig]. and the test certificates are located in credentials/development/attestation/ directory, which are generated using all default values.” [Default Kconfig values] 

Let me know if this answers your questions,

Kind regards,
Andreas

[rlk0]

After setting things up so I could commission into a border router with more extensive logging, I was able to see that the problem was signature validation during attestation. Since the certificates in the JSON factory data were fine, I realized this might happen if the private key left over from another example were left behind. There is an option to copy this into some kind of protected storage, which I think is set by default. So, I did a full erase of the device before reprogramming and that fixed the issue. I'm not sure under what circumstances private key copying does or does not take place; there are too many options all badly documented if they are documented at all, but it seems like it is good idea to fully erase the device when switching examples.