采用多方计算(MPC)的物联网安全性

摘要

公开了用于沿着第一设备(200A)和第二设备(200B)之间的通信信道建立通信的方法和设备。该方法包括相互发现第一设备(200A)和第二设备(200B)，通过交换数据消息来验证(F5，F6，F7)第一设备(200A)和第二设备(200B)之间的通信信道，在第一设备(200A)和第二设备(200B)之间交换秘密，以及随后沿着通信信道交换加密消息。

说明书

本申请要求于2018年5月16日提交的葡萄牙专利申请号20181000034529和2018年5月25日提交的欧洲专利申请号18174412.9的优先权和权益。

背景技术

物联网(IoT)是在未来几年技术将如何与人交互的概念。它是连接到网络(例如私有因特网和/或公共因特网)的“物”或设备的集合，其中“智能”设备不仅与人交互，还彼此交互。Gartner的研究组织发布的数据预测到2020年将有250亿(美国)这样的智能设备连接到因特网。这些物理和虚拟“物”具有身份、物理属性、虚拟个性，并且在没有直接人工干的情况下，通过过程基本上自主地对现实/物理世界中影响这些事件的事件作出反应。

由于该领域的指数增长，存在一些隐私和安全挑战。特别是，需要使安全解决方案适应IoT设备的特定特性。IoT设备中存在资源限制，这是常规设备中没有的[参考文献1]。这些包括IoT设备中的有限的电池寿命和存储空间。IoT设备必需的安全和隐私要求的集合包括但不限于用户和设备身份管理、认证、在不同IoT设备之间的通信中交换的数据的机密性、仅允许授权的某些IoT设备可以访问IoT网络的网络访问控制，以及资源和系统的可用性[参考文献2]。

迄今为止，大多数研究和现有的IoT平台都专注于设备管理，并采用可信任的集中解决方案用于认证和安全。这些集中解决方案基于公钥基础架构(PKI)。尽管使用PKI具有明显的优势，但基于PKI的解决方案却趋于复杂、昂贵且不易于管理[参考文献4]。另外，连接到基于PKI的网络的设备存在上述资源限制。

IoT设备的物理安全也被认为是一个问题，因为存储在IoT设备上的存储器中的任何密钥都可以从物理捕获的IoT设备上读取，并被对手用来发起对其中并入IoT设备的IoT网络的攻击[参考文献3]。

PKI仅依赖证书授权(CA)来验证网络(例如上述IoT网络)中的安全证书。CA代表了网络基础架构中的单个故障点。尽管已知故障点存在于各种协议中，但非常希望这些故障点不应该是唯一的或集中的(例如在CA中)，以使网络对网络上的任何攻击具有更强的恢复能力。如果公开了CA的私钥，则PKI将完全不可逆转地受到损害。任何获得私钥的攻击者都可以轻松地签发新证书，从而在受损害的网络中冒充并执行所谓的中间人(MitM)攻击。MitM攻击是指当攻击者秘密中继并可能更改网络中两方之间的通信时，否则两方将认为两方实际上是彼此直接通信。例如，在简单公开服务器证书的情况下，打开了所谓的“攻击窗口”，在此期间攻击者可以损坏网络。该攻击窗口保持打开状态，已公开的服务器证书被吊销，这可能不会立即完成，例如，如果一段时间未注意到攻击的话。

已知在PKI中发生的另一个问题是，在未正确验证对特定域的所有权的情况下，管理不善的CA签署了用于特定域的证书。

考虑到上述限制，PKI中的基本假设不一定最适合IoT网络和IoT设备。

Diffie-Hellman(DH)密钥交换是一种在网络中的公共信道上安全地交换加密密钥的方法，并且其基于希望在网络上进行通信的双方之间的共享秘密的建立。DH密钥交换基于以下概念：两方(通常称为Alice和Bob)各自建立对自身保密的秘密参数，以及在两方之间不保密并达成一致的起始参数。起始参数在双方都与秘密参数混合，然后作为公共密钥交换。在交换了公共密钥之后，将公共密钥与自己的秘密参数混合，然后双方都具有可用于通信加密的相同值。不幸的是，由于DH密钥交换不提供通信方的认证，因此DH密钥交换也容易受到MitM攻击。因此，攻击者可以冒充Bob和Alice，即通信各方。

已知几种协议，其中双方可以通过传递并确认短认证字符串(SAS)来确认其身份以彼此直接通信。这些协议包括Z实时传输协议(ZRTP)[参考文献9]和通过Juggling(J-PAKE)进行密码认证的密钥交换[参考文献5和7]，并且基于人工交互和手动配置的前提。但是，这样的已知协议不适合与IoT设备通信，因为该协议基于人工交互，这在IoT设备对之间不切实际。

提供的其他解决方案包括PAKE(密码认证的密钥一致)协议。当前，最复杂的算法不能基于公共密钥加密执行密钥交换，并且允许使用低熵密码。在参考文献6中，讨论了三种最先进的PAKE协议。在同一篇论文中，还公开了两种协议，它们比J-PAKE协议更有效，这两种协议在OpenSSL环境中被用作默认协议。

J-PAKE协议[参考文献5和7]是基于共享密码的概念，它不需要PKI或第三方即可在两方之间建立安全通信。J-PAKE将椭圆曲线DH用于密钥一致和Schnorr非交互式零知识(NIZK)签名[参考文献8]证明机制，用于认证双方并基于口令建立双方之间的共享秘密。有些服务仍在使用J-PAKE协议，例如Pale Moon Web浏览器，Bouncycastle(1.48及以上版本)中的轻量级API以及Thread(物联网无线网络协议)。FireFox Sync、OpenSSH和OpenSSL之前也支持此协议，但2014年后将其删除。

有几个已知的J-PAKE问题，已经由Mohsen Toorani发表[参考文献12]。参考文献12展示了Firefox Sync使用的J-PAKE的分析，并识别出J-PAKE中的漏洞。例如，J-PAKE容易遭受密码泄露模拟攻击，并且在重放和未知密钥共享(UKS)攻击方面还有其他缺点。J-PAKE也已包含在OpenSSL和OpenSSH中，但是在实现期间报告了问题[参考文献25]。

使用短认证字符串的设备配对[参考文献22]是一种基于一致的两设备配对机制，并使用SAS检查秘密的真实性。该协议包括三个阶段：发现、一致和认证。当配对服务启动时，服务器开始发布选定的实例名称。客户端将发现该名称和相应的连接参数[参考文献22]。发现服务器后，客户端和服务器使用传输层安全(TLS)会话，该会话允许客户端和服务器使用产生SAS的加密协议就共享秘密达成一致。完成此阶段后，将有认证阶段，用于通过SAS验证配对。在此认证阶段，通过手动验证对SAS进行比较，即，用户必须验证希望进行通信的两个设备(服务器和客户端)都显示相同的字符串。相反，如果服务器和客户端支持快速响应(QR)代码，则服务器显示带有SAS编码的QR代码，并且客户端能够扫描SAS的值并将扫描的值与本地计算值进行比较。

ZRTP[参考文献9]是两点多媒体通信协议，其包含会话建立阶段，该阶段用于就建立安全实时传输协议(SRTP)会话的密钥交换和参数达成一致。该ZRTP协议不是基于数字证书，而是基于在每个会话中生成的DH密钥(前面已经讨论过)。这些DH密钥有助于生成用于SRTP会话的会话密钥和参数。尽管ZRTP协议最初需要使用信令协议，例如会话发起协议(SIP)，但是密钥协商仅通过ZRTP实现执行。然而，DH算法单独不能提供针对MitM攻击的充分保护。为了在ZRTP协议的密钥交换中对两个对等方进行认证，使用了SAS，该SAS被分发到两个电话，并且在两端进行口头比较。如果SAS相同，则两个用户都必须按下按钮以便接受密钥。

美国专利US 7730309教导了一种用于安全电话协议的方法和系统。该安全电话协议可以包括共享的秘密值，该共享的秘密值被高速缓存，然后在以后重新使用以认证用于区别安全电话呼叫的长串的会话密钥。这实现了加密密钥的连续性，而无需用户进行语音认证。该专利的系统在呼叫建立期间利用了DH密钥交换，因此受到了上述限制。

如上所述，现有解决方案未提供用于在IoT网络中的IoT设备之间交换消息(包括数据)的令人满意的认证和加密方法。

发明内容

需要一种通过交换短认证字符串(SAS)进行自主相互配对的新方法，该短认证字符串不涉及用户为验证SAS和通信信道的安全而进行的人工交互。

本公开教导了在两个设备之间使用多方计算进行具有自主验证的所谓密钥交换的系统和方法。密钥交换用于在任何两方之间建立安全的通信，例如IoT设备，实现IP语音(VoIP)协议的设备或网络中的其他单元。该系统和方法是基于例如Diffie-Hellman(DH)密钥交换。但是，本文中描述的方法和系统不需要PKI或任何受信任的第三方(例如证书授权)的存在。

多方计算(MPC)将其本身作为提供用于构建分散的隐私保护计算框架的基本构建块的合适选项。MPC的目标是使各方能够计算他们自己私有输入的某些联合功能[参考文献13]。该协议必须保留一些安全属性：输出的正确性和输入的私密性，即使某些参与者被主动或被动的恶意对手破坏了[参考文献4]，即不会显示比函数本身输出更多的信息。

本公开的方法如下实现用于沿着第一设备和第二设备之间的通信信道建立通信。第一设备和第二设备是本地设备，并且例如可以是包括多个这样的设备的IoT网络或VoIP网络的成员。VoIP网络中的设备是用于传输基于语音的消息的设备。

该方法包括通过例如在第一设备和第二设备之间交换发起和确认消息来相互发现第一设备和第二设备。这种相互发现可以通过在第一设备和第二设备之间自动交换消息作为直接通信来执行。例如在上述VoIP网络中使用的一种替代方案是使用称为SIP服务器的集中的服务器，该服务器能够认证第一设备和第二设备之间的通信信道。然后在第一设备和第二设备之间建立秘密会话密钥。

随后，通过计算第一设备中的第一SAS和第二设备中的第二SAS，然后将第一SAS插入第一设备中的第一MPC模块中以及将第二DAS插入第二设备中的第二MPC模块中，来验证第一设备和第二设备之间的通信信道。多方通信(MPC)模块通过评估第二MPC模块中的第一SAS和第一MPC模块中的第二MAS来确认通信信道的安全。随后，使用多方计算在第一设备和第二设备之间建立共享秘密，并且可以沿着通信信道交换加密消息。

在本公开的一个方面，通过交换发起和确认消息的认证包括生成第一设备和第二设备中的至少一个的随机数标识符。因此，设备为每个通信会话接收不同的标识符以交换通信。如上所述，在VoIP网络中，将通过使用所谓的SIP服务器(SIP＝会话发起协议)来执行相互发现，SIP服务器知道可以使用VoIP协议的设备的身份。VoIP网络中的后续数据传输以点对点(peer-to-peer)方式进行。

该方法还包括在通过多方比较的成功比较之后，从第一设备向第二设备发送确认消息，并且从该第二设备向第一设备发送确认消息。

应注意，在该方法的一个实施方式中，SAS在第一设备和第二设备两者中是相同的，并且实现通信信道的验证的多方通信模块适于检查从第一设备接收到的SAS等于在第二设备中生成的SAS。

在本公开的一个方面，从先前的第一秘密密钥生成第一秘密密钥，并且从先前的第二秘密密钥生成第二秘密密钥，并且在本发明的另一方面，通信信道的验证是在沿通信信道交换每条消息之前执行的。在另一方面，仅在沿着通信信道交换多个消息之后才执行通信信道的验证。

本公开还教导了采用该方法的网络，以使得能够在网络中的本地设备之间进行安全通信。该设备包括用于沿着通信信道向多个设备中的其他设备中的一个或更多个发送消息的发送器，用于从通信信道从多个设备中的其他设备中的一个或更多个接收消息的接收器，用于通过将所生成的SAS与接收到的SAS进行比较来认证通信信道的多方计算模块，以及所述多个设备中的另一设备并生成会话密钥，通信模块用于使用所生成的会话密钥对消息进行加密。

设备还可以进一步包括用于存储多个会话密钥的存储器，并且还可以进一步包括用于生成标识设备的伪随机数的伪随机数生成器。

附图说明

图1A示出了两方之间的第一通信方案。

图1B示出了两方之间的第二通信方案。

图2示出了具有两个设备的网络的概况。

图3示出了作为Raspberry Pi处理器的两个设备的连接。

具体实施方式

现在将基于附图描述本发明。将理解的是，本文描述的本发明的实施例和方面仅是示例，并且不以任何方式限制权利要求的保护范围。本发明由权利要求及其等同物限定。将理解的是，本发明的一个方面或实施例的特征可以与本发明的一个或更多个不同方面和/或实施例的特征结合。

本文中描述的工作涉及用于在网络中，尤其是在IoT网络和VoIP网络中的两个(本地)设备之间进行安全的点对点数据交换的系统和方法的设计和实现。该系统和方法是用于认证两个设备之间的通信的分散的解决方案，并且与现有技术的PKI不同，它不是集中的解决方案，并且本文的系统和方法没有单个故障点。在点对点数据交换中的使用不排除在其中存在一个或更多个中央服务器并且还可以与本地设备进行通信的网络中使用该系统和方法。

该系统和方法具有轻量级架构，因此提供了一种用于IoT环境的解决方案，该IoT环境在IoT网络中具有多个单独的IoT设备和其他单元，而没有额外的开销。该系统和方法适用于不同的要求。如下所解释的，IoT网络的用户可以优先考虑速度或引入额外的安全检查，这将增加运行时间开销。

该系统和方法不依赖人工干预，因此可以用于安全的IP语音(VoIP)通信。该方法可以适用于ZRTP VoIP应用，从而消除了人工干预或验证通信信道的需求，这将在后面进行解释。

该系统和方法利用多方计算(MPC)的概念。这是加密技术的子领域，该加密技术于1982年作为安全的两方计算形式正式引入，并在1986年由Andrew Yao进行了推广[见参考文献13、30和31]。MPC背后的想法是私下地执行计算。在这种情况下，假设N方都想计算函数

EQ f(t\s\do5(1)\,...\,t\s\do5(N))＝S (等式1)

其中一方i负责输入t

目标是，各方中的任何一方都不能获得对(t

为了使MPC协议安全，MPC协议中必须存在一些属性。MPC协议必须保证私密性，这意味着要确保任何人(除了各方本身外)都不知道各方i的输入t

本文的系统和方法基于DH密钥交换，以克服PKI系统的复杂性或受信任的第三方的使用。如简介中所述，DH单独无法确保认证，并且DH存在MitM问题[参见参考文献10获得更多详细信息]。

Zimmermann P.等人[参考文献34]提出了一种通过使用“双重检查”来解决这个MitM问题的解决方案。该双重检查通过为PKI系统中的每个用户显示SAS来检测任何MitM攻击，以便大声读取SAS并使各方能够在互联网协议语音(VoIP)通信(或实际上是通过允许音频信道上的语音通信的任何其他协议进行通信)中通过电话口头地比较SAS。用户必须主动按下“确定”按钮(例如触摸屏或键盘上的回车键)，以确认SAS是否相等。但是，该解决方案(称为ZRTP协议)缺乏使该协议适用于没有音频信道的纯数据交换的可能性，因此无法进行听觉或口头通信。换句话说，不能使用通过语音进行比较的Zimmermann的想法来交换数据的协议，因为没有建立音频或安全信道，以通过该安全信道可以安全地自动交换SAS，而无需用户干预。ZRTP协议的另一个问题是，“懒惰”或“不负责任”的用户可以简单地确认SAS，而无需真正验证SAS是否相等。

本文的系统和方法通过基于MPC加密子领域添加额外的安全层来解决此认证问题。这个额外的安全层包括两个(或更多个)方，其中每一方都有他们自己的输入。现在假设双方都希望对数据项执行某种计算，而又不向对方或整个网络透露他们自己对数据的输入。有必要在没有人工干预的情况下私密地自动比较SAS。此外，SAS的有效性在任何时候都能及时得到保证，因为对于极其敏感的通信，这种双重检查至关重要。SAS的自动比较还消除了懒惰或不负责任的用户确认SAS而不真正检查其有效性的风险。

图1A示出了使用本文的系统和方法在图2中所示的IoT网络中的两个设备(200A和200B)之间的通信方案。图1B示出了当两个设备200A和200B是用于使用IP语音协议进行通信的设备时的通信方案的调试。将理解的是，在这种情况下，两个设备200A和200B可以是智能电话、平板电脑或计算机，但这并不限制本发明。

图2示出了两个设备200A和200B，它们可以彼此通信并且可以以消息的形式彼此交换数据。消息可以是纯数据消息，也可以是使用VoIP协议的具有语音数据的数据包。两个设备200A和200B包括多方计算模块210(其功能将在后面说明)以及用于存储和高速缓存会话密钥的标识符文件220。两个设备200A和200B还包括发送器240和接收器250以及电源260。两个设备200A和200B，例如是具有有限存储容量和可用电力的传感器。

在两个设备200A和200B之间的图1A中的通信方案开始于设备200A和200B两者在步骤F1至F4中使用发送器240和接收器250自动交换HELLO和HELLOack消息(确认接收到HELLO消息)。该消息的交换在没有用户干预的情况下发生，并且在图中被示为阶段1。在这些HELLO和HELLOack消息中，两个设备200A和200B的标识都向彼此披露。使用伪随机数生成器(PRNG)生成标识，并在阶段1期间验证该标识。在阶段1中进行此消息交换之后，阶段2中的密钥一致交换可以在步骤F5中从设备200B到设备200A以提交(Commit)消息开始。图1A所示的方案假定设备200B是发起者。现在有两种方法可以执行以便在设备200B和设备200A之间对密钥达成一致。

在第一种方法中，设备200A和200B通过DH交换来交换新的共享秘密。这在步骤F6和F7中示出。在第二种方法中，设备200A和200B不需要交换新的共享秘密，因为已经存在先前已经在设备200A和200B之间交换的共享秘密。结果，设备200A和200B省略了第二种方法中的DH计算。但是，步骤F6和F7中的所谓的DHPart1和DHPart2消息仍在设备200A和200B之间交换，以确定应该使用设备200A和200B中的几个存储的共享密钥中的哪个。DHPart1和DHPart2消息在ZRTP协议中定义，并且是公共DH值。代替DH值(hvi和pvr)，设备200A和200B使用随机数以及保留的秘密密钥来导出密钥材料[参考文献26]。这在RFC文献6189ZRTP中详细描述：来自因特网工程任务组(ISSN 2070-1721)的单播安全RTP的媒体路径密钥一致，参阅第4.41.1节(可从https://tools.ietf.org/html/rfc6189#section-4.4.1.1下载)。

图1B中的通信方案类似于图1A中所示的通信方案，除了在阶段1中不通过发送Hello消息并接收HelloACK响应来进行设备200A和200B之间的通信信道的发现。两个设备200A和200B均为SIP服务器(其是中央服务器)所知，因此阶段1涉及将两个设备200A和200B(它们是本地设备)的标识从SIP服务器交换到两个设备200A和200B中的另一个。在使用中央SIP服务器交换两个(本地)设备200A和200B的标识之后，可以在两个(本地)设备200A和200B之间直接交换数据。

在完成这些步骤F6之后，在阶段3中，设备200A和200B中的每个设备中的多方计算(MPC)模块210用于通过比较进行SAS的自动验证，如上所述。SAS是从两个设备200A和200B的会话密钥生成的一系列字母和数字。SAS值的生成在ZRTP RFC(https://tools.ietf.org/html/rfc6189#section-4.5.2)中进行了描述，KDF使用了HMAC(https://tools.ietf.org/html/rfc6189#section-4.5)。先前已经在设备200A和200B之间协商好的会话密钥中的任何差异将在两个设备200A和200B处为SAS生成不同的值。

在上述非限制性情况下，MPC模块210实现等式函数以测试该设备中生成的SAS是否等于从另一设备接收到的SAS，并且如果此等式被验证，即，在两个设备200A和200B中生成的SAS是相同的，则MPC模块210返回值S＝1，因此两个设备200A和200B之间通信。然后，两个设备200A和200B可以在步骤F8至F10中向两个设备200A和200B中的另一个设备发送确认(Confirm)消息，指示另一个设备已经接受并验证了SAS(阶段4)。最后，通信协议已准备好开始在此安全会话中发送数据。在值S＝0的情况下，表示验证失败，并且可能存在中间人攻击，则将不会在设备200A和200B之间建立通信。

该方法和系统利用一些额外的安全和隐私属性作为前向保密(forwardsecrecy)，以保证将来的机密通信。例如，当两个设备200A和200B在不同的时间彼此执行多个连接时，该方法和系统在每个会话之间旋转密钥，使得在后面的会话中不使用相同的密钥。这样，用于多个连接上的不同通信的密钥是不同的。

设备200A和200B中的每一个中的标识符文件220高速缓存用于计算秘密会话密钥的对称密钥，并且这些秘密会话密钥随每个会话而改变。假设攻击者可以访问本地种子，该本地种子已被使用并且将被用来导出将来和当前的会话密钥，会话密钥的属性称为前向保密。由于前向保密的属性，攻击者将不能在两个设备200A和200B之间的通信中再现或重放任何先前的数据交换。攻击者无法从被访问的本地种子重新计算先前会话的秘密会话密钥。换句话说，如果单个通信受到损害，则仅此单个通信(消息交换)将受到损害，而不同通信或会话中的其他消息交换则不受损害。如果该单个通信会话的会话密钥以某种方式“泄露”，则可能发生这种情况，那么会话密钥的这种泄漏不会损害当前通信之前的所有先前通信的机密性。

以这种方式，该系统和方法能够在通信中提供额外的保护，因为即使设备200A和200B在通信之前不烦扰交换SAS，仍然存在相当恰当的针对MitM攻击的认证，基于密钥连续性的形式，如以下段落所述。

密钥连续性的想法是，会话密钥仅一次用于该会话期间的通信交换，但是会话密钥本身被用作种子，以为后续的具有通信交换的会话生成会话密钥。后续会话的此会话密钥可以随后用作生成进一步的(后续的)会话密钥的种子，依此类推。换句话说，旧的会话密钥用于生成新的会话密钥，结果，会话密钥的复杂性随着每次使用而变大，并且会话密钥变得更加安全。

通过生成字母和数字的序列作为SAS来完成设备200A和200B之间的会话密钥的协商。可以定义SAS的大小。如上所述，在设备200A和200B处，SAS必须相等。在ZRTP的情况下，任何捕获和解密用作SAS的语音的尝试都将导致字母和数字的序列不同。该序列是从设备200A和200B两者的初始密钥派生的数学函数，以便在设备200A和200B之间明显协商的会话密钥中的任何差异都将生成用于SAS的不同的值。

该密钥连续性解决方案适用于IoT网络的环境，因为IoT网络中的IoT设备数量不断增加，并且会话密钥必须自动提供，因此，无需事先为设备200A、200B的每一个分别提供会话密钥。此外，使用该解决方案，无需使用PKI即可获得端到端的私密。

如表1所示，该系统和方法对该系统具有三种不同的可能模式。用户可以选择三种模式中的哪一种最适合所讨论的实现。

使用的该第一使用模式被称为“无密钥连续模式”。该第一模式利用了现有的ZRTP机制，在ZRTP草案4.9.1节中介绍[参考文献9]，其中建议了在任何设备中都没有高速缓存的实现。此特征将允许系统和方法始终以DH模式执行也基于ZRTP DH模式[参考文献9]。在此第一模式下，必须在设备之间使用MPC比较SAS以验证会话。

该第一模式是安全状态，已经解决了一些安全问题。安全问题之一是对手不可能获得本地共享秘密。在该第一模式中，设备200A和200B之间的连接总是被认为是全新的(brand-new)连接，其中设备200A和200B从未事先就用于两个设备200A和200B之间的通信的会话密钥达成一致。因此，此新连接不是从先前的连接“导出”的，并且密钥连续性属性不能用于创建新密钥。该第一模式不需要在任何设备200A或200B上的存储器中的任何附加存储来存储先前使用的密钥，从该密钥将导出新密钥。然而，由于需要针对每个新的连接执行MPC，所以该第一模式确实增加了连接两个设备200A和200B的网络的开销。需要考虑该额外开销，并与在设备200A和200B中具有额外存储的其他要求平衡。

第二模式是普通模式，并且基于ZRTP的现有机制，在ZRTP RFC的4.4.2节中介绍[参考文献9]，并表示为预共享模式。

在此第二正常模式下，使用了密钥连续性特征，使得不必在所有迭代中都始终使用MPC比较SAS。然而，该比较将在两个设备200A和200B之间每进行N个连接之后发生。N的值可以由用户定义。在一个非限制性方面，N的默认值是10。换句话说，在每10次交换通信之后，验证该协议正在按预期运行。

在该第二模式中保留了前向保密和密钥连续属性。

对于在每次迭代(即两个设备200A和200B之间的通信的每个单独的建立)都必须验证两个设备200A和200B之间的通信的安全的情况，第三模式是“偏执(paranoid)”模式。将不会导出任何密钥，也不会存储任何可以导出新密钥的密钥。例如，在匿名或敏感数据问题中将使用这种偏执模式。这些偏执模式将具有更大的复杂性，以确保进行额外的安全检查。还将有一种经过修改的“安全”模式，该模式没有额外的安全检查，但在几次迭代中将生成SAS，并信任此后的密钥连续。

在该第三“偏执”模式中，与第二正常模式一样，也使用密钥连续。然而，该第三模式是“偏执的”，因为第三模式需要通过比较SAS来进行额外的验证，以确保设备200A和200B两者处的SAS相等并且没有错误。在此第三模式中，每次迭代都在所有连接上使用MPC来比较SAS。

将理解，该第三模式需要网络中以及设备200A和200B上的更大开销，以确保额外的安全检查。对于更敏感的数据，此第三模式是理想的，因为此第三模式在所有连接中都保证协议正常运行，并且在两个连接的设备中SAS相等。

在该第三模式中，仅使用密钥连续性的概念。

如上所述，本文的系统和方法用于IoT网络中，如图2所示。可以假设IoT网络中的设备200A和200B具有很少的资源，有几种系统类型，存在各种类型的操作系统，并且能够适应各种类型的用途。基于这些假设，该系统和方法提供了以下特征。

可用性。如上所述，确实存在现有技术中的一些安全提议，但是，为了应用这些现有技术的安全协议，许多过程是必需的，并且许多现有技术的安全协议都需要先前的密钥更改。将回想起，通过不安全的手段(例如，通过开放的因特网传输未加密的电子邮件)进行的会话密钥的交换会损害设备之间交换通信的过程的所有安全。

本文的方法和系统易于使用。可以将其与J-PAKE的情况进行比较，例如在FirefoxSync中实现的情况。J-PAKE不太容易使用，因为JPAKE要求编写SAS以提供给这两个设备。在本文的方法和系统中，SAS的提供是一种自动且安全的过程，并且该过程对用户是透明的(通过与比较SAS的MPC组合)。如上所述，图2中所示的IoT中的设备200A和200B通常不具有屏幕，在屏幕上可以显示关于SAS的信息以使人能够执行两个设备200A和200B的配对，或者至少用户不能轻松地与此屏幕进行交互，因此可能必须具有键盘或其他设备。

轻量级。IoT网络中设备200A和200B存在局限性，即低功率和处理能力是众所周知的。这使得难以在IoT网络中使用PKI。本文的方法和系统解决了这些问题，因为该方法和系统更适合于低资源设备，而不需要PKI、密钥证书、信任模型、证书授权等，这些都带来了固有的复杂性。

分散的。此方法和系统与PKI有所不同，因为该系统是分散的，并且不单独地和排他地依赖于单个CA，而是包含许多可靠、独立的元素。

该方法和系统的实现基于两个库：ZRTPCPP[参考文献15]，它是ZRTP协议的C++实现-GNU ZRTP C++和ABY[参考文献17]框架，其有效地组合了基于算术共享、Boolean共享和Yao混淆电路(garbled circuit)的安全计算方案，并使得最佳实践解决方案可用于安全的两方计算中[参考文献29]。

ZRTPCPP。使用库ZRTPCPP。

进行了一些调整，并且向ZRTPCPP库添加了一些特征。为了防止可能引发MitM攻击的SAS冲突，发明人增加了密码密钥的大小(高级加密标准(AES)密钥)，从而产生了具有更大大小的SAS新版本。当MitM攻击偶然发生生成相同的SAS或能够在检测之前通过可能的SAS组合运行时，可能会发生SAS冲突。SAS大小的增加提高了关于通信密码额外的安全度，也使SAS的冲突对攻击者而言更加困难。将会意识到，产生无意的冲突越困难，则算法的质量越好。

为了支持预共享模式，ZRTPCPP库也被适配为支持SAS验证的标志，该标志指示先前已成功进行了设备200A、200B中的任何设备之间的SAS比较，并且通信信道已因此得到验证。通常，在标准ZRTP中，永远不会定义经验证的SAS的概念，因为经验证的SAS需要一定的复杂性，并且需要额外的存储来添加额外的接口来接受经验证的SAS。该文的方法和系统具有MPC的先前附加层，从而消除了用户界面的复杂性。如上所述，使用MPC可以自动比较SAS，而无需用户手动干预[参考文献9]。

在该方法和系统的两个应用中，即VoIP或IoT，在此级别进行相同的更改。但是，在IoT用例中，不必保持接口接受SAS，而在VoIP用例中，MPC用作第一或第二因素认证(以确保SAS相等，并且沿着通信信道的呼叫是安全的)，因此，维持了接受SAS的额外接口。

ABY。库ABY组合了安全计算方案，其提供了三种不同的秘密共享方案：算术共享、Boolean共享和Yao混淆电路。这些秘密共享方案允许例如在设备200A和200B之间的两方计算是安全的。ABY库还允许对几乎所有密码运算进行预计算，并基于预计算的茫然传输(oblivious transfer)扩展在安全计算方案之间提供新颖、高效的转换[参考文献17]。

该ABY库仅考虑半诚实(被动)的对手。ABY库假设有一个受计算限制的对手，他试图从协议执行期间两个设备200A和200B之间的通信过程中交换的消息学习附加信息。对手无法偏离协议，因此可以保护ABY免受管理员或政府机构的被动内部攻击，或者可以信任各方不会主动进行不良行为。

ABY库中的此实现包括一些样本应用程序，例如百万富翁的问题、安全计算AES、欧几里得距离、以及可以在GitHub源代码中找到的其他一些应用程序[参考文献17]。百万富翁的问题与从计算机上本地文件获得的输入适配一起使用。百万富翁的问题适于相等的问题。

为了进行这种适配，发明人建立了具有以下函数的所谓的等式问题电路

$out＝bc->PutEQGate(s_alice,s_bob)；$

而不是在布尔(Boolean)电路类中调用大于等于函数：

$out＝bc->PutGTGate(s_alice,s_bob)；$

新的参数被添加到函数$test_equality_prob_circuit$中，以便在ZRTP的$showSAS$函数中由参数将SAS传递给该函数。在该系统中，MPC仅具有比较SAS的函数并保证由协议交换的SAS是正确的。

在针对ZRTPCPP和ABY库两者的实现和设置方面，需要对已发布的协议进行一些必要的更改。众所周知，ZRTP和MPC协议两者都使用点对点方案。因此，有必要定义设备200A或200B中的哪些启动该过程(即发送器)，哪个是接收器。因此库之间进行的组合意味着作为ZRTPCPP的接收器的设备200A或200B成为MPC的一方0，而另一设备200A或200B(即发送器)成为一方1。这仅仅是设计问题并不是对本发明的限制。

使用cmake平台进行ZRTPCPP和ABY库的集成。在执行方面，当ZRTP协议将SAS显示在屏幕上时(在本文中所述的实现中当然是不可能的)，则添加了对该SAS进行验证的新层。另一方面，ABY框架旨在验证SAS的相等性。

在该实现中，存在两种方案。第一种方案是当两个设备200A和200B之间交换的SAS相等时。在该第一种情况下，可以在两个设备200A和200B之间安全且私密地交换数据，如上所述。在第二种情况下，比较表明交换的SAS是不同的。该方法和系统中止尝试的通信，在两个设备200A和200B之间没有任何数据或信息的交换。将假定，在该第二种情况下，当SAS不同时，通信中很可能存在MitM攻击。

在以下段落中，分析了系统的安全，并且描述了一些已知的攻击，以及评估系统针对这些攻击的成功。此分析是根据威胁模型完成的，该威胁模型描述了必要且充分的场景——全部从假设的攻击者的角度出发。

威胁模型。ZRTP高速缓存用于计算秘密会话密钥的值的对称密钥，并且这些计算的值随每个会话而改变，如上所述[参考文献9]。如果有人从设备200A或200B之一的存储器中窃取了ZRTP共享秘密高速缓存，则攻击者将得到一个独特的机会在下一个会话中发起MitM攻击，因为它可以生成用于下一个会话的会话密钥。在方法和系统中这是可能的。应当注意，由于重新生成了会话密钥，因此上述模式“没有密钥连续性”解决了这个问题。如上所述，总是在每个新会话开始时从存储器中删除ZRTP共享秘密高速缓存，并始终以DH模式(基于ZRTP Diffie-Hellman模式[参考文献9])执行系统和方法。但是，始终有必要将SAS与MPC进行比较。

如上所述，有可能发生SAS冲突，从而启动MitM，即诚实用户可以具有一个SAS密钥，并且攻击者可以获得或识别相同的密钥，从而通过MitM截获呼叫[参见参考文献35]。但是，可以通过增加SAS的大小以减少攻击者生成相同SAS密钥的机会来防止这种攻击，如在此方法中进行的和上面所述的。如ZRTP的RFC[参考文献9]中所示，通过增加密码密钥大小(AES密钥)并因此产生具有更大大小的新SAS来执行。SAS大小的增大增加了有关通信密码的更大安全性，也使SAS的冲突对攻击者而言更加困难。

在存储在设备200A和200B上的MPC库中，由于根本没有认证，对手可以发起MitM攻击。ABY使用半诚实的(被动的)对手模型，假设受计算限制的对手，其试图从该方法执行期间交换的看到的消息中学习附加信息。与较强的恶意的(主动的)对手相比，半诚实的对手不允许偏离协议[参考文献29]。对手们可以探索恶意的(主动的)对手模型。主动攻击是指攻击者干扰并修改协议的正常执行。攻击者不能简单地以“被动”方式观察网络中发生的情况。

攻击场景。在本小节中，对提出的解决方案的安全进行了测量，并确定了针对不同攻击场景该方法的安全。这样，发明人能够对本文中概述的方法和系统的安全进行分类。这种安全基于一系列定理，并适用于由Afifi等人使用的那些定理[参考文献38]，以表明认证协议是安全的。为了完成评估，发明人还添加了两个新定理。

假设1。该方法针对去同步攻击是安全的。证明基于以下内容。图1中示出了避免去同步攻击的方式，其中唯一标识符用于将信息存储在数据库中与该设备200A或200B有关的标识符文件220中。当设备200A或200B之一发送消息F7时，存在对设备200A或200B的存储器中的本地高速缓存的更新，然后秘密密钥在存储器中循环。例如，如果存储器破坏了信息，或者发生了另一种类型的问题，则设备200A和200B两者都将不能在预共享模式下协商会话密钥。设备200A和200B两者都将下降到第一阶段，并且将在步骤F6和F7中执行新的DH密钥改变。

假设2。基于PRNG和本地存储的秘密密钥的组合提供的安全，本文中概述的方法和系统针对标签模拟攻击是安全的。

证明。每个设备200A和200B都有唯一标识符——如图1中的步骤F1和F3所示，该唯一标识符由PRNG生成。唯一标识符用于与任何其他设备进行通信。假设攻击者获得了设备200A的标识符，那么攻击者可能会尝试模拟设备200A，并将设备200A的标识符发送给设备200B。攻击者将无法执行此操作，因为如前所述，本地高速缓存中存在标识符文件220，该标识符文件220高速缓存用于计算通信会话的会话密钥的对称密钥材料。上面已经指出，会话密钥的值是循环的，因此随每个通信会话而改变。因此，当攻击者试图模拟设备200A时，攻击者无法将未被检测到的信息传递给设备200B，因为当攻击者尝试为与受攻击的受害者(即另一个设备200B)的下一个通信会话生成新密钥时，秘密密钥与攻击者(设备A的模仿者)的密钥不同，因此设备200B会中断该通信。在第一个迭代中，攻击者将拥有一用于通信会话的经认证的信道，但是由于通信会话的验证将失败，因此攻击者无法完成攻击。

假设3。该方法和系统针对重放攻击也是安全的。重放攻击是一种从两个设备200A和200B之间的一个通信获取信息，并尝试在下一个会话或两个设备200A和200B之间的通信的迭代中设置信息的攻击。例如，如果设备200A正在与设备200B交换文件，则攻击者可以发送交换的一份先前文件，以尝试破坏通信的协议。为了解决该问题，该方法和装置使用密钥连续和前向保密的属性来生成新的会话密钥，并使先前交换的那些数据包和加密信息过时(即，不可解密)。这使得该方法针对重放攻击是安全的，因为如果攻击者执行这种类型的重放攻击，则设备200A和200B将只是忽略发送的信息并继续进行中的传输。

所提出的协议针对向后和向前的可追溯性攻击是安全的。可追溯性可以被分类为被动攻击。在这种场景，攻击者执行的唯一任务是监听设备200A和200B之间交换的信息，并尝试了解导致信息泄漏的模式。

为克服可追溯性攻击而采用的方法是使用上述的偏执模式，其中在设备200A或200B中没有存储本地信息。在通信会话的任何迭代中，使用PRNG生成所有设备200A和200B的新标识符，这使得不可能在受攻击的会话中重现通信方案。这使得该方法针对可追溯性攻击是安全的。

该方法和系统还可以抵抗单点故障。如前所述，在PKI实现的情况下，存在第三方(证书授权——CA)，其检查证书的有效性。CA在公钥和身份人员或组织之间建立链接。因此，此PKI实现中的客户必须依赖第三方。证书授权代表了单个故障点，因为一旦CA受到损害，则网络中的所有节点也将受到损害。例如，让我们加密CA已颁发的15270个“PayPal”证书[参考文献28]到用于钓鱼的网站。这种类型的系统中的故障会损害多个实体。

本文的系统和方法在面临攻击时，只能损害设备200A或200B中的至多一个，而不损害设备200A和200B两者。

MitM利用对SAS的攻击。Martin Petraschek等描述仅对DH的MitM攻击，并指出在ZRTP中，可以通过用语音识别进行SAS比较来进行认证，这对于第一连接是强制性的，对于其他情况则是可选的(因为它可以保证前向保密)。但是，攻击者可能会试图模仿一方的声音，从而欺骗另一方。在这种情况下，MitM攻击者只是在两个设备200A和200B之间转发RTP数据包，并且可以监听对话。最近的研究[参考文献24]表明，这种类型的攻击是可能的。例如，Lyrebird有一套算法，其可以通过仅监听一分钟的音频来克隆任何人的声音，这种克隆可用于生成SAS。

本文的方法通过MPC采用附加的安全层解决了这个问题。该附加的安全层的目的是为各方(即设备200A和200B)创建方法，以在他们输入上共同计算函数，同时保持这些输入私密的。这样，可以在不向其他方透露任何信息的情况下计算SAS的比较。

然而，没有身份，就无法在MPC中防止MitM攻击[如从参考文献39已知]。在此方法中，可以利用不同的处理方法。设备200A和200B的身份不需要有效，因为攻击者截获MPC通信的可能性很高，同时能够生成与其他点相等的信息交换(SAS)的可能性非常低。

这可以通过该示例来证明。令α为字母α＝{a，b，c，...，z}，大小为26(对于拉丁字母而言)，β为数字β＝{0，1，...，9}，大小为10。γ＝α∪β

设备200B中的一个生成与另一设备200A相同的SAS的概率采用公式：n

计算概率，我们只有一种可能的情况用于攻击者生成另一设备的相同SAS。换句话说，生成相同SAS的概率几乎为零。

现在将讨论本文中概述的方法和系统与J-PAKE和ZRTP之间的差异。我们将由分析每种处理方法使用的数据类型(音频vs.数据)，以及安全属性前向保密和密钥连续开始。由于该方法和系统的重点在图2所示的IoT网络上，查看如果该处理方法已针对这种类型的技术准备就绪，以及如果有可能用作自动配置将描述检查。最后，进行分析以查看在其他协议中是否存在多种操作模式，因为本文的系统和方法取决于用户的需求具有适合于安全或速度的操作模式。

自动配置是IoT网络环境中的特征，因为自动配置使通信安全不依赖于用户。此外，IoT网络中的许多IoT设备都没有键盘或屏幕。错误的一个来源是，人们倾向于使提供屏幕上弹出的任何内容变得容易。人类用户可以确认SAS，而无需实际询问SAS在两个设备上是否真正匹配。J-PAKE或ZRTP系统均未提供针对此人类错误的安全保护。

J-PAKE系统至少需要两个屏幕和一键盘，因为对于每个设备，必须输入显示在屏幕上的密钥以进行配置。使用Pale Moon Web浏览器进行了测试，该浏览器继续使用J-PAKE作为其Sync服务的部分。在ZRTP方法中，还需要人机交互，因为音频识别是比较和验证SAS所必需的，其至少需要一显示器和两个按钮。

J-PAKE和ZRTP协议都仅部分地支持IoT，因为这两个协议都需要人工干预，并且如上所述，对于IoT网络，人工干预是不合适的。

以下部分从网络延时(latency)方面呈现了所提出系统的结果。实验是在上述所有已实现的模式下进行的，即没有密钥连续；在正常模式下；并且，最后，在偏执模式下。这些模式在用法和复杂性方面有所不同，因为在给定密钥连续的情况下，并非所有迭代都需要MPC。另一方面，在某些情况下，在通信会话的每次迭代中验证SAS以确保设备200A和200B中的任何两个之间的通信始终是安全的可能很重要。

还测试了系统和方法相对于OpenSSL PKI系统的运行时间。在PKI系统中，如上所述，信任是基于公钥证书构建的。

延时是通过系统中的网络测量的。时钟或计时器用于测量完成特定动作所花费的时间。在这种情况下，作为服务器(接收器)的设备与作为客户端(发送器)的设备之间的通信。如果客户端将数据发送到服务器并等待答复，则可以测量总持续时间，这应大致估计客户端与服务器之间的往返延迟时间(RTD)。目标是测量与PKI基的系统相比，本文的系统和方法的配置时间。还测量了具有和不具有MPC的系统和方法的运行时间，以评估由于MPC引起的额外延时的真实数量级及其对总体延时的贡献。

该实验部分分为三个部分。第一部分包括用于实验的系统(即用于实验的设备以及设备的操作系统)的设置和配置。然后，介绍了实现的不同模式的结果，并讨论了结果。最后，公开了本文的系统和方法的结果与PKI基的系统的结果的比较。

为了测量该系统在现实环境(低资源设备)中的使用的结果，使用运行Canonical的Ubuntu核心(用于IoT的专用操作系统)的两个常见的现成的Raspberry Pi 3模型B进行了实验。

IoT网络从多个设备的互连出现。创建了如图2所示的环境。两个Raspberry Pi B是通过网络202(即因特网)连接的设备200A和200B。Raspberry Pi 200A之一通过无线路由器(ASUS RT-AC3200)205使用无线链路204连接到因特网，Raspberry Pi 200B的另一个使用有线以太网链路203连接到因特网202。决定在现实场景下通过因特网202路由流量以测量具有网络延时的执行时间。

为了评估本文的方法，测量了所有三种模式下的配置时间。图3描绘了要评估的场景，代表了配置阶段。

为了执行这些测量，使用图2中所示的设置进行了gettimeofday()系统调用。结果在下表中给出。对于表III中所示的每种模式以及从1到10的相应迭代，这些值是10次重复后的平均值和平均值的相应标准偏差。

“无密钥连续”模式不需要在设备200A和200B中的标识符文件200中进行任何额外的存储，因为不必存储先前交换的密钥。确定“无密钥连续”模式在所有迭代中花费的平均时间大约为9843ms±50.49。此“无密钥连续”模式在安全性方面具有一些优势，因为该模式从不依赖于先前交换的密钥并且具有密钥连续，并且还减少了存储需求。但是，运行时间是这三种模式中最高的。

如上所述，与先前的“无密钥连续”模式不同，“正常”模式使用了密钥连续的概念。因此，正常模式在设备200A和200B中需要用于密钥的额外存储。然而，如上所述，仅每10次迭代(例如)使用MPC模块210。在这种情况下，第一次迭代后的运行时间为283ms±46.92。在第一次迭代中，考虑到MPC的开销，延时为9745ms±50.49。因为我们每10次迭代使用MPC，这会导致延时峰值。

“偏执”模式类似于“正常”模式，因为偏执模式也利用了密钥连续。然而，这种模式对于在所有迭代中始终通过MPC模块210验证SAS的点是“偏执的”，因此不依赖于密钥连续。

就延时而言，“无密钥连续”模式和偏执模式之间没有区别。与其他两种模式相比，只有正常模式的延时显着降低。该正常模式每10次迭代运行MPC模块210。所有其他迭代都具有类似的行为。从好的方面来说，其余迭代的平均运行时间为283±46.92ms。

在该正常模式下，主要缺点是在设备200A和200B中需要额外的存储。隐含的权衡是在存储和延时之间。

简而言之，操作模式之间的选择取决于所使用的设备200A和200B的类型、设备200A和200B之间的通信链路以及最终取决于IoT网络用户的功能要求。

由于假设了经认证的信道，我们向运行时间添加时间因子δ以代表与之相关联的开销。但是，我们假定此时间因子δ将代表占运行时间的20％以上。

图3示出了要评估的PKI场景。在此图3中示出了本地客户端(由本地Raspberry Pi代表)，以及托管在装有DigiCert证书的远程Raspberry Pi(如图2所示)中的服务器。远程证书支持OCSP装订(stapling)，从而消除了与CA通信的设备的复杂性。TLS服务器会定期向OCSP响应者询问其自己的证书的有效性，并高速缓存响应。OCSP响应者返回OCSP响应，该OCSP响应(直接或间接)由签发证书的CA签名。TLS客户端可以以相同的方式处理此装订的OCSP响应，即，仅当证书具有有效的时间戳和签名时才应使用该证书。

在TLS握手期间，客户端向服务器宣布支持OCSP装订。反之，如果服务器支持证书状态标志，则服务器激活证书状态标志。此过程如图3的步骤1所示。在步骤2期间，在设备A和B之间建立了SSL连接。目标是在由SSL连接握手所增加的延时的顶部上，测量证书的OCSP(状态)检查延时。

为了测量这种场景的延时，使用了来自OpenSSL库的s_client和s_server二进制文件。s_server服务在服务器机器上运行，而s_client在本地机器上运行。可能获得OCSP信息和服务器/客户端握手结果。发现10次迭代平均运行时间为380ms±11.60。

因此，与使用PKI基的系统的结果相比，以“正常”模式运行的本文的系统和方法实现了26％的延时减少。

本文描述了一种用于在IoT网络中的IoT设备之间配置和轻量级通信的新的解决方案，其利用经修改的安全密钥交换协议，其中音频信道被MPC(KEAV)上的数据协商所取代。定义了三种不同的操作模式，它们具有级别增加的安全审查和开销。IoT网络可以用于多个固定传感器，也可以在网络中用于自动驾驶。

在IoT市场中必须解决的可扩展性和小尺寸设备的破坏性问题，应考虑将“正常”模式作为该环境的解决方案。单独使用此机制，就可以在小型IoT设备中执行认证和安全属性证明，而不会对CPU或电池消耗产生重大影响。可以重新设计存储的本地信息，例如，允许这些模式在最常用的通信方案中使用，而在需要零星通信的情况下保留其他模式。例如，这将允许通过IoT网络检测新系统，以取代旧设备。

在该系统和方法的另一应用中，设备可以是VoIP设备。

PatríciaR.Sousa，

Luís Antunes的这项工作得到了项目“NanoSTIMA：从宏观到纳米的人类感知：迈向综合多模式健康监测和分析/

NORTE-01-0145-FEDER-000016(NanoSTIMA:Macro-to-Nano Human Sensing:Towards Integrated Multimodal Health Monitoring and Analytics/NORTE-01-0145-FEDER-000016)”的支持，根据《葡萄牙2020年合作伙伴关系协议》，并通过欧洲区域发展基金(ERDF)，该项目由北葡萄牙区域运营计划资助(NORTE 2020)。

参考文献

1.Yang,Yuchen等“关于物联网中安全和隐私问题的调查(A Survey on Securityand Privacy Issues in Internet-of-Things)”IEEE物联网杂志(2017)。

2.H.Sundmaeker，P.Guillemin，P.Friess和S.Woelffle，“实现物联网的愿景和挑战(Vision and Challenges for Realising the Internet of Things)”，关于物联网的欧洲研究项目集群，2010年。

3.Aman，Muhammad，Kee Chaing Chua和BiplabSikdar，“使用物理不可克隆功能的物联网系统中的相互认证(Mutual Authentication in IoT Systems using PhysicalUnclonable Functions)”IEEE物联网杂志(2017)。

4.Umar,Amjad，数字时代的信息安全和审计(Information Security andAuditing in the Digital)，NGE解决方案公司，2003年。

5.Hao,Feng和Peter YA Ryan，“密码通过欺骗来验证密钥交换(Passwordauthenticated key exchange by juggling)”国际安全协议讲习班，施普林格·柏林·海德堡，2008年。

6.Lancrenon,Jean,Marjan

7.Hao,Feng，“J-pake：通过欺骗进行密码认证的密钥交换(J-pake:Passwordauthenticated key exchange by juggling)”(2016)。

8.Hao,Feng等，“Schnorr NIZK证明：离散对数的非交互式零知识证明(SchnorrNIZK Proof:Non-interactive Zero Knowledge Proof for Discrete Logarithm)”(2013年)。

9.Zimmermann,Phil,Alan Johnston和Jon Callas，ZRTP：单播安全RTP的媒体路径密钥协议(ZRTP:Media path key agreement for unicast secure RTP)，RFC 6189号，2011年。

10.Seo,Dong Hwi和P.Sweeney，“简单的认证密钥协商算法(Simpleauthenticated key agreement algorithm)”电子快报35.13(1999)：1073-1074。

11.Goldreich,Oded，“安全多方计算(Secure multi-party computation)”手稿，初版(1998)：86-97。

12.Toorani,Mohsen。“J-PAKE的安全分析(Security analysis of J-PAKE)”计算机与通信(ISCC)，2014年IEEE研讨会，IEEE，2014年。

13.Yao，AndrewC，“安全计算协议(Protocols for secure computations)”。计算机科学基金会，1982年，SFCS’08，第23届年度研讨会，IEEE，1982年。

14.Hirt，Martin，Ueli Maurer和Bartosz Przydatek，“高效的安全多方计算(Efficient secure multi-party computation)”密码学和信息安全理论与应用国际会议，施普林格·柏林·海德堡，2000年。

15.ZRTP协议的C++实现-GNU ZRTP C++-https://github.com/wernerd/ZRTPCPP[在线；访问30-03-2017]。

16.Petraschek，Martin等人，“对ZRTP的中间人攻击的安全性和可用性方面(Security and Usability Aspects of Man-in-the-Middle Attacks on ZRTP)”J.UCS14.5(2008)：673-692。

17.ABY-高效的混合协议安全两方计算框架(A Framework for EfficientMixed-protocol Secure Two-party Computation)https://github.com/encryptogroup/ABY[在线；访问日期：2017年9月15日]。

18.Keller，Marcel，Emmanuela Orsini和Peter Scholl，“MASCOT：具有忽略转移的更快的恶意算术安全计算(MASCOT:faster malicious arithmetic securecomputation with oblivious transfer)”2016ACM SIGSAC计算机和通信安全会议论文集，ACM，2016年。

19.Huang，Yan，Jonathan Katz和David Evans，“Quod-pro-quo-tocols：具有双重执行的增强半诚实协议(Quid-pro-quo-tocols:Strengthening semi-honest protocolswith dual execution)”安全和隐私(SP)，2012IEEE研讨会，IEEE，2012年。

20.Sakarindr，Pitipatana和Nirwan Ansari，“通过无线基础架构，移动即席和无线传感器网络进行的团体通信中的安全服务(Security services in groupcommunications over wireless infrastructure,mobile ad hoc,and wireless sensornetworks)”IEEE无线通信14.5(2007)。

21.Laud，Peeter和LiinaKamm编辑，安全多方计算的应用(Applications ofSecure Multiparty Computation)，卷13.IOS出版社，2015年。

22.使用短认证字符串的设备配对(2016)https://tools.ietf.org/id/draft-ietf-dnssd-pairing-01.html[在线；访问日期21-04-2017]。

23.使用证书和密钥的TLS握手(2017)https://mcuoneclipse.files.wordpress.com/2017/04/tls-handshaking-with-certific ates-and-keys.png[在线；已访问25-04-2017]。

24.Lyrebird声称它仅用一分钟的示例音频就可以重建任何声音，(2017)http://www.theverge.com/2017/4/24/15406882/ai-voice-synthesis-copy-human-speech-lyrebird[在线；已访问25-04-2017]。

25.Martini，S.：OpenSSL和OpenSSH的J-PAKE实现中的会话密钥检索，(2010)http://seb.dbzteam.org/crypto/jpake-session-key-retrieval.pdf[在线；已访问03-04-2017]。

26.Thermos,Peter和Ari Takanen，保护VoIP网络，培生教育，2007年。

27.Canetti,Ran，“获得普遍可组合的安全性：迈向信任的基础(Obtaininguniversally compoable security:Towards the bare bones of trust)”密码学和信息安全理论与应用国际会议，施普林格·柏林·海德堡，2007年。

28.让我们加密向“PayPal”网络钓鱼站点签发证书：如何保护自己(2017年)http://bit.ly/2i7Z4bT[在线；访问19-05-2017]。

29.Demmler，Daniel，Thomas Schneider和Michael Zohner，“ABY-A高效的混合协议安全两方计算框架(ABY-A Framework for Efficient Mixed-Protocol Secure Two-Party Computation)”NDSS，2015年。

30.Yao,Andrew Chi-Chih，“如何生成和交换秘密(ow to generate andexchange secrets)”计算机科学基金会，1986年，第27届年度研讨会，IEEE，1986年。

31.Yao，AndrewC，“陷门功能的理论和应用(Theory and application oftrapdoor functions)”，计算机科学基金会，1982年，SFCS’08，第23届年度研讨会，IEEE，1982年。

32.Lindell，Yehuda和Benny Pinkas，“安全多方计算以保护隐私的数据挖掘(Secure multiparty computation for privacy-preserving data mining)”隐私与保密杂志1.1(2009)：5，APA。

33.McGrew，D.等，“RFC 3711：安全实时传输协议(SRTP)(RFC 3711:The securereal-time transport protocol(SRTP))”，思科系统公司和爱立信研究技术公司，Rep(2004)。

34.Zimmermann，P.，J.Callas和A.Johnston，“ZRTP：单播安全RTP的媒体路径密钥协议(RFC 6189)(ZRTP:Media Path Key Agreement for Unicast Secure RTP(RFC6189))”，(2011)：2070-1721。

35.Sisalem，Dorgham等，SIP安全，约翰·威利父子(John Wiley&Sons)，2009年。

36.Hlavacs，Helmut等，“通过使用计算难题来增强ZRTP(Enhancing ZRTP byusing Computational Puzzles)”，J.UCS 14.5(2008)：693-716。

37.Petraschek，Martin等，“对ZRTP的中间人攻击的安全性和可用性方面(Security and Usability Aspects of Man-in-the-Middle Attacks on ZRTP)”J.UCS14.5(2008)：673-692。

38.Afifi，M.H.等人，“使用自供电计时器进行被动式物联网的动态认证协议(Dynamic Authentication Protocol Using Self-Powered Timers for Passive因特网of Things)”IEEE物联网杂志(2017)。

39.Pass,Rafael，“具有不诚实多数的有界并发安全多方计算(Bounded-concurrent secure multi-party computation with a dishonest majority)”第三十六届ACM年度计算机理论研讨会论文集，ACM，2004年。