CN112688782B - 一种组合式设备的远程证明方法及设备 - Google Patents

一种组合式设备的远程证明方法及设备 Download PDF

Info

Publication number
CN112688782B
CN112688782B CN201911089398.XA CN201911089398A CN112688782B CN 112688782 B CN112688782 B CN 112688782B CN 201911089398 A CN201911089398 A CN 201911089398A CN 112688782 B CN112688782 B CN 112688782B
Authority
CN
China
Prior art keywords
unit
verification
remote
trusted
remote attestation
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201911089398.XA
Other languages
English (en)
Other versions
CN112688782A (zh
Inventor
胡俊理
潘伟
曾海飞
王玉国
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to JP2022523021A priority Critical patent/JP2022553247A/ja
Priority to EP20876775.6A priority patent/EP4030681A4/en
Priority to PCT/CN2020/116936 priority patent/WO2021073376A1/zh
Priority to BR112022006829A priority patent/BR112022006829A2/pt
Publication of CN112688782A publication Critical patent/CN112688782A/zh
Priority to US17/720,848 priority patent/US20220237295A1/en
Application granted granted Critical
Publication of CN112688782B publication Critical patent/CN112688782B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/14Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1433Vulnerability analysis
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26Power supply means, e.g. regulation thereof
    • G06F1/32Means for saving power
    • G06F1/3203Power management, i.e. event-based initiation of a power-saving mode
    • G06F1/3206Monitoring of events, devices or parameters that trigger a change in power modality
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/606Protecting data by securing the transmission between two devices or processes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

本申请实施例公开了一种组合式设备的远程证明方法及相关设备,该组合式设备包括第一单元和第二单元,该方法包括:第一单元获取第二单元的第一度量信息;该第一单元根据第一度量信息对第二单元进行可信验证,获得第一验证结果;第一单元向远程证明设备发送第一验证结果。这样,该组合式设备中的第一单元具有远程证明功能,可以对其所属的组合式设备内的其他单元进行可信验证,不仅实现了对组合式设备的系统可信验证,从而提高整个系统的可靠性,而且能够有效的降低远程证明设备和组合式设备就远程证明过程需要交互的数据量,一定程度上提高了对组合式设备的远程证明效率。

Description

一种组合式设备的远程证明方法及设备
本申请要求于2019年10月17日递交中国专利局、申请号为CN201910990240.3,发明名称为“一种远程证明方法和设备”的中国专利申请的优先权,其全部内容通过引用结合在本申请中。
技术领域
本申请涉及通信技术领域,特别是涉及一种组合式设备的远程证明方法及相关设备,该远程证明方法用于对组合式设备的系统可信性进行远程证明。
背景技术
随着系统可信性的远程证明被应用到越来越广泛的场景,在目前万物互联的形势下,例如物联网(英文:Internet of Thing,简称:IoT)等系统中的网络设备越来越多,各个网络设备的系统可信对于整个系统而言至关重要,这些网络设备也包括很多组合式网络设备。
基于此,为了提高组合式设备的可信性,以及包括组合式设备的网络的可信性,亟待提供一种组合式设备的远程证明方式,以验证组合式设备的系统可信性。
发明内容
基于此,本申请实施例提供了一种组合式设备的远程证明方法及相关设备,通过对组合式设备的远程证明,实现对组合式设备的系统可信验证,从而提高整个系统的可靠性。
在本申请实施例中,除了可以由远程证明设备对组合式设备中的各单元进行可信验证之外,也赋予了组合式设备中的部分单元远程证明的能力,可以对该组合式设备中其他单元的可信验证。其中,组合式设备可以包括:路由器、交换机或分组传送网(英文:Packet Transport Network,简称:PTN)设备。
第一方面,提供了一种组合式设备的远程证明方法,该组合式设备可以包括第一单元和第二单元,那么,该组合式设备采用远程证明方式进行可信验证具体可以是:第一单元对第二单元进行可信验证并将验证结果发送给远程证明设备,具体远程证明的过程可以包括:第一步,第一单元获取第二单元的第一度量信息;第二步,第一单元根据第一度量信息对第二单元进行可信验证,获得第一验证结果;第三步,第一单元向远程证明设备发送第一验证结果。这样,该组合式设备中的第一单元具有远程证明功能,可以对其所属的组合式设备内的其他单元(例如:第二单元)进行可信验证,那么,组合式设备的第一单元可以直接将其他单元的可信验证结果发送给远程证明设备,该远程证明设备只需要接收第一单元发送的其他单元的验证结果即可,不再需要接收各个单元的度量信息并分别对各个单元进行可信验证,可以有效的降低远程证明设备和组合式设备就远程证明过程需要交互的数据量,一定程度上提高了对组合式设备的远程证明效率。
其中,第一单元可以是控制面,第二单元可以是控制面或转发面。例如:当组合式设备为路由器时,第一单元可以是主用主控板,第二单元可以是备用主控板、转发板、业务板等。
本申请中所述的各单元实际是指包括TPM芯片的单元。例如,第一单元包括第一TPM 芯片,第二单元包括第二TMP芯片。第二单元的度量信息包括在所述第二TPM芯片的至少一个PCR中存放的度量信息。
作为一个示例,对于组合式设备的启动等度量过程较为确定的情况,第一度量信息可以包括第一平台配置注册表(英文:Platform configuration register,简称PCR)值和PCR 参考值。那么,第一方面的第一步中,第一单元获取第二单元的第一度量信息,具体可以包括:第一单元从第二单元获得第一PCR值;第一单元从远程证明设备或本地的安全存储空间中获得PCR参考值。基于此,第一方面的第二步中,第一单元根据第一度量信息对第二单元进行可信验证获得第一验证结果,具体过程可以为:第一单元比较第一PCR值和 PCR参考值,获得第一验证结果,若第一PCR值和PCR参考值一致,则第一验证结果表征第二单元可信,反之,若第一PCR值和PCR参考值不一致,则第一验证结果表征第二单元不可信。如此,即可在组合式设备进行启动等度量过程较为确定的过程时,由其中的第一单元以PCR参考值为依据,对第二单元进行可信验证,实现对组合式设备快速、方便和有效的远程证明。
其中,第一PCR值可以是第二单元内置的信任计算基础(英文:Trusted ComputingBase,简称:TCB)模块当前记录的PCR值;PCR参考值为第二单元的可信的PCR值,用于对第二单元产生的第一PCR值进行校验。
作为另一个示例,对于组合式设备的度量过程较为不确定的情况,例如:组合式设备启动后的运行过程,第一度量信息可以包括第二单元上报的第二PCR值和第一度量日志,其中,第一度量日志包括第一基线值以及基于第一基线值进行扩展得到第二PCR值的过程信息,第一基线值是第二单元上报的基线值;第一度量信息还包括第二基线值,第二基线值是第二单元的可信的基线值,第二基线值用于对第一基线值进行校验。那么,第一方面的第一步中,第一单元获取第二单元的第一度量信息,具体可以包括:第一单元从第二单元获得第二PCR值和第一度量日志,第一度量日志包括第一基线值以及基于第一基线值进行扩展得到第二PCR值的过程信息;第一单元从远程证明设备或本地的安全存储空间中获得第二基线值。基于此,第一方面的第二步中,第一单元根据第一度量信息对第二单元进行可信验证获得第一验证结果,具体过程可以为包括:第一单元基于第一度量日志,计算第三PCR值;第一单元对比第二PCR值和第三PCR值,若第二PCR值和第三PCR值一致,则,第一单元对比第二基线值和第一基线值,获得第一验证结果;反之,若第二PCR 值和第三PCR值不一致,则第一单元可以不对比第二基线值和第一基线值,直接得出第一验证结果,该第一验证结果用于表征该第二单元不可信。如此,即可在组合式设备执行度量过程不确定的进程时,由其中的第一单元以第二基线值为依据,对第二单元进行可信验证,实现对组合式设备快速、方便和有效的远程证明。
其中,第二PCR值可以是第二单元内置的TCB模块当前记录的PCR值,该第一度量日志中记录有基于第一基线值进行扩展得到第二PCR值的过程信息(例如:对该第一基线值的扩展顺序和扩展次数)以及第一基线值。其中,第二PCR值是第二单元的TCB模块基于第一基线值和过程信息计算得到的;而第三PCR值可以是第一单元基于第一度量日志中的第二基线值和过程信息计算得到的。其中,第二基线值可以视作该第二单元的可信的基线值,用于对第一基线值进行校验。
针对上述两个示例,可以理解的是,一种情况下,该第二单元的PCR参考值或第二基线值,可以是被存储在第一单元本地的安全存储空间中,该安全存储空间可以是指不可被攻击者篡改或访问的物理空间,例如:只有远程证明(英文:Remote Attestation,简称:RAT)相关进程或者运行进程实现RAT的模块(称为:RAT组建)才能够访问的物理空间;另一种情况下,该第二单元的PCR参考值或第二基线值,也可以是从远程证明设备上获取的,远程证明设备上保存有组合式设备的各单元的PCR参考值和/或所述第二基线值。
在一些可能的实现方式中,当组合式设备还包括第三单元时,本申请实施例还可以包括:第一单元获取第三单元的第二度量信息;第一单元向远程证明设备发送第二度量信息。这样,第一单元只是将第三单元的度量信息转发给远程证明设备,由远程证明设备对第三单元进行远程证明,也实现了对该组合式设备中的单元进行可信验证的效果。
具体实现时,当该远程证明采用挑战-响应方式时,在第一单元向远程证明设备发送第一验证结果之前,例如在第一方面的第一步之前,或者,第二步和第三步之间,本申请实施例还可以包括:第一单元接收远程证明设备发送的第一度量请求消息,第一度量请求消息可以视作“挑战”,用于请求对组合式设备进行可信验证,那么,第三步中第一单元即可将第一验证结果携带在第一度量回应消息中,作为对“挑战”的“响应”,发送给远程证明设备。
在另一些可能的实现方式中,本申请实施例还可以包括:第一单元向远程证明设备发送第一单元的第三度量信息,远程证明设备对第一单元进行可信验证。这样,一方面,由远程证明设备对第一单元进行可信验证的过程,使得对该组合式设备的可信验证更加完备,即,实现了对组合设备中包括第一单元在内的所有单元的可信验证;另一方面,也可以在由第一单元对第二单元进行可信验证前,先由远程证明设备对第一单元进行可信验证,在第一单元可信的条件下,才确定由该第一单元对第二单元进行远程证明,使得远程证明的过程更加安全,提高了对组合式设备的远程证明的可靠性。
在第一方面的一些可能的实现方式下,组合式设备的远程证明可以采用不同的远程证明模式,例如:中继(英文:Relay)模式、本地验证(英文:Proxy)模式和混合验证(英文:Mixed)模式。其中,中继模式下,由远程证明设备对组合式设备内的所有单元进行可信验证;本地验证模式下,由组合式设备内的第一单元对该组合式设备中的其他单元进行可信验证;混合验证模式下,由组合式设备内的第一单元对该组合式设备中的部分单元进行可信验证,由远程证明设备对该组合式设备中的其他单元进行可信验证。为了确保远程证明可以有序执行,在进行上述远程证明之前,远程证明设备和组合式设备之间可以先确定采用的远程证明模式。
作为一个示例,确定采用远程证明的方式,可以通过在组合式设备和远程证明设备上进行本地静态配置的方式,确定接下来的远程证明采用的远程证明模式。
作为另一个示例,也可以通过组合式设备和远程证明设备之间进行协商的方式,确定接下来的远程证明采用的远程证明模式,例如:第一单元向远程证明设备发出模式协商请求消息;第一单元接收远程证明设备发送的模式协商响应消息,第一单元根据模式协商响应消息,确定远程证明模式。其中,模式协商请求消息中可以携带第一指示信息,第一指示信息用于指示第一单元支持并且建议采用的远程证明模式;模式协商响应消息中携带第二指示信息,第二指示信息用于指示远程证明设备确定接下来采用的远程证明模式。需要说明的是,远程证明模式的协商过程可以是第一单元发起的,也可以是远程证明设备发起的;最终确定的远程证明模式可以是第一单元决策确定的,也可以是远程证明设备决策确定的。这样,通过组合式设备和远程证明设备之间的协商,确定接下来采用的远程证明方式,为后续有序的对组合式设备进行远程证明提供了数据基础。
可以理解的是,当所确定的远程证明模式为本地验证模式时,那么,在本地验证模式下,第一单元负责对组合式设备内除第一单元以外的,其它所有包括TCB模块的单元进行可信验证。当所确定的远程证明模式为混合验证模式时,那么,在混合验证模式下,第一单元对第二单元进行可信验证,远程证明设备对组合式设备中的第四单元进行可信验证,即,第一单元对组合式设备中的部分单元进行可信验证,该部分单元中包括第二单元;另一部分单元将其度量信息通过第一单元发送给远程证明设备,由远程证明设备进行可信验证,该另一部分单元中包括第三单元。
需要说明的是,对于混合验证模式,确定由远程证明设备和第一单元进行可信验证的具体单元,可以是第一单元确定并通知远程证明设备的,也可以是远程证明设备确定并通知第一单元的,还可以是二者协商确定的,该协商确定各自具体验证的单元的过程,可以在协商远程证明模式的过程中同时实现,也可以在确定远程证明模式为混合验证模式后单独协商的。作为一个示例,本申请实施例例如可以采用下述过程确定由远程证明设备和第一单元进行可信验证的具体单元:第一单元向远程证明设备发送第一请求消息,第一请求消息用于向远程证明设备请求验证权限,验证权限指示被第一单元进行可信验证的单元的集合,集合包括第二单元;第一单元接收远程证明设备返回的第一响应消息,第一响应消息用于指示验证权限。其中,该第一响应消息中包括被第一单元进行可信验证的各单元的标识信息,该标识信息例如可以是单元的标识符,用于唯一标识该单元。
需要说明的是,上述第一单元为激活态的主单元,例如,第一单元可以是在该第一方面的第一步之前,从备用态切换为激活态的主单元。
在第一方面的一些可能的实现方式中,触发对组合式设备进行远程证明的方式,一种情况下,第一单元可以周期性的对第二单元进行可信验证,例如:第一单元周期性的向远程证明设备发送第一触发请求,第一触发请求用于周期性的触发远程证明设备对组合式设备进行可信验证。另一种情况下,第一单元也可以是基于事件的触发,对第二单元进行可信验证,例如:第一单元基于事件的发生向远程证明设备发送第二触发请求,第二触发请求用于触发远程证明设备对组合式设备进行可信验证,其中,事件可以包括下述情况中的一种:第一单元发生主备切换、第二单元状态发生变化或配置命令,即,当第一单元从备用态切换为激活态时,或者,第一单元感知到第二单元发生了状态变化(例如新增第二单元或者第二单元发生替换)时,再或者,第二单元接收到配置命令时,触发第一单元对第二单元进行可信验证。如此,可以在发生事件或者达到预设的周期时,无需再被动的等待远程证明的发起,第一单元即可主动对第二单元进行可信验证,节约了远程证明过程的交互流程,提高了该远程证明的效率。
在第一方面的另一些可能的实现方式中,当组合式设备中的单元发生增量变化,即,该单元存在部分PCR值对应的度量信息不变,其他PCR值对应的度量信息变化的情况,那么,本申请实施例为了节约远程证明占用的系统资源,提高远程证明的效率,可以仅对发生变化的度量信息进行远程证明,即,对增量变化对应的度量信息进行获取以及基于该增量变化对应的度量信息进行远程证明。作为一个示例,当第二单元发生第一增量变化,本申请实施例还可以包括:第二单元发生第一增量变化,第一单元获取与第一增量变化对应的第五度量信息;第一单元基于第五度量信息,对第二单元进行可信验证。作为另一个示例,当第一单元发生第二增量变化,则,本申请实施例还可以包括:第一单元向远程证明设备发送该第一单元发生第二增量变化对应的第六度量信息;该远程证明设备基于第六度量信息对发生第二增量变化后的第一单元进行可信验证。这样,本申请实施例实现了只针对各单元发生改变的PCR值对应的度量信息进行验证,而不对所有的PCR值对应的度量信息进行全量验证,避免对没有发生改变的PCR值对应的度量信息进行重复验证,节约网络资源,提高对组合式设备的远程证明效率。
第二方面,本申请实施例还提供了一种组合式设备的远程证明方法,应用于远程证明设备,其中,组合式设备可以包括第一单元和第二单元,本申请实施例具体可以包括:第一步,远程证明设备接收第一单元发送的第一消息,第一消息中携带第一单元对第二单元进行可信验证的第一验证结果;第二步,远程证明设备根据第一消息,获取第一验证结果。
在一些可能的实现方式中,本申请实施例还可以包括:远程证明设备接收第一单元发送的第二消息,第二消息中携带第一单元的第一度量信息;远程证明设备根据第一度量信息,对第一单元进行可信验证,获得第二验证结果。
在另一些可能的实现方式中,本申请实施例还可以包括:远程证明设备对第一验证结果进行校验,得到第三验证结果。具体而言,用于验证第二单元的签名是否正确,以及第一单元对第二单元的可信验证过程是否准确。
在又一些可能的实现方式中,本申请实施例还可以还包括:确定远程证明模式。一种情况下,可以通过静态配置的方式在远程证明设备以及第一单元上设定远程证明模式;另一种情况下,也可以通过协商的方式确定远程证明模式,作为一个示例,协商的过程可以包括:远程证明设备接收第一单元发出的模式协商请求消息;远程证明设备根据模式协商请求消息,确定远程证明模式;远程证明设备向第一单元发送模式协商响应消息,模式协商响应消息中携带远程证明模式,模式协商响应消息用于告知第一单元采用远程证明模式进行远程证明。
作为一个示例,当远程证明模式为本地验证模式时,在本地验证模式下,第一单元负责对组合式设备内包括除第一单元以外的所有单元进行可信验证,所有单元中的每个单元包括可信计算基础TCB模块。那么,本申请实施例还可以包括:远程证明设备根据第一验证结果、第二验证结果和第三验证结果,生成第四验证结果,第四验证结果用于表征组合式设备的系统可信性;其中,若第一验证结果表示第二单元可信,第二验证结果表示第一单元可信,第三验证结果表示第二单元的签名正确且第一单元对第二单元的可信验证过程准确,则,第四验证结果表示组合式设备的系统可信。
作为另一个示例,当远程证明模式为混合验证模式时,在混合验证模式下,第一验证结果为第一单元对第二单元进行可信验证的结果,本申请实施例还可以包括:远程证明设备对组合式设备中的第三单元进行可信验证,获得第五验证结果。那么,本申请实施例还可以包括:远程证明设备根据第一验证结果、第二验证结果、第三验证结果和第五验证结果,生成第六验证结果,第六验证结果用于表征组合式设备的系统可信性;其中,若第一验证结果表示第二单元可信,第二验证结果表示第一单元可信,第三验证结果表示第二单元的签名正确且第一单元对第二单元的可信验证过程准确,第五验证结果表示第三单元可信,则,第六验证结果表示组合式设备的系统可信。
对于混合验证模式,本申请实施例还包括确定由第一单元进行远程证明的单元集合以及由远程证明设备进行远程证明的单元集合,该过程可以是静态配置设定的,也可以是协商确定的。当通过协商确定时,可以是和协商远程证明模式一起确定的;也可以是在确定远程证明模式为混合验证模式后独立确定的,那么,本申请实施例例如可以包括:远程证明设备接收第一单元发送的第一请求消息,第一请求消息用于向远程证明设备请求验证权限;远程证明设备确定验证权限,验证权限指示远程证明设备对第三单元进行可信验证;远程证明设备向第一单元发送第一回应消息,以便第一单元根据验证权限,对第二单元进行可信验证。
需要说明的是,第二方面提供的方法应用于远程证明设备,对应于第一方面提供的应用于组合式设备的方法,故第二方面提供的方法的各种可能的实现方式以及达到的技术效果,可以参照前述第一方面提供的方法的介绍。
第三方面,本申请实施例还提供了一种组合式设备的远程证明装置,应用于组合式设备,该组合式设备包括接收单元、发送单元和处理单元。其中,接收单元用于执行上述第一方面提供的方法中的接收操作;发送单元用于执行上述第一方面提供的方法中的发送操作;处理单元用于执行上述第一方面中除了接收操作和发送操作以外的其他操作,例如:处理单元可以执行第一方面中实施例中的操作:第一单元根据第一度量信息对第二单元进行可信验证,获得第一验证结果。
第四方面,本申请实施例还提供了一种组合式设备的远程证明装置,应用于远程证明设备,该远程证明设备包括接收单元、发送单元和处理单元。其中,接收单元用于执行上述第二方面提供的方法中的接收操作;发送单元用于执行上述第二方面提供的方法中的发送操作;处理单元用于执行上述第二方面中除了接收操作和发送操作以外的其他操作,例如:处理单元可以执行第二方面中实施例中的操作:根据第一消息,获取第一验证结果。
第五方面,本申请实施例还提供了一种组合式设备,包括第一单元和第二单元,其中,第二单元用于将其度量信息发送给第一单元,第一单元用于执行上述第一方面提供的远程证明方法,实现对第二单元的可信验证。
第六方面,本申请实施例还提供了一种组合式设备,包括通信接口和处理器。其中,通信接口用于执行前述第一方面提供的方法中的接收和发送操作;处理器,用于执行前述第一方面提供的方法中除所述接收和发送操作以外的其他操作。
第七方面,本申请实施例还提供了一种组合式设备,该组合式设备包括存储器和处理器。其中,存储器用于存储程序代码;处理器用于运行所述程序代码中的指令,使得该组合式设备执行以上第一方面提供的方法。
第八方面,本申请实施例还提供了远程证明设备,该远程证明设备包括通信接口和处理器。其中,通信接口用于执行前述第二方面提供的方法中的接收和发送操作;所述处理器用于执行前述第二方面提供的方法中除所述接收和发送操作以外的其他操作。
第九方面,本申请实施例还提供了一种远程证明设备,该远程证明设备包括存储器和处理器。其中,存储器用于存储程序代码;处理器用于运行所述程序代码中的指令,使得该远程证明设备执行以上第二方面提供的方法。
第十方面,本申请实施例还提供了一种计算机可读存储介质,该计算机可读存储介质中存储有指令,当其在计算机上运行时,使得所述计算机执行以上第一方面或第二方面提供的所述的组合式设备的远程证明方法。
第十一方面,本申请实施例还提供了计算机程序产品,当其在计算机上运行时,使得计算机执行前述第一方面或第二方面提供的所述的组合式设备的远程证明方法。
附图说明
为了更清楚地说明本申请实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请中记载的一些实施例,对于本领域普通技术人员来讲,还可以根据这些附图获得其他的附图。
图1为本申请实施例中一度量启动的可信性证明过程的结构示意图;
图2为本申请实施例中一应用场景中远程证明的框架示意图;
图3为本申请实施例中一种组合式设备的结构示意图;
图4为本申请实施例中中继模式下一种远程证明方法的信令流程图;
图5为本申请实施例中本地验证模式下一种远程证明方法的信令流程图;
图6为本申请实施例中一种组合式设备的远程证明方法的流程示意图;
图7a为本申请实施例中步骤601的一实现方式的信令流程图;
图7b为本申请实施例中步骤601的另一实现方式的信令流程图;
图7c为本申请实施例中步骤601的再一实现方式的信令流程图;
图8为本申请实施例中度量信息基准值的生成过程示意图;
图9a为本申请实施例中步骤602的一实现方式的信令流程图;
图9b为本申请实施例中步骤602的另一实现方式的信令流程图;
图10为本申请实施例中步骤603的一实现方式的信令流程图;
图11为本申请实施例中另一种组合式设备的远程证明方法的流程示意图;
图12为本申请实施例中又一种组合式设备的远程证明方法的流程示意图;
图13为本申请实施例中步骤1201的一实现方式的信令流程图;
图14为本申请实施例中再一种组合式设备的远程证明方法的流程示意图;
图15a为本申请实施例中一种远程证明模式的协商方法的信令流程图;
图15b为本申请实施例中另一种远程证明模式的协商方法的信令流程图;
图16a为本申请实施例中又一种远程证明模式的协商方法的信令流程图;
图16b为本申请实施例中再一种远程证明模式的协商方法的信令流程图;
图17a为本申请实施例中主单元状态切换时的一种远程证明方法的信令流程图;
图17b为本申请实施例中主单元状态切换时的另一种远程证明方法的信令流程图;
图18为本申请实施例中子单元更新时的一种远程证明方法的信令流程图;
图19a为本申请实施例中主单元度量信息改变时的一种远程证明方法的信令流程图;
图19b为本申请实施例中主单元度量信息改变时的另一种远程证明方法的信令流程图;
图20为本申请实施例中一种组合式设备的远程证明方法的流程示意图;
图21为本申请实施例中另一种组合式设备的远程证明方法的流程示意图;
图22为本申请实施例中一种组合式设备的远程证明装置的结构示意图;
图23为本申请实施例中另一种组合式设备的远程证明装置的结构示意图;
图24为本申请实施例中一种组合式设备的结构示意图;
图25为本申请实施例中另一种组合式设备的结构示意图;
图26为本申请实施例中又一种组合式设备的结构示意图;
图27为本申请实施例中一种远程证明设备的结构示意图;
图28为本申请实施例中另一种远程证明设备的结构示意图。
具体实施方式
为了使得本申请实施例的介绍更加清楚,在介绍本申请实施例之前,先对可信验证的一些基本概念以及过程进行简要说明。
可以理解的是,网络设备中具有可信平台模块(英文:Trusted Platform Module,简称: TPM),该TPM中存在不可被篡改的、绝对可信且不需要外界维护的可信组件(也称为可信根),是可信验证必不可少的部分。
对某个网络设备的系统可信性验证,具体可以包括:该网络设备中的TPM对该网络设备上的系统启动过程、进程运行过程、配置文件等系统状态进行可信性度量,得到系统可信性的度量信息;基于度量信息验证该网络设备的系统是否可信。
作为一个示例,参见图1所示的启动模型,在启动过程中,网络设备的系统可信性验证过程例如可以包括:第一步,TPM中的可信根为基本输入输出系统(英文:Basic InputOutput System,简称:BIOS)提供信任基础;第二步,BIOS启动,初始化硬件系统,通过调用TPM中的可信根,检查下一阶段要运行的Loader的签名,对该Loader和配置信息进行度量,并将度量信息记录到TPM中;第三步,Loader运行,定位获取操作系统镜像文件,通过调用TPM中的可信根,检查下一阶段要运行的操作系统内核Kernel的签名,对该Kernel进行度量,并将度量信息记录到TPM中;第四步,Kernel运行,启动操作系统和安全应用等,对配置信息进行度量并将度量信息记录到TPM中。可见,在上述网络设备完成启动时,可以进行远程证明,即,由该网络设备根据该TPM记录的度量信息产生报告,并将该报告发送给具有远程证明功能的服务器,由该服务器基于接收到的报告对该网络设备的启动过程进行可信验证,得到验证结果。其中,度量信息至少可以包括:TPM 上计算并保存在平台配置注册表(英文:Platform configuration register,简称PCR)中的 PCR值,通常是指在运行过程中对基线值进行多次扩展后得到的值,具体和运行过程中扩展的次数以及扩展的顺序相关。
可以理解的是,远程证明是指待可信验证的网络设备将度量信息发送给服务器,由服务器基于接收到的度量信息对该待可信验证的网络设备进行远程证明。由于远程证明更易于集中监控网络设备,所以,越来越多的网络设备采用远程证明的方式进行系统可信性验证。其中,网络设备的远程证明例如可以包括:一方面,具有远程证明功能的服务器对网络设备的启动等较为确定的度量过程产生的度量信息进行远程证明;另一方面,具有远程证明功能的服务器对网络设备运行过程中的动态进程产生的度量信息进行远程证明。
参见图2所示的网络模型,该模型示出了远程证明的一种场景。其中,该场景包括:待证明设备Attester 201、验证服务器Verifier 202、中继设备Relying Party(下文中简称RP) 203和供应链实体Asserter 204。其中,Attester 201是指终端、物联网(英文:Internet of Thing,简称:IoT)网关、或应用服务器等需要进行远程证明的网络设备,终端例如可以是:交换机、路由器、个人计算机(英文:personal computer,简称:PC)等;该Attester 201内部可以包括:中央处理器(英文:Central Processing Unit,简称:CPU)&TPM、BOIS、Kernel 和应用(英文:application,简称:app)四部分,用于进行度量信息的计算和记录,也可以称作证明平台Attest Platform。其中,Verifier 202是指具有远程证明功能的服务器,也可以称作证明服务器Attest Server;RP 203是指可以与Attester 201和Verifier 202通信、负责 Attester 201和Verifier 202之间信息交互的设备,例如可以是网络管理设备;供应链实体Asserter 204,例如可以是设备制造商的网络设备。
具体实现时,Verifier 202对Attester 201进行远程证明的过程具体可以包括:S11, Attester 201通过可信根计算并收集自身的度量信息,提供给RP 203;S12,RP 203接收Attester 201发送的度量信息,并通过签名认证的方式验证Attester 201的身份;S13,RP 203 对Attester 201的身份验证通过后,RP 203将Attester 201的度量信息用RP 203自己的证书进行签名,并发给Verifier 202;S14,Verifier 202对RP 203的身份验证通过后,Verifier 202 基于度量信息验证Attester 201是否可信,并将验证结果发送给RP203,以便客户或者技术人员可以知悉Attester 201的系统可信状况。而在S14之前,Asserter 204用于为Attester 201提供初始的设备ID等配置信息,而且该Asserter 204上也具有Attester 201的基线值以及PCR参考值;Assester 204可以将Attester 201的基线值以及PCR参考值发送给Verifier 202,作为该Verifier 202对Attester 201进行远程证明的依据。其中,基线值是指对Attester 201上的软件包进行哈希计算得到的摘要,一般为一个固定的值;PCR参考值,是指启动等确定的度量过程中,对基线值进行确定顺序和确定次数的扩展后得到的值,作为对确定的度量过程进行可信验证的标准。
需要说明的是,为了保证整个远程证明交互过程中设备和通信的安全性,一方面,可以默认本申请实施例中的Verifier是绝对安全和可信的设备,即,该Verifier具有对网络设备进行可信验证的资格。另一方面,必须预先部署好证书机制(包括证书申请和吊销等),以支持交互过程中证书的校验和查看等必要操作,具体而言,Attester 201使用从隐私证书授权(英文:certificate authority,简称:CA)服务器205申请到的证书,对其记录的度量信息进行加密和签名,Verifier 202对收到的信息解密,并与隐私证书授权服务器205交互以校验Attester 201的证书是否合法。用户可以查看到隐私证书授权服务器205对外颁发的证书,并能查看Verifier 202对Attester 201的远程证明结果。
其中,具有远程证明功能的服务器(下文中以Verifier为例进行描述),可以通过网络配置协议(英文:Network Configuration Protocol,简称:NETCONF)的挑战-响应方式对网络设备(下文中以Attester为例进行描述)进行远程证明,远程证明的相关信息可以通过又一代(英文:YetAnother Next Generation,简称:YANG)数据模型进行描述。
需要说明的是,Verifier在本申请实施例中,指负责对Attester进行远程证明的设备,一种情况下,该Verifier可以是指同时部署RP203和Verifier 202功能的设备;另一种情况下,该Verifier也可以是指具有直接和Attester 201进行数据交互功能的设备。也就是说,本申请实施例中的Attester 201只需要关注Verifier 202即可,在后续说明中,不再对RP 203 和Attester 201、以及RP 203和Verifier 202之间的信息交互过程予以说明,只涉及Attester 201和Verifier 202直接交互的说明。
需要说明的是,本申请实施例中的相关说明可以参见:draft-birkholz-rats-architecture-01 和draft-birkholz-rats-reference-interaction-model-00的相关描述。
目前,很多场景中的网络设备,包括多个独立的组件或单元(下文中称为单元),称为组合式设备,例如:交换机、路由器等。组合式设备的单元中,一部分单元内置有信任计算基础(英文:Trusted Computing Base,简称:TCB)模块,另一部分单元内不包括TCB 模块的单元。TCB模块,相当于上文网络设备中TPM,用于对其所在的单元上的系统启动过程、进程运行过程、配置文件等进行计算和记录,从而得到表征可信性的度量信息。由于只有内置有TCB模块的单元,才能够产生度量信息、需要进行可信验证,而不包括 TCB模块的单元,不会影响该组合式设备的可信验证,所以,本申请实施例中组合式设备中的单元,特指内置有TCB模块的单元,不涉及不具有TCB模块的单元。
其中,组合式设备可以包括:主单元(英文:Leader unit)和子单元(英文:Subsidiary unit)。其中,主单元上具有可以直接和外部设备进行交互的通信接口,子单元则不具有可以和外部设备直接交互的通信接口的单元,子单元需要通过内部互联结构以及主单元的通信接口实现和外部设备的交互。可以理解的是,通信接口,是指能够实现和外部设备通信的物理接口,例如可以是管理接口,以组合式设备为路由器为例,该路由器通过管理接口和网管相连,路由器即可通过该管理接口和网管进行交互,例如:通过该管理接口向网管下发配置信息、网管通过该管理接口查询路由器的运行状态等。
举例来说,当组合式设备为路由器时,主单元可以是指路由器的主控板,为了提高该路由器的可靠性,通常会在路由器中部署两个主控板,一个主控板处于激活态(即,工作状态),当激活态的主控板不可用时,另一个备用态的主控板即可接替原激活态的主控板继续工作,这样,该路由器不会因为一个主控板不可用就整体重启或宕机,影响整个网络的运行。子单元可以是指路由器的插卡、基卡、线卡、增值业务板,其中,线卡通常可以指转发板,而插卡可以指在转发板上扩展的子卡,基卡是指基本的转发单元,增值业务板例如提供英特网协议安全性(英文:Internet Protocol Security,简称:IPSec)的业务板。
参见图3所示,为一种组合式设备的示意图,该组合式设备300可以包括:主单元311、主单元312、以及多个子单元321、322、……,其中,主单元311和主单元312,具有可以直接和外部设备进行交互的通信接口,而且集成有TCB模块的单元;子单元321、 322、……上,集成有TCB模块,但不具有可以和外部设备直接交互的通信接口,只能通过内部互联结构330以及主单元311或主单元312上的通信接口实现和外部设备的交互。
由于组合式设备的启动或运行等行为包括了各主单元和子单元的启动或运行等行为,所以,验证组合式设备的系统可信性,需要对其包括主单元和各子单元的可信性进行分别验证,当主单元和各子单元全部可信,才可以确定该组合式设备的系统可信。
基于此,随着信息爆发式的增长以及万物互联的盛况,为了提供安全、可靠的网络环境,亟待提供一种对组合式设备的远程证明方式,实现对网络中的组合式设备进行严格的可信验证,以满足目前对组合式设备以及包括组合式设备的网络逐渐提高的可信性要求。
作为一个示例,在图2所示的场景中,假设图2中的Attester 201为具有图3所示结构的组合式设备,参见图4,Verifier 202对Attester 201进行远程证明的过程可以包括:S21, Verifier 202向Attester 201发起远程证明请求消息(也称为发起证明挑战),该远程证明请求消息用于触发一次对Attester 201的远程证明;S22,Attester 201将所有单元的度量信息携带在远程证明回应消息中,发送给Verifier 202,其中,备用态的主单元312和各子单元 321、322、……将其度量信息发送给激活态的主单元311,由该激活态的主单元311将接收到的度量信息以及自己的度量信息携带在远程证明回应消息中,通过该激活态的主单元 311上的通信接口发送给Verifier 202;S23,Verifier 202从所接收到的远程证明回应消息中,获得激活态的主单元311、备用态的主单元312以及各子单元321、322、……的度量信息,并基于其上保存的该Attester 201的各单元的PCR参考值或者基线值,验证Attester 201提供的度量信息,获得各单元的验证结果;S24,Verifier 202基于各单元的验证结果,确定Attester 201的系统可信性的验证结果。
可以理解的是,上述图4示出的组合式设备的远程证明方法,组合式设备中所有单元的可信验证均需要由Verifier执行,如果网络中的组合式设备增多,且组合式设备中包括较多的单元,则,在上述远程证明方法执行时,需要与Verifier进行交互的报文数量会呈指数增长,增加了该Verifier的负载。例如:假设在网络中增加了一个包括10个子单元和 2个主单元的组合式设备,其他部分不变,则,利用图4所示的实施例进行远程证明,该组合式设备需要和Verifier交互12个实体(包括10个子单元以及2个主单元)在度量过程的相关信息,对于Verifier而言,相当于要增加12个实体的负载。
基于此,本申请实施例提供了一种组合式设备的远程证明方法,该组合式设备中的主单元具有远程证明功能,可以对其所属的组合式设备内的其他单元进行可信验证,那么,组合式设备的主单元可以直接将其他单元的可信验证结果发送给Verifier,Verifier只需要接收其他单元的验证结果即可,不再需要接收各个单元的度量信息并分别对各个单元进行可信验证。还以在网络中增加了一个包括10个子单元和2个主单元的组合式设备为例,在该实现方式下,如果10个子单元和1个主单元均由组合式设备中的另一个主单元进行可信验证,那么,对于Verifier而言,只需要接收组合式设备中的主单元发送的验证结果即可,相当于只要增加1个实体(即,主单元)的负载,而且,Verifier和组合式设备就远程证明过程需要交互的数据量能够大大降低。
作另为一个示例,仍然以图2所示的场景为例,假设图3所示的组合式设备为图2中的Attester 201,则,参见图5,Verifier 202对Attester 201进行远程证明的过程可以包括: S31,Verifier 202向主单元311发送度量请求消息1,该度量请求消息1可以视作采用挑战 -响应方式进行远程证明时的“挑战”,用于请求该组合式设备进行可信验证;S32,主单元 311向Verifier 202发送请求消息1,该请求消息1用于请求获取主单元312、子单元321、 322、……可信验证的依据,例如:对于启动等度量过程较为确定的过程,该可信验证的依据可以是PCR参考值,又例如:对于启动后其他度量过程难以确定的过程,该可信验证的依据可以是不随度量过程变化而改变的标准的基线值A;S33,Verifier 202将主单元312、子单元321、322、……对应的PCR参考值1和/或基线值A携带在响应消息1中,发送给主单元311,其中,基线值A以及PCR参考值1为各单元可信的基线值和PCR参考值; S34,主单元311分别向主单元312、子单元321、322、……发送度量请求消息2,分别用于向主单元312、子单元321、322、……请求其度量信息,该度量信息至少包括各单元的 TCB模块中记录的PCR值1,此外,该度量信息还可以包括度量日志,该度量日志中记录有基线值a以及基于基线值a进行扩展得到PCR值1的过程信息;S35,主单元312、子单元321、322、……分别将其度量信息携带在度量回应消息2中,发送给主单元311;S36,主单元311对主单元312、子单元321、322、……分别进行可信验证,获得验证结果1,具体而言,一种情况下,对于确定的度量过程,主单元311比较各单元的PCR值1和PCR 参考值1是否一致;另一种情况下,对于无法确定的度量过程,主单元311先基于度量日志计算出PCR值2,即,通过对基线值a按照度量日志记录的过程信息计算出PCR值2,比较PCR值1和PCR值2是否一致,以及比较度量日志中的基线值a和基线值A是否一致;S37,主单元311将验证结果1携带在度量回应消息1中,发送给Verifier 201,其中,度量回应消息1可以视作采用挑战-响应方式进行远程证明时的对“挑战”的“响应”,即,对S31中度量请求消息1的响应消息。
需要说明的是,该图6所示的对组合式设备的远程证明方法中,S32~S33和S34~S35 的执行不限定先后顺序,可以如上所示的先执行S32~S33再执行S34~S35,也可以先执行 S34~S35之后再执行S32~S33,还可以同时执行这两部分。而且,S31可以在S37之前的任何时机执行。
需要说明的是,一种情况下,在每次远程证明的过程中,可以都执行S32~S33,为该次远程证明提供可靠的数据基础;另一种情况下,在多次远程证明的过程中,也可以只执行一次S32~S33,并将PCR参考值(或PCR参考值和基线值A)保存在主单元本地,在之后的远程证明过程中,直接从本地读取即可。
可以理解的是,上述场景仅是本申请实施例提供的一个场景示例,本申请实施例并不限于此场景。
下面结合附图,通过实施例来详细说明本申请实施例中一种组合式设备的远程证明方法及相关设备的具体实现方式。
可以理解的是,通过赋予组合式设备Attester中的主单元特定的功能——能够对其所属的组合式设备中的其他单元进行可信验证,可以有效的减少在远程证明过程中组合式设备Attester和远程证明服务器Verifier之间的交互数据量,减轻Verifier的负担。
在一些可能的实现方式中,Verifier和Attester之间支持多种远程证明模式,例如:中继(英文:Relay)模式、本地验证(英文:Proxy)模式和混合验证(英文:Mixed)模式。其中,中继模式下,由Verifier对组合式设备Attester内的主单元以及多个子单元进行可信验证;本地验证模式下,由Attester内的主单元对该Attester中的所有子单元进行可信验证;混合验证模式下,由Attester内的主单元对该Attester中的部分子单元进行可信验证,由 Verifier对该Attester中的其他子单元进行可信验证。
为了确保远程证明可以有序执行,在进行远程证明之前,Verifier和Attester之间可以先确定采用的远程证明模式。确定采用远程证明的方式,作为一个示例,可以通过在Attester 和Verifier上进行本地静态配置的方式,确定接下来的远程证明采用的远程证明模式,例如,在Attester和Verifier上同时配置远程证明模式为本地验证模式,那么,接下来Attester 和Verifier之间的远程证明过程将采用本地验证模式;作为另一个示例,也可以通过Attester 和Verifier之间进行协商的方式,确定接下来的远程证明采用的远程证明模式,例如,Attester 通过消息告知Verifier接下来可以采用本地验证模式和混合验证模式,请求Verifier确定具体的远程证明模式,Verifier回复确定采用混合验证模式,那么,通过协商确定接下来Attester 和Verifier之间的远程证明过程将采用混合验证模式,通过协商确定远程证明模式的具体过程可以参见下述图16a~图16b所示实施例。
具体实现时,作为一个示例,当确定的远程证明模式为中继模式,则,可以按照图4所示的实施例进行远程证明。作为另一个示例,当确定的远程证明模式为混合验证模式,具体可以参见下述图12所示的实施例的相关说明。作为再一个示例,当确定的远程证明模式为本地验证模式,则,可以按照上述图3所示的实施例进行远程证明,具体也可以参见下述图6所示实施例的相关说明。
图6为本申请实施例中一种组合式设备的远程证明方法的流程示意图。参见图6,该方法应用于包括Attester和Verifier的网络中,且已知该Attester为组合式设备,该Attester 中包括单元10和单元20,其中,单元10具体可以是图3的组合式设备300中处于激活态的主单元311,单元20具体可以是图3的组合式设备300中处于备用态的主单元312、子单元321、322、……中的任意一个单元。在组合式设备采用本地验证模式进行远程证明的情况下,处于激活态的主单元10需要对Attester中的其他所有单元均执行下述方法,以主单元10对单元20进行可信验证为例,该方法具体可以包括下述步骤601~步骤605:
步骤601,单元10获得单元20的度量信息1。
可以理解的是,单元10是指具有对其所属的组合式设备中的其他单元进行可信验证功能的主单元,例如可以是交换机或路由器的控制面;单元20是指可以通过单元10或者Verifier进行可信验证的单元,例如可以是交换机或路由器的控制面,也可以是交换机或路由器的转发面。
度量信息1,可以是指Attester中的单元20在运行过程产生的、用于验证该单元20可信性的信息。一种情况下,对于较为确定的度量过程,例如启动过程,度量信息1具体可以包括PCR值1,该PCR值1具体可以是单元20内置的TCB模块当前记录的PCR值。另一种情况下,对于不能够确定的度量过程,例如:启动后的运行过程,度量信息1除了包括PCR值2之外,还可以包括度量日志,其中,PCR值2可以是单元20内置的TCB 模块当前记录的PCR值,该度量日志中记录有基于基线值a进行扩展得到PCR值2的过程信息(例如:对该基线值a的扩展顺序和扩展次数)以及基线值a。其中,PCR值1和 PCR值2均是在对应的度量过程中TCB模块基于基线值a和过程信息计算得到的,具体数值和度量过程中扩展的次数以及扩展的顺序相关。
作为第一个示例,步骤601中单元10获得单元20的度量信息1,具体可以是单元20主动发送给单元10的,例如,参见图7a,步骤601具体为:S40,单元20向单元10发送度量请求消息1,该度量请求消息1中包括度量信息1,该度量请求消息1用于请求该单元10对单元20进行可信验证,那么,该单元10接收度量请求消息1后,即可通过解析该度量请求消息1,获得度量信息1。
可以理解的是,度量请求消息1具体可以是NETCONF协议下的消息,该度量请求消息1具体可以携带下述信息:随机数Nonce、签名使用的证书aik、使用aik证书对RCR 值进行签名的结果quote、PCR支持的哈希算法PcrBanks以及度量日志EventLog等。其中, Nonce可以是单元10生成并预先发送给单元20的随机数,用作安全校验;aik可以是根据单元10之前发送的签名使用的证书类型aikType确定的IAK或LAK证书的内容;PcrBanks 具体可以取SHA1或SHA256等哈希算法;EventLog中具体记录了对该单元20中各个进程的度量过程,例如对基线值a的扩展次数以及扩展顺序。
其中,该度量请求消息1可以定时触发也可以人工配置触发。
需要说明的是,本申请实施例中的涉及的各消息,例如:度量请求消息1以及下述的度量回应消息1、请求消息1、响应消息1、消息1、模式协商请求消息1、模式协商回应消息1等,作为一个示例,可以使用传输控制协议/用户数据报协议(英文:Transmission ControlProtocol/User Datagram Protocol,简称:TCP/UDP)、端口以及路由器通告(英文:RouterAdvertisemen,简称:RA)下的消息,那么,各种消息携带的内容,可以通过该类型消息中标准的类型长度值(英文:Tag Length Value,简称:TLV)格式字段或者和TLV 格式类似的字段(例如:在标准的TLV格式字段基础上增加一些特定字段)携带。作为另一个示例,也可以使用超文本传输安全协议(英文:Hyper Text Transfer Protocol overSecureSocket Layer,简称:HTTPS)以及端口号下的消息,那么,可以通过统一资源定位符(英文:Uniform Resource Locator,简称:URL)区分不同的消息类型,并在请求或响应(或回应、应答)相关消息中定义消息字段。
本申请实施例中,消息例如可以通过RAType字段定义,例如:可以通过设置RAType字段中的值为1,表示该消息为上述度量请求消息1。而各消息中携带信息的定义,例如:度量信息,可以通过标准TLV字段或者类似TLV字段定义,标准TLV字段或者类似TLV 字段中具体可以包括:MsgType、MsgLen和MsgContext字段,其中,可以通过设置MsgType 字段取值为1,表示该TLV字段用于指示PCR值,该TLV中的MsgContext字段的取值用于表示PCR值的具体数值;也可以通过设置MsgType字段取值为2,表示该TLV字段用于指示度量日志,该TLV中的MsgContext字段的取值用于表示基线值以及基线值的扩展顺序以及扩展次数。
作为第二个示例,步骤601中单元10获得单元20的度量信息1,也可以是单元10向单元20发送请求,单元20响应该请求向单元10发送度量信息1,例如,参见图7b,步骤601可以包括:S41,单元10向单元20发送度量请求消息2,该度量请求消息2用于请求单元20发送度量信息1;S42,单元20向单元10发送度量回应消息1,该度量回应消息1中包括单元20的度量信息1,该度量回应消息1为度量请求消息2的响应消息;那么,该单元10接收度量回应消息1后,即可通过解析该度量回应消息1,获得度量信息1。
可以理解的是,度量请求消息2中具体可以携带下述信息:Nonce、请求的PCR值的列表PCRs以及aikType等。其中,Nonce为该单元10生成的随机数,发送给单元20,用于防止恶意攻击,进行安全校验,aikType用于携带IAK或LAK证书类型。度量回应消息 1中具体可以携带信息以及相关解释详见上述第一个示例中对于度量请求消息1的相关说明。
需要说明的是,该度量请求消息2中也可以不包含PCRs,那么,度量回应消息1需要返回TCB模块记录的所有PCR值。
其中,该度量请求消息2可以定时触发也可以人工配置触发。
作为第三个示例,步骤601中单元10获得单元20的度量信息1,也可以是单元20向单元10发送一个请求,作为回复,单元10向单元20发送另一个请求,单元20响应该另一个请求向单元10发送度量信息1,例如,参见图7c,步骤601可以包括:S43,单元20 向单元10发送度量请求消息3,该度量请求消息3用于指示单元10获取单元20的度量信息1;S41,单元10向单元20发送度量请求消息2,该度量请求消息2用于请求单元20 发送度量信息1;S42,单元20向单元10发送度量回应消息1,该度量回应消息1中包括单元20的度量信息1,该度量回应消息1为度量请求消息2的响应消息;那么,该单元 10接收度量回应消息1后,即可通过解析该度量回应消息1,获得度量信息1。
需要说明的是,上述三个示例实现步骤601时,触发执行步骤601的方式可以是:人工配置触发或者定时周期(例如:2小时)触发;对于第一个示例和第三个示例,还可以是由单元20启动触发的,即,当单元20启动时,触发按照第一种示例或第三种示例执行步骤601。
可以理解的是,通过步骤601,单元10获得了待进行可信验证的单元20的度量信息1,为该单元10对单元20的可信验证提供了数据基础。
步骤602,单元10获得单元20的度量信息2。
度量信息2,是指Attester中的单元20可信时其度量信息1应该符合的标准或者依据。一种情况下,当度量过程为启动等较为确定的过程时,对基线值的扩展顺序和扩展次数较为固定,对基线值进行确定顺序和确定次数的扩展后得到的值也是一个固定的值,那么,该固定的值即可作为PCR参考值,用作校验该确定的度量过程的标准,该情况下,度量信息2可以包括PCR参考值。另一种情况下,当度量过程为启动以外的不能确定的其他度量过程时,对基线值的扩展顺序和扩展次数无法固定,那么,可以将固定的基线值用作校验该度量过程的标准,该情况下,度量信息2可以包括该基线值。
通常,度量信息2是在研发阶段,针对软件包中的各个软件生成的。图8示出了度量信息基准值的生成过程,参见图8,可以包括:研发阶段、发布阶段和下载阶段。其中,在研发阶段,具体可以包括:第一步,构建软件包,例如:软件包括不限于:基本输入输出系统(英文:Basic Input Output System,简称:BIOS)、启动装载(英文:Bootloader)、操作系统(英文:Operating System,简称:OS)等;第二步,生成该软件包中各个软件的度量信息2;第三步,为度量信息2进行数字签名保护。此时,进入发布阶段,可以将生成的数字签名保护后的度量信息2发布到可靠的支持(英文:Support)网站上,以便各个 Verifier从该Support网站上下载该度量信息2。那么,Verifier可以从Support网站上下载度量信息2,具体过程可以包括:第一步,Verifier下载数字签名保护后的度量信息2;第二步,对度量信息2的数字签名进行验签;第三步,将度量信息2保存至该Verifier中。
需要说明的是,一种情况下,度量信息2可以保存在Verifier上,也可以保存在供应商或制造商设备Assester上,还可以保存在第三方可信的服务器上,那么,Verifier、Assester 和第三方可信的服务器,可以统称为保存度量信息基准值的设备。另一种情况下,度量信息2也可以预置在软件包中,当组合式设备的主单元加载该软件包时,就可以随之获得该度量信息2。
在第一种可能的实现方式中,步骤602中单元20的度量信息2,可以是单元10向保存度量信息2的设备获取的。下文中以保存度量信息2的设备为Verifier为例进行说明,Assester或第三方可信的服务器的实现方式可以参见下述描述。
作为一个示例,若单元10上保存有其他所有单元的标识信息,也即,单元10上保存有单元20的标识信息1,标识信息1用于唯一标识单元20。参见图9a,步骤602具体可以包括:S51,单元10向Verifier发送请求消息1,该请求消息1中携带单元20的标识信息1,该请求消息1用于请求获取单元20的度量信息2;S52,Verifier解析该请求消息1,获得单元20的标识信息1,并从其上保存的度量信息中,查找并确定单元20的标识信息 1对应的度量信息2;S53,Verifier向单元10发送响应消息1,该响应消息1中携带度量信息2;S54,单元10通过解析响应消息1,获得度量信息2。
其中,单元20的标识信息1具体可以包括单元20的标识符,用于唯一标识该单元20。单元20的标识符例如可以包括:单元20的索引、单元20的名称等,单元20的索引可以是YANG文稿中对单元20的定义,通过数字表示,作为物理索引可以唯一标识单元20;单元20的名称,通过字符串表示,那么,单元20的索引相比单元20的名称,可以更快的确定出对应的单元20。进一步,单元20的标识信息1还可以包括单元20的版本信息,单元20的版本信息具体可以指示软件版本号和/或单元20的类型(例如:板卡型号)。当单元20中的软件版本发生变化时,度量信息2可能也发生变化,版本信息会发生对应的变化,但单元20的名称和索引可能并不会更新,那么,该情况下,单元20的标识信息1 中必须携带版本信息,再携带名称和索引中的至少一个。
作为另一个示例,若单元10上未保存各个单元20的标识信息1,则,步骤602除了包括上述S51~S54以外,参见图9b,在S51之前,还可以包括:S501,单元10向单元20 发送请求消息2,该请求消息2用于请求获取单元20的标识信息1;S502,单元20向单元10发送响应消息2,该响应消息2中携带单元20的标识信息1。
可以理解的是,通过上述两个示例,单元10能够从Verifier上动态的获取到单元20 的度量信息2。一种方式下,单元10可以在每次进行远程证明时,均执行从Verifier上获取单元20的度量信息2的步骤,并基于该次获取到的度量信息2对单元20进行远程证明,如此,可以有效的避免度量信息2这一远程证明的依据被恶意篡改,使得远程证明的标准发生改变,导致远程证明的验证结果不可靠的问题,每次都重新从Verifier上动态获取该度量信息2,确保了远程证明的标准的可靠性,从而提高了本实施例提供的组合式设备的远程证明的安全性。另一种方式下,单元10可以只在第一次进行远程证明时执行一次从 Verifier上获取单元20的度量信息2的步骤,并将该度量信息2永久地保存在本地的安全存储空间中,之后的远程证明过程中,从本地获得该度量信息2并对单元20进行远程证明即可,如此,无需再在每次远程证明时都向Verifier请求度量信息2,能够大大的降低单元10和Verifier之间的交互数据量。再一种方式下,也可以周期性的获取度量信息2,即,单元10从Verifier获取一次度量信息2后,将其保存并在预设周期(例如:48小时)使用该度量信息2对单元20进行可信验证,下一个周期,重新从Verifier上下载一次度量信息 2’,用最新下载的该度量信息2’更新本地保存的度量信息2,并在该周期内使用更新后的度量信息2对单元20进行远程证明,以此类推,如此,可以一定程度上确保该度量信息2 的有效性和可靠性,提高了单元10对单元20可信验证的安全性。
需要说明的是,在步骤602之前,为了确保远程证明的可靠性,Verifier可以只对确定可信的单元10发送度量信息2,即,在Verifier向单元10发送度量信息2之前,Verifier可以先对单元10进行可信验证,具体过程可以包括:第一步,单元10将自己的度量信息 3发送给Verifier;第二步,Verifier根据度量信息3对该单元10进行可信验证,获得验证结果2。其中,第一步的度量信息3具体可以携带在上述请求消息1中,也可以携带在其他消息中发送给Verifier,只要在Verifier向单元10发送单元20的度量信息2之前执行均可。具体实现时,若Verifier根据验证结果2确定单元10可信,则,该Verifier才主动向单元10提供单元20的度量信息2,或者,该Verifier才响应单元10的请求向单元10提供单元20的度量信息2;若Verifier根据验证结果2确定单元10不可信,那么,该Verifier 需要将该验证结果2反馈给用户能够查看的设备(例如:RP)上,以告知用户该组合式设备的单元10不可信。
在第二种可能的实现方式中,步骤602中单元20的度量信息2,也可以是单元10从其本地的安全存储空间中获得的。而本地的该度量信息2,一种情况下,可以是预先从Verifier等保存有度量信息2的设备上下载并保存的,具体实现方式可以参见第一种实现方式的相关描述;另一种情况下,也可以是人工静态配置在单元10的本地安全存储空间的;再一种情况下,还可以是在加载软件包时单元10直接获取并保存在本地安全存储空间的。
其中,人工静态在该单元10上配置单元20的度量信息2,具体可以是技术人员从Verifier或者Support网站等保存度量信息2的位置查找该单元20的度量信息2,并将其手动配置至该单元10的安全存储空间中。
单元10在加载软件包时直接获取并保存度量信息2,具体可以是:软件包中预置了单元20的度量信息2,当单元10加载该软件包时,即可获得该软件包中预置的单元20的度量信息2,那么,单元10即可将其保存在本地的安全存储空间中。
可以理解的是,单元10的本地安全存储空间,是指单元10中被限制访问或者不可被篡改的物理空间。例如:只有远程证明(英文:Remote Attestation,简称:RAT)相关进程或者运行进程实现RAT的模块(称为:RAT组建)才能够访问的物理空间,能够作为安全存储空间保存度量信息基准值1;又例如:单元10的TPM中包括的存储区域,如,实体的TPM芯片中的存储区域,或者,单元10中的软件隔离区域(也称为:虚拟可信平台模块,英文:VirtualTrusted Platform Module,简称:VTPM),该TPM包括的存储区域和单元10的其他存储空间采用TrustZone等技术进行隔离,该TPM包括的存储区域中保存的该度量信息2不能被篡改。
如此,单元10的本地保存有单元20的度量信息2,在单元10需要对单元20进行远程证明时,即可直接从本地获得该单元20的度量信息2,无需再通过和Verifier的交互获得单元20的度量信息2,大大的降低了单元10和Verifier的交互数据量,减轻了Verifier 的负担,一定程度上可以提高对该组合式设备的远程证明效率。
可以理解的是,通过步骤602,单元10获得了待进行可信验证的单元20的度量信息2,为该单元10对单元20的可信验证提供了可靠的依据,使得该单元10对单元20进行可信验证成为可能。
需要说明的是,步骤61和步骤602的执行没有先后顺序的限定,可以先执行步骤601 再执行步骤602,也可以先执行步骤602再执行步骤601,或者,还可以同时执行步骤601和步骤602。
步骤603,单元10根据度量信息1和度量信息2,对单元20进行可信验证,获得验证结果1。
可以理解的是,单元10在获得单元20的度量信息1以及其对应的度量信息2之后,即可将度量信息1和度量信息2两者进行比较,判断是否存在异常情况,生成验证结果1。
作为一个示例,当度量过程较为确定时,度量信息1可以包括PCR值1,度量信息2可以包括PCR参考值,那么,步骤603具体可以包括:单元10比对PCR值1和PCR参考值是否一致,生成验证结果1。若PCR值1和PCR参考值一致,则,验证结果1表示通过单元10的可信验证确定该单元20可信;否则,若PCR值1和PCR参考值不一致,则,验证结果1表示通过单元10的可信验证确定该单元20不可信。
作为另一个示例,当度量过程不能够确定时,度量信息1可以包括PCR值2和度量日志,度量信息2可以包括基线值,那么,步骤603具体可以包括:第一步,单元10基于度量日志,计算PCR值3;第二步,单元10对比PCR值3和PCR值2是否一致,得到比较结果1;第三步,单元10对比度量日志中的基线值和度量信息2中的基线值是否一致,得到比较结果2;第四步,基于比较结果1和比较结果2,生成验证结果1。其中,若比较结果1和比较结果2均为一致,则,验证结果1表示通过单元10的可信验证确定该单元 20可信;否则,若比较结果1和比较结果2中的至少一个为不一致,则,验证结果1表示通过单元10的可信验证确定该单元20不可信。
其中,验证结果1,具体可以包括用于表征单元20可信或不可信的信息,还可以包括:基于度量信息1和度量信息2进行可信验证过程的对比信息;此外,该验证结果1还可以包括:导致该单元20不可信的可信验证过程的日志,以便让Verifier知晓单元10对单元 20的可信验证失败的具体原因。
步骤604,单元10将验证结果1携带在消息1中发送给Verifier。
步骤605,Verifier从消息1中获得验证结果1。
可以理解的是,单元10得到每个单元20的验证结果1后,即可基于该验证结果1生成该单元20对应的消息1,并将该消息1发送给Verifier,该消息1用于指示单元10对其所属的组合式设备内的单元20的验证结果1。具体实现时,Verifier接收到单元10发送的消息1后,可以通过解析该消息1,获得验证结果1。
作为一个示例,该消息1也可以是对于度量请求消息4的度量回应消息2,那么,在度量回应消息2之前的任何时刻,参见图10,本申请实施例还包括:S61,Verifier向单元 10发送度量请求消息4,度量请求消息4用于请求对组合式设备进行可信验证;S62,单元10向Verifier反馈度量回应消息2。该示例中,度量请求消息4中携带下述信息:Nonce、 PCRs、aikType等。如果该度量请求消息4中不包含PCRs,单元10中需要返回所有PCR 值。该度量请求消息4可以定时触发也可以人工配置触发。度量回应消息2中可以携带下述信息:Nonce、aik、quote、PcrBanks、EventLog等。同时,还可以携带单元20的标识信息1以及验证结果1(可以表示为Unit-RAResult)。
作为另一个示例,该消息1也可以是度量结果通知消息,用于告知单元10对单元20的可信验证的结果。该消息1携带的内容以及具体的作用可以参见度量回应消息2的相关描述。
另外,为了减少和Verifier进行通信的次数,节约网络资源,单元10可以在获得对组合式设备中的其他所有单元的验证结果后,基于所有验证结果,生成消息1,并将该消息1发送给Verifier,该消息1用于指示单元10对其所属的组合式设备内的其他单元的验证结果。
如此,在对组合式设备进行远程证明时,该组合式设备中的单元10可以对该组合式设备中的其他单元20进行可信验证,并将验证结果发送给Verifier,无需再通过单元10将其他单元20的度量信息发送给Verifier,由Verifier对所有的单元分别进行可信验证,大大的减少了对组合式设备进行可信验证过程中,该组合式设备和Verifier之间交互的数据量,减轻了Verifier的负担,提高了组合式设备进行远程证明的效率。
另外,在Verifier获得单元20的验证结果1后,为了确定该组合式设备的系统可信性,本申请实施例还可以包括:Verifier对单元10进行可信验证以及Verifier对验证结果1的校验,并生成用于表征组合式设备系统可信性的最终验证结果。参见图11,本申请实施例还可以包括下述步骤606~步骤609:
步骤606,单元10将自己的度量信息3发送给Verifier;
步骤607,Verifier根据度量信息3对该单元10进行可信验证,获得验证结果2;
步骤608,Verifier对消息1进行校验,获得验证结果3;
步骤609,Verifier基于验证结果1、验证结果2和验证结果3,生成验证结果4,该验证结果4用于表征组合式设备的系统可信性。
其中,步骤606~步骤607只要在步骤609之前执行即可,例如:可以在步骤605之后执行,也可以在步骤601之前执行。
可以理解的是,Verifier在获得单元10的度量信息3后,可以查找Verifier上保存的该单元10的度量信息4,步骤607的验证过程具体可以参见上述步骤603中单元10对单元20的可信验证过程的描述,在此不再赘述。
对于步骤608,当Verifier接收到单元10发送的消息1中,不仅可以获取到验证结果 1,还可以获取到可信验证过程日志以及单元20的签名,该Verifier可以对该消息1中的内容进行校验,具体而言,一方面,该Verifier可以基于消息1,获得单元20的签名,并确定该单元20的签名是否正确,生成校验结果1;另一方面,该Verifier也可以基于消息 1,获得单元10对单元20的可信验证过程日志,并确定单元10对该单元20的可信验证过程是否准确,生成校验结果2,其中,该校验过程类似步骤603中的可信验证过程,具体描述参见步骤603中对应的说明。基于此,Verifier可以基于校验结果1和校验结果2,生成验证结果3。
其中,当校验结果1表示单元20的签名正确,且校验结果2表示单元10对该单元20的可信验证过程准确,验证结果3就表示Verifier对于验证结果1的校验通过;否则,当校验结果1表示单元20的签名不正确,和/或,校验结果2表示单元10对该单元20的可信验证过程不准确,验证结果3就表示Verifier对于验证结果1的校验不通过。
具体实现时,当Verifier获得验证结果1、验证结果2和验证结果3时,该Verifier即可执行步骤609,即,基于验证结果1、验证结果2和验证结果3生成验证结果4,验证结果4具体可以包括用于表征组合式设备可信或不可信的信息,若组合式设备不可信,则,该验证结果4还可以包括:表征导致该组合式设备不可信的原因的相关信息。一种情况下,若各验证结果1表示对应的单元20均可信,验证结果2表示单元10可信,验证结果3表示单元20的签名正确且单元10对单元20的可信验证过程准确,则,验证结果4表示组合式设备的系统可信;另一种情况下,若满足下述条件中的至少一个:验证结果1表示存在单元20不可信,验证结果2表示单元10不可信,验证结果3表示单元20的签名不正确或单元10对单元20的可信验证过程不准确,则,验证结果4表示组合式设备的系统不可信,且该验证结果4还可以表示出导致该组合式设备的系统不可信的原因,例如:当各验证结果1表示对应的单元20均可信,验证结果2表示单元10可信,验证结果3表示单元20的签名正确但单元10对单元20的可信验证过程不准确,那么,验证结果4不仅表示该组合式设备系统不可信,还表示该由于单元10对单元20的可信验证过程不准确导致该组合式设备系统不可信。
可见,本申请实施例中,在本地验证模式下,组合式设备中的单元10可以对该组合式设备中的其他单元20进行本地可信验证,获得验证结果1后,再将所有单元20的验证结果1发送给Verifier,Verifier无需再去获取众多单元20的度量信息,也无需再对每个单元20进行可信验证,不仅能够大大的减轻了该Verifier的负担,而且可以降低组合式设备和Verifier之间交互的数据量,节约了网络资源。进一步的,Verifier可以对单元10发来的本地验证结果进行校验,并基于此生成对该组合式设备整体的系统可信性验证结果,即,Verifier可以基于很少的信息进行简单的验证过程即可实现对组合式设备的远程证明,确定其系统可信性,实现了对组合式设备方便、快捷和有效的远程证明,从而提高了网络的可靠性和安全性。
图12为本申请实施例中另一种组合式设备的远程证明方法的流程示意图。参见图12,该方法应用于包括Attester和Verifier的网络中,且已知该Attester为组合式设备,该Attester 中包括单元10和单元20,其中,单元10具体可以是图3的组合式设备300中处于激活态的主单元311,单元集20具体可以是图3的组合式设备300中处于备用态的主单元312、子单元321、322、……,单元21可以是备用态的主单元312、子单元321、322、……中的任意一个单元,而单元22可以是备用态的主单元312、子单元321、322、……中除了单元21之外的单元中另一个任意的单元。在组合式设备采用混合验证模式进行远程证明的情况下,以处于激活态的主单元10对单元21进行可信验证、Verifier对单元22进行可信验证为例,该方法具体可以包括下述步骤1201~步骤1207:
步骤1201,单元10和Verifier确定单元集20中,单元21由单元10进行可信验证,单元22由Verifier进行可信验证。
步骤1202,单元10获得单元集20中各单元的度量信息1,该度量信息1包括单元21的度量信息11和单元22的度量信息12。
步骤1203,单元10获得子单元21的度量信息21。
步骤1204,单元10根据度量信息11和度量信息21,对单元21进行可信验证,获得验证结果5。
步骤1205,单元10将度量信息12发送给Verifier。
步骤1206,Verifier根据度量信息12和度量信息22,对单元22进行可信验证,获得验证结果6。
步骤1207,单元10将验证结果5携带在消息2中发送给Verifier。
步骤1208,Verifier从消息2中获得验证结果5,并记录验结果5和验证结果6。
对于步骤1201,一种可能的实现方式下,可以在单元10上预先配置有单元的标识信息,包括单元21的标识信息11,指示在混合验证模式下该单元10需要进行可信验证的单元的集合,该集合中包括单元21,同理,在Verifier上也预先配置有单元的标识信息,包括单元22的标识信息12,指示在混合验证模式下需要Verifier进行可信验证的单元的集合,该集合中包括单元22。如此,在混合验证模式下,单元10和Verifier无需进行额外的协商即可确定出彼此负责可信验证的子单元,节约了远程证明的协商时间,使得该方式下的远程证明更加高效。
另一种可能的实现方式下,也可以在Verifier和单元10之间进行单独协商,确定各自负责可信验证的单元,参见图13,具体可以包括:S71,单元10向Verifier发送请求消息3,该请求消息3用于向Verifier请求验证权限;S72,Verifier向单元10反馈响应消息3,该响应消息3用于指示确定的验证权限;S73,单元10根据响应消息3中的验证权限,确定对单元21进行可信验证。其中,验证权限,可以是指请求Verifier指定在混合验证模式下,组合式设备的所有单元中可以由单元10进行可信验证的单元的集合,单元10根据验证权限可以获知由该单元10自身负责可信验证的具体单元,其中可以包括单元21。
可以理解的是,请求消息3中可以携带该组合式设备内单元集合20的标识信息1,供 Verifier从单元集合20中确定待单元10进行可信验证的子集合,该子集合包括单元21;或者,该请求消息3中也可以携带单元10确定的由自身进行可信验证的候选单元集合20’,为Verifier确定待单元10进行可信验证的子集合提供参考,其中,响应消息3中指示的子集合并不限于候选单元集合20’的范围,一种情况下,子集合中包括的单元可以是候选单元集合20’中的全部或部分单元;另一种情况下,子集合中的单元也可以包括候选单元集合20’之外的其他单元。需要说明的是,当响应消息3中不携带单元的标识信息时,可以认为指示单元10对其他全部单元进行可信验证,该情况下的具体实现方式,可以参见上述图6所示实施例的相关说明。
需要说明的是,该实现方式下,也可以由单元10决定验证权限,即,本申请实施例具体还可以将上述图13中各步骤的执行主体调换,具体可以包括:S71’,Verifier向单元10发送请求消息3’,该请求消息3’用于向单元10请求验证权限;S72’,单元10向Verifier反馈响应消息3’,该响应消息3’用于指示确定的验证权限;S73’,Verifier根据响应消息3’中的验证权限,确定对单元22进行可信验证。具体解释可以参见上述图13中的具体说明。
需要说明的是,一种情况下,只要确定采用混合验证模式,就进行一次针对性的协商,确定单元10和Verifier各自负责进行可信验证的单元集合。另一种情况下,也可以只进行一次协商,将确定的验证权限保存,以便之后在混合验证模式下使用该验证权限进行远程证明。再一种情况下,还可以周期性的进行协商,即,预设协商周期(例如:7天),每个协商周期进行一次协商,确定单元10和Verifier各自负责进行可信验证的单元集合,作为该协商周期内Verifier和单元10对组合式设备的各单元进行远程证明时的分工依据。
在再一种可能的实现方式中,也可以在协商确定远程证明模式时,同时协商确定在混合验证模式下Verifier和单元10各自负责可信验证的单元,具体实现可以参见下述图15a 和图15b所示实施例中的相关描述。
对于步骤1202~步骤1208,具体实现可以参见上述图6所示实施例的相关描述。
需要说明的是,上述步骤1203~步骤1204和步骤1205~步骤1206可以同时执行,也可以先执行步骤1203~步骤1204再执行步骤1205~步骤1206,还可以先执行步骤1205~步骤1206再执行步骤1203~步骤1204。步骤1207只要在步骤1204之后执行即可,即,可以在步骤1204和步骤1205之间执行,也可以在图12所示的位置执行。
另外,在Verifier记录验证结果5和验证结果6后,为了确定该组合式设备的系统可信性,本申请实施例还可以包括:Verifier对单元10进行可信验证以及Verifier对验证结果 5的校验,并生成用于表征组合式设备系统可信性的最终验证结果。参见图14,本申请实施例还可以包括下述步骤1209~步骤1212:
步骤1209,单元10将自己的度量信息3发送给Verifier;
步骤1210,Verifier根据度量信息3对该单元10进行可信验证,获得验证结果2;
步骤1211,Verifier对消息2进行校验,获得验证结果3;
步骤1212,Verifier基于验证结果5、验证结果6、验证结果2和验证结果3,生成验证结果7,该验证结果7用于表征组合式设备的系统可信性。
其中,步骤1209~步骤1210只要在步骤1212之前执行即可,例如:可以在步骤1208之后执行的,也可以在步骤1201之前执行。
需要说明的是,上述步骤1209~步骤1212的实现方式可以参见图11中步骤606~步骤 609的相关说明。
可以理解的是,当Verifier获得验证结果5、验证结果6、验证结果2和验证结果3时,该Verifier即可执行步骤1212,即,基于验证结果5、验证结果6、验证结果2和验证结果3生成验证结果7,验证结果7具体可以包括用于表征组合式设备可信或不可信的信息,若组合式设备不可信,则,该验证结果7还可以包括:表征导致该组合式设备不可信的原因的相关信息。一种情况下,若验证结果5表示单元10进行可信验证的各单元21均可信,验证结果6表示Verifier进行可信验证的各单元22均可信,验证结果2表示单元10可信,验证结果3表示单元21的签名正确且单元10对单元21的可信验证过程准确,则,验证结果7表示组合式设备的系统可信;另一种情况下,若满足下述条件中的至少一个:验证结果5表示存在单元21不可信,验证结果6表示存在单元22不可信,验证结果2表示单元10不可信,验证结果3表示单元21的签名不正确或单元10对单元21的可信验证过程不准确,则,验证结果7表示组合式设备的系统不可信,且该验证结果7还可以表示出导致该组合式设备的系统不可信的原因,例如:当验证结果5表示单元10进行可信验证的各单元21中存在不可信的单元,验证结果6表示各单元22均可信,验证结果2表示单元 10可信,验证结果3表示单元20的签名正确且单元10对单元20的可信验证过程准确,那么,验证结果7不仅表示该组合式设备系统不可信,还表示该由于单元10验证出存在不可信的单元,导致该组合式设备系统不可信。
可见,本申请实施例中,在混合验证模式下,组合式设备中的单元10可以对该组合式设备中的部分单元进行本地可信验证,其余的单元则由Verifier进行可信验证,这样,Verifier无需再对组合式设备中的所有单元进行可信验证,能够一定程度上减轻该Verifier 的负担,降低组合式设备和Verifier之间交互的数据量,节约网络资源。进一步的,Verifier 可以对单元10发来的本地验证结果进行校验,并基于此生成对该组合式设备整体的系统可信性验证结果,即,Verifier可以基于很少的信息进行简单的验证过程即可实现对组合式设备的远程证明,确定其系统可信性,实现了对组合式设备方便、快捷和有效的远程证明,从而提高了网络的可靠性和安全性。
此外,本申请实施例中对组合式设备的远程证明方法中,采用的远程证明模式包括多种,那么,本申请实施例还包括确定远程证明模式的过程。具体实现时,确定远程证明模式的方法包括但不限于下述4种:
作为第一个示例,确定远程证明模式,具体可以是人工预先在组合式设备和Verifier 中配置远程证明模式。那么,即可按照所配置的远程证明模式执行图6或图12所示的实施例对应的远程证明方法;当需要切换远程证明模式时,可以再重新配置新的远程证明模式,并采用该新配置的远程证明模式对组合式设备进行远程证明。
作为第二个示例,远程证明模式,也可以是由第三方设备(例如:控制器或网络管理服务器等)确定并配置到Verifier和单元10上的,指示Verifier和单元10采用该远程证明模式对组合式设备进行远程证明。一种情况下,第三方设备可以将确定的远程证明模式分别下发给Verifier和单元10。另一种情况下,该第三方设备也可以将确定的远程证明模式下发给Verifier,再由Verifier将确定的该远程证明模式发送给单元10。又一种情况下,该第三方设备还可以将确定的远程证明模式下发给单元10,再由单元10将确定的该远程证明模式发送给Verifier。其中,第三方设备和Verifier之间、第三方设备和单元10之间以及Verifier和单元10之间,下发确定的该远程证明模式时,可以采用NETCONF中的消息完成。
作为第三个示例,远程证明模式,也可以不提前确定,而是在Verifier和单元10进行远程证明时,通过交互的消息确定。例如:如果单元10向Verifier发送的消息中携带了其余所有单元的可信验证结果,则,可以视作单元10和该Verifier之间采用了本地验证模式,那么,将该本地验证模式确定为单元10和该Verifier之间的远程证明模式;又例如:如果单元10向Verifier发送的消息中携带了其余所有单元的度量信息,则,可以视作单元10 和该Verifier之间采用了中继模式,那么,将该中继模式确定为单元10和该Verifier之间的远程证明模式;再例如:如果单元10向Verifier发送的消息中携带了部分单元集合的度量信息以及其余单元的可信验证结果,则,可以视作单元10和该Verifier之间采用了混合验证模式,那么,将该混合验证模式确定为单元10和该Verifier之间的远程证明模式。
作为第四个示例,本申请实施例还提供了一种远程证明模式的协商方法,该方法中通过协商的方式确定Verifier和单元10之间采用的远程证明模式。该方法应用于包括Attester 和Verifier的网络中,且已知该Attester为组合式设备,该Attester中包括单元10和单元 20。其中,一种情况下,参见图15a,该远程证明模式具体可以是由Verifier决策的;另一种情况下,参见图15b,该远程证明模式还可以是由单元10确定的。
参见图15a,为本申请实施例中一种远程证明模式的协商方法的信令流程图。该远程证明模式的协商方法,具体可以包括:
步骤15a1,单元10向Verifier发送模式协商请求消息1;
步骤15a2,Verifier向单元10反馈模式协商响应消息1;
步骤15a3,单元10根据模式协商响应消息1,确定远程证明模式。
可以理解的是,一种情况下,该模式协商请求消息1中可以携带候选的程证明模式,候选的程证明模式可以是下述模式中的至少一种:中继模式、本地验证模式和混合验证模式。另一种情况下,该模式协商请求消息1中也可以不携带任何候选的远程证明模式,那么,可以默认该单元10支持任意的远程证明模式,将远程证明模式的决策权完全交给Verifier。
对于Verifier,在接收到模式协商请求消息1后,需要确定出即将采用的远程证明模式。一种情况下,当模式协商请求消息1中携带候选的远程证明模式时,Verifier可以从中确定即将采用的远程证明模式,或者,Verifier也可以不考虑候选的远程证明模式,自主确定即将采用的远程证明模式。另一种情况下,当模式协商请求消息1中未携带候选的远程证明模式,那么,Verifier可以根据自己的需求以及能力确定即将采用的远程证明模式。
在Verifier确定出即将采用的远程证明模式后,即可基于该即将采用的远程证明模式生成模式协商响应消息1,并将该模式协商响应消息1反馈给单元10,一般单元10通过解析该模式协商响应消息1,确定即将采用的远程证明模式。
需要说明的是,当候选模式包括混合验证模式时,为了节约远程证明的耗时,提高远程证明效率,模式协商请求消息1中还可以携带待在该单元10上进行可信验证的候选单元集合20’;同理,当Verifier确定即将采用的远程证明模式为混合验证模式时,模式协商响应消息1中还可以携带Verifier确定的、由单元10负责进行可信验证的单元集合,该单元集合包括单元21。
如此,通过图15a提供的协商方式,Verifier可以决策出和组合式设备之间即将采用的远程证明模式,并将该远程证明模式告知组合式设备的单元10,实现在单元10和Verifier 之间远程证明模式的确定,使得Verifier和组合式设备之间可以确定的执行图6或图12所示的远程证明方法,为有序的对组合式设备进行高效的远程证明提供了前提条件。
参见图15b,为本申请实施例中另一种远程证明模式的协商方法的信令流程图。该远程证明模式的协商方法,具体可以包括:
步骤15b1,Verifier向单元10发送模式协商请求消息2;
步骤15b2,单元10向Verifier反馈模式协商响应消息2;
步骤15b3,Verifier根据模式协商响应消息2,确定远程证明模式。
需要说明的是,本实施例中只是对图15a中各步骤的执行主体进行调换,由单元10决策其和Verifier之间即将采用的远程证明模式,所以,本申请实施例中的具体实现方式以及相关说明,均可以参见图15a的相关描述。
如此,通过图15b提供的上述协商方式,组合式设备中的单元10可以决策出和Verifier 之间即将采用的远程证明模式,并将该远程证明模式告知Verifier,实现在单元10和Verifier 之间远程证明模式的确定,使得Verifier和组合式设备之间可以确定的执行图6或图12所示的远程证明方法,为有序的对组合式设备进行高效的远程证明提供了前提条件。
需要说明的是,在实际的远程证明模式的协商过程中,除了上述图15a和图15b所示的实现方式外,通常还可以通过单元10和Verifier之间的多次复杂交互进行远程证明模式的协商。为了更加清楚的说明在实际通信过程中通过多次交互进行远程证明模式协商的可能实现方式,下面通过图16a和图16b为例,介绍单元10和Verifier之间进行远程证明模式协商过程中可能出现的多种情况。
参见图16a,在由Verifier决策使用的目标远程证明模式的情况下,本申请实施例提供的远程证明模式的协商方法例如可以包括:
步骤16a1,单元10向Verifier发送模式协商开始请求消息1。
可以理解的是,该模式协商开始请求消息1中不包含具体的远程证明模式协商的内容,只用于告知Verifier该单元10想要开始和Verifier进行远程证明模式的协商,向Verifier请求开始协商远程证明模式。
步骤16a2,Verifier向单元10发送模式协商开始应答消息1。
可以理解的是,该模式协商开始应答消息1用于表示该Verifier是否同意和单元10开始协商远程证明模式,若同意,则执行下述步骤,否则中止该次协商,不再执行后续步骤。
需要说明的是,上述步骤16a1~步骤16a2为该实施例中可选择执行的步骤。
步骤16a3,单元10向Verifier发送模式协商请求消息3。
可以理解的是,该模式协商请求消息3中包含该单元10建议使用的候选的远程证明模式1,该候选的远程证明模式1可以是该单元10最想使用的一个远程证明模式,也可以是该单元10支持的多个远程证明模式。
其中,对于该模式协商请求消息3中携带多个候选的远程证明模式1的情况,该模式协商请求消息3中还可以包括各候选的远程证明模式1对应的使用优先级。该使用优先级可以是根据Verifier的负载情况以及组合式设备中子单元的实际情况,为各候选的远程证明模式1灵活定义的,如:假设模式协商请求消息3中从前到后的位置依次包括三个候选的远程证明模式1为:本地验证模式、混合验证模式和中继模式,那么,候选的远程证明模式1对应的使用优先级从高到低可以为:本地验证模式>混合验证模式>中继模式,或者,也可以为:本地验证模式<混合验证模式<中继模式。具体实现时,该使用优先级可以通过单独的优先级字段显式,该优先级字段中的取值类型可以是整数值类型(如:数字越大使用优先级越高或数字越大使用优先级越低)、字符串类型等。
步骤16a4,Verifier判断是否同意采用该候选的远程证明模式1中的目标远程证明模式0,若同意,则执行步骤16a5;否则,可以执行下述过程中的任意一个:步骤16a6、步骤16a7~步骤16a9、步骤16a10~步骤16a12。
步骤16a5,Verifier向单元10发送模式协商应答消息3,用于表示协商成功。
其中,为了表征所确定的目标远程证明模式0,该模式协商应答消息3中可以包括协商结果字段,该字段的值除了用于表示协商结果为协商成功,还可以用于表示Verifier同意使用的远程证明模式0。
需要说明的是,当模式协商请求消息3中的候选的远程证明模式1中只包括该目标远程证明模式0时,该模式协商应答消息3中的协商结果字段的值可以仅用于表示协商结果为协商成功,无需表明Verifier同意使用的远程证明模式0。
若Verifier不同意使用候选的远程证明模式1进行接下来的远程证明,则可以认为协商失败,该情况下,可以包括下述三种可能的实现方式:
在一种可能的实现方式中,可以执行下述步骤16a6:
步骤16a6,Verifier向单元10发送的模式协商应答消息4。
其中,该模式协商应答消息4携带协商结果字段,该协商结果字段的值除了用于表示协商结果为协商失败,还可以用于表示该Verifier建议使用的远程证明模式2。
可以理解的是,在单元10收到该模式协商应答消息4后,若该单元10同意该远程证明模式2,则认为协商成功,并使用该远程证明模式2进行远程证明。对于Verifier,若在步骤16a6之后,没有再收到新的模式协商请求消息,则也可以认为协商成功,使用该远程证明模式2进行后续的远程证明。
在另一种可能的实现方式中,可以执行下述步骤16a7~步骤16a9:
步骤16a7,Verifier向单元10发送的模式协商应答消息5,用于表示协商失败。
其中,该模式协商应答消息5携带协商结果字段,该协商结果字段的值,可以仅用于表示协商结果为协商失败。而该模式协商应答消息5中可以不包含具体的远程证明模式的内容,只用于告知该单元10上次协商失败。
步骤16a8,单元10向Verifier发送模式协商请求消息4。
可以理解的是,该模式协商请求消息4中包含该单元10新提出的建议使用的候选的远程证明模式1’。
步骤16a9,Verifier向单元10发送模式协商应答消息6,携带从候选的远程证明模式 1’中确定的目标远程证明模式0’,用于表示协商成功。
需要说明的是,步骤16a8~步骤16a9的相关说明可以参见上述步骤16a3~步骤16a5 的相关描述。
在再一种可能的实现方式中,可以执行下述步骤16a10~步骤16a12:
步骤16a10,Verifier向单元10发送的模式协商应答消息7,用于表示协商失败。
其中,该模式协商应答消息7携带协商结果字段,该协商结果字段的值,除了用于表示协商结果为协商失败,还可以用于表示Verifier建议使用的远程证明模式3。
步骤16a11,单元10向Verifier发送模式协商请求消息5。
可以理解的是,该模式协商请求消息5中包含该单元10参考Verifier建议使用的远程证明模式3,新提出的建议使用的候选的远程证明模式1”。
步骤16a12,Verifier向单元10发送模式协商应答消息8,携带从候选的远程证明模式 1”中确定的目标远程证明模式0”,用于表示协商成功。
需要说明的是,步骤16a11~步骤16a12的相关说明也可以参见上述步骤16a3~步骤16a5 的相关描述。
如此,可以在首次远程证明模式协商失败之后,通过上述三种具体的实现方式,继续进行远程证明模式的协商,直到由Verifier确定出两者均同意使用的目标远程证明模式,为后续有序的执行本申请实施例提供的远程证明提供了前提条件。
可选地,本申请实施例还可以包括:
步骤16a13,单元10向Verifier发送模式协商结束请求消息1,用于通知Verifier模式协商流程的结束。
步骤16a14,Verifier回复单元10模式协商结束应答消息1。
其中,该模式协商结束请求消息1中可以包括本次协商的协商结果,如协商成功或协商失败。如果协商结果为协商成功,则该模式协商结束应答消息1中还可以包括协商确定的目标远程模式,也可以包括协商确定的目标远程模式以及由单元10进行可信验证的子单元21的标识信息11。Verifier即可基于该模式协商结束请求消息1中的内容,确认单元 10发送的协商结果等相关信息与该Verifier自己认定的协商结果等相关信息是否一致,得到比较结果,并在模式协商结束应答消息1中携带该比较结果。若比较结果表示Verifier 和单元10对协商结果等相关信息的认定一致,则认为协商成功,反之,若计较结果表示Verifier和单元10对协商结果等相关信息的认定不一致,则认为协商不成功。
可见,通过上述步骤16a1~步骤16a14,实现了通过协商的形式,由Verifier决策出组合式设备的远程证明过程中使用的远程证明模式,为有序的进行本申请实施例提供的远程证明方法提供了数据基础。
参见图16b,在由单元10决策使用的目标远程证明模式的情况下,本申请实施例提供的远程证明模式的协商方法例如可以包括:
步骤16b1,Verifier向单元10发送模式协商开始请求消息2。
步骤16b2,单元10向Verifier发送模式协商开始应答消息2。
需要说明的是,上述步骤16b1~步骤16b2为该实施例中可选择执行的步骤。
步骤16b3,Verifier向单元10发送模式协商请求消息6。
步骤16b4,单元10判断是否同意采用该候选的远程证明模式4中的目标远程证明模式0,若同意,则执行步骤16b5;否则,可以执行下述过程中的任意一个:步骤16b6、步骤16b7~步骤16b9、步骤16b10~步骤16b12。
步骤16b5,单元10向Verifier发送模式协商应答消息9,用于表示协商成功。
若单元10不同意使用候选的远程证明模式1进行接下来的远程证明,则可以认为协商失败,该情况下,可以包括下述三种可能的实现方式:
在一种可能的实现方式中,可以执行下述步骤16b6:
步骤16b6,单元10向Verifier发送的模式协商应答消息10,携带建议使用的远程证明模式5。
在另一种可能的实现方式中,可以执行下述步骤16b7~步骤16b9:
步骤16b7,单元10向Verifier发送的模式协商应答消息11,用于表示协商失败。
步骤16b8,Verifier向单元10发送模式协商请求消息7,携带Verifier新提出的建议使用的候选的远程证明模式4’。
步骤16b9,单元10向Verifier发送模式协商应答消息12,携带从候选的远程证明模式4’中确定的目标远程证明模式0’,用于表示协商成功。
在再一种可能的实现方式中,可以执行下述步骤16b10~步骤16b12:
步骤16b10,单元10向Verifier发送的模式协商应答消息13,用于表示协商失败,提供单元10建议使用的远程证明模式6。
步骤16b11,Verifier向单元10发送模式协商请求消息8,携带Verifier新提出的建议使用的候选的远程证明模式4”。
步骤16b12,单元10向Verifier发送模式协商应答消息14,携带从候选的远程证明模式1”中确定的目标远程证明模式0”,用于表示协商成功。
可选地,本申请实施例还可以包括:
步骤16b13,Verifier向单元10发送模式协商结束请求消息2,用于通知单元10模式协商流程的结束。
步骤16b14,单元10回复Verifier模式协商结束应答消息2。
需要说明的是,上述步骤16b1~步骤16b14的实现方式以及相关说明,可以参见图16a 中步骤16a1~步骤16a14,在此不再赘述。
可见,通过上述步骤16b1~步骤16b14,实现了通过协商的形式,由组合式设备中的单元10决策出组合式设备的远程证明过程中使用的远程证明模式,为有序的进行本申请实施例提供的远程证明方法提供了数据基础。
另外,触发对组合式设备进行可信验证的方式,具体可以包括:方式一、单元10可以周期性的向Verifier发送触发请求1,该触发请求1用于周期性的触发Verifier对组合式设备进行可信验证,例如:每2个小时,单元10生成并向Verifier发送一个触发请求1,用于触发Verifier启动对该单元10所在的组合式设备的一次远程证明;方式二、单元10 也可以基于事件的发生向Verifier发送触发请求2,触发请求2用于触发Verifier对所述组合式设备进行可信验证,其中,事件具体可以包括下述情况中的至少一种:控制面的主备切换、转发面的更新或命令行的执行。
作为一个示例:对于包括多个主单元的组合式设备,由于激活态的主单元发生故障,为了确保该组合式设备可以正常使用,可以将备用态的主单元的状态切换为激活态,并使用该可以正常工作的主单元接替不可用的主单元的工作,该过程可以概括为发生了控制面的主备切换事件,可以理解的是,上述实施例中的单元10均为当前处于激活态的主单元。
作为另一个示例,根据组合式设备上的业务需求,可以随时新增或者替换其中的子单元,如:在路由器插入新的转发板或者将原转发板1替换为转发板1’,以提高该路由器的性能,该过程可以概括为转发面的更新事件。
作为再一个示例,还可以根据实际需求,在命令行输入指令并执行,用于触发向Verifier 发送触发请求2,触发Verifier启动一次远程证明,该过程可以概括为发生了命令行的执行事件。
可以理解的是,上述三个示例中的事件,均可以被单元10感知到,并且该单元10感知到上述事件发生时,即可生成并向Verifier发送触发请求2。
目前,远程证明通常由Verifier发起,待验证的Attester只能被动等待Verifier发起请求后才可以进行远程证明。那么,为了确保组合式设备发生上述事件后,可以及时的对事件发生之后的组合式设备进行可信验证,以确保该组合式设备以及网络的安全,在本申请实施例中,组合式设备中的单元还被赋予可以主动发起远程证明的功能。
在一些可能的实现方式中,当组合式发生控制面的主备切换事件时,即,激活态的主单元10不可用,主单元11从备用态切换为激活态,接替主单元10继续工作,那么,主单元11可以主动向Verifier发起一次远程证明。
作为一个示例,参见图17a,本申请实施例提供的远程证明方法,应用于组合式设备,该组合式设备除了包括主单元10和主单元11,还包括子单元20,该方法具体可以包括:
步骤17a1,主单元11按照上述图6或图12所示的实施例对子单元20进行可信验证,获得验证结果8。
步骤17a2,主单元11向Verifier发送度量请求消息5,用于指示Verifier对组合式设备进行远程证明。
步骤17a3,Verifier向主单元11发送度量请求消息6。
步骤17a4,主单元11向Verifier发送度量回应消息3,携带验证结果8。
可以理解的是,度量请求消息6中具体可以携带下述消息:Nonce、PCRs、aikType等;度量回应消息3中具体可以携带下述消息:Nonce、aik、quote、PcrBanks、EventLog 等。
需要说明的是,步骤17a2可以在步骤17a1之前执行,也可以在步骤17a1之后执行,不进行具体限定。
需要说明的是,上述步骤17a1~步骤17a4的具体实现方式以及相关概念说明,可以参见上述图6以及图12所示实施例。
如此,通过本申请实施例,可以在发生主单元状态切换事件后,无需再被动的等待Verifier的发起,从备用态切换到激活态的主单元即可主动发起一次远程证明请求,触发Verifier及时的和该主单元11进行远程证明,确保组合式设备发生替换事件后可以及时的进行可信验证,提高了组合式设备以及整个网络的安全性和可靠性。
作为另一个示例,参见图17b,本申请实施例提供的远程证明方法,应用于组合式设备,该组合式设备除了包括主单元10和主单元11,还包括子单元20,该方法具体可以包括:
步骤17b1,主单元11按照上述图7或图13所示的实施例对子单元20进行可信验证,获得验证结果8。
步骤17b2,主单元11向Verifier发送度量请求消息5,携带验证结果8。
需要说明的是,上述步骤17b1~步骤17b2的具体实现方式以及相关概念说明,可以参见上述图6以及图12所示实施例。
如此,通过本申请实施例,可以在发生控制面的主备切换事件后,无需再被动的等待Verifier的发起,从备用态切换到激活态的主单元即可主动发起一次远程证明请求,并直接将其对子单元20的验证结果8携带于该远程证明请求中发送给Verifier,节约了交互流程,在确保组合式设备发生替换事件后可以及时的进行可信验证,提高了组合式设备以及整个网络的安全性和可靠性的基础上,还在一定程度上提高了该远程证明的效率。
在另一些可能的实现方式中,由于许多组合式设备支持热插拔,即,在组合式设备中进行子单元的新增或替换等更新事件时,例如:在组合式设备的子单元中新增子单元25或者将子单元24替换为子单元25,那么,该组合式设备中的子单元集合20更新为子单元集合30,组合式设备并不会重新启动,但是,该热插拔很可能对组合式设备的系统可信性造成影响。基于此,本申请实施例中,当组合式设备发生转发面的更新事件时,主单元10 可以感知到子单元发生了热插拔,主动向Verifier发起一次远程证明。
作为一个示例,参见图18,本申请实施例提供的远程证明方法,应用于组合式设备,该组合式设备除了包括主单元10和更新后的子单元集合30,该方法具体可以包括:
步骤1801,主单元10按照上述图6所示的实施例对子单元集合30进行可信验证,获得验证结果9。
步骤1802,主单元10向Verifier发送度量请求消息6,携带验证结果9。
需要说明的是,上述步骤1801~步骤1802的具体实现方式以及相关概念说明,可以参见上述图6所示实施例。
需要说明的是,本申请实施例以本地验证模式为例进行说明,实际情况下,当远程证明模式为混合验证模式时,主单元10还可以按照上述图12所示的实施例对子单元集合30中的部分子单元进行可信验证,获得验证结果9;主单元10向Verifier发送度量请求消息6,携带验证结果9以及其余子单元的度量信息,以便Verifier对该组合式设备中的其余子单元也进行可信验证。该情况下的具体实现方式以及相关概念说明,可以参见上述图12 所示实施例。
如此,通过本申请实施例,可以在发生转发面的更新事件后,无需再被动的等待Verifier 的发起,主单元10即可感知到该事件的发生并主动对变化后的子单元集合30进行可信验证,而且直接将验证结果9携带于该远程证明请求中发送给Verifier,节约了交互流程,在确保组合式设备发生子单元的热插拔后可以及时的进行可信验证,提高了组合式设备以及整个网络的安全性和可靠性的基础上,还在一定程度上提高了该远程证明的效率。
可以理解的是,组合式设备的子单元或者主单元在运行过程时产生的度量信息中,通常包括多个PCR值,目前,远程证明时会对度量信息中的所有PCR值均进行可信验证,但是,很多场景中,单元发生增量变化,即,度量信息中一部分PCR值并没有发生变化,只有另一部分PCR值发生改变(即为增量变化对应的度量信息),如果仍然对所有的PCR 值进行验证,那么,对没有发生的PCR值的验证就是重复操作,浪费网络资源。基于此,本申请实施例还提供了只针对度量信息中发生改变的PCR值进行远程证明的方法。
作为一个示例,当组合式设备的主单元10的度量信息发生变化,则,参见图19a,本申请实施例具体可以包括:
步骤19a1,Verifier向主单元10发送度量请求消息7;
步骤19a2,主单元10获得度量信息4;
步骤19a3,主单元10将度量信息4携带在度量回应消息4中,发送给Verifier;
步骤19a4,Verifier基于度量信息4,对主单元10进行可信验证,获得验证结果10。
可以理解的是,该度量信息4为主单元10中改变的PCR值组成的度量信息,即,主单元10的增量变化对应的度量信息,例如可以是图6所示实施例中单元10的度量信息3,那么,图6所示实施例中,单元10为度量信息发生改变的主单元。这样,主单元10直接上报其发生改变的PCR值,并请求Verifier对该发生改变的PCR值进行验证,不仅减少了 Verifier和主单元10之间交互的数据量,而且减轻了Verifier的可信验证工作量,提高了远程证明的效率。需要说明的是,该情况下,主单元10上记录有上次可信验证时该主单元 10的所有PCR值,以便生成新的度量信息后,通过对比确定发生改变的PCR值。
另一些情况下,该度量信息4可以是主单元10当前所有的PCR值组成的度量信息,主单元10将全部的PCR值均上报给Verifier,由Verifier从中确定出发生改变的PCR值,并对该发生改变的PCR值进行验证,仍然可以减轻Verifier的可信验证工作量,提高远程证明的效率。需要说明的是,该情况下,Verifier上记录有上次可信验证时主单元10的所有PCR值,以便在接收到该主单元10发送的新的度量信息后,通过对比确定发生改变的 PCR值。
作为另一个示例,当组合式设备中除主单元10以外的其他单元20的度量信息发生变化,则,参见图19b,本申请实施例具体可以包括:
步骤19b1,主单元10向单元20发送度量请求消息8;
步骤19b2,单元20获得度量信息5;
步骤19b3,单元20将度量信息5携带在度量回应消息5中,发送给主单元10;
步骤19b4,主单元10基于度量信息5,对单元20进行可信验证,获得验证结果11。
可以理解的是,该度量信息5为单元20中改变的PCR值组成的度量信息,例如可以是图6所示实施例中单元10获得单元20的度量信息1,那么,图6所示实施例中,单元 20为度量信息发生改变的主单元或子单元。这样,单元20直接上报其发生改变的PCR值,并请求主单元10对该发生改变的PCR值进行验证,不仅减少了主单元10和单元20之间交互的数据量,而且减轻了主单元10的可信验证工作量,提高了远程证明的效率。需要说明的是,该情况下,单元20上记录有上次可信验证时该单元20的所有PCR值,以便生成新的度量信息后,通过对比确定发生改变的PCR值。
另一些情况下,该度量信息5可以是单元20当前所有的PCR值组成的度量信息,单元20将全部的PCR值均上报给主单元10,由主单元10从中确定出发生改变的PCR值,并对该发生改变的PCR值进行验证,仍然可以减轻主单元10的可信验证工作量,提高远程证明的效率。需要说明的是,该情况下,主单元10上记录上次可信验证时单元20的所有PCR值,以便在接收到该单元20发送的新的度量信息后,通过对比确定发生改变的PCR 值。
可见,通过上述图19a和图19b,本申请实施例实现了只针对主单元或子单元发生改变的PCR值进行验证,而不对所有的PCR值进行全量验证,避免对没有发生改变的PCR 值进行重复验证,节约网络资源,提高对组合式设备的远程证明效率。
需要说明的是,为了安全起见,上述各实施例中,Verifier和组合式设备之间交互的各种消息以及组合式设备内各单元之间交互的各种消息,均可以进行加密传输,具体实现方式在本申请中不做赘述。
图20示出了本申请实施例中一种组合式设备的远程证明方法的流程示意图,该组合式设备可以包括第一单元和第二单元,以第一单元为执行主体,对该组合式设备进行远程证明的过程例如可以包括:
步骤2001,第一单元获取第二单元的第一度量信息;
步骤2002,第一单元根据第一度量信息对第二单元进行可信验证,获得第一验证结果;
步骤2003,第一单元向远程证明设备发送第一验证结果。
这样,该组合式设备中的第一单元具有远程证明功能,可以对其所属的组合式设备内的其他单元(例如:第二单元)进行可信验证,那么,组合式设备的第一单元可以直接将其他单元的可信验证结果发送给远程证明设备,该远程证明设备只需要接收第一单元发送的其他单元的验证结果即可,不再需要接收各个单元的度量信息并分别对各个单元进行可信验证,可以有效的降低远程证明设备和组合式设备就远程证明过程需要交互的数据量,一定程度上提高了对组合式设备的远程证明效率。
其中,第一单元可以是控制面,第二单元可以是控制面或转发面。例如:当组合式设备为路由器时,第一单元可以是主控板,第二单元可以是主控板、转发板、业务板等。
作为一个示例,对于组合式设备的启动等度量过程较为确定的情况,第一度量信息可以包括第一PCR值和PCR参考值。那么,步骤2001中第一单元获取第二单元的第一度量信息,具体可以包括:第一单元从第二单元获得第一PCR值;第一单元从远程证明设备或本地的安全存储空间中获得PCR参考值。基于此,步骤2002中,第一单元根据第一度量信息对第二单元进行可信验证获得第一验证结果,具体过程可以为:第一单元比较第一 PCR值和PCR参考值,获得第一验证结果,若第一PCR值和PCR参考值一致,则第一验证结果表征第二单元可信,反之,若第一PCR值和PCR参考值不一致,则第一验证结果表征第二单元不可信。如此,即可在组合式设备进行启动等度量过程较为确定的过程时,由其中的第一单元以PCR参考值为依据,对第二单元进行可信验证,实现对组合式设备快速、方便和有效的远程证明。
作为另一个示例,对于组合式设备的度量过程较为不确定的情况,例如:组合式设备启动后的运行过程,第一度量信息可以包括第二单元上报的第二PCR值和第一度量日志,其中,第一度量日志包括第一基线值以及基于第一基线值进行扩展得到第二PCR值的过程信息,第一基线值是第二单元上报的基线值;第一度量信息还包括第二基线值,第二基线值是第二单元的可信的基线值,第二基线值用于对第一基线值进行校验。那么,步骤2001 中,第一单元获取第二单元的第一度量信息,具体可以包括:第一单元从第二单元获得第二PCR值和第一度量日志,第一度量日志包括第一基线值以及基于第一基线值进行扩展得到第二PCR值的过程信息;第一单元从远程证明设备或本地的安全存储空间中获得第二基线值。基于此,步骤2002中,第一单元根据第一度量信息对第二单元进行可信验证获得第一验证结果,具体过程可以为包括:第一单元基于第一度量日志,计算第三PCR值;第一单元对比第二PCR值和第三PCR值,若第二PCR值和第三PCR值一致,则,第一单元对比第二基线值和第一基线值,获得第一验证结果;反之,若第二PCR值和第三PCR 值不一致,则第一单元可以不对比第二基线值和第一基线值,直接得出第一验证结果,该第一验证结果用于表征该第二单元不可信。如此,即可在组合式设备执行度量过程不确定的进程时,由其中的第一单元以第二基线值为依据,对第二单元进行可信验证,实现对组合式设备快速、方便和有效的远程证明。
针对上述两个示例,可以理解的是,一种情况下,该第二单元的PCR参考值或第二基线值,可以是被存储在第一单元本地的安全存储空间中,该安全存储空间可以是指不可被攻击者篡改或访问的物理空间,例如:只有RAT相关进程或者运行进程实现RAT的模块(称为:RAT组建)才能够访问的物理空间;另一种情况下,该第二单元的PCR参考值或第二基线值,也可以是从远程证明设备上获取的,远程证明设备上保存有组合式设备的各单元的PCR参考值。
在一些可能的实现方式中,当组合式设备还包括第三单元时,本申请实施例还可以包括:第一单元获取第三单元的第二度量信息;第一单元向远程证明设备发送第二度量信息。这样,第一单元只是将第三单元的度量信息转发给远程证明设备,由远程证明设备对第三单元进行远程证明,也实现了对该组合式设备中的单元进行可信验证的效果。
具体实现时,当该远程证明采用挑战-响应方式时,在第一单元向远程证明设备发送第一验证结果之前,例如在步骤2001之前,或者,步骤2002和步骤2003之间,本申请实施例还可以包括:第一单元接收远程证明设备发送的第一度量请求消息,第一度量请求消息可以视作“挑战”,用于请求对组合式设备进行可信验证,那么,步骤2003中第一单元即可将第一验证结果携带在第一度量回应消息中,作为对“挑战”的“响应”,发送给远程证明设备。
在另一些可能的实现方式中,本申请实施例还可以包括:第一单元向远程证明设备发送第一单元的第三度量信息,远程证明设备对第一单元进行可信验证。这样,一方面,由远程证明设备对第一单元进行可信验证的过程,使得对该组合式设备的可信验证更加完备,即,实现了对组合设备中包括第一单元在内的所有单元的可信验证;另一方面,也可以在由第一单元对第二单元进行可信验证前,先由远程证明设备对第一单元进行可信验证,在第一单元可信的条件下,才确定由该第一单元对第二单元进行远程证明,使得远程证明的过程更加安全,提高了对组合式设备的远程证明的可靠性。
在又一些可能的实现方式下,组合式设备的远程证明可以采用不同的远程证明模式,为了确保远程证明可以有序执行,在进行上述远程证明之前,远程证明设备和组合式设备之间可以先确定采用的远程证明模式。
作为一个示例,确定采用远程证明的方式,可以通过在组合式设备和远程证明设备上进行本地静态配置的方式,确定接下来的远程证明采用的远程证明模式。
作为另一个示例,也可以通过组合式设备和远程证明设备之间进行协商的方式,确定接下来的远程证明采用的远程证明模式,例如:第一单元向远程证明设备发出模式协商请求消息;第一单元接收远程证明设备发送的模式协商响应消息,第一单元根据模式协商响应消息,确定远程证明模式。其中,模式协商请求消息中可以携带第一指示信息,第一指示信息用于指示第一单元支持并且建议采用的远程证明模式;模式协商响应消息中携带第二指示信息,第二指示信息用于指示远程证明设备确定接下来采用的远程证明模式。需要说明的是,远程证明模式的协商过程可以是第一单元发起的,也可以是远程证明设备发起的;最终确定的远程证明模式可以是第一单元决策确定的,也可以是远程证明设备决策确定的。这样,通过组合式设备和远程证明设备之间的协商,确定接下来采用的远程证明方式,为后续有序的对组合式设备进行远程证明提供了数据基础。
可以理解的是,当所确定的远程证明模式为本地验证模式时,那么,在本地验证模式下,第一单元负责对组合式设备内除第一单元以外的,其它所有包括TCB模块的单元进行可信验证。当所确定的远程证明模式为混合验证模式时,那么,在混合验证模式下,第一单元对第二单元进行可信验证,远程证明设备对组合式设备中的第四单元进行可信验证,即,第一单元对组合式设备中的部分单元进行可信验证,该部分单元中包括第二单元;另一部分单元将其度量信息通过第一单元发送给远程证明设备,由远程证明设备进行可信验证,该另一部分单元中包括第二单元。
需要说明的是,对于混合验证模式,确定由远程证明设备和第一单元进行可信验证的具体单元,可以是第一单元确定并通知远程证明设备的,也可以是远程证明设备确定并通知第一单元的,还可以是二者协商确定的,该协商确定各自具体验证的单元的过程,可以在协商远程证明模式的过程中同时实现,也可以在确定远程证明模式为混合验证模式后单独协商的。作为一个示例,本申请实施例例如可以采用下述过程确定由远程证明设备和第一单元进行可信验证的具体单元:第一单元向远程证明设备发送第一请求消息,第一请求消息用于向远程证明设备请求验证权限,验证权限指示被第一单元进行可信验证的单元的集合,集合包括第二单元;第一单元接收远程证明设备返回的第一响应消息,第一响应消息用于指示验证权限。其中,该第一响应消息中包括被第一单元进行可信验证的各单元的标识信息,该标识信息例如可以是单元的标识符,用于唯一标识该单元。
需要说明的是,上述第一单元为激活态的主单元,例如,第一单元可以是在该第一方面的第一步之前,从备用态切换为激活态的主单元。
在再一些可能的实现方式中,触发对组合式设备进行远程证明的方式,一种情况下,第一单元可以周期性的对第二单元进行可信验证,例如:第一单元周期性的向远程证明设备发送第一触发请求,第一触发请求用于周期性的触发远程证明设备对组合式设备进行可信验证。另一种情况下,第一单元也可以是基于事件的触发,对第二单元进行可信验证,例如:第一单元基于事件的发生向远程证明设备发送第二触发请求,第二触发请求用于触发远程证明设备对组合式设备进行可信验证,其中,事件可以包括下述情况中的一种:第一单元发生主备切换、第二单元状态发生变化或配置命令,即,当第一单元从备用态切换为激活态时,或者,第一单元感知到第二单元发生了状态变化(例如新增第二单元或者第二单元发生替换)时,再或者,第二单元接收到配置命令时,触发第一单元对第二单元进行可信验证。如此,可以在发生事件或者达到预设的周期时,无需再被动的等待远程证明的发起,第一单元即可主动对第二单元进行可信验证,节约了远程证明过程的交互流程,提高了该远程证明的效率。
在另一些可能的实现方式中,当组合式设备中的单元发生增量变化,即,该单元存在部分度量信息不变,其他度量信息变化的情况,那么,本申请实施例为了节约远程证明占用的系统资源,提高远程证明的效率,可以仅对发生变化的度量信息进行远程证明,即,对增量变化对应的度量信息进行获取以及基于该增量变化对应的度量信息进行远程证明。作为一个示例,当第二单元发生第一增量变化,本申请实施例还可以包括:第二单元发生第一增量变化,第一单元获取与第一增量变化对应的第五度量信息;第一单元基于第五度量信息,对第二单元进行可信验证。作为另一个示例,当第一单元发生第二增量变化,则,本申请实施例还可以包括:第一单元向远程证明设备发送该第一单元发生第二增量变化对应的第六度量信息;该远程证明设备基于第六度量信息对发生第二增量变化后的第一单元进行可信验证。这样,本申请实施例实现了只针对各单元发生改变的PCR值对应的度量信息进行验证,而不对所有的PCR值对应的度量信息进行全量验证,避免对没有发生改变的 PCR值对应的度量信息进行重复验证,节约网络资源,提高对组合式设备的远程证明效率。
图21示出了本申请实施例中另一种组合式设备的远程证明方法的流程示意图,应用于远程证明设备,其中,组合式设备可以包括第一单元和第二单元,本申请实施例具体可以包括:
步骤2101,远程证明设备接收第一单元发送的第一消息,第一消息中携带第一单元对第二单元进行可信验证的第一验证结果;
步骤2102,远程证明设备根据第一消息,获取第一验证结果。
在一些可能的实现方式中,本申请实施例还可以包括:远程证明设备接收第一单元发送的第二消息,第二消息中携带第一单元的第一度量信息;远程证明设备根据第一度量信息,对第一单元进行可信验证,获得第二验证结果。
在另一些可能的实现方式中,本申请实施例还可以包括:远程证明设备对第一验证结果进行校验,得到第三验证结果。具体而言,用于验证第二单元的签名是否正确,以及第一单元对第二单元的可信验证过程是否准确。
在又一些可能的实现方式中,本申请实施例还可以还包括:确定远程证明模式。一种情况下,可以通过静态配置的方式在远程证明设备以及第一单元上设定远程证明模式;另一种情况下,也可以通过协商的方式确定远程证明模式,作为一个示例,协商的过程可以包括:远程证明设备接收第一单元发出的模式协商请求消息;远程证明设备根据模式协商请求消息,确定远程证明模式;远程证明设备向第一单元发送模式协商响应消息,模式协商响应消息中携带远程证明模式,模式协商响应消息用于告知第一单元采用远程证明模式进行远程证明。
作为一个示例,当远程证明模式为本地验证模式时,在本地验证模式下,第一单元负责对组合式设备内包括除第一单元以外的所有单元进行可信验证,所有单元中的每个单元包括可信计算基础TCB模块。那么,本申请实施例还可以包括:远程证明设备根据第一验证结果、第二验证结果和第三验证结果,生成第四验证结果,第四验证结果用于表征组合式设备的系统可信性;其中,若第一验证结果表示第二单元可信,第二验证结果表示第一单元可信,第三验证结果表示第二单元的签名正确且第一单元对第二单元的可信验证过程准确,则,第四验证结果表示组合式设备的系统可信。
作为另一个示例,当远程证明模式为混合验证模式时,在混合验证模式下,第一验证结果为第一单元对第二单元进行可信验证的结果,本申请实施例还可以包括:远程证明设备对组合式设备中的第三单元进行可信验证,获得第五验证结果。那么,本申请实施例还可以包括:远程证明设备根据第一验证结果、第二验证结果、第三验证结果和第五验证结果,生成第六验证结果,第六验证结果用于表征组合式设备的系统可信性;其中,若第一验证结果表示第二单元可信,第二验证结果表示第一单元可信,第三验证结果表示第二单元的签名正确且第一单元对第二单元的可信验证过程准确,第五验证结果表示第三单元可信,则,第六验证结果表示组合式设备的系统可信。
对于混合验证模式,本申请实施例还包括确定由第一单元进行远程证明的单元集合以及由远程证明设备进行远程证明的单元集合,该过程可以是静态配置设定的,也可以是协商确定的。当通过协商确定时,可以是和协商远程证明模式一起确定的;也可以是在确定远程证明模式为混合验证模式后独立确定的,那么,本申请实施例例如可以包括:远程证明设备接收第一单元发送的第一请求消息,第一请求消息用于向远程证明设备请求验证权限;远程证明设备确定验证权限,验证权限指示远程证明设备对第三单元进行可信验证;远程证明设备向第一单元发送第一回应消息,以便第一单元根据验证权限,对第二单元进行可信验证。
需要说明的是,图21提供的方法应用于远程证明设备,对应于图20提供的应用于组合式设备的方法,故图21提供的方法的各种可能的实现方式以及达到的技术效果,可以参照前述图20提供的方法的介绍。
对于上述图20和图21所示的实施例中,可以理解的是,一种情况下,对应图5所示实施例,组合式设备可以是Attester 201,其中,第一单元可以是主单元311,第二单元可以是主单元312、子单元321、322、……中的任意一个单元,远程证明设备可以是Verifier202;另一种情况下,对应图6、7a~7c、8、9a~9b、10~14、15a~15b以及16a~16b所示的实施例,第一单元可以对应单元10,第二单元可以对应单元20,远程证明设备可以是Verifier;再一种情况下,对应图17a和图17b所示的实施例中,第一单元可以对应主单元11,第二单元可以对应子单元20,远程证明设备可以是Verifier;又一种情况下,对应图 18所示的实施例中,第一单元可以对应主单元10,第二单元可以对应子单元集合30中的单元,远程证明设备可以是Verifier;另一种情况下,对应19a~19b所示的实施例中,第一单元可以对应主单元10,第二单元可以对应单元20,远程证明设备可以是Verifier。那么,步骤2001~步骤2003的概念解释、具体实现方式以及达到的效果,可以参见上述图5、6、 7a~7c、8、9a~9b、10~14、15a~15b、16a~16b、17a~17b、18以及19a~19b对应实施例的相关描述。
此外,本申请实施例还提供了一种组合式设备的远程证明装置2200,参见图22所示。该装置2200应用于组合式设备,该组合式设备包括接收单元2201、发送单元2202和处理单元2203。其中,接收单元2201用于执行上述图5、6、7a~7c、8、9a~9b、10~14、15a~15b、16a~16b、17a~17b、18、19a~19b以及图20所示实施例对应的方法中,组合式设备(或Attester)所执行的接收操作,例如:执行图6所示的实施例中的步骤601;发送单元2202 用于执行上述图5、6、7a~7c、8、9a~9b、10~14、15a~15b、16a~16b、17a~17b、18、19a~19b以及图20所示实施例对应的方法中,组合式设备(或Attester)所执行的发送操作。例如:执行图6所示实施例中的步骤604;处理单元2203用于执行上述图5、6、7a~7c、8、9a~9b、 10~14、15a~15b、16a~16b、17a~17b、18、19a~19b以及图20所示实施例对应的方法中,组合式设备(或Attester)所执行的除了接收操作和发送操作以外的其他操作,例如:处理单元2203可以执行图6所示实施例中的步骤603,即,根据度量信息1和度量信息2,对单元20进行可信验证,获得验证结果1。
此外,本申请实施例还提供了一种组合式设备的远程证明装置2300,参见图23所示。该装置2300应用于远程证明设备,该远程证明设备包括接收单元2301、发送单元2302和处理单元2303。其中,接收单元2301用于执行上述图5、6、7a~7c、8、9a~9b、10~14、 15a~15b、16a~16b、17a~17b、18、19a~19b以及图21所示实施例对应的方法中,远程证明设备(或Verifier)所执行的接收操作,例如:执行图11所示的实施例中的步骤606;发送单元2302用于执行上述图5、6、7a~7c、8、9a~9b、10~14、15a~15b、16a~16b、17a~17b、 18、19a~19b以及图21所示实施例对应的方法中,远程证明设备(或Verifier)所执行的发送操作。例如:执行图9a所示实施例中的S53;处理单元2303用于执行上述图5、6、 7a~7c、8、9a~9b、10~14、15a~15b、16a~16b、17a~17b、18、19a~19b以及图21所示实施例对应的方法中,远程证明设备(或Verifier)所执行的除了接收操作和发送操作以外的其他操作,例如:处理单元2303可以执行图11所示实施例中的步骤607~609。
此外,本申请实施例还提供了一种组合式设备2400,包括第一单元2401和第二单元 2402,其中,第二单元2402用于将其度量信息发送给第一单元2401,第一单元2401用于执行上述图5、6、7a~7c、8、9a~9b、10~14、15a~15b、16a~16b、17a~17b、18、19a~19b以及图20所示实施例对应的远程证明方法,实现对该组合式设备2400的可信验证。
此外,本申请实施例还提供了一种组合式设备2500,如图25所示,该组合式设备2500 可以包括通信接口2501和处理器2502。其中,通信接口2501用于执行前述图5、6、7a~7c、8、9a~9b、10~14、15a~15b、16a~16b、17a~17b、18、19a~19b以及图20所示实施例中的接收和发送操作;处理器2502,用于执行前述图5、6、7a~7c、8、9a~9b、10~14、15a~15b、 16a~16b、17a~17b、18、19a~19b以及图20所示实施例中,除所述接收和发送操作以外的其他操作,例如:执行图6所示实施例中的步骤603。
此外,本申请实施例还提供了一种组合式设备2600,如图26所示,该组合式设备2600 包括存储器2601和处理器2602。其中,存储器2601用于存储程序代码;处理器2602用于运行所述程序代码中的指令,使得该组合式设备2600执行以上图5、6、7a~7c、8、9a~9b、10~14、15a~15b、16a~16b、17a~17b、18、19a~19b以及图20所示实施例提供的方法。
此外,本申请实施例还提供了远程证明设备2700,如图27所示,该远程证明设备2700 包括通信接口2701和处理器2702。其中,通信接口2701用于执行前述图5、6、7a~7c、8、9a~9b、10~14、15a~15b、16a~16b、17a~17b、18、19a~19b以及图21所示实施例中的接收和发送操作;所述处理器2702用于执行前述图5、6、7a~7c、8、9a~9b、10~14、15a~15b、 16a~16b、17a~17b、18、19a~19b以及图21所示实施例中除所述接收和发送操作以外的其他操作,例如:执行图11所示实施例中的步骤607~609。
此外,本申请实施例还提供了一种远程证明设备2800,如图28所示,该远程证明设备2800包括存储器2801和处理器2802。其中,存储器2801用于存储程序代码;处理器 2802用于运行所述程序代码中的指令,使得该远程证明设备2800执行以上图5、6、7a~7c、 8、9a~9b、10~14、15a~15b、16a~16b、17a~17b、18、19a~19b以及图21所示实施例提供的方法。
可以理解的是,上述实施例中,处理器可以是中央处理器(英文:centralprocessing unit,缩写:CPU),网络处理器(英文:network processor,缩写:NP)或者CPU和NP的组合。处理器还可以是专用集成电路(英文:application-specific integratedcircuit,缩写:ASIC),可编程逻辑器件(英文:programmable logic device,缩写:PLD)或其组合。上述PLD可以是复杂可编程逻辑器件(英文:complex programmable logicdevice,缩写:CPLD),现场可编程逻辑门阵列(英文:field-programmable gate array,缩写:FPGA),通用阵列逻辑 (英文:generic array logic,缩写:GAL)或其任意组合。处理器可以是指一个处理器,也可以包括多个处理器。存储器可以包括易失性存储器(英文:volatile memory),例如随机存取存储器(英文:random-access memory,缩写:RAM);存储器也可以包括非易失性存储器(英文:non-volatile memory),例如只读存储器(英文:read-only memory,缩写: ROM),快闪存储器(英文:flash memory),硬盘(英文:hard diskdrive,缩写:HDD) 或固态硬盘(英文:solid-state drive,缩写:SSD);存储器还可以包括上述种类的存储器的组合。存储器可以是指一个存储器,也可以包括多个存储器。在一个具体实施方式中,存储器中存储有计算机可读指令,所述计算机可读指令包括多个软件模块,例如发送模块,处理模块和接收模块。处理器执行各个软件模块后可以按照各个软件模块的指示进行相应的操作。在本实施例中,一个软件模块所执行的操作实际上是指处理器根据所述软件模块的指示而执行的操作。处理器执行存储器中的计算机可读指令后,可以按照所述计算机可读指令的指示,执行组合式设备获远程证明设备可以执行的全部操作。
可以理解的是,上述实施例中,组合式设备2500/远程证明设备2700的通信接口2501/2701,具体可以被用作组合式设备的远程证明装置2200/2300中的接收单元2201/2202 和发送单元2301/2302,实现组合式设备2500和远程证明2700之间的数据通信。
此外,本申请实施例还提供了一种计算机可读存储介质,该计算机可读存储介质中存储有指令,当其在计算机上运行时,使得所述计算机执行以上图5、6、7a~7c、8、9a~9b、 10~14、15a~15b、16a~16b、17a~17b、18、19a~19b、20以及图21所示实施例提供的所述组合式设备的远程证明方法。
此外,本申请实施例还提供了计算机程序产品,当其在计算机上运行时,使得计算机执行前述图5、6、7a~7c、8、9a~9b、10~14、15a~15b、16a~16b、17a~17b、18、19a~19b、 20以及图21所示实施例提供的所述组合式设备的远程证明方法。
本申请实施例中提到的“第一单元”、“第一度量信息”等名称中的“第一”只是用来做名字标识,并不代表顺序上的第一。该规则同样适用于“第二”等。
通过以上的实施方式的描述可知,本领域的技术人员可以清楚地了解到上述实施例方法中的全部或部分步骤可借助软件加通用硬件平台的方式来实现。基于这样的理解,本申请的技术方案可以以软件产品的形式体现出来,该计算机软件产品可以存储在存储介质中,如只读存储器(英文:read-only memory,ROM)/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者诸如路由器等网络通信设备)执行本申请各个实施例或者实施例的某些部分所述的方法。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于装置实施例和设备实施例而言,由于其基本相似于方法实施例,所以描述得比较简单,相关之处参见方法实施例的部分说明即可。以上所描述的设备及装置实施例仅仅是示意性的,其中作为分离部件说明的模块可以是或者也可以不是物理上分开的,作为模块显示的部件可以是或者也可以不是物理模块,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
以上所述仅是本申请的优选实施方式,并非用于限定本申请的保护范围。应当指出,对于本技术领域的普通技术人员来说,在不脱离本申请的前提下,还可以作出若干改进和润饰,这些改进和润饰也应视为本申请的保护范围。

Claims (30)

1.一种组合式设备的远程证明方法,其特征在于,所述组合式设备包括多个独立单元,所述多个独立单元包括第一单元和多个第二单元,所述第一单元上具有直接和外部设备进行交互的通信接口,所述第二单元不具有和外部设备直接交互的通信接口,所述方法包括:
所述第一单元获取所述多个第二单元中每个第二单元的第一度量信息,所述第一单元具有远程证明功能;
所述第一单元根据所述多个第二单元中每个第二单元的所述第一度量信息,对对应的第二单元进行可信验证,获得所述多个第二单元中每个第二单元的第一验证结果;
所述第一单元向远程证明设备发送所述多个第二单元中每个第二单元的第一验证结果。
2.根据权利要求1所述的方法,其特征在于,所述第一度量信息包括第一平台配置注册表PCR值和PCR参考值。
3.根据权利要求1所述的方法,其特征在于,所述第一度量信息包括所述第二单元上报的第二PCR值和第一度量日志,其中,所述第一度量日志包括第一基线值以及基于所述第一基线值进行扩展得到所述第二PCR值的过程信息,所述第一基线值是所述第二单元上报的基线值,所述第一度量信息还包括第二基线值,所述第二基线值是所述第二单元的可信的基线值,所述第二基线值用于对所述第一基线值进行校验。
4.根据权利要求1-3任意一项所述的方法,其特征在于,所述组合式设备还包括第三单元,所述方法还包括:
所述第一单元获取所述第三单元的第二度量信息;
所述第一单元向所述远程证明设备发送所述第二度量信息。
5.根据权利要求1-3任意一项所述的方法,其特征在于,所述组合式设备包括路由器、交换机或分组传送网PTN设备。
6.根据权利要求1-3任意一项所述的方法,其特征在于,在所述第一单元向远程证明设备发送所述第一验证结果之前,所述方法还包括:
所述第一单元接收所述远程证明设备发送的第一度量请求消息,所述第一度量请求消息用于请求对所述组合式设备进行可信验证。
7.根据权利要求1-3任意一项所述的方法,其特征在于,所述方法还包括:
所述第一单元向所述远程证明设备发送所述第一单元的第三度量信息,以便所述远程证明设备对所述第一单元进行可信验证。
8.根据权利要求1-3任意一项所述的方法,其特征在于,所述方法还包括:
所述第一单元向所述远程证明设备发出模式协商请求消息;
所述第一单元接收所述远程证明设备发送的模式协商响应消息,
所述第一单元根据所述模式协商响应消息,确定远程证明模式。
9.根据权利要求1-3任一项所述的方法,其特征在于,所述第一单元负责对所述组合式设备内除所述第一单元以外的,其它所有包括可信计算基础TCB模块的单元进行可信验证;或
所述第一单元对所述多个第二单元进行可信验证,所述远程证明设备对所述组合式设备中的第三单元进行可信验证。
10.根据权利要求1-3任意一项所述的方法,其特征在于,所述方法还包括:
所述第一单元向所述远程证明设备发送第一请求消息,所述第一请求消息用于向所述远程证明设备请求验证权限,所述验证权限指示被所述第一单元进行可信验证的单元的集合,所述集合包括所述第二单元;
所述第一单元接收所述远程证明设备返回的第一响应消息,所述第一响应消息用于指示所述验证权限。
11.根据权利要求1-3任意一项所述的方法,其特征在于,所述方法还包括:
所述第一单元周期性的对所述第二单元进行可信验证。
12.根据权利要求1-3任意一项所述的方法,其特征在于,所述方法还包括:
基于事件的触发,所述第一单元对所述第二单元进行可信验证。
13.根据权利要求12所述的方法,其特征在于,所述事件包括下述情况中的一种:所述第一单元发生主备切换、所述第二单元状态发生变化或配置命令。
14.根据权利要求1-3任意一项所述的方法,其特征在于,所述方法还包括:
当所述第二单元发生增量变化,所述第一单元获取与所述增量变化对应的第五度量信息;
所述第一单元基于所述第五度量信息,对所述第二单元进行可信验证。
15.一种组合式设备的远程证明方法,其特征在于,应用于远程证明设备,所述组合式设备包括多个独立单元,所述多个独立单元包括第一单元和多个第二单元,所述第一单元具有远程证明功能,所述第一单元用于对多个所述第二单元进行可信验证,所述第一单元上具有直接和外部设备进行交互的通信接口,所述第二单元不具有和外部设备直接交互的通信接口,所述方法包括:
所述远程证明设备接收所述第一单元发送的第一消息,所述第一消息中携带所述第一单元对所述多个第二单元中每个第二单元进行可信验证所获得的所述多个第二单元中每个第二单元的第一验证结果;
所述远程证明设备根据所述第一消息,获取所述多个第二单元中每个第二单元对应的第一验证结果。
16.根据权利要求15所述的方法,其特征在于,所述组合式设备包括路由器、交换机或分组传输网PTN设备。
17.根据权利要求15所述的方法,其特征在于,所述方法还包括:
所述远程证明设备接收所述第一单元发送的第二消息,所述第二消息中携带所述第一单元的第一度量信息;
所述远程证明设备根据所述第一度量信息,对所述第一单元进行可信验证,获得第二验证结果。
18.根据权利要求17所述的方法,其特征在于,所述方法还包括:
所述远程证明设备对所述第一验证结果进行校验,得到第三验证结果。
19.根据权利要求18所述的方法,其特征在于,所述方法还包括:
所述远程证明设备接收所述第一单元发出的模式协商请求消息;
所述远程证明设备根据所述模式协商请求消息,确定远程证明模式;
所述远程证明设备向所述第一单元发送模式协商响应消息,所述模式协商响应消息中携带所述远程证明模式,所述模式协商响应消息用于告知所述第一单元采用所述远程证明模式进行远程证明。
20.根据权利要求18所述的方法,其特征在于,所述方法还包括:
所述远程证明设备根据所述第一验证结果、所述第二验证结果和所述第三验证结果,生成第四验证结果,所述第四验证结果用于表征所述组合式设备的系统可信性;
其中,若所述第一验证结果表示所述第二单元可信,所述第二验证结果表示所述第一单元可信,所述第三验证结果表示所述第二单元的签名正确且所述第一单元对所述第二单元的可信验证过程准确,则,所述第四验证结果表示所述组合式设备的系统可信。
21.根据权利要求18所述的方法,其特征在于,
所述第一单元负责对所述组合式设备内除所述第一单元以外的,其它所有包括可信计算基础TCB模块的单元进行可信验证;或
所述第一验证结果为所述第一单元对所述多个第二单元中每个第二单元进行可信验证的结果,所述方法还包括:
所述远程证明设备对所述组合式设备中的第三单元进行可信验证,获得第五验证结果。
22.根据权利要求21所述的方法,其特征在于,所述方法还包括:
所述远程证明设备根据所述第一验证结果、所述第二验证结果、所述第三验证结果和所述第五验证结果,生成第六验证结果,所述第六验证结果用于表征所述组合式设备的系统可信性;
其中,若所述第一验证结果表示所述第二单元可信,所述第二验证结果表示所述第一单元可信,所述第三验证结果表示所述第二单元的签名正确且所述第一单元对所述第二单元的可信验证过程准确,所述第五验证结果表示所述第三单元可信,则,所述第六验证结果表示所述组合式设备的系统可信。
23.根据权利要求15-22任意一项所述的方法,其特征在于,所述方法还包括:
所述远程证明设备接收所述第一单元发送的第一请求消息,所述第一请求消息用于向所述远程证明设备请求验证权限,所述验证权限指示被所述第一单元进行可信验证的单元的集合,所述集合包括所述第二单元;
所述远程证明设备确定所述验证权限;
所述远程证明设备向所述第一单元发送第一响应消息,以所述第一响应消息用于指示所述验证权限。
24.一种组合式设备,其特征在于,所述组合式设备包括第一单元和第二单元,所述第一单元用于执行前述权利要求1-14任意一项所述的方法。
25.一种组合式设备,其特征在于,所述组合式设备包括存储器和处理器;
所述存储器,用于存储程序代码;
所述处理器,用于运行所述程序代码中的指令,使得所述组合式设备执行以上权利要求1-14任意一项所述的组合式设备的远程证明方法。
26.一种远程证明设备,其特征在于,所述远程证明设备包括通信接口和与所述通信接口通信的处理器;
通过所述通信接口和所述处理器,所述远程证明设备用于执行前述权利要求15-23任意一项所述的方法。
27.一种远程证明设备,其特征在于,所述远程证明设备包括存储器和处理器;
所述存储器,用于存储程序代码;
所述处理器,用于运行所述程序代码中的指令,使得所述远程证明设备执行以上权利要求15-23任意一项所述的组合式设备的远程证明方法。
28.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质中存储有指令,当其在计算机上运行时,使得所述计算机执行以上权利要求1-14任意一项所述的组合式设备的远程证明方法或者权利要求15-23任意一项所述的组合式设备的远程证明方法。
29.一种通信系统,包括权利要求24或25所述的组合式设备以及权利要求26或27所述的远程证明设备。
30.一种组合式设备中的第一单元,其特征在于,所述组合式设备还包括第二单元,所述第一单元用于执行权利要求1-14任意一项所述的组合式设备的远程证明方法。
CN201911089398.XA 2019-10-17 2019-11-08 一种组合式设备的远程证明方法及设备 Active CN112688782B (zh)

Priority Applications (5)

Application Number Priority Date Filing Date Title
JP2022523021A JP2022553247A (ja) 2019-10-17 2020-09-22 複合デバイスのためのリモート証明方法およびデバイス
EP20876775.6A EP4030681A4 (en) 2019-10-17 2020-09-22 METHOD AND DEVICE FOR REMOTE CERTIFICATION OF A COMBINED DEVICE
PCT/CN2020/116936 WO2021073376A1 (zh) 2019-10-17 2020-09-22 一种组合式设备的远程证明方法及设备
BR112022006829A BR112022006829A2 (pt) 2019-10-17 2020-09-22 Método de atestado remoto e dispositivo para dispositivo composto
US17/720,848 US20220237295A1 (en) 2019-10-17 2022-04-14 Remote Attestation Method and Device for Composite Device

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910990240 2019-10-17
CN2019109902403 2019-10-17

Publications (2)

Publication Number Publication Date
CN112688782A CN112688782A (zh) 2021-04-20
CN112688782B true CN112688782B (zh) 2023-09-08

Family

ID=75445224

Family Applications (2)

Application Number Title Priority Date Filing Date
CN201911089398.XA Active CN112688782B (zh) 2019-10-17 2019-11-08 一种组合式设备的远程证明方法及设备
CN201911090276.2A Active CN112688907B (zh) 2019-10-17 2019-11-08 组合式设备远程证明模式协商方法及相关设备,存储介质

Family Applications After (1)

Application Number Title Priority Date Filing Date
CN201911090276.2A Active CN112688907B (zh) 2019-10-17 2019-11-08 组合式设备远程证明模式协商方法及相关设备,存储介质

Country Status (6)

Country Link
US (2) US20220237295A1 (zh)
EP (2) EP4030681A4 (zh)
JP (2) JP2022553247A (zh)
CN (2) CN112688782B (zh)
BR (2) BR112022007167A2 (zh)
WO (2) WO2021073376A1 (zh)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112688782B (zh) * 2019-10-17 2023-09-08 华为技术有限公司 一种组合式设备的远程证明方法及设备
US12010144B2 (en) 2020-06-18 2024-06-11 Intel Corporation End-to-end device attestation
US11455388B1 (en) * 2021-04-26 2022-09-27 Weeve.Network System and method for end-to-end data trust management with real-time attestation
WO2023117249A1 (en) * 2021-12-22 2023-06-29 British Telecommunications Public Limited Company Attestation methods
WO2023117248A1 (en) * 2021-12-22 2023-06-29 British Telecommunications Public Limited Company Attestation methods
US11978063B2 (en) * 2022-04-12 2024-05-07 Cisco Technology, Inc. Establishing ownership of dual route processors (RPs) using secure zero-touch provisioning (ZTP)
US20240031174A1 (en) * 2022-07-20 2024-01-25 Arista Networks, Inc. Establishing trust between supervisors in a network device

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101043338A (zh) * 2007-04-27 2007-09-26 中国科学院软件研究所 基于安全需求的远程证明方法及其系统
CN101477602A (zh) * 2009-02-10 2009-07-08 浪潮电子信息产业股份有限公司 一种可信计算环境中远程证明的方法
CN101610273A (zh) * 2009-08-03 2009-12-23 西安西电捷通无线网络通信有限公司 一种安全的远程证明方法
CN101951388A (zh) * 2010-10-14 2011-01-19 中国电子科技集团公司第三十研究所 一种可信计算环境中的远程证明方法
CN103560887A (zh) * 2013-11-04 2014-02-05 深圳数字电视国家工程实验室股份有限公司 智能终端远程证明方法和系统
CN105159744A (zh) * 2015-08-07 2015-12-16 浪潮电子信息产业股份有限公司 一种虚拟机的度量方法及装置
CN105227319A (zh) * 2015-10-23 2016-01-06 浪潮电子信息产业股份有限公司 一种验证服务器的方法及装置
CN109714168A (zh) * 2017-10-25 2019-05-03 阿里巴巴集团控股有限公司 可信远程证明方法、装置和系统

Family Cites Families (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06261033A (ja) * 1993-03-08 1994-09-16 Nippon Telegr & Teleph Corp <Ntt> 認証制御方式
US5784566A (en) * 1996-01-11 1998-07-21 Oracle Corporation System and method for negotiating security services and algorithms for communication across a computer network
CN100544247C (zh) * 2004-02-16 2009-09-23 华为技术有限公司 安全能力协商方法
US7549048B2 (en) * 2004-03-19 2009-06-16 Microsoft Corporation Efficient and secure authentication of computing systems
CN100571134C (zh) * 2005-04-30 2009-12-16 华为技术有限公司 在ip多媒体子系统中认证用户终端的方法
CN1859096B (zh) * 2005-10-22 2011-04-13 华为技术有限公司 一种安全认证系统及方法
KR101009330B1 (ko) * 2006-01-24 2011-01-18 후아웨이 테크놀러지 컴퍼니 리미티드 모바일 네트워크를 기반으로 하는 엔드 투 엔드 통신에서의 인증을 위한 방법, 시스템 및 인증 센터
US20080046752A1 (en) * 2006-08-09 2008-02-21 Stefan Berger Method, system, and program product for remotely attesting to a state of a computer system
WO2008126183A1 (ja) * 2007-03-15 2008-10-23 Fujitsu Microelectronics Limited セキュアネットワークシステム、セキュア装置及びセキュアシステム
US8161285B2 (en) * 2008-09-26 2012-04-17 Microsoft Corporation Protocol-Independent remote attestation and sealing
WO2010113266A1 (ja) * 2009-03-31 2010-10-07 富士通株式会社 情報処理装置,情報処理装置の起動制御方法及び起動プログラム
CN101527718B (zh) * 2009-04-16 2011-02-16 西安西电捷通无线网络通信股份有限公司 一种建立三元对等鉴别可信网络连接架构的方法
CN102271320B (zh) * 2010-06-03 2016-01-20 中兴通讯股份有限公司 业务协商方法及系统
US20120131334A1 (en) * 2010-11-18 2012-05-24 International Business Machines Corporation Method for Attesting a Plurality of Data Processing Systems
EP2939166B1 (en) * 2012-12-28 2020-11-11 Nok Nok Labs, Inc. Query system and method to determine authentication capabilities
CN103501303B (zh) * 2013-10-12 2017-02-22 武汉大学 一种针对云平台虚拟机度量的主动远程证明方法
US10305893B2 (en) * 2013-12-27 2019-05-28 Trapezoid, Inc. System and method for hardware-based trust control management
CN103841198B (zh) * 2014-03-07 2017-03-29 中南大学 一种净室云计算数据处理方法及系统
US10635821B2 (en) * 2017-10-13 2020-04-28 Baidu Usa Llc Method and apparatus for launching a device
CN109729523B (zh) * 2017-10-31 2021-02-23 华为技术有限公司 一种终端联网认证的方法和装置
US10678938B2 (en) * 2018-03-30 2020-06-09 Intel Corporation Trustworthy peripheral transfer of ownership
GB2574598B (en) * 2018-06-11 2021-07-28 Advanced Risc Mach Ltd Attestation using device-specific and application-specific attestation messages
CN109005035B (zh) * 2018-07-12 2020-07-28 同济大学 一种网联汽车远程匿名签发验证通信系统
EP3671667A1 (en) * 2018-12-18 2020-06-24 Neopost Technologies Secured parcel locker system with token security
US11212119B2 (en) * 2019-04-05 2021-12-28 Cisco Technology, Inc. Remote attestation of modular devices with multiple cryptoprocessors
CN114640441A (zh) * 2019-06-24 2022-06-17 华为技术有限公司 一种远程证明方式的协商方法及装置
CN110309659A (zh) * 2019-07-08 2019-10-08 沈昌祥 一种基于双体系结构的可信计算平台的动态度量方法
CN112688782B (zh) * 2019-10-17 2023-09-08 华为技术有限公司 一种组合式设备的远程证明方法及设备

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101043338A (zh) * 2007-04-27 2007-09-26 中国科学院软件研究所 基于安全需求的远程证明方法及其系统
CN101477602A (zh) * 2009-02-10 2009-07-08 浪潮电子信息产业股份有限公司 一种可信计算环境中远程证明的方法
CN101610273A (zh) * 2009-08-03 2009-12-23 西安西电捷通无线网络通信有限公司 一种安全的远程证明方法
CN101951388A (zh) * 2010-10-14 2011-01-19 中国电子科技集团公司第三十研究所 一种可信计算环境中的远程证明方法
CN103560887A (zh) * 2013-11-04 2014-02-05 深圳数字电视国家工程实验室股份有限公司 智能终端远程证明方法和系统
CN105159744A (zh) * 2015-08-07 2015-12-16 浪潮电子信息产业股份有限公司 一种虚拟机的度量方法及装置
CN105227319A (zh) * 2015-10-23 2016-01-06 浪潮电子信息产业股份有限公司 一种验证服务器的方法及装置
CN109714168A (zh) * 2017-10-25 2019-05-03 阿里巴巴集团控股有限公司 可信远程证明方法、装置和系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
基于信息流的可信操作系统度量架构;胡浩等;《中国科学院研究生院学报》;20090715(第04期);全文 *

Also Published As

Publication number Publication date
CN112688907B (zh) 2023-06-30
EP4037279A1 (en) 2022-08-03
EP4030681A4 (en) 2022-11-16
BR112022006829A2 (pt) 2022-07-05
BR112022007167A2 (pt) 2022-06-28
US20220239688A1 (en) 2022-07-28
US20220237295A1 (en) 2022-07-28
EP4030681A1 (en) 2022-07-20
WO2021073376A1 (zh) 2021-04-22
JP2022553249A (ja) 2022-12-22
CN112688782A (zh) 2021-04-20
WO2021073375A1 (zh) 2021-04-22
CN112688907A (zh) 2021-04-20
EP4037279A4 (en) 2022-11-16
JP2022553247A (ja) 2022-12-22
JP7451696B2 (ja) 2024-03-18

Similar Documents

Publication Publication Date Title
CN112688782B (zh) 一种组合式设备的远程证明方法及设备
AU2011323225B2 (en) Device validation, distress indication, and remediation
KR101353725B1 (ko) 무선 네트워크내의 보안 키 관리 방법 및 시스템
US8479000B2 (en) Information processing device, authentication system, authentication device, information processing method, information processing program, recording medium, and integrated circuit
US20150106911A1 (en) Provisioning proxy for provisioning data on hardware resources
KR102558266B1 (ko) 데이터 수집 방법, 장치, 디바이스 및 컴퓨터가 판독 가능한 저장 매체
CN112134692B (zh) 一种远程证明方式的协商方法及装置
CN117453343A (zh) 虚拟机度量、机密计算认证方法、设备、系统及存储介质
Turan et al. Propagating trusted execution through mutual attestation
Johnson et al. Recommendations for distributed energy resource patching
JP6629773B2 (ja) 機器リスト作成システム、及び機器リスト作成方法
CN115695529B (zh) 智能化远程运维方法、装置、计算机设备及存储介质
JP2018205847A (ja) 情報処理システム、電子機器、情報処理方法、情報処理プログラム、情報管理方法及び情報更新方法
AU2015221575A1 (en) Device validation, distress indication, and remediation
Lin et al. Embedded approach for device inventory collection utilizing OS programmability
Min Evaluation and Implementation for Pushing Automatic Updates to IoT Devices
Jadhav Evaluation and implementation of zero-touch onboarding solutions for IIoT
CN117786700A (zh) 显卡启动系统、方法及存储介质
CN117591195A (zh) 目标应用的启动方法、装置和存储介质
Beyerstedt Secure and Robust Firmware Updates of IoT Devices
Palurik et al. Preparation and Deployment of Secure Over-The-Air Updates for Embedded Devices: Challenges and Solutions

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant