JEDI: MANY-TO-MANY END-TO-END ENCRYPTION AND KEY DELEGATION FOR IOT - SAM KUMAR, YUNCONG HU, MICHAEL P ANDERSEN, RALUCA ADA POPA, DAVID E. CULLER ...
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
JEDI: Many-to-Many End-to-End
Encryption and Key Delegation for IoT
Sam Kumar, Yuncong Hu, Michael P Andersen, Raluca Ada Popa, David E. Culler
University of California, Berkeley
IoT Devices Collect Privacy-Sensitive Data
Lighting
Occupancy
Sensor
Border Router Message Broker Device Gateway
Intermediaries
Video Doorbell Smart Speaker/Virtual
Assistant
2
IoT Devices Collect Privacy-Sensitive Data
Lighting
Occupancy
Sensor
Border Router Message Broker Device Gateway
Intermediaries
Video Doorbell Smart Speaker/Virtual
Assistant
Want End-to-End Encryption (E2EE)
3
Existing E2EE is a Poor Fit for Large-Scale IoT
• Large-scale IoT systems use the publish/subscribe paradigm
4
IoT Systems use Publish/Subscribe
Sub sodaHall/atrium/*
Pub/Sub Broker Bob
Temperature
Sensor
Cloud Services
5
IoT Systems use Publish/Subscribe
Lighting
Alice
Pub sodaHall/room465F/occupancy
Sub sodaHall/atrium/*
Occupancy
Sensor
Sub sodaHall/ Bob
Pub/Sub Broker
atrium/hvac
Temperature
Sensor
Heating, Ventilation,
and Cooling Cloud Services
6
IoT Systems use Publish/Subscribe
Who is allowed to
read which resources?
Lighting
Alice
Pub sodaHall/room465F/occupancy
Sub sodaHall/atrium/*
Occupancy
Sensor
Sub sodaHall/ Bob
Pub/Sub Broker
atrium/hvac
Temperature
Sensor
Heating, Ventilation,
and Cooling Cloud Services
7
IoT Systems use Decentralized Delegation
Delegate Delegate
Access to Access to Access to
sodaHall/* sodaHall/room410/* sodaHall/room410/lamp0/*
until May 2021 until January 2020
• Decentralized delegation is an old idea (SPKI/SDSI [CECF01])
• It’s the state-of-the-art for access control in large-scale IoT systems
(e.g., Vanadium [TS16], BOSSWAVE [AKCCK17])
8
IoT Devices are Resource-Constrained
Server/Workstation/Laptop Smartphone Smart Home Appliance Wearable Ultra Low-Power Deeply
Embedded Sensor
More Powerful Less Powerful
100,000 DMIPS 50 DMIPS
10 GiB RAM 32 KiB RAM
Power Constraints
9
JEDI: Joining Encryption and
Delegation for IoT
10Joining Encryption and Delegation for IoT
JEDI is an end-to-end encryption (E2EE) protocol that:
• Allows senders and receivers to be decoupled as in publish/subscribe
• Supports decentralized delegation
• Can run on resource-constrained IoT devices
11Roadmap
1. Requirements of large-scale IoT systems
2. JEDI’s approach
a) Encryption in the new model (pub/sub, delegation)
b) Finding a suitable, lightweight encryption scheme
c) Anonymous signatures
d) Revocation
3. Empirical study
12Roadmap
1. Requirements of large-scale IoT systems
2. JEDI’s approach
a) Encryption in the new model (pub/sub, delegation)
b) Finding a suitable, lightweight encryption scheme
Focus of this talk
c) Anonymous signatures
d) Revocation
3. Empirical study
13Publish/Subscribe in JEDI
Problem: How to encrypt?
Central Idea: Encrypt each
message according to the
Lighting
resource it is published to Alice
Pub sodaHall/room465F/occupancy
sodaHall/atrium/temp
Sub sodaHall/atrium/*
Data
Occupancy
Sensor
Sub sodaHall/ Bob
Pub/Sub Broker
atrium/hvac
Temperature
Sensor
Heating, Ventilation,
and Cooling Cloud Services
14Publish/Subscribe in JEDI
Problem: How to encrypt?
Central Idea: Encrypt each
message according to the
Lighting
resource it is published to sodaHall/atrium/temp Alice
Pub sodaHall/room465F/occupancy
Data Sub sodaHall/atrium/*
Occupancy
Sensor
Sub sodaHall/ Bob
Pub/Sub Broker
atrium/hvac
Temperature
Sensor
Heating, Ventilation,
and Cooling Cloud Services
15Publish/Subscribe in JEDI
Problem: How to encrypt?
sodaHall/atrium/temp
Central Idea: Encrypt each
message according to the
Lighting Data
resource it is published to Alice
Pub sodaHall/room465F/occupancy
Sub sodaHall/atrium/*
Occupancy
Sensor
Sub sodaHall/ Bob
Pub/Sub Broker
atrium/hvac
sodaHall/atrium/temp
Temperature
Sensor Data
Heating, Ventilation,
and Cooling Cloud Services
16Publish/Subscribe in JEDI
Problem: How to encrypt?
sodaHall/atrium/temp
Central Idea: Encrypt each
message according to the
Lighting Data
resource it is published to Alice
Pub sodaHall/room465F/occupancy
Sub sodaHall/atrium/*
Occupancy
Sensor
Sub sodaHall/ Bob
Pub/Sub Broker
atrium/hvac
sodaHall/atrium/temp
Temperature
Sensor Data
Heating, Ventilation,
and Cooling Cloud Services
17Publish/Subscribe in JEDI
Lighting
Alice
Pub sodaHall/room465F/occupancy
Sub sodaHall/atrium/*
Occupancy
Sensor
Sub sodaHall/ Bob
Pub/Sub Broker
atrium/hvac
Temperature
Sensor
Heating, Ventilation,
and Cooling Cloud Services
18Publish/Subscribe in JEDI
Lighting Q: How to control which
Person A
principals have which
Pub sodaHall/room465F/occupancy
Sub sodaHall/atrium/*
decryption keys?
Occupancy
Sensor A: Decentralized delegation
Sub sodaHall/
Pub/Sub Broker Person B
atrium/hvac
Temperature
Sensor
Heating, Ventilation,
and Cooling Cloud Services
19Decentralized Delegation [CECF01, AKCCK17]
Building LabBuilding
Director can
Manager can Manager can
read sodaHall/
read sodaHall/* read floor4/*
sodaHall/*
Campus Facilities Manager Building Manager Lab Director
temperature
floor3 atrium humidity
sodaHall lab_space
floor4 lighting
alice_office
hvac
(Root)
LabBuilding
Director can
Trust sensor0 Alice
Manager cancan
read
floor2 lighting read sodaHall/
sodaHall/floor4/
Domain room299 read sodaHall/*
floor4/*
alice_office/*
coryHall hvac
swarm_lab
floor4 Alice
room400 occupancy
20Decentralized Delegation in JEDI
Key for * Key for sodaHall/* Key for sodaHall/floor4/*
Campus Facilities Manager Building Manager Lab Director
temperature
floor3 atrium humidity
sodaHall lab_space
floor4 lighting
alice_office
hvac
(Root)
Trust sensor0 Key for sodaHall/floor4/
floor2 lighting alice_office/*
Domain room299
coryHall hvac
swarm_lab
floor4 Alice
room400 occupancy
21Instantiating JEDI Using
Attribute-Based Encryption (ABE [GPSW06])
Set aside efficiency for the moment
22Preliminary JEDI Design Using ABE
Lighting Encrypt message using ABE
with the three attributes Person A
“1-sodaHall, 2-atrium, 3-temp”
Pub sodaHall/room465F/occupancy
Sub sodaHall/atrium/*
Occupancy
Sensor
Sub sodaHall/ Person B
Pub/Sub Broker
atrium/hvac
Temperature
Sensor
Heating, Ventilation,
and Cooling Cloud Services
23Preliminary JEDI Design Using ABE
Generate
Key for * Key for sodaHall/* Key for sodaHall/floor4/*
Campus Facilities Manager Building Manager Lab Director
ABE key for the policy ABE key for the policy
temperature
“1-sodaHall” “1-sodaHall AND 2-floor4”
floor3 atrium humidity
sodaHall lab_space
floor4 lighting
alice_office
hvac
(Root)
Trust sensor0 Key for sodaHall/floor4/
floor2 lighting alice_office/*
Domain room299
coryHall hvac
swarm_lab
floor4 Alice
room400 occupancy
24Expiry
25Encrypt Using Current Time
Encrypt message using ABE with
Lighting
the six attributes
Person A
“1-sodaHall, 2-atrium, 3-temp,
Pub sodaHall/room465F/occupancy
year-2019, month-Aug, day-16” Sub sodaHall/atrium/*
Occupancy
Sensor
Sub sodaHall/ Person B
Pub/Sub Broker
atrium/hvac
Temperature
Sensor
Heating, Ventilation,
and Cooling Cloud Services
26Time is Another Hierarchy
Hour Day Month Year
Consists of 4 ABE keys:
… … … 2018
start
… 01
Expires Feb 02, 2020 Policy: “year-2019”
… 02 Jan
... … 2019
Policy: “year-2020 AND … … …
(Root)
month-Jan” … 01
… 02 Jan
… …
Policy: “year-2020 AND … 01
month-Feb AND day-01”
… 02 2020
end Feb
… 03
… …
Policy: “year-2020 AND
month-Feb AND day-02” … … …
27Support for Resource-
Constrained Devices
28Hamilton Platform [KACKZMC18]
• Based on the Atmel SAMR21 SoC
• 32-bit ARM Cortex M0+ @ 48 MHz
• 32 KiB Data Memory (RAM)
• Goal: several years of battery life
• $1.00 CR123A Lithium battery
29Energy Cost of ABE
• Due to hybrid encryption, we invoke ABE rarely (e.g., once per hour)
• Regardless, ABE dominates power consumption
• ABE takes 4 minutes on Hamilton → battery won’t even last 100 days
30Choosing a More Efficient Encryption Scheme
BE [FN94, BGW05] WIBE [ACDMNS06] CP-ABE [BSW07] RIBE [BGK08]
RSA Fuzzy-IBE [SW04]
RHIBE [SE14]
IBE [BF01] MRQED [SBCSP07] KP-ABE [GPSW06]
El Gamal WKD-IBE [AKN07] FHE [Gentry09]
Regev HIBE [GS02, BBG05] IPE [KSW08]
ke-PKE [CHK03] Multi-Authority ABE [LW11] HABE [WLWG11]
HVE [BW07] DP-ABE [AI09]
PRE [BBS98, AFGH05] IDTHD [BY04] PKE-IP [ABCP15]
AIBE [Gentry06]
AHIBE [BW06] IB-PRE [GA07] HIBBE [LLWQ14] HPE [LOSTW10] RHIBBE [LLZWL18]
We identify WKD-IBE:
IBBE [SF07, Delerablée07, GW09] RR-IBBE [SCGYMC16]
• More efficient than ABE, but much less flexible
• Flexible enough to realize JEDI, if used carefully
31Summary of WKD-IBE [AKN07]
• Each ciphertext or key encodes a vector of strings and wildcards
foo bar baz * qux quux * quuz corge
• A key can decrypt a ciphertext if their vectors match
• Given a key, one can generate a new key with some wildcards
replaced with strings
32Summary of WKD-IBE [AKN07]
• Each ciphertext or key encodes a vector of strings and wildcards
foo bar baz * qux quux * quuz corge
Generate
Replaced
foo bar baz grault qux quux * quuz corge
• A key can decrypt a ciphertext if their vectors match
• Given a key, one can generate a new key with some wildcards
replaced with strings
33How JEDI Uses WKD-IBE
• JEDI encodes multiple concurrent hierarchies into WKD-IBE’s vector
• Private key for sodaHall/room410/*, valid for August 2019:
sodaHall room410 * * * 2019 Aug * *
First ℓ1 components for Resource Hierarchy Last ℓ2 components for Time Hierarchy
• For decentralized delegation, we can generate a private key for
sodaHall/room410/light0/*, valid for August 16, 2019
34How JEDI Uses WKD-IBE
• JEDI encodes multiple concurrent hierarchies into WKD-IBE’s vector
• Private key for sodaHall/room410/*, valid for August 2019:
sodaHall room410 * * * 2019 Aug * *
Generate
sodaHall room410 light0 * * 2019 Aug 16 *
• For decentralized delegation, we can generate a private key for
sodaHall/room410/light0/*, valid for August 16, 2019
35Cryptographic Improvements to WKD-IBE
Existing WKD-IBE Encryption Algorithm [AKN07]
Message Observation: adjacent
Encryption
WKD-IBE
Ciphertext
encryptions in JEDI differ
Attribute Vector
in only a few attributes
JEDI’s New WKD-IBE Encryption Algorithm
Message Idea: encrypt according
Encryption
State to the delta from the
Delta
Previous State
Ciphertext previous attributes
Changed Attributes
36Roadmap
1. Requirements of large-scale IoT systems
2. JEDI’s approach
a) Encryption in the new model (pub/sub, delegation)
b) Finding a suitable, lightweight encryption scheme
Focus of this talk
c) Anonymous signatures
See paper for details
d) Revocation
3. Empirical study
39Roadmap
1. Requirements of large-scale IoT systems
2. JEDI’s approach
a) Encryption in the new model (pub/sub, delegation)
b) Finding a suitable, lightweight encryption scheme
c) Anonymous signatures
d) Revocation
3. Empirical study
40Implementation
Two parts of JEDI’s implementation:
1. JEDI Cryptography Library (https://github.com/ucbrise/jedi-pairing)
• Includes assembly optimizations for ARM Cortex-M0+ (also x86-64, ARMv8)
• 4-5x performance improvement over pure C/C++ on Hamilton
2. JEDI Protocol Prototype (https://github.com/ucbrise/jedi-protocol)
• Implemented for bw2 [AKCFCP17], a messaging system for smart cities
41JEDI Applied to bw2 (Running on a Laptop)
• Most of JEDI’s overhead comes No E2EE NaCl + Padding WKD-IBE
from the symmetric-key crypto 70
Time to Publish (ms)
library (NaCl secretbox) 60
50
40
• JEDI’s overhead is ≈ 10 ms for 30
small messages 20
10
0
1 KiB 32 KiB 1 MiB
Running on a
Laptop
Message Size
42Estimated Battery Life on a Hamilton Sensor
AES Only JEDI ABE (estimated) • Each encryption with JEDI is 37x
6 more efficient than naïvely
5
applying ABE
Battery Life (Years)
4
3
• JEDI’s battery life, when
sampling once every 10 s, is:
2 • 14x better than using ABE
1 • within 2x of using AES only
• several years long
0
Sampling Data at 0.1 Hz Running on a
Hamilton Sensor
43We are Deploying JEDI in the Real World!
44Conclusion
JEDI is an end-to-end encryption protocol for large-scale IoT systems. It:
• Allows senders and receivers to be decoupled as in publish/subscribe
• Supports decentralized delegation with expiry
• Can run on devices across the spectrum of resource constraints
https://github.com/ucbrise/jedi-pairing
Extended paper: https://arxiv.org/abs/1905.13369
https://github.com/ucbrise/jedi-protocol-go
This material is based on work supported by the National Science Foundation Graduate Research Fellowship Program
under Grant No. DGE-1752814. Any opinions, findings, and conclusions or recommendations expressed in this material
are those of the authors and do not necessarily reflect the views of the National Science Foundation. 45You can also read
