申请/专利权人：赛普拉斯半导体公司

申请日：2017-11-29

公开（公告）日：2024-03-22

公开（公告）号：CN110100247B

主分类号：G06F21/62

分类号：G06F21/62;H04L9/32;H04L9/40;G06F21/30;G06F21/33

优先权：["20161222 US 62/437,877","20170331 US 15/476,758"]

专利状态码：有效-授权

法律状态：2024.03.22#授权;2019.08.30#实质审查的生效;2019.08.06#公开

摘要：描述了物联网IoT设备以及安全通信和认证协议，用于识别IoT设备和对方，并确保在通过可信通信路径传输和接收数据之前，IoT设备和对方之间的通信被认证。

主权项：1.一种用于通过物联网IoT设备从设备制造商的在线数据库接收嵌入式证书的方法，所述方法包括：在所述IoT设备和所述设备制造商的服务器之间建立连接；认证所述设备制造商的服务器；在所述IoT设备和所述设备制造商的服务器之间创建加密连接；将设备型号和固件版本号从所述IoT设备发送到所述设备制造商的服务器，并通过所述设备制造商的在线数据库生成测试代码，并将所述测试代码发送到所述IoT设备；由所述IoT设备执行所述测试代码，以使所述测试代码对一些固件码字进行采样，并将散列结果发送回所述设备制造商的服务器，以及在所述IoT设备执行所述测试代码之后，将来自所述IoT设备的多个固件码字与设备固件的预期码字进行比较；以及如果来自所述IoT设备的固件码字与设备固件的预期码字匹配，则从所述设备制造商的服务器向所述IoT设备发布所述嵌入式证书。

全文数据：用于无线IOT系统的强认证和易用性的嵌入式证书方法相关申请本申请是于2017年3月31日提交的第15476,758号美国非临时专利申请的国际申请，其要求于2016年12月22日提交的第62437,877号美国临时专利申请的权益，所有申请通过引用以其整体并入本文。技术领域本公开大体上涉及无线系统，更具体地说，涉及物联网“IoT”设备的连通性。背景支持互联网的设备和互联网连通性变得越来越普遍。随着连通性扩展到越来越多的设备，并且连通性的应用增加，信息的安全性和信息的通信变得越来越重要。互联网不再局限于个人电脑或笔记本电脑。更确切地讲，它跟随用户在他们的口袋里，在他们的车里，出现在他们生活的每个角落。随着越来越多的设备的出现，恶意软件和寻求私人信息的访问点增加，给物联网IoT带来了新的安全挑战。无线标准如蓝牙低能耗BLE、和WiFi定义了具有强大安全性能的认证和加密协议。然而，基于标准的IoT产品可能仍然容易受到安全攻击。许多标准使用共享秘密作为认证凭证，但是随着IoT技术从仅仅出现在手持装置上扩展开来显示器或输入输出接口的缺少会给设置、更新和验证如密码或秘密密钥等的认证凭证带来困难。制造商可以在IoT设备中使用当前或默认密码或密钥；用户通常从不改变它。附图说明图1示出了根据一个实施例的具有IoT设备和通信的系统。图2示出了根据一个实施例的嵌入式证书。图3示出了根据一个实施例的针对IoT设备和对方的认证协议。图4示出了根据一个实施例的用于建立加密连接的方法。图5A示出了根据一个实施例的用于验证芯片供应商的证书的方法。图5B示出了根据一个实施例的用于验证IoT芯片的证书的方法。图6示出了根据一个实施例的用于IoT芯片和对方的认证的初始化过程。图7示出了根据一个实施例的用于IoT芯片和对方的认证过程。图8示出了根据一个实施例的用于引入第二对方的过程。图9示出了根据一个实施例的用于从IoT访问控制列表移除对方的方法。图10A示出了根据一个实施例的用于从在线源向具有可信执行环境的设备发布证书的方法。图10B示出了根据一个实施例的由具有可信执行环境的设备生成并将证书注册到在线源的方法。图10C示出了根据一个实施例的用于从在线源向没有可信执行环境的设备发布证书的方法。图11A示出了根据一个实施例的用于在设备制造者的指令下从芯片供应商提供证书的方法。图11B示出了根据一个实施例的通过传输层安全性TLS握手handshake发送设备制造者的信息的方法。图11C示出了根据一个实施例的用于在验证有效设备固件之后通过TLS发布证书的方法。图12示出了根据一个实施例的用于根据所述协议提供具有强安全性的锁的方法。详细描述图1示出了系统100，其包括装备有无线射频和天线125的设备110和同样装备有无线射频和天线155的对方150。设备110可以是耦合到天线115和处理单元CPU122的IoT芯片120。IoT芯片120和CPU122也可以耦合到存储器124。存储器124可以存储由IoT芯片120和或CPU122访问和或执行的数据或程序。IoT芯片也称为IoT设备120可以根据本文描述的各种协议通过天线115和155来与对方150无线通信。在一个实施例中，单独的COM电路126可以包括在设备110中，而在另一个实施例中，COM电路126可以包括在IoT芯片120中。对方150可以是移动手持装置或另一计算设备。对方150也可以是与IoT芯片设置在同一完整设备内的集成电路。IoT芯片120可以使用嵌入式证书，该证书与用于发布证书的一组协议相结合，允许IoT芯片识别自身并验证安全通信和控制。嵌入式证书可以在制造或编程期间发布。在其他实施例中，证书可以通过芯片供应商或者通过可由芯片供应商启用的其他第三方在线发布。该组协议可以包括初始化、引入、认证和移除协议。这些协议可以建立、证明和管理设备如IoT芯片120和对方150之间的信任关系。图2示出了嵌入式证书200的实施例。嵌入式证书200可以包括共享公共内容210和非共享公共内容250。共享公共内容210可以是双证书链或单证书。对于单证书共享公共内容，可以向第一证书212分配芯片供应商的私钥，并且包括芯片标识信息214，芯片标识信息214包括唯一芯片ID215和芯片公钥216。在一个实施例中，唯一芯片ID215不是供应商提供的根密钥，而是提供给芯片的特定ID。第一证书212还可以包括芯片供应商信息217，其包括芯片供应商ID218和芯片供应商公钥219。在一个实施例中，第一证书212可以包括由该供应商或由用于系统内编程的供应商提供的预安装的根密钥未示出。因此，预安装的根密钥可以由可信的供应方或编程供应商提供。芯片和芯片供应商的ID和公钥可以被转换成散列hash并存储在散列块220中。最后，散列块220和芯片供应商的私钥未显示可用于生成和存储加密结果221。对于双证书链，第二证书222可以被添加到证书212。第二证书222可以包括第二芯片供应商信息224，其包括芯片供应商ID225和芯片供应商公钥226。第二证书222还可以包括证书颁发机构信息227，其包括证书颁发机构的ID228和证书颁发机构的公钥229。芯片供应商和证书颁发机构的ID和公钥可以被转换成散列并存储在散列块230中。最后，散列块230和证书颁发机构的私钥未显示可用于生成和存储加密结果231。嵌入式证书200的非共享公共内容250可以包括芯片供应商的公钥252以及其他芯片供应商254和证书颁发机构256的公钥。公钥的数量可以由嵌入式证书200被保存在其中的储存器的大小来确定。可以在线获得不是芯片供应商公钥252的芯片供应商的芯片供应商和证书颁发机构的公钥。嵌入式证书200可以包括私有内容280，其包括芯片的私钥。在这样的实施例中，可能需要实施安全协议来保护私有内容。包含在嵌入式证书200中的信息可以是固定的不可变的。在各种实施例中，嵌入式证书的信息可以存储在实时可编程OTP寄存器或受保护的内部存储器如闪存中。嵌入式证书200可以由芯片供应商的服务器或在芯片供应商的辅助下由设备制造者的服务器在制造后的某个时间在线发布给IoT芯片，用于低成本制造和基于证书的安全功能的可选使用。如果嵌入式证书是由芯片供应商的服务器发布的，则可以验证设备固件，以确保其没有受到损害，从而防止向使用真正的IoT芯片的恶意设备发布证书。嵌入式证书可以在有或没有互联网连通性的情况下由对方验证。图3示出了根据一个实施例的用于在IoT设备和对方之间进行识别、认证和通信的高级过程300。在步骤310中，对方可以首先运行传输层安全TLS握手来建立安全连接。TLS握手协议可以使用公钥私钥算法以基于其芯片ID来认证芯片。TLS握手协议然后可以针对高级过程300的剩余部分创建加密连接。在TLS握手完成之后，在步骤320中，对方可以运行初始化协议。初始化协议可用于通过步骤310的加密TLS连接来在对方和IoT设备之间建立信任关系。信任关系可以通过提供高熵共享秘密或证书来创建。然后，在步骤330，对方可以由具有嵌入式证书的设备认证。可以通过显示其知道高熵共享秘密或对应于其证书的所提供的密钥来认证对方。一旦对方被认证，对方和IoT设备就可以在步骤340开始通信。步骤340的通信可以用于所有目的，包括向IoT设备引入其他对方或从IoT设备移除其他对方以进行可信任的通信。高级过程300可以被称为基于证书的安全协议，并且可以从IoT芯片验证设备固件开始，以防止证书被受损设备使用。基于证书的安全协议可能要求服务器频繁更新证书，因为以前颁发的证书到期时间expirationtime很短。在该实施例中，用颁发的证书来损坏设备可能更加困难。基于证书的安全协议可以提供基于芯片特定ID的强认证。它可以取消设置、输入和验证作为认证凭证的共享秘密的要求。最后，它可以为IoT设备提供更好的易用性。高级过程300开始于对方在步骤310运行TLS握手。图4示出了根据实施例的TLS握手400的流程图。首先，在步骤410，对方也称为“客户端”向IoT芯片也称为“服务器”发送“ClientHello”消息。在步骤420，IoT芯片然后通过发送几条消息来响应对方，这几条消息包括：“ServerHello”、“Certificate”、“ServerKeyExchange”和“ServerHelloDone”。在步骤430，对方向IoT芯片发送“ClientKeyExchange”消息，并且在步骤440发送“ChangeCipherSpec”和“Finished”消息。在步骤445，如果IoT芯片没有及时从对方接收到上述消息，则IoT设备在步骤450终止与对方的通信。如果IoT设备在步骤445及时从对方接收到上述消息，则在步骤460，IoT芯片向对方发送“ChangeCipherSpec”和“Finished”消息。在步骤465，如果对方没有及时从IoT芯片接收到上述消息，则在步骤470，对方终止与IoT设备的通信。如果对方在步骤465确实及时从IoT芯片接收到了上述消息，则握手完成，并且可以在步骤480完成如以上参考图3所讨论的进一步的初始化和授权。图4的TLS握手400可用于验证芯片供应商的证书和或IoT芯片的证书。TLS握手400可以根据图5A的方法500验证芯片供应商的证书。首先，在步骤510中，对方可以根据公共信息根据上面的图2计算散列值。然后可以在步骤520创建解密的散列值。在步骤525，如果计算的散列值与解密的散列值相同，则芯片供应商的证书可以被信任，并且图4的TLS握手的剩余部分和图3的通信可以在步骤530继续。如果在步骤525，计算的散列值与解密的散列值不相同，则芯片供应商的证书可能不可信，并且在步骤540，对方和IoT芯片之间的通信可以终止。如上所述，TLS握手400可以根据图5B的方法505验证IoT芯片的证书。首先，在步骤550中，对方可以根据公共信息根据上面的图2计算散列值。然后可以在步骤560创建解密的散列值。在步骤565，如果计算的散列值与解密的散列值相同，则芯片的证书可以被信任，并且图4的TLS握手的剩余部分和图3的通信可以在步骤570继续。如果在步骤565，计算的散列值与解密的散列值不同，则芯片的证书可能不可信，并且在步骤580，对方和IoT芯片之间的通信可以终止。在TLS握手完成并且加密连接被创建之后，可以向对方认证IoT芯片。例如，IoT芯片证明它拥有与所声明的唯一芯片ID相对应的私钥。然而，对方尚未向IoT芯片进行认证。在对方在其访问控制列表ACL中没有IoT芯片的ID的情况下，这意味着它与IoT设备或IoT芯片没有信任关系，可以执行初始化过程来建立信任关系。图6示出了用于创建IoT设备或IoT芯片与对方之间的信任关系的初始化过程600的一个实施例。首先，在步骤602，IoT设备使用共享秘密与对方配对。共享秘密潜在地可能很弱，并且仅针对配对两个设备的初始步骤而创建，以用于随后的初始化和授权。然后，在步骤604，对方开始TLS握手，并且在步骤606创建与IoT设备的加密TLS连接如以上参考图4所描述的。在步骤607，如果IoT设备的ID在对方的ACL中，则不再需要初始化过程600，并且协议可以在步骤608前进到认证协议在图7中更详细地讨论。如果IoT设备的ID不在对方的ACL中，则在步骤610，对方可以用包含该IoT设备的设备的制造商的网络服务器或在线数据库检查IoT设备的ID，以确保该设备实际上是由制造商制造的并且没有被损坏。在一个实施例中，步骤610可以推迟到互联网连通性对于对方是可用的时间。在另一个实施例中，对方可以请求用户验证可以打印在包含该IoT设备的设备上的芯片ID与IoT设备证书中呈现的ID是否相同。如果它们相同，则初始化过程可以继续。然后，在步骤612，对方设备可以向IoT设备发送初始化请求，该请求包括对方的ID或证书。在步骤613，如果IoT设备的ACL不是空的，并且对方的ID不在IoT设备的ACL中，而是在待定的ACL中，则在步骤614，IoT设备可以用具有随机数nonce的引入质询来响应初始化请求。然后，在步骤616，对方可以用制造商的低熵密钥存储在具有对方ID的待定ACL中计算随机数的散列值。然后，在步骤618，对方可以发送带有散列的引入响应。然后，在步骤620，IoT设备可以计算相同的散列，并确保来自对方和来自IoT设备的两个散列匹配。如果两个散列匹配或者如果在步骤613中IoT设备的ACL为空，则初始化过程600在步骤619确定对方是否在初始化请求中发送了证书。如果对方在初始化请求中发送了证书，则IoT设备在步骤620验证该证书，并在步骤622发送具有加密随机数的初始化质询。在一个实施例中，步骤622中的加密随机数从对方的公钥导出。对方可以在步骤624用其私钥解密随机数，并在步骤626发送具有解密的随机数的初始化响应。在步骤627，如果对方的随机数和IoT设备的随机数匹配，则在步骤628，IoT设备可以决定信任对方。然后，在步骤630，IoT设备可以将对方的ID和公钥保存在其ACL中，并在步骤632发送初始化结束消息。在步骤634，对方可以将IoT设备的ID和对方的公钥保存到其ACL中。如果在步骤619，对方没有在初始化请求中发送证书，则IoT设备在步骤636发送秘密初始化请求，并且对方在步骤638发送具有高熵秘密和低熵密码的秘密初始化请求响应。然后，在步骤640，IoT设备将对方的ID保存到其ACL中，并在步骤642发回初始化结束消息。然后，在步骤644，对方将IoT设备的ID和高熵秘密保存到其ACL中。在一个实施例中，保存到对方的ACL的高熵秘密可以使用用户生成的密钥加密。从其中对方将IoT设备的ID保存到其ACL以及在步骤634中，保存对方的公钥的步骤634和644，初始化过程在步骤645确定初始化协议是否成功。如果已经成功，在步骤648，对方请求IoT设备改变到高熵共享秘密，并且整个认证过程初始化过程600是其中的一部分在步骤650中完成。IoT设备和对方然后可以通过基于共享秘密的硬件加密连接通信，或者通过硬件可能不支持的TLS连接通信。如果初始化协议在步骤645中没有成功，则IoT设备可以发回初始化拒绝消息，并且IoT设备和对方之间的通信可以终止。如果在初始化过程600的步骤607中，IoT设备的ID在对方的ACL中，则授权协议可以在步骤608中启动。图7示出了在图6的步骤608中所提到的认证协议700的一个实施例。当IoT设备和对方之间已经存在信任关系时，可以执行认证协议700。授权协议700因此被用于向IoT设备认证对方。认证协议700开始于步骤702中IoT设备与对方配对。对方然后可以在步骤704开始TLS握手，并在步骤706创建与IoT设备的加密TLS连接。然后，在步骤708，对方可以向IoT设备发送具有对方ID的认证请求。在步骤710中，对方可以用包含该IoT设备的设备的制造商的网络服务器或在线数据库检查IoT设备的ID，以确保该设备实际上是由制造商制造的并且没有被损坏。步骤710可以被推迟，直到对方具有互联网连通性。在另一个实施例中，在步骤712中，对方可以请求用户验证可以打印在包含该IoT设备的设备上的芯片ID是否与IoT设备证书中呈现的ID相同。如果它们相同，则认证过程可以继续。然后，在步骤714，对方可以向IoT设备发送认证请求消息。在步骤715，如果对方的ID不在IoT设备的ACL中，IoT设备可以在步骤716发送认证拒绝消息并终止与对方的通信。如果在步骤715，对方的ID在IoT设备的ACL中，并且如果在步骤717，对方在认证请求中发送了证书，则IoT设备可以在718验证该证书。然后，在步骤720，IoT设备可以发送认证质询，该认证质询具有用对方的公钥加密的随机数。然后，在步骤722，对方可以使用私钥解密来自IoT设备的随机数，并在认证响应中发回随机数。在步骤723，如果对方随机数与IoT设备随机数相同，则IoT设备可以在步骤724发送认证完成消息。如果在步骤723，对方随机数与IoT设备随机数不同，则IoT设备可以在步骤716发送认证拒绝消息并终止与对方的通信。如果在步骤715，对方的ID在IoT设备的ACL中，并且如果在步骤717，对方没有在认证请求中发送证书，则IoT设备可以在步骤726用包括随机数的认证质询来回复。在步骤728，对方可以用对方的高熵秘密计算随机数的散列，并且在步骤730，在认证响应中发回散列。然后，在步骤732，IoT设备可以使用对方的高熵秘密来计算相同的散列，该高熵秘密被存储在具有对方ID的IoT设备的ACL中。在步骤733，如果来自对方的散列和由IoT设备计算的散列相同，则在步骤724，IoT设备可以发回认证完成消息。如果它们不匹配，则在步骤716，IoT设备可以在步骤发回认证拒绝消息并终止与对方的通信。一旦图7的认证过程完成并成功，IoT设备可以通过基于共享秘密的硬件加密连接与对方通信，或者通过硬件可支持或可不支持的TLS连接而与对方通信。一旦图7的整个认证过程完成并成功，如果允许IoT设备与一个以上的对方保持信任关系，则已经在IoT芯片的ACL上的对方可以通过引入过程引入另一个对方来与IoT芯片建立信任关系。图8示出了引入过程800的一个实施例。在步骤810，已经在IoT设备的ACL上的对方可以向IoT设备发送引入请求。然后，在步骤820，IoT设备可以将发送的对方ID保存到待定ACL中，然后可以在步骤830等待第二对方发起初始化协议。在一个实施例中，第二对方的初始化协议可以类似于图6的初始化过程600。在又一实施例中，IoT设备可以启动定时器以提供时间窗口，在该时间窗口期间，必须接收来自第二对方的初始化请求。如果在IoT设备的定时器到期时没有接收到来自第二对方的初始化请求，则初始化协议可能不会开始，并且可能需要根据图8的重复的引入过程。因为对方可以向IoT设备引入其他对方，所以对方也可以从IoT设备的ACL中移除其他对方或自己。在一个实施例中，待移除的对方必须根据移除过程提供批准。图9示出了用于从IoT设备的ACL中移除第二对方的移除过程900。首先，在步骤902，对方向IoT设备发送移除请求。在步骤903，如果对方试图从IoT设备的ACL中移除自己，则IoT设备在步骤904将该对方从其ACL中移除，并在步骤906发送移除完成消息。然后，在步骤908，IoT设备可以切断与对方的TLS连接。如果在步骤903，对方试图从IoT设备的ACL中移除另一第二对方，则在步骤910，IoT设备可以可选地请求对方证明第二对方的同意。然后，在步骤912，对方可以用第二对方的低熵密码计算随机数的散列，并且在步骤914，在移除响应中将散列发送到IoT设备。IoT设备然后可以在步骤916计算相同的散列。在步骤917，如果由第一对方计算的散列与IoT设备计算的散列不匹配，则在步骤918，IoT设备不切断与第二对方的TLS连接。如果在步骤917由第一对方计算的散列与IoT设备计算的散列匹配，则IoT设备在步骤920从其ACL中移除第二对方ID，在步骤922发送移除完成消息，并在步骤924切断与第二对方的TLS连接。嵌入式证书可以在芯片制造和测试过程中被直接编程到IoT芯片中。如上所述，嵌入式证书可以存储在OTP寄存器或受保护的内部存储器中。在另一个实施例中，在IoT芯片已经被构建到使用上述协议的设备中之后，嵌入式证书可以被发布给IoT芯片。在该实施例中，嵌入式证书可以从在线源发布。在设备完全或部分组装后发布嵌入式证书可以提供许多好处。在IoT芯片中芯片特定的信息或秘密的缺少可允许最终设备在低成本工厂被组装，而这些工厂无法满足更强大的安全要求。这可能会降低总制造成本。可以防止没有嵌入式证书但具有芯片特定的秘密的IoT芯片通过将其放入不可信设备中而被置于恶意目的。最后，没有特定嵌入式证书的芯片可以用于具有不同安全要求的各种产品，并且可以在生产后实现安全要求。设备固件可以存储在存储器类似于存储器124中，或者可以位于在IoT芯片的内部的IoT芯片的存储器中。在生产和测试期间，设备固件可以在工厂中使用IoT固件进行编程。在一个实施例中，每个IoT芯片可以被闪存编程有相同的固件图像而没有任何芯片特定的秘密。在该实施例中，如果IoT芯片没有嵌入式证书芯片供应商或制造商没有提供证书，设备固件可以触发IoT设备从在线源请求证书。设备固件可以确保IoT芯片和设备制造者的服务器之间的互联网连通性。在确认设备固件有效后，可以从在线源发布证书。图10A示出了用于从在线源向具有对IoT芯片可信任执行环境的设备中的IoT芯片发布证书的方法1000。在步骤1002，IoT设备也称为IoT芯片首先连接到设备制造者的服务器。设备制造者可以是IoT设备或IoT芯片可被集成到其中的系统或部分系统的制造商。服务器可以是可通过连接访问的数据库。服务器可以通过互联网、本地网络、硬连线连接或一些其他机制来访问。在IoT芯片连接到设备制造者的服务器之后，IoT设备可以在步骤1004开始类似于图4中描述的TLS握手的TLS握手。因为IoT芯片用内置在固件中的设备制造者的公钥编程，所以可以在步骤1006认证设备制造者的服务器，并且在步骤1008创建加密的TLS连接。然后，在步骤1010，设备可以将设备型号和固件版本号从IoT设备发送到服务器，此后，在步骤1012，设备制造者的服务器随机选择设备固件的码字的块号。在步骤1014，这些块号被发送到IoT芯片的可信执行环境。在步骤1016，IoT芯片的可信执行环境运行一段代码来采样固件码字的指定块，并将散列结果发送回设备制造者的服务器。在步骤1017，如果固件码字匹配设备固件，则在步骤1018，设备制造者的服务器验证设备和IoT芯片，并向IoT芯片发布证书和相应的芯片特定的私钥，该证书包含唯一的IoT芯片ID和由设备制造者的私钥签名的芯片特定的公钥。然后，在步骤1020，IoT芯片将证书和芯片特定的私钥保存到受保护的OTP寄存器或等同物中，以供将来在认证中使用。如果在步骤1017，固件码字与设备固件不匹配，则在步骤1022，设备制造者的服务器不发布证书。图10B示出了针对设备中可信执行环境中的IoT芯片在内部生成芯片ID和一对公钥私钥并将公钥注册到在线源的方法1030，在线源又将公钥和芯片ID签署到证书中。在步骤1032，IoT设备也称为IoT芯片连接到设备制造者的服务器。服务器可以是可通过连接访问的数据库。服务器可以通过互联网、本地网络、硬连线连接或一些其他机制来访问。设备制造者可以是IoT设备或IoT芯片可被集成到其中的系统或部分系统的制造商。在IoT芯片连接到设备制造者的服务器之后，IoT设备可以在步骤1034开始类似于图4中描述的TLS握手的TLS握手。因为IoT芯片用内置在固件中的设备制造者的公钥编程，所以在步骤1036认证设备制造者的服务器，并且在步骤1038创建加密的TLS连接。在步骤1040，设备生成芯片ID和一对公钥私钥，然后将芯片ID、公钥、设备型号和固件版本号从IoT设备发送到服务器，之后在步骤1042，设备制造者的服务器随机选择设备固件的码字的块号。在步骤1044，这些块号被发送到IoT芯片的可信执行环境。在步骤1046，IoT芯片的可信执行环境运行一段代码来采样固件码字的指定块，并将散列结果发送回设备制造者的服务器。在步骤1047，如果固件码字匹配设备固件，则在步骤1048，设备制造者的服务器验证设备和IoT芯片，并将芯片ID和公钥签署到证书中，并将证书发送给IoT芯片。然后，在步骤1050，IoT芯片将证书和芯片特定的私钥保存到受保护的OTP寄存器或等同物中，以供将来在认证中使用。如果在步骤1047，固件码字与设备固件不匹配，则在步骤1052，设备制造者的服务器不发布证书。图10C示出了用于从在线源向没有可信执行环境的设备的IoT芯片发布证书的方法1060。在步骤1062，IoT设备也称为IoT芯片首先连接到设备制造者的服务器。服务器可以是可通过连接访问的数据库。服务器可以通过互联网、本地网络、硬连线连接或一些其他机制来访问。设备制造者可以是IoT设备或IoT芯片可被集成到其中的系统或部分系统的制造商。在IoT芯片连接到设备制造者的服务器之后，IoT设备可以在步骤1064开始类似于图4中描述的TLS握手的TLS握手。因为IoT芯片用内置在固件中的设备制造者的公钥编程，所以在步骤1066认证设备制造者的服务器，并且在步骤1068创建加密的TLS连接。然后，在步骤1070，设备可以将设备型号和固件版本号从IoT设备发送到服务器，之后，在步骤1072，设备制造者的服务器生成一段测试代码。在步骤1074，测试代码在短期限deadline的情况下被发送到IoT芯片，该短期限覆盖代码执行时间和数据传输的往返时间。然后，测试代码对一些固件码字进行采样，并将散列结果发送回设备制造者的服务器。在步骤1075，如果固件码字匹配设备固件，则在步骤1076，设备制造者的服务器验证设备和IoT芯片，并向IoT芯片发布证书和相应的芯片特定的私钥，该证书包含唯一的IoT芯片ID和由设备制造者的私钥签名的芯片特定的公钥。然后，在步骤1078，IoT芯片将证书和芯片特定的私钥保存到受保护的OTP寄存器或等同物中，以供将来在认证中使用。如果在步骤1075，固件码字与设备固件不匹配，则在步骤1080，设备制造者的服务器不发布证书。在另一个实施例中，设备制造者可能希望芯片供应商允许自己发布证书。图11A示出了IoT芯片从芯片供应商的服务器接收证书的方法1100。在步骤1102，设备制造者可以向芯片供应商提供公钥和服务器URL或地址。然后，在步骤1104，设备固件可以触发IoT设备联系芯片供应商的服务器。在该实施例中，在IoT芯片已经联系了芯片供应商的服务器之后，该过程可以遵循图10的方法1000，其中证书由设备制造者的服务器发布。然而，在该实施例中，设备制造者的服务器被芯片供应商的服务器替换。在图11B的方法1101的实施例中进一步解释了图11A的步骤1102，在该步骤1102中设备制造者向芯片供应商提供其公钥和服务器URL或地址。IoT芯片可以首先在步骤1110连接到芯片供应商的服务器，之后在步骤1112，IoT设备开始TLS握手。TLS握手可以类似于上面参考图4描述的那样被创建。芯片供应商的证书可以在步骤1114中被认证，因为IoT芯片是用芯片供应商的公钥编程的。因此，在步骤1116中创建加密的TLS连接。然后，在步骤1118，IoT芯片可以将设备制造者的ID发送到芯片供应商的服务器。然后，在步骤1120，芯片供应商的服务器可以向IoT芯片发送相应的设备制造者的公钥和服务器URL或地址。然后，IoT芯片将设备制造者的密钥和服务器URL或地址保存到OTP寄存器或等同物中。在IoT芯片从芯片供应商的服务器获得必要信息后，设备制造者可以在验证设备固件有效之后通过TLS发布证书。通过TLS发布证书的实施例被示出为图11C的方法1103。IoT芯片可以在步骤1130连接到设备制造者的服务器，并且在步骤1132作为TLS握手，其类似于上面参考图4描述的TLS握手。可以在步骤1134创建加密的TLS连接。设备制造者的服务器可以被认证，因为IoT芯片具有设备制造者的公钥。然后，在步骤1136，设备固件可以将设备型号和固件版本发送给设备制造者的服务器。设备制造者的服务器可以在步骤1138生成具有一期限的一段测试代码，该期限覆盖代码执行时间和数据传输的往返时间，并且在步骤1140将该代码发送给IoT设备。测试代码可以对一些固件码字进行采样，并将散列结果发送回设备制造者的服务器。在步骤1141，如果码字匹配设备固件，则可在步骤1142确定设备和IoT芯片是非恶意的，并且设备制造者的服务器可以向IoT芯片发布证书和芯片特定的私钥。证书和芯片特定的私钥可以包括唯一的芯片ID和由设备制造者的私钥签名的匹配的公钥。在步骤1144，设备制造者的服务器还可以向IoT芯片发送一段可控设备固件测试代码和相应的测试结果。然后，在步骤1146，IoT芯片可以将证书、芯片特定的私钥、测试代码和结果保存到OTP寄存器或等同物。如果在步骤1141码字与设备固件不匹配，则在步骤1148，设备和IoT芯片可能被确定为恶意的，或者由于某些其他原因，设备制造商的服务器可能无法向IoT芯片发布证书和芯片特定的私钥。在一个实施例中，IoT芯片可以在提供基于证书的服务之前或者在传输任何数据之前检查设备固件的有效性。在该实施例中，IoT芯片固件可以基于当在步骤1142其发布证书时从设备制造者的服务器接收的可控设备固件测试代码随机生成一段测试代码。IoT芯片可以向设备固件发送代码，该代码具有仅涵盖代码执行时间的短期限。然后，测试代码可以对一些固件码字进行采样，并将散列结果发送回IoT芯片。固件码字匹配测试结果，该测试结果在设备制造商的服务器在步骤1142中发布证书时也从设备制造商的服务器接收，设备被确定为非恶意的，并且IoT芯片可以继续联网服务。在该实施例中，当恶意设备试图破解测试代码并通过欺骗服务器来获得证书时，恶意设备必须分析测试代码并通过研究设备固件的副本来生成正确答案。测试代码由随机码字随机生成，随机码字可包括无用指令如ADDSUBMULTIPY和有用指令的混合。为定时器分配一个短的超时值会使生成正确答案的努力失败。这个短的超时覆盖了运行测试代码并发回结果所需的时间，不会给恶意设备留下额外的开销来完成测试代码的分析并产生正确的答案。恶意设备需要大量时间来解汇编和理解随机生成的二进制代码。这个时间量大于提供的时间。在另一个实施例中，可以在发布的证书中添加到期时间，这可能需要执行图11A-C的过程，以在当前证书到期之前请求具有新到期时间的新证书。证书发布机构的重复特性给恶意设备造成了进一步的障碍。在各种实施例中，图2的嵌入式证书和图3-9的初始化、认证、引入和移除协议可用于在和低能耗BLE系统、Zigbee网络或WIFI系统中以强认证和更大易用性实现安全通信。本领域的普通技术人员将认识到，上述证书和协议可以用于本文没有列出的安全无线通信标准。上述解决方案可以被构建到现有和BLE以及WIFI芯片的固件中，或者构建到BLE、和WIFI芯片的特定硬件中。将解决方案构建到IoT片上系统SOC中可以遵循以下描述的架构。共享和公共内容例如图2的共享公共内容210可以保存到只读OTP寄存器或等效硬件中。第一证书图2的212可以要求唯一的芯片ID和芯片的公钥。证书可以由芯片供应商的私钥签名。可选的第二证书图2的222可以要求芯片供应商ID和芯片供应商的公钥。第二证书可以由证书颁发机构的私钥签名。本领域普通技术人员将理解，芯片供应商只需要这种证书几年，并且该证书可能足以持续IoT芯片的运行寿命。共享和公共内容可以包括芯片供应商的公钥，也可以包括主要芯片供应商和证书颁发机构的公钥。私有内容如图2的私有内容280可以包括IoT芯片的私钥和固件签名验证的秘密密钥。IoT芯片的私钥可以被保存到只写OTP寄存器，并且仅由将私钥应用于给定数据块的专用电路访问。在这个实施例中，寄存器不能被专用电路之外的CPU或任何AXI主机读取。在另一个实施例中，对于具有信任区TrustZone的ARMCPU，可通过ROM代码或认证固件在安全模式下读取OTP寄存器。在该实施例中，可以禁用安全模式下的JTAG。在又一个实施例中，只有保存在内部闪存中的ROM代码或安全引导加载器代码可以从可读OTP寄存器访问私钥，并且可以在专用内部SRAM中执行公钥私钥算法。作为私有内容一部分的用于固件签名验证的秘密密钥可以包括来自固件创作者author的秘密对称密钥或公钥。在该实施例中，固件创作者可以是芯片供应商以外的实体。秘密密钥的实现、存储和访问可以对应于上述私钥的实现、存储和访问。上述嵌入式证书和授权协议的应用可以针对具有强安全性的锁实现。蓝牙锁可以使用固定的PIN，并具有内置证书。蓝牙锁可能没有输入输出显示设备。唯一的ID可以打印在锁本身上。锁可以由带有不支持内置证书的蓝牙兼容芯片的手持装置控制。手持装置可以运行由锁制造商提供的应用“app”。尽管app的运行环境可能不安全，但对于这种实现方式，认为锁和应用都不会受到损坏。也就是说，app的数据可能会被其他设备读取和查看。锁的目标是防止潜在的窃听者打开锁，同时允许多个授权用户打开锁。在授权用户的手持装置上运行同一app的未授权用户应该无法打开锁。锁应该易于使用，并保护缺乏经验的用户免受恶意锁的侵害。图12示出了具有以上目标和参数的强安全性蓝牙锁的过程1200。首先，在步骤1202，用户可以从锁制造商下载app。在步骤1204，当app首次运行时，它生成具有高熵的appID和app密钥也具有高熵。然后，在步骤1206，app可以要求用户输入密码。用户输入的密码可以被称为app密码，并且具有低熵。在步骤1208，使用app密码的散列值，app可以生成对称密钥。在步骤1210，app可以用对称密钥加密appID和app密钥，并将加密结果保存到设备储存器。手持装置的设备储存器可以由其他设备读取，因此在一个实施例中，appID和app密钥可以使用手持装置上没有存储的秘密来加密。当用户需要输入app密码来运行app时，app不知道输入的密码是正确的还是不正确的。因此，低熵密码可以保护秘密数据，因为暴力攻击必须用真实且耗时的方法来验证。这种方法很容易被锁识别。在步骤1212，蓝牙手持装置可以与由于固定的PIN具有弱认证的锁配对。然后，在步骤1214，锁丢弃来自手持装置的除TLS消息之外的任何输入数据，以便认证不会被虚假数据中断。然后，在步骤1216，app可以遵循类似于上面在图4-9中描述的TLS协议，以使用锁内置证书来认证锁。在一个实施例中，app对应于图4-9的对方以及锁对应于IoT设备或IoT芯片。在锁验证了锁的证书之后，在步骤1218，app可以为用户显示在证书中的锁ID，以供用户验证它是否与打印在锁上的ID相同。在步骤1221，如果证书中的锁ID与打印在锁上的ID不相同，则app可以在步骤1220中断与锁的通信。如果在步骤1221，证书中的锁ID被识别为打印在锁上的ID，则在步骤1222，app可以用加密信道完成到锁的TLS握手，并且在步骤1222_2，检查IoT设备上存储的数据以获得验证的锁ID。此时，锁可能只接受来自app的三个命令：初始化、引入跟踪introduction_followup和认证。这是因为锁已经通过app的认证，但app尚未通过锁的认证。在步骤1223，app通过读取手持装置上存储的数据来检查锁ID是否已经被验证。如果锁ID已经被验证，则在步骤1224，锁被识别，使得锁可以从app接收附加命令。如果手持装置上存储的数据没有指示锁被验证，则在步骤1225确定锁是否是新锁。如果锁不是新的，在步骤1226，app可以联系制造商的网络服务器或在线数据库来验证锁ID。如果在步骤1225中锁是新锁，则app可以在步骤1228要求用户输入锁特定的密码，然后在步骤1230中发出初始化命令。初始化命令可以用来使app成为锁的初始主导master。如果没有现有的主导，在步骤1232，锁可以接受命令，并向app询问其app密钥和密码。在步骤1234，锁可以将appID、散列app密钥和散列锁特定的密码保存到存储器位置。本文描述的实施例可以与各种无线通信协议和范例一起使用，包括但不限于：蓝牙低能耗BLE、和WiFi。如受益于本公开的本领域普通技术人员将会理解，本文描述的各种步骤和过程的实施例不与特定的通信协议相关联，并且也可以与其他协议一起使用。在以上的描述中，阐述了许多细节。然而，对于获得本公开的益处的本领域中的普通技术人员将明显的是，本发明的实施例可在没有这些特定细节的情况下进行实践。在一些情况下，众所周知的结构和设备以框图形式而不是详细地示出，以免使本说明书模糊。详细描述的一些部分依据对计算机存储器内的数据位的操作的算法和符号表示来呈现。这些算法描述和表示是数据处理领域的技术人员使用来最有效地向本领域的其他技术人员传达他们工作的实质的手段。算法在此处并且通常被设想为导致期望结果的自我一致的步骤序列。这些步骤是需要对物理量进行物理操作的那些步骤。通常，虽然不是必须的，但是这些量采用能够被存储、传输、组合、比较和以其他方式操纵的电或磁信号的形式。主要出于习惯用法的原因，将这些信号称为位、值、元素、符号、字符、术语、数字等等已被证明有时是方便的。然而，应当记住，所有的这些和类似的术语与适当的物理量相关联并且仅仅是应用于这些量的方便标记。除非另有特别说明，否则如从上文讨论中所明显看出的，应认识到，在整个说明书中，使用诸如“加密”、“解密”、“存储”、“提供”、“得到”、“获得”、“接收”、“认证”、“删除”、“执行”、“请求”、“通信”、“初始化”等等的术语的讨论，指的是计算系统或者类似的电子计算设备的动作和处理，其中计算系统或者类似的电子计算设备将在计算系统的寄存器和存储器内表征为物理例如，电子量的数据操作和转换为在计算系统存储器或寄存器或者其他这样的信息存储、传输或者显示设备内类似表征为物理量的其他数据。本文中使用的单词“示例”或“示例性”意为用作示例、实例或例证。本文中被描述为“示例”或“示例性”的任何方面或设计不一定被解释为与其他方面或设计相比是优选或者有利的。更确切地讲，单词“示例”或“示例性”的使用旨在以具体的方式来提出概念。如在本申请中所使用的，术语“或”旨在表示包含性的“或”而不是排他性的“或”。也就是说，除非另有说明或从上下文中是清楚的，否则“X包括A或B”旨在表示自然包含的排列中的任一个。也就是说，如果X包括A；X包括B；或X包括A和B二者，那么在前述实例中的任一个下满足“X包括A或B”。另外，如在本申请和所附权利要求中使用的冠词“一a”和“一an”通常应该被解释为意指“一个或更多个”，除非另有说明或从上下文中清楚地针对单数形式。此外，贯穿全文使用的术语“实施例”或“一个实施例”或“实施方式”或“一个实施方式”不旨在意指同一个实施例或实施方式，除非如此描述。关于上述协议提及的特定命令或消息仅旨在具有说明性。本领域普通技术人员将理解，可以使用不同具体措辞但类似功能的命令，并且这些命令仍然落入上述描述的范围内。本文所描述的实施例还可涉及用于执行本文中的操作的装置。该装置可出于所需的目的而被特别构造，或者它可包括由被储存在计算机中的计算机程序选择性激活或重配置的通用计算机。这样的计算机程序可以被存储在非暂时性计算机可读存储介质中，诸如但不限于包括软盘、光盘、CD-ROM和磁光盘的任意类型的盘、只读存储器ROM、随机存取存储器RAM、EPROM、EEPROM、磁卡或光卡、闪存、或适用于储存电子指令的任何类型的介质。术语“计算机可读存储介质”应当被认为包括存储一个或更多个指令集的单个介质或多个介质例如，集中式或分布式的数据库和或相关联的高速缓存以及服务器。术语“计算机可读介质”也应当被认为包括能够存储、编码或携带由机器执行并导致机器实施任何一个或更多个本实施例的方法的指令集的任何介质。术语“计算机可读存储介质”相应地应当被认为包括，但不限于，固态存储器、光介质、磁介质、能够存储用于由机器执行并导致机器实施任一个或更多个本实施例的方法的指令集的任何介质。本文提出或提及的算法和显示不是固有地与任何特定计算机或其他装置相关。各种通用系统可以根据本文的教导与程序一起使用，或者可证明构建更专用的装置以执行所需的方法步骤是方便的。用于这些系统中的各种系统所需的结构将出现于以下描述中。另外，本实施例没有参考任何特定的编程语言来描述。将认识到，可以使用各种编程语言来实现如本文所述的实施例的教导。以上描述阐述了诸如特定系统、组件、方法等的示例的许多特定细节，以便提供对本发明的若干实施例的良好理解。然而，对于本领域的技术人员将明显的是，本发明的至少一些实施例可在没有这些特定细节的情况下进行实践。在其他实例中，众所周知的组件或方法没有具体描述或者是以简单的框图的形式来呈现，以避免不必要地使本发明模糊。因此，以上阐述的特定细节仅仅是示例性的。特定的实施方式可以与这些示例性细节不同并且仍然被视为在本发明的范围内。将要理解的是，以上描述旨在是例证性而不是限制性的。在阅读并且理解以上描述之后，许多其他实施例对于本领域的技术人员将是明显的。因此，本发明的范围应参考所附权利要求连同这些权利要求有权要求的等效物的整个范围来确定。

权利要求：1.一种用于连接到对方的物联网IoT设备，所述IoT设备被配置为执行指令以：在所述IoT设备和所述对方之间建立连接；如果所述IoT设备的标识ID存储在所述对方的访问控制列表ACL中，则开始认证协议；以及如果所述IoT设备的ID没有存储在所述对方的ACL中，则开始初始化协议，其中所述初始化协议在所述IoT设备和所述对方之间建立安全连接，使用该安全连接来开始所述认证协议。2.根据权利要求1所述的IoT设备，其中，所述初始化协议包括将所述IoT设备的ID与和所述对方相关联的在线数据库进行比较。3.根据权利要求1所述的IoT设备，其中，所述初始化协议包括：如果所述IoT设备的ACL不为空，则比较来自所述IoT设备的随机数的第一散列和来自所述对方的随机数的第二散列，并且如果它们相同，则继续所述初始化协议；如果所述IoT设备的ACL为空：如果所述对方向所述IoT设备发送证书，则用所述IoT设备验证所述证书并将对方ID保存到所述IoT设备的ACL，以及如果所述对方没有向所述IoT设备发送证书，则在来自所述IoT设备的秘密初始化请求和来自所述对方的秘密初始化请求响应之后，将所述对方ID保存到所述IoT设备的ACL；以及将所述对方和所述IoT设备之间的通信更改为基于共享秘密。4.根据权利要求1所述的IoT设备，其中，所述授权协议包括：如果对方ID在所述IoT设备的ACL中：如果所述对方在授权请求中发送证书，则使用所述IoT设备验证所述证书，以及如果所述对方没有在所述授权请求中发送证书，则验证来自所述对方和所述IoT设备的散列值，以及认证在所述对方和所述IoT设备之间的通信；以及如果所述对方ID不在所述IoT设备的ACL中，拒绝所述对方的授权。5.根据权利要求4所述的IoT设备，其中，使用所述IoT设备验证所述证书包括：从所述IoT设备向所述对方发送随机数；由所述对方和所述IoT设备计算所述随机数的散列值；比较来自所述对方的散列值和来自所述IoT设备的散列值；以及如果来自所述对方的散列值和来自所述IoT设备的散列值相同，认证所述IoT设备和所述对方之间的通信。6.根据权利要求1所述的IoT设备，其中，在所述IoT设备和所述对方之间建立连接包括：发送和接收去往和来自所述IoT设备和所述对方的多条消息；以及如果在允许的时间窗口内接收到所述多条消息，则在所述IoT设备和所述对方之间建立通信链路。7.一种包括存储器的设备，所述存储器存储嵌入式证书，所述嵌入式证书包括：共享公共内容，所述共享公共内容包括：唯一芯片标识ID和芯片公钥，第一芯片供应商ID和第一芯片供应商公钥，以及第一散列块和第一加密结果的第一存储位置；非共享公共内容，所述非共享公共内容包括所述第一芯片供应商公钥；以及私有内容。8.根据权利要求7所述的设备，所述共享公共内容还包括：第二芯片供应商ID和第二供应商公钥；证书颁发机构ID和证书颁发机构公钥；以及第二散列块和第二加密结果的第二存储位置。9.根据权利要求7所述的设备，所述非共享公共内容还包括至少第二芯片供应商公钥。10.根据权利要求7所述的设备，所述非共享公共内容还包括至少一个证书颁发机构公钥。11.根据权利要求7所述的设备，其中，所述私有内容包括用于IoT集成电路的私钥。12.根据权利要求7所述的设备，其中，所述嵌入式证书被保存在实时可编程OTP寄存器中。13.根据权利要求7所述的设备，其中，所述嵌入式证书被保存在安全闪存中。14.根据权利要求7所述的设备，其中，所述嵌入式证书通过以下方式被验证：计算所述唯一芯片ID和所述芯片公钥的散列值，所述散列值由所述第一芯片供应商的公钥签名；从所述散列值和所述第一芯片供应商的公钥生成解密的散列值；以及如果所述散列值和所述解密的散列值相同，则验证所述嵌入式证书。15.一种用于通过物联网IoT设备从设备制造商的在线数据库接收嵌入式证书的方法，所述方法包括：在所述IoT设备和所述设备制造商的服务器之间建立连接；认证所述设备制造商的服务器；在所述IoT设备和所述设备制造商的服务器之间创建加密连接；通过所述设备制造商的在线数据库生成测试代码，并将所述测试代码发送到所述IoT设备；在所述IoT设备执行所述测试代码之后，将来自所述IoT设备的多个固件码字与设备固件的预期码字进行比较；以及如果来自所述IoT设备的固件码字与设备固件的预期码字匹配，则从所述设备制造商的服务器向所述IoT设备发布所述嵌入式证书。16.根据权利要求15所述的用于通过物联网IoT设备从设备制造商的服务器接收嵌入式证书的方法，其中，生成测试代码还包括添加所述IoT设备运行所述测试代码并响应所述设备制造商的服务器的期限。17.根据权利要求15所述的用于通过物联网IoT设备从设备制造商的服务器接收嵌入式证书的方法，其中，所述嵌入式证书被保存在所述IoT设备的安全闪存中。18.根据权利要求15所述的用于通过物联网IoT设备从设备制造商的服务器接收嵌入式证书的方法，其中，在所述IoT设备和所述设备制造商的服务器之间的加密连接被创建之后，所述IoT设备向所述设备制造商的服务器发送设备型号和固件版本号。19.根据权利要求18所述的用于通过物联网IoT设备从设备制造商的服务器接收嵌入式证书的方法，其中，所述测试代码从来自所述IoT设备的所述设备型号和固件版本号中导出。

百度查询： 赛普拉斯半导体公司 用于无线IOT系统的强认证和易用性的嵌入式证书方法

免责声明
1、本报告根据公开、合法渠道获得相关数据和信息，力求客观、公正，但并不保证数据的最终完整性和准确性。
2、报告中的分析和结论仅反映本公司于发布本报告当日的职业理解，仅供参考使用，不能作为本公司承担任何法律责任的依据或者凭证。

阅读全文 双屏查看 官方信息 专利公告 收藏专利 下载PDF 下载WORD