connectedhomeip
connectedhomeip copied to clipboard
Unique ID for Rotating Device ID should be programmed per device during factory provisioning
Problem
In https://github.com/project-chip/connectedhomeip/pull/15031 the initial change for making Rotating Device ID generation algorithm compatible with the spec was done (replacing serial number with unique ID). This change, for the purpose of rotating device id generation, added unique ID config that can be overwritten by the vendor, however it should not be a config at all as according to spec:
The unique identifier SHALL consist of a randomly-generated 128-bit or longer octet string which SHALL be programmed during factory provisioning or delivered to the device by the vendor using secure means after a software update.
Proposed Solution
Unique ID for Rotating Device ID should be part of factory data that are created per-device. Then the value should be read from flash and passed to the RDID generation algorithm. After that CHIP_DEVICE_CONFIG_ROTATING_DEVICE_ID_UNIQUE_ID
should be removed.
Spec Review: We do not believe this is a spec compliance issue, removing spec.
Spec Review: @kkasperczyk-no can you please confirm this is still an issue and/or is it resolved with the linked PR?
With my linked PR (#15031) it was not resolved, but I think the unique ID for Rotating Device ID was moved from the Configuration Manager to the DeviceInstanceInfoProvider interface in :https://github.com/project-chip/connectedhomeip/pull/18767. So I believe we could close the issue after this PR merge. @ArekBalysNordic could you confirm?
Ok, I see what is the status, it is not done in the final shape yet.
I'm not sure how to handle this issue. In general there are many values that are factory data and it should be flashed and read from the memory, while currently we are using some default test values defined in the C header files. The unique ID is just one example of such value among the others like serial number, manufacturing date, hardware version etc.
I created this issue just to remember that current implementation is not in the final shape and we cannot use this default values in the release version. Nevertheless I believe we should handle it in one generic issue regarding all factory data that will be resolved only when all platforms will switch from using default configs to the real factory data read from flash.
Issue Scrub: @kkasperczyk-no is this still an issue. If so, is this something you can look at?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
This stale issue has been automatically closed. Thank you for your contributions.