icnrg C. Wood
Internet-Draft University of California Irvine
Intended status: Experimental March 13, 2017
Expires: September 14, 2017
Content-Locked Encryption and Authentication of Nameless Objects
draft-wood-icnrg-clean-00
Abstract
This document specifies CCNx CLEAN - content-locked encryption and
authentication of nameless objects - as a way of enabling encrypted
and naturally de-duplicated content in CCN. CLEAN allows producers
to encrypt large collections of static data and use the FLIC Manifest
to convey the necessary decryption information to consumers. As a
result, CLEAN encrypts nameless content objects without any
application input.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 14, 2017.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Wood Expires September 14, 2017 [Page 1]
Internet-Draft CCNxCLEAN March 2017
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions and Terminology . . . . . . . . . . . . . . . 3
2. CLEAN Crypto . . . . . . . . . . . . . . . . . . . . . . . . 3
3. CLEAN End Host Support . . . . . . . . . . . . . . . . . . . 4
4. FLIC Support . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. Normative References . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
In CCN, nameless objects are content objects which do not carry a
Name TLV field [CCNxSemantics]. Matching an interest to a nameless
content object therefore requires knowledge of the latter's
ContentObjectHash (or ContentId). A ContentId is the cryptographic
hash of a Content Object message. A router may only forward a
nameless content object if its cryptographic hash digest matches that
which is specified in the ContentObjectHashRestriction of the
corresponding interest.
Manifests are network-level structures used to convey ContentIds to
consumers so that they may request nameless content objects. These
are necessary since a consumer cannot know the ContentId of a
nameless content object which it has not yet retrieved. Manifests
are typically used to group segments of a single, large piece of data
under a common name. For example, imagine the consumer wishes to
obtain the data named /foo/bar, which has a total size well beyond
the 64KiB limit imposed by the CCN packet format. To transfer /foo/
bar efficiently, the producer segments the /foo/bar data into fixed
size chunks and, for each chunk, creates a nameless content object.
Wood Expires September 14, 2017 [Page 2]
Internet-Draft CCNxCLEAN March 2017
Then, the producer creates a Manifest with the name /foo/bar which
contains the references to each of these constituent nameless object
parts, along with their ContentIds. To fetch /foo/bar, a consumer
then (a) issues a request for the name /foo/bar, (b) receives,
verifies, and parses the Manifest, and (c) subsequently issues
requests for each nameless content object using the provided
ContentIds. (See [CCNxSemantics] for more details.) The [FLIC] data
structure is one type of CCN Manifest data structure used to enable
this mechanism.
By default, the data contained inside each nameless content object is
unencrypted. If privacy is required, the producer application must
explicitly encrypt the data prior to transfer. This is not ideal
since it requires application-layer input. To improve this baseline
scenario, we introduce CCNx CLEAN - content-locked encryption and
authentication of nameless objects. CLEAN builds on recent advances
in message-locked encryption ([MLE]) to encrypt nameless objects by
default without invalidating their natural de-duplication properties.
1.1. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119].
The following terms are used:
Nameless object: A CCN content object packet which contain a Name TLV
field.
2. CLEAN Crypto
CLEAN only relies on MLE, which is a form of encryption by which the
encryption key for a message is derived from the message itself. For
example, in MLE, a message M may be encrypted by a key K = H(M),
where H is a suitable cryptographic hash function for use in MLE
constructions. The encryption of M is thus computed as M' =
Enc(H(M), M), where Enc is a symmetric-key encryption algorithm
suitable for MLE. This procedure is deterministic; two identical
messages will be encrypted to identical ciphertext values. As a
result, MLE supports natural de-duplication of data based on
ciphertext equality.
Wood Expires September 14, 2017 [Page 3]
Internet-Draft CCNxCLEAN March 2017
3. CLEAN End Host Support
Let D be a piece of data for which a producer P would normally create
a Manifest with name N, i.e., M(N). Let C_1,...,C_n be the n
nameless content object _payloads_ created from D. The CLEAN
construction works as follows:
1. P computes k = KDF(H(D)), where KDF is a suitable key derivation
function, such as HKDF [RFC5869].
2. For each C_i in C_1,...,C_n, P derives k_i = KDF(k + i) uses it
to compute C_i' = Enc(k, C_i), where '+' is concatenation.
3. From C_1',...,C_n', P creates the manifest M(N) as per the [FLIC]
specification.
4. P inserts H(D) into the root node of M(N). (This is described in
the following section.)
When complete, P publishes the manifest tree M(N) and its constituent
nameless object pieces.
4. FLIC Support
The [FLIC] format already includes the metadata value
OverallDataDigest. For a given FLIC node F_i, this value corresponds
to H(D_i), where D_i is the array of application data in the nameless
content objects _contained in_ F_i. If F is the root of M(N), then
H(D) is the hash of complete set of application data in the manifest.
Therefore, CLEAN does not require any changes in the FLIC format.
5. Use Cases
Since the data digest (i.e., H(D)) is contained in the root manifest,
the privacy of nameless content objects reduces to that of the root
manifest. This has the following benefits:
1. If access control to D is needed, P need only apply the necessary
access control scheme to the root manifest so that H(D) is not
leaked. This permits the encrypted nameless object leaves to be
de-duplicated naturally in the network.
2. If D is public data that a consumer Cr wishes to retrieve
privately, the root manifest can be requested over a secure,
ephemeral session between Cr and P. One way to establish such a
channel is with [CCNxKE]. Of course, if D is public, then any
malicious consumer Adv may follow this approach to obtain D and
decrypt nameless objects, or learn what data was requested by
Wood Expires September 14, 2017 [Page 4]
Internet-Draft CCNxCLEAN March 2017
other consumers. However, Adv is forced to guess which name N
was requested to be successful in either attack.
In both cases, the nameless content objects that carry segments of D
remain protected without applying any type of encryption-based access
control to them individually.
6. Security Considerations
The CLEAN security model depends on the root manifest being protected
either at rest or, optionally, in transit. If the root is protected
at rest via some access control mechanism, then CLEAN remains secure
in the MLE model. MLE security also holds if the root is encrypted
only in transit over a secure session.
7. Normative References
[CCNxKE] Marc Mosko, ., Ersin Uzun, ., and Christopher. Wood, "CCNx
Key Exchange Protocol Version 1.0", n.d.,
.
[CCNxSemantics]
Mosko, M., Solis, I., and C. Wood, "CCNx Semantics", n.d.,
.
[FLIC] Christian Tschudin, . and Christopher. Wood, "File-Like
ICN Collection (FLIC)", n.d.,
.
[MLE] Mihir Bellare, ., Sriram Keelveedhi, ., and . Thomas
Ristenpart, "Message-locked encryption and secure
deduplication", n.d.,
.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
.
Wood Expires September 14, 2017 [Page 5]
Internet-Draft CCNxCLEAN March 2017
Author's Address
Christopher A. Wood
University of California Irvine
EMail: woodc1@uci.edu
Wood Expires September 14, 2017 [Page 6]