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

[Zhiyi Zhang]

Hi Junxiao,

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.

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

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)

I have already take the ndncert server offline. We will perform a major
upgrade on ndncert protocol and ndncert codebase.

Best,
Zhiyi

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

> Hi Zhiyi
>
> I asked a crypto expert to look at the NDNCERT protocol, and we found a
> serious flaw that would allow an attacker to obtain a certificate. It works
> as follows:
>
>    1. Bob owns email address bob at example.org. According to example.org's
>    CA policy, it entitles him to request a certificate named /org/example/bob.
>    2. Bob sends PROBE command with his email address, and the CA grants
>    the namespace /org/example/bob.
>    3. Bob sends NEW command with a certificate request CR_B for identity /org/example/bob.
>    Eve intercepts this command, and sends another NEW command with a different
>    certificate request CR_E for the same identity, but it contains Eve's
>    public key.
>    4. The CA generates two different request-ids ID_B and ID_E, one for
>    each certificate request.
>    5. Bob sends SELECT command choosing the email challenge under ID_B.
>    Eve does the same for ID_E. The CA sends two emails with PIN_B and PIN_E to
>    bob at example.org.
>    6. Bob receives two emails. Since the email template only contains the
>    six-digit PIN code and the CA name, Bob has no idea which email corresponds
>    to his certificate request.
>    7. There's a 50% chance that Bob enters PIN_E to his ndncert-client,
>    and sends a VALIDATE command that contains ID_B and PIN_E. Eve intercepts
>    this command and prevents it from reaching the CA.
>    8. Since PIN_E appears as plaintext in the VALIDATE command, Eve is
>    now able to construct a VALIDATE command with ID_E and PIN_E, and send it
>    to the CA.
>    9. The CA issues a certificate to Eve, despite that Eve does not
>    control the email address.
>
> The expert has suggested encrypting the PIN code, so that Eve cannot see
> PIN_E, stopping this attack.
> What do you think about this, and do you have other solutions?
>
> Yours, Junxiao
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20181024/ba9d5237/attachment.html>