In particular, CCN content routers may choose to check all,
some or none, as their resources allow, and dynamically
adapt in response to detected attack or consumer advice.
4. 2. Managing trust
Although CCN moves data in a peer-to-peer fashion, it
provides end-to-end security between content publisher
and consumer. Consumers determine whether received
content is acceptable or trustworthy. CCN’s trust is
contextual, narrowly determined in the context of particular content and the purpose for which it will be used.
Different consumers can even use different trust models
for the same content. For example, a bank might require
that a deed be signed by someone authorized by the courts
while a backup server might only care that its signature
validates. This model is more flexible and scalable than
mandating a one-size-fits-all approach such as trusting
any publisher who has paid an annual fee to some root
The basic primitive of content-based security—
authenticated bindings from names to content—can be
used to implement mechanisms for establishing higher-level trust. CCN’s signed bindings between names and
content act in essence to certify that Data. For example,
when a name refers to an individual or organization
and the content is a public key, the result is essentially
a digital certificate. This allows CCN to support traditional mechanisms such as hierarchical PKI for establishing trust in keys. CCN also supports more general,
non-hierarchical models such as SDSI2, 5, 18 where keys are
mapped to identities via locally controlled namespaces.
For example, the members of an organization might be
recognized because their keys are certified by the organization itself, not because they are validated by a third-party like Verisign. If we know and trust one of parc.com’s
employees, we get their key any time we receive content
from them and by following its key locators (certification
chain) can easily get the key of parc.com (Figure 4). Thus,
starting from a small number of public keys authenticated using a variety of user-friendly mechanisms (e.g.,
personal contact, organizational membership, public
experience16, 20), one can use SDSI’s model to infer trust
in a large number of publishers.
figure 4. CCn trust establishment can associate content namespaces
with publisher keys.
parc.com/george/desktop public key
Signed by parc.com/george
Signed by parc.com
Evidence-based security. The CCN content model creates many
secured relationships: Each piece of data is bound to its name
and publisher’s key; names are implicitly bound to other
names by the naming hierarchy and application-level naming
conventions; publishers are bound to other publishers by the
key certification graph. As a consumer accumulates content,
this web of trusted relationships can be used to automatically
infer trust in entire collections of content. For example, once
trust has been established for the block of video shown in
Figure 4, that decision can be applied to any block of any version of / parc.com/george/videos/WidgetA.mpg signed by the
same key. Similarly, a block of the video signed by a different
key is automatically suspicious.
This notion can be extended beyond collections defined
by naming hierarchy. As Section 3. 2 notes, the full name of
a ContentObject contains a cryptographic digest of its
contents (a self-certifying name4, 6, 14, 15) and the identity (key)
of its publisher. Embedding a link using the full name of the
target ContentObject creates a secure reference4, 12, 13, 17 that
can resolve to only one object. Such references can be used to
express delegation, saying that the publisher P of a link named
N with target (N ′, P ′) intends the name N to refer to whatever
publisher P′ refers to by target name N′. They can also be used
to build up a network of trust in content where signed Data
certify the other content chunks they securely reference. For
example, having decided to trust the content of web page A,
browsers may automatically trust the images, ads, etc., that
A securely links to. This trust is fine-grained since the linked
content is only considered valid within the context of A.
4. 3. Content protection and access control
The primary means of controlling access to CCN content is
encryption. CCN does not require trusted servers or directo-ries to enforce access control policies: No matter who stumbles across private content, only authorized users are able to
Encryption of content, or even names or name components, is completely transparent to the network—to CCN, it
is all just named binary data (though efficient routing may
require that some name components remain in the clear).
Decryption keys are distributed as ContentObjects.
Name conventions, encapsulated in programmer-friendly
libraries, make it easy to find and decrypt the key needed by
an authorized user to decrypt a given piece of content. CCN
does not mandate any particular encryption or key distribution scheme. Arbitrary, application-appropriate access control models can be implemented simply by choosing how to
encode and distribute decryption keys for particular content.
4. 4. network security and denial-of-service
CCN’s design protects it from many classes of network attack.
Authenticating all content, including routing and policy information, prevents data from being spoofed or tampered with.
It is difficult to target malicious packets at host vulnerabilities
since CCN Interests address content, not hosts. Effective
attacks against CCN must use denial of service to either hide
legitimate content or drown it in a sea of spurious packets.
TCP/IP content originates at some server and an attacker
can easily hide it by placing a filter anywhere on the single