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

Marc.Mosko at parc.com Marc.Mosko at parc.com
Thu Apr 20 11:51:42 PDT 2017


On Apr 20, 2017, at 3:00 AM, Luca Muscariello <luca.muscariello at gmail.com<mailto:luca.muscariello at gmail.com>> wrote:

Marc,

this means, correct me if I'm wrong, that you can
1) let a CDN node store encrypted data packets, as a relay in case of ephemeral keys (the data origin is still the live encryption point )

We had not envisioned it that way.  The idea here is that once the authentication server negotiates with the client, it then delegates the data transfer and data encryption to the MovePrefix namespace.  It would be problematic if two systems were capable of encrypting potentially different data with the same AES keys.  So, in this case, the MovePrefix server is not a relay.  It is a delegation and the MoveToken is a recovery mechanism for the traffic secret.  This only works when there is a strong relationship between the authentication and MovePrefix systems.  The system we use is somewhat like Kerberos & IETF LURK.  The {MovePrefix, MoveToken} is explained more fully in an accepted-but-not-yet-published paper cited below [2].

The MovePrefix is not a replacement for a authorization delegation system, which is what one would use when there is not a strong relationship between systems.  In this case, the consumer would pin up a CCNxKE session to the first namespace, then that would re-direct to a second namespace and provide an authorization token (e.g. OAuth-like) and the consumer would then pin up a new CCNxKE session to that namespace and present the authorization token.  This does not use the {MovePrefix, MoveToken} and derives two independent set of ephemeral keys.

In another usage, there does not need to be the delegated authorization.  Consumer does CCNxKE to first namespace, gets redirected to second namespace and establishes new CCNxKE session to that namespace to retrieve, for example, a broadcast encrypted file that it has separate keys for from the first system.  This does not use the {MovePrefix, MoveToken}.

There might be ways of doing what you describe, but one would need to look at what is trying to be accomplished.  This sounds a bit more like the trusted middle box TLS where some data is private and some data is shared with the middle box.  Chris Wood and I will have a paper in ICC 2017 about a technique like “blind caching” for ICN [1].  We will also have a paper in IFIP Networking on mobile sessions using CCNxKE [2].

[1] Christopher Wood and Marc Mosko, "Secure Off-Path Replication in Content-Centric Networks,” ICC NGNI 2017, Paris (yet to appear).

[2] Marc Mosko, Ersin Uzun, Christopher A. Wood, “Mobile Sessions in Content-Centric Networks,” IFIP Networking 2017, Stockholm (yet to appear).

2) let a CDN node store encrypted data packets for longer in case of, for instance,  broadcast encryption (the data origin, at the time the consumer start asking for data, can be the CDN node).

Yes, this is exactly right and one of the main use cases.  The consumer gets channel privacy using CCNxKE to the CDN and content privacy/authenticity via normal ICN methods.

The channel privacy, in this case, is only as good as one’s trust in the server certificate used in the DH exchange.  Otherwise, someone could insert a MITM to observe traffic.  A consumer needs to believe two things (A) that the namespace of the certificate is a trustworthy (won’t snoop on me) namespace and (B) the root of trust of the certificate is trustworthy (the holder of the private key corresponding to the certificate is really the desired namespace).

In the above examples in your (1), some of this could be punted to the authorization system.  Because we believe that system for the desired content (for whatever reason of that trust), then it telling us that the MovePrefix (or other namespace delegation mechanism) is OK for channel security, we can derive (A) from that.  Point (B) could be from a trusted 3rd party (e.g. a verisign) or the authorization server could give us a root of trust for the certificate we should expect for (A), such as a fingerprint of the certificate or fingerprint of the certificate chain.


In all cases there is no trust delegation from the content owner to the CDN.

Well, there’s some in that the authorization system says you should use the second system and that you could infer some degree of channel privacy from that.

I think the point here is that the CDN does not need to impersonate the content’s namespace like today where a CDN must have a certificate that has the content owner’s name in it and those private keys.  There’s no impersonation happening here, it’s is all explicit handoffs.

Also, the data is stored encrypted and not in the clear like today CDN.

A CDN today could store broadcast encrypted content today, so I’m not sure this is a strong differentiator.


W/o trust delegation the publisher does not need to have an explicit contract with the CDN node.
The CDN node cannot decrypt data.

If one wanted to use the {MovePrefix, MoveToken} approach, one needs a tight relationship.  For the re-direct method, there does not need to be a tight relationship, the publisher only needs to tell the consumer what new namespace to use.

A content provider, however, needs to ensure that it’s use of 3rd parties conforms to its privacy policy with its users.  If the content provider, for example, says to a user to get the content from a cache operated by the consumer’s ISP, then there is a high likelihood that the cache and ISP could uniquely identify the consumer and could make use of that transaction outside the content provider’s privacy policy if there is no relationship between the two.  Even if the request goes to a 3rd party CDN, unless there is a relationship between the content provider and CDN, an ISP could mark Interests in such a way that the CDN could track usage with the ISP (i.e. the ISP pays the CDN to track for it).

Marc



Luca


On Wed, 19 Apr 2017 at 19:34, <Marc.Mosko at parc.com<mailto:Marc.Mosko at parc.com>> wrote:
On Apr 18, 2017, at 1:03 PM, Luca Muscariello <luca.muscariello at gmail.com<mailto:luca.muscariello at gmail.com>> wrote:

Marc,

Suppose the server that issues the manifest is the same unique server in the list. Suppose the outer name is used like the hostname and the inner name is used as the content path in a name hierarchy local to the server.

Yes, this is what would happen with CCNxKE and encapsulated encryption.  The outer name would be something like /foo/sessions/session_id/sequence_num.  The inner names would be something like /foo/content/content_id/version/chunk.  In this case, the inner content does not need to be encrypted (e.g. broadcast encrypted), though it’s still a good practice to sign it (e.g. the manifests).


Encryption would be made on the fly by the server, using ephemeral keys, why not, using a DH negotiation.

yes, that is what would happen with CCNxKE, the session encryption keys are pretty much just like TLS 1.3.


How far is this to today point to point session based encryption?

I think CCNxKE is cryptographically the same encryption as TLS 1.3.  There are some differences in restart and move tokens and the use of ICN names instead of IP addresses.  CCNxKE also introduced the idea of move tokens so the authentication server can pass the data transfer to a different server (namespace) using an authorization token.  There is also some differences in the up-front work so CCNxKE puts more work on the client than the server to avoid computational DoS.


I see a couple of differences like block integrity for reliable transport like in TLS but seems minor.

Yes, it’s closer to DTLS 1.3 than TCP-based TLS.  Though I should point out the CCNxKE is just the key exchange part and setting up a session id, it is not the actual data transport (i.e. there’s no record format).

We recommended the data transport be done using encapsulation (outer names and inner names) not in-place encryption [1].  This does result in something a little like a record format for the data, but the important thing is it is separable from the key exchange to allow experimentation and innovation in that area.  For example, CCNxKE could be used more like IKE than TLS, though it is based on the TLS semantics of key exchange.

[1] https://www.ietf.org/id/draft-wood-icnrg-esic-00.txt


What seems still a big difference is the way trust and authentication is decoupled to the encryption key.

Yes, this is the important thing.  There is a separate trust of the channel from the data.  CCNxKE lets one or both parties authenticate the peer for channel security (i.e. non-observability) and then separately trust the data (e.g. via manifest signing).

This enables several types of new services.  First, I might want to use a CDN that I trust due to its terms of use (e.g. they don’t keep records or they don’t resell info), so I want to know my channel is secure to them separately from the content.  Second, if I trust some content provider (e.g. a hulu service) and that service tells me to use such-and-such CDN, then I might have some assurance of a similar level of customer confidentiality from that CDN as from the content provider (at least for that provider).  I may have stronger legal protections and privacy protections when the CDN has contractual obligations to the content provider than when I grab content from random opportunistic caches.

Marc


Hope my use case is clear.

Luca

On Mon, Apr 17, 2017 at 6:00 PM, <Marc.Mosko at parc.com<mailto:Marc.Mosko at parc.com>> wrote:
See replies in-line

On Apr 16, 2017, at 6:05 AM, Pengyuan Zhou <zpymyyn at gmail.com<mailto:zpymyyn at gmail.com>> wrote:

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<mailto: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?

Yes, this is the common publish-and-forget approach of ICN.  There are a variety of key-wrapping techniques to communicate a symmetric data key to a designated consumer (see the older CCNx way of doing it [1] or the link Jeff sent to the NDN group access control).  Both use techniques to wrap a symmetric keys for each consumer for some piece of data (there are a variety of technical differences and there are other proposals).

The larger picture is as you say, one-way encryption.  There are some advantages in this if your network model is disconnected (in time or space).  There are also some cryptographic disadvantages, such as needing to know all the consumers (to wrap the key for them), no forward secrecy, and correlation attacks.   It usually also has a lazy idea of revocation: to remove a group member one changes the keys going forward, but does not go backwards and re-encrypt under the assumption that whatever was previously published as readable has already been read (it’s could also be a huge computational endeavor).

Some have argued that for some content, e.g. static page elements from a bank page, it’s ok to use such an approach because an attacker already knows your going to that bank via the name (or IP address).  It’s only the personal information that needs session encryption.  I think as long as an attacker cannot gain more information about you (e.g. you download the “I’m super crazy rich” image vs the “I’m in debt” image) it could be ok, but that level of cognizance about what leaks information is often hard to see ahead of time (my example was pretty blatant).  It is safer to assume all page elements could leak information.

[1] https://github.com/ProjectCCNx/ccnx/blob/master/doc/specs/AccessControl/AccessControlSpecs01.pdf

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.  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.

By “publisher lists” I meant that a single publisher (e.g. Hulu) publishes a list of the approved cached (e.g. Akamai, Comcast, Fastly).  It would sign this and make it public with some TTL.  A consumer can then learn the name of the caches (really CDNs) and match that against a certificate in the TLS-like (CCNxKE) transaction.  If a consumer did not know to trust a specific name, then you’d be vulnerable to MITM attacks trying to set up an opportunistic encrypted session.

The root of trust could be a 3rd party like today (e.g. verisign et al.) or could be provided in the “publisher list” or could be via some other mechanism like schematized trust.  One must ensure that whatever is used in this step is also resistant to MITM.

This establishes the outer security layer for an encrypted session that can then pass inner Interests and Data through it.  Those inner names do not need to be correlated to the outer names.  It thus achieves protection against observability without the publish-and-forget approach.  That said, it is still likely that a video provider (or other paywall content provider) would use broadcast encryption of the payloads and likely with non-obvious names.  Or other models, such as the paywall content provider running their own servers in the CDN’s network so the session encryption and inner object signing are all that is needed without an extra encryption layer.

This scheme is pretty similar to what happens today.  You connect to a publisher (e.g. www.hulu.com<http://www.hulu.com/>) and that publisher gives you back a link to content that will then resolve (via DNS) to a CDN (e.g. a Fastly IP address).  One difference is that to get the “gold lock” the CDN is impersonating the publisher’s TLS certificate so the certificate name and URI host match.  In the CCNxKE approach, we decouple the channel session encryption from the content provenance, so you can separately trust both whom you talk to and what you talk about.

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


_______________________________________________
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/20170420/8822099a/attachment-0001.html>


More information about the Ndn-interest mailing list