In the current implementation, KDpub certificate isn't signed by trustAnchor, right ?

[paulyu12]

In the current implementation, KDpub certificate isn't signed by trustAnchor, right ?

But according to the description of SSP, the cetificate response TLV from controller to device includes anchor-signed-cert-of-KDpub

Codes that constuct certificate response are around here.
https://github.com/gujianxiao/NDN-IoT-Android/blob/7c88f74cf903330174961e339444b87a7bd1dc65/ndn_lite_support_library/src/main/java/NDNLiteSupport/SignOnBasicControllerBLE/secureSignOn/secureSignOnVariants/basic/SignOnBasicController.java#L771

[peurpdapeurp]

Ah yes, you are correct; I had forgotten that I had to add that to the implementation (I left a note for myself at line 783).

I will work on adding this.

[paulyu12]

Just a confusion: why do you make the controller generates and distributes KD key pair? In the general protocol, only one entity saves the private key. But in the current implemntation, both the controller and the device do. Is there a method that a KD key pair is generated by a device and sent to the controller to be signed (KDpub) ?

[peurpdapeurp]

We have the protocol implemented in the current way that it is because we assume that constrained devices do not have the ability to generate key pairs with enough entropy for the key pair to be used in the long term.

It is possible to have the protocol be modified so that the key pair is generated in the constrained device, and this is addressed in the original paper describing the protocol, but we have not implemented that version of the protocol.