CN110770695B

CN110770695B - 物联网(iot)设备管理

Info

Publication number: CN110770695B
Application number: CN201880039511.0A
Authority: CN
Inventors: D·A·波查夫; M·A·汉堡; P·罗哈吉; A·卡普尔; J·P·威滕奥尔
Original assignee: Cryptography Research Inc
Current assignee: Cryptography Research Inc
Priority date: 2017-06-16
Filing date: 2018-06-14
Publication date: 2024-01-30
Anticipated expiration: 2038-06-14
Also published as: WO2018232111A1; JP7457173B2; JP7227919B2; US11777926B2; JP2020523806A; CN110770695A; JP2023053159A; US20200145409A1

Abstract

本文中描述的实施例描述了用于解决物联网(IoT)基础设施中的设备证书的初始建立的技术。实施例涉及与端点类型无关地统一安全证书建立，从而解决IoT设备中的巨大多样性的挑战。该方法旨在解决将IoT端点初始可信登记到安全基础设施中的挑战，该安全基础设施允许IoT环境中的设备之间的安全通信。

Description

物联网(IOT)设备管理

背景技术

对安全系统和应用的需求正在增长。当前，安全集成电路(IC)经常在工厂车间利用安全密钥编程。安全密钥可以以多种方式使用，例如，以保护存储的数据，控制对数字内容的访问，或者加密/认证在事务中使用的数据。这些密钥可以存储在一次性可编程存储器中，该存储器可以直接保存密钥，也可以保存与密码功能一起使用的基本密钥，该密码功能得出用于各种功能的密钥。通常，通过在安全设施中执行密钥加载过程来提供安全性。物联网(IoT)设备和IoT应用的使用也在增长。IoT设备需要证书才能附接到IoT应用服务和IoT平台服务。但是，由于在制造时提供证书所需要的设备和专业知识，很难在制造中提供这些证书。此外，IoT设备的计算和存储资源各不相同，并且常常受到限制。

附图说明

在附图的图中，以示例而非限制的方式示出了本发明。

图1示出了根据一个实施例的IoT设备管理(IDM)系统的系统图。

图2是示出根据一个实施例的IDM系统的数据流序列的流程图。

图3A是示出根据一个实施例的在信任和策略建立阶段期间在设备供应服务与RoT认证服务之间的数据流序列的流程图。

图3B是示出根据一个实施例的在设备供应阶段期间在IoT设备与设备供应服务之间的数据流序列的流程图。

图3C是示出根据一个实施例的在设备供应阶段的认证过程期间在IoT设备与RoT认证服务之间的数据流序列的流程图。

图3D是示出根据一个实施例的在设备供应阶段的接入过程期间在IoT设备、设备供应服务、和RoT认证服务之间的数据流序列的流程图。

图3E是示出根据一个实施例的在设备供应阶段期间的用于认证过程和注册过程的在IoT设备、设备供应服务、和IoT应用服务之间的数据流序列的流程图。

图3F是示出根据一个实施例的在应用数据阶段期间在IoT设备、设备供应服务、和IoT应用服务之间的数据流序列的流程图。

图4是示出根据一个实施例的在IoT设备、RoT认证服务、设备供应服务、和IoT应用服务之间的交互序列的流程图。

图5是示出根据一个实施例的在IoT设备、RoT认证服务、设备供应服务、和IoT应用服务之间用于认证和身份服务的交换的消息序列的流程图。

图6是示出根据一个实施例的针对图10的序列在每个相关组件上执行的各种操作的流程图。

图7是示出根据一个实施例的在IoT设备、RoT认证服务、设备供应服务、和IoT应用服务之间交换的HTTP消息序列的流程图。

图8是示出根据一个实施例的在IoT设备、RoT认证服务、设备供应服务、和IoT应用服务之间的用于认证、身份和数据证明的一系列交互的流程图。

图9是根据一个实施例的基于pubDB的供应过程的流程图。

图10是示出根据一个实施例的针对图14的序列在每个相关组件上执行的各种操作的流程图。

图11是根据一个实施例的基于签名PKI的供应过程的流程图。

图12是示出根据一个实施例的针对图16的序列在每个相关组件上执行的各种操作的流程图。

图13是根据一个实施例的用于对称核心的基于TLS PKI的供应过程1900的流程图。

图14是根据一个实施例的用于非对称核心的基于TLS PKI的供应过程1900的流程图。

图15是根据一个实施例的实时安全检查过程的流程图。

图16是根据一个实施例的用于安全地供应IoT设备的方法的流程图。

图17是根据一个实施例的其中可以执行本文中描述的任何方法的计算机系统的一个实施例的图。

具体实施方式

本文中描述的是涉及物联网(IoT)设备管理的技术。IoT设备需要证书才能附接到应用服务、平台服务等。但是，由于所需要的设备和专业知识，很难在制造中提供这些证书。本文中描述的是IoT安全服务(ISS)基础设施，其可以用于在现场唯一地标识这些IoT设备，质询IoT设备，获取IoT设备内部的密码材料的知识，并且验证IoT设备是否具有自己的密码材料的知识。一旦IoT设备已经提供了其身份的证明，便可以向该IoT设备提供证书以连接到平台服务、应用服务等。IoT设备具有唯一的身份和密码密钥。ISS基础设施具有关于设备内部的该密码密钥的知识。IoT设备可以向ISS基础设施的服务器中的一个发送消息，以请求特定平台服务的证书。ISS基础设施的服务器可以向该IoT设备发送质询。IoT设备使用密钥来计算质询，并且在响应中将密码计算发送回服务器。服务器验证对质询的响应以及其身份和IoT设备内部的密码密钥的预知是否正确。在对质询的响应被验证之后，服务器可以向IoT设备分发平台证书。

以前，将端点登记到IoT域中的典型场景涉及手动登记。手动登记过程需要由设备(例如，IoT集线器或平台设备)将电缆插入端点中以为IoT设备建立证书。这很难大规模执行，并且无法远程执行。本文中描述的实施例允许远程且大规模地管理IoT设备，包括IoT设备的登记。

在一个实施例中，一种用于建立分布式信任网络的系统具有带有硬件或软件信任根的设备、向该设备提供应用的应用服务、以及具有该设备的信任根的直接知识的信任根服务。信任根服务器为应用服务提供认证服务和安全供应服务，使得应用服务可以与设备建立可信连接，而无需具有设备的信任根的直接知识。直接知识可以基于在设备的设备制造期间供应的一个或多个密钥。直接知识表示该信息是通过系统本身以外的其他方式接收的。该信息可以带外(空间外部)或之前(时间外部)交换。

图1示出了根据一个实施例的IoT设备管理(IDM)系统100的系统图。IDM系统100包括提供认证服务104和设备供应服务106的信任根(RoT)服务102，以便IoT应用服务108可以与IoT设备110建立可信连接，而无需具有IoT设备110的RoT的直接知识。IoT设备110的RoT可以是硬件RoT、软件RoT或其任何组合。RoT服务102包括认证和授权策略服务器112(下文中称为“认证策略服务器112”)和RoT身份服务器114。IoT设备110可以使用灵活的前端协议101(标记为用于认证和授权的AuthN和AuthZ协议)与认证服务104通信。在一个实施例中，认证策略服务器112和RoT身份服务器114使用独立于前端协议101的后端协议103(诸如超文本传输协议安全(HTTPS))通信。在一些实施例中，前端协议101保持IoT设备110的状态，并且后端协议是无状态的。前端协议101可以包括针对IoT设备的芯片制造方的业务需求、通信协议、和认证协议。认证服务104可以在两个服务器之间被划分，作为安全性与灵活性之间的折衷。通过将RoT身份服务器114作为与认证策略服务器112分开的服务器，可以具有灵活性和安全性。认证策略服务器112可以在与不同类型的IoT设备的协议特定的通信中提供灵活性，而由RoT身份服务器114中存储的安全证书可以被保护。例如，RoT身份服务器114可以包含需要被保护的设备密钥的数据库。与IoT设备110对RoT身份服务器114的更直接访问相比，可以由认证策略服务器112管理对RoT身份服务器114中的数据库的访问，该认证策略服务器112在提供由RoT身份服务器114存储的安全证书之前，认证IoT设备并且授权IoT设备110。实际上，可以认为RoT身份服务器114对IoT设备110隐藏。在其他实施例中，认证策略服务器112和RoT身份服务器114可以在单个服务器中一起实现。在一个实施例中，前端协议101包括针对IoT设备101的芯片制造方的业务需求、用于设备之间的通信的通信协议、以及用于认证IoT设备110的认证协议。应当注意，尽管示出了一个认证策略服务器112和一个RoT身份服务器112，但是在其他实施例中，认证服务104可以包括多个认证策略服务器和多个RoT身份服务器、或其任何组合。例如，可以有多个认证策略服务器，但是只有一个RoT身份服务器114。

如上所述，RoT服务102包括设备供应服务106。如图所示，前端供应策略服务器116和后端供应服务器118可以提供设备供应服务106。IoT设备110可以使用协议特定的前端协议105(标记为设备供应)与前端供应策略服务器116通信。在一个实施例中，前端供应策略服务器116和后端供应服务器118使用独立于前端协议105的后端协议107(诸如HTTPS)通信。设备供应服务106可以在两个服务器之间划分，作为安全性与灵活性之间的折衷，非常类似于认证服务104的认证策略服务器112和RoT身份服务器114。通过将供应服务器118作为与供应策略服务器116分开的服务器，可以具有灵活性和安全性。供应策略服务器116可以在与不同类型的IoT设备的协议特定的通信中提供灵活性，而供应服务器118可以对IoT设备110隐藏。在其他实施例中，供应策略服务器116和供应服务器118可以在单个服务器中一起实现。应当注意，尽管示出了一个供应策略服务器116和一个供应服务器118，但是在其他实施例中，设备供应服务106可以包括多个供应策略服务器和多个供应服务器、或其任何组合。例如，可以有多个供应策略服务器，但是只有一个供应服务器118。在一个实施例中，前端协议101保持状态，并且后端协议103是无状态的。在一个实施例中，前端协议105包括针对IoT设备101的芯片制造方的业务需求、用于设备之间的通信的通信协议、以及用于认证IoT设备110的认证协议。前端协议105还可以标识应当用于认证IoT设备110的RoT认证服务。

如图1所示，策略供应服务器116可以经由安全连接109与认证策略服务器112(和RoT身份服务器114)通信。通过安全连接109，策略供应服务器116可以例如通过如下所述提供消息认证码(MAC)来与认证策略服务器112交换安全证书、建立策略、以及交换会话证书。策略可以包括何时供应IoT设备110和/或何时不供应IoT设备110的规则或决定。

如上所述，RoT服务102提供认证服务104和设备供应服务106，以使得IoT应用服务108可以与IoT设备110建立可信连接，而无需具有IoT设备110的RoT的直接知识。IoT应用服务108包括IoT应用网关120和IoT应用服务器122以向IoT设备110提供IoT应用。IoT设备110可以使用协议特定的前端协议111(标记的应用数据)与IoT应用网关120通信。在一个实施例中，IoT应用网关120和IoT应用服务器122可以使用独立于前端协议111的后端协议113通信。该后端协议113可能不一定是安全的，因为应用数据是通过如本文所述的安全连接传送的。备选地，IoT应用网关120和IoT应用服务器122可以使用HTTPS通信。IoT应用网关120可以确定IoT 110是否具有对IoT应用服务器122的访问。也就是说，IoT应用网关120可以在IoT应用服务器122向IoT设备110提供IoT应用服务108之前认证/授权IoT设备110。实际上，可以认为IoT应用服务器122对IoT设备110隐藏。在其他实施例中，IoT应用网关120和IoT应用服务器122可以在单个服务器中一起实现。应当注意，尽管示出了一个IoT应用网关120和一个IoT应用服务器122，但是在其他实施例中，IoT应用服务108可以包括多个IoT应用网关和多个IoT应用服务器。

如图1所示，IoT应用网关120可以经由安全连接115与供应策略服务器116(和供应服务器118)通信。通过安全连接115，供应策略服务器116可以交换由IoT设备110呈现的所供应的信息以检查是否应当由IoT应用网关120授予对IoT设备110的访问，如下所述。

认证服务104可以由诸如认证服务提供方的第一实体管理。设备供应服务106可以由诸如IoT平台提供方的第二实体管理。IoT应用服务108可以由第三实体管理。在某些情况下，认证服务104和设备供应服务106可以由单个实体管理。在某些情况下，设备供应服务106和IoT应用服务108可以由单个实体管理。还应当注意，这些服务的服务器可以部署在多台机器中，并且可以位于单独的设施中。例如，认证服务104的服务器可以部署在安全数据中心，并且设备供应服务106和IoT应用服务108的服务器可以部署在云数据中心。

在另一实施例中，IoT安全分析服务130可以与认证服务104、设备供应服务106、和IoT应用服务108中的每个通信，以收集用于ISS基础设施的数据分析的信息。在图1所示的实施例中，IoT安全分析服务130与IoT应用网关120、供应服务器118、和RoT身份服务器114通信。在其他实施例中，IoT安全分析服务可以与相应服务内的其他服务器通信以收集数据进行分析。

在一些实施例中，IoT设备110包括硬件RoT。在其他实施例中，IoT设备110包括软件RoT。在一个实施例中，IoT设备110的密码核心(也称为安全核心)可以管理对硬件或软件RoT的访问。代替用户具有证书，IoT设备具有存储在认证服务104处的属性。这些属性被称为RoT属性，并且可以包括：1)会话密钥；2)序列(接受的输入)；3)容器(程序、代码等)；4)得出的密钥，或其任何组合。认证服务104可以向外部各方授权对RoT属性的使用，诸如设备供应服务106、固件更新、组隐私身份等。在一些实施例中，RoT属性不需要存储在数据库中，而是可以由认证服务104按需生成。RoT属性可以是密钥资料、设备元数据(诸如内核版本等)、或其他属性。

在一个实施例中，认证策略服务器112是可以位于第一设施中的密码学研究部(CRD)认证/授权(AuthN/AuthZ)策略服务器。如本文所述，认证策略服务器112可以负责AuthN/AuthZ策略和令牌管理。认证策略服务器112可以将令牌发回到IoT设备110(客户端)，并且可以利用RoT身份服务器114。认证策略服务器112可以主要用于将客户端侧策略和协议映射到RoT身份服务器114的一个或多个应用编程接口(API)集合。RoT身份服务器114可以负责存储和管理IoT设备110中的RoT安全核心的RoT属性。例如，在对称密钥密码系统中，RoT身份服务器114可以存储对称密钥。

在设备供应服务器106处，供应策略服务器116可以类似于认证策略服务器112，操作为管理IoT设备110的供应策略的前端服务器。供应策略服务器116可以是用于在IoT设备110上供应信息的特定服务器的前端。例如，供应服务器118可以发出证书。供应策略服务器116可能期望访问令牌作为供应请求的一部分，其中访问令牌应当已经由认证策略服务器112发出。供应策略服务器116可以潜在地使用访问令牌来请求相关联的RoT的其他属性。如果令牌和请求有效，则供应策略服务器116可以向IoT设备110发出供应信息，并且还可以通知服务提供方平台(例如，设备供应服务106的运营方)。这可以经由供应服务器118的API来完成。供应服务器118还可以包括用于撤销设备证书的附加API调用。在这种情况下，供应策略服务器116可以呼叫服务提供方以撤销证书。供应服务器118可以负责为证书颁发机构供应必要的信息。

在IoT应用服务108处，IoT应用网关120负责获取与IoT设备110上的安全状态有关的IoT客户端数据，并且将IoT设备110重定向到IoT应用服务器122。虽然IoT应用网关120被示出为服务器，但是在其他实施例中，IoT应用网关120可以被实现为规则集合，该规则集合被集成到由IoT应用服务器122或IoT平台提供方提供的API中。IoT应用服务器122可以被配置为仅允许具有有效证书的IoT设备110连接到IoT应用。IoT应用服务器122可以通过传输层协议安全(TLS)支持消息排队遥测传输(MQTT)。备选地，IoT应用服务器122可以支持其他发布-订阅消息协议。IoT应用服务器122可以使用或者可以不使用消息代理。IoT应用服务器122可以允许提供IoT应用数据以及用于应用逻辑的用户界面(UI)。

在IoT安全分析服务130处，(多个)服务器负责分析数据并且报告数据中的异常。除了提供认证统计信息之外，IoT安全分析服务130还可以用于检测异常和非证书数据，这些异常和非证书数据可以作为策略决策或修改策略决策的业务逻辑的输入或考虑因素。

在一个实施例中，可以将客户端软件开发套件(SDK或devkit)提供给IoT设备制造方或IoT平台提供方，以允许创建与IoT应用交互的应用。客户端SDK可以提供基于功能的插件架构，该架构具有执行从服务器下载的脚本以实现特定简档或策略的附加能力。插件可以是动态的，并且可以下载附加插件。一些具有很少资源的IoT设备可能没有存储所有插件。插件可以经由动态脚本(例如，嵌入式Lua)绑定在一起，动态脚本本身是可下载的(被签名以用于认证)。IoT设备110还可以被提供有支持各种AuthN/AuthZ模型的认证库。例如，在Open ID协议的情况下，这些库和插件可能需要很小。也可以提供对X.509证书的供应库支持，但是在计算资源方面，供应库可能需要非常简单和轻便。例如，IoT客户端库可以包括由第三方供应方或IoT平台提供方提供的IoT客户端库。这些IoT客户端库可以通过TLS使用MQTT。

图2-3F是示出图1的各个组件之间的数据流的数据流序列图。对于数据流序列图，存在对认证令牌请求、身份令牌、和访问令牌的引用。认证令牌请求可以是来自RoT身份服务器114(例如，开放式IoT身份连接服务器)的针对令牌的客户端请求(即，IoT设备110)。根据请求的范围，RoT身份服务器114可以返回身份令牌、访问令牌、或两者。身份令牌可以表示认证过程和协议的结果。身份令牌可以包含IoT设备110的RoT的标识符。身份令牌可以包含关于RoT的附加信息(例如，关于设备、内核、操作系统的元数据)以及关于如何在认证服务处认证RoT的细节。访问令牌可以允许访问资源，诸如该资源是关于RoT的RoT属性。访问令牌可以包含关于RoT的信息。该信息可以被认为是关于IoT设备110、IoT设备110的内核、操作系统(OS)等的元数据。外部服务使用关于RoT的信息(元数据)来访问RoT属性。

关于图2-3F描述的实施例旨在用于解决IoT设置中设备证书的初始建立的方法。实施例旨在统一安全证书建立，而与端点类型无关，从而解决IoT设备中的巨大多样性的挑战。该方法旨在解决将IoT端点初始可信登记到安全基础设施中的挑战，该安全基础设施允许IoT环境中的设备之间的安全通信。

图2是示出根据一个实施例的IDM系统的数据流序列200的流程图。数据流序列200分为信任建立阶段202、安全设备供应阶段204、和应用数据阶段206。在信任建立阶段202，设备供应服务106和RoT认证服务104交换安全证书201、建立策略203，并且可选地通过通信信道交换会话证书205。通信信道可以是安全通信信道，并且可以是带外通信信道以提供附加安全性。所建立的策略可以包括决策逻辑，该决策逻辑用于确定是否供应IoT设备110，是否认证IoT设备110，是否授权IoT设备110等。

在安全设备供应阶段204，IoT设备110向设备供应服务106发送具有设备简档信息207的请求。设备简档信息207可以包括在制造方使用描述(MUD)文件中描述的统一资源定位符(URL)。MUD文件可以描述如何与特定设备交互。MUD文件可以包括简档标识符。MUD文件还可以指定要使用的RoT认证服务，以使得RoT认证服务具有针对IoT设备的特定RoT的计算。在框208处，设备供应服务106可以从设备简档信息207中确定要由RoT认证服务104使用来认证IoT设备110的认证方法。认证方法可以具有相关联的标识策略标识符。而且，在框208处，设备供应服务106可以在重定向响应209中的URL中编码标识策略标识符。设备供应服务106向IoT设备110发送重定向响应209以将IoT设备110重定向到在所选择的策略中指定的RoT认证服务104。例如，重定向响应209可以包括用于IoT设备110连接到RoT认证服务104的连接点。IoT设备110向RoT认证服务104(即，向在重定向响应209中指定的连接点)发送RoT信息。在框212处，RoT认证服务104标识该策略并且确定该策略下的要求以建立IoT设备110的身份并且潜在地向IoT设备110发出令牌(例如，访问令牌)。RoT认证服务104可以评估设备是否具有正确的RoT信息。RoT认证服务104和IoT设备110根据指定策略建立身份213，并且当根据策略建立身份213时，RoT认证服务104根据该策略发出令牌215。RoT认证服务104或设备供应服务106可以发送质询以及MAC，并且评估响应以验证IoT设备100。令牌215可以是如本文中所述的访问令牌或访问令牌和身份令牌。然后，IoT设备110向设备供应服务106发送具有令牌217的供应请求。在框218处，设备供应服务106验证请求和令牌。设备供应服务106可以可选地向IoT应用服务108发送消息219以向IoT应用服务108注册或撤销IoT设备110。MUD文件可以指定设备供应服务106是否应当注册IoT设备110、以及哪个IoT应用服务108应当注册IoT设备110，诸如设备供应服务106应当连接到哪里以注册IoT设备110。IoT应用服务108可以提供注册或注册服务，该注册或注册服务由RoT认证服务添加以向IoT应用服务108提醒并通知特定IoT设备110的证书。在框218处，如果请求和令牌被验证，则设备供应服务106向IoT设备110发出供应信息221。

在应用数据阶段206期间，IoT设备110和IoT应用服务108使用供应信息221来连接和交换数据223。

IDM系统的数据流序列200可以被认为是委托的认证系统，因为认证是由IoT应用服务108委托给RoT认证服务104的(和/或与设备供应服务106相关地)。

图3A是示出根据一个实施例的在信任和策略建立阶段302期间在设备供应服务106与RoT认证服务104之间的数据流序列300的流程图。在信任和策略建立阶段302期间，设备供应服务106和RoT认证服务104交换安全证书301。安全证书301可以包括密钥、MAC等以建立设备供应服务106与RoT认证服务104之间的安全连接。设备供应服务106和RoT认证服务104可以通过通信信道交换安全证书。该通信信道可以是安全通信信道。安全通信信道可以是带外通信信道，以更加安全。设备供应服务106可以向RoT认证服务104请求303认证方法的列表，并且RoT认证服务104可以利用认证方法的列表来响应304。例如，对于给定类别的IoT设备，可以使用特定的认证方法，而不同类别的IoT设备可以使用不同的认证方法。对于列表中的每个认证方法，设备供应服务106可以使用循环305来选择307认证方法中的每个并且为每个认证方法分配策略标识符。可以在重定向响应的URL中加密策略标识符。对于每个认证方法，设备供应服务106可以将策略标识符309和认证方法的列表上载到RoT认证服务104。策略标识符还可以定义对在验证后返回到IoT设备311的令牌的要求311。设备供应服务106和RoT认证服务104还可以交换会话密钥313。

图3B是示出根据一个实施例的在安全设备供应阶段402期间在IoT设备与设备供应服务106之间的数据流序列400的流程图。在安全设备供应阶段402期间，IoT设备100向设备供应服务106发送设备简档信息401(例如，在MUD中描述的URL)。设备供应服务106基于简档信息401中的简档标识符来获取供应策略信息403。设备供应服务106确定要请求的标识策略405，并且向IoT设备110发送重定向响应407。重定向响应407可以利用包含用于认证的加密策略标识符的URL(例如，URL/Topic/...)将IoT设备110重定向到RoT认证服务104。应当注意，供应策略描述了由于设备与ISS后端之间的整个交互而在什么情况下以及在设备中供应了什么。标识策略向ISS基础设施的后端描述如何认证设备。需要后者，因为例如取决于设备的类型，可以通过多种方式认证设备(诸如多个密钥数据库)。

图3C是示出根据一个实施例的在安全设备供应阶段的RoT认证过程502期间在IoT设备与RoT认证服务之间的数据流序列的流程图。IoT设备110将RoT信息501发送到RoT认证服务104(例如，使用在来自设备供应服务106的重定向中供给的连接点)。在框503处，RoT认证服务140解密要应用的策略标识符(如果在URL中被加密)。RoT认证服务104向IoT设备110发送质询507，并且IoT设备110向RoT认证服务104发送回响应509。在框511处，RoT认证服务104验证响应。RoT认证服务104可以在循环505中针对在与策略标识符相关联的策略中指定的每个策略执行质询和响应。循环505可以由供应策略服务发起，并且涉及RoT认证服务(又称为RoT身份服务器)。然而，在备选实施例中，质询可以由RoT认证服务发出和验证。尽管未示出该流程，但是它可以更复杂，但是从根本上可以基于设备认证质询/响应来实现相同的令牌发出。

在另一实施例中，如果允许，IoT设备110可选地向RoT认证服务104发送数据513以协商、生成、或修改RoT属性。RoT认证服务104可以向IoT设备110发送回数据515，并且在框517处生成或修改RoT属性。

在一个或多个标识策略被验证之后，继续进行认证过程，RoT认证服务104在框519处生成访问令牌。在另一实施例中，RoT认证服务104可以可选地在框521处生成RoT身份令牌。RoT认证服务104向IoT设备110发送令牌523(在框519处的访问令牌和在框521处的可选身份令牌)。RoT认证服务104也向IoT设备110发送重定向响应525。重定向响应525可以将IoT设备100重定向到IoT应用服务108。

图3D是示出根据一个实施例的在安全设备供应阶段的访问过程602期间在IoT设备、设备供应服务、和RoT认证服务之间的数据流序列的流程图。在访问过程602期间，IoT设备110可以向设备供应服务106发送具有访问令牌的请求601。在一个实施例中，设备供应服务106验证令牌603并且向RoT认证服务104发送访问令牌。RoT认证服务104验证访问令牌607并且向设备供应服务106发送验证响应609。在另一实施例中，设备供应服务106从访问令牌611中提取属性并且发送请求613以从RoT认证服务104请求附加的RoT安全信息。RoT认证服务104检查对安全属性615的访问，并且将RoT安全属性发送回设备供应服务106。RoT安全属性应当包括策略标识符。继续访问过程602，设备供应服务106验证安全属性619，包括策略标识符。

图3E是示出根据一个实施例的在安全设备供应阶段期间用于认证过程和注册过程的在IoT设备110、设备供应服务106、和IoT应用服务108之间的数据流序列的流程图。作为其中设备供应服务106发送请求703并且从IoT设备110接收响应705的循环701的一部分，可以执行证书过程702和可选的注册过程704。

在证书过程702中，IoT设备110可以向设备供应服务106发送证书请求707。设备供应服务106验证709证书请求，并且向IoT设备110发送证书711。然而，如果设备供应服务106未验证证书请求，则证书711不被发送到IoT设备110。

在注册过程704中，设备供应服务106向IoT应用服务108发送请求713，以注册IoT设备110或其相关联的访问令牌。IoT应用服务108为请求713执行本地注册715。作为注册过程704的一部分，IoT应用服务108还可以向设备供应服务106发送确认响应(ACK)717。

图3F是示出根据一个实施例的在应用数据阶段802期间在IoT设备110、设备供应服务106、和IoT应用服务108之间的数据流序列的流程图。在应用数据阶段802期间，IoT设备110可以通过发送具有供应信息的请求801来与IoT应用服务108连接。IoT应用服务108可以允许或拒绝803请求。IoT设备110可以向IoT应用服务108发送后续消息805、809，并且从IoT应用服务108接收相应的响应807、811。当IoT设备110完成访问IoT应用服务108时(例如，不再访问IoT应用)，IoT设备110可以发送从IoT应用服务断开的请求813。IoT应用服务108可以发送确认响应815(ACK)。

在另一实施例中，IoT应用服务108可以执行访问检查804以确定IoT设备110是在黑名单还是白名单上。在一个实施例中，IoT应用服务108向设备供应服务106发送请求817以及所供应的信息。设备供应服务106检查该IoT设备110是否具有访问819，并且将结果821发送回IoT应用服务108。访问检查804可以是基于拉取的模型，如图所示。备选地，访问检查804可以是基于推送的模型。

在一些实施例中，IoT设备110包括密码管理器(CM)核心，并且可以被称为CM核心设备。CM核心可以用作设备的代理。CM核心是能够执行命令集合的硬件核心。序列可以被数字签名和/或携带有效性的其他密码证明(例如，MAC)，CM核心可以验证该序列以确认序列的原始和有效性。这可以控制CM核心将接受哪些数据(以及将执行哪些操作)，即使用于传递序列的通信通道是不可信的。在一个实施例中，CM核心是CryptoManager^TM核心。CryptoManager^TM核心是硬件核心，其可以提供对特征激活、配置管理、和安全密钥管理的密码控制。CryptoManager^TM核心可以集成到片上系统(SoC)设计中，并且可以经由位于SoC主总线上的寄存器接口进行访问。模块是包含指令和数据的程序，该程序的执行可以产生序列的安全构建。序列可以是由在委托装置设备内的硬件安全模块(HSM)上运行并且由CM核心使用的模块产生的二进制数据。

在一个实施例中，CM核心可以利用相应的服务来提供安全事务处理以建立如本文所述的IoT标识以及RoT认证和授权。IoT设备110可以由生产移动设备的芯片组的无工厂半导体供应方、制造移动互联网连接设备的系统集成方(OEM)、以及将这些设备部署在其无线网络上的移动网络运营方(MNO)等制造和/或管理。这些公司可以将其设备或组件的某些制造外包给操作远程制造设施的第三方制造方，诸如大批量制造场所。作为客户制造和通信系统的关键任务部分，基础设施的设计优先级是高可用性和完整性。鉴于IoT设备的多样性和经常受限的计算资源，本文中描述的实施例可以使用上面关于图1-3F描述的RoT身份、认证、和授权过程来提供高可用性和完整性。在一个实施例中，RoT认证服务104(以及相关联的服务器)可以充当保护主密钥并且授权具有IoT应用服务108的IoT设备110的安装、配置、和操作的实体。每个设备可以包括HSM，HSM可以用作保护敏感数据的保管库，并且用作用于执行与敏感数据相关联的命令或操作的平台。敏感数据可以是令牌、密钥、序列号、设备特定信息、固件等。

应当注意，描述的各个部分将组件、设备、或服务称为逻辑实体。有时，逻辑实体的内部结构很重要。例如，服务可以包括多个服务器、共享文件系统、共享数据库等。在服务的内部构件很重要并且这些服务器中的每个被视为逻辑实体的情况下，每个服务器被称为单独的服务器设备以将其与可以执行不同操作的其他设备区分开。每个服务器或设备可以包括主计算设备(例如，处理器等)以及可选的嵌入式HSM。一些ID和密钥将存储在HSM内部，而其他ID和密钥将存储在设备的硬盘驱动器上。如本文所述，ID或密钥的确切位置基于ID或密钥的敏感性和实现细节来确定。ID用于标识基础设施内的组件。还应当注意，以上关于图2-3F描述的各种过程或数据流可以由处理逻辑来执行，该处理逻辑可以包括硬件(例如，电路系统、专用逻辑、可编程逻辑、微代码等)、软件、固件或其组合。

在另一实施例中，一种用于向应用服务认证设备的系统包括：a)具有存储密码材料的硬件/软件信任根的设备；b)具有与设备上的密码材料相同或相对应的认证服务(RoT认证服务)；以及c)希望在允许访问其服务之前以不同模式认证设备的应用服务。认证服务将密码材料与附加属性集相关联。这些属性包括会话密钥、序列、能够在硬件信任根上执行的安全程序、所得出的密钥、编码为数据的远程功能调用、以及其他数据。在另一实施例中，设备连接到想要访问服务的应用服务，并且应用服务在预协商的策略下重定向设备以针对认证服务进行认证。在其他实施例中，认证服务使用安全协议来认证设备以确认其满足策略属性，设备和认证服务使用信任根更新属性以证明相同的属性，并且认证服务返回安全的可能是多个令牌以将身份以及访问信息绑定到设备。属性信息可以直接编码在令牌中，也可以充当不透明标识符，以允许应用服务稍后获取属性。应用服务可以检查(多个)令牌：i)仍然有效(例如，令牌可能是有时间限制的，或者需要与认证服务进行核对)；ii)在所请求的策略标识符下被发出；iii)仅对该应用服务有效。应用服务使用令牌来建立设备的身份并且具有对提供所请求的服务所需要的属性的访问。应用服务和认证服务可以由不同的实体来操作。

本文中描述的是用于解决将IoT端点初始可信登记到安全基础设施中的挑战的方法，该方法允许在IoT环境中的设备之间的安全通信。以下描述了提出的解决IoT设置中的设备证书的初始建立的方法的各种实施例。该设计的实施例基于在设备生命周期的早期阶段向设备供应安全证书，诸如SoC制造以及随后利用这些设备将设备安全地登记到安全基础设施(诸如PKI(关键基础设施))中。基础设施包括认证服务和委托的认证方案，除了别的之外，还允许建立在设备生命周期的各个阶段中属于不同方的新证书。此外，所提出的设计旨在统一安全证书建立，而与端点类型无关，从而解决了IoT设备中的巨大差异的挑战。

图4-15是示出与IoT设备和IDM系统的设备(也称为IoT基础设施)交互的序列的流程图，包括三个用例：认证、身份、和证明。在认证用例中，供应服务可以在认证服务的帮助下验证设备的真实性。在身份用例中，认证服务或者向供应服务提供唯一的设备别名，或者验证由设备本身提供的别名不会被某个其他设备重复。所有三个用例都可以使用图9中阐明的相同基本流程。

图4是示出根据一个实施例的在IoT设备110、RoT认证服务104、设备供应服务106、和IoT应用服务108之间的交互序列900的流程图。可以通过处理逻辑来执行导致设备之间的交互的操作，该处理逻辑可以包括硬件(例如，电路系统、专用逻辑、可编程逻辑、微代码等)、软件、固件、或其组合。序列900可以开始于从IoT设备110到设备供应服务106的前端供应策略服务器116的初始请求901。前端供应策略服务器116可以通过响应于初始请求901向IoT设备110发送回重定向响应来将IoT设备110重定向到认证策略服务器112。IoT设备110可以在重定向之后向RoT认证服务104的认证策略服务器112发送认证请求903。认证策略服务器112向RoT身份服务器114发送认证请求903，并且作为响应接收身份令牌和可选的访问令牌数据。认证策略服务器112将身份令牌905、和可选的访问令牌数据发送回IoT设备110。IoT设备110将身份令牌907(和可选的访问令牌数据)发送到前端供应策略服务器116。在框909处，前端供应策略服务器116在向供应服务器118发送供应请求之前检查身份令牌907。

应当注意，本文中描述的协议与OpenID连接(OIDC)协议具有一些相似之处，但是在很多方面有所不同。例如，在所使用的协议中，身份令牌被使用用于IoT设备，而不用于用户或用户代理。在其基础上，设备尝试访问设备供应服务106，该设备供应服务106使用单独的服务(RoT身份服务器114)来认证设备。它还被设计为消除(或至少在不可能时最小化)系统中任何位置的保持状态。特别地，该协议减少了两个方向上的随机数交换，从而简化了来自多个设备的消息的处理。仍然存在随机数，但是它们是经由客户端从服务器发送到服务器的。特别地，随机数从供应策略服务器116共享到IoT设备110。如果要针对每个交换执行重播保护，则将需要更多随机数。安全功能(即，重播保护，通常是通过使用随机数来提供的)改为依靠IoT设备与后端服务器之间的安全传送来提供。具体地，该传送要求是服务器认证的TLS协议。在标识(和认证)之后，IoT设备110可以通过诸如TLS/DTSL(MQTT、HTTP等)的连接与IoT应用服务108传送数据911，如本文中所述。

图5描述了在交换中的实体之间交换的消息，该交换结合了认证的用例和向设备发出特定于域的身份。

图5是示出根据一个实施例的在IoT设备110、RoT认证服务104、设备供应服务106、和IoT应用服务108之间的用于认证和身份服务的消息序列1000的流程图。序列1000可以开始于供应策略服务器116响应于来自IoT设备110(未示出)的初始请求而向IoT设备110发送重定向响应1001。重定向响应1001可以包括随机数、时间戳(或其他时间信息)、以及消息认证码(UMAC或hmac)的哈希，包括预共享密钥(PSK)和随机数/时间。PSK可以在供应策略服务器116与认证策略服务器112之间共享。随机数可以是由供应策略服务器116选择的随机值。

响应于重定向响应1001，IoT设备110生成认证请求1003以发送给认证策略服务器112。认证请求1003可以包括RoT标识符(rotID)(它是不可变的信任根ID)、校验和、随机数、时间戳、和HMAC。校验和(chksum)是根据得出的根密钥(rotKey)、rotID、随机数、和时间戳计算的校验和。rotKey是使用密钥树得出的。密钥树具有基本密钥和路径。路径定义了如何将基本密钥转换为rotKey。校验和可以使用来自IoT设备110的CM核心的hash1原语和hash2原语来计算。类似地，MAC可以是hash1原语和hash2原语的组合。更一般地，任何密钥MAC(HMAC)可以执行类似的操作。这样做的想法是，与其与后端共享实际唯一的核心(RoT)密钥，不如在后端与核心交互的任何时间得出解决方案特定的密钥。该推导是通过利用常量对唯一核心密钥进行哈希处理来完成的。

在一个实施例中，认证请求1003是如下的HTTP重定向：

认证策略服务器112接收认证请求1003，并且将认证请求1003作为认证请求1005一起发送给RoT身份服务器114。RoT身份服务器114利用认证响应1007进行响应，认证响应1007包括随机数、时间戳、和HMAC。认证策略服务器112接收认证响应1007。假设认证响应1007验证认证请求1005，认证策略服务器112向IoT设备110提供身份令牌(idToken)1009。idToken可以包括随机数、时间戳、和HMAC、以及声明。证明数据(attData)可以包含来自设备的描述其属性的数据，该数据由设备内的信任根证明。另一方面，声明是设备的属性，其由后端(RoT认证服务器)提供和证明。声明通常将包括attData，但可以具有其他信息，诸如该设备在最后一个小时内已经被后端认证了多少次。随机数、时间戳、HMAC、和声明可以被数字签名。IoT设备110将身份令牌1009提交给供应策略服务器116作为身份令牌1011。在一个实施例中，以下是示例身份令牌：

{

“iss”：https：//authn.rambus.com，

“sub”：“alias1234”，

“aud”：iotProvider1”，

“exp”：1311281970，

“iat”：1311280970，

“auth_time”：1311280969，

“amr”：“um：rambuscmv1”，

“nonce”：“AWFQ...Gwcg＝”，

“req_time”：1311280802，

“mac”：“AABc...CQEfcg＝”

}

在框1013处，供应策略服务器116验证身份令牌1011。为了验证身份令牌1011，供应策略服务器116可以通过相互认证的安全信道1015与供应服务器118通信。类似地，认证策略服务器112和RoT身份服务器114可以通过相互认证的安全信道1017通信。IoT设备110和认证策略服务器112通过单向认证的安全信道1019通信，并且IoT设备和供应策略服务器116通过单向认证的安全信道1021通信。供应策略服务器116可以通过相互认证的安全信道1023与认证策略服务器112通信。

应当注意，图5没有示出一些初步操作，诸如在后端上部署模块、在设备上进行排序，在后端组件之间建立信任等等，以便专注于认证流程并且捕获关于在CM核心上执行的序列和在后端中执行的模块的细节。此外，应当注意，尽管示出并描述了一个IoT设备110，但是存在由该单个基础设施服务的多个IoT设备。

关于图5，该简单配置依赖于传输层(TLS)的安全信道来防止重播和中间人攻击，并依赖于不可变id(rotID)的机密性。设备上的应用可以包含序列，而后端在该简单配置中使用一个单个模块。设备供应服务106可以使用附加序列作为对IoT设备110内的CM核心的质询并且产生响应。下面描述了不依赖于IoT设备与服务之间的TLS信道的安全属性的安全配置。

在一些实施例中，从该有限的安全性角度来看，在高级别，当应用尝试联系其需要认证请求(1003)的供应服务106(例如，1001)时，由该应用发起交互。供应策略服务器116利用到认证策略服务器112的重定向响应，该认证策略服务器可以是OpenID连接服务器(OIDC服务器)并且发送一些附加数据，如图5所示，诸如随机数、时间以及使用预共享密钥的随机数和时间的HMAC。随后，IoT设备110借助于RoT和RoT内部计算来产生请求。例如，IoT设备110可以使用作为由CM核心执行的以完成操作的命令集的静态序列，在CM核心的帮助下提供请求。在已经执行序列之后，除了从供应策略服务器116接收并且由应用转发到OIDC服务器(例如，112)的数据(随机数、时间、和HMAC)之外，CM核心还产生包含rotID(CM核心的标识符)和校验和的输出。认证策略服务器112将这些数据项进一步转发到RoT身份服务器114，在此执行HSM模块。在执行之前，验证时间和HMAC。然后，使用rotID查找得出的rotKey(在核心与基础设施之间共享的密钥，对应于具有给定rotID的设备)。模块使用得出的rotKey的该值来验证校验和。一旦完成，RoT身份服务器114就向认证策略服务器112返回认证响应1007，并且认证策略服务器112返回描述认证参数的令牌。该令牌是由OpenID连接协议指定的idToken，除了别的之外，其包括设备的身份(别名)。该令牌被格式化为具有令牌(jwt)的JSON，并且可以由认证策略服务器112(AuthN&AuthZ策略服务器)的非对称密钥来签名，以由供应策略服务器116来验证。

图6是示出根据一个实施例的针对图5的序列1000在每个相关组件上执行的各种操作的流程图。在框1101处，供应策略服务器116生成随机数，记录时间戳并且使用PSK创建HMAC，并且发送初始响应(重定向响应)。在框1103处，IoT设备110处的应用将随机数和时间戳发送到CM核心的缓冲器，并且执行序列以获得校验和结果。在框1103处，应用还创建认证请求并且经由认证策略服务器112将认证请求发送到RoT身份服务器114。在框1105处，RoT身份服务器114验证HMAC，使用rotID查找得出的rotKey，并且验证认证请求的校验和。RoT身份服务器114还创建、签名认证响应并且将认证响应发送回认证策略服务器112。在框1107处，认证策略服务器112验证认证请求。在验证之后，认证策略服务器112创建、签名身份令牌并且将身份令牌发送到IoT设备110处的应用。IoT设备110处的应用将身份令牌发送回供应策略服务器116，在框1109处，供应策略服务器116验证身份令牌上的签名并且针对其自己的策略检查时间。供应策略服务器116还执行供应操作。

应当注意，由于在以上流程中，任何实体都没有保持任何状态并且没有状态被完全封装在请求或响应对象中，因此不需要具有会话标识符(会话ID)的显式标识符。还应当注意，请求/响应对象本身可以由URL编码的字符串或JSON对象表示。

在另一实施例中，除了认证设备之外，RoT身份服务器114还可以向设备提供仅在特定IoT应用的上下文内有效的唯一身份。当需要跟踪设备时，这可能很有用，同时通过不允许设备跨多个服务使用相同的ID来保护设备/用户的隐私。此外，协议不得泄漏不可变的ID。这些ID通常在由RoT认证服务104返回的ID令牌的“子”字段中提供。相反，在另一实施例中，在隐私保护配置中，在“ID令牌中的“子”字段中使用表示该特定应用中的设备的别名。

尽管图5-6从逻辑或安全的角度示出并描述了组件之间的交互，但是可以使用HTTP或类似的机制来交换这些消息。下图将上面的交换映射到HTTP方法。这些仅从设备的角度描述发生的事情，不包括不涉及设备的交换。另外，供应策略服务器116与认证策略服务器112之间的交换的机制可以是各种类型的机制，包括在部署之前交换预共享密钥。

图7是示出根据一个实施例的在IoT设备110、RoT认证服务104、设备供应服务106、和IoT应用服务108之间交换的HTTP消息的序列1200的流程图。对于序列1200，IoT设备110最初向供应策略服务器116发送请求1201。请求1201可以包括设备数据。供应策略服务器116向IoT设备110发送回第一重定向1203(Redirect1)。第一重定向1203包括供应数据。供应数据可以是由供应策略服务器116生成的用于辅助供应事务的值，诸如随机数、时间戳、HMAC(随机数|时间)。在第一重定向1203之后，IoT设备110向认证策略服务器112发送认证请求1205(在Redirect1之后)。认证请求1205包括供应数据、以及证明数据、和授权数据。证明数据可以是由应用传输到IoT设备110的密码核心(例如，CM核心)的值，其需要由密码核心签名(MAC'ed)。证明数据可以由公钥或证书签名请求(CSR)来签名。认证数据可以是签名或校验和，从而允许认证服务104认证请求设备并且验证传入数据。认证策略服务器112向IoT设备110发送回第二重定向1207(Redirect2)。第二重定向1207包括令牌和证明数据。在第二重定向1207之后，IoT设备110向供应策略服务器116发送请求1209(在Redirect2之后)。请求1209包括令牌和证明数据。供应策略服务器116检查令牌和证明数据。供应策略服务器116向IoT设备110发送回包括被供应的数据(例如，设备的应用证书和其他应用相关数据)的HTTP响应1213。一旦由设备供应服务106和RoT认证服务104认证和授权，IoT设备可以与IoT应用服务108通信，诸如使用TLS/DTLS(MQTT、HTTP等)上的安全连接。

以下示例是以上关于图7描述的HTTP事务。

2.Redirect1 1203：

HTTP/1.0 302 Found

Location：https：//oidcserver.com/provisionMe/

{“AuthChain”：”AQFA...EAwCBcg＝”，

“nonce”：”BCXF..BCEwUxn＝”，

“reqTime”：1311280969，

“hmac”：”AFBC..AAEwQnb＝”}

3.Follow redirect1 1205：

POST/provisionMe？response_type＝code&scope＝authn HTTP/1.1

Host：oidcserver.com

Accept：application/json

{“AttestationData”：”AAAw...ECQFBcg＝”，

“AuthData”：”AAEC..AwQFBgc＝”，

“nonce”：”BCXF..BCEwUxn＝”，

“reqTime”：1311280969，

“hmac”：”AFBC..AAEwQnb＝”}

4.Redirect2 1207：

HTTP/1.0 302 Found

Location：https：//provisioner.iotProvider.com/provisionMe/token/<tokenID>

<Token>(examples below)

5.Follow redirect2 1209：

POST/provisionMe/token/<tokenID>HTTP/1.1

Host：provisioner.iotProvider.com

Accept：application/json

{“AttestationData”：”AAAw...ECQFBcg＝”}

6.HTTP Response 1213：

HTTP/1.0 200 OK

Content-Type：application/json

Content-Length：xxxx

{″Data：″AwQF...AAECBgc＝″}

如上所述，第二重定向1207包括一个或多个令牌。令牌可以是身份令牌，或者令牌可以是身份令牌和访问令牌。关于模块的输出以及如何将结果数据转换为身份令牌(idToken)和可选的访问令牌，有几种备选方案。首先，输出取决于用例。以下是两个用例中的两个示例输出。第一示例是仅要求对设备进行认证的情况。第二示例是包括证明数据的情况。密码核心可以提供证书签名请求作为证明数据。应当注意，输出取决于认证的成功或失败。在RoT身份服务器114已经完成成功认证的情况下，诸如以下面示例1所示的格式发出身份令牌。在认证失败的情况下，可以发送回错误消息。备选地，在另一种方法中，不向设备或RoT身份服务器114外部的任何设备提供回错误消息。发送回错误消息可能有助于系统负载，但是不发送回错误消息可能有助于安全性，在这种情况下，攻击者无法轻松了解失败的认证尝试。

示例1——仅认证用例：模块响应(由模块返回并且从RoT身份服务器114发送到认证策略服务器112)，其可以被包括在第二重定向1207中。

/>

以上令牌是编码令牌的格式的示例，但是不包含实际数据。

示例2——认证和证明数据用例：模块响应(由模块返回并且从RoT身份服务器114发送到认证策略服务器112)，其可以被包括在第二重定向1207中。

/>

以上令牌是编码令牌的格式的示例，但是不包含实际数据。

尽管认证和身份服务是有用的，但是在其他实施例中，基础设施还可以提供数据证明功能。使用该功能，应用可以让其公钥(或证书签名请求)由密码核心签名并且在后端被验证，而这又可以由供应策略服务器116验证。该验证可以被使用作为用于向设备上运行的应用发出证书的策略。应当注意，尽管密码核心可能对给定的数据进行盲签名，但该数据的签名可能仍然可用于为证书的发出提供一层验证，如图8的流程和序列细节所示。

图8是示出根据一个实施例的在IoT设备110、RoT认证服务104、设备供应服务106、和IoT应用服务108之间的用于认证、身份、和数据证明服务的交互的序列1300的流程图。序列1300可以开始于供应策略服务器116响应于来自IoT设备110(未示出)的初始请求而向IoT设备110发送重定向响应1301。重定向响应1301可以包括随机数、时间戳(或其他时间信息)、和HMAC(PSK、随机数|时间)。如上所述，PSK可以是供应策略服务器116与认证策略服务器112之间的预共享密钥。随机数可以是由供应策略服务器116选择的随机值。

响应于重定向响应1301，IoT设备110生成认证请求1303以发送到认证策略服务器112。认证请求1303可以包括rotID、校验和、随机数、时间戳、HMAC、和证明数据(标记为attData)。校验和(chksum)可以通过得出的PADA、rotID和设备数据(Pub)来计算。PADAK是可以从中得出其他密钥的基(或根)密钥。PADAK可以在硅制造过程中编程，但是要在最终客户(例如，OEM)知道之前。由于这些设备可以分配给很多不同的OEM，因此将基于该设备和OEM独有的PADAK得出新密钥。校验和可以用于认证设备并且验证设备数据(Pub)。Pub是对公钥的引用，公钥通常是证明数据或设备数据的一部分，证明数据或设备数据是证书签名请求的基础。证明数据是由应用提供给密码核心(例如，CM核心)的附加数据。在该数据被发送到认证策略服务器112之前，密码核心对该数据进行加密和签名。该证明数据被验证，并且然后打包为访问令牌的一部分。这种数据的一个示例是应用的公钥，其可以用作由供应服务器118发出证书的基础。在一种实现中，由IoT设备110证明的数据是其公钥，该公钥用于与IoT应用的安全事务。由IoT设备110证明的公钥用于创建证书。该证书在与IoT应用进行相互认证的传输层协议安全(TLS)会话期间被使用。数据1317(例如，cert)包含该公钥。在RoT校验和计算中使用TLS公钥提供了以下证明：该IoT设备110并且仅该设备具有该公钥及其相关的私钥。

认证策略服务器112接收具有证明数据的认证请求1303，并且将认证请求1303作为认证请求1305一起发送给RoT身份服务器114。认证请求1305还包括证明数据。RoT身份服务器114利用认证响应1307进行响应，该认证响应1307包括随机数、时间戳、HMAC、和证明数据。认证策略服务器112接收认证响应1307。假设认证响应1307验证认证请求1305，认证策略服务器112向IoT设备110提供身份令牌(idToken)和访问令牌(accessToken)1309。如上所述，访问令牌可以是已签名的证明数据。idToken可以包括随机数、时间戳、和HMAC。随机数、时间戳、和HMAC可以被数字签名。IoT设备110将身份令牌和访问令牌1309提交给供应策略服务器116作为身份令牌和访问令牌1311。

在框1313处，供应策略服务器116验证身份令牌1011。为了验证身份令牌，供应策略服务器116可以通过相互认证的安全信道1015与供应服务器118通信。在框1315处，供应服务器118确定是否要发出证书。当供应服务器118发出证书时，供应策略服务器116向IoT设备110发送回包括证书的数据1317。类似地，认证策略服务器112和RoT身份服务器114可以通过相互认证的安全信道通信。IoT设备110和认证策略服务器112通过单向认证的安全信道通信，并且IoT设备和供应策略服务器116通过单向认证的安全信道通信。

在一些实施例中，从该有限的安全性角度来看，在高级别，当应用尝试联系其需要认证请求(1303)的供应服务106(例如，1301)时，由该应用发起交互。供应策略服务器116利用到认证策略服务器112的重定向进行响应，该重定向包括图8所示的附加数据，诸如随机数、时间、和HMAC。随后，IoT设备110使用静态序列在CM核心的帮助下产生请求。在已经执行序列之后，除了从供应策略服务器116接收并且由应用转发到OIDC服务器(例如，112)的数据(随机数、时间、和HMAC)之外，CM核心还产生包含rotID(CM核心的标识符)和校验和的输出。输出还包括证明数据。认证策略服务器112将这些数据项进一步转发到RoT身份服务器114，在此执行HSM模块。在执行之前，验证时间和HMAC。然后，使用rotID查找得出的rotKey(在核心和基础设施之间共享的密钥，对应于具有给定rotID的设备)。模块使用得出的rotKey的该值来验证校验和。一旦完成，RoT身份服务器114就向认证策略服务器112返回认证响应1307，并且认证策略服务器112返回描述认证参数的两个令牌。一个令牌可以是由OpenID连接协议指定的身份令牌，除了别的之外，其包括设备的身份(其别名)。该令牌被格式化为具有令牌(jwt)的JSON，并且可以由认证策略服务器112(AuthN&AuthZ策略服务器)的非对称密钥签名以由供应策略服务器116来验证。另一令牌可以是访问令牌，其包括可以由设备供应服务106验证的已签名的证明数据。该数据的示例可以是应用的公钥，它可以在框1315处用作由供应服务器118发出证书的基础。

上述各种实施例假设设备上的信任根是使用对称密钥的CM核心。但是，IDM需要支持基础设施中的各种IoT设备(也称为IoT端点)。下面描述了两个备选方案，它们依赖于密码核心使用非对称密钥不仅用于输入验证(如在CM核心实施例中所述)，而且还用作密码核心的证书，包括基于pubDB的供应和基于PKI的供应。在基于PKI的供应中，个性化的结果是核心证书。该备选方案与对称核心实施例类似，因为核心变为供应公钥基础设施(PKI)的一部分。在另一备选的基于pubDB的供应中，设备具有非对称密钥对，但它们没有证书。取而代之，后端具有设备的公钥数据库，该数据库由设备的ID(rotID)索引。可以将其视为基于对称密钥的供应(其中存在密钥查找数据库)和基于PKI的供应(其中存在非对称密钥作为核心的证书)之间的混合。

图9是根据一个实施例的基于pubDB的供应过程的流程图。为了便于描述，过程1400使用由相似的附图标记表示的与图8相同的交互序列1300。本实施例使用证明数据，因为它是有用的供应情况。响应于重定向响应1301，IoT设备110生成并且发送认证请求1403以发送给认证策略服务器112。认证请求1403包括rotID、签名、随机数、时间戳、HMAC、和证明数据(标记为attData)。签名可以是ECDSA签名，并且可以在rotID、时间、和设备数据(Pub)上使用设备的私钥来计算。签名用于认证设备并且验证设备数据(Pub)，如上面更详细描述的。如序列1300中一样，证明数据是由应用提供给非对称密码核心的附加数据。在该数据被发送到认证策略服务器112之前，密码核心对该数据进行加密和签名。该证明数据被验证，并且然后打包为访问令牌的一部分。这种数据的一个示例是应用的公钥，其可以用作由供应服务器118发出证书的基础。

认证策略服务器112接收具有证明数据和设备证书的认证请求1403，并且将具有证明数据的认证请求1403作为认证请求1305一起发送给RoT身份服务器114。RoT身份服务器114利用认证响应1307进行响应，认证响应1307包括随机数、时间戳、HMAC、和证明数据。认证策略服务器112接收认证响应1307。假设认证响应1307验证认证请求1305，认证策略服务器112向IoT设备110提供身份令牌(idToken)和访问令牌(accessToken)1309。如上所述，访问令牌可以是已签名的证明数据。idToken可以包括随机数、时间戳、和HMAC。随机数、时间戳、和HMAC可以被数字签名。IoT设备110将身份令牌和访问令牌1309提交给供应策略服务器116作为身份令牌和访问令牌1311。

应当注意，图9的实施例与图8的实施例之间的主要区别在于由非对称核心计算的签名类型。这里假定为ECDSA，而在对称核心情况下，签名是由对称核心(例如，CM核心)计算的专有校验和。

图10是示出根据一个实施例的针对图9的序列在每个相关组件上执行的各种操作的流程图。在框1501处，供应策略服务器116生成随机数，记录时间戳并且使用PSK创建HMAC，并且发送初始响应(重定向响应)。在框1503处，IoT设备110处的应用将随机数和时间戳发送到非对称核心的缓冲器，并且非对称核心执行序列以获得签名结果。例如，签名结果是使用随机数、时间戳、和HMAC计算的ECDSA签名。在框1503处，应用还创建认证请求并且经由认证策略服务器112将认证请求发送到RoT身份服务器114。在框1505处，RoT身份服务器114验证HMAC，在设备的公钥数据库中查找核心的公钥，该数据库由设备的ID(rotID)索引。RoT身份服务器114还验证认证请求的签名。RoT身份服务器114还创建、签名认证响应并且将认证响应发送回认证策略服务器112。在框1507处，认证策略服务器112验证认证请求。在验证之后，认证策略服务器112创建、签名身份令牌(和可选的访问令牌)，并且将身份令牌(和可选的访问令牌)发送到IoT设备110处的应用。IoT设备110处的应用将身份令牌发送回供应策略服务器116，在框1509处，供应策略服务器116验证身份令牌上的签名并且针对其自己的策略检查时间。供应策略服务器116还执行供应操作。

在另一实施例中，除了认证设备之外，RoT身份服务器114还可以向设备提供仅在特定IoT应用的上下文内有效的唯一身份。当需要跟踪设备时，这可能很有用，同时通过不允许设备跨多个服务使用相同的ID来保护设备/用户的隐私。此外，协议不得泄漏不可变的ID。这些ID通常在由RoT认证服务104返回的ID令牌的“子”字段中提供。相反，在另一实施例中，在隐私保护配置中，在ID令牌中的“子”字段中使用表示该特定应用中的设备的别名。在基于pubDB的供应中，别名与应用及其证书相关联，而后端使用不可变ID来查找公钥。

下面描述了基于PKI的供应的两个子情况。一个子情况使用与以上关于图9-10示出和描述的基于pubDB的流程和处理类似的流程和处理。也就是说，非对称核心正在使用ECDSA对随机数、时间、HMAC、和证明数据进行签名，并且IoT设备110将结果发送到认证策略服务器112。如图11-12所示，该子情况称为基于签名PKI的供应过程。另一种子情况是使用终止于核心的TLS连接，而不依赖于由主机设备提供的TLS。从安全角度来看，这可能是更好的选择，但可能是更复杂的设计，因为现在设备的操作系统(例如，高级操作系统(HLOS))需要充当代理，而不是TLS端点，就像在所有其他情况下一样。如图13-14所示，该子情况称为基于TLS PKI的供应。

图11是根据一个实施例的基于签名PKI的供应过程1600的流程图。为了便于描述，过程1600使用与由相似的附图标记表示的与图9相同的交互序列1400，包括证明数据。响应于重定向响应1301，IoT设备110生成并且发送认证请求1603以发送给认证策略服务器112。认证请求1603包括随机数、时间戳、HMAC、证明数据(标记为attData)、和设备证书(deviceCert)的签名。签名可以是ECDSA签名，并且可以使用随机数、时间、HMAC、和证明数据来计算。签名用于认证设备并且验证设备数据(Pub)。如同序列1400中一样，证明数据是由应用提供给非对称密码核心的附加数据。密码核心在该数据发送到认证策略服务器112之前对该数据进行加密和签名。该证明数据被验证，并且然后打包为访问令牌的一部分。这种数据的一个示例是应用的公钥，其可以用作由供应服务器118发出证书的基础。

认证策略服务器112接收具有证明数据和设备证书的认证请求1603，并且将具有证明数据和设备证书的认证请求1603作为认证请求1605一起发送给RoT身份服务器114。RoT身份服务器114利用认证响应1307进行响应，认证响应1307包括随机数、时间戳、HMAC、和证明数据。RoT身份服务器114可以验证设备证书是否由可信机构签名，并且然后可以从可信设备证书中提取公钥。然后，可以使用设备证书中的公钥来验证认证响应(数字签名)。通常，RoT身份服务器114可以使用证书(以及对称密钥或公钥数据库)来认证设备。例如，可能有“制造证书”和“应用证书”。后者可以基于由前者提供的认证来发出。认证策略服务器112接收认证响应1307。假设认证响应1307验证了认证请求1305，认证策略服务器112向IoT设备110提供身份令牌(idToken)和访问令牌(accessToken)1309。如上所述，访问令牌可以是已签名的证明数据。idToken可以包括随机数、时间戳、和HMAC。随机数、时间戳、和HMAC可以被数字签名。IoT设备110将身份令牌和访问令牌1309提交给供应策略服务器116作为身份令牌和访问令牌1311。

应当注意，图11的实施例与和图9的实施例之间的主要区别在于在认证请求1603中发送的由非对称核心计算的签名和设备证书。

图12是示出根据一个实施例的针对图11的序列在每个相关组件上执行的各种操作的流程图。在框1701处，供应策略服务器116生成随机数，记录时间戳并且使用PSK创建HMAC，并且发送初始响应(重定向响应)。在框1703处，IoT设备110处的应用将随机数和时间戳发送到非对称核心的缓冲器，并且非对称核心执行序列以获得签名结果。例如，签名结果是使用随机数、时间戳、和HMAC计算的ECDSA签名。在框1703处，应用还创建认证请求并且将认证请求经由认证策略服务器112发送到RoT身份服务器114。如上所述，认证请求包括设备证书。在框1705处，RoT身份服务器114验证HMAC，验证设备证书，并且验证认证请求的签名。RoT身份服务器114还创建、签名认证响应并且将认证响应发送回认证策略服务器112。在框1707处，认证策略服务器112验证认证请求。在验证之后，认证策略服务器112创建、签名身份令牌(和可选的访问令牌)，并且将身份令牌(和可选的访问令牌)发送到IoT设备110处的应用。IoT设备110处的应用将身份令牌发送回供应策略服务器116，在框1709处，供应策略服务器116验证身份令牌上的签名并且针对其自己的策略检查时间。供应策略服务器116还执行供应操作。

如上所述，在基于TLS PKI的供应中，核心充当TLS客户端，并且将其设备私钥和证书用于TLS会话内的客户端认证。一旦建立了该会话，任何应用层协议都可以在其之上运行，包括供应另一证书，诸如在图13中使用的安全周界和密钥中所述。

图13是根据一个实施例的用于对称核心的基于TLS PKI的供应过程1800的流程图。在过程1800中，一些设备具有硬件安全边界，包括：IoT设备110的硬件安全边界1810，其中存储有根密钥(rotKey)1812；供应服务器118的硬件安全边界1820，其中存储有证书颁发机构私钥(CApriv)1822；以及RoT身份服务器114的硬件安全边界1830，其中存储有数据库包装密钥(dbWrapKey)1832和得出根密钥(drotkey)1834。dbWrapKey是用于加密设备密钥数据库的密钥。例如，如果后端使用对称密钥和关联设备ID的数据库，则需要在静态时对其进行加密。为此，使用dbWrapKey。在一些实施例中，RoT身份服务器114包括其中存储有密钥数据库1842的硬件安全边界1840。

为了便于描述，过程1800使用与图5相同的交互序列1000，由相似的附图标记表示。然而，过程1800的序列使用TLS，如下所述。例如，供应策略服务器116和认证策略服务器112可以使用TLS密钥对1850在相互认证的安全信道1023上通信。供应策略服务器116和认证策略服务器112可以交换预共享密钥(PSK)1852。类似地，认证策略服务器112和RoT身份服务器114可以使用TLS密钥对1850通过相互认证的安全信道1017通信。IoT设备110可以使用设备TLS密钥对1854通过单向认证的安全通道1019与认证策略服务器112通信，通过单向认证的安全通道1021与供应策略服务器116通信，或者这两者。

图14是根据一个实施例的用于非对称核心的基于TLS PKI的供应过程1900的流程图。在过程1900中，一些设备具有硬件安全边界，包括：IoT设备110的硬件安全边界1910，其中存储有设备私钥1912和IoT应用私钥1914；以及供应服务器118的硬件安全边界1920，其中存储有证书颁发机构私钥(CApriv)1922。应当注意，RoT身份服务器114可以存储不需要存储在硬件安全边界内的公钥数据库1942。

为了便于描述，过程1900使用与图11相同的交互序列1600，由相似的附图标记表示。然而，过程1900的序列使用TLS，如下所述。例如，供应策略服务器116和认证策略服务器112可以使用TLS密钥对1950在相互认证的安全信道1023上通信。供应策略服务器116和认证策略服务器112可以交换预共享密钥(PSK)1952。类似地，认证策略服务器112和RoT身份服务器114可以使用TLS密钥对1950通过相互认证的安全信道1017通信。IoT设备110可以使用设备TLS密钥对1954通过单向认证的安全信道1019与认证策略服务器112通信，通过单向认证的安全信道1021与供应策略服务器116通信，或者这两者。

除了上述认证、身份和证明服务，如果需要，系统还可以执行附加的安全检查。在图15中示出了附加的安全检查的一个示例。

图15是根据一个实施例的实时安全检查过程2000的流程图。为了便于描述，实时安全检查过程2000使用与图5相同的交互序列1000，由相似的附图标记表示。一旦IoT设备110将身份令牌1009作为身份令牌1011提交给供应策略服务器116，则供应策略服务器116可以在框1013处验证身份令牌1009，并且可以向IoT设备110发出附加质询2013。该质询2013可以是另一静态序列，这将基于IoT设备110的当前状态产生响应。IoT设备110计算响应2015，并且将其发送回供应策略服务器116以进行验证。并行地，供应策略服务器116可以经由认证策略服务器112向RoT身份服务器114发送请求2017(getExpectedResponse)，并且经由认证策略服务器112从RoT身份服务器114接收期望响应2019。供应策略服务器116可以将预期响应2019与从IoT设备110接收的响应2015比较，以查看它们是否匹配。如果它们匹配，则供应策略服务器116可以将数据2021发送到IoT设备110。如果响应2015与预期响应2019不匹配，则供应策略服务器116可以将错误响应发送到IoT设备110。备选地，供应策略服务器116不发送错误响应。

应当注意，该实时安全检查将要求RoT身份服务器114保持IoT设备110的状态。例如，RoT身份服务器114在执行模块之后将不得不缓存期望响应。

在另一实施例中，除了证明输入到密码核心的数据(这可能有助于保护证书登记)之外，还可以修改方案以产生可以在密码核心与后端服务之间共享的对称密钥。

图16是根据一个实施例的用于安全地供应IoT设备的方法2100的流程图。方法2100可以由处理逻辑来执行，该处理逻辑可以包括硬件(例如，电路系统、专用逻辑、可编程逻辑、微代码等)、软件、固件或其组合。方法2100可以由设备供应服务的一个或多个服务器执行。再次参考图16，方法2100开始于框2102处的处理逻辑，该处理逻辑从物联网(IoT)设备接收消息以安全地供应IoT设备。该消息包括简档标识符。处理逻辑使用简档标识符来获取供应策略信息(框2104)，并且确定信任根(RoT)认证服务以认证和授权IoT设备(框2016)。处理逻辑向IoT设备发送重定向响应以将IoT设备重定向到RoT认证服务以认证和授权IoT设备(框2108)。重定向响应可以包括用于认证IoT设备的加密策略标识符。处理逻辑随后接收供应请求，该供应请求包括由RoT认证服务发出的令牌(框2110)。处理逻辑验证供应请求和令牌(框2112)。当在框2112处供应请求和令牌被验证之后，处理逻辑将供应信息发送到IoT设备(框2114)，并且方法2100结束。如果在框2112处供应请求、令牌或两者均未被验证，则处理逻辑发送(或不发送)错误消息(框2116)，并且方法2100结束。

在另一实施例中，当在框2112处供应请求和令牌被验证之后，处理逻辑向IoT应用服务注册IoT设备。在某些情况下，它可以注册令牌、设备、或两者。IoT应用服务可以执行本地注册，并且向设备供应服务发送回确认(ACK)。

在另一实施例中，处理逻辑与RoT认证服务交换安全证书。处理逻辑从RoT认证服务获得(或以其他方式接收)认证方法的列表。认证方法是用于认证IoT设备的过程，诸如由IoT平台提供方指定的过程。处理逻辑从列表中选择认证方法，并且为该认证方法分配策略标识符。处理逻辑将策略标识符和认证方法发送到RoT认证服务。处理逻辑还可以与RoT认证服务建立会话密钥。在一个实施例中，策略标识符定义对由RoT认证服务发出的令牌的一个或多个要求。在另一实施例中，安全证书包括MAC。

在另一实施例中，处理逻辑通过接收在MUD文件中描述的URL来接收消息，其中MUD文件包括简档标识符。在另一实施例中，处理逻辑从供应策略信息中确定要由RoT认证服务用于认证IoT设备的认证方法，该认证方法具有标识策略标识符。处理逻辑在重定向响应中的URL中编码标识策略标识符。

在另一实施例中，处理逻辑确定供应请求中的令牌具有未知格式，向RoT认证服务发送请求以验证令牌，并且从RoT认证服务接收验证响应。在另一实施例中，处理逻辑确定供应请求中的令牌包含RoT属性，并且从令牌中提取RoT属性。处理逻辑发送请求以从RoT认证服务获得附加RoT安全属性，该附加RoT安全属性包括标识策略标识符。处理逻辑验证附加RoT安全属性。

在另一实施例中，处理逻辑从IoT应用服务接收检查检查访问请求，以检查是否应当将对IoT应用的访问授权给IoT设备。检查访问请求包括IoT设备的所供应的信息。处理逻辑使用所供应的信息验证对IoT设备的访问，并且向IoT应用服务发送响应。

上面描述的各种实施例可以关于本文中描述的设备供应服务的一个或多个服务器执行的操作。在其他实施例中，可以由本文中描述的设备的指定服务器执行其他方法，诸如设备供应服务106的供应策略服务器116和供应服务器118。在其他实施例中，可以由RoT认证服务执行其他方法，包括以上关于认证策略服务器112和RoT身份服务器114所描述的操作。类似地，可以由IoT设备110和IoT应用服务108(包括如本文中描述的IoT应用网关120和IoT应用服务器122)执行其他方法。

图17是根据一个实施例的其中可以执行本文中描述的任何方法的计算机系统2200的一个实施例的图。计算机系统2200可以包括处理器2202、主存储器2204、存储存储器2206、芯片组2208、一个或多个外围设备2210、网络接口设备2222、以及可配置为与可移动存储设备2215连接的可移动存储设备接口2203。处理器2202可操作用于根据本文中描述的任何方法来执行指令2226(或软件)。指令2226可以包括存储在主存储器2204或可移动存储设备2205中并且由处理器2202执行并且可以用于执行与本文中描述的关于认证、身份、证明、和实时安全检查服务有关的各种操作的指令。在一个实施例中，计算机系统2200表示图1的IDM 100的任何一个或多个设备，诸如IoT设备110、认证策略服务器112、RoT身份服务器114、供应策略服务器116、供应服务器118、IoT应用网关120、IoT应用服务器122、或IoT安全分析服务130的任何设备。

在某些情况下，计算机系统2200可以连接(例如，联网)到LAN、内部网、外网、或互联网中的其他机器。计算机系统2200可以是云中的主机、云提供方系统、云控制器、服务器、客户端、或任何其他机器。计算机系统2200可以在客户端服务器网络环境中以服务器或客户端计算机的能力操作，或者在对等(或分布式)网络环境中作为对等机器操作。机器可以是个人计算机(PC)、平板电脑、控制台设备或机顶盒(STB)、个人数字助理(PDA)、蜂窝电话、web设备、服务器、网络路由器、交换机或网桥、或者能够执行一组指令(顺序或其他方式)的机器，这些指令指定要由该机器执行的操作。此外，虽然仅示出了单个机器，但是术语“机器”也应当被认为包括单独地或共同地执行一组(或多组)指令以执行本文中讨论的任何一个或多个方法的机器(例如，计算机)的任何集合。

计算机系统2200包括处理器2202(例如，主机处理器或处理设备)、主存储器2204(例如，只读存储器(ROM)、闪存、动态随机存取存储器(DRAM)、存储存储器2206(例如，闪存、静态随机存取存储器(SRAM)等)，以及辅助存储器2218(例如，驱动单元形式的数据存储设备，其可以包括固定或可移动计算机可读存储介质)，它们通过总线2230彼此通信。

处理器2202表示一个或多个通用处理设备，诸如微处理器、中央处理单元等。更具体地，处理器2202可以是复杂指令集计算(CISC)微处理器、精简指令集计算(RISC)微处理器、超长指令字(VLIW)微处理器、实现其他指令集的处理器、或者实现指令集组合的处理器。处理器2202还可以是一个或多个专用处理设备，诸如专用集成电路(ASIC)、现场可编程门阵列(FPGA)、数字信号处理器(DSP)、网络处理器等。

在一个实施例中，处理器2202可以驻留在第一集成电路上，而主存储器2204可以驻留在第二集成电路上。例如，集成电路可以包括主机计算机(例如，具有一个以上处理核心、L1高速缓存、L2高速缓存等的CPU)、主机控制器、或其他类型的处理器2202。第二集成电路可以包括存储设备，该存储设备耦合到主机设备，并且其主要功能取决于主机设备，并且因此第二集成电路可以被认为是扩展了主机设备的功能，而不构成主机设备的核心架构的一部分。该存储设备可以能够与主机设备通信。例如，存储设备可以是单个IC或包括在公共集成电路基板上的单个IC设备的任何组合的多IC模块。图17的组件可以驻留在“公共载体基板”上，例如，集成电路(“IC”)管芯基板、多IC模块基板等。备选地，存储设备可以驻留在一个或多个印刷电路板上，例如，主板、子板、或其他类型的电路卡。在其他实现中，主存储器和处理器2202可以驻留在相同或不同的载体基板上。

计算机系统2200可以包括芯片组2208，芯片组2208是指一组集成电路、或芯片，这些集成电路、或芯片被设计为与处理器2202一起工作并且控制处理器2202与外部设备之间的通信。例如，芯片组2208可以是主板上的一组IC，该主板将处理器2202链接到超高速设备(诸如主存储器2204和图形控制器)，并且将处理设备链接到外围设备2210的低速外围总线，诸如USB、PCI或ISA总线。在一个实施例中，可移动存储设备接口2203可以在芯片组2208中实现。

计算机系统2200还可以包括网络接口设备2222。计算机系统2200还可以包括一个或多个外围设备2210，诸如通过图形端口和图形芯片组连接到计算机系统的视频显示单元(例如，液晶显示器(LCD))、字母数字输入设备(例如，键盘)、光标控制设备(例如，鼠标)、信号生成设备(例如，扬声器)等。集成电路设备“编程”可以包括，例如但不限于，响应于主机指令将控制值加载到设备内的寄存器或其他存储电路中，从而控制设备的操作方面，建立设备配置或通过一次性编程操作(例如，在设备生产过程中烧断配置电路中的保险丝)控制设备的操作方面，和/或将设备的一个或多个选定的引脚或其他接触结构连接到参考电压线(也称为捆绑)以建立设备的特定设备配置或操作方面。术语“示例性”用于表示示例，而不是偏好或要求。

在以上描述中，阐述了很多细节。然而，对于受益于本公开的本领域的普通技术人员显而易见的是，可以在没有这些具体细节的情况下实践本发明的实施例。在某些情况下，以框图的形式而不是详细地示出了公知的结构和设备，以避免使描述不清楚。

根据对计算机存储器内的数据位的操作的算法和符号表示来呈现详细描述的某些部分。这些算法描述和表示是数据处理领域的技术人员用来最有效地向本领域的其他技术人员传达其工作实质的手段。算法在这里通常被认为是引起期望结果的步骤的自一致序列。这些步骤是需要对物理量进行物理操纵的步骤。通常，尽管不是必须的，这些量采取能够被存储、传输、组合、比较和以其他方式操纵的电或磁信号的形式。主要出于通用的原因，已经证明有时将这些信号称为位、值、元素、符号、字符、项、数字等是方便的。

然而，应当牢记，所有这些和类似术语均应当与适当的物理量相关联，并且仅仅是应用于这些量的方便标签。除非从上述讨论中另外明确指出，否则应当理解，在整个描述中，利用诸如“加密”、“解密”、“存储”、“提供”、“得出”、“获得”、“接收”、“认证”、“删除”、“执行”、“请求”、“通信”等的术语的讨论是指计算系统或类似电子计算设备的动作和过程，这些动作和过程将被表示为计算系统的寄存器和存储器中的物理(例如，电子)量的数据操纵和转换为类似地表示为计算系统存储器或寄存器或其他此类信息存储、传输或显示设备中的物理量的其他数据。

词语“示例”或“示例性”在本文中被用来表示用作示例、例子或说明。本文中被描述为“示例”或“示例性”的任何方面或设计均不一定被解释为比其他方面或设计更优选或有利。相反，使用词语“示例”或“示例性”来表示概念。如本公开中所使用的，术语“或”旨在表示包括性的“或”而不是排他性的“或”。也就是说，除非另有说明或从上下文可以清楚地看出，否则“X包括A或B”旨在表示自然的包括性排列中的任何一个。也就是说，如果X包括A；X包括B；或X包括A和B两者，则在任何上述情况下都满足“X包括A或B”。另外，在本公开和所附权利要求书中使用的冠词“一个(a)”和“一个(an)”通常应当被解释为表示“一个或多个”，除非另有说明或从上下文中清楚地指向单数形式。此外，术语“一个实施例(anembodiment)”或“一个实施例(one embodiment)”或“一种实现(an implementation)”或“一种实现(one implementation)”的使用在全文中并不旨在表示相同的实施例或实现，除非如此描述。

本文中描述的实施例还可以涉及用于执行本文中的操作的装置。该装置可以被特殊构造用于所需目的，或者可以包括由存储在计算机中的计算机程序选择性地激活或重新配置的通用计算机。这样的计算机程序可以存储在非瞬态计算机可读存储介质中，例如但不限于任何类型的盘，包括软盘、光盘、CD-ROM和磁光盘、只读存储器(ROM)、随机存取存储器(RAM)、EPROM、EEPROM、磁卡或光卡、闪存、或者适用于存储电子指令的任何类型的介质。术语“计算机可读存储介质”应当被理解为包括存储一个或多个指令集的单个介质或多个介质(例如，集中式或分布式数据库和/或相关联的高速缓存和服务器)。术语“计算机可读介质”也应当被认为包括能够存储、编码、或携带一组指令以由机器执行并且使机器执行本实施例的任何一种或多种方法的任何介质。因此，术语“计算机可读存储介质”应当被认为包括但不限于固态存储器、光学介质、磁介质、能够存储用于由机器执行并且使机器执行本实施例的任何一种或多种方法的一组指令的任何介质。

本文中提出的算法和显示与任何特定的计算机或其他设备不固有地相关。各种通用系统可以与根据本文中的教导的程序一起使用，或者可以证明构造更专用的装置以执行所需要的方法步骤是方便的。各种这些系统所需要的结构将从下面的描述中出现。另外，没有参考任何特定的编程语言来描述本实施例。应当理解，可以使用各种编程语言来实现如本文中描述的实施例的教导。

以上描述阐述了很多特定细节，诸如特定系统、组件、方法等的示例，以便提供对本发明的若干实施例的良好理解。然而，对本领域技术人员显而易见的是，可以在没有这些具体细节的情况下实践本发明的至少一些实施例。在其他情况下，未详细描述公知的组件或方法，或者以简单的框图格式呈现公知的组件或方法，以避免不必要地混淆本发明。因此，以上阐述的具体细节仅是示例性的。特定实现可以与这些示例性细节不同，并且仍然被认为在本发明的范围内。

应当理解，以上描述旨在说明而不是限制。通过阅读和理解以上描述，很多其他实施例对于本领域技术人员将是显而易见的。因此，本发明的范围应当参考所附权利要求以及这些权利要求所赋予的等同物的全部范围来确定。

虽然已经参考本发明的特定实施例描述了本发明，但是显而易见的是，在不脱离本发明的更广泛精神和范围的情况下，可以对其进行各种修改和改变。例如，至少在可行的情况下，任何实施例的特征或方面可以与任何其他实施例组合或代替其对应的特征或方面来应用。因此，说明书和附图应当被认为是说明性的而不是限制性的。

Claims

1.一种用于建立分布式信任网络的系统，具有：

信任根RoT服务，所述RoT服务具有设备的RoT的直接知识，所述RoT服务向应用服务提供所述设备的认证服务和安全供应服务，以使得所述应用服务能够在不具有所述设备的RoT的直接知识的情况下与所述设备建立可信连接，其中所述RoT服务包括认证策略服务器和RoT身份服务器以提供所述认证服务，其中所述认证策略服务器的前端协议是特定于所述设备的并且保持所述设备的状态，并且其中所述认证策略服务器与所述RoT身份服务器之间的后端协议独立于所述前端协议并且是无状态的。

2.根据权利要求1所述的系统，其中所述直接知识基于在所述设备的设备制造期间被提供的至少一个密钥。

3.根据权利要求1所述的系统，其中所述前端协议包括芯片制造方对所述设备的业务需求、通信协议、和认证协议。

4.根据权利要求1所述的系统，还包括所述设备，其中所述设备的所述RoT是硬件RoT。

5.根据权利要求1所述的系统，还包括所述设备，其中所述设备的所述RoT是软件RoT。

6.根据权利要求1所述的系统，其中所述认证策略服务器和所述RoT身份服务器使用传输层安全TLS和超文本传输协议安全HTTPS通信。

7.根据权利要求1所述的系统，还包括所述应用服务，所述应用服务用于向所述设备提供应用。

8.根据权利要求7所述的系统，其中所述应用服务包括前端应用网关和后端应用服务器。

9.根据权利要求8所述的系统，其中所述前端应用网关和所述后端应用服务器使用超文本传输协议安全HTTPS通信。

10.根据权利要求1所述的系统，其中所述RoT服务还包括前端供应策略服务器和后端供应服务器以提供所述安全供应服务。

11.一种方法，包括：

在设备供应服务处，从物联网IoT设备接收消息以安全地供应所述IoT设备，所述消息包括简档标识符和供应请求；

使用所述简档标识符获取供应策略信息；

确定信任根RoT认证服务以认证和授权所述IoT设备；

由所述设备供应服务向所述IoT设备发送重定向响应以将所述IoT设备重定向到所述RoT认证服务以认证和授权所述IoT设备，其中所述重定向响应包括被用于认证所述IoT设备的加密策略标识符；

在所述设备供应服务处接收供应请求，所述供应请求包括由所述RoT认证服务发出的令牌；

验证所述供应请求和所述令牌；以及

当所述供应请求和所述令牌被验证之后，由所述设备供应服务向所述IoT设备发送供应信息，

其中所述设备供应服务和所述RoT认证服务由RoT服务向IoT应用服务提供，以使得所述IoT应用服务能够在不具有所述IoT设备的RoT的直接知识的情况下与所述IoT设备建立可信连接。

12.根据权利要求11所述的方法，还包括：

当所述供应请求和所述令牌被验证之后，由所述设备供应服务向所述IoT应用服务注册所述IoT设备。

13.根据权利要求11所述的方法，还包括：

由所述设备供应服务与所述RoT认证服务交换安全证书；

从所述RoT认证服务获得认证方法的列表；

从所述列表中选择认证方法；

分配用于所述认证方法的策略标识符；

向所述RoT认证服务发送所述策略标识符和所述认证方法；以及

与所述RoT认证服务建立会话密钥。

14.根据权利要求13所述的方法，其中所述策略标识符定义对由所述RoT认证服务发出的令牌的一个或多个要求。

15.根据权利要求13所述的方法，其中所述安全证书包括消息认证码MAC。

16.根据权利要求11所述的方法，其中接收所述消息包括接收统一资源定位符URL，所述URL在制造方使用描述MUD文件中被描述，其中所述MUD文件包括所述简档标识符。

17.根据权利要求11所述的方法，还包括：

从所述供应策略信息中确定认证方法，所述认证方法要由所述RoT认证服务使用以认证IoT设备，所述认证方法具有标识策略标识符；以及

在所述重定向响应中的统一资源定位符URL中编码所述标识策略标识符。

18.根据权利要求11所述的方法，还包括：

确定所述供应请求中的所述令牌具有未知格式；

向所述RoT认证服务发送对验证所述令牌的请求；以及

从所述RoT认证服务接收验证响应。

19.根据权利要求11所述的方法，还包括：

确定所述供应请求中的所述令牌包含RoT属性；

从所述令牌中提取所述RoT属性；

发送请求以从所述RoT认证服务获得附加RoT安全属性，所述附加RoT安全属性包括标识策略标识符；以及

验证所述附加RoT安全属性。

20.根据权利要求11所述的方法，还包括：

从所述IoT应用服务接收检查访问请求，以检查对IoT应用的访问是否应当被授予给IoT设备，其中所述检查访问请求包括所述IoT设备的所供应的信息；

使用所述所供应的信息验证对所述IoT设备的访问；以及

由所述设备供应服务向所述IoT应用服务发送响应。

21.一种方法，包括：

在信任根RoT认证服务处从设备供应服务接收供应策略信息，所述供应策略信息定义对发出令牌的要求；

在所述RoT认证服务处从物联网IoT设备接收重定向消息以认证和授权所述IoT设备，所述消息包括策略标识符和供应请求，所述策略标识符被用于标识所述供应策略信息；

由所述RoT认证服务根据所述供应策略信息认证和授权所述IoT设备；

当所述IoT设备被认证和授权之后，发出令牌；以及

利用发出的所述令牌向所述IoT设备发送重定向响应，所述重定向响应利用发出的所述令牌将所述IoT设备重定向到所述设备供应服务，以用于所述供应请求安全地供应请求，以安全地供应所述IoT设备，

22.根据权利要求21所述的方法，还包括：

由所述RoT认证服务与所述设备供应服务交换安全证书；

向所述设备供应服务提供认证方法的列表；

从所述列表中接收对认证方法的选择；

从所述设备供应服务接收所述策略标识符和所述认证方法的分配；以及

与所述设备供应服务建立会话密钥。

23.根据权利要求22所述的方法，其中所述策略标识符定义对由所述RoT认证服务发出的令牌的一个或多个要求。

24.根据权利要求22所述的方法，其中所述安全证书包括消息认证码MAC。

25.根据权利要求21所述的方法，其中接收所述重定向消息包括接收统一资源定位符URL，所述URL利用标识策略标识符被编码。