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

[Zhiyi Zhang]

This is the link to the new design of NDNCERT:
https://docs.google.com/presentation/d/17DLHLwiftGtuqkITJLgV_YWbhuq-NQhvOSNpWgal0wY/edit?usp=sharing

Best,
Zhiyi

On Wed, Oct 24, 2018 at 3:05 PM Zhiyi Zhang <zhiyi at cs.ucla.edu> wrote:

>
>
> 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/abc769ff/attachment.html>