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]

This partially answers the question. But it does not address the issue of why one example produces an Uncertified Device message while the other does not. I believe the uncertified message is actually coming from the commissioner, an Android phone not Home Assistant, since the same behavior occurs if I try to add the examples to Google Home.

[AHaug]

Yeah, to expand on my previous comment: I didn't just mean HA, but the ecosystem in general, i.e you might also see the same with an Apple/Amazon ecosystem as well (other brands are available)

Could you attach/upload the commissioning log, device log and/or chip-tool log when you perform the commissioning?

Kind regards,
Andreas

[rlk0]

I have attached the output from the Temperature Sensor example device during commissioning. On the phone, the Uncertified message occurs about 73401, Device Connected around 119101, an add device (to HA) prompt message occurs around 157489 and the fail occurs at 187962.

/cfs-file/__key/communityserver-discussions-components-files/4/TempSensor.zip

[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.