Distributed Compliance Ledger (DCL) in Matter
[Copy link]
Source: https://blog.csdn.net/espressif/article/details/123984182
One of the advantages of Matter is that Matter device manufacturers (suppliers) do not need to develop their own mobile apps or cloud services. Their Matter devices can join any ecosystem that supports Matter and connect seamlessly with other Matter devices in the ecosystem.
How is this possible? How do Matter device manufacturers securely publish device information and allow the Matter ecosystem to access it? In this post, we will discuss the Distributed Compliance Ledger (DCL) in Matter.
-
What is the Distributed Compliance Ledger (DCL)?
Matter DCL is a secure, encrypted distributed storage network based on blockchain technology that allows the Connection Standards Alliance (CSA) and authorized suppliers to publish their Matter device information and allows the Matter ecosystem to query relevant information through the DCL client.
-
What information is stored in the DCL?
Matter device information is stored in 5 databases:
1. Vendor Schema: includes basic information about vendors, such as the company's legal name, the brand name associated with the VendorID, the vendor's homepage URL, etc.
2. Device Information Database (DeviceModel Schema): includes basic information about the device, such as product name, product ID, part number, commissoning information, and other information that is common to all software versions.
3. Device Software Version Database (DeviceSoftwareVersionModel Schema): includes detailed information about the software version, such as release notes URL, firmware digests (FirmwareDigests), OTA software image URL, etc.
Note: Only URLs are stored in the DCL, not the images themselves. Therefore, vendors need to store OTA software images elsewhere and publish only the download URLs of the images in the DCL.
4. Compliance Test Result Schema: Contains device compliance and test result data.
5. Product Authentication Root Certificate Database (PAA Schema): Contains a list of approved product authentication root certificates (Please read " Matter's Security Model " for more information.)
-
How will the Matter ecosystem use this information?
All of the above information will be stored in DCL. After that, the Matter ecosystem can complete the following operations by accessing DCL:
1. Check the authentication status of the device
2. Verify the Device Authentication Certificate (DAC) by tracing back to the root certificate PAA
3. Get commissioning instructions, manual links, product information, etc.
4. Check OTA status and upgrade your device to the latest firmware version
DCL is a network of independent servers owned and hosted by CSA Alliance and its members. Each server holds a copy of the database containing Matter device information, and the servers communicate with each other via encrypted security protocols.
Does each vendor need to install its own DCL server? The answer is no.
The CSA Alliance provides a public DCL server to support suppliers to access DCL information using DCL clients. CSA can also configure "write permissions" for members, allowing them to publish their own Matter device information to DCL.
A vendor may also install its own dedicated DCL server. Such a dedicated DCL server is usually only used by the vendor's own clients, but may optionally allow access to other vendors.
-
DCL has limited "write permissions"
1. Vendors can add new device models under their VendorID (either through CSA's DCL server or their own dedicated DCL server). Vendors need to associate their VendorID with a public key during account creation in order to have "write access" to the DCL.
2. Suppliers can update some information of existing device models (such as product name, product description, firmware and hardware information, etc.), and can only update relevant information of devices associated with their own supplier accounts.
3. The CSA Certification Center can write or revoke the certification status of a device in the DCL.
-
DCL's "read permissions" are open to everyone
Everyone can read from DCL:
1. Device model information, including firmware and hardware versions
2. Device authentication status
3. Product Certification Root Certificate List
Next, let's take a look at the typical workflow of DCL through a simple example. First, we assume that there are the following roles:
1. Connectivity Standards Alliance (CSA)
3. Bulb B (provided by supplier A)
4. Testing organization T
The typical workflow is as follows:
1. Supplier A is a member of CSA, has registered its public key and obtained the "write permission" of DCL. Supplier A develops and produces a Matter light bulb B, and uses CSA's DCL server to add the information of light bulb B to DCL.
2. Supplier A sends a batch of bulbs B to testing agency T, which performs Matter certification tests on B and sends the test results to CSA. CSA checks the test results received and adds the device certification information of bulb B to the DCL if the test passes.
3. Consumer C buys a light bulb B from the market and uses the mobile phone APP of the Matter-supported ecosystem G to commission light bulb B, so that light bulb B joins ecosystem G and works with other devices in G. Ecosystem G needs to obtain relevant information about light bulb B from DCL to complete the commissioning process.
4. After this, supplier A develops a new feature for light bulb B. At this point, supplier A releases a software version in DCL that includes the new feature. A device in ecosystem G provides the Matter OTA upgrade function, which can assist light bulb B in completing the OTA process.
5. Later, consumer C is interested in some services provided by another ecosystem H that supports Matter, so he adds light bulb B to ecosystem H in a similar way. At this point, light bulb B can work seamlessly in ecosystems G and H at the same time.
In this way, consumer C can seamlessly enjoy all the services provided by these two ecosystems.
|