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

[Zhiyi Zhang]

On Thu, Oct 25, 2018 at 7:00 PM Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> 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.
>

I am saying this board, which I don't think is equipped with ECC support.
http://ww1.microchip.com/downloads/en/devicedoc/Atmel-42243-SAMR21-Xplained-Pro_User-Guide.pdf


> 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.
>

Sure I agree with you.


>
> 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).
>

It's already a library as well as some command line tools. We also have a
PPA package for this here:
https://github.com/named-data/ppa-packaging/tree/master/ndncert


>
> 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.
>

You are right. I am also considering whether we should adopt TOFU when
there is no CA certificate pre-installed. It is very different from
security bootstrapping where the cert requester and issuer can establish
trust at the same time, in a genertic scenario, there is usually no way for
a requester to challenge the CA  (e.g., requester cannot require CA to
obtain some shared secret or scan some QR code).


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

Best,
Zhiyi


>
> Yours, Junxiao
>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20181029/ce373c08/attachment.html>