Device attestation with Matter PKI
WHITE PAPER
What is Matter?
There are an estimated 300 million smart homes in the world, and the number is expected to be 478 million in 2025.1 The average American smart home consumer has spent $ 1,172 on smart home electronics. The popularity and the trend of growth is decelerated by weaknesses of user experience: Until now, smart home devices tend to be usable only with only one controller app or smart home system. Smart homes with different device brands often require a multiple of controller applications; practically almost as many controller apps as devices.
This will change with ‘Matter’. Matter is an industry-aligning smart home communication standard that has set the goal that any Matter-enabled device can be controlled by any Matter-enabled smart home system. Practically, it will be possible to use all Matter devices with all Matter controller apps, such as mobile devices, wall panels, and voice assistants.
The Connectivity Standard Alliance (CSA) is an association that drives the Matter interoperability program (https://csa-iot.org/all-solutions/matter/) with standardization, open-source software and a compliance testing and certification scheme. The promise to the consumer is that Matter certified, compliant products will seamlessly and securely interoperate with each other.
“Smart home devices should be secure, reliable, and seamless to use. And with Matter, they are.” 2
Device vendors can also benefit from the program and concentrate on what they are good at: designing and producing the devices. With Matter, they can make use of the open-source communication firmware stack provided by CSA or of low-price Matter System-on-Chips (SoC), and avoid spending on developing the user interface and the controller application.
1 Top 35 Smart Home Facts and Statistics (2024) / Today´s Homeowner (todsayshomeowner.com)
2 Connectivity Standards Alliance. https://csa-iot.org/all-solutions/matter/
2
How Matter ensures compliance and prevents counterfeiting
To receive and use the Matter compliancy label, products must undergo interoperability tests and be certified by CSA. To protect the Matter ecosystem against non-certified and counterfeit products, Matter devices must carry a digital proof of compliance, called a Device Attestation Certificate (DAC). At the time of being commissioned into a smart home environment (called the Matter ‘fabric’), the smart home device must use the DAC to prove towards the commissioner component (a Matter controller) that it is a Matter compliant, certified device.
For the digital proof to be useful and provide strong protection against fraud and counterfeiting it must be:
• digitally verifiable with one-time validity (recording and replaying the proof should be rejected),
• unique for each device,
• unclonable,
• non-detachable from the device,
• impossible to counterfeit, e.g., by guessing or computing the response expected by the commissioner.
The attestation (i.e., verification) procedure is described in the Matter Specification. In essence, this is an active cryptographic authentication protocol between the device and the commissioner, which makes use of public key cryptography and digital signatures.
The device stores a unique and secret private key and uses it to digitally sign the attestation request of the commissioner. The corresponding public key is linked to the device identifier in the DAC, which is digitally signed by a certificate authority (CA), called a Product Attestation Intermediate (PAI). The digital signature of the PAI allows the commissioner to verify the authenticity of the DAC.
The commissioner’s attestation request includes a one-time random challenge number (a nonce), which the device’s response must also contain. In this way, the response has only one-time validity and is secure against a replay attack. The commissioner verifies the device’s digital signature with the help of the public key in the DAC. Then, it verifies the authenticity of the attached DAC, which is the proof of the device being certified and genuine (not counterfeited).
All PAI certificates are issued by one of the Matter root CAs, called Product Attestation Authorities (PAA). The certificates of the approved PAAs are listed and maintained on the Distributed Compliance Ledger (DLC, https://webui.dcl.csa-iot.org/pki), which can be accessed by commissioners via Internet, and which plays the role of the trust anchor in the Matter attestation PKI. The DCL is controlled by CSA. For the commissioner to accept a DAC, the DAC’s CA chain must contain a PAA certificate, which is present on the DCL.
3
How and when is the DAC provisioned to the device?
There are different ways to generate the attestation key pair, and to issue and provision the DAC to the device.
On-board key generation
The attestation key pair is, in optimal case, generated in the device using a proper random number generator and stored in a non-readable, tamper-proof memory. The private key should only be used for device attestation during commissioning.
Issuing the DAC requires the public part of the key pair to be transmitted to the certificate authority (the PAI). So, if the key pair is generated in the device, a two-way data transfer is needed between the device and the PAI: the device sending the public key to the PAI and receiving the DAC from it. One way to perform this data exchange is in a synchronous process during the manufacturing of the device, with the help of either an on-premises or a remote, Internet-based PAI CA.
Central key generation
Another solution can be that the key pair is generated externally on the production site or in the CA, and provisioned to the device together with the DAC. This method requires only one-way communication and enables the pre-production of key pairs and DACs in a central PAI, transfer to the manufacturing site asynchronously, i.e. before key and DAC are provisioned to the device. The downside of this method is that the secrecy of the private key must be maintained while transferring it from the generating site to the device, which adds to security risks and, respectively, system complexity.
Pre-provisioning in the supply chain
The keys and DAC may be provisioned at different stages in the supply chain:
a) The most natural way is if the device vendor or its Electronic Manufacturing Services (EMS) provisions the DAC into the devices.
b) Several semiconductor manufacturers offer System-on-Chip (SoC) solutions for Matter device vendors and can, on demand, even provision a DAC during the chip manufacturing process.
c) A secure element (a chip specially designed to protect secret key material) may be employed to store and use the attestation private key and potentially other secret key material. Some secure element vendors offer provisioning a DAC into their chips.
d) Some OEMs offer white-labelled firmware and hardware components for the actual Matter device vendors and may provision the DAC during their own manufacturing process.
In-the-field provisioning, just-in-time provisioning
A further option is, though not explicitly mentioned in the Matter Specification, the provisioning of the DAC when the device is already “in the field”. This method has the advantage to roll out DACs to heritage devices, provided that firmware upgrade over-the-air (FUOTA) is available. In principle, the DAC may also be provisioned just-in-time, i.e. right before it is commissioned into a Matter fabric. For any form of in-the-field provisioning, the device must be authenticated at the FUOTA or provisioning service with some strong credential, such as a certificate installed at the time of manufacturing.
6
Why a Certificate Policy is enforced?
For the high fidelity of the attestation procedure, the following major security objectives must be met:
a) The device private key must be high quality random data, which is never exposed by and is not extractable from the device by tampering, reverse engineering, hacking, cyberattack or similar malicious effort. To avoid special cryptographic attacks, the private key must be used only for digital signatures, preferably only for Matter device attestation. These objectives must be met by secure hardware, software and development techniques and are in the responsibility of the device (or component) manufacturer.
b) In case the private key is generated externally to the device, the key generation and the key transfer from the source to the device must maintain randomness, uniqueness and secrecy of the private key. Multiple use of the same private key in different devices must be prevented. The key pair and the DAC must be provisioned exactly to the certified device (i.e. to one single device) that is named in the DAC. These requirements are in shared responsibility of the key generating instance (e.g., the PAI) and the device (or component) manufacturer.
c) It must not be possible to create Device Attestation Certificates for non-certified or non-authorized devices. The proper VID and PID must be used in the DACs, i.e., the PAI must issue DACs only with the authorized VID and PID. Most importantly, the PAI private key must be protected from being stolen, replicated and/or used to sign unauthorized DAC requests. These objectives must be met by the PAI operator.
d) Furthermore, it must not be possible to create a “pirate” PAI CA under an authorized PAA. For that, the PAA private key must be protected from being stolen, replicated and/or used to issue PAI certificates to unauthorized entities. These objectives must be met by the PAA operator.
The above security objectives of the Matter PKI can only be met by a mixture of physical and digital security control, organizational rules, personnel controls, and general computer and network security controls in the entire Public Key Infrastructure and provisioning infrastructure.
The Matter Certificate Policy
To be able to systematically design, implement and assess the security of the Matter PKI and the provisioning infrastructure, the relevant high-level requirements are collected in the Matter Certificate Policy (CP). The PKI operational practices and security measures must cover following aspects:
• Physical security: multi-layer physical protection with physical barriers (fences, walls, doors), access controls and audit log; intrusion, fire, and water protection; surveillance; multi-person access to critical equipment and data;
• Logical security controls: protection of the CA private key in compliant Hardware Security Modules (HSM), protection of HSM activation data; role-based access controls; role segregation and multi-person access controls on all critical systems, applications and actions; equipment and network security; proper user identification, authorization and credential management processes; strong credential policy;
7
• PKI lifecycle processes: initial issuing, rekeying (optional), and revocation service. Revocation lists (CRLs) of PAAs and PAIs must be published in an online repository, which must be accessible via the Internet;
• PKI process security: authorization and authentication for, and audit logging of all CA administration and certification activities; notifications to requestors; capability of mitigating vulnerabilities and recovering from compromise;
• Availability, backup and disaster recovery: operational availability and continuity measures;
• Retention of audit data, regular audit reviews: regular reviews and archiving of relevant audit and supplementary data;
• Personnel controls: background check of trusted personnel, ensuring awareness and competency of trusted personnel, repetitive trainings;
• Compliant certificates: All certificates must fulfil the specified format and content;
Following and implementing new CP versions.
We can conclude that compliant PKI operation is not a simple task, needs secure facilities, secure IT infrastructure and organization, secure procedures, an online repository, and special expertise. Especially the requirements on HSMs, multi-person and multi-role physical and logical controls add to operational costs.
CPS and compliance audit
As briefly outlined above, the secure operation of the Matter PKI is, on the one hand, mandated by the Matter CP, on the other hand, quite a challenging task. To keep the fidelity (i.e., the assurance level) of DACs at a generally high level across the Matter ecosystem, CSA approves and continuously monitors the practices of all PKI entities: of PAAs and of PAIs. How? With an approval process:
> First, each certificate authority (PAI or PAA) operator must document its security practices in a Certificate Practice Statement. This document describes how the CA’s practices fulfil the requirements of the Matter CP.
> CSA requires an audit of the PAA’s and/or PAI’s practices. Today, the audit may be done by the CA operator in form of a self-assessment, and the audit report as well as the CPS submitted to CSA for review. CSA (or an authorized auditor) reviews the CPS and the audit report, and assesses, if the CA operator’s practices ensure the sufficiently high assurance of the DACs, i.e. properly mitigate the risk of misuse and counterfeiting of DACs. As of today, CAs must pay a fee for CSA’s approval efforts.
> In future, the approval procedure may include an audit of the CA’s operation by an accredited, external auditor. A uniform auditing scheme is planned to be developed by CSA.
> Compliance with the Matter CP is not a one-time project but must be continuously maintained by the CA operators. They must update their practices if new released versions of the CP require so.
We can conclude that PAA/PAI approval is a rather costly, time-consuming task, and requires expertise.
8
Requirements on the devices and on the manufacturer’s provisioning infrastructure As stated earlier, the overall security of the PKI does not only depend on the CA’s secure operation, but on the devices and on the certificate provisioning systems too: The devices must securely store and operate the attestation private key and the overall provisioning infrastructure must be secure, so that the earlier asserted Security Objectives a) and b) and the corresponding stipulations of the Matter CP can be met.
How the private key is stored and operated in the device – e.g., in a special hardware secure element or in software-protected flash memory – is not prescribed by CSA but the device vendor can decide on a risk-appropriate protection method. For device vendors and component manufacturers, no approval procedure is defined to verify compliance with these stipulations. Nevertheless, vendors and manufacturers must guarantee their fulfillment.
If the vendor or manufacturer operates its own PAA and PAI, this guarantee is implicitly given when applying for approval of their PAA/PAI CPS.
If a service provider operates the PAA and/or PAI, the service provider must let the PAI owner vendor (or manufacturer) sign a Requestor Agreement Document (RAD). The RAD lists the CP requirements that apply to device vendors and manufacturers. With signing the RAD, the vendor or manufacturer guarantees the fulfillment of the requirements by contractual obligation towards the PKI service provider. Furthermore, intellectual property rights, liabilities and indemnities are defined in the RAD.
The device vendors’ options to obtain the DACs
Matter devices must present a valid Device Attestation Certificate (DAC) to a commissioner component, when added to a smart home environment, called Matter ‘fabric’. Device vendors have several options how their devices can obtain a DAC from an approved authority, called PAI:
1. The vendor can purchase and build the device based on a System-on-Chip (SoC) component, which comes with a DAC. Several chip manufacturers operate a non-vendor-scoped Matter PKI.
2. The vendor can also buy Matter certified, white-label products from an OEM and rebrand it. The white-label product may be provisioned with DACs holding the ultimate vendor’s VID and PID.
3. The vendor or its OEM partner may build its own vendor-scoped PKI including a PAA and PAI. As described in this white paper, Matter CP-compliant PKI operation requires access- controlled facilities, proper organization and personnel, a whole series of logical and procedural controls, regular audit log reviews, etc., and a whole lot of PKI expertise. The PKI operator must pass a CSA approval process.
4. The vendor may choose to outsource its operation to a PKI service provider, who undergoes the CSA approval process, and is authorized to host and manage a vendor’s PAI instance on behalf of the vendor. The PAI service provider typically also operates a non-vendor-scoped PAA. The advantages for the device vendor are manifold, as displayed on the next page.
9
• Specially secured facilities, IT and equipment (especially costly HSM) are not needed.
• An Internet-exposed repository needs not be operated by the vendor.
• No personnel need to be trained for and bound by PKI operation.
• No in-house PKI knowledge needs to be built up and maintained.
• No lengthy and costly PKI approval process.
• The vendor can focus on its core business.
• Predictable, constant, and moderate PKI operational costs; a PKI service provider can share most of its operational costs among multiple customers.
Nexus’ Matter PKI Service
Nexus operates a CSA-approved non-VID-scoped Matter PAA authority. The Nexus Matter PAA certificate is listed on the Distributed Compliance Ledger (DCL) since January 2024. Nexus also hosts and manages PAI certificate authorities as a Service for Matter device vendors. Product interoperability tests can be done using DACs from a pre-production PKI service with a Nexus pre-production PAA listed on the Matter Testnet Ledger (https://testnet.iotledger.io/pki)
Chip manufacturers, device OEMs and Matter product vendors are encouraged to use the Nexus Matter PKI Service. The service provides high security, Matter compliant PKI at predictable and moderate costs. Nexus has been operating compliant PKI services for dozens of IoT customers since many years and fulfil high security standards, like eIDAS, LoA3, PCIDSS, TiSAX, etc. Based on Nexus’ own Common Criteria EAL4+ certified Certificate Authority software and nearly 30 years of PKI experience, Nexus can also help customers to build their Matter compliant on-premises PKI.
At Nexus, part of IN Groupe, we believe in securing society by enabling trusted identities. As a leading European company specializing in innovative identity management, we are committed to shaping a safer society by providing trusted identities for people and things.
Our comprehensive portfolio of identity and security solutions enables organizations of all sizes and industries worldwide to issue, manage, and utilize trusted identities for their workforce, workplace, and the Internet of Things (IoT).
With close to 300 dedicated employees across Europe and Asia, and a vast global partner network, we are growing to become a leading global player and contributor to a safer society.
Please visit nexusgroup.com for more information.
10
” Our commitment to excellence and innovation drives us to build a secure tomorrow with trusted identities ” www.nexusgroup.com
