CN112217775B

CN112217775B - 一种远程证明方法及装置

Info

Publication number: CN112217775B
Application number: CN201910631547.4A
Authority: CN
Inventors: 夏靓; 潘伟; 史玉林; 魏建雄
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2019-07-12
Filing date: 2019-07-12
Publication date: 2022-04-05
Anticipated expiration: 2039-07-12
Also published as: JP7310003B2; CN112217775A; EP3982609A4; EP3982609A1; WO2021008490A1; BR112022000443A2; JP2022540231A; EP3982609B1; US20220131856A1; US12314398B2; CN114884689A

Abstract

本申请公开了一种远程证明方法和装置。该方法具体包括：第一网络设备通过第二网络设备接收加密信息和第二网络设备的第一度量信息，该加密信息是对第三网络设备的第二度量信息进行加密得到的信息；第一网络设备根据第一度量信息确定第二网络设备系统可信；第一网络设备对加密信息进行解密，得到第二度量信息。可见，若网络设备要进行远程证明，可以先确定对其进行远程证明的验证设备是系统可信的，即，先确保网络设备的远程证明环境的可信和安全，再利用该系统可信的验证设备对该网络设备进行远程证明，提高了远程证明的可靠性，从而提高了网络安全性。

Description

一种远程证明方法及装置

技术领域

本申请涉及通信技术领域，特别是涉及一种远程证明方法及装置，用于对网络设备的系统可信性进行远程证明。

背景技术

对于具有可信平台模块(英文：Trusted Platform Module，简称：TPM)的网络设备来说，TPM可以对网络设备上的系统启动过程、进程运行过程、配置文件等系统状态进行可信性度量，从而得到系统可信性的度量信息。在远程证明的场景下，网络设备可以将系统可信性的度量信息发送给服务器，服务器根据度量信息得到系统可信性的验证结果，用户可以通过访问服务器来查看验证结果。

随着系统可信性的远程证明被应用到越来越广泛的场景，网络中可能会出现大量用于对网络设备的系统可信性进行远程证明的服务器，这其中就难免会存在一些本身并不可信的服务器。若网络设备将其系统可信性的度量信息发送给本身并不可信的服务器，则网络设备可能出现较大的安全风险。

发明内容

基于此，本申请实施例提供了一种远程证明方法及装置，以避免服务器本身的系统不可信时获得网络设备系统可信性的度量信息，从而降低网络设备的安全风险。

第一方面，本申请实施例提供了一种远程证明方法，该方法具体可以包括：第一网络设备通过第二网络设备接收加密信息和第二网络设备的第一度量信息，该加密信息是对第三网络设备的第二度量信息进行加密得到的信息；第一网络设备根据第一度量信息，确定第二网络设备系统可信；第一网络设备对加密信息进行解密，得到第二度量信息。可见，本申请实施例提供的远程证明方法，通过第一网络设备先对第二网络设备的系统可信性进行验证，在确定第二网络设备系统可信的情况下，该第一网络设备才对加密信息进行解密，得到第三网络设备的第二度量信息，从而第二网络设备才可以基于该第二度量信息对第三网络设备进行系统可信性验证，如此，该远程证明方法确保了第三网络设备的远程证明环境的可信和安全，提高了远程证明的可靠性，从而降低了该网络设备发生安全风险的概率。

可以理解的是，一种情况下，第一网络设备是可以是具有制造商授权签名机构(英文：Manufacturer Authorized Signing Authority，简称：MASA)服务的设备MASA，第二网络设备是：验证服务器Verifier、中继设备Relying Party(下文中简称RP)、或RP&Verifier(即，将RP和Verifier合二为一的设备)；另一种情况下，第一网络设备也可以是MASA&Verifier(即，将MASA和Verifier合二为一的设备)，那么，第二网络设备可以是RP，第三网络设备可以是Attester。

结合第一方面的一种具体实现方式，该实施例还可以包括：第一网络设备向第二网络设备发送第二度量信息。其中，第一网络设备为MASA，第二网络设备为Verifier。这样，第二网络设备可以基于第二度量信息对第三网络设备的系统可信性进行验证。

作为该实现方式的一个示例，第一网络设备通过第二网络设备接收加密信息和第二网络设备的第一度量信息，具体为：第一网络设备接收第二网络设备发送的网络配置NETCONF协议的请求消息，请求消息中携带有加密信息和第一度量信息；第一网络设备向第二网络设备发送第二度量信息，具体为：第一网络设备向第二网络设备发送NETCONF协议的响应消息，响应消息中携带有第二度量信息。可以理解的是，在请求消息中采用因特网工程任务组又一代数据模型IETF YANG Data Model格式对加密信息和第一度量信息进行描述；在响应消息中采用IETF YANG Data Model格式对第一度量信息进行描述。

结合第一方面的另一种具体实现方式，该实施例还可以包括：第一网络设备根据第二度量信息，验证第三网络设备的系统可信性，得到第一验证结果；第一网络设备向第二网络设备发送第一验证结果。其中，第一网络设备为MASA&Verifier，第二网络设备为RP。这样，第一网络设备可以基于第二度量信息对第三网络设备的系统可信性进行验证，并将验证结果发送给第二网络设备，以便用户通过第二网络设备查看第三网络设备的系统可信性。

作为该实现方式的一个示例，第一网络设备通过第二网络设备接收加密信息和第二网络设备的第一度量信息，具体为：第一网络设备接收第二网络设备发送的网络配置NETCONF协议的请求消息，请求消息中携带有加密信息和第一度量信息；第一网络设备向第二网络设备发送第一验证结果，具体为：第一网络设备向第二网络设备发送NETCONF协议的响应消息，响应消息中携带有第一验证结果。可以理解的是，在请求消息中采用因特网工程任务组又一代数据模型IETF YANG Data Model格式对加密信息和第一度量信息进行描述；在响应消息中采用IETF YANG Data Model格式对第一验证结果进行描述。

结合第一方面的又一种具体实现方式，第一网络设备通过第二网络设备接收加密信息，具体为：第一网络设备通过第二网络设备接收由第四网络设备发送的加密信息；该方法还包括：第一网络设备通过第二网络设备接收第四网络设备的第三度量信息；那么，第一网络设备对加密信息进行解密之前，该方法还包括：第一网络设备根据第三度量信息，确定第四网络设备的系统可信。其中，第一网络设备为MASA，第二网络设备为Verifier，第三网络设备为Attester，第四网络设备为RP。

结合第一方面的再一种具体实现方式，该实施例还可以包括：第一网络设备接收第二网络设备发送的身份信息；那么，第一网络设备对加密信息进行解密之前，该方法还包括：第一网络设备根据身份信息，确定第二网络设备身份合法。其中，一种情况下，第一网络设备是可以是MASA，第二网络设备是：Verifier、RP、或RP&Verifier；另一种情况下，第一网络设备也可以是MASA&Verifier，第二网络设备可以是RP，第三网络设备可以是Attester。这样，第一网络设备在对加密信息进行解密之前，确保了对第三网络设备进行系统可信验证的第二网络设备的身份合法性和系统可信性，提高了远程证明的安全性。

作为一个示例，该第一验证结果，可以用于确定是否允许第三网络设备接入网络。具体而言，当第一验证结果表示第三网络设备系统可信时，确定允许该第三网络设备接入网络；反之，当第一验证结果表示第三网络设备系统不可信时，确定拒绝该第三网络设备接入网络。

第二方面，本申请实施例还提供了一种远程证明方法，该方法具体可以包括：第一网络设备接收第二网络设备发送的加密信息，加密信息是对第二网络设备的第一度量信息进行加密得到的信息；第一网络设备向第三网络设备发送加密信息和第一网络设备的第二度量信息；第一网络设备接收第三网络设备发送的指示信息；第一网络设备根据该指示信息确定第二网络设备的系统可信性。可见，本申请实施例提供的远程证明方法，通过第三网络设备先对第一网络设备的系统可信性进行验证，在确定第一网络设备系统可信的情况下，该第三网络设备才对加密信息进行解密，得到第二网络设备的第一度量信息，从而第一网络设备才可以基于该第一度量信息对第二网络设备进行系统可信性验证，如此，该远程证明方法确保了第二网络设备的远程证明环境的可信和安全，提高了远程证明的可靠性，从而降低了该网络设备发生安全风险的概率。

可以理解的是，第一网络设备可以是RP、Verifier或RP&Verifier，那么，第二网络设备可以是Attester，第三网络设备可以是Verifier、MASA或MASA&Verifier。

结合第二方面的一种具体实现方式，对于第一网络设备为RP的情况，该指示信息可以为第二网络设备的系统可信性的验证结果。

结合第二方面的另一种具体实现方式，对于第一网络设备为Verifier的情况，该指示信息还可以为第一度量信息；那么，第一网络设备根据指示信息确定第二网络设备的系统可信性，具体为：第一网络设备根据第一度量信息，验证第二网络设备的系统可信性。

其中，第一网络设备向第三网络设备发送的加密信息和第三网络设备的第二度量信息，具体为：第一网络设备向第三网络设备发送的网络配置NETCONF协议的请求消息，请求消息中携带有加密信息和第二度量信息；第一网络设备接收第三网络设备发送的第一验证结果，具体为：第一网络设备接收第三网络设备发送的NETCONF协议的响应消息，响应消息中携带有指示信息。作为一个示例，在请求消息中采用因特网工程任务组又一代数据模型IETF YANG Data Model格式对加密信息和第二度量信息进行描述；在响应消息中采用IETF YANG Data Model格式对指示信息进行描述。

结合第二方面的再一种具体实现方式，第一网络设备接收第二网络设备发送的加密信息，具体为：第一网络设备通过第四网络设备接收第二网络设备发送的加密信息；那么，该方法还包括：第一网络设备接收第四网络设备发送的第四网络设备的第三度量信息；第一网络设备向第三网络设备发送第三度量信息。其中，第一网络设备可以是Verifier，第二网络设备可以是Attester，第三网络设备可以是MASA，第四网络设备可以是RP。

结合第二方面的又一种具体实现方式，该实施例还包括：第一网络设备接收第二网络设备发送的第一身份信息；那么，在第一网络设备向第三网络设备发送该加密信息和第一网络设备的第二度量信息之前，该方法还包括：第一网络设备根据第一身份信息，确定第二网络设备身份合法。其中，第一网络设备可以是RP、Verifier或RP&Verifier，那么，第二网络设备可以是Attester，第三网络设备可以是Verifier、MASA或MASA&Verifier。

结合第二方面的另一种具体实现方式，该实施例还包括：第一网络设备接收第四网络设备发送的第二身份信息；那么，在第一网络设备向第三网络设备发送该加密信息和第一网络设备的第二度量信息之前，该方法还包括：第一网络设备根据第二身份信息，确定第四网络设备身份合法。其中，第一网络设备可以是Verifier，第二网络设备可以是Attester，第三网络设备可以是MASA，第四网络设备可以是RP。

结合第二方面的又一种具体实现方式，该实施例还包括：第一网络设备向第三网络设备发送第一网络设备的第三身份信息。其中，该第三身份信息用于验证第一网络设备的身份合法性。

可以理解的是，该实施例中，第一网络设备还可以根据第二网络设备的系统可信性，确定是否允许第二网络设备接入网络。

需要说明的是，第二方面提供的方法和第一方面提供的方法是基于两个网络设备介绍的同一远程证明方法，是相对应的，故第二方面提供的方法的各种可能的实现方式以及达到的技术效果，可以参照前述第一方面提供的方法的介绍。

第三方面，本申请实施例还提了一种远程证明方法，该方法具体可以包括：第一网络设备生成加密信息，加密信息是对第一网络设备的度量信息进行加密得到的信息；第一网络设备向第二网络设备发送加密信息；其中，度量信息用于验证第一网络设备的系统可信性，从而得到验证结果。可见，本申请实施例提供的远程证明方法，通过第一网络设备对其度量信息进行加密后，将加密信息发送给第二网络设备，如此，该远程证明方法可以在确定了对第一网络设备的远程证明环境的可信和安全的情况下，第二网络设备才可以获取解密后的第一网络设备的度量信息，从而对第一网络设备进行系统可信性验证，提高了远程证明的可靠性，从而降低了该网络设备发生安全风险的概率。

可以理解的是，第一网络设备可以是Attester，第二网络设备可以是Verifier、RP或RP&Verifier。

结合第三方面的一种具体实现方式，该实施例还可以包括：第一网络设备向第二网络设备发送第一网络设备的身份信息，身份信息用于验证第一网络设备的身份合法性。其中，第一网络设备可以是Attester，第二网络设备可以是Verifier、RP或RP&Verifier。

结合第三方面的另一种具体实现方式，该验证结果，可以用于确定是否允许第一网络设备接入网络。

需要说明的是，第三方面提供的方法和第一方面提供的方法是基于两个网络设备介绍的同一远程证明方法，是相对应的，故第三方面提供的方法的各种可能的实现方式以及达到的技术效果，可以参照前述第一方面提供的方法的介绍。

第四方面，本申请实施例还提供了另一种远程证明方法，该方法具体可以包括：第一网络设备向第二网络设备查询第三网络设备的系统可信性；第一网络设备确定第三网络设备系统可信；第一网络设备向第三网络设备发送第一网络设备的度量信息；其中，度量信息用于验证第一网络设备的系统可信性，从而得到验证结果。可见，本申请实施例提供的远程证明方法，通过预先在第二网络设备上保存有第三网络设备的系统可信性验证结果，在第一网络设备向第三网络设备发送该第一网络设备的度量信息之前，先向第二网络查询第三网络设备的系统可信性验证结果，在确定第三网络设备系统可信的情况下，该第一网络设备才将其度量信息发送给第三网络设备，由第三网络设备基于该度量信息对第一网络设备进行系统可信性验证，确保了第一网络设备的远程证明环境的可信和安全，提高了网络设备进行远程证明的可靠性，从而降低了网络发生的安全风险概率。

可以理解的是，第一网络设备可以是Attester，第二网络设备为MASA，那么，第三网络设备可以是Verifier、RP&Verifier或RP。

结合第四方面的一种具体实现方式，在第一网络设备向第三网络设备发送第一网络设备的度量信息之前，该实施例还包括：第一网络设备向第二网络设备查询第四网络设备的系统可信性；第一网络设备确定第四网络设备系统可信；其中，第三网络设备用于将接收到的度量信息向第四网络设备发送，第四网络设备用于根据度量信息验证第一网络设备的系统可信性。这样，第一网络设备确定接收其度量信息的第三网络设备和第四网络设备均系统可信的情况下，才通过第三网络设备将其度量信息发送给第四网络设备，确保了对第一网络设备进行系统可信验证环境的可信和安全，提高了远程证明的安全性。其中，第一网络设备可以是Attester，第二网络设备为MASA，第三网络设备为RP，第四网络设备为Verifier。

结合第四方面的一种具体实现方式，在第一网络设备向第三网络设备发送第一网络设备的度量信息之前，该实施例还包括：第一网络设备向第二网络设备查询第三网络设备的身份合法性以及第四网络设备的身份合法性；第一网络设备确定第四网络设备身份合法。这样，第一网络设备确定接收其度量信息的第三网络设备和第四网络设备均系统可信和身份合法的情况下，才通过第三网络设备将其度量信息发送给第四网络设备，确保了对第一网络设备进行系统可信验证环境的可信和身份合法，提高了远程证明的安全性。其中，第一网络设备可以是Attester，第二网络设备为MASA，第三网络设备为RP，第四网络设备为Verifier。

可以理解的是，第一网络设备系统可信性的验证结果，用于确定是否允许第一网络设备接入网络。

第五方面，本申请实施例还提供了一种远程证明方法，该方法具体可以包括：第一网络设备向第二网络设备发送第一网络设备的第一度量信息，第一度量信息用于验证第一网络设备的系统可信性并将第一网络设备的系统可信性的第一验证结果记录在第二网络设备中；第一网络设备接收第三网络设备发送的第三网络设备的第二度量信息；其中，第二度量信息用于验证第三网络设备的系统可信性。可以理解的是，第一网络设备可以是RP、Verifier或RP&Verifier，那么，第二网络设备可以是MASA，第三网络设备可以是Attester。

结合第五方面的一种具体实现方式，该实施例还可以包括：第一网络设备向第四网络设备发送第二度量信息。其中，第一网络设备可以是RP，第四网络设备可以是Verifier，第二网络设备可以是MASA，第三网络设备可以是Attester。

在本实施例中，第四网络设备与第二网络设备为相同的设备。即，第四网络设备和第二网络设备均为MASA&Verifier。

结合第五方面的另一种具体实现方式，该实施例还包括：第一网络设备接收第四网络设备发送的第二验证结果，第二验证结果为第二网络设备的系统可信性的验证结果。

结合第五方面的又一种具体实现方式，该实施例还包括：第一网络设备根据第二度量信息，验证第三网络设备的系统可信性。其中，第一网络设备为Verifier。

结合第五方面的再一种具体实现方式，该实施例还包括：第一网络设备接收第三网络设备发送的第一身份信息；第一网络设备根据第一身份信息，验证第三网络设备的身份合法性。

结合第五方面的另一种具体实现方式，该实施例还包括：第一网络设备向第二网络设备发送第一网络设备的第二身份信息，第二身份信息用于验证第一网络设备的身份合法性并将第一网络设备的身份合法性的第二验证结果记录在第二网络设备中。

结合第五方面的又一种具体实现方式，该实施例还包括：第一网络设备根据第三网络设备的系统可信性的验证结果，确定是否允许第三网络设备接入网络。

需要说明的是，第五方面提供的方法和第四方面提供的方法是基于两个网络设备介绍的同一远程证明方法，是相对应的，故第五方面提供的方法的各种可能的实现方式以及达到的技术效果，可以参照前述第四方面提供的方法的介绍。

第六方面，本申请实施例还提供了一种远程证明方法，该方法具体可以包括：第一网络设备接收第二网络设备发送的第二网络设备的第一度量信息；第一网络设备根据第一度量信息，验证第二网络设备的系统可信性，得到第一验证结果；第一网络设备接收第三网络设备针对第二网络设备的系统可信性的验证结果的查询请求；第一网络设备向第三网络设备发送第一验证结果。

可以理解的是，一种情况下，第一网络设备可以是MASA，那么，第二网络设备可以是Verifier、RP或RP&Verifier，第三网络设备可以是Attester；另一种情况下，该第一网络设备也可以是MASA&Verifier，那么，第二网络设备可以是RP，第三网络设备可以是Attester。

结合第六方面的一种具体实现方式，该实施例还包括：第一网络设备接收第四网络设备发送的第四网络设备的第二度量信息；第一网络设备根据第二度量信息，验证第四网络设备的系统可信性，得到第二验证结果；第一网络设备接收第三网络设备针对第四网络设备的系统可信性的验证结果的查询请求；第一网络设备向第三网络设备发送第二验证结果；其中，第二网络设备用于接收第三网络设备发送的第三网络设备的第三度量信息并向第四网络设备发送第三度量信息；第四网络设备用于根据第三度量信息验证第三网络设备的系统可信性，从而得到第五验证结果。其中，第一网络设备可以是MASA，第二网络设备是RP，第四网络设备是verifier，第三网络设备可以是Attester。

可以理解的是，该第五验证结果，用于确定是否允许第三网络设备接入网络。

结合第六方面的另一种具体实现方式，该实施例还包括：第一网络设备接收第二网络设备发送的第二网络设备的第一身份信息和第四网络设备发送的第四网络设备的第二身份信息；第一网络设备根据第一身份信息，验证第二网络设备的系统可信性，得到第三验证结果，以及，根据第二身份信息，验证第四网络设备的系统可信性，得到第四验证结果；第一网络设备接收第三网络设备针对第二网络设备的身份合法性的验证结果的查询请求和第三网络设备针对第四网络设备的身份合法性的验证结果的查询请求；第一网络设备向第三网络设备发送第三验证结果和第四验证结果。

结合第六方面的又一种具体实现方式，该实施例还包括：第一网络设备接收第三网络设备经第二网络设备发送的第三网络设备的第三度量信息；第一网络设备根据第三度量信息，验证第三网络设备的系统可信性；第一网络设备向第三网络设备发送第五验证结果，第五验证结果为第三网络设备的系统可信性的验证结果。其中，第一网络设备可以是MASA&Verifier，第二网络设备是RP，第三网络设备是Attester。

需要说明的是，第六方面提供的方法和第四方面提供的方法是基于两个网络设备介绍的同一远程证明方法，是相对应的，故第六方面提供的方法的各种可能的实现方式以及达到的技术效果，可以参照前述第四方面提供的方法的介绍。

第七方面，本申请实施例还提供了一种远程证明装置，该装置包括：接收单元和处理单元。

其中，接收单元，用于通过第二网络设备接收加密信息和第二网络设备的第一度量信息，加密信息是对第三网络设备的第二度量信息进行加密得到的信息；

处理单元，用于根据第一度量信息，确定第二网络设备系统可信；并对加密信息进行解密，得到第二度量信息。

结合第七方面的一种具体实现方式，该装置还包括：发送单元。该发送单元，用于向第二网络设备发送第二度量信息。

作为一个示例，接收单元，具体用于：接收第二网络设备发送的网络配置NETCONF协议的请求消息，请求消息中携带有加密信息和第一度量信息；发送单元，具体用于：向第二网络设备发送NETCONF协议的响应消息，响应消息中携带有第二度量信息。其中，在请求消息中采用因特网工程任务组又一代数据模型IETF YANG Data Model格式对加密信息和第一度量信息进行描述；在响应消息中采用IETF YANG Data Model格式对第一度量信息进行描述。

结合第七方面的另一种具体实现方式，处理单元，还用于根据第二度量信息，验证第三网络设备的系统可信性，得到第一验证结果；发送单元，还用于向第二网络设备发送第一验证结果。

可以理解的是，第一验证结果，用于确定是否允许第三网络设备接入网络。

作为一个示例，该第一接收单元，具体用于：接收第二网络设备发送的网络配置NETCONF协议的请求消息，请求消息中携带有加密信息和第一度量信息；第二发送单元，具体用于：第一网络设备向第二网络设备发送NETCONF协议的响应消息，响应消息中携带有第一验证结果。其中，在请求消息中采用因特网工程任务组又一代数据模型IETF YANG DataModel格式对加密信息和第一度量信息进行描述；在响应消息中采用IETF YANG DataModel格式对第一验证结果进行描述。

结合第七方面的再一种具体实现方式，该接收单元，具体用于：通过第二网络设备接收由第四网络设备发送的加密信息；那么，该接收单元，还用于通过第二网络设备接收第四网络设备的第三度量信息；处理单元，还用于在第一网络设备对加密信息进行解密之前，根据第三度量信息，确定第四网络设备的系统可信性。

结合第七方面的另一种具体实现方式，接收单元，还用于接收第二网络设备发送的身份信息；处理单元，还用于第一网络设备对加密信息进行解密之前，根据身份信息，确定第二网络设备身份合法。

需要说明的是，第七方面提供的装置和第一方面提供的方法相对应的，故第七方面提供的装置的各种可能的实现方式以及达到的技术效果，可以参照前述第一方面提供的方法的介绍。

第八方面，本申请实施例还提供了一种远程证明装置，包括：接收单元、发送单元和处理单元。

其中，接收单元，用于接收第二网络设备发送的加密信息，加密信息是对第二网络设备的第一度量信息进行加密得到的信息；

发送单元，用于向第三网络设备发送加密信息和第一网络设备的第二度量信息；

接收单元，还用于接收第三网络设备发送的指示信息；

处理单元，用于根据指示信息确定第二网络设备的系统可信性。

一种情况下，该指示信息为第二网络设备的系统可信性的验证结果。

另一种情况下，该指示信息为第一度量信息；那么，该处理单元，具体用于：根据第一度量信息，验证第二网络设备的系统可信性。

作为一个示例，该发送单元，具体用于：向第三网络设备发送的网络配置NETCONF协议的请求消息，请求消息中携带有加密信息和第二度量信息；接收单元，具体用于：接收第三网络设备发送的NETCONF协议的响应消息，响应消息中携带有指示信息。其中，在请求消息中采用因特网工程任务组又一代数据模型IETF YANG Data Model格式对加密信息和第二度量信息进行描述；在响应消息中采用IETF YANG Data Model格式对指示信息进行描述。

结合第八方面的一种具体实现方式，该接收单元，具体用于：通过第四网络设备接收第二网络设备发送的加密信息；接收单元，还用于接收第四网络设备发送的第四网络设备的第三度量信息；发送单元，还用于向第三网络设备发送第三度量信息。

结合第八方面的另一种具体实现方式，接收单元，还用于接收第二网络设备发送的第一身份信息；处理单元，还用于在第一网络设备向第三网络设备发送加密信息和第一网络设备的第二度量信息之前，根据第一身份信息，确定第二网络设备的身份合法。

结合第八方面的又一种具体实现方式，接收单元，还用于接收第四网络设备发送的第二身份信息；处理单元，还用于在第一网络设备向第三网络设备发送加密信息和第一网络设备的第二度量信息之前，根据第二身份信息，确定第四网络设备的身份合法。

结合第八方面的再一种具体实现方式，该发送单元，还用于向第三网络设备发送第一网络设备的第三身份信息。

结合第八方面的又一种具体实现方式，该处理单元，还用于根据第二网络设备的系统可信性，确定是否允许第二网络设备接入网络。

需要说明的是，第八方面提供的装置和第二方面提供的方法相对应的，故第八方面提供的装置的各种可能的实现方式以及达到的技术效果，可以参照前述第二方面提供的方法的介绍。

第九方面，本申请实施例还提供了一种远程证明装置，包括：处理单元和发送单元。

其中，处理单元，用于生成加密信息，加密信息是对第一网络设备的度量信息进行加密得到的信息；

发送单元，用于向第二网络设备发送加密信息；其中，度量信息用于验证第一网络设备的系统可信性，从而得到验证结果。可以理解的是，该验证结果，用于确定是否允许第一网络设备接入网络。

结合第九方面的一种具体实现方式，该发送单元，还用于向第二网络设备发送第一网络设备的身份信息，身份信息用于验证第一网络设备的身份合法性。

需要说明的是，第九方面提供的装置和第三方面提供的方法相对应的，故第九方面提供的装置的各种可能的实现方式以及达到的技术效果，可以参照前述第三方面提供的方法的介绍。

第十方面，本申请实施例还提供了一种远程证明装置，包括：处理单元和发送单元。

其中，处理单元，用于第一网络设备向第二网络设备查询第三网络设备的系统可信性；并确定第三网络设备系统可信；

发送单元，用于向第三网络设备发送第一网络设备的度量信息；其中，度量信息用于验证第一网络设备的系统可信性，从而得到验证结果。

可以理解的是，验证结果，用于确定是否允许第一网络设备接入网络。

结合第十方面的一种具体的实现方式，处理单元，还用于在第一网络设备向第三网络设备发送第一网络设备的度量信息之前，向第二网络设备查询第四网络设备的系统可信性；并确定第四网络设备系统可信；其中，第三网络设备用于将接收到的度量信息向第四网络设备发送，第四网络设备用于根据度量信息验证第一网络设备的系统可信性。

结合第十方面的另一种具体的实现方式，处理单元，还用于在第一网络设备向第三网络设备发送第一网络设备的度量信息之前，向第二网络设备查询第三网络设备的身份合法性以及第四网络设备的身份合法性；并确定第四网络设备身份合法。

需要说明的是，第十方面提供的装置和第四方面提供的方法相对应的，故第十方面提供的装置的各种可能的实现方式以及达到的技术效果，可以参照前述第四方面提供的方法的介绍。

第十一方面，本申请实施例还提供了一种远程证明装置，包括：发送单元和接收单元。

其中，发送单元，用于向第二网络设备发送第一网络设备的第一度量信息，第一度量信息用于验证第一网络设备的系统可信性并将第一网络设备的系统可信性的第一验证结果记录在第二网络设备中；

接收单元，用于接收第三网络设备发送的第三网络设备的第二度量信息；其中，第二度量信息用于验证第三网络设备的系统可信性。

结合第十一方面的一种具体实现方式，发送单元，还用于向第四网络设备发送第二度量信息。

结合第十一方面的另一种具体实现方式，第四网络设备与第二网络设备为相同的设备。

结合第十一方面的又一种具体实现方式，接收单元，还用于接收第四网络设备发送的第二验证结果，第二验证结果为第二网络设备的系统可信性的验证结果。

结合第十一方面的再一种具体实现方式，该装置还包括：处理单元。该处理单元，用于根据第二度量信息，验证第三网络设备的系统可信性。

结合第十一方面的又一种具体实现方式，接收单元，还用于接收第三网络设备发送的第一身份信息；处理单元，还用于根据第一身份信息，验证第三网络设备的身份合法性。

结合第十一方面的另一种具体实现方式，发送单元，还用于向第二网络设备发送第一网络设备的第二身份信息，第二身份信息用于验证第一网络设备的身份合法性并将第一网络设备的身份合法性的第二验证结果记录在第二网络设备中。

结合第十一方面的又一种具体实现方式，处理单元，还用于根据第三网络设备的系统可信性的验证结果，确定是否允许第三网络设备接入网络。

需要说明的是，第十一方面提供的装置和第五方面提供的方法相对应的，故第十一方面提供的装置的各种可能的实现方式以及达到的技术效果，可以参照前述第五方面提供的方法的介绍。

第十二方面，本申请实施例还提供了一种远程证明装置，包括：接收单元、处理单元和发送单元。

其中，接收单元，用于接收第二网络设备发送的第二网络设备的第一度量信息；

处理单元，用于根据第一度量信息，验证第二网络设备的系统可信性，得到第一验证结果；

接收单元，还用于接收第三网络设备针对第二网络设备的系统可信性的验证结果的查询请求；

发送单元，用于向第三网络设备发送第一验证结果。

结合第十二方面的一种具体实现方式，接收单元，还用于接收第四网络设备发送的第四网络设备的第二度量信息；处理单元，还用于根据第二度量信息，验证第四网络设备的系统可信性，得到第二验证结果；接收单元，还用于接收第三网络设备针对第四网络设备的系统可信性的验证结果的查询请求；发送单元，还用于向第三网络设备发送第二验证结果；其中，第二网络设备用于接收第三网络设备发送的第三网络设备的第三度量信息并向第四网络设备发送第三度量信息；第四网络设备用于根据第三度量信息验证第三网络设备的系统可信性，从而得到第五验证结果。

结合第十二方面的另一种具体实现方式，接收单元，还用于接收第二网络设备发送的第二网络设备的第一身份信息和第四网络设备发送的第四网络设备的第二身份信息；处理单元，还用于根据第一身份信息，验证第二网络设备的系统可信性，得到第三验证结果，以及，根据第二身份信息，验证第四网络设备的系统可信性，得到第四验证结果；接收单元，还用于接收第三网络设备针对第二网络设备的身份合法性的验证结果的查询请求和第三网络设备针对第四网络设备的身份合法性的验证结果的查询请求；发送单元，还用于向第三网络设备发送第三验证结果和第四验证结果。

结合第十二方面的又一种具体实现方式，接收单元，还用于接收第三网络设备经第二网络设备发送的第三网络设备的第三度量信息；处理单元，还用于根据第三度量信息，验证第三网络设备的系统可信性；发送单元，还用于向第三网络设备发送第五验证结果，第五验证结果为第三网络设备的系统可信性的验证结果。

需要说明的是，第十二方面提供的装置和第六方面提供的方法相对应的，故第十二方面提供的装置的各种可能的实现方式以及达到的技术效果，可以参照前述第六方面提供的方法的介绍。

第十三方面，本申请实施例还提供了一种网络设备，该网络设备包括存储器和处理器；其中，存储器，用于存储程序代码；处理器，用于运行程序代码中的指令，使得网络设备执行以上第一方面～第三方面任意一种实现方式下的远程证明方法。

第十四方面，本申请实施例还提供了一种网络设备，该网络设备包括存储器和处理器；其中，存储器，用于存储程序代码；处理器，用于运行程序代码中的指令，使得网络设备执行以上第四方面～第六方面任意一种实现方式下的远程证明方法。

第十五方面，本申请实施例还提供了一种计算机程序产品，当其在计算机上运行时，使得计算机执行前述第一方面～第六方面任意一种实现方式下的远程证明方法。。

第十六方面，本申请实施例还提供了一种计算机可读存储介质，计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行以上第一方面～第六方面任意一种实现方式下的远程证明方法。

第十七方面，本申请实施例还提供了一种通信系统，包括第十三方面提供的网络设备以及第十四方面提供的网络设备。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。

图1为本申请实施例中一度量启动的可信性证明过程的结构示意图；

图2为本申请实施例中一应用场景中远程证明的框架示意图；

图3为本申请实施例中另一应用场景中远程证明的框架示意图；

图4为本申请实施例中又一应用场景中远程证明的框架示意图；

图5为本申请实施例中一种远程证明方法的信令流程图；

图6为本申请实施例中另一种远程证明方法的信令流程图；

图7为本申请实施例中又一种远程证明方法的信令流程图；

图8为本申请实施例中再一种远程证明方法的信令流程图；

图9为本申请实施例中另一种远程证明方法的信令流程图；

图10为本申请实施例中又一种远程证明方法的信令流程图；

图11为本申请实施例中再一种远程证明方法的信令流程图；

图12为本申请实施例中另一种远程证明方法的信令流程图；

图13为本申请实施例中一种BRSKI和远程证明过程的信令流程图；

图14为本申请实施例中又一种BRSKI和远程证明过程的信令流程图；

图15为本申请实施例中另一种BRSKI和远程证明过程的信令流程图；

图16为本申请实施例中一种远程证明方法的流程示意图；

图17为本申请实施例中另一种远程证明方法的流程示意图；

图18为本申请实施例中又一种远程证明方法的流程示意图；

图19为本申请实施例中一种远程证明方法的流程示意图；

图20为本申请实施例中另一种远程证明方法的流程示意图；

图21为本申请实施例中又一种远程证明方法的流程示意图；

图22为本申请实施例中一种远程证明装置的结构示意图；

图23为本申请实施例中另一种远程证明装置的结构示意图；

图24为本申请实施例中又一种远程证明装置的结构示意图；

图25为本申请实施例中再一种远程证明装置的结构示意图；

图26为本申请实施例中又一种远程证明装置的结构示意图；

图27为本申请实施例中另一种远程证明装置的结构示意图；

图28为本申请实施例中一种网络设备的结构示意图；

图29为本申请实施例中另一种网络设备的结构示意图；

图30为本申请实施例中一种通信系统的结构示意图。

具体实施方式

随着信息爆发式的增长以及万物互联的盛况，网络中包括越来越多的网络设备，为了提高安全、可靠的网络环境，需要对网络和网络设备等有较高的可信性要求，这就需要对网络中的网络设备进行严格的可信验证。

可以理解的是，网络设备中具有可信平台模块(英文：Trusted Platform Module，简称：TPM)，该TPM中存在不可被篡改的、绝对可信且不需要外界维护的可信组件(也称为可信根)，是可信验证必不可少的部分。通常，TPM中有三个可信根：度量可信根(英文：Root ofTrust for Measurement，简称：RTM)、存储可信根(英文：Root of Trust for Storage，简称：RTS)和报告可信根(英文：Root of Trust for Reporting，简称：RTR)。其中，RTM用于对其所属的网络设备进行完整性度量，是使用核心度量可信根(英文：Core Root of Trustfor Measurement，简称：CRTM)控制的计算组件，该CRTM是TPM执行RTM时的执行代码，一般存储在基本输入输出系统(英文：Basic Input Output System，简称：BIOS)中，由于度量信息是该RTM度量产生的，所以该RTM可以作为可信相关度量信息传递的原点。其中，完整性度量可以是指对网络设备上的软件在运行期间的每个阶段均进行的度量。RTS是用于保存完整性度量和度量序列的组件，可以由对存储加密的组件和加密密钥组成。RTR是一个通过计算生成报告的组件，能够可靠地报告RTS存储的度量信息，可以由签名来保证该RTR组件的可靠性。上述RTM、RTS和RTR三个可信根可以存在于网络设备的TPM和BIOS中，可以由专家或技术人员通过评估来确定该网络设备的某一系统状态是否符合可信的标准。需要说明的是，TPM和BIOS通常视作绝对可信的模块。

对某个网络设备的系统可信性验证，具体可以包括：该网络设备中的TPM对该网络设备上的系统启动过程、进程运行过程、配置文件等系统状态进行可信性度量，得到系统可信性的度量信息；比较度量信息和可信标准，得到系统状态的可信性的验证结果，即，该网络设备的系统状态可信或者不可信；从而，用户可以通过查看验证结果确定该网络设备是否可信，从而以此为依据确定对该网络设备的后续操作，例如：对不可信的网络设备进行维护或者允许可信的网络设备接入网络。

作为一个示例，为了更加清楚的说明网络设备的系统可信性验证过程，下面以图1所示的启动模型为例，介绍网络设备的启动过程的系统可信性验证。

可以理解的是，在启动过程中，TPM对系统启动过程中涉及的关键启动步骤进行度量，并记录度量值。例如：参见图1，该网络设备进行度量启动的具体过程可以包括：第一步，TPM中的可信根为BIOS提供信任基础；第二步，BIOS启动，初始化硬件系统，通过调用TPM中的可信根，检查下一阶段要运行的Loader的签名，对该Loader和配置信息进行度量，并将度量值记录到TPM中；第三步，Loader运行，定位获取操作系统镜像文件，通过调用TPM中的可信根，检查下一阶段要运行的操作系统内核Kernel的签名，对该Kernel进行度量，并将度量值记录到TPM中；第四步，Kernel运行，启动操作系统和安全应用等，并对配置信息进行度量并将度量值记录到TPM中。上述启动过程可以称为度量启动过程，该度量启动过程的特点为：在系统启动过程中只进行度量和度量值的记录，不干涉启动过程，即，不会因为某个启动步骤对应的度量值不可信就停止启动。

在系统启动完成时，一种情况下，可以由该网络设备进行本地验证，即，由该网络设备根据该TPM记录的度量值产生报告并进行可信验证，得到验证结果。另一种情况下，也可以进行远程证明，即，由该网络设备根据该TPM记录的度量值产生报告，并将该报告发送给服务器，由该服务器基于接收到的报告进行可信验证得到验证结果；或者，由该TPM对产生的报告进行可信验证得到验证结果，并将该验证结果发送给服务器。

目前，随着待验证的网络设备的增多，相对于本地证明，由于远程证明更易于集中监控设备完整性，所以，网络设备的系统可信性的远程证明被应用到越来越广泛的场景中。可以理解的是，远程证明是指待可信验证的网络设备将度量信息发送给服务器，由服务器基于接收到的度量信息对该待可信验证的网络设备进行远程证明。其中，远程证明例如可以包括：一方面，服务器对网络设备的启动过程产生的度量信息进行远程证明；另一方面，服务器对网络设备运行过程中的进程等动态变化的对象，进行动态度量过程中产生的度量信息进行远程证明；再一方面，服务器对网络设备中产生的静态数据，如：配置信息、文件等，进行静态度量过程中产生的度量信息进行远程证明。

参见图2所示的网络模型，该模型示出了远程证明的一种场景。其中，该场景包括：证明平台Attest Platform 201、证明服务器Attest Server 202、隐私证书授权(英文：certificate authority，简称：CA)203和用户204。其中，证明平台Attest Platform 201可以是终端、物联网(英文：Internet of Thing，简称：IoT)网关、网络或应用服务器等需要进行远程证明的网络设备，该Attest Platform 201内部可以包括：中央处理器(英文：Central Processing Unit，简称：CPU)&TPM、BOIS、Kernel和应用(英文：application，简称：app)四部分，用于进行完整性值的计算和记录。

具体实现时，Attest Platform 201可以通过一定格式和交互流程将其自身安全属性(例如，包括：软、硬件完整性值，配置信息，节点状态等自身安全属性)通过挑战-响应的交互机制安全地发送给Attest Server 202，并由该Attest Server 202按照一定策略进行远程证明，最终证明该Attest Platform 201是否可信。另外，为了保证整个远程证明交互过程中设备和通信的安全性，必须预先部署好证书机制(包括证书申请和吊销等)，以支持交互过程中证书的校验和查看等必要操作，具体而言，Attest Platform 201使用从隐私CA203申请到的证书，对其记录的完整性值进行加密和签名，Attest Server 202对收到的信息解密，并与隐私CA203交互以校验Attest Platform 201的证书是否合法。用户204可以查看到隐私CA203对外颁发的证书，并能查看Attest Server 202对Attest Platform 201的远程证明结果。

举例来说，以因特网工程任务组(英文：internet engineering task framework，简称：IETF)远程证明程序(英文：Remote Attestation Procedures，简称：RATS)工作组定义的如图3所示的远程证明架构图为例，同时，定义了通过网络配置协议(英文：NetworkConfiguration Protocol，简称：NETCONF)的挑战-响应方式进行远程证明，远程证明的相关信息可以通过又一代(英文：Yet Another Next Generation，简称：YANG)数据模型进行描述。需要说明的是，该实例中的相关说明可以参见：draft-birkholz-rats-architecture-01和draft-birkholz-rats-reference-interaction-model-00的相关描述。

如图3所示，该场景示出的远程证明系统300包括：待证明设备Attester 301、验证服务器Verifier 302、中继设备Relying Party 303和供应链实体Asserter 304。其中，Attester 301是指该远程证明系统300中被验证的设备或应用，具体可以是：交换机、路由器、终端、个人计算机(英文：personal computer，简称：PC)、IoT、应用等；Verifier 302，具体可以是具有远程证明功能的服务器；Relying Party(下文中简称RP)303，例如可以是网络管理设备，在该远程证明系统300中，该RP 303可以同时与Attester 301和Verifier 302通信，进行远程证明中信息的交互；供应链实体Asserter 304，例如可以是设备制造商的网络设备。具体实现远程证明的过程可以包括：S11，Attester 301通过可信根计算并收集自身的各项完整性证明信息，作为度量信息，提供给RP 303；S12，RP 303接收Attester 301发送的待远程证明的度量信息，并通过签名认证的方式验证Attester 301的身份；S13，验证通过后，RP 303将Attester 301的待远程证明的度量信息用RP 303自己的证书进行签名，并发给Verifier 302；S14，Verifier 302验证Attester 301提供的度量信息，并将验证结果发送给RP 303。而在上述S11～S14之前，Asserter 304用于为Attester 301提供初始的设备ID等配置信息，而且其上具有Attester 301的完整性证明的参考值或标准值，也用于将这些参考值或标准值发送给Verifier 302，作为该Verifier 302进行远程证明的依据。需要说明的是，Attester 301具体可以对应图2中的证明平台Attest Platform 201，Verifier 302具体可以对应图2中的证明服务器Attest Server 202。

为了确保对网络设备的系统可信性验证可以可靠实施，需要严格要求执行远程证明的服务器自身必须是系统可信的。目前，网络设备假设服务器(或者服务器和中继设备)是身份合法且系统可信的，在此基础上由具有远程证明功能的服务器对该网络设备进行远程证明。但是，随着系统可信性的远程证明被广泛的应用，网络中可能会出现大量用于对网络设备的系统可信性进行远程证明的服务器(或者服务器和中继设备)，大量具有远程证明功能的服务器(或者服务器和中继设备)中，很有可能存在一些本身身份不合法、被攻克或者不可信的服务器(或者服务器和中继设备)。此时，执行远程证明的服务器(或者服务器和中继设备)的本身系统可信变得至关重要，若网络设备将其系统可信性的度量信息发送给本身并不可信的服务器(或者服务器和中继设备)，则网络设备可能出现较大的安全风险。

基于此，为了在远程证明服务器不断增多的场景下，提供一种更加可靠的远程证明方式，在本申请实施例中，不再假定服务器(或者服务器和中继设备)是系统可信的，而是对服务器(或者服务器和中继设备)进行系统可信性的验证，在确定该服务器(或者服务器和中继设备)可信后，该服务器才可以接收到网络设备的度量信息，并基于该度量信息验证网络设备的系统可信性。这样，避免了网络设备系统可信性的度量信息被本身系统不可信的服务器获得，导致该网络设备出现较大安全隐患的问题，通过对即将执行远程证明的服务器(或者服务器和中继设备)进行系统可信性验证，确保在验证结果为系统可信的服务器上进行网络设备的系统可信性验证，提高了网络设备远程证明的可靠性，从而降低网络设备的安全风险。

可以理解的是，本申请实施例可以通过因特网工程任务组(英文：internetengineering task framework，简称：IETF)引导远程安全密钥基础设施(英文：Bootstrapping Remote Secure Key Infrastructures，简称：BRSKI)协议中定义的，具有制造商授权签名机构(英文：Manufacturer Authorized Signing Authority，简称：MASA)服务的设备MASA，帮助网络设备验证服务器(或者服务器和中继设备)的系统可信性。所以，本申请实施例中的远程证明方法可以通过改进的IETF远程证明程序(英文：RemoteAttestation Procedures，简称：RATS)协议和IETF BRSKI协议进行。

举例来说，本申请实施例的场景之一，可以是应用到如图4所示的远程证明系统400中。该远程证明系统400除了包括远程证明系统300中所包括的：Attester 301、Verifier 302、RP 303和Asserter 304外，还可以包括：制造商授权签名机构(英文：Manufacturer Authorized Signing Authority，简称：MASA)305。其中，该MASA305，可以是指由因特网工程任务组(英文：internet engineering task framework，简称：IETF)的引导远程安全密钥基础设施(英文：Bootstrapping Remote Secure Key Infrastructures，简称：BRSKI)协议定义的一个由制造商提供或得到制造商授权的签名机构，例如：可以是专门的服务器设备，或者，也可以是计算机设备对外提供的软件服务。该MASA305，可以用于对RP 303和Verifier 302进行身份合法性和系统可信性验证，或者，其上也可以保存有RP303和Verifier 302的身份合法性验证结果和系统可信性验证结果。

作为一个示例，若MASA305具有对RP 303和Verifier 302进行系统可信性验证的能力，则，本申请实施例中实现远程证明的过程具体可以包括：S21，Attester 301向RP 303发送加密信息，该加密信息为度Attester 301的度量信息1加密得到的信息；S22，RP 303将加密信息和自身的度量信息2发送给Verifier 302；S23，Verifier 302将加密信息、度量信息2和自身的度量信息3发送给MASA 305；S24，MASA 305基于度量信息2和度量信息3，分别对RP 303和Verifier 302的系统可信性进行验证，得到验证结果1；S25，当验证结果1表示RP 303和Verifier 302均可信时，MASA 305将加密信息进行解密，得到度量信息1，并将度量信息1发送给Verifier 302；S26，Verifier 302基于度量信息1对Attester 301进行系统可信性验证，得到验证结果2；S27，Verifier 302将验证结果2发送给RP 303，供用户在Verifier 302或RP 303上查看Attester 301是否可信。

需要说明的是，S21～S23中除了发送上述描述中的信息，还可以携带身份信息，用于供直接接收该身份信息的设备对该发送方进行身份合法性验证，例如：S22中，RP 303还可以将自身的身份信息发送给Verifier 302，由Verifier 302对该RP 303的身份合法性进行验证；并将身份合法性验证结果携带在后续消息中发送，那么，执行S25时，当验证结果1表示RP 303和Verifier 302均可信，且身份验证结果表示Attester 301、RP 303和Verifier 302均身份合法时，MASA 305才将加密信息进行解密，得到度量信息1，并将度量信息1发送给Verifier 302，以执行后续验证过程。

作为另一个示例，若MASA 305上保存有RP 303和Verifier 302的系统可信性验证结果，则，本申请实施例中实现远程证明的过程具体也可以包括：S31，Attester 301向MASA305查询RP 303和Verifier 302的系统可信性；S32，MASA 305向Attester 301反馈关于RP303和Verifier 302的系统可信性的验证结果3；S33，若验证结果3表示RP 303和Verifier302的系统可信，则，Attester 301通过RP 303向Verifier 302发送该Attester 301的度量信息1；S34，Verifier 302基于度量信息1对Attester 301进行系统可信性验证，得到验证结果2；S35，Verifier 302将验证结果2发送给RP 303，供用户在Verifier 302或RP 303上查看Attester 301是否可信。

需要说明的是，S31中还可以向MASA305查询Attester 301、RP 303和Verifier302的身份合法性，那么，S32中反馈的验证结果3中还可以包括RP 303和Verifier 302的身份合法性的相关结果，那么，执行S33时，当验证结果3表示RP 303和Verifier 302均可信，且身份验证结果表示Attester 301、RP 303和Verifier 302均身份合法时，MASA 305才将加密信息进行解密，得到度量信息1，并将度量信息1发送给Verifier 302，以执行后续验证过程。

需要说明的是，本申请实施例中，RP 303和Verifier 302不具有对加密信息解密的能力。

需要说明的是，该场景中，RP 303和Verifier 302可以被部署于同一设备，或者，Attester 301可以和Verifier 302直接进行数据交互，此时，Attester 301就只需要关注Verifier 302(或Verifier 302和RP 301所属的设备)是否系统可信(或系统可信和身份合法)即可。

可以理解的是，上述场景仅是本申请实施例提供的一个场景示例，本申请实施例并不限于此场景。

下面结合附图，通过实施例来详细说明本申请实施例中一种远程证明方法的具体实现方式。

在一些具体的实现方式中，通过MASA先对RP和Verifier进行系统可信性验证，在确定RP和Verifier均系统可信的情况下，该MASA才对包括Attester度量信息1加密后的加密信息进行解密，由Verifier基于该度量信息1对Attester进行系统可信性验证，确保了Attester的远程证明环境的可信和安全，提高了Attester远程证明的可靠性，从而降低了该Attester的安全风险。具体实现方式可以参见下述图5～图8的实施例。

图5为本申请实施例中一种远程证明方法的信令流程图。参见图5，该方法应用于包括Attester、RP、Verifier和MASA的网络中，且已知该Attester、RP和Verifier身份合法。该方法具体可以包括下述步骤501～步骤509：

步骤501，Attester对其度量信息1进行加密，得到加密信息。

可以理解的是，假设整个网络已经通过BRSKI等机制完成了初始配网的过程，所有设备之间可以安全通信。在Attester在远程证明之前，无法判断进行远程证明的Verifier和RP是否系统可信，为了该Attester的安全，需要先将自身的度量信息1加密后在Verifier和RP之间发送，以免被不可信的Verifier或RP获得；待确定Verifier和RP系统可信后再将度量信息1发送给Verifier进行远程证明。其中，确定Verifier和RP系统可信，可以是通过具有MASA服务功能的MASA设备实现的，该MASA是通过扩展的BRSKI提供的。

可以理解的是，度量信息1，可以是指Attester在运行过程产生的、用于验证该Attester系统可信性的信息。该度量信息1具体可以包括对硬件完整性值、软件完整性值、配置信息等。其中，硬件完整性值可以是指Attester中硬件驱动程序(如：启动驱动程序)产生的度量值的集合；软件完整性值可以是指Attester中运行的进程等动态变化的对象产生的度量值的集合；配置信息可以是指Attester中产生的静态数据，如：配置信息、文件等，进行静态度量产生的信息。

具体实现时，Attester可以采用公钥对度量信息1进行加密，得到加密信息。一种情况下，该公钥可以是电气及电子工程师学会(英文：Institute of Electrical andElectronics Engineers，简称：IEEE)IEEE定义的IEEE 802.1AR的Attester的初始设备标识(英文：Initial Device Identity，简称：IDevID)，MASA可以对该IDevID加密的加密信息进行解密。另一种情况下，该公钥也可以是MASA对所有的待验证Attester统一分配的用于加密度量信息的公钥。再一种情况下，该公钥还可以是Attester和MASA约定且共同知晓的、用于加密度量信息的其他公钥。

需要说明的是，Verifier和RP不知晓加密信息的解密私钥，没有对加密信息进行解密的能力。

步骤502，Attester将加密信息发送给RP。

作为一个示例，Attester可以将加密信息携带在远程证明请求中，发送给RP，用于指示该RP将该远程证明请求发送给Verifier，并且指示该RP将自身的度量信息2发送给Verifier。

作为另一个示例，在步骤502之前，RP可以向Attester发起远程证明请求，那么，Attester还可将加密信息携带在远程证明响应消息中，发送给RP，用于指示该RP将该远程证明响应消息发送给Verifier，并且指示该RP将自身的度量信息2发送给Verifier。

步骤503，RP将加密信息和RP的度量信息2发送给Verifier。

其中，该度量信息2，可以是指RP在运行过程产生的、用于验证该RP系统可信性的信息。该度量信息2具体可以包括对硬件完整性值、软件完整性值、配置信息等。

具体实现时，RP接收到携带加密信息的远程证明请求或远程证明响应消息后，可以将自身的度量信息2也携带在该远程证明请求或远程证明响应消息中，和加密信息一起发送给Verifier。其中，该携带了度量信息2的远程证明请求或远程证明响应消息，用于指示Verifier将该消息中的加密信息和度量信息2以及该Verifier的度量信息3发送给MASA。

步骤504，Verifier向MASA发送请求消息，用于请求MASA验证Verifier和RP的系统可信性，其中，请求消息中携带加密信息、度量信息2和Verifier的度量信息3。

其中，该度量信息3，可以是指Verifier在运行过程产生的、用于验证该Verifier系统可信性的信息。该度量信息3具体可以包括对硬件完整性值、软件完整性值、配置信息等。

具体实现时，Verifier接收到远程证明请求或远程证明响应消息后，可以解析该远程证明请求或远程证明响应消息，获得其中携带加密信息和度量信息2，并且，将该加密信息、度量信息2以及自身的度量信息3携带在请求消息中，发送给MASA。

可以理解的是，该请求消息，一种情况下，可以是网络配置NETCONF协议已定义的凭证请求消息，用于指示MASA基于度量信息2和度量信息3分别对应RP和Verifier进行系统可信性验证，并在验证结果表示二者均系统可信时，对加密信息进行解密并将解密后的度量信息发送给Verifier。另一种情况下，也可以是NETCONF协议下新定义的请求消息。再一种情况下，还可以是其他协议中的请求消息。

作为一个示例，在该请求消息中，可以采用因特网工程任务组又一代数据模型IETF YANG Data Model格式对加密信息、度量信息2和度量信息3进行描述。例如：该YANG数据模型的请求消息具体可以如下：

其中，enumeration表示枚举，string表示数据类型为字符串，binary表示数据类型为二进制，boolean表示数据类型为布尔值。

步骤505，MASA基于度量信息2和度量信息3分别对RP和Verifier进行系统可信性验证，获得验证结果1和验证结果2。

可以理解的是，MASA可以判断度量信息2中是否存在一些度量参数不符合标准或者缺少必要的度量参数等异常情况，若存在，则可以确定该RP的系统不可信，若不存在，则可以确定该RP的系统可信，并根据确定的系统可信性得到验证结果1。该验证结果1用于表示该RP的系统是否可信。同理，MASA还可以判断度量信息3中是否存在一些度量参数不符合标准或者缺少必要的度量参数等异常情况，若存在，则可以确定该Verifier的系统不可信，若不存在，则可以确定该Verifier的系统可信，并根据确定的系统可信性得到验证结果2。该验证结果2用于表示该Verifier的系统是否可信。

步骤506，当验证结果1和验证结果2分别表示RP和Verifier系统可信时，MASA对加密信息进行解密，获得度量信息1。

可以理解的是，当验证结果1表示RP的系统可信，且验证结果2表示Verifier的系统可信时，该MASA确定由该RP和该Verifier对该Attester进行远程证明是安全和可信的，即，RP和Verifier获得了对Attester进行远程证明的资格。

需要说明的是，当验证结果1表示RP的系统不可信，或者，验证结果2表示Verifier的系统不可信，此时，该MASA确定由该RP和该Verifier对该Attester进行远程证明是不安全和不可信的，即，RP和Verifier不可以对Attester进行远程证明。该情况下，MASA可以将该验证结果1和验证结果2通过请求消息对应的响应消息发送给Attester、RP和Verifier，用于告知各个设备该次远程证明的验证结果。

具体实现时，该MASA可以基于Attester对度量信息1进行加密时的公钥的对应的私钥，对该加密信息进行解密，获得度量信息1。

步骤507，MASA将度量信息1携带在响应消息中发送给Verifier。

可以理解的是，按照请求消息的指示，在确定RR和Verifier系统可信后，MASA将度量信息1携带在响应消息中发送给Verifier。该响应消息，是指用于响应步骤504中的请求消息的消息，用于指示Verifier对Attester的度量信息1进行系统可信性验证。一种情况下，若请求消息为NETCONF协议已定义的凭证请求消息，那么，该响应消息可以是NETCONF协议中已定义的凭证响应消息。另一种情况下，若请求消息为NETCONF协议中新定义的请求消息，那么，该响应消息可以是NETCONF协议中与该新定义的请求消息对应的响应消息。再一种情况下，若请求消息为其他协议中的请求消息，那么，该响应消息可以是其他协议中的该请求消息对应的响应消息。

作为一个示例，在该响应消息中，也可以采用因特网工程任务组又一代数据模型IETF YANG Data Model格式对度量信息1进行描述。例如：该YANG数据模型的请求消息具体可以如下：

需要说明的是，该响应消息中，还可以包括RP、Verifier的系统可信性验证结果，用于告知RP和Verifier其系统可信。

步骤508，Verifier基于度量信息1，对Attester进行系统可信性验证，获得验证结果3。

可以理解的是，Verifier可以判断度量信息1中是否存在一些度量参数不符合标准或者缺少必要的度量参数等异常情况，若存在，则可以确定该Attester的系统不可信，若不存在，则可以确定该Attester的系统可信，并根据确定的系统可信性得到验证结果3。该验证结果3用于表示该Attester的系统是否可信。

步骤509，Verifier将验证结果3发送给RP。

作为一个示例，Verifier可以将验证结果3携带在响应消息中，发送给RP，可以指示该RP对Attester进行处理，例如：资源管理或Attester的网络接入控制等。

可以理解的是，用户可以通过Verifier或者RP查询该Attester的系统可信性。该Attester的系统可信性的验证结果，用于确定是否允许该Attester接入网络，即，Attester系统可信时该Attester可以接入网络的必要条件，在确定该Attester系统可信的情况下，该Attester才可以被允许接入网络。

需要说明的是，在步骤509之后，RP也可以将验证结果3发送给Attester，用于直接告知该Attester是否系统可信。

可见，通过在包括Attester、RP、Verifier和MASA的场景中，已知Attester、RP和Verifier身份合法的条件下，避免Attester系统可信性的度量信息被本身系统不可信的RP和Verifier获得，导致该Attester出现较大安全隐患的问题，通过MASA先对RP和Verifier进行系统可信性验证，在确定两者系统可信的条件下才将解密后的Attester的度量信息1发送给Verifier进行系统可信性验证，确保了Attester的远程证明环境的可信和安全，提高了Attester远程证明的可靠性，从而降低了该Attester的安全风险。

仍然对于包括Attester、RP、Verifier和MASA的网络，若该Attester、RP和Verifier的身份合法性未知，那么，本申请实施例还提供了另一种远程证明方法，参见图6，该方法具体可以包括下述步骤601～步骤612：

步骤601，Attester对其度量信息1进行加密，得到加密信息。

步骤602，Attester将加密信息和Attester的身份信息1发送给RP。

步骤603，RP基于身份信息1对Attester的身份合法性进行验证。

步骤604，若确定Attester的身份合法，则RP将加密信息、该RP的度量信息2和RP的身份信息2发送给Verifier。

步骤605，Verifier基于身份信息2对RP的身份合法性进行验证。

步骤606，若确定RP的身份合法，则Verifier向MASA发送请求消息，用于请求MASA验证Verifier和RP的系统可信性，其中，请求消息中携带加密信息、度量信息2、Verifier的度量信息3和Verifier的身份信息3。

步骤607，MASA基于身份信息3对Verifier的身份合法性进行验证。

步骤608，若确定Verifier的身份合法，则MASA基于度量信息2和度量信息3分别对RP和Verifier进行系统可信性验证，获得验证结果1和验证结果2。

步骤609，当验证结果1和验证结果2分别表示RP和Verifier系统可信时，MASA对加密信息进行解密，获得度量信息1。

步骤610，MASA将度量信息1携带在响应消息中发送给Verifier。

步骤611，Verifier基于度量信息1，对Attester进行系统可信性验证，获得验证结果3。

步骤612，Verifier将验证结果3发送给RP。

可以理解的是，身份信息1，是指用于验证Attester身份合法性的相关信息；身份信息2，是指用于验证RP身份合法性的相关信息；身份信息3，是指用于验证Verifier身份合法性的相关信息。Attester身份合法性可以由RP验证，RP身份合法性可以由Verifier验证，Verifier身份合法性可以由MASA验证。或者，Attester、RP和Verifier身份合法性验证也可以统一由MASA执行。

需要说明的是，上述步骤601～步骤612中，加密信息、度量信息和加密信息、以及验证结果，系统可信性验证等的具体实现以及相关描述，可以参见图5所示实施例的相关说明。

可见，通过在包括Attester、RP、Verifier和MASA的场景中，避免Attester系统可信性的度量信息被本身系统不可信或身份不合法的RP和Verifier获得，导致该Attester出现较大安全隐患的问题，先通过对Attester、RP和Verifier的身份合法性验证，以及MASA对RP和Verifier进行系统可信性验证，在验证均通过后才将解密后的Attester的度量信息1发送给Verifier进行系统可信性验证，确保了Attester的远程证明环境的可信和安全，提高了Attester远程证明的可靠性，从而降低了该Attester的安全风险。

若待远程证明的网络中，若RP和Verifier被部署于同一设备中，或者Attester直接和Verifier进行交互，那么，参见图7，本申请实施例还提供了另一种远程证明方法，该图7中的Verifier基于网络的实际架构，既可以是指部署上述实施例中RP和Verifier功能的设备，也可以是指和Attester直接交互的Verifier。该方法中假设Verifier和Attester身份合法，具体可以包括下述步骤701～步骤707：

步骤701，Attester对其度量信息1进行加密，得到加密信息。

步骤702，Attester将加密信息发送给Verifier。

步骤703，Verifier将加密信息、该Verifier的度量信息3携带在请求消息中发送给MASA。

步骤704，MASA基于度量信息3对Verifier进行系统可信性验证，获得验证结果2。

步骤705，当验证结果2表示Verifier系统可信时，MASA对加密信息进行解密，获得度量信息1。

步骤706，MASA将度量信息1携带在响应消息中发送给Verifier。

步骤707，Verifier基于度量信息1，对Attester进行系统可信性验证，获得验证结果3。

需要说明的是，上述步骤701～步骤707中，加密信息、度量信息和加密信息、以及验证结果，系统可信性验证等的具体实现以及相关描述，可以参见图5所示实施例的相关说明。

需要说明的是，本申请实施例中假设已知Verifier和Attester身份合法，当不确定两者身份是否合法时，具体实现方式以及相关描述，可以参见图6所示实施例的相关描述，在此不再赘述。

可见，通过在包括Attester、Verifier和MASA的场景中，避免Attester系统可信性的度量信息被本身系统不可信或身份不合法的Verifier获得，导致该Attester出现较大安全隐患的问题，通过MASA先对Verifier进行系统可信性验证，在验证均通过后才将解密后的Attester的度量信息1发送给Verifier进行系统可信性验证，确保了Attester的远程证明环境的可信和安全，提高了Attester远程证明的可靠性，从而降低了该Attester的安全风险。

若待远程证明的网络中，若MASA和Verifier被部署于同一设备中，该设备记作MASA&Verifier，那么，参见图8，本申请实施例还提供了另一种远程证明方法。该方法中假设RP和Attester身份合法，具体可以包括下述步骤801～步骤807：

步骤801，Attester对其度量信息1进行加密，得到加密信息。

步骤802，Attester将加密信息发送给RP。

步骤803，Verifier将加密信息、该RP的度量信息2携带在请求消息中发送给MASA&Verifier。

步骤804，MASA&Verifier基于度量信息2对RP进行系统可信性验证，获得验证结果1。

步骤805，当验证结果1表示RP系统可信时，MASA&Verifier对加密信息进行解密，获得度量信息1。

步骤806，MASA&Verifier基于度量信息1，对Attester进行系统可信性验证，获得验证结果3。

步骤807，MASA&Verifier将验证结果3携带在响应消息中发送给RP。

需要说明的是，上述步骤801～步骤807中，加密信息、度量信息和加密信息、以及验证结果，系统可信性验证等的具体实现以及相关描述，可以参见图5所示实施例的相关说明。

需要说明的是，本申请实施例中假设已知RP和Attester身份合法，当不确定两者身份是否合法时，具体实现方式以及相关描述，可以参见图6所示实施例的相关描述，在此不再赘述。

可见，通过在包括Attester、RP和MASA&Verifier三个网络设备的场景中，避免Attester系统可信性的度量信息被本身系统不可信或身份不合法的RP获得，导致该Attester出现较大安全隐患的问题，通过MASA&Verifier先对RP进行系统可信性验证，在验证均通过后才将解密后的Attester的度量信息1发送给Verifier进行系统可信性验证，确保了Attester的远程证明环境的可信和安全，提高了Attester远程证明的可靠性，从而降低了该Attester的安全风险。

在另一些具体的实现方式中，通过MASA上保存有RP和Verifier的系统可信性验证结果，在Attester向外发送度量信息1之前，先向MASA查询RP和Verifier的系统可信性验证结果，在确定RP和Verifier均系统可信的情况下，该Attester才将度量信息1发送给Verifier，由Verifier基于该度量信息1对Attester进行系统可信性验证，确保了Attester的远程证明环境的可信和安全，提高了Attester远程证明的可靠性，从而降低了该Attester的安全风险。具体实现方式可以参见下述图9～图12的实施例。

图9为本申请实施例中另一种远程证明方法的信令流程图。参见图9，该方法应用于包括Attester、RP、Verifier和MASA的网络中，且已知该Attester、RP和Verifier身份合法。该方法具体可以包括下述步骤901～步骤906：

步骤901，Attester向MASA发送查询请求消息，用于向MASA查询Verifier和RP的系统可信性。

可以理解的是，在Attester还没有入网之前，MASA可以先对RP和Verifier进行系统可信性验证，并记录验证结果。作为一个示例，可以在步骤901之前，由MASA分别发起对RP和Verifier的系统可信性验证，RP将度量信息2发送给MASA，MASA基于度量信息2对RP进行系统可信性验证，获得并记录验证结果2；同理，Verifier将度量信息3发送给MASA，MASA基于度量信息3对Verifier进行系统可信性验证，获得并记录验证结果3。作为另一个示例，可以在步骤901之前，由RP主动将度量信息2发送给MASA，MASA基于度量信息2对RP进行系统可信性验证，获得并记录验证结果2；同理，Verifier主动将度量信息3发送给MASA，MASA基于度量信息3对Verifier进行系统可信性验证，获得并记录验证结果3。这样，为Attester查询RP和Verifier的系统可信性提供了数据基础。

具体实现时，当Attester需要入网时，可以直接向MASA查询RP和Verifier的系统可信性；或者，当RP向Attester发起远程证明时，即，当Attester接收到RP发送的远程证明请求消息时，该Attester向MASA查询RP和Verifier的系统可信性。

当MASA接收到该查询请求消息后，按照该查询请求消息的指示，查询其上保存的RP和Verifier的系统可信性验证的验证结果。作为一个示例，MASA可以直接将RP的验证结果2和Verifier的验证结果3直接作为查询结果；作为另一个示例，MASA查询RP的验证结果2和Verifier的验证结果3，对各验证结果进行分析，将分析确定的系统可信性的结论作为查询结果，例如：将“RP-系统可信”作为查询结果。

步骤902，MASA向Attester返回携带查询结果的查询反馈消息。

步骤903，当Attester接收到的查询结果表示RP和Verifier系统可信时，Attester将度量信息1发送给RP。

步骤904，RP将度量信息1发送给Verifier。

具体实现时，当Attester接收到MASA反馈的查询反馈消息时，通过解析可以获得查询结果，一种情况下，该查询结果包括验证结果1和验证结果32，那么，Attester可以对验证结果1进行分析，确定RP是否系统可信，并且可以对验证结果2进行分析，确定Verifier是否系统可信。另一种情况下，该查询结果可以包括RP和Verifier的系统可信性的结论，那么，Attester可以直接从查询结果中确定RP和Verifier是否系统可信。当Verifier和RP均为系统可信时，该Attester确定其远程证明环境安全，此时，可以将其度量信息1经过RP发送给Verifier。一旦Verifier和RP中的至少一个存在系统不可信，则，该Attester确定其远程证明环境不安全，从而不利用RP和Verifier进行远程证明。

可以理解的是，度量信息1可以被携带在远程证明请求中发送给Verifier，或者，当步骤901之前由RP向Attester发起远程证明请求，那么，该度量信息1可以被携带在远程证明响应消息中发送给Verifier。

步骤905，Verifier基于度量信息1，对Attester进行系统可信性验证，获得验证结果3。

步骤906，Verifier将验证结果3发送给RP。

作为一个示例，Verifier可以将验证结果3携带在远程证明响应消息中，发送给RP，可以指示该RP对Attester进行处理，例如：资源管理或Attester的网络接入控制等。

可以理解的是，用户可以通过Verifier或者RP查询该Attester的系统可信性。或者，在步骤906之后，RP也可以将验证结果3发送给Attester，用于直接告知该Attester是否系统可信。

需要说明的是，本申请实施例步骤901～步骤906中的具体实现方式以及相关说明，可以参见图5所示实施例的相关描述。

可见，通过在包括Attester、RP、Verifier和MASA的场景中，已知Attester、RP和Verifier身份合法的条件下，避免Attester系统可信性的度量信息被本身系统不可信的RP和Verifier获得，导致该Attester出现较大安全隐患的问题，通过Attester先向MASA查询RP和Verifier的系统可信性，在确定两者系统可信的情况下，才将自身的度量信息1发送给Verifier进行系统可信性验证，确保了Attester的远程证明环境的可信和安全，提高了Attester远程证明的可靠性，从而降低了该Attester的安全风险。

仍然对于包括Attester、RP、Verifier和MASA的网络，若该Attester、RP和Verifier的身份合法性未知，那么，本申请实施例还提供了另一种远程证明方法，参见图10，该方法具体可以包括下述步骤1001～步骤1006：

步骤1001，Attester向MASA发送查询请求消息，用于向MASA查询Verifier和RP的系统可信性，以及Attester、RP和Verifier的身份合法性。

可以理解的是，在Attester还没有入网之前，MASA可以先对RP和Verifier进行系统可信性验证，并对Attester、RP和Verifier进行身份合法性验证。身份合法性验证，作为一个示例，可以在步骤901之前，由MASA分别发起对Attester、RP和Verifier的身份合法性验证，Attester将身份信息1发送给MASA，MASA基于身份信息1对Attester进行身份合法性验证，并记录是否合法；同理，RP将身份信息2发送给MASA，MASA基于身份信息2对RP进行身份合法性验证，并记录是否合法；Verifier将身份信息3发送给MASA，MASA基于身份信息3对Verifier进行身份合法性验证，并记录是否合法。作为另一个示例，可以在步骤901之前，由Attester、RP和Verifier主动将其对应的身份信息发送给MASA，MASA基于身份信息对各设备进行身份合法性验证，并记录是否合法。需要说明的是，系统可信性验证可以参见步骤601的相关描述。这样，为Attester查询RP和Verifier的系统可信性以及Attester、RP和Verifier身份合法性提供了数据基础。

步骤1002，MASA向Attester返回携带查询结果的查询反馈消息。

可以理解的是，该查询结果包括RP和Verifier的系统可信性验证结果以及Attester、RP和Verifier身份合法性验证结果。

步骤1003，当Attester接收到的查询结果表示RP和Verifier系统可信且Attester、RP和Verifier身份合法时，Attester将度量信息1发送给RP。

步骤1004，RP将度量信息1发送给Verifier。

步骤1005，Verifier基于度量信息1，对Attester进行系统可信性验证，获得验证结果3。

步骤1006，Verifier将验证结果3发送给RP。

需要说明的是，上述步骤1001～步骤1006中，度量信息、身份信息、验证结果以及系统可信性验证等的具体实现以及相关描述，可以参见图9和图6所示实施例的相关说明。

可见，通过在包括Attester、RP、Verifier和MASA的场景中，避免Attester系统可信性的度量信息被本身系统不可信或身份不合法的RP和Verifier获得，导致该Attester出现较大安全隐患的问题，通过先对Attester、RP和Verifier的身份合法性以及RP和Verifier的系统可信性的查询，在确定均为系统可信且身份合法后，Attester才将度量信息1发送给Verifier进行系统可信性验证，确保了Attester的远程证明环境的可信和安全，提高了Attester远程证明的可靠性，从而降低了该Attester的安全风险。

若待远程证明的网络中，若RP和Verifier被部署于同一设备中，或者Attester直接和Verifier进行交互，那么，参见图11，本申请实施例还提供了另一种远程证明方法，该图11中的Verifier基于网络的实际架构，既可以是指部署上述实施例中RP和Verifier功能的设备，也可以是指和Attester直接交互的Verifier。该方法中假设Verifier和Attester身份合法，具体可以包括下述步骤1101～步骤1104：

步骤1101，Attester向MASA发送查询请求消息，用于向MASA查询Verifier的系统可信性。

步骤1102，MASA向Attester返回携带查询结果的查询反馈消息。

可以理解的是，该查询结果包括Verifier的系统可信性验证结果。

步骤1103，当Attester接收到的查询结果表示Verifier系统可信时，Attester将度量信息1发送给Verifier。

步骤1104，Verifier基于度量信息1，对Attester进行系统可信性验证，获得验证结果3。

需要说明的是，上述步骤1101～步骤1104中，度量信息、验证结果以及系统可信性验证等的具体实现以及相关描述，可以参见图7和图9所示实施例的相关说明。

需要说明的是，本申请实施例中假设已知Verifier和Attester身份合法，当不确定两者身份是否合法时，具体实现方式以及相关描述，可以参见图10所示实施例的相关描述，在此不再赘述。

可见，通过在包括Attester、Verifier和MASA的场景中，避免Attester系统可信性的度量信息被本身系统不可信的Verifier获得，导致该Attester出现较大安全隐患的问题，通过Attester先向MASA查询Verifier的系统可信性，在确定Verifier系统可信后才Attester才将度量信息1发送给Verifier进行系统可信性验证，确保了Attester的远程证明环境的可信和安全，提高了Attester远程证明的可靠性，从而降低了该Attester的安全风险。

若待远程证明的网络中，若MASA和Verifier被部署于同一设备中，该设备记作MASA&Verifier，那么，参见图12，本申请实施例还提供了另一种远程证明方法。该方法中假设RP和Attester身份合法，具体可以包括下述步骤1201～步骤1206：

步骤1201，Attester向MASA&Verifier发送查询请求消息，用于向MASA查询RP的系统可信性。

步骤1202，MASA&Verifier向Attester返回携带查询结果的查询反馈消息。

可以理解的是，该查询结果包括RP的系统可信性验证结果。

步骤1203，当Attester接收到的查询结果表示RP系统可信时，Attester将度量信息1发送给RP。

步骤1204，RP将度量信息1发送给MASA&Verifier。

步骤1205，MASA&Verifier基于度量信息1，对Attester进行系统可信性验证，获得验证结果3。

步骤1206，MASA&Verifier将验证结果3发送给RP。

需要说明的是，上述步骤1201～步骤1206中，度量信息、验证结果，系统可信性验证等的具体实现以及相关描述，可以参见图8和图9所示实施例的相关说明。

需要说明的是，本申请实施例中假设已知RP和Attester身份合法，当不确定两者身份是否合法时，具体实现方式以及相关描述，可以参见图10所示实施例的相关描述，在此不再赘述。

可见，通过在包括Attester、RP和MASA&Verifier三个网络设备的场景中，避免Attester系统可信性的度量信息被本身系统不可信的RP获得，导致该Attester出现较大安全隐患的问题，通过MASA&Verifier先对RP进行系统可信性验证，在验证均通过后才将解密后的Attester的度量信息1发送给Verifier进行系统可信性验证，确保了Attester的远程证明环境的可信和安全，提高了Attester远程证明的可靠性，从而降低了该Attester的安全风险。

在上述图4所示的场景的基础上，结合图13～图15，介绍本申请实施例提供的远程证明方法结合在BRSKI协议框架下的几种具体实现。Attester首次接入网络前，至少需要满足要求：基于BRSKI协议的身份合法性验证通过；远程证明网络设备的系统可信。该实现在对BRSKI协议的影响较小的情况下，完成较为安全的远程证明。

具体实现时，如图13所示，该实施例中，RP和注册设备Register部署于同一设备中，该设备记作RP&Register本实施例可以包括：

步骤1301，Attester首次入网，执行BRSKI协议流程。

步骤1302，按照BRSKI协议的流程，Attester自动发现Register，并用自身的IDevID证书进行入网认证，以及执行注册enrollment流程。

步骤1303，RP&Register向Attester发送远程证明请求消息。

步骤1304，Attester使用自身的IDevID对应的公钥对度量信息1进行加密，得到加密信息。

步骤1305，Attester向RP&Register发送携带加密信息和Attester的IDevID证书的远程证明响应消息。

其中，上述步骤1303～步骤1305为扩展的BRSKI协议对应的步骤。

步骤1306，RP&Register向MASA验证RP&Register的证书。

步骤1307，MASA向RP&Register返回授权结果的凭证Voucher，以及审计日志等信息。

步骤1308，RP&Register转发Voucher等信息给Attester，以便Attester根据此信息验证RP&Register的身份合法性。

其中，步骤1306～步骤1309具体可以是BRSKI过程中验证RP&Register身份合法性的过程。

步骤1309，RP&Register将加密信息和该RP&Register的度量信息2发送给Verifier。

可以理解的是，步骤1309具体可以是采用RATS协议转发的。

步骤1310，Verifier将加密信息、度量信息2、Verifier的度量信息3以及该Verifier的身份证书携带在请求消息中发送给MASA。

步骤1311，MASA基于度量信息2、Verifier的度量信息3分别对RP&Register和Verifier的系统可信性进行验证，并且对Verifier的身份合法性进行验证。

步骤1312，当确定RP&Register和Verifier的系统可信且Verifier的身份合法时，MASA将加密信息进行解密，获得度量信息1。

步骤1313，MASA将度量信息1携带在响应消息中发送给Verifier。

步骤1314，Verifier基于度量信息1对Attester进行系统可信性验证，获得验证结果。

步骤1315，Verifier将Attester系统可信性的验证结果发送给RP&Register。

步骤1316，RP&Register将Attester、RP&Register和Verifier的身份合法性验证结果，以及Attester、RP&Register和Verifier的系统可信性验证结果，发送给Attester。

需要说明的是，执行完上述远程证明后，Attester可以确定Verifier和RP&Register是系统可信且身份合法的设备，那么，在后续有远程证明需求时，可以直接将度量信息通过RP&Register发送给Verifier，由Verifier进行快速和安全的对Attester的系统可信性的验证。

需要说明的是，在一些实现方式中，由于在步骤1316中Attester接收到了RP&Register的身份合法性验证结果和系统可信性验证结果，那么，为了节约网络资源和简化验证程序，可以不执行原有BRSKI程序中的上述步骤1306～步骤1309对应的验证RP&Register身份合法性的过程。

需要说明的是，上述步骤1306～步骤1309和步骤1310～步骤1316的执行，没有先后顺序。通常情况下，按照上述顺序依次执行，但是，为了节约网络资源，先进行基于BRSKI协议的身份合法性验证，在通过时，才执行远程证明网络设备的系统可信验证；在未通过时，可以不进行远程证明，直接阻止网络设备入网。另一些情况下，还可以先执行远程证明网络设备的系统可信验证，在验证结果表示该网络设备的系统可信时，才执行基于BRSKI协议的身份合法性验证；在不可信时，可以不进行基于BRSKI协议的身份合法性验证，直接阻止网络设备入网。又一些情况下，也可以同时执行基于BRSKI协议的身份合法性验证和远程证明网络设备的系统可信验证，当两者同时验证通过时，才允许该网络设备入网。

需要说明的是，上述步骤1310～步骤1316对应Attester远程证明的过程，具体实现可以参见本申请中图5～图12对应实施例的相关描述。

可见，本实施例将远程证明的方法结合到BRSKI协议流程中，展示了Attester首次接入网络的具体过程，利用本申请实施例提供的远程证明的方法，可以使得对Attester的远程证明更加准确，从而提高了Attester首次入网的可靠性。

具体实现时，对于RP和Verifier被部署于同一设备中，或者Attester直接和Verifier进行交互的情况，那么，参见图14，该图14中的Verifier基于网络的实际架构，既可以是指部署上述实施例中RP和Verifier功能的设备，也可以是指和Attester直接交互的Verifier；该Verifier和注册设备Register部署于同一设备中，该设备记作Verifier&Register。

如图14所示，本申请实施例还提供了另一种远程证明方法，该方法中假设Verifier和Attester身份合法，具体可以包括：

步骤1401，Attester首次入网，执行BRSKI协议流程。

步骤1402，按照BRSKI协议的流程，Attester自动发现Register，并用自身的IDevID证书进行入网认证，以及执行注册enrollment流程。

步骤1403，Verifier&Register向Attester发送远程证明请求消息。

步骤1404，Attester使用自身的IDevID对应的公钥对度量信息1进行加密，得到加密信息。

步骤1405，Attester向Verifier&Register发送携带加密信息和Attester的IDevID证书的远程证明响应消息。

其中，上述步骤1403～步骤1405为扩展的BRSKI协议对应的步骤。

步骤1406，Verifier&Register向MASA验证Verifier&Register的证书。

步骤1407，MASA向Verifier&Register返回授权结果的凭证Voucher，以及审计日志等信息。

步骤1408，Verifier&Register转发Voucher等信息给Attester，以便Attester根据此信息验证Verifier&Register的身份合法性。

其中，步骤1406～步骤1408具体可以是BRSKI过程中验证Verifier&Register身份合法性的过程。

步骤1409，Verifier&Register将加密信息、该Verifier&Register的度量信息3和Verifier&Register的身份证书携带在请求消息中发送给MASA。

步骤1410，MASA基于度量信息3对Verifier&Register的系统可信性进行验证，并且对Verifier&Register的身份合法性进行验证。

步骤1411，当确定Verifier&Register的系统可信且身份合法时，MASA将加密信息进行解密，获得度量信息1。

步骤1412，MASA将度量信息1携带在响应消息中发送给Verifier&Register。

步骤1413，Verifier&Register基于度量信息1对Attester进行系统可信性验证，获得验证结果。

步骤1414，Verifier&Register将Attester和Verifier&Register的身份合法性验证结果，以及Attester和Verifier&Register的系统可信性验证结果，发送给Attester。

需要说明的是，执行完上述远程证明后，Attester可以确定Verifier&Register是系统可信且身份合法的设备，那么，在后续有远程证明需求时，可以直接将度量信息发送给Verifier&Register，由Verifier&Register进行快速和安全的对Attester的系统可信性的验证。

需要说明的是，在一些实现方式中，由于在步骤1414中Attester接收到了Verifier&Register的身份合法性验证结果和系统可信性验证结果，那么，为了节约网络资源和简化验证程序，可以不执行原有BRSKI程序中的上述步骤1406～步骤1408对应的验证Verifier&Register身份合法性的过程。

具体实现时，对于MASA和Verifier被部署于同一设备中，该设备记作MASA&Verifier的情况，那么，参见图15，本申请实施例还提供了另一种远程证明方法，具体可以包括：

步骤1501，Attester首次入网，执行BRSKI协议流程。

步骤1502，按照BRSKI协议的流程，Attester自动发现Register，并用自身的IDevID证书进行入网认证，以及执行注册enrollment流程。

步骤1503，RPr&Register向Attester发送远程证明请求消息。

步骤1504，Attester使用自身的IDevID对应的公钥对度量信息1进行加密，得到加密信息。

步骤1505，Attester向RPr&Register发送携带加密信息和Attester的IDevID证书的远程证明响应消息。

其中，上述步骤1503～步骤1505为扩展的BRSKI协议对应的步骤。

步骤1506，RP&Register向MASA&Verifier验证RP&Register的证书。

步骤1507，MASA&Verifier向RP&Register返回授权结果的凭证Voucher，以及审计日志等信息。

步骤1508，RP&Register转发Voucher等信息给Attester，以便Attester根据此信息验证RP&Register的身份合法性。

其中，步骤1506～步骤1508具体可以是BRSKI过程中验证Verifier&Register身份合法性的过程。

步骤1509，RP&Register将加密信息、该RP&Register的度量信息2携带在请求消息中发送给MASA&Verifier。

步骤1510，MASA&Verifier基于度量信息2对RP&Register的系统可信性进行验证。

步骤1511，当确定RP&Register的系统可信时，MASA&Verifier将加密信息进行解密，获得度量信息1。

步骤1512，MASA&Verifier基于度量信息1对Attester进行系统可信性验证，获得验证结果。

步骤1513，MASA&Verifier将Attester的系统可信性的验证结果发送给RP&Register。

步骤1514，RP&Register将Attester和RP&Register的身份合法性验证结果，以及Attester和RP&Register的系统可信性验证结果，发送给Attester。

需要说明的是，执行完上述远程证明后，Attester可以确定MASA&Verifier是系统可信且身份合法的设备，那么，在后续有远程证明需求时，可以直接将度量信息通过RP&Register发送给MASA&Verifier，由MASA&Verifier进行快速和安全的对Attester的系统可信性的验证。

图16为本申请实施例中的一种远程证明方法的流程示意图。参与远程证明的设备包括第一网络设备、第二网络设备和第三网络设备，以第一网络设备为执行主体，具体的远程证过程可以包括：

步骤1601，第一网络设备通过第二网络设备接收加密信息和第二网络设备的第一度量信息，该加密信息是对第三网络设备的第二度量信息进行加密得到的信息。

步骤1602，第一网络设备根据该第一度量信息，确定第二网络设备的系统可信。

步骤1603，第一网络设备对加密信息进行解密，得到第二度量信息。

需要说明的是，与上述图5～图8对应的实施例对应，该图16对应实施例中，一种情况下，第一网络设备可以是图5～图7对应实施例中的MASA，那么，第二网络设备可以是图5和图6对应实施例中的Verifier和RP，也可以是图7实施例中的RP和Verifier合二为一的设备(即，RP&Verifier)，第三网络设备可以是Attester；另一种情况下，该第一网络设备也可以是图8对应实施例中的MASA&Verifier，那么，第二网络设备可以是图7对应实施例中的RP，第三网络设备可以是Attester。该图16所示的实施例的相关实现方式可以分别对应上述图5～图8对应实施例的相关描述。

对应于第一网络设备为MASA，第二网络设备为Verifier的情况，该实施例还可以包括：第一网络设备向第二网络设备发送第二度量信息。这样，第二网络设备可以基于第二度量信息对第三网络设备的系统可信性进行验证。

对于第一网络设备为MASA&Verifier，第二网络设备为RP的情况，该实施例还可以包括：第一网络设备根据第二度量信息，验证第三网络设备的系统可信性，得到第一验证结果；第一网络设备向第二网络设备发送第一验证结果。这样，第一网络设备可以基于第二度量信息对第三网络设备的系统可信性进行验证，并将验证结果发送给第二网络设备，以便用户通过第二网络设备查看第三网络设备的系统可信性。

作为一个示例，本实施例还可以包括：第一网络设备向第二网络设备发送第二验证结果，该第二验证结果为第二网络设备的系统可信性的验证结果。

对于第一网络设备为MASA，第二网络设备为Verifier，第三网络设备为Attester，第四网络设备为RP的情况，该实施例中的步骤1601中第一网络设备通过第二网络设备接收加密信息，具体为：第一网络设备通过第二网络设备接收由第四网络设备发送的该加密信息；该实施例具体还可以包括：第一网络设备通过第二网络设备接收第四网络设备的第三度量信息；那么，在步骤1603之前，该方法还包括：第一网络设备根据第三度量信息，确定第四网络设备的系统可信。作为一个示例，该实施例还可以包括：第一网络设备向第二网络设备发送第三验证结果，该第三验证结果为第四网络设备的系统可信性的验证结果。相关说明，具体可以参见图5和图6对应实施例的相关描述。

在一些具体的实现方式中，本申请实施例还可以包括：第一网络设备接收第二网络设备发送的身份信息；在步骤1603之前，该方法还包括：第一网络设备根据身份信息，确定第二网络设备的身份合法。其中，该实施例还可以包括：第一网络设备向第二网络设备发送第四验证结果，该第四验证结果为第二网络设备的身份合法性的验证结果。相关说明，具体可以参见图6对应实施例的相关描述。

可以理解的是，该实施例中的第一验证结果，用于确定是否允许第三网络设备接入网络。

该实施例中，步骤1601具体为：第一网络设备接收第二网络设备发送的网络配置NETCONF协议的请求消息，请求消息中携带有加密信息和第一度量信息；而第一网络设备向第二网络设备发送第二度量信息，具体为：第一网络设备向第二网络设备发送NETCONF协议的响应消息，响应消息中携带有第二度量信息。其中，在请求消息中可以采用因特网工程任务组又一代数据模型IETF YANG Data Model格式对加密信息和第一度量信息进行描述；在响应消息中也可以采用IETF YANG Data Model格式对第一度量信息进行描述。

或者，该实施例中，步骤1601具体也可以为：第一网络设备接收第二网络设备发送的网络配置NETCONF协议的请求消息，请求消息中携带有加密信息和第一度量信息；而第一网络设备向第二网络设备发送第一验证结果，具体为：第一网络设备向第二网络设备发送NETCONF协议的响应消息，响应消息中携带有第一验证结果。

图17为本申请实施例中的一种远程证明方法的流程示意图。参与远程证明的设备包括第一网络设备、第二网络设备和第三网络设备，以第一网络设备为执行主体，具体的远程证过程可以包括：

步骤1701，第一网络设备接收第二网络设备发送的加密信息，加密信息是对第二网络设备的第一度量信息进行加密得到的信息；

步骤1702，第一网络设备向第三网络设备发送加密信息和第一网络设备的第二度量信息；

步骤1703，第一网络设备接收第三网络设备发送的指示信息；

步骤1704，第一网络设备根据该指示信息确定第二网络设备的系统可信性。

需要说明的是，与上述图5～图8对应的实施例对应，该图17对应实施例中，第一网络设备可以是RP、Verifier或RP和Verifier合一的设备(即，RP&Verifier)，那么，第二网络设备可以是Attester，第三网络设备可以是Verifier、MASA或MASA和Verifier合一的设备(即，MASA&Verifier)。该图17所示的实施例的相关实现方式可以分别对应上述图5～图8对应实施例的相关描述。

一种情况下，对于第一网络设备为RP的情况，该指示信息可以为第二网络设备的系统可信性的验证结果。

另一种情况下，对于第一网络设备为Verifier的情况，该指示信息还可以为第一度量信息；那么，步骤1704中根据指示信息确定第二网络设备的系统可信性，具体为：第一网络设备根据第一度量信息，验证第二网络设备的系统可信性。

对应于图5所示的实施例，步骤1701具体为：第一网络设备通过第四网络设备接收第二网络设备发送的加密信息；该实施例还可以包括：第一网络设备接收第四网络设备发送的该第四网络设备的第三度量信息；从而，第一网络设备向第三网络设备发送第三度量信息；其中，第三度量信息用于验证第四网络设备的系统可信性，加密信息用于在确定第一网络设备系统可信且第四网络设备系统可信的情况下被解密成第一度量信息。

可以理解的是，该实施例还可以包括：第一网络设备向第二网络设备发送第一验证结果，该第一验证结果为第二网络设备的系统可信性的验证结果。

可以理解的是，该实施例还可以包括：第一网络设备接收第三网络设备发送的第二验证结果，该第二验证结果为第一网络设备的系统可信性的验证结果。其中，该实施例中还可以包括：第一网络设备向第二网络设备发送该第二验证结果，这样，第二网络设备即可知晓第一网络设备的系统可信性，方便后续远程证明。

可以理解的是，该实施例还可以包括：第一网络设备接收所述第三网络设备发送的第三验证结果，该第三验证结果为第四网络设备的系统可信性的验证结果。那么，该实施例中还包括：第一网络设备向第二网络设备发送第三验证结果，具体为，第一网络设备向第四网络设备发送该第三验证结果，再由第四网络设备向第二网络设备发送给第三验证结果。

与图6对应实施例提供的方法对应，该实施例还可以包括：第一网络设备接收第二网络设备发送的第一身份信息；那么，步骤1702之前，该方法还包括：第一网络设备根据第一身份信息，确定第二网络设备的身份合法性。其中，第一网络设备还可以向第二网络设备发送第四验证结果，该第四验证结果为第二网络设备的身份合法性的验证结果。

作为一个示例，该实施例还可以包括：第一网络设备接收第四网络设备发送的第二身份信息；那么，步骤1702之前，该方法还包括：第一网络设备根据第二身份信息，确定第四网络设备的身份合法。其中，第一网络设备还可以向第四网络设备发送第五验证结果，该第五验证结果为第四网络设备的身份合法性的验证结果。

作为另一个示例，该实施例还可以包括：第一网络设备向第三网络设备发送第一网络设备的第三身份信息。其中，第一网络设备还可以接收第三网络设备发送的第六验证结果，该第六验证结果为第一网络设备的身份合法性的验证结果。该实施例中第一网络设备还可以向第二网络设备发送第六验证结果。

其中，该实施例还可以包括：第一网络设备向第四网络设备发送第一网络设备的第三身份信息，第三身份信息用于验证第一网络设备的身份合法性。

可以理解的是，该实施例中，第一网络设备还可以根据第二网络设备的系统可信性，用于确定是否允许该第二网络设备接入网络。

该实施例中，步骤1702，具体为：第一网络设备向第三网络设备发送的网络配置NETCONF协议的请求消息，请求消息中携带有加密信息和第二度量信息；步骤1703中第一网络设备接收第三网络设备发送的指示信息，具体为：第一网络设备接收第三网络设备发送的NETCONF协议的响应消息，响应消息中携带有指示信息。其中，在请求消息中可以采用因特网工程任务组又一代数据模型IETF YANG Data Model格式对加密信息和第二度量信息进行描述；在响应消息中也可以采用IETF YANG Data Model格式对指示信息进行描述。

图18为本申请实施例中的一种远程证明方法的流程示意图。参与远程证明的设备包括第一网络设备和第二网络设备，以第一网络设备为执行主体，具体的远程证过程可以包括：

步骤1801，第一网络设备生成加密信息，加密信息是对第一网络设备的度量信息进行加密得到的信息。

步骤1802，第一网络设备向第二网络设备发送加密信息；其中，度量信息用于验证第一网络设备的系统可信性，从而得到验证结果。

需要说明的是，与上述图5～图8对应的实施例对应，该图18对应实施例中，第一网络设备可以是Attester，那么，第二网络设备可以是Verifier、RP或RP和Verifier合一的设备(即，RP&Verifier)。该图18所示的实施例的相关实现方式可以分别对应上述图5～图8对应实施例的相关描述。

作为一个示例，该实施例还可以包括：第一网络设备接收第二网络设备发送的验证结果，该验证结果为第一网络设备的系统可信性的验证结果。

作为另一个示例，该实施例还可以包括：第一网络设备接收第二网络设备发送的该第二网络设备系统可信性的验证结果。

可以理解的是，该实施例中，第一网络设备还可以向第二网络设备发送第一网络设备的身份信息，身份信息用于验证第一网络设备的身份合法性。从而，本实施例还可以包括：第一网络设备接收第二网络设备发送的第一网络设备身份合法性的验证结果；还可以包括：第一网络设备接收第二网络设备发送的第二网络设备身份合法性的验证结果。

可以理解的是，第一网络设备的系统可信性的验证结果，用于确定是否允许第一网络设备接入网络。

需要说明的是，上述图16～图18所示的实施例，分别对应于MASA、RP或Verifier、Attester侧执行本申请实施例提供的远程证明方法，具体的实现方式、达到的效果以及相关概念说明，可以参见图5～图8所示实施例的相关描述。

图19为本申请实施例中另一种远程证明方法的流程示意图。该方法以第一网络设备为执行主体，具体的远程证明过程可以包括：

步骤1901，第一网络设备向第二网络设备查询第三网络设备的系统可信性；

步骤1902，第一网络设备确定第三网络设备系统可信；

步骤1903，第一网络设备向第三网络设备发送第一网络设备的度量信息；其中，度量信息用于验证第一网络设备的系统可信性，从而得到验证结果。

需要说明的是，与上述图9～图12对应的实施例对应，该图19对应实施例中，第一网络设备可以是Attester，第二网络设备为MASA，那么，第三网络设备可以是Verifier、RP或RP和Verifier合一的设备(即，RP&Verifier)。该图19所示的实施例的相关实现方式可以分别对应上述图9～图12对应实施例的相关描述。

作为一个示例，该实施例在第一网络设备向第三网络设备发送第一网络设备的度量信息之前，还可以包括：第一网络设备向第二网络设备查询第四网络设备的系统可信性；第一网络设备确定第四网络设备系统可信；其中，第三网络设备用于将接收到的度量信息向第四网络设备发送，第四网络设备用于根据度量信息验证第一网络设备的系统可信性。

作为一个示例，该实施例在第一网络设备向第三网络设备发送第一网络设备的度量信息之前，还可以包括：第一网络设备向第二网络设备查询第三网络设备的身份合法性以及第四网络设备的身份合法性；第一网络设备确定第四网络设备身份合法。

其中，该实施例中的第一网络设备还可以接收第三网络设备发送的第一网络设备系统可信性的验证结果。

其中，该实施例中的第一网络设备还可以向第三网络设备发送第一网络设备的身份信息，该身份信息用于验证第一网络设备的身份合法性。

其中，该实施例中的第一网络设备还可以接收第三网络设备发送的第一网络设备身份合法性的验证结果。

图20为本申请实施例中另一种远程证明方法的流程示意图，该方法以第一网络设备为执行主体，具体的远程证明过程可以包括：

步骤2001，第一网络设备向第二网络设备发送第一网络设备的第一度量信息，第一度量信息用于验证第一网络设备的系统可信性并将第一网络设备的系统可信性的第一验证结果记录在第二网络设备中；

步骤2002，第一网络设备接收第三网络设备发送的第三网络设备的第二度量信息；其中，第二度量信息用于验证第三网络设备的系统可信性。

需要说明的是，与上述图9～图12对应的实施例对应，该图20对应实施例中，第一网络设备可以是RP、Verifier或RP和Verifier合一的设备(即，RP&Verifier)，那么，第二网络设备可以是MASA，第三网络设备可以是Attester。该图20所示的实施例的相关实现方式可以分别对应上述图9～图12对应实施例的相关描述。

作为一个示例，若第一网络设备为RP，第四网络设备为Verifier，那么，本实施例还可以包括：第一网络设备向第四网络设备发送第二度量信息。其中，第四网络设备与第二网络设备可以为相同的设备。那么，第一网络设备还可以根据第二度量信息，验证第三网络设备的系统可信性。

作为另一个示例，该实施例还可以包括：第一网络设备接收第四网络设备发送的第二验证结果，该第二验证结果为第二网络设备的系统可信性的验证结果。那么，该第一网络设备还可以向第三网络设备发送第三验证结果，该第三验证结果为第三网络设备的系统可信性的验证结果。

作为再一个示例，该实施例中还可以包括：第一网络设备接收第三网络设备发送的第一身份信息；第一网络设备根据第一身份信息，验证第三网络设备的身份合法性。那么，该第一网络设备还可以向第三网络设备发送第四验证结果，该第四验证结果为第三网络设备的身份合法性的验证结果。

作为又一个示例，该实施例中还可以包括：第一网络设备向第二网络设备发送第一网络设备的第二身份信息，第二身份信息用于验证第一网络设备的身份合法性并将第一网络设备的身份合法性的第二验证结果记录在第二网络设备中。

作为另一个示例，该实施例中还可以包括：第一网络设备根据第三网络设备的系统可信性的验证结果，确定是否允许第三网络设备接入网络。

图21为本申请实施例中另一种远程证明方法的流程示意图，该方法以第一网络设备为执行主体，具体的远程证明过程可以包括：

步骤2101，第一网络设备接收第二网络设备发送的第二网络设备的第一度量信息；

步骤2102，第一网络设备根据第一度量信息，验证第二网络设备的系统可信性，得到第一验证结果；

步骤2103，第一网络设备接收第三网络设备针对第二网络设备的系统可信性的验证结果的查询请求；

步骤2104，第一网络设备向第三网络设备发送第一验证结果。

需要说明的是，与上述图9～图12对应的实施例对应，该图21对应实施例中，一种情况下，第一网络设备可以是图9～图12对应实施例中的MASA，那么，第二网络设备可以是Verifier或RP，也可以是RP和Verifier合一的设备(即，RP&Verifier)，第三网络设备可以是Attester；另一种情况下，该第一网络设备也可以是MASA &Verifier，那么，第二网络设备可以是RP，第三网络设备可以是Attester。该图21所示的实施例的相关实现方式可以分别对应上述图9～图12对应实施例的相关描述。

作为一个示例，该实施例还可以包括：第一网络设备接收第四网络设备发送的第四网络设备的第二度量信息；第一网络设备根据第二度量信息，验证第四网络设备的系统可信性，得到第二验证结果；第一网络设备接收第三网络设备针对第四网络设备的系统可信性的验证结果的查询请求；第一网络设备向第三网络设备发送第二验证结果；其中，第二网络设备用于接收第三网络设备发送的第三网络设备的第三度量信息并向第四网络设备发送第三度量信息，第四网络设备用于根据第三度量信息验证第三网络设备的系统可信性，从而得到第五验证结果。

作为另一个示例，该实施例还可以包括：第一网络设备接收第二网络设备发送的第二网络设备的第一身份信息和第四网络设备发送的第四网络设备的第二身份信息；第一网络设备根据第一身份信息，验证第二网络设备的系统可信性，得到第三验证结果，以及，根据第二身份信息，验证第四网络设备的系统可信性，得到第四验证结果；第一网络设备接收第三网络设备针对第二网络设备的身份合法性的验证结果的查询请求和第三网络设备针对第四网络设备的身份合法性的验证结果的查询请求；第一网络设备向第三网络设备发送第三验证结果和第四验证结果。

作为再一个示例，该实施例还可以包括：第一网络设备接收第三网络设备经第二网络设备发送的第三网络设备的第三度量信息；第一网络设备根据第三度量信息，验证第三网络设备的系统可信性；第一网络设备向第三网络设备发送第五验证结果，第五验证结果为第三网络设备的系统可信性的验证结果。

可以理解的是，第三网络设备的系统可信性的验证结果，即，第五验证结果，用于确定是否允许第三网络设备接入网络。

需要说明的是，上述图19～图21所示的实施例，分别对应于MASA、RP或Verifier、Attester侧执行本申请实施例提供的远程证明方法，具体的实现方式、达到的效果以及相关概念说明，可以参见图9～图12所示实施例的相关描述。

图22示出了本申请实施例提供的一种远程证明装置的结构示意图。该装置2200包括：接收单元2201和处理单元2202。

其中，接收单元2201，用于通过第二网络设备接收加密信息和第二网络设备的第一度量信息，加密信息是对第三网络设备的第二度量信息进行加密得到的信息；

处理单元2202，用于根据第一度量信息，确定第二网络设备系统可信，并对加密信息进行解密，得到第二度量信息。

在一种具体实现方式中，该装置2200还包括：发送单元。该发送单元，用于向第二网络设备发送第二度量信息。

作为一个示例，接收单元2201，具体用于：接收第二网络设备发送的网络配置NETCONF协议的请求消息，请求消息中携带有加密信息和第一度量信息；发送单元，具体用于：向第二网络设备发送NETCONF协议的响应消息，响应消息中携带有第二度量信息。其中，在请求消息中采用因特网工程任务组又一代数据模型IETF YANG Data Model格式对加密信息和第一度量信息进行描述；在响应消息中采用IETF YANG Data Model格式对第一度量信息进行描述。

在另一种具体实现方式中，该处理单元2202，还用于根据第二度量信息，验证第三网络设备的系统可信性，得到第一验证结果；发送单元，还用于向第二网络设备发送第一验证结果。

作为一个示例，该接收单元2201，具体用于：接收第二网络设备发送的网络配置NETCONF协议的请求消息，请求消息中携带有加密信息和第一度量信息；发送单元，具体用于：第一网络设备向第二网络设备发送NETCONF协议的响应消息，响应消息中携带有第一验证结果。其中，在请求消息中采用因特网工程任务组又一代数据模型IETF YANG DataModel格式对加密信息和第一度量信息进行描述；在响应消息中采用IETF YANG DataModel格式对第一验证结果进行描述。

在再一种具体实现方式，该接收单元2201，具体用于：通过第二网络设备接收由第四网络设备发送的加密信息；那么，接收单元2201，还用于通过第二网络设备接收第四网络设备的第三度量信息；处理单元2202，还用于在第一网络设备对加密信息进行解密之前，根据第三度量信息，确定第四网络设备的系统可信性。

在另一种具体实现方式中，该接收单元2201，还用于接收第二网络设备发送的身份信息；那么，处理单元2202，还用于在第一网络设备对加密信息进行解密之前，确定第二网络设备身份合法。

可以理解的是，该装置2200中的接收单元2201，可以用于执行图16对应实施例中的接收操作对应的步骤，例如：步骤1601；处理单元2202，可以用于执行图16对应实施例中的确定、解密等操作对应的步骤，例如：步骤1602和步骤1603。

需要说明的是，该装置2200可以对应图5～图7所示方法实施例中的MASA，图8所示实施例中的MASA&Verifier，或者图16所示的方法实施例中的第一网络设备，故该装置2200的各种可能的实现方式以及达到的技术效果，可以参照前述图5～图8以及图16所示的实施例提供的方法的介绍。

图23示出了本申请实施例提供的另一种远程证明装置2300的结构示意图。该装置2300，包括：接收单元2301、发送单元2302和处理单元2303。

其中，接收单元2301，用于接收第二网络设备发送的加密信息，加密信息是对第二网络设备的第一度量信息进行加密得到的信息；

发送单元2302，用于向第三网络设备发送加密信息和第一网络设备的第二度量信息；

接收单元2301，还用于接收第三网络设备发送的指示信息；

处理单元2303，用于根据指示信息确定第二网络设备的系统可信性。

另一种情况下，该指示信息为第一度量信息；那么，该处理单元2303，具体用于：根据第一度量信息，验证第二网络设备的系统可信性。

作为一个示例，该发送单元2302，具体用于：向第三网络设备发送的网络配置NETCONF协议的请求消息，请求消息中携带有加密信息和第二度量信息；接收单元2301，具体用于：接收第三网络设备发送的NETCONF协议的响应消息，响应消息中携带有指示信息。其中，在请求消息中采用因特网工程任务组又一代数据模型IETF YANG Data Model格式对加密信息和第二度量信息进行描述；在响应消息中采用IETF YANG Data Model格式对指示信息进行描述。

在一种具体实现方式中，该接收单元2301，具体用于：通过第四网络设备接收第二网络设备发送的加密信息；接收单元2301，还用于接收第四网络设备发送的第四网络设备的第三度量信息；该发送单元2302，还用于向第三网络设备发送第三度量信息。

在另一种具体实现方式中，接收单元2301，还用于接收第二网络设备发送的第一身份信息；处理单元2303，还用于在第一网络设备向第三网络设备发送所述加密信息和所述第一网络设备的第二度量信息之前，根据第一身份信息，确定第二网络设备的身份合法。

在又一种具体实现方式中，接收单元2301，还用于接收第四网络设备发送的第二身份信息；处理单元2303，还用于在第一网络设备向第三网络设备发送所述加密信息和所述第一网络设备的第二度量信息之前，确定第四网络设备的身份合法。

在再一种具体实现方式中，发送单元2302，还用于向第三网络设备发送第一网络设备的第三身份信息。

在又一种具体实现方式中，处理单元2303，还用于根据第二网络设备的系统可信性，确定是否允许第二网络设备接入网络。

可以理解的是，该装置2300中的接收单元2301，可以用于执行图17对应实施例中的接收操作对应的步骤，例如：步骤1701和步骤1703；处理单元2303，可以用于执行图17对应实施例中的确定等操作对应的步骤，例如：步骤1704；发送单元2302，可以用于执行图17对应实施例中的发送操作对应的步骤，例如：步骤1702。

需要说明的是，该装置2300可以对应图5或图6所示实施例中的RP或Verifier，图7所示方法实施例中的Verifier，图8所示实施例中的RP，或者图17所示的方法实施例中的第一网络设备，故该装置2300的各种可能的实现方式以及达到的技术效果，可以参照前述图5～图8以及图17对应实施例提供的方法的介绍。

图24示出了本申请实施例提供的一种远程证明装置的结构示意图。该装置2400，包括：处理单元2401和发送单元2402。

其中，处理单元2401，用于生成加密信息，加密信息是对第一网络设备的度量信息进行加密得到的信息；

发送单元2402，用于向第二网络设备发送加密信息；其中，度量信息用于验证第一网络设备的系统可信性，从而得到验证结果。可以理解的是，该验证结果，用于确定是否允许第一网络设备接入网络。

在一种具体实现方式中，发送单元2402，还用于向第二网络设备发送第一网络设备的身份信息，身份信息用于验证第一网络设备的身份合法性。

可以理解的是，该装置2400中的处理单元2401，可以用于执行图18对应实施例中的加密等操作对应的步骤，例如：步骤1801；发送单元2402，可以用于执行图18对应实施例中的发送操作对应的步骤，例如：步骤1802。

需要说明的是，该装置2400可以对应图5～图8所示实施例中的Attester，或者图18所示的方法实施例中的第一网络设备，故该装置2400的各种可能的实现方式以及达到的技术效果，可以参照前述图5～图8以及图18对应实施例提供的方法的介绍。

图25示出了本申请实施例提供的另一种远程证明装置的结构示意图。该装置2500，包括：处理单元2501和发送单元2502。

其中，处理单元2501，用于第一网络设备向第二网络设备查询第三网络设备的系统可信性；并确定第三网络设备系统可信；

发送单元2502，用于向第三网络设备发送第一网络设备的度量信息；其中，度量信息用于验证第一网络设备的系统可信性，从而得到验证结果。

在一种具体的实现方式中，处理单元2501，还用于在第一网络设备向第三网络设备发送第一网络设备的度量信息之前，向第二网络设备查询第四网络设备的系统可信性；并确定第四网络设备系统可信；其中，第三网络设备用于将接收到的度量信息向第四网络设备发送，第四网络设备用于根据度量信息验证第一网络设备的系统可信性。

在另一种具体的实现方式中，处理单元2501，还用于在第一网络设备向第三网络设备发送第一网络设备的度量信息之前，向第二网络设备查询第三网络设备的身份合法性以及第四网络设备的身份合法性；并确定第四网络设备身份合法。

可以理解的是，该装置2500中的处理单元2501，可以用于执行图19对应实施例中的查询、确定等操作对应的步骤，例如：步骤1901和步骤1902；发送单元2502，可以用于执行图19对应实施例中的发送操作对应的步骤，例如：步骤1903。

需要说明的是，该装置2500可以对应图9～图12所示方法实施例中的Attester，或者图19所示的方法实施例中的第一网络设备，故该装置2500的各种可能的实现方式以及达到的技术效果，可以参照前述图9～图12以及图19对应实施例所提供的方法的介绍。

图26示出了本申请实施例提供的一种远程证明装置的结构示意图。该装置2600，包括：发送单元2601和接收单元2602。

其中，发送单元2601，用于向第二网络设备发送第一网络设备的第一度量信息，第一度量信息用于验证第一网络设备的系统可信性并将第一网络设备的系统可信性的第一验证结果记录在第二网络设备中；

接收单元2602，用于接收第三网络设备发送的第三网络设备的第二度量信息；其中，第二度量信息用于验证第三网络设备的系统可信性。

在一种具体实现方式中，发送单元2601，还用于向第四网络设备发送第二度量信息。

在另一种具体实现方式中，第四网络设备与第二网络设备为相同的设备。

在又一种具体实现方式中，接收单元2602，还用于接收第四网络设备发送的第二验证结果，第二验证结果为第二网络设备的系统可信性的验证结果。

在再一种具体实现方式中，该装置2600还包括：处理单元。该处理单元，用于根据第二度量信息，验证第三网络设备的系统可信性。

在又一种具体实现方式中，接收单元2602，还用于接收第三网络设备发送的第一身份信息；处理单元，还用于根据第一身份信息，验证第三网络设备的身份合法性。

在另一种具体实现方式中，发送单元2601，还用于向第二网络设备发送第一网络设备的第二身份信息，第二身份信息用于验证第一网络设备的身份合法性并将第一网络设备的身份合法性的第二验证结果记录在第二网络设备中。

在又一种具体实现方式中，处理单元，还用于根据第三网络设备的系统可信性的验证结果，确定是否允许第三网络设备接入网络。

可以理解的是，该装置2600中的发送单元2601，可以用于执行图20对应实施例中的发送操作对应的步骤，例如：步骤2001；接收单元2602，可以用于执行图20对应实施例中的接收操作对应的步骤，例如：步骤2002。

需要说明的是，该装置2600可以对应图9或图10所示实施例中的RP或Verifier，图11所示方法实施例中的Verifier，图12所示实施例中的RP，或者图20所示的方法实施例中的第一网络设备，故该装置2600的各种可能的实现方式以及达到的技术效果，可以参照前述图9～图12以及图20对应实施例所提供的方法的介绍。

图27示出了本申请实施例提供的另一种远程证明装置的结构示意图。该装置2700，包括：接收单2701、处理单元2702和发送单元2703。

其中，接收单元2701，用于接收第二网络设备发送的第二网络设备的第一度量信息；

处理单元2702，用于根据第一度量信息，验证第二网络设备的系统可信性，得到第一验证结果；

接收单元2701，还用于接收第三网络设备针对第二网络设备的系统可信性的验证结果的查询请求；

发送单元2703，用于向第三网络设备发送第一验证结果。

在一种具体实现方式中，接收单元2701，还用于接收第四网络设备发送的第四网络设备的第二度量信息；处理单元2702，还用于根据第二度量信息，验证第四网络设备的系统可信性，得到第二验证结果；接收单元2701，还用于接收第三网络设备针对第四网络设备的系统可信性的验证结果的查询请求；发送单元2703，还用于向第三网络设备发送第二验证结果；其中，第二网络设备用于接收第三网络设备发送的第三网络设备的第三度量信息并向第四网络设备发送第三度量信息；第四网络设备用于根据第三度量信息验证第三网络设备的系统可信性，从而得到第五验证结果。

在另一种具体实现方式中，接收单元2701，还用于接收第二网络设备发送的第二网络设备的第一身份信息和第四网络设备发送的第四网络设备的第二身份信息；处理单元2702，还用于根据第一身份信息，验证第二网络设备的系统可信性，得到第三验证结果，以及，根据第二身份信息，验证第四网络设备的系统可信性，得到第四验证结果；接收单元2701，还用于接收第三网络设备针对第二网络设备的身份合法性的验证结果的查询请求和第三网络设备针对第四网络设备的身份合法性的验证结果的查询请求；发送单元2703，还用于向第三网络设备发送第三验证结果和第四验证结果。

在又一种具体实现方式中，接收单元2701，还用于接收第三网络设备经第二网络设备发送的第三网络设备的第三度量信息；处理单元2702，还用于根据第三度量信息，验证第三网络设备的系统可信性；发送单元2703，还用于向第三网络设备发送第五验证结果，第五验证结果为第三网络设备的系统可信性的验证结果。

可以理解的是，该装置2700中的接收单元2701，可以用于执行图21对应实施例中的接收操作对应的步骤，例如：步骤2101和步骤2103；处理单元2702，可以用于执行图21对应实施例中的验证等操作对应的步骤，例如：步骤2102；发送单元2703，可以用于执行图21对应实施例中的发送操作对应的步骤，例如：步骤2104。

需要说明的是，该装置2700可以对应图9～图11所示实施例中的MASA，图12所示方法实施例中的MASA&Verifier，或者图21所示的方法实施例中的第一网络设备，故该装置2700的各种可能的实现方式以及达到的技术效果，可以参照前述图9～图12以及图21对应实施例所提供的方法的介绍。

此外，本申请实施例还提供了一种网络设备2800，如图28所示，该网络设备2800包括存储器2801、处理器2802和收发器2803。其中，所述存储器2801、处理器2802和收发器2803可以通过总线通信连接。收发器例如可以是光模块。

在一些可能的实现方式中，该网络设备2800中的存储器2801，用于存储程序代码；处理器2802，用于运行程序代码中的指令，使得网络设备2800执行下述操作：

通过第二网络设备接收加密信息和第二网络设备的第一度量信息，该加密信息是对第三网络设备的第二度量信息进行加密得到的信息；

根据第一度量信息，确定第二网络设备系统可信；以及

对加密信息进行解密，得到第二度量信息。

在一种具体实现方式中，处理器2802，还用于运行程序代码中的指令，使得网络设备2800执行下述操作：

向第二网络设备发送第二度量信息。

该实现方式的一个示例，通过第二网络设备接收加密信息和第二网络设备的第一度量信息，具体为：接收第二网络设备发送的网络配置NETCONF协议的请求消息，请求消息中携带有加密信息和第一度量信息；向第二网络设备发送第二度量信息，具体为：第一网络设备向第二网络设备发送NETCONF协议的响应消息，响应消息中携带有第二度量信息。可以理解的是，在请求消息中采用因特网工程任务组又一代数据模型IETF YANG Data Model格式对加密信息和第一度量信息进行描述；在响应消息中采用IETF YANG Data Model格式对第一度量信息进行描述。

在另一种实现方式中，处理器2802，还用于运行程序代码中的指令，使得网络设备2800执行下述操作：根据第二度量信息，验证第三网络设备的系统可信性，得到第一验证结果；向第二网络设备发送第一验证结果。其中，第一网络设备为MASA&Verifier，第二网络设备为RP。这样，第一网络设备可以基于第二度量信息对第三网络设备的系统可信性进行验证，并将验证结果发送给第二网络设备，以便用户通过第二网络设备查看第三网络设备的系统可信性。

作为该实现方式的一个示例，通过第二网络设备接收加密信息和第二网络设备的第一度量信息，具体为：接收第二网络设备发送的网络配置NETCONF协议的请求消息，请求消息中携带有加密信息和第一度量信息。所述向第二网络设备发送第一验证结果，具体为：向第二网络设备发送NETCONF协议的响应消息，响应消息中携带有第一验证结果。可以理解的是，在请求消息中采用因特网工程任务组又一代数据模型IETF YANG Data Model格式对加密信息和第一度量信息进行描述；在响应消息中采用IETF YANG Data Model格式对第一验证结果进行描述。

在又一种实现方式中，通过第二网络设备接收加密信息，具体为：通过第二网络设备接收由第四网络设备发送的加密信息；处理器2802，还用于运行程序代码中的指令，使得网络设备2800执行下述步骤：通过第二网络设备接收第四网络设备的第三度量信息。其中，网络设备2800执行对加密信息进行解密之前，还用于执行：根据第三度量信息，确定第四网络设备的系统可信。

在再一种实现方式中，处理器2802，还用于运行程序代码中的指令，使得网络设备2800执行以下步骤：接收第二网络设备发送的身份信息。相应的，在网络设备2800执行对加密信息进行解密之前，处理器2802，还用于运行程序代码中的指令，使得网络设备2800执行下述步骤：根据身份信息，确定第二网络设备身份合法。

需要说明的是，对于该可能的实现方式，该网络设备2800可以对应图5～图7所示方法实施例中的MASA，图8所示实施例中的MASA&Verifier，或者图16所示的方法实施例中的第一网络设备，故该网络设备2800的各种可能的实现方式以及达到的技术效果，可以参照前述图5～图8以及图16所示的实施例提供的方法的介绍。

在另一些可能的实现方式中，该网络设备2800中的存储器2801，用于存储程序代码；处理器2802，用于运行程序代码中的指令，使得网络设备执行下述操作：

接收第二网络设备发送的加密信息，加密信息是对第二网络设备的第一度量信息进行加密得到的信息；

向第三网络设备发送加密信息和第一网络设备的第二度量信息；

接收第三网络设备发送的指示信息；

根据该指示信息确定第二网络设备的系统可信性。

在一种实现方式中，该指示信息可以为第二网络设备的系统可信性的验证结果。

在另一种实现方式中，该指示信息还可以为第一度量信息。相应的那么，处理器2802，具体用于运行程序代码中的指令，使得网络设备执行：根据第一度量信息，验证第二网络设备的系统可信性。

其中，向第三网络设备发送的加密信息和第三网络设备的第二度量信息，具体为：向第三网络设备发送的网络配置NETCONF协议的请求消息，请求消息中携带有加密信息和第二度量信息；接收第三网络设备发送的第一验证结果，具体为：接收第三网络设备发送的NETCONF协议的响应消息，响应消息中携带有指示信息。作为一个示例，在请求消息中采用因特网工程任务组又一代数据模型IETF YANG Data Model格式对加密信息和第二度量信息进行描述；在响应消息中采用IETF YANG Data Model格式对指示信息进行描述。

在再一种实现方式中，接收第二网络设备发送的加密信息，具体为：通过第四网络设备接收第二网络设备发送的加密信息。相应的，那么，处理器2802，具体用于运行程序代码中的指令，使得网络设备2800执行以下操作：接收第四网络设备发送的第四网络设备的第三度量信息；通过收发器2803向第三网络设备发送第三度量信息。

在又一种实现方式中，处理器2802，还用于运行程序代码中的指令，使得网络设备执行下述操作：接收第二网络设备发送的第一身份信息；那么，在第一网络设备向第三网络设备发送该加密信息和第一网络设备的第二度量信息之前，处理器2802，还用于运行程序代码中的指令，使得网络设备执行以下操作：根据第一身份信息，确定第二网络设备身份合法。

在另一种实现方式中，处理器2802，还用于运行程序代码中的指令，使得网络设备2800执行下述操作：接收第四网络设备发送的第二身份信息；那么，在第一网络设备向第三网络设备发送该加密信息和第一网络设备的第二度量信息之前，网络设备2800还执行下述操作：通过收发器2803接收第四网络设备发送的第二身份信息：根据第二身份信息，确定第四网络设备身份合法。

在又一种实现方式，处理器2802，还用于运行程序代码中的指令，使得网络设备2800执行下述操作：向第三网络设备发送第一网络设备的第三身份信息。其中，该第三身份信息用于验证第一网络设备的身份合法性。

需要说明的是，对于该可能的实现方式，该网络设备2800可以对应图5或图6所示实施例中的RP或Verifier，图7所示方法实施例中的Verifier，图8所示实施例中的RP，或者图17所示的方法实施例中的第一网络设备，故该网络设备2800的各种可能的实现方式以及达到的技术效果，可以参照前述图5～图8以及图17对应实施例提供的方法的介绍。

在又一些可能的实现方式中，该网络设备2800中的存储器2801，用于存储程序代码；处理器2802，用于运行程序代码中的指令，使得网络设备2800执行下述操作：

生成加密信息，该加密信息是对第一网络设备的度量信息进行加密得到的信息；

向第二网络设备发送上述加密信息；其中，度量信息用于验证第一网络设备的系统可信性，从而得到验证结果。

在一种实现方式中，处理器2802，还用于运行程序代码中的指令，使得网络设备2800执行下述操作：向第二网络设备发送第一网络设备的身份信息，身份信息用于验证第一网络设备的身份合法性。

其中，该验证结果，可以用于确定是否允许第一网络设备接入网络。

需要说明的是，对于该可能的实现方式，该网络设备2800可以对应图5～图8所示实施例中的Attester，或者图18所示的方法实施例中的第一网络设备，故该网络设备2800的各种可能的实现方式以及达到的技术效果，可以参照前述图5～图8以及图18对应实施例提供的方法的介绍。

此外，本申请实施例还提供了一种网络设备2900，如图29所示，该网络设备2900包括存储器2901、处理器2902和收发器2903。所述存储器2901、处理器2902和收发器2903可以通过总线通信连接。所述收发器2903例如可以是光模块。

在一些可能的实现方式中，该网络设备2900中的存储器2901，用于存储程序代码；处理器2902，用于运行程序代码中的指令，使得网络设备2900执行下述操作：

向第二网络设备查询第三网络设备的系统可信性

确定第三网络设备系统可信；

向第三网络设备发送第一网络设备的度量信息；其中，度量信息用于验证第一网络设备的系统可信性，从而得到验证结果。

在一种实现方式中，在向第三网络设备发送第一网络设备的度量信息之前，处理器2902，还用于运行程序代码中的指令，使得网络设备2900执行下述操作：向第二网络设备查询第四网络设备的系统可信性；确定第四网络设备系统可信；其中，第三网络设备用于将接收到的度量信息向第四网络设备发送，第四网络设备用于根据度量信息验证第一网络设备的系统可信性。

在一种实现方式中，在向第三网络设备发送第一网络设备的度量信息之前，处理器2902，还用于运行程序代码中的指令，使得网络设备2900执行：向第二网络设备查询第三网络设备的身份合法性以及第四网络设备的身份合法性；确定第四网络设备身份合法。

需要说明的是，对于该可能的实现方式，该网络设备2900可以对应图9～图12所示方法实施例中的Attester，或者图19所示的方法实施例中的第一网络设备，故该网络设备2900的各种可能的实现方式以及达到的技术效果，可以参照前述图9～图12以及图19对应实施例所提供的方法的介绍。

在另一些可能的实现方式中，该网络设备2900中的存储器2901，用于存储程序代码；处理器2902，用于运行程序代码中的指令，使得网络设备2900执行下述操作：

向第二网络设备发送第一网络设备的第一度量信息，第一度量信息用于验证第一网络设备的系统可信性并将第一网络设备的系统可信性的第一验证结果记录在第二网络设备中；接收第三网络设备发送的第三网络设备的第二度量信息；其中，第二度量信息用于验证第三网络设备的系统可信性。

在一种实现方式中，处理器2902，还用于运行程序代码中的指令，使得网络设备2900执行：向第四网络设备发送第二度量信息。

在本实施例中，第四网络设备与第二网络设备为相同的设备。

在另一种实现方式中，处理器2902，还用于运行程序代码中的指令，使得网络设备2900执行：接收第四网络设备发送的第二验证结果，第二验证结果为第二网络设备的系统可信性的验证结果。

在一种实现方式中，处理器2902，还用于运行程序代码中的指令，使得网络设备2900执行：根据第二度量信息，验证第三网络设备的系统可信性。

在再一种具体实现方式中，处理器2902，还用于运行程序代码中的指令，使得网络设备2900执行：接收第三网络设备发送的第一身份信息；第一网络设备根据第一身份信息，验证第三网络设备的身份合法性。

在另一种实现方式中，处理器2902，还用于运行程序代码中的指令，使得网络设备2900执行：向第二网络设备发送第一网络设备的第二身份信息，第二身份信息用于验证第一网络设备的身份合法性并将第一网络设备的身份合法性的第二验证结果记录在第二网络设备中。

在又一种实现方式中，处理器2902，还用于运行程序代码中的指令，使得网络设备2900执行：根据第三网络设备的系统可信性的验证结果，确定是否允许第三网络设备接入网络。

需要说明的是，对于该可能的实现方式，该网络设备2900可以对应图9或图10所示实施例中的RP或Verifier，图11所示方法实施例中的Verifier，图12所示实施例中的RP，或者图20所示的方法实施例中的第一网络设备，故该网络设备2900的各种可能的实现方式以及达到的技术效果，可以参照前述图9～图12以及图20对应实施例所提供的方法的介绍。

接收第二网络设备发送的第二网络设备的第一度量信息；

根据第一度量信息，验证第二网络设备的系统可信性，得到第一验证结果；

接收第三网络设备针对第二网络设备的系统可信性的验证结果的查询请求；第一网络设备向第三网络设备发送第一验证结果。

在一种实现方式中，处理器2902，还用于运行程序代码中的指令，使得网络设备2900执行：接收第四网络设备发送的第四网络设备的第二度量信息；根据第二度量信息，验证第四网络设备的系统可信性，得到第二验证结果；接收第三网络设备针对第四网络设备的系统可信性的验证结果的查询请求通过收发器2903向第三网络设备发送第二验证结果；其中，第二网络设备用于接收第三网络设备发送的第三网络设备的第三度量信息并向第四网络设备发送第三度量信息；第四网络设备用于根据第三度量信息验证第三网络设备的系统可信性，从而得到第五验证结果。

在另一种实现方式中，处理器2902，还用于运行程序代码中的指令，使得网络设备2900执行：接收第二网络设备发送的第二网络设备的第一身份信息和第四网络设备发送的第四网络设备的第二身份信息；根据第一身份信息，验证第二网络设备的系统可信性，得到第三验证结果，以及，根据第二身份信息，验证第四网络设备的系统可信性，得到第四验证结果；接收第三网络设备针对第二网络设备的身份合法性的验证结果的查询请求和第三网络设备针对第四网络设备的身份合法性的验证结果的查询请求；向第三网络设备发送第三验证结果和第四验证结果。

在又一种实现方式，处理器2902，还用于运行程序代码中的指令，使得网络设备2900执行：接收第三网络设备经第二网络设备发送的第三网络设备的第三度量信息；根据第三度量信息，验证第三网络设备的系统可信性；向第三网络设备发送第五验证结果，第五验证结果为第三网络设备的系统可信性的验证结果。

需要说明的是，对于该可能的实现方式，该网络设备2900可以对应图9～图11所示实施例中的MASA，图12所示方法实施例中的MASA&Verifier，或者图21所示的方法实施例中的第一网络设备，故该网络设备2900的各种可能的实现方式以及达到的技术效果，可以参照前述图9～图12以及图21对应实施例所提供的方法的介绍。

其中，在本申请所述的网络设备2800以及网络设备2900中，处理器2802/2902可以是中央处理器(英文：central processing unit，缩写：CPU)，网络处理器(英文：networkprocessor，缩写：NP)或者CPU和NP的组合。处理器2802/2902还可以是专用集成电路(英文：application-specific integrated circuit，缩写：ASIC)，可编程逻辑器件(英文：programmable logic device，缩写：PLD)或其组合。上述PLD可以是复杂可编程逻辑器件(英文：complex programmable logic device，缩写：CPLD)，现场可编程逻辑门阵列(英文：field-programmable gate array，缩写：FPGA)，通用阵列逻辑(英文：generic arraylogic,缩写：GAL)或其任意组合。处理器2802/2902可以是指一个处理器，也可以包括多个处理器。存储器2801/2901可以包括易失性存储器(英文：volatile memory)，例如随机存取存储器(英文：random-access memory，缩写：RAM)；存储器2801/2901也可以包括非易失性存储器(英文：non-volatile memory)，例如只读存储器(英文：read-only memory，缩写：ROM)，快闪存储器(英文：flash memory)，硬盘(英文：hard disk drive，缩写：HDD)或固态硬盘(英文：solid-state drive，缩写：SSD)；存储器2801/2901还可以包括上述种类的存储器的组合，存储器2801/2901可以是指一个存储器，也可以包括多个存储器。在一个具体实施方式中，存储器2801/2901中存储有计算机可读指令，所述计算机可读指令包括多个软件模块，例如发送模块2821/2921，处理模块2811/2911和接收模块2831/2931。处理器2802/2902执行各个软件模块后可以按照各个软件模块的指示进行相应的操作。在本实施例中，一个软件模块所执行的操作实际上是指处理器2802/2902根据所述软件模块的指示而执行的操作。处理器2802/2902执行存储器2801/2901中的计算机可读指令后，可以按照所述计算机可读指令的指示，执行网络设备2800/2900可以执行的全部操作。

此外，本申请实施例还提供了一种通信系统3000，如图30所示，该通信系统300可以包括上述网络设备2800以及网络设备2900。用于执行前述图5～图12以及图16～图21对应实施例中任意一种实现方式所述的远程证明方法。

此外，本申请实施例还提供了一种计算机程序产品，当其在计算机上运行时，使得计算机执行前述图5～图12以及图16～图21对应实施例中任意一种实现方式所述的远程证明方法。

此外，本申请实施例还提供了一种计算机可读存储介质，计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行以上图5～图12以及图16～图21对应实施例中任意一种实现方式所述的远程证明方法。

本申请实施例中提到的“第一网络设备”、“第一度量信息”等名称中的“第一”只是用来做名字标识，并不代表顺序上的第一。该规则同样适用于“第二”等序数词。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到上述实施例方法中的全部或部分步骤可借助软件加通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如只读存储器(英文：read-only memory，ROM)/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者诸如路由器等网络通信设备)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例和设备实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的设备及装置实施例仅仅是示意性的，其中作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅是本申请示例性的实施方式，并非用于限定本申请的保护范围。

Claims

1.一种远程证明方法，其特征在于，包括：

第一网络设备通过第二网络设备接收加密信息和所述第二网络设备的第一度量信息，所述加密信息是第三网络设备对所述第三网络设备的第二度量信息进行加密得到的信息；

所述第一网络设备根据所述第一度量信息，确定所述第二网络设备系统可信；

所述第一网络设备对所述加密信息进行解密，得到所述第二度量信息；

所述第一网络设备向所述第二网络设备发送所述第二度量信息，以使所述第二网络设备基于所述第二度量信息对所述第三网络设备的系统可信性进行验证；或者，所述第一网络设备根据所述第二度量信息，验证所述第三网络设备的系统可信性，得到第一验证结果，并由所述第一网络设备向所述第二网络设备发送所述第一验证结果。

2.根据权利要求1所述的方法，其特征在于，当所述第三网络设备的系统可信性由所述第二网络设备负责验证时，

所述第一网络设备通过第二网络设备接收加密信息，具体为：

所述第一网络设备通过所述第二网络设备接收由第四网络设备发送的所述加密信息；

所述方法还包括：

所述第一网络设备通过所述第二网络设备接收所述第四网络设备的第三度量信息；

所述第一网络设备对所述加密信息进行解密之前，所述方法还包括：

所述第一网络设备根据所述第三度量信息，确定所述第四网络设备系统可信。

3.根据权利要求1或2所述的方法，其特征在于，还包括：

所述第一网络设备接收所述第二网络设备发送的身份信息；

所述第一网络设备根据所述身份信息，确定所述第二网络设备身份合法。

4.根据权利要求1所述的方法，其特征在于，当所述第三网络设备的系统可信性由所述第二网络设备负责验证时，

所述第一网络设备通过第二网络设备接收加密信息和所述第二网络设备的第一度量信息，具体为：所述第一网络设备接收所述第二网络设备发送的网络配置NETCONF协议的请求消息，所述请求消息中携带有所述加密信息和所述第一度量信息；

所述第一网络设备向所述第二网络设备发送所述第二度量信息，具体为：所述第一网络设备向所述第二网络设备发送NETCONF协议的响应消息，所述响应消息中携带有所述第二度量信息。

5.根据权利要求4所述的方法，其特征在于，

在所述请求消息中采用因特网工程任务组又一代数据模型IETF YANG Data Model格式对所述加密信息和所述第一度量信息进行描述；

在所述响应消息中采用所述IETF YANG Data Model格式对所述第一度量信息进行描述。

6.根据权利要求1所述的方法，其特征在于，当所述第三网络设备的系统可信性由所述第一网络设备负责验证时，

所述第一网络设备接收第二网络设备发送的加密信息和所述第二网络设备的第一度量信息，具体为：所述第一网络设备接收所述第二网络设备发送的网络配置NETCONF协议的请求消息，所述请求消息中携带有所述加密信息和所述第一度量信息；

所述第一网络设备向所述第二网络设备发送所述第一验证结果，具体为：所述第一网络设备向所述第二网络设备发送NETCONF协议的响应消息，所述响应消息中携带有所述第一验证结果。

7.根据权利要求6所述的方法，其特征在于，

在所述响应消息中采用所述IETF YANG Data Model格式对所述第一验证结果进行描述。

8.一种远程证明方法，其特征在于，包括：

第一网络设备接收第二网络设备发送的加密信息，所述加密信息是对所述第二网络设备的第一度量信息进行加密得到的信息；

所述第一网络设备向第三网络设备发送所述加密信息和所述第一网络设备的第二度量信息；

所述第一网络设备接收所述第三网络设备发送的指示信息；

所述第一网络设备根据所述指示信息，确定所述第二网络设备的系统可信性；

所述指示信息为所述第二网络设备的系统可信性的验证结果，或者，所述指示信息为所述第一度量信息，以用于所述第一网络设备验证所述第二网络设备的系统可信性。

9.根据权利要求8所述的方法，其特征在于，当所述第二网络设备的系统可信性由所述第一网络设备负责验证时，所述第一网络设备接收第二网络设备发送的加密信息，具体为：所述第一网络设备通过第四网络设备接收所述第二网络设备发送的所述加密信息；

所述方法还包括：

所述第一网络设备接收第四网络设备发送的所述第四网络设备的第三度量信息；

所述第一网络设备向所述第三网络设备发送所述第三度量信息。

10.根据权利要求8或9所述的方法，其特征在于，还包括：

所述第一网络设备接收所述第二网络设备发送的第一身份信息；

所述第一网络设备向第三网络设备发送所述加密信息和所述第一网络设备的第二度量信息之前，所述方法还包括：

所述第一网络设备根据所述第一身份信息，确定所述第二网络设备身份合法。

11.根据权利要求9所述的方法，其特征在于，还包括：

所述第一网络设备接收所述第四网络设备发送的第二身份信息；

所述第一网络设备向第三网络设备发送所述加密信息和所述第一网络设备的第二度量信息之前，所述方法还包括：所述第一网络设备根据所述第二身份信息，确定所述第四网络设备身份合法。

12.根据权利要求8或9所述的方法，其特征在于，还包括：

所述第一网络设备向所述第三网络设备发送所述第一网络设备的第三身份信息。

13.根据权利要求8所述的方法，其特征在于，

所述第一网络设备向第三网络设备发送的所述加密信息和所述第一网络设备的第二度量信息，具体为：所述第一网络设备向所述第三网络设备发送的网络配置NETCONF协议的请求消息，所述请求消息中携带有所述加密信息和所述第二度量信息；

所述第一网络设备接收所述第三网络设备发送的指示信息，具体为：所述第一网络设备接收所述第三网络设备发送的NETCONF协议的响应消息，所述响应消息中携带有所述指示信息。

14.一种网络设备，其特征在于，所述网络设备包括存储器和处理器；

所述存储器，用于存储程序代码；

所述处理器，用于运行所述程序代码中的指令，使得所述网络设备执行权利要求1～7任一项所述的远程证明方法。

15.一种网络设备，其特征在于，所述网络设备包括存储器和处理器；

所述存储器，用于存储程序代码；

所述处理器，用于运行所述程序代码中的指令，使得所述网络设备执行权利要求8～13任一项所述的远程证明方法。

16.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得所述计算机执行以上权利要求1～7任一项所述的远程证明方法或者权利要求8～13任一项所述的远程证明方法。

17.一种通信系统，包括权利要求14所述的网络设备以及权利要求15所述的网络设备。