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

[Zhiyi Zhang]

Hi Junxiao,

Thank you for helping to point out the mismatch between the spec and
implementation.
I have fixed the issues and updated the deployment.

Best,
Zhiyi

On Wed, Feb 17, 2021 at 5:04 PM Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> Hi Zhiyi
>
> I did a test on your CA. The NewResponse packet is decoding correctly.
> However, after sending ChallengeRequest, I'm getting the following error:
> 0000   15 2b ab 01 04 ad 26 49 6e 74 65 72 65 73 74 20   .+....&Interest
> 0010   70 61 72 61 6d 61 74 65 72 73 20 64 65 63 72 79   paramaters decry
> 0020   70 74 69 6f 6e 20 66 61 69 6c 65 64 2e            ption failed.
>
> I looked at the CA code and noticed several obvious bugs.
> I guess this error is caused by the first bug. You can look at the packet
> trace and cross-reference server logs near the packet timestamps, to
> confirm this theory.
>
> HKDF
> The CA invokes HKDF as follows:
>
> https://github.com/Zhiyi-Zhang/ndncert/blob/7cca76aeae764667da6f4ca80684439a5af8e5dc/src/ca-module.cpp#L260
>   hkdf(sharedSecret.data(), sharedSecret.size(), salt.data(), salt.size(),
> aesKey.data(), aesKey.size());
>
> The protocol specifies:
> The Info is the 8 byte value of request-id.
> But the implementation is missing the Info parameter.
>
> decryptionIv check
> The protocol specifies:
> Recipient ... should check ... the counter is monotonically increasing and
> has not wrapped around.
> Suppose the first message from the requester has 3 blocks and uses IV
> 0xd674c25ade65161400000000, the second message from the requester can use
> any IV that starts with 0xd674c25ade651614 and ends with a number greater
> than or equal to 0x00000003. For example, the second message could use IV
> 0xd674c25ade65161400000003 or 0xd674c25ade65161400000020.
>
> The CA checks the initialization vector as follows:
>
> https://github.com/Zhiyi-Zhang/ndncert/blob/7cca76aeae764667da6f4ca80684439a5af8e5dc/src/detail/crypto-helpers.cpp#L403-L406
>     if (currentIv != decryptionIv) {
>       NDN_THROW(std::runtime_error("Error when decrypting the AES
> Encrypted Block: "
>                                    "The observed IV is incorrectly
> formed."));
>     }
> This implementation is overly strict: it would only admit
> 0xd674c25ade65161400000003, but incorrectly rejects
> 0xd674c25ade65161400000020.
>
> Moreover, the CA fails to check that the random value portion selected by
> the requester differs from the random value portion selected by the CA.
> That check is required by the protocol.
>
> Buffer overflow in IV decoding
> There's an undefined behavior in this line:
>
> https://github.com/Zhiyi-Zhang/ndncert/blob/7cca76aeae764667da6f4ca80684439a5af8e5dc/src/detail/crypto-helpers.cpp#L398
> std::vector<uint8_t>
> currentIv(block.get(tlv::InitializationVector).value(),
> block.get(tlv::InitializationVector).value() + 12);
> If the TLV-LENGTH of the IV element is less than 12, a buffer overflow
> condition may occur.
>
> Yours, Junxiao
>
> On Wed, Feb 17, 2021 at 6:12 PM Zhiyi Zhang <zhiyi at cs.ucla.edu> wrote:
>
>> *External Email*
>> Hi Junxiao,
>>
>> I've added RestartSec in the systemd file and removed the status field
>> from NEW packets.
>> I also restarted the service on Suns.
>>
>> Best,
>> Zhiyi
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20210217/daee75fe/attachment-0001.html>