JEDI: Many-to-Many End-to-End Encryption and Key Delegation for IoT

by   Sam Kumar, et al.

As the Internet of Things (IoT) emerges over the next decade, developing secure communication for IoT devices is of paramount importance. Achieving end-to-end encryption for large-scale IoT systems, like smart buildings or smart cities, is challenging because multiple principals typically interact indirectly via intermediaries, meaning that the recipient of a message is not known in advance. This paper proposes JEDI (Joining Encryption and Delegation for IoT), a many-to-many end-to-end encryption protocol for IoT. JEDI encrypts and signs messages end-to-end, while conforming to the decoupled communication model typical of IoT systems. JEDI's keys support expiry and fine-grained access to data, common in IoT. Furthermore, JEDI allows principals to delegate their keys, restricted in expiry or scope, to other principals, thereby granting access to data and managing access control in a scalable, distributed way. Through careful protocol design and implementation, JEDI can run across the spectrum of IoT devices, including ultra low-power deeply embedded sensors severely constrained in CPU, memory, and energy consumption. We apply JEDI to an existing IoT messaging system and demonstrate that its overhead is modest.



There are no comments yet.


page 1

page 2

page 3

page 4


A Federated Capability-based Access Control Mechanism for Internet of Things (IoTs)

The prevalence of Internet of Things (IoTs) allows heterogeneous embedde...

Graph Layer Security: Encrypting Information via Common Networked Physics

The proliferation of low cost Internet of Things (IoT) devices demands n...

ABE-Cities: An Attribute-Based Encryption System for Smart Cities

In the near future, a technological revolution will involve our cities, ...

Increasing negotiation performance at the edge of the network

Automated negotiation has been used in a variety of distributed settings...

The Cost of OSCORE and EDHOC for Constrained Devices

Many modern IoT applications rely on the Constrained Application Protoco...

Pyronia: Intra-Process Access Control for IoT Applications

Third-party code plays a critical role in IoT applications, which genera...

SEA-BREW: A Scalable Attribute-Based Encryption Scheme for Low-Bitrate IoT Wireless Networks

Attribute-Based Encryption (ABE) is an emerging cryptographic technique ...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

As the Internet of Things (IoT) has emerged over the past decade, smart devices have become increasingly common. This trend is only expected to continue, with tens of billions of new IoT devices deployed over the next few years [33]. The IoT vision requires these devices to communicate to discover and use the resources and data provided by one another. Yet, these devices collect privacy-sensitive information about users. A natural step to secure privacy-sensitive data is to use end-to-end encryption to protect it during transit.

Existing protocols for end-to-end encryption, such as SSL/TLS and TextSecure [47], focus on one-to-one communication between two principals: for example, Alice sends a message to Bob over an insecure channel. Such protocols, however, appear not to be a good fit for large-scale industrial IoT systems. Such IoT systems demand many-to-many communication among decoupled senders and receivers, and require decentralized delegation of access to enforce which devices can communicate with which others.

We investigate existing IoT systems, which currently do not encrypt data end-to-end, to understand the requirements on an end-to-end encryption protocol like JEDI. We use smart cities as an example application area, and data-collecting sensors in a large organization as a concrete use case. We identify three central requirements, which we treat in turn below:

Decoupled senders and receivers. IoT-scale systems could consist of thousands of principals, making it infeasible for consumers of data (e.g., applications) to maintain a separate session with each producer of data (e.g., sensors). Instead, senders are typically decoupled from receivers. Such decoupling is common in publish-subscribe systems for IoT, such as MQTT, AMQP, XMPP, and Solace [81]. In particular, many-to-many communication based on publish-subscribe is the de-facto standard in smart buildings, used in systems like BOSS [39], VOLTTRON [87], Brume [70] and bw2 [5], and adopted commercially in AllJoyn and IoTivity. Senders publish messages by addressing them to resources and sending them to a router. Recipients subscribe to a resource by asking the router to send them messages addressed to that resource.

Many systems for smart buildings/cities, like sMAP [38], SensorAct [7], bw2 [5], VOLTTRON [87], and BAS [61], organize resources as a hierarchy. A resource hierarchy matches the organization of IoT devices: for instance, smart cities contain buildings, which contain floors, which contain rooms, which contain sensors, which produce streams of readings. We represent each resource—a leaf in the hierarchy—as a Uniform Resource Indicator (URI), which is like a file path. For example, a sensor that measures temperature and humidity might send its readings to the two URIs buildingA/floor2/roomLHall/sensor0/temp and buildingA/floor2/roomLHall/sensor0/hum. A user can subscribe to a URI prefix, such as buildingA/floor2/roomLHall/*, which represents a subtree of the hierarchy. He would then receive all sensor readings in room “LHall.”

Figure 1:

IoT comprises a diverse set of devices, which span more than four orders of magnitude of computing power (estimated in Dhrystone MIPS).

222Image credits:,,,

Decentralized delegation. Access control in IoT needs to be fine-grained. For example, if Bob has an app that needs access to temperature readings from a single sensor, that app should receive the decryption key for only that one URI, even if Bob has keys for the entire room. In an IoT-scale system, it is not scalable for a central authority to individually give fine-grained decryption keys to each person’s devices. Moreover, as we discuss in §2, such an approach would pose increased security and privacy risks. Instead, Bob, who himself has access to readings for the entire room, should be able to delegate temperature-readings access to the app. Generally, a principal with access to a set of resources can give another principal access to a subset of those resources.

Vanadium [82] and bw2 [5] introduced decentralized delegation (SPKI/SDSI [34] and Macaroons [14]) in the smart buildings space. Since then, decentralized delegation has become the state-of-the-art for access control in smart buildings, especially those geared toward large-scale commercial buildings or organizations [45, 55]. In these systems, a principal can access a resource if there exists a chain of delegations, from the owner of the resource to that principal, granting access. At each link in the chain, the extent of access may be qualified by caveats, which add restrictions to which resources can be accessed and when. While these systems provide delegation of permissions, they do not provide protocols for encrypting and decrypting messages end-to-end.

Resource constraints. IoT devices vary greatly in their capabilities, as shown in Fig. 1. This includes devices constrained in CPU, memory, and energy, such as wearable devices and low-cost environmental sensors.

In smart buildings/cities, one application of interest is indoor environmental sensing. Sensors that measure temperature, humidity, or occupancy may be deployed in a building; such sensors are battery-powered and transmit readings using a low-power wireless network. To see ubiquitous deployment, they must cost only tens of dollars per unit and have several years of battery life. To achieve this price/power point, sensor platforms are heavily resource-constrained, with mere kilobytes of memory (farthest right in Fig. 1[52, 74, 44, 63, 27, 4, 3]. The power consumption of encryption is a serious challenge, even more so than its latency on a slower CPU; the CPU and radio must be used sparingly to avoid consuming energy too quickly [94, 59]. For example, on the sensor platform used in our evaluation, an average CPU utilization of merely 5% would result in less than a year of battery life, even if the power cost of using the transducers and network were zero.

Figure 2: JEDI keys can be qualified and delegated, supporting decentralized, cryptographically-enforced access control via key delegation. Each person has a decryption key for the indicated resource subtree that is valid until the indicated expiry time. Black arrows denote delegation.

1.1 Overview of JEDI

This paper presents JEDI, a many-to-many end-to-end encryption protocol compatible with the above three requirements of IoT systems. JEDI encrypts messages end-to-end for confidentiality, signs them for integrity while preserving anonymity, and supports delegation with caveats, all while allowing senders and receivers to be decoupled via a resource hierarchy. JEDI differs from existing encryption protocols like SSL/TLS, requiring us to overcome a number of challenges:

  1. [leftmargin=*,topsep=0mm,noitemsep]

  2. Formulating a new system model for end-to-end encryption to support decoupled senders and receivers and decentralized delegation typical of IoT systems (§1.1.1)

  3. Realizing this expressive model while working within the resource constraints of IoT devices (§1.1.2)

  4. Allowing receivers to verify the integrity of messages, while preserving the anonymity of senders (§1.1.3)

  5. Extending JEDI’s model to support revocation (§1.1.4)

Below, we explain how we address each of these challenges.

1.1.1 JEDI’s System Model (§2)

Participants in JEDI are called principals. Any principal can create a resource hierarchy to represent some resources that it owns. Because that principal owns all of the resources in the hierarchy, it is called the authority of that hierarchy.

Due to the setting of decoupled senders and receivers, the sender can no longer encrypt messages with the receiver’s public key, as in traditional end-to-end encryption. Instead, JEDI models principals as interacting with resources, rather than with other principals. Herein lies the key difference between JEDI’s model and other end-to-end encryption protocols: the publisher of a message encrypts it according to the URI to which it is published, not the recipients subscribed to that URI. Only principals permitted to subscribe to a URI are given keys that can decrypt messages published to that URI.

IoT systems that support decentralized delegation (Vanadium, bw2), as well as related non-IoT authorization systems (e.g., SPKI/SDSI [34] and Macaroons [14]) provide principals with tokens (e.g., certificate chains) that they can present to prove they have access to a certain resource. Providing tokens, however, is not enough for end-to-end encryption; unlike these systems, JEDI allows decryption keys to be distributed via chains of delegations. Furthermore, the URI prefix and expiry time associated with each JEDI key can be restricted at each delegation. For example, as shown in Fig. 2, suppose Alice, who works in a research lab, needs access to sensor readings in her office. In the past, the campus facilities manager, who is the authority for the hierarchy, granted a key for buildingA/* to the building manager, who granted a key for buildingA/floor2/* to the lab director. Now, Alice can obtain the key for buildingA/floor2/alice_office/* directly from her local authority (the lab director).

1.1.2 Encryption with URIs and Expiry (§3)

JEDI supports decoupled communication. The resource to which a message is published acts as a rendezvous point between the senders and receivers, used by the underlying system to route messages. Central to JEDI is the challenge of finding an analogous cryptographic rendezvous point that senders can use to encrypt messages without knowledge of receivers. A number of IoT systems [79, 75] use only simple cryptography like AES, SHA2, and ECDSA, but these primitives are not expressive enough to encode JEDI’s rendezvous point, which must support hierarchically-structured resources, non-interactive expiry, and decentralized delegation.

Existing systems [88, 89, 90] with similar expressivity to JEDI use Attribute-Based Encryption (ABE) [51, 13]. Unfortunately, ABE is not suitable for JEDI because it is too expensive, especially in the context of resource constraints of IoT devices. Some IoT systems rule it out due to its latency alone [79]. In the context of low-power devices, encryption with ABE would also consume too much power. JEDI circumvents the problem of using ABE or basic cryptography with two insights: (1) Even though ABE is too heavy for low-power devices, this does not mean that we must resort to only symmetric-key techniques. We show that certain IBE schemes [1] can be made practical for such devices. (2) Time is another resource hierarchy: a timestamp can be expressed as year/month/day/hour, and in this hierarchical representation, any time range can be represented efficiently as a logarithmic number of subtrees. With this insight, we can simultaneously support URIs and expiry via a nonstandard use of a certain type of IBE scheme: WKD-IBE [1]. Like ABE, WKD-IBE is based on bilinear groups (pairings), but it is an order-of-magnitude less expensive than ABE as used in JEDI. To make JEDI practical on low-power devices, we design it to invoke WKD-IBE rarely, while relying on AES most of the time, much like session keys. Thus, JEDI achieves expressivity commensurate to IoT systems that do not encrypt data—significantly more expressive than AES-only solutions—while allowing several years of battery life for low-power low-cost IoT devices.

1.1.3 Integrity and Anonymity (§4)

In addition to being encrypted, messages should be signed so that the recipient of a message can be sure it was not sent by an attacker. This can be achieved via a certificate chain, as in SPKI/SDSI or bw2. Certificates can be distributed in a decentralized manner, just like encryption keys in Fig. 2.

Certificate chains, however, are insufficient if anonymity is required. For example, consider an office space with an occupancy sensor in each office, each publishing to the same URI buildingA/occupancy. In aggregate, the occupancy sensors could be useful to inform, e.g., heating/cooling in the building, but individually, the readings for each room could be considered privacy-sensitive. The occupancy sensors in different rooms could use different certificate chains, if they were authorized/installed by different people. This could be used to deanonymize occupancy readings. To address this challenge, we adapt the WKD-IBE scheme that we use for end-to-end encryption to achieve an anonymous signature scheme that can encode the URI and expiry and support decentralized delegation. Using this technique, anonymous signatures are practical even on low-power embedded IoT devices.

1.1.4 Revocation (§5)

As stated above, JEDI keys support expiry. Therefore, it is possible to achieve a lightweight revocation scheme by delegating each key with short expiry and periodically renewing it to extend the expiry. To revoke a key, one simply does not renew it. We expect this expiry-based revocation to be sufficient for most use cases, especially for low-power devices, which typically just “sense and send.”

Enforcing revocation cryptographically, without relying on expiration, is challenging. As we discuss in §5, any cryptographically-enforced scheme that provides immediate revocation (i.e., keys can be revoked without waiting for them to expire) is subject to the fundamental limitation that the sender of a message must know which recipients are revoked when it encrypts the message. JEDI provides a form of immediate revocation, subject to this constraint. We use techniques from tree-based broadcast encryption [72, 40] to encrypt in such a way that all decryption keys for that URI, except for ones on a revocation list, can be used to decrypt. Achieving this is nontrivial because we have to combine broadcast encryption with JEDI’s semantics of hierarchical resources, expiry, and delegation. First, we modify broadcast encryption to support delegation, in such a way that if a key is revoked, all delegations made with that key are also implicitly revoked. Then, we integrate broadcast revocation, in a non-black-box way, with JEDI’s encryption and delegation, as a third resource hierarchy alongside URIs and expiry.

1.2 Summary of Evaluation

For our evaluation, we use JEDI to encrypt messages transmitted over bw2 [5, 28], a deployed open-source messaging system for smart buildings, and demonstrate that JEDI’s overhead is small in the critical path. We also evaluate JEDI for a commercially available sensor platform called “Hamilton” [52], and show that a Hamilton-based sensor sending one sensor reading every 30 seconds would see several years of battery lifetime when sending sensor readings encrypted with JEDI. As Hamilton is among the least powerful platforms that will participate in IoT (farthest to the right in Fig. 1), this validates that JEDI is practical across the IoT spectrum.

2 JEDI’s Model and Threat Model

A principal can post a message to a resource in a hierarchy by encrypting it according to the resource’s URI, hierarchy’s public parameters, and current time, and passing it to the underlying system that delivers it to the relevant subscribers. Given the secret key for a resource subtree and time range, a principal can generate a secret key for a subset of those resources and subrange of that time range, and give it to another principal, as in Fig. 2. The receiving principal can use the delegated key to decrypt messages that are posted to a resource in that subset at a time during that subrange.

JEDI does not require the structure of the resource hierarchy to be fixed in advance. In Fig. 2, the campus facilities manager, when granting access to buildingA/* to the building manager, need not be concerned with the structure of the subtree rooted at buildingA. This allows the building manager to organize buildingA/* independently.

2.1 Trust Assumptions

A principal is trusted for the resources it owns or was given access to (for the time ranges for which it was given access). In other words, an adversary who compromises a principal can read all resources that principal can read and forge new messages as if it were that principal. In particular, an adversary who compromises the authority for a resource hierarchy gains control over that resource hierarchy.

JEDI allows each principal to act as an authority for its own resource hierarchy in its own trust domain, without a single authority spanning all hierarchies. In particular, principals are not organized hierarchically; a principal may be delegated multiple keys, each belonging to a different resource hierarchy. In the example in Fig. 2, Alice might also receive JEDI keys from her landlord granting access to resources in her apartment building, in a separate hierarchy where her landlord is the authority. If Alice owns resources she would like to delegate to others, she can set up her own hierarchy to represent those resources. Existing IoT systems with decentralized delegation, like bw2 and Vanadium, use a similar model.

Figure 3: Applying JEDI to a smart buildings IoT system. Components introduced by JEDI are shaded. The subscriber’s key is obtained via JEDI’s decentralized delegation (Fig. 2).

2.2 Applying JEDI to an Existing System

As shown in Fig. 3, JEDI can be applied as a wrapper around existing many-to-many communication systems, including publish-subscribe systems for smart cities. The transfer of messages from producers to consumers is handled by the existing system. A common design used by such systems is to have a central broker (or router) forward messages; however, an adversary who compromises the broker can read all messages. In this context, JEDI’s end-to-end encryption protects data from such an adversary. Publishers encrypt their messages with JEDI before passing them to the underlying communication system (without knowledge of who the subscribers are), and subscribers decrypt them with JEDI after receiving them from the underlying communication system (without knowledge of who the publishers are).

2.3 Comparison to a Naïve Key Server Model

To better understand the benefits of JEDI’s model, consider the natural strawman of a trusted key server. This key server generates a key for every URI and time. A publisher encrypts each message for that URI with the same key. A subscriber requests this key from the trusted key server, which must first check if the subscriber is authorized to receive it. The subscriber can decrypt messages for a URI using this key, and contact the key server for a new key when the key expires. JEDI’s model is better than this key server model as follows:

  • [itemsep=0mm,leftmargin=*,topsep=0ex,noitemsep]

  • Improved security. Unlike the trusted key server, which must always be online, the authority in JEDI can delegate qualified keys to some principals and then go offline, leaving these principals to qualify and delegate keys further. While the authority is offline, it is more difficult for an attacker to compromise it and easier for the authority to protect its secrets because it need only access them rarely. This reasoning is the basis of root Certificate Authorities (CAs), which access their master keys infrequently. In contrast, the trusted key server model requires a central trusted party (key server) to be online to grant/revoke access to any resource.

  • Improved privacy. No single participant sees all delegations in JEDI. An adversary in JEDI who steals an authority’s secret key can decrypt all messages for that hierarchy, but still does not learn who has access to which resource, and cannot access separate hierarchies to which the first authority has no access. In contrast, an adversary who compromises the key server learns who has access to which resource and can decrypt messages for all hierarchies.

  • Improved scalability. In the campus IoT example above, if a building admin receives access to all sensors and all their different readings for a building, the admin must obtain a potentially very large number of keys, instead of one key for the entire building. Moreover, the campus-wide key server needs to grant decryption keys to each application owned by each employee or student at the university. Finally, the campus-wide key server must understand which delegations are allowed at lower levels in the hierarchy, requiring the entire hierarchy to be centrally administered.

2.4 IoT Gateways

Low-power wireless embedded sensors, due to power constraints, often do not use network protocols like Wi-Fi, and instead use specialized low-power protocols such as Bluetooth or IEEE 802.15.4. It is common for these devices to rely on an application-layer gateway to send data to computers outside of the low-power network [96]. This gateway could be in the form of a phone app (e.g., Fitbit), or in the form of a specialized border router [97, 26]. In some traditional setups, the gateway is responsible for performing encryption/authentication [75]. JEDI accepts that gateways may be necessary for Internet connectivity, but does not rely on them for security—JEDI’s cryptography is lightweight enough to run directly on the low-power sensor nodes. This approach prevents the gateway from becoming a single point of attack; an attacker who compromises the gateway cannot see or forge data for any device using that gateway.

2.5 Generalizability of JEDI’s Model

Since JEDI decouples senders from receivers, it has no requirements on what happens at any intermediaries (e.g., does not require messages to be forwarded from publishers to subscribers in any particular way). Thus, JEDI works even when messages are exchanged in a broadcast medium, e.g., multicast. This also means that JEDI is more broadly applicable to systems with hierarchically organized resources. For example, URIs could correspond to filepaths in a file system, or URLs in a RESTful web service.

2.6 Security Goals

JEDI’s goal is to ensure that principals can only read messages from or send messages to resources they have been granted access to receive from or send to. In the context of publish-subscribe, JEDI also hides the content of messages from an adversary who controls the router.

JEDI does not attempt to hide metadata relating to the actual transfer of messages (e.g., the URIs on which messages are published, which principals are publishing or subscribing to which resources, and timing). Hiding this metadata is a complementary task to achieving delegation and end-to-end encryption in JEDI, and techniques from the secure messaging literature [31, 35, 86] will likely be applicable.

3 End-to-End Encryption in JEDI

A central question answered in this section is: How should publishers encrypt messages before passing them to the underlying system for delivery (§3.4)? As explained in §1.1.2, although ABE, the obvious choice, is too heavy for low-power devices, we identify WKD-IBE, a more lightweight identity-based encryption scheme, as sufficient to achieve JEDI’s properties. The primary challenge is to encode a sufficiently expressive rendezvous point in the WKD-IBE ID (called a pattern) that publishers use to encrypt messages (§3.4).

3.1 Building Block: WKD-IBE

We first explain WKD-IBE [1], the encryption scheme that JEDI uses as a building block. Throughout this paper, we denote the security parameter as .

In WKD-IBE, messages are encrypted with patterns, and keys also correspond to patterns. A pattern is a list of values: . The notation denotes the th component of , 1-indexed. A pattern matches a pattern if, for all , either or . In other words, if specifies a value for an index , must match it at . Note that the “matches” operation is not commutative; “ matches ” does not imply “ matches ”.

We refer to a component of a pattern containing an element of as fixed, and to a component that contains as free. To aid our presentation, we define the following sets:

Definition 1.

For a pattern , we define:

A key for pattern can decrypt a message encrypted with pattern if . Furthermore, a key for pattern can be used to derive a key for pattern , as long as matches . In summary, the following is the syntax for WKD-IBE.

  • [itemsep=0mm,leftmargin=*,topsep=0.4ex]

  • ;

  • , derives a key for , where either is the , or matches ;

  • ;

  • .

We use the WKD-IBE construction in §3.2 of [1], based on BBG HIBE [18]. Like the BBG construction, it has constant-size ciphertexts, but requires the maximum pattern length to be known at Setup time. In this WKD-IBE construction, patterns containing can only be used in , not in ; we extend it to support encryption with patterns containing . We include the WKD-IBE construction with our optimizations in Appendix A.

3.2 Concurrent Hierarchies in JEDI

WKD-IBE was originally designed to allow delegation in a single hierarchy. For example, the original suggested use case of WKD-IBE was to generate secret keys for a user’s email addresses in all valid subdomains, such as sysadmin@* [1].

JEDI, however, uses WKD-IBE in a nonstandard way to simultaneously support multiple hierarchies, one for URIs and one for expiry (and later in §5, one for revocation), each in the vein of HIBE. We think of the components of a WKD-IBE pattern as “slots” that are initially empty, and are progressively filled in with calls to . To combine a hierarchy of maximum depth (e.g., the URI hierarchy) and a hierarchy of maximum depth (e.g., the expiry hierarchy), one can WKD-IBE with the number of slots equal to . The first slots are filled in left-to-right for the first hierarchy and the remaining slots are filled in left-to-right for the second hierarchy (Fig. 4).

3.3 Overview of Encryption in JEDI

Each principal maintains a key store containing WKD-IBE decryption keys. To create a resource hierarchy, any principal can call the WKD-IBE function to create a resource hierarchy. It releases the public parameters and stores the master secret key in its key store, making it the authority of that hierarchy. To delegate access to a URI prefix for a time range, a principal (possibly the authority) searches its key store for a set of keys for a superset of those permissions. It then qualifies those keys using to restrict them to the specific URI prefix and time range (§3.5), and sends the resulting keys to the recipient of the delegation.333JEDI does not govern how the key set is transferred to the recipient, as there are existing solutions for this. One can use an existing protocol for one-to-one communication (e.g., TLS) to securely transfer the key set. Or, one can encrypt the key set with the recipient’s (normal, non-WKD-IBE) public key, and place it in a common storage area. The recipient accepts the delegation by adding the keys to its key store.

Before sending a message to a URI, a principal encrypts the message using WKD-IBE. The pattern used to encrypt it is derived from the URI and the current time (§3.4), which are included along with the ciphertext. When a principal receives a message, it searches its key store, using the URI and time included with the ciphertext, for a key to decrypt it.

In summary, JEDI provides the following API:

Note that the WKD-IBE public parameters are an implicit argument to each of these functions. Finally, although the above API lists the arguments to as and , JEDI actually supports succinct delegation over more complex sets of URIs and timestamps (see §3.7).

3.4 Expressing URI/Time as a Pattern

A message is encrypted using a pattern derived from (1) the URI to which the message is addressed, and (2) the current time. Let be a collision-resistant hash function. Let be the pattern length in the hierarchy’s WKD-IBE system. We use the first slots to encode the URI, and the last slots to encode the time.

Given a URI of length , such as a/b/c ( in this example), we split it up into individual components, and append a special terminator symbol $: ("a", "b", "c", $). Using , we map each component to , and then put these values into the first slots. If is our pattern, we would have , , , and for this example. Now, we encode the time range into the remaining slots. Any timestamp, with the granularity of an hour, can be represented hierarchically as (year, month, day, hour). We encode this into the pattern like the URI: we hash each component, and assign them to consecutive slots. The final slots encode the time, so the depth of the time hierarchy is . The terminator symbol $ is not needed to encode the time, because timestamps always have exactly components. For example, suppose that a principal sends a message to a/b on June 8, 2017 at 6 AM. The message is encrypted with the pattern in Fig. 4.

Figure 4: Pattern used to encrypt message sent to a/b on June 08, 2017 at 6 AM. The figure uses 8 slots for space reasons; JEDI is meant to be used with more slots (e.g., 20).

3.5 Producing a Key Set for Delegation

Now, we explain how to produce a key set corresponding to a URI prefix and time range. To express a URI prefix as a pattern, we do the same thing as we did for URIs, without the terminator symbol $. For example, a/b/* is encoded in a pattern as , , and all other slots free. Given the private key for , one can use WKD-IBE’s to fill in slots . This allows one to generate the private key for a/b, a/b/c, etc.—any URI for which a/b is a prefix. To grant access to only a specific resource (a full URI, not a prefix), the $ is included as before.

In encoding a time range into a pattern, single timestamps (e.g., granting access for an hour) are done as before. The hierarchical structure for time makes it possible to succinctly grant permission for an entire day, month, or year. For example, one may grant access for all of 2017 by filling in slot with and leaving the final slots, which correspond to month, day, and year, free. Therefore, to grant permission over a time range, the number of keys granted is logarithmic in the length of the time range. For example, to delegate access to a URI from October 29, 2014 at 10 PM until December 2, 2014 at 1 AM, the following keys need to be generated: 2014/Oct/29/23, 2014/Oct/29/24, 2014/Oct/30/*, 2014/Oct/31/*, 2014/Nov/*, 2014/Dec/01/*, and 2014/Dec/02/01. The tree can be chosen differently to support longer time ranges (e.g., additional level representing decades), change the granularity of expiry (e.g., minutes instead of hours), trade off encryption time for key size (e.g., deeper/shallower tree), or use a more regular structure (e.g., binary encoding with logarithmic split). For example, our implementation uses a depth-6 tree (instead of depth-4), to be able to delegate time ranges with fewer keys.

In summary, to produce a key set for delegation, first determine which subtrees in the time hierarchy represent the time range. For each one, produce a separate pattern, and encode the time into the last slots. Encode the URI prefix in the first slots of each pattern. Finally, generate the keys corresponding to those patterns, using keys in the key store.

3.6 Optimizations for Low-Power Devices

On low-power embedded devices, performing a single WKD-IBE encryption consumes a significant amount of energy. Therefore, we design JEDI with optimizations to WKD-IBE.

3.6.1 Hybrid Encryption and Key Reuse

JEDI uses WKD-IBE in a hybrid encryption scheme. To encrypt a message in JEDI, one samples a symmetric key , and encrypts with JEDI to produce ciphertext . The pattern used for WKD-IBE encryption is chosen as in §3.4 to encode the rendezvous point. Then, one encrypts using to produce ciphertext . The JEDI ciphertext is .

For subsequent messages, one reuses and ; the new message is encrypted with to produce a new . One can keep reusing and until the WKD-IBE pattern for encryption changes, which happens at the end of each hour (or other interval used for expiry). At this time, JEDI performs key rotation by choosing a new , encrypting it with WKD-IBE using the new pattern, and then proceeding as before. Therefore, most messages only incur cheap symmetric-key encryption.

This also reduces the load on subscribers. The JEDI ciphertexts sent by a publisher during a single hour will all share the same . Therefore, the subscriber can decrypt once for the first message to obtain , and cache the mapping from to to avoid expensive WKD-IBE decryptions for future messages sent during that hour.

Thus, expensive WKD-IBE operations are only performed upon key rotation, which happens rarely—once an hour (or other granularity chosen for expiry) for each resource.

3.6.2 Precomputation with Adjustment

Even with hybrid encryption and key reuse to perform WKD-IBE encryption rarely, WKD-IBE contributes significantly to the overall power consumption on low-power devices. Therefore, this section explores how to perform individual WKD-IBE encryptions more efficiently.

Most of the work to encrypt under a pattern is in computing the quantity , where and the are part of the WKD-IBE public parameters. One may consider computing once, and then reusing its value when computing future encryptions under the same pattern . Unfortunately, this alone does not improve efficiency because the pattern used in one WKD-IBE encryption is different from the pattern used for the next encryption.

JEDI, however, observes that and are similar; they match in the slots corresponding to the URI, and the remaining slots will correspond to adjacent leaves in the time tree. JEDI takes advantage of this by efficiently adjusting the precomputed value to compute as follows:

This requires one exponentiation per differing slot between and (i.e., the Hamming distance). Because and usually differ in only the final slot of the time hierarchy, this will usually require one exponentiation total, substantially faster than computing from scratch. Additional exponentiations are needed at the end of each day, month, and year, but they can be eliminated by maintaining additional precomputed values corresponding to the start of the current day, current month, and current year.

The protocol remains secure because a ciphertext is distributed identically whether it was computed from a precomputed value or via regular encryption as in Appendix A.

3.7 Extensions

Via simple extensions, JEDI can support (1) wildcards in the middle of a URI or time, and (2) forward secrecy. We describe these extensions in Appendix F.

3.8 Security Guarantee (Proof in Appendix E)

We formalize the security of JEDI’s encryption below.

Theorem 1.

Suppose JEDI is instantiated with a Selective-ID CPA-secure [17, 1], history-independent (Appendix E) WKD-IBE scheme. Then, no probabilistic polynomial-time adversary can win the following security game against a challenger with non-negligible advantage:
Initialization. selects a (URI, time) pair to attack.
Setup. gives the public parameters of the JEDI instance.
Phase 1. can make three types of queries to :

  1. [topsep=0pt, noitemsep, wide, labelwidth=!, labelindent=0pt]

  2. asks to create a principal; returns a name in , which can use to refer to that principal in future queries. A special name exists for the authority.

  3. asks for the key set of any principal; gives the keys that the principal has. At the time this query is made, the requested key may not contain a key whose URI and time are both prefixes of the challenge (URI, time) pair.

  4. asks to make any principal delegate a key set of ’s choice to another principal (specified by names in ).

Challenge. When chooses to end Phase 1, it sends two messages, and , of the same length. Then chooses a random bit , encrypts under the challenge (URI, time) pair, and gives the ciphertext.
Phase 2. can make additional queries as in Phase 1.
Guess. outputs , and wins the game if . The advantage of an adversary is .

We prove this theorem in Appendix E. Although we only achieve selective security in the standard model (like much prior work [18, 1]), one can achieve adaptive security if the hash function in §3.5 is modeled as a random oracle [1]. It is sufficient for JEDI to use a CPA-secure (rather than CCA-secure) encryption scheme because JEDI messages are signed, as detailed below in §4.

4 Integrity in JEDI

To prevent an attacker from flooding the system with messages, spoofing fake data, or actuating devices without permission, JEDI must ensure that a principal can only send a message on a URI if it has permission. For example, an application subscribed to buildingA/floor2/roomLHall/sensor0/temp should be able to verify that the readings it is receiving are produced by sensor0, not an attacker. In addition to subscribers, an intermediate party (e.g., the router in a publish-subscribe system) may use this mechanism to filter out malicious traffic, without being trusted to read messages.

4.1 Starting Solution: Signature Chains

A standard solution in the existing literature, used by SPKI/SDSI [34], Vanadium [82], and bw2 [5], is to include a certificate chain with each message. Just as permission to subscribe to a resource is granted via a chain of delegations in §3, permission to publish to a resource is also granted via a chain of delegations. Whereas §3 includes WKD-IBE keys in each delegation, these integrity solutions delegate signed certificates. To send a message, a principal encrypts it (§3), signs the ciphertext, and includes a certificate chain that proves that the signing keypair is authorized for that URI and time.

4.2 Anonymous Signatures

The above solution reveals the sender’s identity (via its public key) and the particular chain of delegations that gives the sender access. For some applications this is acceptable, and its auditability may even be seen as a benefit. For other applications, the sender must be able to send a message anonymously. See §1.1.3 for an example. How can we reconcile access control (ensuring the sender has permission) and anonymity (hiding who the sender is)?

4.2.1 Starting Point: WKD-IBE Signatures

Our solution is to use a signature scheme based on WKD-IBE. Abdalla et al. [1] observe that WKD-IBE can be extended to a signature scheme in the same vein as has been done for IBE [19] and HIBE [49]. To sign a message with a key for pattern , one uses to fill in a slot with , and presents the decryption key as a signature.

This is our starting point for designing anonymous signatures in JEDI. A message can be signed by first hashing it to and signing the hash as above. Just as consumers receive decryption keys via a chain of delegations (§3), publishers of data receive these signing keys via chains of delegations.

4.2.2 Anonymous Signatures in JEDI

The construction in §4.2.1 has two shortcomings. First, signatures are large, linear in the number of fixed slots of the pattern. Second, it is unclear if they are truly anonymous.

Signature size. As explained in §3 and Appendix A, we use a construction of WKD-IBE based on BBG HIBE [18]. BBG HIBE supports a property called limited delegation in which a secret key can be reduced in size, in exchange for limiting the depth in the hierarchy at which subkeys can be generated from it. We observe that the WKD-IBE construction also supports this feature. Because we need not support for the decryption key acting as a signature, we use limited delegation to compress the signature to just two group elements.

Anonymity. The technique in §4.2.1 transforms an encryption scheme into a signature scheme, but the resulting signature scheme is not necessarily anonymous. For the particular construction of WKD-IBE that we use, however, we prove that the resulting signature scheme is indeed anonymous. Our insight is that, for this construction of WKD-IBE, keys are history-independent in the following sense: , for a fixed and , returns a private key with the exact same distribution regardless of (see §3.1 for notation). Because signatures, as described in §4.2.1, are private keys generated with , they are also history-independent; a signature for a pattern has the same distribution regardless of the key used to generate it. This is precisely the anonymity property we desire.

4.3 Optimizations for Low-Power Devices

As in §3.6.1, we must avoid computing a WKD-IBE signature for every message. A simple way to do this is to sample a digital signature keypair each hour, sign the verifying key with WKD-IBE at the beginning of the hour, and sign messages during the hour with the corresponding signing key.

Unfortunately, this may still be too expensive for low-power embedded devices because it requires a digital signature, which requires asymmetric-key cryptography, for every message. We can circumvent this by instead (1) choosing a symmetric key every hour, (2) signing at the start of each hour (using WKD-IBE for anonymity), and (3) using in an authenticated broadcast protocol to authenticate messages sent during the hour. An authenticated broadcast protocol, like µTESLA [75], generates a MAC for each message using a key whose hash is the previous key; thus, the single signed key allows the recipient to verify later messages, whose MACs are generated with hash preimages of . In general, this design requires stricter time synchronization than the one based on digital signatures, as the key used to generate the MAC depends on the time at which it is sent. However, for the sense-and-send use case typical of smart buildings, sensors anyway publish messages on a fixed schedule (e.g., one sample every seconds), allowing the key to depend only on the message index. Thus, timely message delivery is the only requirement. Our scheme differs from µTESLA because the first key (end of the hash chain) is signed using WKD-IBE.

Additionally, we use a technique similar to precomputation with adjustment (§3.6.2) for anonymous signatures. Conceptually, , which is used to produce signatures, can be understood as a two-step procedure: (1) produce a key of the correct form and structure (called ), and (2) re-randomize the key so that it can be safely delegated (called ). Re-randomization can be accelerated using the same precomputed value that JEDI uses for encryption (§3.6.2), which can be efficiently adjusted from one pattern to the next. The result of can also be adjusted to obtain the corresponding result for a similar pattern more efficiently. We fully explain our adjustment technique for signatures in Appendix A.3.

Finally, WKD-IBE signatures as originally proposed (§4.2.1) are verified by encrypting a random message under the pattern corresponding to the signature, and then attempting to decrypt it using the key acting as a signature. We provide a more efficient signature verification algorithm for this construction of WKD-IBE in Appendix A.

4.4 Security Guarantee (Proof in Appendix E)

The integrity guarantees of the method in this section can be formalized using a game very similar to the one in Theorem 1, so we do not present it here for brevity. We do, however, formalize the anonymous aspect of WKD-IBE signatures:

Theorem 2.

For any well-formed keys , corresponding to the same (URI, time) pair in the same resource hierarchy, and any message , the distribution of signatures over produced using is information-theoretically indistinguishable from (i.e., equal to) the distribution of signatures over produced using .

This implies that even a powerful adversary who observes the private keys held by all principals cannot distinguish signatures produced by different principals, for a fixed message and pattern. No computational assumptions are required. We prove Theorem 2 in Appendix E.

5 Revocation in JEDI

This section explains how JEDI keys may be revoked.

5.1 Simple Solution: Revocation via Expiry

A simple solution for revocation is to rely on expiration. In this solution, all keys are time-limited, and delegations are periodically refreshed, according to a higher layer protocol, by granting a new key with a later expiry time. In this setup, the principal who granted a key can easily revoke it by not refreshing that delegation when the key expires. We expect this solution to be sufficient for many applications of JEDI.

5.2 Immediate Revocation

Some disadvantages of the solution in §5.1 are that (1) principals must periodically come online to refresh delegations, and (2) revocation only takes effect when the delegated key expires. We would like a solution without these disadvantages.

However, any revocation scheme that does not wait for keys to expire is subject to set of inherent limitations. The recipient of the revoked delegation still has the revoked decryption key, so it can still decrypt messages encrypted in the same way. This means that we must either (1) rely on intermediate parties to modify ciphertexts so that revoked keys cannot decrypt them, or (2) require senders to be aware of the revocation, and encrypt messages in a different way so that revoked keys cannot decrypt them. Neither solution is ideal: (1) makes assumptions about how messages are delivered, which we have avoided thus far (§2), and requires trust in an intermediary to modify ciphertexts, and (2) weakens the decoupling of senders and receivers (§1.1). We adopt the second compromise: while senders will not need to know who are the receivers, they will need to know who has been revoked.

5.3 Immediate Revocation in JEDI

We extend tree-based broadcast encryption [72, 40] to support decentralized delegation of decryption keys, and incorporate it into JEDI. We use tree-based broadcast encryption because it only requires senders to know about revoked users when encrypting messages, as opposed to all users in the system (as is required by other broadcast encryption schemes).

5.3.1 Tree-based Broadcast Encryption

Existing work [72, 40] proposes two methods of tree-based broadcast encryption: Complete Subtree (CS) and Subset Difference (SD). We focus on the CS method here.

The CS method is based on a binary tree (Fig. 5) where each node corresponds to a separate keypair. Each user corresponds to a leaf of the tree and has the secret keys for all nodes on the root-to-leaf path. To encrypt a message that is decryptable by a subset of users, one finds a collection of subtrees that include all leaves except those corresponding to revoked users and encrypts the message multiple times using the public keys corresponding to the root of each subtree. By associating each node with an ID and encrypting with IBE, one can avoid generating a separate keypair for each node.

5.3.2 Modifying Broadcast Encryption for Delegation

Users in broadcast encryption do not map one-to-one to users in JEDI. To avoid confusion, we refer to “users” in broadcast encryption as “leaves” (abbreviated ).

We modify the CS method to support delegation, as follows. Each key corresponds to a range of consecutive leaves. When a user qualifies a key to delegate to another principal, she produces a new key corresponding to a subrange of the leaves of the original key. When a key is revoked, publishers are informed of the range of leaves corresponding to the revoked key. Then, they encrypt new messages using the CS method, choosing subtrees that cover all leaves except those corresponding to revoked leaves. If a key is revoked, that key and all keys derived from it can no longer decrypt messages, which is a property that we want. Thus, if Alice has leaves, she must store secret keys for nodes, where is the total number of leaves (so the depth of the tree is ).

In JEDI, we reduce this to secret keys by using HIBE. We give each node an identifier that describes the path from the root of the tree to that node. In particular, if is an ancestor of , then is a prefix of . Note that if we use HIBE with these IDs directly, a user with the secret key for the root can generate keys for all nodes in the tree. To fix this, we use a property called limited delegation, introduced by prior work [18], to generate a HIBE key that is unqualifiable (i.e., cannot be extended). For example, if Alice has leaves to in Fig. 5, she stores an unqualifiable key for node and a qualifiable key for node . In general, each user must store qualifiable keys and unqualifiable keys, thus total.

Figure 5: Key management of the CS method. Red nodes indicate nodes associated with revoked leaves. The green node is the root of the subtree covering unrevoked leaves.

5.3.3 Using Delegable Broadcast Encryption in JEDI

Secret keys in our modified broadcast encryption scheme consist of HIBE keys, so incorporating it into JEDI is simple. As discussed in §3.2, JEDI uses WKD-IBE in a way that provides multiple concurrent hierarchies, each in the vein of HIBE. Therefore, we can instantiate a third hierarchy of depth and use it for revocation.

Let be the number of revoked keys. The CS method has -size ciphertexts, so JEDI ciphertexts grow to this size when revocation is used. When encrypting a message, senders use the same encryption protocol from §3 for the first slots, and repeat the process, filling in the remaining slots with the ID of each node used for broadcast encryption. The size of secret keys is after our modifications to the CS method, so JEDI keys grow by this factor, to a total of WKD-IBE keys, where is the length of the time range for expiry.

The construction in this section works to revoke decryption keys, but cannot be used with anonymous signatures (§4.2). Extensions of tree-based broadcast encryption to signatures exist [64, 65], and we expect them to be useful to develop a construction for anonymous signatures.

How can JEDI inform publishers which leaves are revoked? One simple option is to have a global revocation list, which principals can append to. However, storing this information in a single list becomes a central point of attack, which we have avoided in our system thus far (§2). To avoid this, one can store the revocation list in a global-scale blockchain, such as Bitcoin or Ethereum, which would require an adversary to be exceptionally powerful to mount a successful attack. When revoking a set of leaves, a principal uses those keys to sign a predetermined object (as in §4.2), proving it owns an ancestor of that key in the hierarchy. To keep the revocation list private, one can use JEDI’s encryption to ensure that only principals with permission to publish to a particular resource can see which keys are revoked for that resource (since publishers too have signing keys, as described in §4).

5.4 Security Guarantee (Proof in Appendix E)

The security guarantee for immediate revocation can be stated as a modification to the game in Theorem 1. In the Initialization Phase, when gives the challenge (URI, time), additionally submits a list of revoked leaves. Furthermore, may compromise principals in possession of private keys that can decrypt the challenge (URI, time) pair during Phases 1 and 2, as long as all leaves corresponding to those keys are in the revocation list submitted in the Initialization Phase. We provide a proof in Appendix E.

5.5 Optimizing JEDI’s Immediate Revocation

A single JEDI ciphertext, with revocation enabled, consists of WKD-IBE ciphertexts. To compute them efficiently, we observe that there is a large overlap in the patterns used in individual WKD-IBE encryptions, allowing us to use the “precomputation with adjustment” strategy from §3.6.2.

Even with the above optimization, immediate revocation substantially increases the cost of JEDI’s cryptography. To reduce this cost, we make three observations. First, to extend JEDI’s hybrid encryption to work with revocation, it is sufficient to additionally rotate keys whenever the revocation list changes, in addition to the end of each hour (as in §3.6.1). This means that, in the common case where the revocation list does not change in between two messages, efficient symmetric-key encryption can be used. Second, the revocation list used to encrypt a message need only contain revoked leaves for the particular URI to which the message is sent. This not only makes the broadcast encryption more efficient (smaller ), but also causes the effective revocation list for a stream of data to change even more rarely, allowing JEDI to benefit more from hybrid encryption. Third, we can do the same thing as above using the expiry time rather than the URI, allowing us to cull the revocation list by removing keys from it once they expire.

The efficiency of hybrid encryption depends on the revocation list changing rarely. We believe this is a reasonable assumption; most revocation will be handled by expiry, so immediate revocation is only needed if a principal must lose access unexpectedly. In the smart buildings use case (§1), for example, a key would need to be revoked if a principal unexpectedly transfers to another job.

The SD method for tree-based broadcast encryption can also be extended to support delegation and incorporated into JEDI (Appendix B), The SD method has smaller ciphertexts but larger keys.

6 Implementation

We implemented JEDI as a library in the Go programming language. We expect that only a few applications will require the anonymous signature protocol in §4.2 or the tree-based revocation protocol in §5.3; most applications can use signature chains (§4.1) for integrity and expiry for revocation (§5.1). Therefore, our implementation makes anonymous signatures optional and implements revocation separately. We expect JEDI’s key delegation to be computed on relatively powerful devices, like laptops, smartphones, or Raspberry Pis; less powerful devices (e.g., right half of Fig. 1) will primarily send and receive messages, rather than generate keys for delegation. Therefore, our focus for low-power platforms was on the “sense-and-send” use case [27, 41, 44] typical of indoor environmental sensing, where a device periodically publishes sensor readings to a URI. Whereas our Go library provides higher-level abstractions, we expect low-power devices to use JEDI’s crypto library directly.

6.1 C/C++ Library for JEDI’s Cryptography

As part of JEDI, we implemented a cryptography library optimized in assembly for three different architectures typical of IoT platforms (Fig. 1). It implements WKD-IBE and JEDI’s optimizations and modifications (in §3.6, §4.3, Appendix A). The construction of WKD-IBE is based on a bilinear group in which the Bilinear Diffie-Hellman Exponent assumption holds. We originally planned to use Barreto-Naehrig elliptic curves [58, 32] to implement WKD-IBE. Unfortunately, a recent attack on Barreto-Naehrig curves [60] reduced their estimated security level from 128 bits to at most 100 bits [11]. Therefore, we use the recent BLS12-381 elliptic curve [25].

State-of-the-art cryptography libraries implement BLS12-381, but none of them, to our knowledge, optimize for microarchitectures typical of low-power embedded platforms. To improve energy consumption, we implemented BLS12-381 in C/C++, profiled our implementation, and re-wrote performance-critical routines in assembly. We focus on ARM Cortex-M, an IoT-focused family of 32-bit microprocessors typical of contemporary low-power embedded sensor platforms [52, 29, 56]. Cortex-M processors have been used in billions of devices, including commercial IoT offerings such as Fitbit and Nest Protect. Our assembly targets Cortex-M0+, which is among the least powerful of processors in the Cortex-M series, and of those used in IoT devices (farthest to the right in Fig. 1). By demonstrating the practicality of JEDI on Cortex-M0+, we establish that JEDI is viable across the spectrum of IoT devices (Fig. 1).

The main challenge in targeting Cortex-M0+ is that the 32-bit multiply instruction provides only the lower 32 bits of the product. Even on more powerful microarchitectures without this limitation (e.g., Intel Core i7), most CPU time () is spent on multiply-intensive operations (e.g., BigInt multiplication and Montgomery reduction), so the lack of such an instruction was a performance bottleneck. As a workaround, our assembly code emulates multiply-accumulate with carry in 23 instructions. Cortex-M3 and Cortex-M4, which are more commonly used than Cortex-M0+, have instructions for 32-bit multiply-accumulate which produce the entire 64-bit result; we expect JEDI to be more efficient on those processors.

We also wrote assembly to optimize BLS12-381 for x86-64 and ARM64, representative of server/laptop and smartphone/Raspberry Pi, respectively (first two tiers in Fig. 1). Thus, our Go library, which runs on these non-low-power platforms, also benefits from low-level assembly optimizations.

6.2 Application of JEDI to bw2

We used our JEDI library to implement end-to-end encryption in bw2, a syndication and authorization system for IoT. bw2’s syndication model is based on publish-subscribe, explained in §1. Here we discuss bw2’s authorization model. Access to resources is granted via certificate chains from the authority of a resource hierarchy to a principal. Individual certificates are called Declarations of Trust (DOTs). bw2 maintains a publicly accessible registry of DOTs, implemented using blockchain smart contracts, so that principals can find the DOTs they need to form DOT chains. A trusted router enforces permissions granted by DOTs. Principals must present DOT chains when publishing/subscribing to resources, and the router verifies them. Note that a compromised router can read messages.

We use JEDI to enforce bw2’s authorization semantics with end-to-end encryption. DOTs granting permission to subscribe now contain WKD-IBE keys to decrypt messages. By default, DOTs granting permission to publish to a URI remain unchanged, and are used as in §4.1. WKD-IBE keys may also be included in DOTs granting publish permission, for anonymous signatures (§4.2). Using our library for JEDI, we implemented a wrapper around the bw2 client library. It transparently encrypts and decrypts messages using WKD-IBE, and includes WKD-IBE parameters and keys in DOTs and principals, as needed for JEDI. bw2 signs each message with a digital signature (first alternative in §4.3).

The bw2-specific wrapper is less than 900 lines of Go code. Our implementation required no changes to bw2’s client library, router, blockchain, or core—it is a separate module. Importantly, it provides the same API as the standard bw2 client library. Thus, it can be used as a drop-in replacement for the standard bw2 client library, to easily add end-to-end encryption to existing bw2 applications with minimal changes.

7 Evaluation

We evaluate JEDI via microbenchmarks, determine its power consumption on a low-power sensor, measure the overhead of applying it to bw2, and compare it to other systems.

Operation Laptop Rasp. Pi Sensor
Mul. (Chosen Scalar) 109 µs 1.33 ms 509 ms
Mul. (Chosen Scalar) 343 µs 3.86 ms 1.44 s
Mul. (Rand. Scalar) 504 µs 5.47 ms 1.90 s
Mul. (Chosen Scalar) 507 µs 5.48 ms 2.81 s
Pairing 1.29 ms 14.0 ms 3.83 s
Table 1: Latency of JEDI’s implementation of BLS12-381

7.1 Microbenchmarks

Benchmarks labeled “Laptop” were produced on a Lenovo T470p laptop with an Intel Core i7-7820HQ CPU @ 2.90 GHz. Benchmarks labeled “Raspberry Pi” were produced on a Raspberry Pi 3 Model B+ with an ARM Cortex-A53 @ 1.4 GHz. Benchmarks labeled “Sensor” were produced on a commercially available ultra low-power environmental sensor platform called “Hamilton” with an ARM Cortex-M0+ @ 48 MHz. We describe Hamilton in more detail in §7.3.

7.1.1 Performance of BLS12-381 in JEDI

Table 1 compares the performance of JEDI’s BLS12-381 implementation on the three platforms, with our assembly optimizations. As expected from Fig. 1, the Raspberry Pi performance is an order of magnitude slower than Laptop performance, and performance on the Hamilton sensor is an additional two-to-three orders of magnitude slower.

7.1.2 Performance of WKD-IBE in JEDI

Fig. 6 depicts the performance of JEDI’s cryptography primitives. Fig. 6 does not include the sensor platform; §7.3 thoroughly treats performance of JEDI on low-power sensors.

In Figure 5(a), we used a pattern of length 20 for all operations, which would correspond to, e.g., a URI of length 14 and an Expiry hierarchy of depth 6. To measure decryption and signing time, we measure the time to decrypt the ciphertext or sign the message, plus the time to generate a decryption key for that pattern or ID. For example, if one receives a message on a/b/c/d/e/f, but has the key for a/*, he must generate the key for a/b/c/d/e/f to decrypt it.

Figure 5(a) demonstrates that the JEDI encrypts and signs messages and generates qualified keys for delegation at practical speeds. On a laptop, all WKD-IBE operations take less than 10 ms with up to 20 attributes. On a Raspberry Pi, they are 10x slower (as expected), but still run at interactive speeds.

Laptop Rasp. Pi
Enc. 3.08 ms 37.3 ms
Dec. 3.61 ms 43.9 ms
KeyD. 4.77 ms 58.5 ms
Sign 4.80 ms 61.2 ms
Verify 4.78 ms 56.3 ms
(a) Latency of , , , , and with 20 attributes
(b) Encryption with Revocation
Figure 6: Performance of JEDI’s cryptography

7.1.3 Performance of Immediate Revocation in JEDI

Figure 5(b) shows the cost of JEDI’s immediate revocation protocol (§5). A private key containing leaves consists of WKD-IBE secret keys where is the total number of leaves. Therefore, the performance of immediate revocation depends primarily on the number of leaves.

To encrypt a message, one WKD-IBE encryption is performed for each subtree needed to cover all unrevoked leaves. In general, encryption is , where is the number of revoked leaves. Each key contains a set of consecutive leaves, so encryption is also , where is the number of revoked JEDI keys. Decryption time remains almost the same, since only one WKD-IBE decryption is needed.

To benchmark revocation, we use a complete binary tree of depth 16 (). The time to generate a new key for delegation is essentially independent of the number of leaves conveyed in that key, because . We empirically confirmed this; the time to generate a key for delegation was constant at 2.4 ms on a laptop and 31 ms on a Raspberry Pi as the number of leaves in the key was varied from 5 to 1,000.

To benchmark encryption with revocation, we assume that there exist 2,048 users in the system each with 32 leaves. We measure encryption time with a pattern with 20 fixed slots (for URI and time) as we vary the number of revoked users. Figure 5(b) shows that encryption becomes expensive when the revocation list is large ( milliseconds on laptop and seconds on Raspberry Pi). However, such an encryption only needs to be performed by a publisher when the URI, time, or revocation list changes; subsequent messages can reuse the underlying symmetric key (§5.5). Furthermore, the revocation list includes only revoked keys that match the (URI, time) pair being used, so it is not expected to grow very large.

(a) Encrypt/publish message
(b) Receive/decrypt message
Figure 7: Critical-path operations in bw2, with/without JEDI

7.2 Performance of JEDI in bw2

In bw2, the two critical-path operations are publishing a message to a URI, and receiving a message as part of a subscription. We measure the overhead of JEDI for these operations because they are core to bw2’s functionality and would be used by any messaging application built on bw2. Our methodology is to perform each operation repeatedly in a loop, to measure the sustained performance (operations/second), and report the average time per operation (inverse). To minimize the effect of the network, the router was on the same link as the client, and the link capacity was 1 Gbit/s. In our experiments, we used a URI of length 6 and an Expiry tree of depth 6. We also include measurements from a strawman system with pre-shared AES keys—this represents the critical-path overhead of an approach based on the Trusted Key Server discussed in §2. Our results are in Fig. 7.

We implement the optimizations in §3.6.1, so only symmetric key encryption/decryption must be performed in the common case (labeled “usual” in the diagram). However, the symmetric keys will not be cached for the first message sent every hour, when the WKD-IBE pattern changes. A WKD-IBE operation must be performed in this case (labeled “1st message” in the diagram). For large messages, the cost of symmetric key encryption dominates. JEDI has a particularly small overhead for 1 MiB messages in Fig. 6(b), perhaps because 1 MiB messages take several milliseconds to transmit over the network, allowing the client to decrypt a message while the router is sending the next message.

We also consider creating DOTs and initiating subscriptions, which are not in the critical path of bw2. These results are in Fig. 8 (note the log scale in Fig. 7(a)). Creating DOTs is slower with JEDI, because WKD-IBE keys are generated and included in the DOT. Initiating a subscription in bw2 requires forming a DOT chain; in JEDI, one must also derive a private key from the DOT chain. Fig. 7(a) shows the time to form a short one-hop DOT chain, and in the case of JEDI, includes the time to derive the private key. For JEDI’s encryption (§3), these additional costs are incurred only by DOTs that grant permission to subscribe. With anonymous signatures, DOTs granting permission to publish incur this overhead as well, as WKD-IBE keys must be included. Fig. 7(b) puts this in context by measuring the end-to-end latency from initiating a subscription to receiving the first message (measured using bw2’s “query” functionality).

(a) Create DOT, Build Chain
(b) Time to Query/Subscribe
Figure 8: Occasional bw2 operations, with and without JEDI

For a DOT to be usable, it must be inserted into bw2’s registry. This requires a blockchain transaction (not included in Fig. 8). An important consideration in this regard is size. In the unmodified bw2 system, a DOT that grants permission on a/b/c/d/e/f is 198 bytes. With JEDI, each DOT also contains multiple WKD-IBE keys, according to the time range. In the “worst case,” where the start time of a DOT is Jan 01 at 01:00, and the end time is Dec 31 at 22:59, a total of 45 keys are needed. Each key is approximately 1 KiB (Table 6), so the size of this DOT is approximately 45 KiB.

Because bw2’s registry of DOTs is implemented using blockchain smart contracts, the bandwidth for inserting DOTs is limited. Using JEDI would increase the size of DOTs as above, resulting in an approximately 100-400x decrease in aggregate bandwidth for creating DOTs. However, this can be mitigated by changing bw2 to not store DOTs directly in the blockchain. DOTs can be stored in untrusted storage, with only their hashes stored in the blockchain-based registry. Such a solution could be based on Swarm [84] or Filecoin [46].

7.3 Feasibility on Ultra Low-Power Devices

We use a commercially available sensor platform called “Hamilton” [52, 4] built around the Atmel SAMR21 system-on-chip (SoC). The SAMR21 costs approximately $2.25 per unit [43] and integrates a low-power microcontroller and radio. The sensor platform we used in this study costs $18 to manufacture [59]. For battery lifetime calculations, we assume that the platform is powered using a CR123A Lithium battery that provides 1400 mAh at 3.0 V (252 J of energy). Such a battery costs $1. The SAMR21 is heavily constrained: it has only a 48 MHz CPU frequency based on the ARM Cortex-M0+ microarchitecture, and a total of only 32 KiB of data memory (RAM). Our goal is to validate that JEDI is practical for an ultra low-power sensor platform like Hamilton, in the context of a “sense-and-send” application in a smart building. Since most of the platform’s cost ($18) comes from the on-board transducers and assembly, rather than the SAMR21 SoC, using an even more resource-constrained SoC would not significantly decrease the platform’s cost. An analogous argument applies to energy consumption, as the transducers account for more than half of Hamilton’s idle current [59].

Hamilton/SAMR21 is on the lower end of platforms typically used for sense-and-send applications in buildings. Some older studies [44, 63] use even more constrained hardware like the TelosB; this is because those studies were constrained by hardware available at the time. Modern 32-bit SoCs, like the SAMR21, offer substantially better performance at a similar price/power point to those older platforms [59].

7.3.1 CPU Usage

Table 2 shows the time for encryption and anonymous signing in JEDI on Hamilton. The results use the optimizations discussed in §3.6 and §4.3, and include the time to “adjust” precomputed state. They indicate that symmetric keys can be encrypted and anonymously signed in less than 10 seconds. This is feasible given that encryption and anonymous signing occur rarely, once an hour, and need not be produced at interactive speeds in the normal “sense-and-send” use case.

Operation Time Average Current
Sleep (Idle) N/A 0.0063 mA
WKD-IBE Encrypt 6.50 s 10.2 mA
WKD-IBE Encrypt and Sign 9.89 s 10.2 mA
Table 2: CPU and power costs on the Hamilton platform

7.3.2 Power Consumption

To calculate the impact on battery lifetime, we consider a “sense-and-send” application, in which the Hamilton device obtains readings from its sensors at regular intervals, and immediately sends the readings encrypted over the wireless network. We measured the average current consumed for varying sample intervals, when each message is encrypted with AES-CCM, without using JEDI (“AES Only” in Table 3). We estimate JEDI’s average current based on the current, duration, and frequency (once per hour, for these estimates) of JEDI operations, and add it to the average current of the “AES Only” setup. Our estimates assume that the µTESLA-based technique in §4.3 is used to avoid attaching a digital signature to each message. We divide the battery’s energy capacity by the result to compute lifetime. As shown in Table 3, JEDI decreases battery life by about 40-60%. Battery life is several years even with JEDI, acceptable for IoT sensor platforms.

JEDI’s overhead depends primarily on the granularity of expiry times (one hour, for these estimates), not the sample interval. To improve power consumption, one could use a time tree with larger leaves, allowing principals to perform WKD-IBE encryptions and anonymous signatures less often. This would, of course, make expiry times coarser.

AES Only JEDI (enc) JEDI (enc & sign)
10 s 32 µA / 5.1 y 50 µA / 3.2 y 60 µA / 2.6 y
20 s 20 µA / 8.1 y 38 µA / 4.2 y 48 µA / 3.3 y
30 s 15 µA / 10 y 34 µA / 4.7 y 44 µA / 3.6 y
Table 3: Average current and expected battery life (for 1400 mAh battery) for sense-and-send, with varying sample interval

7.3.3 Memory Budget

Performing WKD-IBE operations requires only 6.5 KiB of data memory, which fits comfortably within the 32 KiB of data memory (RAM) available on the SAMR21. The code space required for our implementation of WKD-IBE and BLS12-381 is about 74 KiB, which fits comfortably in the 256 KiB of code memory (ROM) provided by the SAMR21.

A related question is whether storing a hash chain in memory (as required for authenticated broadcast, §4.3) is practical. If we use a granularity of 1 minute for authenticated broadcast, the length of the hash chain is 60. At the start of an hour, one computes the entire chain, storing 10 hashes equally spaced along the chain, each separated by 5 hashes. As one progresses along the hash chain, one re-computes each set of 5 hashes one additional time. This requires storage for only 15 hashes ( KiB memory) and computation of only 105 hashes per hour, which is practical. One could possibly optimize performance further using hierarchical hash chains [53].

7.3.4 Impact of JEDI’s Optimizations

JEDI’s cryptographic optimizations (§3.6.2, §4.2.2, §4.3), which use WKD-IBE in a non-black-box manner, provide a 2-3x performance improvement. Our assembly optimizations (§6) provide an additional 4-5x improvement. Without both of these techniques, JEDI would not be practical on low-power sensors. Hybrid encryption and key reuse (§3.6.1), which let JEDI use WKD-IBE rarely, are also crucial.

7.4 Comparison to Other Systems

Crypto Scheme / System Avoids Central Trust? Expressivity Performance
Trusted Key Server (§2)
  • [leftmargin=*,noitemsep,topsep=0ex]

  • No

  • [leftmargin=*,noitemsep,topsep=0ex]

  • Supports arbitrary policies (beyond hierarchies)

  • No delegation

  • [leftmargin=*,noitemsep,topsep=0ex]

  • µs to encrypt 1 KiB message (same as JEDI in common case, faster for first message after key rotation)

  • Trusted party generates one key per resource

PRE (Lattice-Based), as used in PICADOR [24]
  • [leftmargin=*,noitemsep,topsep=0ex]

  • No

  • [leftmargin=*,noitemsep,topsep=0ex]

  • Supports arbitrary policies (beyond hierarchies)

  • No delegation

  • [leftmargin=*,noitemsep,topsep=0ex]

  • ms encrypt, ms decrypt (similar to JEDI: 3-4 ms)

  • Trusted party must generate one key per sender-receiver pair

PRE (Pairing-Based), as used in Pilatus [80]
  • [leftmargin=*,noitemsep,topsep=0ex]

  • Yes

  • [leftmargin=*,noitemsep,topsep=0ex]

  • Delegation is single-hop

  • Delegation is coarse (all-or-nothing)

  • Can compute aggregates on encrypted data

  • [leftmargin=*,noitemsep,topsep=0ex]

  • 0.6 ms encrypt, 1.3 ms re-encrypt, 0.5 ms decrypt (faster than JEDI: 3-4 ms)

  • Practical on constrained IoT device with crypto accelerator

CP-ABE [13]
  • [leftmargin=*,noitemsep,topsep=0ex]

  • Yes

  • [leftmargin=*,noitemsep,topsep=0ex]

  • Good fit for RBAC policies

  • Cannot support JEDI’s hierarchy abstraction with delegation

  • [leftmargin=*,noitemsep,topsep=0ex]

  • Only symmetric crypto in common case

  • 14 ms encrypt for first time after key rotation (4-5x slower than JEDI: 3 ms)

KP-ABE, as used in Sieve [88]
  • [leftmargin=*,noitemsep,topsep=0ex]

  • Yes

  • [leftmargin=*,noitemsep,topsep=0ex]

  • Succinct delegation based on attributes

  • Delegation is single-hop

  • [leftmargin=*,noitemsep,topsep=0ex]

  • Only symmetric crypto in common case

  • 25 ms encrypt for first time after key rotation (8-9x slower than JEDI: 3 ms)

Delegable Large Univ. KP-ABE [51] (used in Alternative JEDI Design)
  • [leftmargin=*,noitemsep,topsep=0ex]

  • Yes

  • [leftmargin=*,noitemsep,topsep=0ex]

  • Generalizes beyond hierarchies and supports multi-hop delegation (subsumes JEDI)

  • [leftmargin=*,noitemsep,topsep=0ex]

  • Only symmetric crypto in common case

  • 60 ms encrypt for first time after key rotation (20x slower than JEDI: 3 ms)

  • Impractical for low-power sense-and-send

This paper: WKD-IBE  [1] with Optimizations, as used in JEDI
  • [leftmargin=*,noitemsep,topsep=0ex]

  • Yes

  • [leftmargin=*,noitemsep,topsep=0ex]

  • Delegation is multi-hop

  • Succinct delegation of subtrees of resources (or more complex sets, §3.7)

  • Non-interactive expiry

  • [leftmargin=*,noitemsep,topsep=0ex]

  • After key rotation (e.g., once per hour), 3 ms encrypt, 4 ms decrypt (Fig. 5(a))

  • Only symmetric crypto in common case

  • Practical for ultra low-power “sense-and-send” without crypto accelerator

Table 4: Comparison of JEDI with other crypto-based IoT/cloud systems

Table 4 compares JEDI to other systems and cryptographic approaches, particularly those geared toward IoT, in regard to security, expressivity and performance. We treat these existing systems as they would be used in a messaging system for smart buildings (§1). Table 4 contains quantitative comparisons to the cryptography used by these systems; for those schemes based on bilinear groups, we re-implemented them using our JEDI crypto library (§6.1) for a fair comparison.

Security. The owner of a resource is considered trusted for that resource, in the sense that an adversary who compromises a principal can read all of that principal’s resources. In Table 4, we focus on whether a single component is trusted for all resources in the system. Note that, although Trusted Key Server (§2) and PICADOR [24] encrypt data in flight, granting or revoking access to a principal requires participation of an online trusted party to generate new keys.

Expressivity. PRE-based approaches, which associate public keys with users and support delegation via proxy re-encryption, are fundamentally coarse-grained—a re-encryption key allows all of a user’s data to be re-encrypted. PICADOR [24] allows more fine-grained semantics, but does not enforce them cryptographically. ABE-based approaches typically do not support delegation beyond a single hop, whereas JEDI achieves multi-hop delegation. In ABE-based schemes, however, attributes/policies attached to keys can describe more complex sets of resources than JEDI. That said, a hierarchical resource representation is sufficient for JEDI’s intended use case, namely smart cities; existing syndication systems for smart cities, which do not encrypt data and are unconstrained by the expressiveness of crypto schemes, choose a hierarchical rather than attribute-based representation (§1).

Performance. The Trusted Key Server (§2) is the most naïve approach, requiring an online trusted party to enforce all policy. Even so, JEDI’s performance in the common case is the same as the Trusted Key Server (Fig. 7), because of JEDI’s hybrid encryption—JEDI invokes WKD-IBE rarely. Even when JEDI invokes WKD-IBE, its performance is not significantly worse than PRE-based approaches. An alternative design for JEDI uses the GPSW KP-ABE construction instead of WKD-IBE, but it is significantly more expensive. Based Table 3, the power cost of a WKD-IBE operation even when only invoked once per hour contributes significantly to the overall energy consumption on the low-power IoT device; using KP-ABE instead of WKD-IBE would increase this power consumption by an order of magnitude, reducing battery life significantly.

In summary, existing systems fall into one of three categories. (1) The Trusted Key Server allows access to resources to be managed by arbitrary policies, but relies on a central trusted party who must be online whenever a user is granted access or is revoked. (2) PRE-based approaches, which permit sharing via re-encryption, cannot cryptographically enforce fine-grained policies or support multi-hop delegation. (3) ABE-based approaches, if carefully designed, can achieve the same expressivity as JEDI, but are substantially less performant and are not suitable for low-power embedded devices.

8 Related Work

We organize related work into the following categories.

Traditional Public-Key Encryption. SiRiUS [50] and Plutus [57] are encrypted filesystems based on traditional public-key cryptography, but they do not support delegable and qualifiable keys like JEDI. Akl et al. [2] and further work [36, 37] propose using key assignment schemes for access control in a hierarchy. A line of work [85, 54, 9, 8] builds on this idea to support both hierarchical structure and temporal access. Key assignment approaches, however, require the full hierarchy to be known at setup time, which is not flexible in the IoT setting. JEDI does not require this, allowing different subtrees of the hierarchy to be managed separately (§1.1, “Delegation”).

Identity-Based Encryption. Tariq et al. [83] use Identity-Based Encryption (IBE) [19] to achieve end-to-end encryption in publish-subscribe systems, without the router’s participation in the protocol. However, their approach does not support hierarchical resources. Further, encryption and private keys are on a credential-basis, so each message is encrypted multiple times according to the credentials of the recipients.

Wu et al. [92] use a prefix encryption scheme based on IBE for mutual authentication in IoT. Their prefix encryption scheme is different from JEDI, in that users with keys for identity a/b/c can decrypt messages encrypted with prefix identity a, a/b and a/b/c, but not identities like a/b/c/d.

Hierarchical Identity-Based Encryption. Since the original proposal of Hierarchical Identity-Based Encryption (HIBE) [49], there have been multiple HIBE constructions [49, 17, 18, 48] and variants of HIBE [93, 1]. Although seemingly a good match for resource hierarchies, HIBE cannot be used as a black box to efficiently instantiate JEDI. We considered alternative designs of JEDI based on existing variants of HIBE, but as we elaborate in Appendix C, each resulting design is either less expressive or significantly more expensive than JEDI.

Attribute-Based Encryption. A line of work [95, 88] uses Attribute-Based Encryption (ABE) [51, 13] to delegate permission. For example, Yu et al. [95] and Sieve [88] use Key-Policy ABE (KP-ABE) [51] to control which principals have access to encrypted data in the cloud. Some of these approaches also provide a means to revoke users, leveraging proxy re-encryption to safely perform re-encryption in the cloud. Our work additionally supports hierarchically-organized resources and decentralized delegation of keys, which [95] and [88] do not address. As discussed in §7.4 and Appendix D, WKD-IBE is substantially more efficient than KP-ABE and provides enough functionality for JEDI. WKD-IBE could be a lightweight alternative to KP-ABE for some applications.

Other approaches prefer Ciphertext-Policy ABE (CP-ABE) [13]. Existing work [89, 90] combines HIBE with CP-ABE to produce Hierarchical ABE (HABE), a solution for sharing data on untrusted cloud servers. The “hierarchical” nature of HABE, however, corresponds to the hierarchical organization of domain managers in an enterprise, not a hierarchical organization of resources as in our work.

Proxy Re-Encryption. NuCypher KMS [42] allows a user to store data in the cloud encrypted under her public key, and share it with another user using Proxy Re-Encryption (PRE) [15]. While NuCypher assumes limited collusion among cloud servers and recipients (e.g., of secret sharing) to achieve properties such as expiry, JEDI enforces expiry via cryptography, and therefore remains secure against any amount of collusion. Furthermore, NuCypher’s solution for resource hierarchies requires a keypair for each node in the hierarchy, meaning that the creation of resources is centralized. Finally, keys in NuCypher are not qualifiable. Given a key for a/*, one cannot generate a key for a/b/* to give to another principal.

PICADOR [24], a publish-subscribe system with end-to-end encryption, uses a lattice-based PRE scheme. However, PICADOR requires a central Policy Authority to specify access control, by creating a re-encryption key for every permitted pair of publisher and subscriber. In contrast, JEDI’s access control is decentralized.

Revocation Schemes. Broadcast encryption (BE) [72, 40, 20, 21, 62, 22, 23] is a mechanism to achieve revocation, by encrypting messages such that they are only decryptable by a specific set of users. However, these existing schemes do not support key qualification and delegation, and therefore, cannot be used in JEDI directly. Another line of work builds revocation directly into the underlying cryptography primitive, achieving Revocable IBE [16, 66, 77, 91], Revocable HIBE [76, 78, 67] and Revocable KP-ABE [10]. These papers use a notion of revocation in which URIs are revoked. In contrast, JEDI supports revocation at the level of keys. If multiple principals have access to a URI, and one of their keys is revoked, then the other principal can still use its key to access the resource. Some systems [42, 12] rely on the participation of servers or routers to achieve revocation.

Secure Reliable Multicast Protocol. Secure Reliable Multicast [68, 69] also uses a many-to-many communication model, and ensures correct data transfer in the presence of malicious routers. JEDI, as a protocol to encrypt messages, is complementary to those systems.

Authorization Services. JEDI is complementary to authorization services for IoT, such as bw2 [5], Vanadium [82], WAVE [6], and AoT [73], which focus on expressing authorization policies and enabling principals to prove they are authorized, rather than on encrypting data. Droplet [79] provides encryption for IoT, but does not support delegation beyond one hop and does not provide hierarchical resources.

An authorization service that provides secure in-band permission exchange, like WAVE [6], can be used for key distribution in JEDI. JEDI can craft keys with various permissions, while WAVE can distribute them without a centralized party by including them in its attestations.

9 Conclusion

In this paper, we presented JEDI, a protocol for end-to-end encryption for IoT. JEDI provides many-to-many encrypted communication on complex resource hierarchies, supports decentralized key delegation, and decouples senders from receivers. It provides expiry for access to resources, reconciles anonymity and authorization via anonymous signatures, and allows revocation via tree-based broadcast encryption. Its encryption and integrity solutions are capable of running on embedded devices with strict energy and resource constraints, making it suitable for the Internet of Things.


The JEDI cryptography library is available at and our implementation of the JEDI protocol for bw2 is available at


We thank our anonymous reviewers and our shepherd William Enck for their invaluable feedback. We would also like to thank students from the RISE Security Group and BETS Research Group for giving us feedback on early drafts of this paper. This research was supported by Intel/NSF CPS-Security #1505773 and #20153754, DoE #DE-EE000768, California Energy Commission #EPC-15-057, NSF CISE Expeditions #CCF-1730628, NSF GRFP #DGE-1752814, and gifts from the Sloan Foundation, Hellman Fellows Fund, Alibaba, Amazon, Ant Financial, Arm, Capital One, Ericsson, Facebook, Google, Intel, Microsoft, Scotiabank, Splunk and VMware.


  • [1] M. Abdalla, E. Kiltz, and G. Neven. Generalized key delegation for hierarchical identity-based encryption. Cryptology ePrint Archive, Report 2007/221.
  • [2] S. G. Akl and P. D. Taylor. Cryptographic solution to a problem of access control in a hierarchy. TOCS, 1983.
  • [3] M. P Andersen, G. Fierro, and D. E. Culler. System design for a synergistic, low power mote/BLE embedded platform. In IPSN, 2016.
  • [4] M. P. Andersen, H.-S. Kim, and D. E. Culler. Hamilton - a cost-effective, low power networked sensor for indoor environment monitoring. In BuildSys, 2017.
  • [5] M. P. Andersen, J. Kolb, K. Chen, D. E. Culler, and R. Katz. Democratizing authority in the built environment. In BuildSys, 2017.
  • [6] M. P Andersen, S. Kumar, M. AbdelBaky, G. Fierro, J. Kolb, H.-S. Kim, D. E. Culler, and R. A. Popa. WAVE: A decentralized authorization framework with transitive delegation. In USENIX Security, 2019.
  • [7] P. Arjunan, N. Batra, H. Choi, A. Singh, P. Singh, and M. B. Srivastava. SensorAct: A privacy and security aware federated middleware for building management. In BuildSys, 2012.
  • [8] M. J. Atallah, M. Blanton, N. Fazio, and K. B. Frikken. Dynamic and efficient key management for access hierarchies. In TISSEC, 2009.
  • [9] M. J. Atallah, M. Blanton, and K. B. Frikken. Incorporating temporal capabilities in existing key management schemes. In ESORICS, 2007.
  • [10] N. Attrapadung and H. Imai. Conjunctive broadcast and attribute-based encryption. In ICPBC, 2009.
  • [11] R. Barbulescu and S. Duquesne. Updating key size estimations for pairings. Cryptology ePrint Archive, Report 2017/334.
  • [12] S. Belguith, S. Cui, M. R. Asghar, and G. Russello. Secure publish and subscribe systems with efficient revocation. In SAC, 2018.
  • [13] J. Bethencourt, A. Sahai, and B. Waters. Ciphertext-policy attribute-based encryption. In S&P, 2007.
  • [14] A. Birgisson, J. G. Politz, Ú. Erlingsson, A. Taly, M. Vrable, and M. Lentczner. Macaroons: Cookies with contextual caveats for decentralized authorization in the cloud. In NDSS, 2014.
  • [15] M. Blaze, G. Bleumer, and M. Strauss. Divertible protocols and atomic proxy cryptography. EUROCRYPT, 1998.
  • [16] A. Boldyreva, V. Goyal, and V. Kumar. Identity-based encryption with efficient revocation. In CCS, 2008.
  • [17] D. Boneh and X. Boyen. Efficient selective-ID secure identity-based encryption without random oracles. In EUROCRYPT, 2004.
  • [18] D. Boneh, X. Boyen, and E.-J. Goh. Hierarchical identity based encryption with constant size ciphertext. In EUROCRYPT and Cryptology ePrint Archive, 2005.
  • [19] D. Boneh and M. Franklin. Identity-based encryption from the Weil pairing. In CRYPTO, 2001.
  • [20] D. Boneh, C. Gentry, and B. Waters. Collusion resistant broadcast encryption with short ciphertexts and private keys. In CRYPTO, 2005.
  • [21] D. Boneh and B. Waters. A fully collusion resistant broadcast, trace, and revoke system. In CCS, 2006.
  • [22] D. Boneh, B. Waters, and M. Zhandry. Low overhead broadcast encryption from multilinear maps. In CRYPTO, 2014.
  • [23] D. Boneh and M. Zhandry. Multiparty key exchange, efficient traitor tracing, and more from indistinguishability obfuscation. Algorithmica, 2017.
  • [24] C. Borcea, A. B. D. Gupta, Y. Polyakov, K. Rohloff, and G. Ryan. PICADOR: End-to-end encrypted publish-subscribe information distribution with proxy re-encryption. FGCS, 2017.
  • [25] S. Bowe. BLS12-381: New zk-SNARK elliptic curve construction, 2018.
  • [26] A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, J. P. Vasseur, and R. Alexander. RPL: IPv6 routing protocol for low-power and lossy networks. RFC, RFC Editor, 2012.
  • [27] D. Brunelli, I. Minakov, R. Passerone, and M. Rossi. POVOMON: An ad-hoc wireless sensor network for indoor environmental monitoring. In EESMS, 2014.
  • [28] bw2.
  • [29] B. Campbell. Introducing Hail, 2017.
  • [30] R. Canetti, S. Halevi, and J. Katz. A forward-secure public-key encryption scheme. In EUROCRYPT, 2003.
  • [31] R. Cheng, W. Scott, B. Parno, I. Zhang, A. Krishnamurthy, and T. Anderson. Talek: A private publish-subscribe protocol. Technical report, University of Washington CSE, 2016.
  • [32] J. H. Cheon. Security analysis of the strong Diffie-Hellman problem. In EUROCRYPT, 2006.
  • [33] Cisco. The Internet of things reference model. Technical report, Cisco, 2014.
  • [34] D. Clarke, J.-E. Elien, C. Ellison, M. Fredette, A. Morcos, and R. L. Rivest. Certificate chain discovery in SPKI/SDSI. Journal of Computer Security, 2001.
  • [35] H. Corrigan-Gibbs, D. Boneh, and D. Mazières. Riposte: An anonymous messaging system handling millions of users. In S&P, 2015.
  • [36] J. Crampton, N. Farley, G. Gutin, M. Jones, and B. Poettering. Cryptographic enforcement of information flow policies without public information. In ACNS, 2015.
  • [37] J. Crampton, K. Martin, and P. Wild. On key assignment for hierarchical access control. In CSFW, 2006.
  • [38] S. Dawson-Haggerty, X. Jiang, G. Tolle, J. Ortiz, and D. E. Culler. sMAP: A simple measurement and actuation profile for physical information. In SenSys, 2010.
  • [39] S. Dawson-Haggerty, A. Krioukov, J. Taneja, S. Karandikar, G. Fierro, N. Kitaev, and D. E. Culler. BOSS: Building operating system services. In NSDI, 2013.
  • [40] Y. Dodis and N. Fazio. Public key broadcast encryption for stateless receivers. In DRM, 2002.
  • [41] P. Dutta, D. E. Culler, and S. Shenker. Procrastination might lead to a longer and more useful life. In HotNets, 2007.
  • [42] M. Egorov and M. Wilkison. NuCypher KMS: decentralized key management system. CoRR, 2017.
  • [43] DigiKey Electronics. Atsamr21e18a-mu microchip technology. Feb. 8, 2019.
  • [44] M. C. Feldmeier. Personalized Building Comfort Control. PhD thesis, MIT, 2009.
  • [45] G. Fierro and D. E. Culler. XBOS: An extensible building operating system. Technical report, EECS Department, University of California, Berkeley, 2015.
  • [46] Filecoin. Jan. 19, 2018.
  • [47] T. Frosch, C. Mainka, C. Bader, F. Bergsma, J. Schwenk, and T. Holz. How secure is TextSecure? In EuroS&P, 2016.
  • [48] C. Gentry and S. Halevi. Hierarchical identity based encryption with polynomially many levels. In TCC, 2009.
  • [49] C. Gentry and A. Silverberg. Hierarchical ID-based cryptography. In ASIACRYPT, 2002.
  • [50] E.-J. Goh, H. Shacham, N. Modadugu, and D. Boneh. SiRiUS: Securing remote untrusted storage. In NDSS, 2003.
  • [51] V. Goyal, O. Pandey, A. Sahai, and B. Waters. Attribute-based encryption for fine-grained access control of encrypted data. In CCS, 2006.
  • [52] Hamilton IoT.
  • [53] Y.-C. Hu, M. Jakobsson, and A. Perrig. Efficient constructions for one-way hash chains. In ACNS, 2005.
  • [54] H.-F. Huang and C.-C. Chang. A new cryptographic key assignment scheme with time-constraint access control in a hierarchy. Computer Standards & Interfaces, 2004.
  • [55] J. Hviid and M. B. Kjaergaard. Activity-tracking service for building operating systems. In PerCom, 2018.
  • [56] imix: Low-power IoT research platform, 2017.
  • [57] M. Kallahalla, E. Riedel, R. Swaminathan, Q. Wang, and K. Fu. Plutus: Scalable secure file sharing on untrusted storage. In FAST, 2003.
  • [58] Y. Kawahara, T. Kobayashi, M. Scott, and A. Kato. Barreto-Naehrig curves. Technical report, Internet-Draft draft-kasamatsu-bncurves-02. Internet Engineering Task Force., 2016.
  • [59] H.-S. Kim, M. P. Andersen, K. Chen, S. Kumar, W. J. Zhao, K. Ma, and D. E. Culler. System architecture directions for post-SoC/32-bit networked sensors. In SenSys, 2018.
  • [60] T. Kim and R. Barbulescu. Extended tower number field sieve: A new complexity for the medium prime case. In CRYPTO, 2016.
  • [61] A. Krioukov, G. Fierro, N. Kitaev, and D. E. Culler. Building application stack (BAS). In BuildSys, 2012.
  • [62] A. Lewko, A. Sahai, and B. Waters. Revocation systems with very small private keys. In S&P, 2010.
  • [63] C. Li, Z. Li, M. Li, F. Meggers, A. Schlueter, and H. B. Lim. Energy efficient HVAC system with distributed sensing and control. In ICDCS, 2014.
  • [64] B. Libert, T. Peters, and M. Yung. Group signatures with almost-for-free revocation. In CRYPTO, 2012.
  • [65] B. Libert, T. Peters, and M. Yung. Scalable group signatures with revocation. In EUROCRYPT, 2012.
  • [66] B. Libert and D. Vergnaud. Adaptive-ID secure revocable identity-based encryption. In CT-RSA, 2009.
  • [67] W. Liu, J. Liu, Q. Wu, B. Qin, D. Naccache, and H. Ferradi. Compact CCA2-secure hierarchical identity-based broadcast encryption for fuzzy-entity data sharing. Cryptology ePrint Archive, Report 2016/634.
  • [68] D. Malkhi, M. Merritt, and O. Rodeh. Secure reliable multicast protocols in a WAN. Dist. Computing, 2000.
  • [69] D. Malkhi and M. Reiter. A high-throughput secure reliable multicast protocol. Computer Security, 1997.
  • [70] A. Mehanovic, T. H. Rasmussen, and M. B. Kjærgaard. Brume - a horizontally scalable and fault tolerant building operating system. In IoTDI, 2018.
  • [71] R. C. Merkle. A certified digital signature. In ASIACRYPT, 1989.
  • [72] D. Naor, M. Naor, and J. Lotspiech. Revocation and tracing schemes for stateless receivers. In CRYPTO, 2001.
  • [73] A. L. M. Neto, A. L. F. Souza, I. Cunha, M. Nogueira, I. O. Nunes, L. Cotta, N. Gentille, A. A. F. Loureiro, D. F. Aranha, H. K. Patil, and L. B. Oliveira. AoT: Authentication and access control for the entire IoT device life-cycle. In SenSys, 2016.
  • [74] Particle Mesh. Feb. 2, 2019.
  • [75] A. Perrig, R. Szewczyk, V. Wen, D. E. Culler, and J. D. Tygar. SPINS: Security protocols for sensor networks. In MobiCom, 2001.
  • [76] J. H. Seo and K. Emura. Efficient delegation of key generation and revocation functionalities in identity-based encryption. In CT-RSA, 2013.
  • [77] J. H Seo and K. Emura. Revocable identity-based encryption revisited: Security model and construction. In PKC, 2013.
  • [78] J. H. Seo and K. Emura. Revocable hierarchical identity-based encryption: History-free update, security against insiders, and short ciphertexts. In CT-RSA, 2015.
  • [79] H. Shafagh, L. Burkhalter, S. Duquennoy, A. Hithnawi, and S. Ratnasamy. Droplet: Decentralized authorization for IoT data streams. CoRR, 2018.
  • [80] H. Shafagh, A. Hithnawi, L. Burkhalter, P. Fischli, and S. Duquennoy. Secure sharing of partially homomorphic encrypted IoT data. In SenSys, 2017.
  • [81] Solace cloud. Jan. 17, 2018.
  • [82] A. Taly and A. Shankar. Distributed authorization in Vanadium. In FOSAD VIII, 2016.
  • [83] M. A. Tariq, B. Koldehofe, and K. Rothermel. Securing broker-less publish/subscribe systems using identity-based encryption. TPDS, 2014.
  • [84] V. Tron, A. Fischer, and N. Johnson. Smash-proof: Auditable storage for Swarm secured by masked audit secret hash. Technical report, Ethersphere, 2016.
  • [85] W.-G. Tzeng. A time-bound cryptographic key assignment scheme for access control in a hierarchy. TKDE, 2002.
  • [86] J. van den Hooff, D. Lazar, M. Zaharia, and N. Zeldovich. Vuvuzela: Scalable private messaging resistant to traffic analysis. In SOSP, 2015.
  • [87] VOLTTRON. Jan. 23, 2019.
  • [88] F. Wang, J. Mickens, N. Zeldovich, and V. Vaikuntanathan. Sieve: Cryptographically enforced access control for user data in untrusted clouds. NSDI, 2016.
  • [89] G. Wang, Q. Liu, and J. Wu. Hierarchical attribute-based encryption for fine-grained access control in cloud storage services. In CCS, 2010.
  • [90] G. Wang, Q. Liu, J. Wu, and M. Guo. Hierarchical attribute-based encryption and scalable user revocation for sharing data in cloud servers. Computers & Security, 2011.
  • [91] Y. Watanabe, K. Emura, and J. H. Seo. New revocable IBE in prime-order groups: Adaptively secure, decryption key exposure resistant, and with short public parameters. In CT-RSA, 2017.
  • [92] D. J. Wu, A. Taly, A. Shankar, and D. Boneh. Privacy, discovery, and authentication for the Internet of things. In ESORICS, 2016.
  • [93] D. Yao, N. Fazio, Y. Dodis, and A. Lysyanskaya. ID-based encryption for complex hierarchies with applications to forward security and broadcast encryption. In CCS, 2004.
  • [94] W. Ye, J. Heidemann, and D. Estrin. An energy-efficient MAC protocol for wireless sensor networks. In INFOCOM, 2002.
  • [95] S. Yu, C. Wang, K. Ren, and W. Lou. Achieving secure, scalable, and fine-grained data access control in cloud computing. In INFOCOM, 2010.
  • [96] T. Zachariah, N. Klugman, B. Campbell, J. Adkins, N. Jackson, and P. Dutta. The Internet of things has a gateway problem. In HotMobile, 2015.
  • [97] Zigbee gateway. Feb. 13, 2019.

Appendix A JEDI’s Optimizations to WKD-IBE

The purpose of Appendix A is twofold. First, it largely reproduces the construction of WKD-IBE provided in §3.2 of [1], which we used in JEDI, for readers who would like additional context. Second, it fully explains the “Precomputation with Adjustment” optimizations (§3.6.2) that JEDI uses for fast encryption and signatures on low-power platforms.

a.1 Construction with our Optimizations

We present the WKD-IBE construction in §3.2 of [1]. For completeness, we include the extension to signatures described in §4.2, as well as our observation in §3.1 that the encryption algorithm in [1] can be extended to work with arbitrary patterns.

The construction is based on bilinear groups. and are cyclic groups of prime order , and they are related by a bilinear map . The security parameter is related to the number of bits of . We implemented WKD-IBE using BLS12-381, an asymmetric bilinear group whose bilinear map is of the form . We denote the smaller and faster of the two source groups (elliptic curve over ). The construction of WKD-IBE was originally defined for symmetric bilinear groups. Our description of the construction below shows how we mapped the construction onto an asymmetric bilinear group.

: Select and . Then select and let . Output:

and .

: If is the master key, take . Select . The private key for the pattern is the following triple:

If is not the master key, then parse as , where . Select . The private key for is:

Observe that the resulting key is identically distributed, regardless of whether or not the input key is the master key.

: Here, . Select and output

: Parse the key as , and the ciphertext as . Output

To support encryption over arbitrary patterns (§3.1), we only compute the product over fixed slots, just as is done in the BBG HIBE construction [18]. In contrast, the original WKD-IBE construction requires all slots in the pattern to be fixed, and iterates over all slots. The proof technique from [18]

, namely padding the selected ID with zeros, can be used here to modify the proof of WKD-IBE 

[1] to account for our optimization that allows free slots to be used in encryption.

a.2 Construction of WKD-IBE Signatures

We originally explained anonymous signatures in §4.2.1 by (1) dedicating one of the slots in a pattern for signing messages, and (2) defining signature generation as a call to that fills that dedicated slot. We then proposed improvements to the signature scheme, to make it constant size (§4.2.2) and make the verification procedure more efficient (§4.3). We formally describe our optimizations to the signature algorithm below. Note that we added an extra term to the public parameter that represents the slot dedicated to signing messages, and an analogous element (, ) to the third component of each secret key. It was not present in the original WKD-IBE construction, and is not used for encryption in Appendix A.1.

: Parse the key as , where . Let be the pattern corresponding to . Select and output

: Parse the signature as . Check:

In contrast to optimized procedures above, the naïve signature algorithm has , and for , where is the same as except that , the message being signed. The modification we make is that (1) the signature contains only the first two components of (since the third component is not used for decryption), and (2) the verification procedure checks that is a private key corresponding to more efficiently than encrypting and decrypting a random message.

Finally, note that the Sign function can be generalized to allow a key with pattern to produce a signature for pattern if matches . This can be done trivially by first applying KeyDer to obtain a key for , and calling the Sign on the existing key. Our implementation supports this GeneralizedSign functionality more efficiently, as follows:

: Parse the key as , where . Select and output

a.3 Precomputation with Adjustment

We formally explain the precomputation optimization introduced in §3.6.2 and §4.3.

a.3.1 Precomputation with Adjustment for Encryption

We define the new WKD-IBE operations as follows (as before, is an implicit parameter):

: Output

: is the existing precomputed value, is the pattern it corresponds to, and is the pattern whose precomputed value to compute. Output

: Here, . Select and output

The above routines are used as described in §3.6.2. Observe that the output of and the output of are distributed identically—security of this optimization relies on this fact.

a.3.2 Precomputation with Adjustment for Signatures

As explained in §4.3, we think of in two parts, and :

: Parse as , where . Output:

: Parse as . Sample and output

and are the “two parts” of in the sense that where the distributions are over the sampled randomness.

We can take advantage of these functions to accelerate signing of messages. Note the similarity between and . The setup we consider is that a principal has a key for some pattern representing a URI prefix and time prefix. It will repeatedly sign messages with a pattern representing at a fully-qualified URI and specific time, where matches . The next signature will be on pattern which shares the same URI as but corresponds to the next leaf in the time tree. The naïve algorithm is to call to obtain a key for and then call . The key idea behind the optimization is to instead call to obtain a pseudo-key for (which is not safe to delegate), and then create a signature for that. Observe that the resulting signature is distributed in exactly the same way whether the naïve or optimized method is used. (§4.3, which explains as simply being a call to , explains this technique as splitting into two parts, and .)

Now that we have described the signature process in terms of two calls, one to and another to , we describe how to apply Precomputation with Adjustment to each of these operations. can be accelerated using the same precomputed value we used to accelerate encryption. We have already shown how to “adjust” this precomputed value from to .

: Parse the key as . Let be the pattern corresponding to ; must be the precomputed value corresponding to . Select and output:

Finally, we explain how the result of can be adjusted from pattern to pattern . The procedure also requires the parent key (whose pattern we denote ), on which was called to obtain the key corresponding to pattern .

: Parse the parent key as as where . Parse the child key as . is the pattern corresponding to , and is the pattern that the resulting key will correspond to. Output:

To sign a message each hour, JEDI maintains the result of , (as it does for encryption), and also the result of , , derived from its key. Then it adjusts both values, using and , when the pattern used to sign changes. To sign a message , it computes .

As an additional optimization, we only compute the first two elements of the output of and when using it to produce signatures.

Appendix B Revocation in JEDI using the SD Method

The SD algorithm for tree-based broadcast encryption is introduced in prior work [72, 40]. In this section, we explain how to extend SD algorithm to support delegation. We follow the same approach to apply this extension in JEDI as we did for the CS method in §5.

b.1 Overview of SD Method

We first provide a brief overview of the SD method, as described in [40]. Both the CS and SD method use a technique called Subset Cover. Let be the (finite) set of all users. A family of subsets is defined over . Each each element of is a subset of , and corresponds to a keypair (, ). Each user is given the secret key for every set containing that user. Now, suppose that someone wants to encrypt a message such that it is visible only to a subset of users, denoted . To achieve this, she must find a subset cover for : sets such that . Then, she encrypts her message under the public key for each in the subset cover. Only users in have the secret key for one of the to decrypt the message.

The CS method (as described in §5.3) uses a subset family , where each subset is a complete subtree of the binary tree over the users. The SD method uses a different subset family than the CS method, in which each leaf belongs to more subsets. Each subset is defined in terms of two nodes, and , where is a descendant of . contains all leaves in the subtree rooted at but not in the subtree rooted at . Each leaf now belongs to different subsets, and therefore has secret keys.

Each subset is associated with an ID in HIBE as follows. The first component of the ID is . The remaining components of the ID are , where each bit occupies one component, which makes it possible to generate the private key for from the private key for , as long as is a descendant of .

If a leaf belongs to both and , it only needs to be given . With this optimization, each leaf only has HIBE secret keys.

For encryption, the sender must find a subset cover over all unrevoked leaves, as in the CS method. The algorithm for finding the optimal subset cover is introduced in [72]. [72] also proves that only subsets (and therefore encryptions) are needed.

b.2 Extension of SD Method for Delegation

We follow the same idea in §5.3 that each key corresponds to a range of consecutive leaves, and the delegation and revocation follow the same rule. In contrast to CS method, we use WKD-IBE instead of HIBE to reduce the storage requirement.

b.2.1 Analysis of Private Key Storage

A principal with a set of consecutive leaves denoted must be able to generate private keys for all subsets where .

We define as the set of leaves in the subtree rooted at , and as in a Merkle Tree [71]. Then define as follows: