-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NOC certificate questions #118
Comments
@jonsmirl Hello, I have the same need, do you have any progress now? |
you need to implement these callbacks
|
@jonsmirl First of all, thank you for your answer. There are some parameters that I don’t understand their meaning, such as: val operationalKeyConfig = OperationalKeyConfig(myKeypairDelegate(), trustedRootCertificate,
trustedIntermediateCertificate, nodeOperationalCertificate, ipkEpochKey
) In this code, in addition to passing in KeypairDelegate, you also need to pass in trustedRootCertificate, trustedIntermediateCertificate, nodeOperationalCertificate, and ipkEpochKey. Can I generate these certificates myself using openssl? What is ipkEpochKey? Finally, based on the keywords you mentioned, I found a related PR for this feature that may help us better understand it. |
Google really needs to supply some sample code for this. This sample code does not need to be cloud based, in comments it can simply say -- do this in the cloud. Every Matter controller app has to implement this. You can't use the built-in demo version, it leaves the private key sitting in the config file. There is absolutely zero documentation for doing this. I figured it out by reading the code, making guesses about what to do, until I finally got it working. You make the root key and cert in the cloud. Code on the phone makes the NOC key and CSR. Those get sent to the cloud to be signed. The NOC private key is kept in phone's trust zone. You can use null for trustedIntermediateCertificate. ipkEpochKey is a random string which I think can be null too. Then you implement KeypairDelegate to utilize that Root key off in the cloud. ecdsaSignMessage() has to ship the message off to the cloud, sign it, and return the response. The trustedIntermediateCertificate can be used to avoid needing to access the cloud for each newly commissioned device. Also note, each house needs a different root key. Don't use one root key for everything! Those keys should be made using Google Cloud Key Management and stored with protection level SOFTWARE ($0.06/mth). The hardware level protection is unaffordable for this use case. Don't just stick them in a database, because if you lose that database you've given access to every customer. The root key is per house, not per user. So if two people are in the same house you need to invite the second person into your home and share access to the root key with them. You have to give your IOS app access to this same home root key. So the cloud access has to be cross platform. |
@jonsmirl Thank you very much, this will be very helpful to me. Google should have written this sample more comprehensively, many key points were not mentioned. |
These keys actually need to be secure. Matter is going to add support for cameras in the next version, and if you lose control of these keys hackers will be able to get into the cameras. This applies even if you don't make cameras. The keys let you onto the entire fabric, not just your own devices on that fabric. |
I am starting to think this Android CHIP controller API is simply broken. IOS started off with the same API Android has then they deprecated it and switched to this new API. In the Android API you can't just pass in the MTRKeypair class like you can on IOS, Instead you have to pass in the OperationalKeyConfig structure which which contains the MTRKeypair reference, but it also has to have the nodeOperationalCertificate as a parameter in that struct and it can't be NULL. And now you are stuck, because CHIP has to call KeypairDelegate to make the nodeOperationalCertificate and you have to pass in the nodeOperationalCertificate using the same struct as you use to pass in KeypairDelegate. IOS deprecated the old API and made the new one which fixes this dependency loop. To make CHIP work with cloud certificates you need that first IOS API. So the Android work around seems to be that I need to make the controller nodeOperationalCertificate using my own code before CHIP starts so that I can pass it in. |
@jonsmirl Were you ever able to successfully your own KeyPairDelegate and NOC and supply them to CHIP? When I try, I'm running into CHIP_ERROR_INVALID_PUBLIC_KEY because CHIP thinks the public key in the delegate and the NOC don't match. As far as I can tell, they do though... |
They need to match, most likely you don't have one of then encoded right
|
@jonsmirl Thank you! That resolved my issue. For some reason, I assumed that |
@jonsmirl You might have already figured this out, but this helped me understand why we need a NOC before initializing the device controller: project-chip/connectedhomeip#27027 |
The controller is just another Matter device, there is nothing special about it, so it needs a NOC just like every other device. Note that a controller is not really making the NOC for the other devices, it is just forwarding that request to NOCChainIssuer. And then it is NOCChainIssuer that makes the NOC certificate. If you have not built your own NOCChainIssuer then you are using the sample one included in the Java library. |
The Sample app is just making a demo controller using the default demo certificates. How do you set the controller up in order to make an actual vendor commissioner?
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.
Matter NOC certificates need MatterRCACId, MatterFabricId, MatterICACId values encoded into the Issuer and Subject fields. Where do these IDs come from?
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?
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.
The text was updated successfully, but these errors were encountered: