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

Junxiao Shi shijunxiao at email.arizona.edu
Wed Feb 17 17:04:03 PST 2021


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/c23dd25c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zhiyi-ndncert_20210217.pcapng
Type: application/octet-stream
Size: 3316 bytes
Desc: not available
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20210217/c23dd25c/attachment.obj>


More information about the Nfd-dev mailing list