JEDI: Many-to-Many End-to-End Encryption and Key Delegation for IoT
Background
端到端加密的需求：
大型物联网系统中因为多个主体通常通过中介进行间接交互，这意味着无法提前知道消息的接收者。物联网设备通常会收集用户的隐私敏感信息。保护隐私敏感数据的一个自然步骤是在传输过程中使用端到端加密来保护它。现有的端到端加密协议(如SSL/TLS和TextSecure)侧重于两个主体之间的一对一通信:例如，Alice通过不安全的通道向Bob发送消息。然而，这种协议似乎不适用于大规模工业物联网系统。这样的物联网系统需要在已解耦的发送方和接收方之间进行多对多通信，并且需要分散的访问授权来强制哪些设备可以与哪些设备通信。
我们调查了现有的物联网系统，这些系统目前没有端到端加密数据，以了解像JEDI这样的端到端加密协议的需求。我们将智能城市作为一个示例应用领域，将大型组织中的数据收集传感器作为一个具体的用例。我们确定了三个中心需求，下面依次讨论
- 发送方与接收方解耦。iot级系统可能包含数千个主体，这使得数据使用者(例如，应用程序)无法与每个数据生产者(例如，传感器)保持单独的会话。相反，发送方通常与接收方解耦。这种脱钩在物联网的发布-订阅系统中很常见，如MQTT、AMQP、XMPP和Solace[76]。特别是，基于发布-订阅的多对多通信是智能建筑中事实上的标准，在BOSS[36]、VOLTTRON[82]、Brume[66]和bw2[5]等系统中使用，并在AllJoyn和IoTivity中被商业化采用。发送者通过将消息寻址到资源并将其发送到路由器来发布消息。接收方通过请求路由器向其发送发送到该资源的消息来订阅该资源。
- 分散授权。例如，如果Bob有一个应用程序需要访问单个传感器的温度读数，那么该应用程序应该只接收该URI的解密密钥，即使Bob拥有整个房间的密钥。在IoT-scale系统中，中央机构无法对每个人的设备分别提供细粒度的解密密钥。此外，正如我们在第二部分中所讨论的，这种方法会增加安全性和隐私风险。Bob自己可以访问整个房间的读数，他应该能够将温度读数的访问权限分配给应用程序。通常，一个可以访问一组资源的主体可以让另一个主体访问这些资源的子集。
- 资源受限。物联网设备的性能差异很大。这包括CPU、内存和能量受限的设备，如可穿戴设备和低成本环境传感器。加密的功耗是一个严重的挑战，甚至比它在较慢的CPU上的延迟更严重;CPU和收音机必须谨慎使用，以避免过快消耗能量[55,89]。例如，在我们评估中使用的传感器平台上，即使使用传感器和网络的电源成本为零，平均CPU使用率仅为5%也会导致不到一年的电池寿命。
Overview
本文介绍了一种符合上述三种物联网系统要求的多对多端到端加密协议JEDI。JEDI对消息进行端到端的加密以保证机密性，在保证匿名性的同时对消息进行完整性签名，并支持带有警告的委托，同时允许发送方和接收方通过一个资源层次结构来解耦。JEDI与现有的加密协议(如SSL/TLS)不同，需要我们克服许多挑战
JEDI’s System Model
JEDI的参加者被称为首领。任何主体都可以创建一个资源层次结构来表示它所拥有的一些资源。因为该主体拥有层次结构中的所有资源，所以它被称为该层次结构的权威.
由于已解耦的发送方和接收方的设置，发送方不能再像传统的端到端加密那样使用接收方的公钥加密消息。相反，JEDI建模的原则是与资源交互，而不是与其他主体交互。这里存在JEDI模型和其他端到端加密协议之间的关键区别: 消息的发布者根据消息发布到的URI对其进行加密，而不是订阅该URI的接收者。只有被允许订阅URI的主体才会被授予密钥，这些密钥可以对发布到该URI的消息进行解密。
支持分散授权的物联网系统(Vanadium、bw2)以及相关的非物联网授权系统(如SPKI/SDSI[31]和Macaroons[13])为主体提供令牌(如证书链)，这些令牌可以用来证明它们可以访问某个资源。然而，提供令牌对于端到端加密来说是不够的;与这些系统不同，JEDI允许通过代表团链分发解密密钥。此外，可以在每个委托上限制与每个密钥关联的URI前缀和过期时间。例如，如图2所示，假设Alice在一个研究实验室工作，需要访问她办公室的传感器读数。在过去，校园设施经理是这个层级的权威，他把buildingA/*的钥匙授予了建筑经理，而建筑经理又把buildingA/floor2/**的钥匙授予了实验室主任。现在，Alice可以直接从她当地的权威机构(实验室主任)那里获得buildingA/floor2/alice_office/**的钥匙。
Encryption with URIs and Expiry
JEDI支持解耦通信。消息发布到的资源充当发送方和接收方之间的集合点，底层系统使用它来路由消息。JEDI的核心挑战是找到一个类似的密码学集合点，发送者可以使用它来加密信息，而不需要知道接收者的信息。许多物联网系统[70、74]只使用像AES、SHA2和ECDSA这样的简单密码，但这些原语不足以表达对JEDI集合点的编码，JEDI中的集合点必须支持分级结构的资源、非交互失效和分散的授权。
现有与JEDI相似[的系统[83 85]使用基于属性的加密(ABE)[12,48]。不幸的是，ABE不适合JEDI，因为它太贵了，尤其是在物联网设备资源紧张的情况下。一些物联网系统仅因为其延迟就将其排除在外[74]。在低功耗设备的情况下，使用ABE进行加密也会消耗过多的功耗。JEDI用两个观点来回避使用ABE或基本密码术的问题:(1)虽然ABE对于低功率设备来说太重了，但这并不意味着我们必须只使用对称密钥技术。我们证明，某些IBE方案[1]可以用于此类设备。(2)时间是另一种资源层次结构:时间戳可以表示为年/月/日/小时，在这种层次结构中，任何时间范围都可以有效地表示为子树的对数数量。有了这一认识，我们可以通过非标准地使用某种类型的IBE方案(WKD-IBE[1])来同时支持uri和过期。像ABE一样，WKD-IBE是基于双线性群(配对)，但它的数量级比ABE要便宜。为了使JEDI在低功率设备上实用，我们设计它很少调用WKD-IBE，而大部分时间依赖于AES，很像会话密钥。因此，JEDI实现了与物联网系统相当的表达能力，而物联网系统不加密数据，因此比AESonly解决方案更具有表达能力，同时允许低功耗低成本物联网设备的电池寿命为几年。
完整性和匿名
除了加密之外，还应该对消息进行签名，以便消息的接收者能够确保消息不是由攻击者发送的。这可以通过证书链实现，如SPKI/SDSI或bw2。证书可以像图2中的加密密钥一样分散分布。然而，如果需要匿名，证书链是不够的。例如，考虑一个在每个办公室中都有占用传感器的办公空间，每个办公室都发布到相同的URI buildingA/占用。总的来说，占用传感器可以用于通知，例如，建筑物内的加热/冷却，但是单独来说，每个房间的读数被认为是隐私。不同房间的占用传感器可以使用不同的证书链，如果它们是由不同的人授权/安装的。这可以用来消除占用数据的匿名性。为了解决这一挑战，我们采用了用于端到端加密的WKD-IBE方案，以实现能够编码URI和过期的匿名签名方案，并支持分散授权。使用这种技术，匿名签名甚至在低功耗的嵌入式物联网设备上也很实用。
撤销
如上所述，JEDI密钥支持过期。因此，可以通过赋予每个密钥较短的有效期并定期对其进行更新来延长有效期，从而实现轻量级的撤销方案。要撤销密钥，只需不更新它。我们期望这种基于到期的撤销对于大多数用例都是足够的，特别是对于低功耗设备，它们通常只是感知和发送。以密码方式强制执行撤销，而不依赖于过期，这是一个挑战。正如我们在5中所讨论的，任何提供立即撤销的加密强制方案(即在加密消息时，消息的发送方必须知道哪些接收方被撤销，这是一个基本的限制。JEDI提供了一种立即撤销的形式，受此约束。我们使用基于树的广播加密技术[37,67]进行加密，使该URI的所有解密密钥(撤销列表中的密钥除外)都可以用于解密。实现这一点很重要，因为我们必须将广播加密与JEDI的分级资源、过期和委托语义结合起来。首先，我们修改广播加密以支持委托，这样，如果一个密钥被撤销，所有使用该密钥的委托也将被隐式地撤销。然后，我们以非黑盒的方式将广播撤销与JEDI的加密和委托集成在一起，作为与uri和过期一起的第三种资源层次结构
JEDI’s Model and Threat Model
主体可以根据资源的URI、层次结构的公共参数和当前时间对资源进行加密，然后将消息传递给底层系统，底层系统将消息传递给相关订阅者，从而向层次结构中的资源发布消息。给定一个资源子树和时间范围的密钥，一个主体可以为这些资源的子集和该时间范围的子范围生成一个密钥，并将其交给另一个主体，如图2所示。接收主体可以使用委托的密钥来解密在子范围内每次发送到该子集中的资源的消息。
Compare
为了更好地理解JEDI的好处，考虑一下可信密钥服务器模式。这个密钥服务器为每个URI和时间生成一个密钥。发布者使用相同的密钥加密该URI的每个消息。订阅者从可信密钥服务器请求此密钥，该服务器必须首先检查订阅者是否被授权接收此密钥。订阅者可以使用此密钥解密URI消息，并在密钥过期时联系密钥服务器获取新密钥。JEDI比关键服务器模式更好，如下所示
- 改进的安全。与必须始终在线的可信密钥服务器不同，JEDI中的权威可以将合格的密钥委派给某些主体，然后脱机，让这些主体进一步进行限定和委派密钥。当授权处于离线状态时，由于只需要很少访问，攻击者很难对其进行攻击，同时也更容易保护其机密。这种推理是根证书颁发机构(CAs)的基础，它很少访问它们的主密钥。相反，可信密钥服务器模型要求中央可信方(密钥服务器)处于联机状态，以授予/撤销对任何资源的访问权。
- 改进的隐私。每一个参与者看到所有代表团都穿着JEDI的服装。JEDI中的敌手如果窃取了某个权威的秘钥，可以解密该层级的所有消息，但仍然不知道谁可以访问哪个资源，也无法访问第一个权威无法访问的单独的层级。相反，破坏密钥服务器的对手知道谁有权访问哪个资源，并且可以为所有层次结构解密消息。
- 提高可伸缩性。在上面的校园物联网的例子中，如果一个管理员接收到所有的传感器和所有不同的建筑物读数，管理员必须获得一个潜在的非常大的数量的钥匙，而不是整个建筑物的一个钥匙。此外，校园范围的密钥服务器需要向大学中每个员工或学生拥有的每个应用程序授予解密密钥。最后，全校范围的密钥服务器必须理解在层次结构的较低级别允许哪些委托，这要求整个层次结构集中管理。
End-to-End Encryption in JEDI
本节回答的一个中心问题是:发布者在将消息传递到底层系统进行传递之前应该如何加密消息(3.4)?正如在1.1.2中所解释的那样，尽管对于低功耗设备来说，最明显的选择ABE太重了，但我们认为WKD-IBE(一种更轻量级的基于身份的加密方案)足以实现JEDI的特性。主要的挑战是在WKD-IBE ID(称为模式)中编码一个充分表达的集合点，发布者使用该集合点加密消息
Building Block: WKD-IBE
WKD-IBE( identity-based encryption with wildcard key derivation) 基于身份的加通配符密钥派生的加密. 它通过允许更通用的密钥委托模式来增强基于身份的分层加密(HIBE)的概念。为标识字符串向量派生了一个秘密密钥，其中可以使用通配符将条目留空。然后可以使用此键派生任何模式的键，这些模式使用具体的标识字符串替换通配符。例如，您可能希望允许大学的首席系统管理员为所有部门的sysadmin电子邮件地址sysadmin@.univ.edu派生密钥(因此能够解密)，其中是可以用任何字符串替换的通配符。
In WKD-IBE, messages are encrypted with patterns, and keys also correspond to patterns. A pattern is a list of values.
Overview of Encryption in JEDI
在向URI发送消息之前，sender使用WKD-IBE加密消息。用于加密它的模式来自URI和当前时间(3.4)，它们与密文一起包含在其中。当receiver接收到一条消息时，它使用密文中包含的URI和时间来搜索其密钥存储库，以查找用于解密的密钥。
Encrypt(Message;URI;Time) -> Ciphertext 加密
Decrypt(Ciphertext;URI;Time;KeyStore) -> Message 解密
Delegate(KeyStore;URIPrefix;TimeRange) -> KeySet 委托
AcceptDelegation(KeyStore;KeySet) -> KeyStore' 接受委托
Optimizations for Low-Power Devices （WKD-IBE与AES混合）
在低功耗的嵌入式设备上，执行单个WKDIBE加密将消耗大量的能量。因此，我们优化了WKD-IBE。
JEDI在混合加密方案中使用WKD-IBE。要在JEDI中加密消息m，可以对对称密钥k进行采样，然后用WKD-IBE的密钥对k进行加密以产生密文c1。然后，一个k加密m来产生密文c2。密文是(c1;c2)。对于后续消息，可以重用k和c1;用k对新消息进行加密，生成一个新的c2。您可以继续重用k和c1，直到WKD-IBE模式进行加密更改为止，这种更改在每个小时结束时发生(或用于到期的其他间隔)。此时，JEDI通过选择一个新的k来执行密钥旋转，使用WKD-IBE对其进行加密，然后像以前一样继续操作。因此，大多数消息只使用廉价的对称密钥加密。这也减少了receiver的负载。由sender在一小时内发送的密文将共享相同的c1。因此，订阅者可以对第一个消息解密一次以获得k，并缓存从c1到k的映射，以避免对在该小时内发送的未来消息进行昂贵的WKD-IBE解密。因此，昂贵的WKD-IBE操作仅在键旋转时执行，这种情况很少每小时发生一次(或为过期选择其他粒度)。