[Ndn-interest] Complete trust management from scratch in ndn-cxx
Michał Król
m.krol at ucl.ac.uk
Mon Oct 30 03:43:55 PDT 2017
I wasn't serving the certificate, so probably that's the problem. Both
consumer and producer are on the same physical machine, so I assumed the
consumer could retrieve the certificate directly from NFD. I'll try to
add the necessary code. However, it's a bit strange that a certificate
is still received, but with a malformed name...
@Pedro: thanks a lot for your code! I was looking for something like
this for a long time. It's extremely useful. It's just that it doesn't
compile with the newest version of ndn-cxx (v 0.6.0). The security API
got changed, but it's easy to adapt it.
Thank you both for your help,
Michał
On 26/10/17 22:33, Muktadir R Chowdhury (mrchwdhr) wrote:
>
> Can you tell me how your application is serving the certificate (where
> you are setting interest filter for certificate)?
>
> E.g. face.setInterestFilter("/root/site1/KEY")
>
>
> Can you share the code where you are doing it?
>
>
> The code snippet you shared shows how you are signing the data, not
> the certificate serving process.
>
>
> Muktadir
>
>
> ------------------------------------------------------------------------
> *From:* Michał Król <m.krol at ucl.ac.uk>
> *Sent:* Tuesday, October 24, 2017 9:20:20 PM
> *To:* Muktadir R Chowdhury (mrchwdhr); ndn-interest at lists.cs.ucla.edu
> *Subject:* Re: [Ndn-interest] Complete trust management from scratch
> in ndn-cxx
>
>
> If I understood well, the API says, that createIdentity() just
> retrieves the identity if it's already in the system (even if the name
> is somewhat misleading):
>
>
> "This method will check if the identity exists in PIB and whether the
> identity has a default key and default certificate. If the identity
> does not exist, this method will create the identity in PIB. If the
> identity's default key does not exist, this method will create a key
> pair and set it as the identity's default key. If the key's default
> certificate is missing, this method will create a self-signed
> certificate for the key."
>
>
> Anyway, which other method should be used to retrieve the certificate?
> I couldn't find any "good practice" document about it's supposed to be
> done.
>
>
>
> On 24/10/17 16:02, Muktadir R Chowdhury (mrchwdhr) wrote:
>>
>> You don't have to create the site identity again. You are creating it
>> using ndnsec-key-gen.
>>
>>
>> Just use the identity name to get the certificate, put it in the data
>> packet, name the data packet as the name of the cert, then send it.
>>
>>
>> Muktadir
>>
>> ------------------------------------------------------------------------
>> *From:* Michał Król <m.krol at ucl.ac.uk>
>> *Sent:* Tuesday, October 24, 2017 8:32:00 PM
>> *To:* Muktadir R Chowdhury (mrchwdhr); ndn-interest at lists.cs.ucla.edu
>> *Subject:* Re: [Ndn-interest] Complete trust management from scratch
>> in ndn-cxx
>>
>>
>> Sure, in the constructor I use:
>>
>> m_face.setInterestFilter("/root/site1",
>> bind(&Producer::onInterest, this, _1, _2),
>> RegisterPrefixSuccessCallback(),
>> bind(&Producer::onRegisterFailed, this,
>> _1, _2));
>>
>>
>> m_ident = m_keyChain.createIdentity(Name("/root/site1"));
>> m_info = ndn::security::SigningInfo(m_ident);
>>
>>
>> And then in when an interest arrives I use this to sign the data:
>>
>> m_keyChain.sign(*data, m_info);
>>
>>
>> On 24/10/17 15:28, Muktadir R Chowdhury (mrchwdhr) wrote:
>>>
>>> How are you serving the certificate?
>>>
>>> Can you share the code where producer is sending the certificate?
>>>
>>>
>>> Muktadir
>>>
>>>
>>> ------------------------------------------------------------------------
>>> *From:* Michał Król <m.krol at ucl.ac.uk>
>>> *Sent:* Tuesday, October 24, 2017 8:24:35 PM
>>> *To:* Muktadir R Chowdhury (mrchwdhr); ndn-interest at lists.cs.ucla.edu
>>> *Subject:* Re: [Ndn-interest] Complete trust management from scratch
>>> in ndn-cxx
>>>
>>>
>>> When I dump the certificate I get the correct name:
>>>
>>> ndnsec-dump-certificate -i -p /root/site1
>>>
>>> Certificate name:
>>> /root/site1/KEY/%AF%C7%D8y3%5De%06/NA/%FD%00%00%01_AR%9B%1C
>>>
>>> Key Locator: Name=/root/KEY/%AC%FD%1A%A9%CA%9A%A5%C3
>>>
>>>
>>> However, when I use it to sign, the name I get at the consumer is:
>>>
>>> /root/site1/KEY/%AF%C7%D8y3%5De%06/%FD%00%00%01_N%9E%0Aw
>>>
>>>
>>> The "NA" component is missing and that's the cause of the problem.
>>>
>>>
>>> In some tutorials, people submit "-N /root/site1" parameter to the
>>> ndnsec-certgen command. However, in the newest version, this option
>>> is not present. Could it be the problem?
>>>
>>>
>>>
>>>
>>> /root/site1/KEY/%AF%C7%D8y3%5De%06/%FD%00%00%01_N%9E%0Aw
>>>
>>>
>>> On 24/10/17 15:10, Muktadir R Chowdhury (mrchwdhr) wrote:
>>>>
>>>> The value for KEY_COMPONENT_OFFSET is -4. That means you get the
>>>> 4th component from the last. Another way of saying this is that you
>>>> have three more component after KEY.
>>>>
>>>>
>>>> Your key/cert creation looks fine.
>>>>
>>>> You can check the name of the certificate using this command:
>>>>
>>>> ndnsec-dump-certificate -i -p /root,
>>>>
>>>> ndnsec-dump-certificate -i -p /root/site1
>>>>
>>>>
>>>> Just make sure the data that contains the certificate is same as
>>>> the name of the certificate.
>>>>
>>>>
>>>> Muktadir
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>> *From:* Michał Król <m.krol at ucl.ac.uk>
>>>> *Sent:* Tuesday, October 24, 2017 7:54:44 PM
>>>> *To:* Muktadir R Chowdhury (mrchwdhr); ndn-interest at lists.cs.ucla.edu
>>>> *Subject:* Re: [Ndn-interest] Complete trust management from
>>>> scratch in ndn-cxx
>>>>
>>>>
>>>> Thanks for your message Muktadir. However, it still looks like the
>>>> <key-owner-prefix> can have only one component.
>>>>
>>>>
>>>> When I send an Interest for "/root", use identity "/root" to sign
>>>> and data name "root" it works fine. But when I send an interest for
>>>> "/root/site1", use identity "/root/site1" to sign and data name
>>>> "root/site1" it doesn't, because the check in ndn-cxx is expecting
>>>> "KEY" and I have "site1" now as the second component. I tried to
>>>> set the site1 signed certificate as the trust anchor in the config
>>>> file, but it still doesn't help.
>>>>
>>>>
>>>> The check I'm talking about is in ./src/security/v2/certificate.cpp
>>>> line 132. KEY_COMPONENT_OFFSET points to the wrong name component.
>>>> Maybe there's a problem when I'm generating the identities?
>>>>
>>>> I do it like this:
>>>>
>>>> ndnsec-keygen /root | tee root.ndncert | ndnsec-cert-install -
>>>> ndnsec-keygen /root/site1 > site1.req
>>>> ndnsec-certgen -s /root/ site1.req > site1.ndncert
>>>> ndnsec-cert-install -f site1.ndncert
>>>>
>>>>
>>>> Once again, thanks a lot for your help,
>>>>
>>>> Michał
>>>>
>>>>
>>>> On 23/10/17 21:35, Muktadir R Chowdhury (mrchwdhr) wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> When your producer sends the certificate make sure that the name
>>>>> of the data is the name of the certificate. Because the receiver
>>>>> will use the data packet to construct the certificate. If the data
>>>>> name does not follow the certificate naming convention, the
>>>>> constructor for Certificate will throw the error you reported.
>>>>>
>>>>>
>>>>>
>>>>> Please note that certificate name and key name are different.
>>>>>
>>>>> Key name: <key-owner-prefix>/KEY/<key-id>,
>>>>>
>>>>> Certificate
>>>>> name: <key-owner-prefix>/KEY/<key-id>/<issuer-id>/<version-id>.
>>>>>
>>>>>
>>>>> For certificate name the library is expecting three more
>>>>> components after the "KEY" component.
>>>>>
>>>>>
>>>>> Let me know if you have any more questions.
>>>>>
>>>>>
>>>>> Muktadir
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>> *From:* Ndn-interest <ndn-interest-bounces at lists.cs.ucla.edu> on
>>>>> behalf of Michał Król <m.krol at ucl.ac.uk>
>>>>> *Sent:* Sunday, October 22, 2017 7:28:45 PM
>>>>> *To:* Matteo.Bertolino at eurecom.fr; ndn-interest at lists.cs.ucla.edu
>>>>> *Subject:* Re: [Ndn-interest] Complete trust management from
>>>>> scratch in ndn-cxx
>>>>>
>>>>>
>>>>> I looked a bit deeper in the code and I found the reason of the
>>>>> problem.
>>>>>
>>>>> ndn-cxx is expecting "KEY" as the second component in the
>>>>> certificate name. However, my certificate name is:
>>>>> "/root/publisher/KEY/%AF%C7%D8y3%5De%06/%FD%00%00%01_D8%F1%A4", so
>>>>> "KEY" is the third component.
>>>>>
>>>>> When I changed the code to put "/root/" in the Interest instead of
>>>>> "/root/site1" it solved the problem and the signature is verified
>>>>> correctly. In future experiments I would like to implement a
>>>>> hierarchy of trust. Do you know what is the problem here?
>>>>>
>>>>> Best,
>>>>>
>>>>> Michał
>>>>>
>>>>>
>>>>> On 17/10/17 10:49, Michał Król wrote:
>>>>>>
>>>>>> Hi Matteo,
>>>>>>
>>>>>> thanks for your message. It's just a formatting problem. For some
>>>>>> reason my mail client decide to replace tabs with "/" and "?".
>>>>>> There are not present in the files though.
>>>>>>
>>>>>> I've seen your tutorial before. Actually, it was the only
>>>>>> complete solution it could find online, so I was basing heavily
>>>>>> on it. Thank you. My setup seems only slightly different, but I
>>>>>> still can't make it work.
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>> Michał
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Begin forwarded message:
>>>>>>>>
>>>>>>>> *From: *Matteo Bertolino <Matteo.Bertolino at eurecom.fr
>>>>>>>> <mailto:Matteo.Bertolino at eurecom.fr>>
>>>>>>>> *Subject: **Re: [Ndn-interest] Complete trust management from
>>>>>>>> scratch in ndn-cxx*
>>>>>>>> *Date: *16 October 2017 19:49:16 BST
>>>>>>>> *To: *<ndn-interest at lists.cs.ucla.edu
>>>>>>>> <mailto:ndn-interest at lists.cs.ucla.edu>>
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>> why do you have the "//" in each line of the validator?
>>>>>>>> I am by phone so I cannot provide you easily a good answer, but
>>>>>>>> you can find a completed and commented use case here:
>>>>>>>> https://github.com/MatteoBertolino92/NDN-matteo/blob/master/ndncxx_miniNDN_someUseCases_nacks__certificates__interest_verification.pdf
>>>>>>>>
>>>>>>>> Section 3. Write me if u need some clarifications.
>>>>>>>> Matteo
>>>>>>>>
>>>>>>>>
>>>>>>>> Quoting Micha? Król <m.krol at ucl.ac.uk <mailto:m.krol at ucl.ac.uk>>:
>>>>>>>>
>>>>>>>>> Dear all,
>>>>>>>>>
>>>>>>>>> I'm struggling with setting up a simple trust/security system
>>>>>>>>> in NDN. I
>>>>>>>>> find it difficult to find an updated set information that will
>>>>>>>>> work for
>>>>>>>>> all system components. Please correct me if I misunderstood
>>>>>>>>> something.
>>>>>>>>>
>>>>>>>>> I have a very simple scenario: one producer and one consumer
>>>>>>>>> on one
>>>>>>>>> machine. I want to have a central entity (root) and a publisher
>>>>>>>>> (publisher) that will be allowed to publish trusted content.
>>>>>>>>>
>>>>>>>>> I first create the root certificate using ndnsec and selfsign
>>>>>>>>> it: /
>>>>>>>>> /
>>>>>>>>>
>>>>>>>>> / ndnsec-key-gen -n /root//
>>>>>>>>> /
>>>>>>>>>
>>>>>>>>> / ndnsec-sign-req /root > root.cert/
>>>>>>>>>
>>>>>>>>> Next I create a certificate for the publisher and sign it
>>>>>>>>> using the root
>>>>>>>>> certificate:
>>>>>>>>>
>>>>>>>>> / ndnsec-key-gen -n /root/publisher > unsigned_publisher.cert//
>>>>>>>>> // ndnsec-cert-gen -S 201510080000 -E 202010080000 -s /root -i
>>>>>>>>> /root/publisher -r unsigned_publisher.cert > publisher.cert/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I then used the publisher identity to sign the data:
>>>>>>>>>
>>>>>>>>> / m_ident =
>>>>>>>>> m_keyChain.createIdentity(Name("/root/publisher"));//
>>>>>>>>> // m_info = ndn::security::SigningInfo(m_ident);/
>>>>>>>>>
>>>>>>>>> / m_keyChain.sign(*data, m_info);/
>>>>>>>>>
>>>>>>>>> On the consumer side I use a validator to validate data:
>>>>>>>>>
>>>>>>>>> / m_validator->load("sample.cfg");/
>>>>>>>>>
>>>>>>>>> / m_validator->validate (data,//
>>>>>>>>> // ndn::bind(&Consumer::onValidated, this, _1),//
>>>>>>>>> // ndn::bind(&Consumer::onValidationFailed, this,
>>>>>>>>> _1, _2));/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I want to trust everything signed with the publishers key. The
>>>>>>>>> sample.cfg is:
>>>>>>>>>
>>>>>>>>> / rule//
>>>>>>>>> // {//
>>>>>>>>> // id "Sample Rule"//
>>>>>>>>> // for data//
>>>>>>>>> // filter//
>>>>>>>>> // {//
>>>>>>>>> // type name//
>>>>>>>>> // name /root/publisher//
>>>>>>>>> // relation is-prefix-of//
>>>>>>>>> // }//
>>>>>>>>> // checker//
>>>>>>>>> // {//
>>>>>>>>> // type hierarchical//
>>>>>>>>> // sig-type rsa-sha256//
>>>>>>>>> // }//
>>>>>>>>> // }//
>>>>>>>>> //
>>>>>>>>> // trust-anchor//
>>>>>>>>> // {//
>>>>>>>>> // type file//
>>>>>>>>> // file-name "root.cert"//
>>>>>>>>> // }/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Now, when I launch the consumer, it issues an interest, gets
>>>>>>>>> the data,
>>>>>>>>> issues another interest to get the key
>>>>>>>>> (/root/publisher/KEY/4%05i%7E%3C%F6%87%2F/%FD%00%00%01_%25%8Bz%80),
>>>>>>>>> but
>>>>>>>>> ends up with an error:
>>>>>>>>>
>>>>>>>>> / Malformed certificate (Name does not follow the naming
>>>>>>>>> convention
>>>>>>>>> for certificate). /
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> My question is now, is it how I'm supposed to do this? If yes,
>>>>>>>>> what's
>>>>>>>>> the problem here? If not, is there any example tutorial,
>>>>>>>>> walking through
>>>>>>>>> the all steps of managing trust in NDN (ndnsec, app, validator)?
>>>>>>>>>
>>>>>>>>> Thanks in advance,
>>>>>>>>>
>>>>>>>>> Micha?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> -------------------------------------------------------------------------------
>>>>>>>> This message was sent using EURECOM Webmail:
>>>>>>>> http://webmail.eurecom.fr <http://webmail.eurecom.fr>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Ndn-interest mailing list
>>>>>>>> Ndn-interest at lists.cs.ucla.edu
>>>>>>>> <mailto:Ndn-interest at lists.cs.ucla.edu>
>>>>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20171030/1663cae7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20171030/1663cae7/attachment-0001.sig>
More information about the Ndn-interest
mailing list