[Nfd-dev] Try NDNCERT (based on Interest-Data exchange) and get an NDN certificate today

[Junxiao Shi]

Hi Zhiyi


>>> With the negotiated shared secret by DH, the requester and issuer can:
>>> 1. Use hmac to sign the request which is faster and fits IoT scenarios
>>>
>>
>> This is false. With low-cost crypto chip such as ECC508 (less than $1),
>> IoT devices can easily access ECDH and ECDSA implemented by hardware.
>> Also, NDNCERT is not just for IoT.
>>
>
> It's true that NDNCERT is not just for IoT. Even though many chips are
> equiped with ECC support, there are still many boards who don't have (e.g.,
> the xpro boards we were using). On xpro board, our real world tests show
> that HMAC is more than ten times faster than ECC.
>

What is “xpro board”? Can you give a datasheet link?
If you are referring to “SAM E54 Xplained Pro”: it does include an ECC508
hardware crypto module.
It’s true that HMAC is faster than ECC (even with ECC508), but speed of
certificate issuance does not matter, as long as it’s not outrageous.
Security is a far more important metric.

First, digest of the public key can be represented as graphics (e.g. a cat
>> face with various colors and features). A client with GUI capability can
>> display the graphics, and the user can compare the graphics with one
>> generated by CA and embedded in the email.
>>
>
> This sounds interesting, but I hold another opinion on this. If we apply
> DH (or ECDH) in NDNCERT protocol, there is already no way that Eve can see
> the which challenge has been selected and what the PIN_E is. In this case,
> Eve cannot hurt anymore.
>
Yes, the attack can be prevented by encrypting PIN.

NDNCERT command line tools are more like a prototype to show how to use
> NDNCERT library. I would expect each system has their own realization of
> CA. If they want to have the fancy images, they can implement this feature.
>
Then you need to publish NDNCERT as a library (i.e. compile into a .so
file, like ndn-cxx does).

>
4. Support "code start" by using TOFO (trust on first use) when the
> requester don't know CA in advance. (Notice it's possbile to have Man In
> the Middle attack in this case)
>
The industry seems to be moving away from TOFU. In AWS IoT, root of trust
is securely programmed into the device during manufacturing process
https://www.microchip.com/design-centers/security-ics/cryptoauthentication/cloud-authentication/aws-iot-atecc608a
. This avoids a lot of attacks.

5. Simpified APIs (the current API requires many embedded call backs to
> work together)
>
Does this refer to the protocol, or the library?

Yours, Junxiao

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20181025/bc185c84/attachment.html>