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

[Zhiyi Zhang]

On Wed, Oct 24, 2018 at 2:27 PM Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> Hi Zhiyi
>
>
>> Your mentioned attack scenario is valid and possible. Thank you for
>> pointing that out!
>> Given the ndncert protocol is for two ends only, I think we can add a
>> Diffie-Hellman process in the NEW command and its reply.
>>
>
> I hope you are referring to ECDH, not classical Diffie-Hellman. Many IoT
> devices have binary code size constraint. Since ECDSA must be supported, it
> takes less binary code to add ECDH than to add classical DH.
>

Yes. ECDH is what in my mind.


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


> 2. Use key derived from the shared secret to AES encrypt the sensitive
>> components and Data content (prevent Eve to see the PIN_E and all the other
>> sensitive info)
>>
> Yes.
>
>
>> On the other hand, I will update the email format to include the full
>> certificate name and request id (each request instance has a unique ID)
>>
> Usability is a concern: user is going to neglect the request ID. There are
> two solutions:
> 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.
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.


> Second, the PIN code can be prefixed by the request ID. The email says
> "PIN code 777777-666666"; the client prompts "Enter PIN code: 777777-"; the
> user types "666666".
>

I would adopt this solution.


>
>
>> I have already take the ndncert server offline. We will perform a major
>> upgrade on ndncert protocol and ndncert codebase.
>>
> When can we see a preview of the new protocol?
>

I have some slides but is not in a good shape. I can organize it and update
a google slide link later.
Some new features:

1. Use interest parameters to save the bandwidth used by Data name
2. ECDH for encrpting Interest name (partially) and Data content
3. Support ephemeral certificates by letting requester to specific the
certificate validity period (of course cannot larger than CA's max
validitiy period setting)
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)
5. Simpified APIs (the current API requires many embedded call backs to
work together)

Best,
Zhiyi



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