<div dir="ltr">Hi Junxiao,<div><br></div><div>Your mentioned attack scenario is valid and possible. Thank you for pointing that out!</div><div>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.</div><div><br></div><div>With the negotiated shared secret by DH, the requester and issuer can:</div><div>1. Use hmac to sign the request which is faster and fits IoT scenarios</div><div>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)</div><div><br></div><div>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)</div><div><br></div><div>I have already take the ndncert server offline. We will perform a major upgrade on ndncert protocol and ndncert codebase.</div><div><br></div><div>Best,</div><div>Zhiyi</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 24, 2018 at 1:17 PM Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu">shijunxiao@email.arizona.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">Hi Zhiyi</div><div class="gmail_extra"><br></div><div class="gmail_extra">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:</div><div class="gmail_extra"><ol><li>Bob owns email address <a href="mailto:bob@example.org" target="_blank">bob@example.org</a>. According to <a href="http://example.org" target="_blank">example.org</a>'s CA policy, it entitles him to request a certificate named /org/example/bob.</li><li>Bob sends PROBE command with his email address, and the CA grants the namespace /org/example/bob.</li><li>Bob sends NEW command with a certificate request CR_B for identity <span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">/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.</span></li><li>The CA generates two different request-ids ID_B and ID_E, one for each certificate request.</li><li>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 <a href="mailto:bob@example.org" target="_blank">bob@example.org</a>.</li><li>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.</li><li>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.</li><li>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.</li><li>The CA issues a certificate to Eve, despite that Eve does not control the email address.</li></ol></div><div class="gmail_extra">The expert has suggested encrypting the PIN code, so that Eve cannot see PIN_E, stopping this attack.</div><div class="gmail_extra">What do you think about this, and do you have other solutions?</div><div class="gmail_extra"><br></div><div class="gmail_extra">Yours, Junxiao</div></div>
</blockquote></div>