Create CAs for Matter Operational PKI

ENTERPRISE

The Matter IoT standard specifies Node Operational credentials as a collection of credentials to enable a Node to identify itself within a Matter network, known as a "Fabric". The Node Operational credentials are installed during the commissioning process.

The Node Operational credentials are distinct from the Device Attestation creden­tials created in the Vendor PKI.

Node Operational Certificates (NOCs), defined in section 6.4.5 of the Matter Core Specification v1.2, may use different encodings than X.509 certificates, though they can be converted between formats. EJBCA supports the issuance of X.509 certificates within the NOC PKI, and issuance has been successfully tested using the CSA official chiptool and core SDK with EJBCA across the entire PKI.

There are three types of certificates involved in the node operational PKI:

• Node Operational Certificate (NOC): Each Matter device is issued an Operational Node ID and a Node Operational Certificate (NOC) for that Operational Node ID. The NOC enables a Node to identify itself within a Fabric. The NOC SHALL be issued by either a Root CA trusted within the Fabric or by an Intermediate Cer­tificate Authority (ICA) whose ICA certificate is directly issued by such a Root CA. The NOC is bound to the Node Operational Key Pair through the Node Operational Credential Signing Request (NOCSR).

• Intermediate CA (ICA) Certificate: In the case where an intermediate CA (ICA) issues the NOC, the ICA certificate is used to attest to the validity of the NOC.

• Trusted Root CA Certificates: Each Node has one or more trusted Root CA certificates in its Node Operational credentials that it uses to verify ICA certificates and Node Operational Certificates presented by other Nodes, treating them as trust anchors as described in RFC 5280.

Matter Specific Fields

Matter certificates issued by the CA are X.509 certificates, conformant with RFC5280. The Matter Core Specification lists the fields that must be included, those that must not be included, and those that are optional.

For Matter Node Operational certificates six specific DN attributes are defined:

The attributes are all encoded as UTF8Strings in certificates. The order of the attributes in a subject- or issuer DN can be issuer-specific and is not enforced by Matter-specifications.

Section "6.5.6.3. Matter DN Encoding Rules" defines which Matter specific DN components are in the different certificates.

For a Trusted Root CA Certificate:

• The subject DN SHALL NOT encode any matter-node-id attribute.

• The subject DN MAY encode at most one matter-fabric-id attribute.

• The subject DN SHALL NOT encode any matter-icac-id attribute.

• The subject DN SHALL encode exactly one matter-rcac-id attribute.

• The subject DN SHALL NOT encode any matter-noc-cat attribute.

For an ICA Certificate:

• The subject DN SHALL NOT encode any matter-node-id attribute.

• The subject DN MAY encode at most one matter-fabric-id attribute.

• The subject DN SHALL encode exactly one matter-icac-id attribute.

• The subject DN SHALL NOT encode any matter-rcac-id attribute.

• The subject DN SHALL NOT encode any matter-noc-cat attribute.

For a Matter Node Operational Certificate (NOC):

• The subject DN SHALL encode exactly one matter-node-id attribute.

• The subject DN SHALL encode exactly one matter-fabric-id attribute.

• The subject DN SHALL NOT encode any matter-icac-id attribute.

• The subject DN SHALL NOT encode any matter-rcac-id attribute.

• The subject DN MAY encode at most three matter-noc-cat attributes.

EJBCA supports these as regular DN attributes and to enforce policy and compliance EJBCA profiles can be configured according to these rules, i.e. allowing 0...3 instances of the DN attribute.

Matter doesn’t specify how firmware images are signed and implementation of firmware image signing is manufacturer-specific, but firmware signing certificates shall include the firmware-signing-id attribute.

Examples

DN

The Matter core specification section 6.5.6.4 provided examples for DNs.

Node examples:

subject = [[
matter-node-id = 0x0102030405060708U,
matter-fabric-id = 0xFAB000000000001DU
]] 

subject = [[
common-name = "NOC Example",
matter-node-id = 0x0102030405060708U,
matter-fabric-id = 0xFAB000000000001DU,
matter-noc-cat = 0xABCD0002U
]]

subject = [[
matter-noc-cat = 0xABCD0004U,
matter-node-id = 0x0102030405060708U,
matter-noc-cat = 0xABCE0018U,
matter-fabric-id = 0xFAB000000000001DU,
matter-noc-cat = 0xABCF0002U
]]

RCAC example:

subject = [[
matter-rcac-id = 0xCA0000000000001DU
]]

subject = [[
matter-rcac-id = 0xCA0000000000001DU,
matter-fabric-id = 0xFAB000000000001DU,
common-name = "ROOT CA HOME 3"
]]

ICAC example:

subject = [[
matter-icac-id = 0xCACACACA00000003U
]]

The specification limits the number of fields to five with the following requirement:

“All implementations SHALL reject Matter certificates with more than 5 RDNs in a single DN.”

EJBCA Enrollment

This is an example of using the REST API to create an end entity, representing a NUC, and then requesting a certificate for this NUC using a simple CSR. The request DN in the CSR doesn’t really matter.

The REST request to the end point v1/endentity/:

{
  "username": "NUC1",
  "password": "random_onetime_enrollment_code_123",
  "subject_dn": "NODEID=FAB000000000001D,FABRICID=DEDEDEDE00010001",
  "ca_name": "MatterICAC",
  "certificate_profile_name": "NOC",
  "end_entity_profile_name": "NOC",
  "token": "USERGENERATED"
}

The REST request to the end point v1/certificate/certificateRequest:

{
  "certificate_request": "MIHSMHkCAQAwFzEVMBMGA1UEAwwMREVERURFREUwMDAxMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEL3CswLxmlbcu2yLviLavwZtqwhGnOfA+f9KzYL8c438TbM3jHppzOCRnmMcgWQisdMnzgx+wOMaJtddXvRYE/KAAMAoGCCqGSM49BAMCA0kAMEYCIQDbBKqT1FdkjDlza/2N5XDN16xdI+/OX7rOD657KBek1wIhAJ+ydcAvuz1ETIVqoemMVdrDkyC39Iw/hIFyYCK2WjEU",
  "username": "NUC",
  "password": "random_onetime_enrollment_code_123",
  "response_format": "DER"
}

Also, CMP can be used, as in this simple example. Note that the subjectDN in the CSR does not matter as the node has been pre-registered as an end entity with the correct DN attributes.

openssl ecparam -name prime256v1 -genkey -noout -out mykey.pem
openssl cmp -cmd ir -server https://ejbca-hostname:8442 -path /ejbca/publicweb/cmp/testNOC -subject "/CN=1234-HTTPS/UID=randomUID" -newkey ./mykey.pem -certout ./https.cert -srvcert ./icac.pem -verbosity 8 -tls_used -chainout ./chain.pem -ref 1234-HTTPS -secret pass:random_ontime_code