NOC certificate questions (CON-416)

[jonsmirl]

1. How many entries can the NOC certificate chain have? Where is the root of that chain?

Should the chain look like this?
RootCA -- company owned (cloud)
IAC -- One per house (cloud)
IAC -- One per controller (stored in controller, shares CASE Authenticated Tag)
NOC - final certificates in the nodes

or like this?
RootCA -- One per house (cloud)
IAC -- One per controller (stored in controller, shares CASE Authenticated Tag)
NOC - final certificates in the nodes

or is the root of this chain a CSA issued certificate?

This model allows people to delete the controller app off from their phones, and then when they reinstall it a new IAC will be generated from the cloud-base house IAC.

2. Matter NOC certificates need MatterRCACId, MatterFabricId, MatterICACId values encoded into the Issuer and Subject fields. Where do these IDs come from?

3. So when instantiating a controller it needs parameters:
   setRootCertificate(ByteArray) -- how do you it build this ByteArray from a CRT file?
   setIntermediateCertificate(ByteArray)
   setFabricId(id) - this ID is also in the certificate, where does it come from?
   setIpk() -- it needs this, what is it, and how do I set it?

4. What do you do with a CASE Authenticated Tag? I think it is for doing this, am I right? I want to have multiple controllers on the same fabric. When a node is commissioned, the nodeId of the commissioner gets written into the ACL. So now if I add a second commissioner, how do I get its nodeID into all of the nodes? I think the answer to this is to use a CASE Authenticated Tag. The first commissioner would update the nodes ACL entry to use the CASE Authenticated Tag instead of a normal nodeID. Then both commissioners would have the same CASE Authenticated Tag. How do you use this feature since the CASE Authenticated Tag has to be inside the NOC certificate? Page 327 of the spec.

[wqx6]

1. Each fabric has one RCAC, so the chain can look like this:

• RCAC&RootKey -- One per house(cloud)

• RCAC&ICAC(Optional)&NOC&NOCKey -- Devices(both the controller and end devices, can share CATs)

  Then the controller and end devices have the same Root cert so they can establish CASE Session.

2. Devices send CSR to the issuer (clould), and the issuer will use the RCAC and its key to issue ICAC and NOC, and add these IDs to the certs when issuing them.
3. The RootCert is self-issued in cloud and sent to device in ByteArray format after the could has issued the ICAC and NOC; The ICAC is also sent to device in ByteArray format; The Fabric ID is generated randomly in clould before the RootCert is self-issued; IPK is in SPEC 4.13.2.6.1
4. Yes, you are right. I have added a method to send the NOC with CATs when pairing devices in PR, you can follow the test steps in that PR.

[jonsmirl]

Is this sequence accurate? Can you help fill in exact commands?
How to add in IPK, is it required?

1. Generate MatterRCACId, MatterFabricId, a CASE-Authenticated-Tag (how?), add to root cert

2. Generate self-signed root key in cloud for house
   chip-cert gen-cert --type r --subject-chip-id CACACACA00000001 --valid-from "2020-10-15 14:23:43" --lifetime 7305 --out-key Chip-Root-Key.txt --out Chip-Root-Cert.txt --out-format chip-hex
   // What is exact chip-cert command?

3. Controller asks cloud to send it RootCert

4. Controller gets MatterRCACId, MatterFabricId, CASE-Authenticated-Tag out of RootCert

5. Generate intermediate key on controller,
   openssl ecparam -genkey -name prime256v1 -noout -out $1/private/intermediate.key
   // What is CHIP API to do this?

6. Generate CSR on controller, Add MatterRCACId, MatterFabricId, MatterICACId, CASE-Authenticated-Tag
   openssl req -config $1/openssl.conf -new -key $1/private/intermediate.key -out $1/certs/intermediate.csr -subj '/CN='$2''
   // What is CHIP API to do this?

7. Send CSR off to cloud

8. Use Root key in cloud to sign CSR
   openssl ca -batch -config root-ca/openssl.conf -keyfile root-ca/private/ca.key -cert root-ca/certs/ca.crt -extensions v3_req -notext -days 900000 -md sha256 -in $1/certs/intermediate.csr -out $1/certs/intermediate.crt
   // What is exact chip-cert command to sign CSR?

9. Send intermediate cert back to controller

Use RootCA and IntermediateCA to start controller.

[wqx6]

I think you are not so clear about the NOC chain generation. There is a example for an NOC Chain generation.

1. A user creates a house in his phone app below his account, the cloud will generate a self-signed RCAC&key and ICAC&key(issued by the RCAC) , save them and bind them to the house created by the user. The API is IssueX509Cert. The DNs in RCAC are RCACId and FabricId. Both of them are generated randomly, saved in cloud and bound to the house. The CATs can also be generated randomly, saved and bound to the house.

2. The user adds a controller(commissioner) to the house, the controller will generate a NOC keypair and use the public key in the key pairing to generate a CSR(APIs are in emberAfOperationalCredentialsClusterCSRRequestCallback), send the CSR Elements to the could. after obtaining the CSR Elements, the cloud will decode it(https://github.com/project-chip/connectedhomeip/blob/master/src/controller/ExampleOperationalCredentialsIssuer.cpp#L343-L362) and use the public key to issue a NOC for the controller IssueX509Cert. The DNs in NOC include NodeId, FabricId and NOCCATs, The nodeId should be sent by the controller, and the other two are generated before.

3. After issuing the NOC, the cloud will send the RCAC cert, ICAC cert and NOC back to the controller. and the controller will save what it receives.

4. When the user tries to pair a matter end device, After PASE Session establishment and device attestation verification, the device will generate CSR and send it to the commissioner. The commissioner will forward the CSR to the cloud and the could will generate the NOC, send it back to the commissioner, and then the commissioner will send this NOC to the device with the RCAC and ICAC and set the device's ACL with the CATs.

To ensure the security, the RCAC private key and ICAC private key are saved in cloud and will never be sent to the controller or end devices. Each device will have a NOC with the NOC private key, also the NOC private key will never leave the device. So the NOC generation should be in cloud.

The cert chain: RCAC(self-signed) ->ICAC(signed by RCAC private key) ->NOC(signed by ICAC private key)

Also the ICAC is optional for NOC chain, so if there is no ICAC, the NOC is signed by the RCAC private key. And in this situation, the cloud will save only the RCAC and its priv-key with the RCACId, fabricId and CATs.

[jonsmirl]

1. Why can't the ICAC/key be generated and stored on the controller? Now the controller can commission devices without needing the cloud.

2. Can multiple controllers have different ICAC (with common Root) and be on the same fabric?

[wqx6]

Why can't the ICAC/key be generated and stored on the controller?

ICAC's key pair can be generated and store on the controller and the cert generation should be in cloud, because ICAC is signed by the RCAC private key and the private key should never leave the cloud.

Now the controller can commission devices without needing the cloud.

Yes, because the test controller will store the RCAC&private-key, but it cannot control the devices once it is factory-reset, so it is only for test. Storing the RCAC&key in the cloud can make the controller be able to control the devices even if it is factory-reset because it can re-obtain the ICAC&NOC signed by the original RCAC again. You can backup the RCAC&key generated by the controller in the cloud, but it is not so safe because the RCAC private key might be leaked during the backup.

Can multiple controllers have different ICAC (with common Root) and be on the same fabric?

Yes, they can.

[dhrishi]

@jonsmirl Please close this issue if your questions are answered

[Dejavu610]

Hello，@jonsmirl ，Does the private keys of ICAC and RCAC must be stored in the cloud? Can ICAC be stored in an APP or matter controller（like hub）? It semms like the RCAC and ICAC certificate perpetually valid unless recreate the house. How to handle if the private key leaked? It seems like there is no RCAC certificate revocation mechanism in matter.

[jonsmirl]

If you store the ICAC in the phone app you can commission devices without needing to access the cloud. This is a way to support multiple users. For each user a different ICAC is generated which they store locally in their phone.

If the RCAC private key is leaked, you are doomed and have the reset all of the devices. There is no way to revoke it. That makes sense, because if you revoked the RCAC then you'd still have to reset all of the devices to get the old RCAC out of them. You could also remove all of the entries for the old fabric and then make a new one using a new RCAC.

If the ICAC private key is leaked, you don't revoke it. Instead you create new ICAC for everyone still trusted with a different CAT tag. Now upgrade all of the device's ACL to use the new CAT tag. This will render the leaked ICAC useless since they won't be able to generate a new ICAC with the new CAT tag in it. You can leave both CATs in the devices durring a window while you are upgrading the controllers. This is how you get rid of a user you gave an ICAC to.

Also note, giving another user an ICAC lets them commission new devices, alter ACLs, etc. You don't have to give other users an ICAC instead you can just give them normal certificates. With a normal certificate they can still do anything allowed by the ACL, they just aren't admins. This is a solution to something like guests in an AirBnB. But why bother? Instead use Google/Apple/Amazon to handle the guests.

There is no solution for losing an RCAC or ICAC private key which does not involve touching all of the devices. CRL (certificate revocation lists) only work because when you verify a certificate you get the CRL from the cloud and Matter devices don't access the cloud on their own. CRLs don't really gain you anything that you can't get from ACLs and changing the CAT tag. If you revoked the RCAC the whole fabric would stop working which is equivalent to remove it or reseting the device.

One thing for sure not to do -- don't store the RCAC in a phone. Because if the person deletes and reinstalls the app, they will lose the RCAC. And people delete apps all of the time when their phones run out of space.

[Dejavu610]

If you store the ICAC in the phone app you can commission devices without needing to access the cloud. This is a way to support multiple users. For each user a different ICAC is generated which they store locally in their phone.

If the RCAC private key is leaked, you are doomed and have the reset all of the devices. There is no way to revoke it. That makes sense, because if you revoked the RCAC then you'd still have to reset all of the devices to get the old RCAC out of them. You could also remove all of the entries for the old fabric and then make a new one using a new RCAC.

If the ICAC private key is leaked, you don't revoke it. Instead you create new ICAC for everyone still trusted with a different CAT tag. Now upgrade all of the device's ACL to use the new CAT tag. This will render the leaked ICAC useless since they won't be able to generate a new ICAC with the new CAT tag in it. You can leave both CATs in the devices durring a window while you are upgrading the controllers. This is how you get rid of a user you gave an ICAC to.

Also note, giving another user an ICAC lets them commission new devices, alter ACLs, etc. You don't have to give other users an ICAC instead you can just give them normal certificates. With a normal certificate they can still do anything allowed by the ACL, they just aren't admins. This is a solution to something like guests in an AirBnB. But why bother? Instead use Google/Apple/Amazon to handle the guests.

There is no solution for losing an RCAC or ICAC private key which does not involve touching all of the devices. CRL (certificate revocation lists) only work because when you verify a certificate you get the CRL from the cloud and Matter devices don't access the cloud on their own. CRLs don't really gain you anything that you can't get from ACLs and changing the CAT tag. If you revoked the RCAC the whole fabric would stop working which is equivalent to remove it or reseting the device.

One thing for sure not to do -- don't store the RCAC in a phone. Because if the person deletes and reinstalls the app, they will lose the RCAC. And people delete apps all of the time when their phones run out of space.

Thank you. You're right, if the ICAC private key is stored in the mobile app, you can commission devices without needing to access the cloud. However, if the private key is stored in the app, and I lose my phone, anyone who knows my Wi-Fi password could potentially control my devices. In that case, I would have to reset all the devices, which seems quite troublesome when there are a lot of devices involved.

[jonsmirl]

Thank you. You're right, if the ICAC private key is stored in the mobile app, you can commission devices without needing to access the cloud. However, if the private key is stored in the app, and I lose my phone, anyone who knows my Wi-Fi password could potentially control my devices. In that case, I would have to reset all the devices, which seems quite troublesome when there are a lot of devices involved.

When you make keypair on a phone using the OS API the private key is stored in the ARM trust zone which is inaccessible. Also, if you lose your phone your phone will have the normal IOS/Android locks on it which are quite difficult to defeat. In general only law enforcement can gain access to a lost phone. Note that if you don't store an ICAC in the phone you have to store a normal certificate which can still access all of the devices, it just can't make new ones.

I see little downside to storing an ICAC in the phone. If you are really worried when you lose the phone you can use the process of changing the CAT tag to render the phone useless.

[Dejavu610]

谢谢。你说得对，如果 ICAC 私钥存储在移动应用程序中，你可以无需访问云就可以调试设备。但是，如果私钥存储在应用程序中，而我丢失了手机，那么任何知道我的 Wi-Fi 密码的人都可能控制我的设备。在这种情况下，我必须重置所有设备，当涉及很多设备时，这似乎相当麻烦。

当您使用 OS API 在手机上创建密钥对时，私钥存储在无法访问的 ARM 信任区域中。此外，如果您丢失了手机，您的手机上将有正常的 IOS/Android 锁，这些锁很难破解。一般来说，只有执法人员才能访问丢失的手机。请注意，如果您没有在手机中存储 ICAC，则必须存储仍然可以访问所有设备的普通证书，只是无法创建新设备。

我认为将 ICAC 存储在手机中没有什么坏处。如果你真的担心丢失手机，你可以使用更改 CAT 标签的过程使手机变得无用。

Got it. Thanks very much.