[Ndn-interest] [Question] Where is the public key should be stored?

[Pengyuan Zhou]

Hi Marc,

Thanks for your reply and interesting ideas. 

I do have some more questions.
> On 14 Apr 2017, at 21:09, Marc.Mosko at parc.com wrote:
> 
> Pengyuan,
> 
> In general there is not the same idea of TLS handshakes because the trust anchors for content would not be the same as the replica name hosting that content in cache.  NDN has several tech reports on different ways to encrypt data that you can find in their publications section.
> 
> In the CICN community, we’ve addressed this mainly two ways:
> 
> 1) The publisher includes the public key in the first content chunk (or a named pointed to it).  If the content is encrypted for a particular recipient, then the publisher wraps a symmetric key in the first chunk then generates per-chunk session keys based on the symmetric key and the chunk number (i.e. the chunk number becomes part of the IV in the AES algorithm’s key derivation).  In CICN, we’ve favored encapsulation encryption (i.e. there’s an unencrypted outer name used for transport and an inner name part of the wrapped encrypted object) as that leaks the least amount of information.
> 
In that sense, encryption is not made on the fly, will that be vulnerable for those relative static content which exist in the network for long time?
> 2) When a replica name is known, for example the publisher lists that you can get the content from Comcast or Akamai, then the client can use a TLS like protocol to get session encryption to that replica.  See, for example, https://www.ietf.org/id/draft-wood-icnrg-ccnxkeyexchange-01.txt <https://www.ietf.org/id/draft-wood-icnrg-ccnxkeyexchange-01.txt>.  This form of opportunistic channel encryption does not replace the end-to-end manifest (or merkle hash tree) signing, but compliments it.  It also includes mechanisms where a user can authenticate to a publisher then get a re-direction token to continue a TLS-like session with a particular replica.
> 
This seems interesting and I may misunderstood this. By publisher lists, does that assume that multiple publishers willing to provide same contents to users in a “sharing” way? If so, I’m wondering the feasibility due to the actual competition relationship of the publishers.
> Marc
> 
> 
>> On Apr 14, 2017, at 11:55 AM, Pengyuan Zhou <zpymyyn at gmail.com <mailto:zpymyyn at gmail.com>> wrote:
>> 
>> Hi all,
>> 
>> According to my understanding, the KeyLocator has the storage location of the key.
>> 
>> My question is where normally should the key be stored, especially for secure transmission?
>> 
>> Since NDN is not end-to-end, there might not be thing like "TLS handshake”, or is there?
>> 
>> If not, then how does NDN realise the agreement of "Master Secret and Session key” (or sth. similar)?
>> 
>> Seems to me that all the key info including the KeyLocator are predefined before transmission, is that realistic?
>> 
>> There might be understanding, please correct me if so.
>> 
>> Thanks.
>> 
>> Best,
>> Pengyuan Zhou
>> University of Helsinki
>> _______________________________________________
>> 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/20170416/1808d3d7/attachment.html>