<div dir="auto"><div><div dir="auto">Hi Zhiyi </div></div><div><br><div class="gmail_quote"></div></div></div><div dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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></blockquote></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto">Also, NDNCERT is not just for IoT.</div></div></blockquote><div><br></div><div>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.</div><div></div></div></div></blockquote><div dir="auto"><br></div></div><div dir="auto"><div dir="auto">What is “xpro board”? Can you give a datasheet link?</div><div dir="auto">If you are referring to “SAM E54 Xplained Pro”: it does include an ECC508 hardware crypto module.</div><div dir="auto">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.</div></div><div dir="auto"><div dir="auto"><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_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="auto">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.</div></div></blockquote><div><br></div><div>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.</div></div></div></blockquote></div><div dir="auto"><div dir="auto">Yes, the attack can be prevented by encrypting PIN.</div></div><div dir="auto"><div dir="auto"><div dir="auto"><br></div><blockquote class="gmail_quote" style="width:992px;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote" style="width:992px"><div></div><div>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.</div></div></div></blockquote><div dir="auto">Then you need to publish NDNCERT as a library (i.e. compile into a .so file, like ndn-cxx does).</div><blockquote class="gmail_quote" style="width:992px;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote" style="width:992px"><div></div></div></div></blockquote><blockquote class="gmail_quote" style="width:992px;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote" style="width:992px"><div></div></div></div></blockquote></div><div dir="auto"><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_quote"><div>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)</div></div></div></blockquote><div dir="auto">The industry seems to be moving away from TOFU. In AWS IoT, root of trust is securely programmed into the device during manufacturing process <a href="https://www.microchip.com/design-centers/security-ics/cryptoauthentication/cloud-authentication/aws-iot-atecc608a">https://www.microchip.com/design-centers/security-ics/cryptoauthentication/cloud-authentication/aws-iot-atecc608a</a> . This avoids a lot of attacks.</div><div dir="auto"><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_quote"><div></div><div>5. Simpified APIs (the current API requires many embedded call backs to work together)</div></div></div></blockquote></div><div dir="auto"><div dir="auto">Does this refer to the protocol, or the library?</div><div dir="auto"><br></div><div dir="auto">Yours, Junxiao</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_quote"><div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div>
</blockquote></div></div>
</blockquote></div></div>
</blockquote>
</div>