[Ndn-interest] Complete trust management from scratch in ndn-cxx

Michał Król m.krol at ucl.ac.uk
Tue Oct 24 08:20:20 PDT 2017


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/20171024/ba736ff0/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/20171024/ba736ff0/attachment-0001.sig>


More information about the Ndn-interest mailing list