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

[Zhiyi Zhang]

Hi Junxiao,

On Thu, Feb 18, 2021 at 5:22 AM Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> Hi Zhiyi
>
> I'm finally able to obtain a certificate from your CA.
> However, there are still a few remaining issues.
>
> Missing prefix registration of issued certificate
> Currently, it's impossible to retrieve an issued certificate unless the
> requester is directly connected to the CA host.
> To solve this issue, the CA needs to perform a prefix registration for
> each certificate, and use Origin=0x41 in the registration. This would cause
> local NLSR to initiate a routing announcement on each certificate name, so
> that the certificate is reachable from anywhere on the network.
> This prefix registration should be deleted when the certificate falls out
> of CA's issued certificate cache, which also withdraws the routing
> announcement.
>

I think this is not an issue given the requester will directly contact the
CA?
After fetching the certificate, the requester should take responsibility to
make his certificate available to the network.


>
> decryptionIv check
> The IV check code is now:
>
> https://github.com/Zhiyi-Zhang/ndncert/blob/de58e605fe26391833c883f1927f7f4cdc226e5b/src/detail/crypto-helpers.cpp#L404-L415
>   if (decryptionIv.empty()) {
>     decryptionIv = currentIv;
>   }
>   else {
>     if (loadBigU32(currentIv, 8) < loadBigU32(decryptionIv, 8)) {
>       NDN_THROW(std::runtime_error("Error when decrypting the AES
> Encrypted Block: "
>                                    "The observed IV is incorrectly
> formed."));
>     }
>     else {
>       decryptionIv = currentIv;
>     }
>   }
>
> The counter check is correct, but it still fails to fulfill these two
> requirements in the protocol:
>
>    - The random value portion chosen by the requester must be different
>    from the random value portion chosen by the CA.
>    - The random value portion in every message from the requester must be
>    the same.
>
>
Fixed.


> Crypto timing vulnerability
> There is timing vulnerability in ECDHState::deriveSecret, hkdf,
> aesGcm128Decrypt functions.
>
> https://github.com/Zhiyi-Zhang/ndncert/blob/de58e605fe26391833c883f1927f7f4cdc226e5b/src/detail/crypto-helpers.cpp
> These functions should not check return values or throw errors in the
> middle, but can only do one check at the end.
>

I've updated the code in crypto helpers. (tho I wouldn't worry too much
about this issue for now).

Best,
Zhiyi



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