End-to-end Encrypted Scalable Abstract Data Types over ICN Christian Tschudin University of Basel, Switzerland [email protected] ABSTRACT Application-level ICN. Symphony’s system is currently based In Information Centric Networking (ICN), data items are made on standard cloud technologies like Hadoop, MongoDB, PubNub, 2 accessible through their name rather than their storage location. Kafka and many more. My view was that Symphony’s use case We extend this storage abstraction and complement it via a name would best be handled by an “application-level ICN” approach: Chat lookup service for retrieving the latest version of a name binding in messages become immutable encrypted named data; chat rooms are order to implement abstract data types (ADT), specifically “append- ordered collections of such objects and must, for audit trail purposes, only logs” and “mutable key-value stores”. Moreover, we make these have an immutable history; finally the ICN repos in the cloud serve data types scalable by choosing implementation techniques known as an append-only store for all immutable content. as CRDTs (conflict-free replicated data types) and we use end-to- Such a re-architecting is not easy to retrofit to a running system, end encryption for protecting the content and structure against but Symphony has started to adopt portions of this new “Sym- untrusted storage providers and forwarding elements. In this paper phony 2.0” architecture when need for replacement or opportuni- we describe our architecture, the interface to the ADTs and report ties showed up. In this paper I report on an independent proof of on a prototype implementation for the cloud that is inspired by a concept that was written in Python and that demonstrates Sym- 3 real Fintech use case. phony’s use case as an application running over an extended ICN . Many additional services that are part of Symphony’s offerings are CCS CONCEPTS not covered by this PoC like e.g. information barriers, encrypted search, entitlement and access control systems, or the web browser- • Networks → Programming interfaces; Cloud computing; • and smartphone-based client apps. Software and its engineering → Abstract data types; • Security and privacy → Management and querying of encrypted data; • The Network becomes the Database. In the new architecture Information systems → Hashed file organization; there is no need for stand-alone database servers: Instead, all digital assets are handled as “linked encrypted data” accessed via a flat ACM Reference Format: namespace from an Information Centric Network (in this work, we Christian Tschudin. 2018. End-to-end Encrypted Scalable Abstract Data Types over ICN. In 5th ACM Conference on Information-Centric Networking focus on ICN as represented by NDN [37], CCNx [14] or CICN [16]). (ICN ’18), September 21–23, 2018, Boston, MA, USA. ACM, New York, NY, A chat message is referenced by its self-certifying name (the hash of USA, 7 pages. https://doi.org/10.1145/3267955.3267962 its binary representation), while a collection of chat messages, i.e. a chat room, is a linked list of such hash names, and the room’s state 1 INTRODUCTION being represented by the most recently added chat message. Chat messages are immutable, hence their name never changes. But chat This work is inspired by a use case of Symphony Communication rooms have dynamic content, hence a name derived from a binary 1 Services LLC , a high-growth technology company in Palo Alto representation of the latest chat message not sufficient. This is that provides secure collaboration for financial services and other solved by creating a permanent “base name” from the empty room, security-sensitive industries. Symphony operates a cloud-based to use this as durable reference for a chat room, and to provide a infrastructure that enables companies to outsource their chat mes- lookup service for getting hold of the latest version’s name based saging in a secure and regulatory-compliant way: Messages are en- on the base name. In our prototype we call this lookup the HEAD and decrypted on end-devices only, using a user key and company- service, while we call ICN’s storage for immutable content the specific escrow keys. Symphony never sees clear-text messages WORM service (write-once-read-many). Similar to GitHub’s role as and, should law enforcement agency determine a need to obtain a version directory [10], or IOTA’s “set of tip nodes” which is also the customer’s messages, must (and could only) hand over the set called “edge set” [21], the HEAD service documents the dynamic of encrypted messages, while the agency will need to obtain the frontier of the append-only WORM. keys from the customer or its third-party key custodian directly. ICN and a Service Architecture for ADTs 1https://en.wikipedia.org/wiki/Symphony_Communication A canonical ICN network à la NDN or CCNx provides a single ser- vice called read(). Our position is that the ICN layer must present Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed itself as much richer than a mere data packet delivery service: The for profit or commercial advantage and that copies bear this notice and the full citation Information-Centric Network has to become “the” database and on the first page. Copyrights for third-party components of this work must be honored. For all other uses, contact the owner/author(s). 2During an industrial leave at Symphony I was part of an architecture team that looked ICN ’18, September 21–23, 2018, Boston, MA, USA into re-designing Symphony’s system. © 2018 Copyright held by the owner/author(s). 3 The mapping of Symphony’s use case to ICN concepts, as well as the techniques ACM ISBN 978-1-4503-5959-7/18/09. presented in this paper, do not necessarily reflect Symphony’s views but rather my https://doi.org/10.1145/3267955.3267962 own. ICN ’18, September 21–23, 2018, Boston, MA, USA Christian Tschudin a platform, potentially cloud-based, for services that refine this database’ content. A first step consists in complementing the cur- distributed applications rent “READ” primitive (implemented with Interest/Data messages) ADT API with (a) a “WRITE” primitive on equal footing (WORM service), (b) data encryption Remote Procedure Call support (RPC) as integral part of ICN, (c) structure ADT with CRDT a name translation service for updating and disseminating latest encryption version information (HEAD service), and finally (d) libraries that ICN API turn these base services into high-level abstract data types which HEAD WORM (ICN) hide the tedious details of implementing them with scaling and encryption in mind (see Figure 1). In Section 2, we first point to the many domains (in distributed Figure 1: A software stack for implementing scalable ADTs systems) that are relevant to this paper and single out CRDTs over HEAD and WORM services. (Conflict-Free Replicated Data Types) in Section 3. Section 4de- scribes our service architecture while Section 5 shows code excerpts of two demo applications (chat and DropBox replacement). distributed applications these are extremely valuable high-level services, but (unlike the ICN flavor of PubSub) they need an active 2 RELATED WORK element in the cloud which can persist items with strong guarantees like “exactly-once” semantics (while the ICN pubsub typically is In this Section we review technologies that relate to this work and best effort): Having “published” an items means that responsibility which mostly stem from the domain of distributed systems (rather of delivery has fully passed to the service provider, although there than networking) For each domain we highlight the problems (with might be limits for how long an item is stored (e.g., up to four days). regard to the use of an ICN network) that the corresponding con- In this paper we study another coupling of the distributed elements, cepts address. The CRDT topic is handled in an independent Section specifically a HEAD name service similar to what GitHub provides. directly afterwards. 2.3 Append-only (and Log-Structured) Storage 2.1 ICN APIs beyond interest/data messaging ICN so far is very much focused on single name-data chunks Several attempts have been made for wrapping the Interest/Data rather than how multiple chunks are actually persisted, both at messaging into more conveniently usable primitives, the motiva- the retrieving end (in a repo) or on the writing side – which is tion being that for example “reliable and secure application-level relevant for performance and for data consistency reasons. In op- message exchange” or “file replication” are the relevant services in erating systems, append-only data structures are a well known which application developers are interested in. Support for Pro- concept and have been implemented multiple times, for exam- ducer/Consumer communication has been the focus of several ple in the venti file system [24] of Plan9. Log-structured file sys- authors (Moiseenko [13], PARC’s CCNx 1.0 lib and now CICN tems [26] also operate along this line and have become an impor- sockets [16]). ChronoSync [39] can be seen as way to automatically tant part in highly reliable systems and consensus services like e.g. replicate hierarchically organized data over ICN. The focus of these RAFT [20]. Blockchains [17] (and distributed ledgers in general) efforts is on the data itself and but not on a well-defined setof also are append-only data structures, but come with extreme as- manipulation procedures. For example, ChronoSync implements sumptions regarding the open set of “contributors” to these data “set reconciliation” but does not offer a set data type where one can structures, involving proof-of-work or similar to prevent malicious easily add elements, test for presence, or compute the difference actors to rewrite the stored content.