GB/T 36639-2018 信息安全技术 可信计算规范 服务器可信支撑平台

  • GB/T 36639-2018  信息安全技术 可信计算规范 服务器可信支撑平台为pdf格式
  • 文件大小:2M
  • 下载速度:极速
  • 文件评级
  • 更新时间:2020-01-13
  • 发 布 人: 13648167612
  • 原始文件下载:
  • 原始文件是会员上传的无错版,推荐下载这个版本

  • 电力弱电,pdf格式,下载需要20积分
  • 立即下载

  • word版文件下载:
  • 特别提醒:word版是本站通过人工智能从pdf转换成的word版本,正确率只有90%左右(正在通过训练继续提高准确率),排版恢复的也并不完全准确,没有进行任何人工校对,VIP会员直接免费下载即可,普通会员无法通过点数下载,算是给VIP的活动。

    特别提醒:word版是不完美的,错误较多,只能参考,有需要的可以少打一些字,别下载了找我们说word内容有问题,这是送给VIP会员的。

  • 文档部分内容预览:
  • GB/T366392018

    实现与物理可信根相对应的功能及接口规范; ·接收并传递来自服务器硬件系统的信任关系到操作系统; ·提供访问和管理物理可信根相关可信接口; ·维护服务器硬件系统与操作系统的信任关系。 b) 在虚拟化环境下,还应包含虚拟可信组件。虚拟可信组件应满足如下要求: · 由虚拟可信根管理器、虚拟可信根、可信迁移、远程证明等组成; ·将信任链从操作系统传递到虚拟机; ·为虚拟机提供可信根服务,使得虚拟机中的可信基础组件无差异地使用虚拟可信根服务; 确保虚拟机与虚拟可信根实例的一对一绑定关系

    服务器可信支撑平台申,密码算法是基础,物理可信根和虚拟可信根是关键部件,完整性度量、 报告是基本可信机制

    物理可信根应满足如下要求: a 是服务器完整性度量的起点; b) 符合相关技术规范的要求,包含但不限于GB/T29829—2013中4.1.3、GB/T29827—2013中 第5章的要求; c)其硬件载体应通过国家相关部门的许可

    给排水工艺、技术虚拟可信根应满足如下要求: a)是虚拟机完整性度量的起点; b)实现物理可信根相匹配的可信功能及接口; C)其实例仅能为一个固定的虚拟机提供可信服务

    可信基础组件的实现应与物理可信根相匹配,如物理可信根为TCM,则可信基确 务模块(TSM)

    5.5完整性度量、存储及报告

    服务器完整性度量、存储及报告应满足如下要求: a) 符合GB/T29829—2013中4.3.1.2的要求; b)服务器中相关部件的完整性度量值应存储于物理可信根中; c)虚拟机中相关部件的完整性度量值应存储于虚拟可信根中。

    服务器完整性度量、存储及报告应满足如下要求: a)符合GB/T29829—2013中4.3.1.2的要求; b)服务器中相关部件的完整性度量值应存储于物理可信根中; c)虚拟机中相关部件的完整性度量值应存储于虚拟可信根中

    本标准凡涉及密码算法的相关内容,按国家有关法规实施;凡涉及采用密码技术角

    本标准凡涉及密码算法的相关内容,按国家有关法规实施;凡涉及采用密码技术解决保密性、完

    性、真实性、不可否认性需求的应遵循密码相关国家标准和行业标准

    6服务器硬件系统可信功能要求

    GB/T366392018

    服务器硬件系统信任链从上电到物理可信根启动后,操作系统内核加载之前的建立流程见图2。

    图2服务器硬件系统信任链建立流程

    a) 服务器硬件系统启动时,物理可信根应作为信任链传递的起点; ) 由物理可信根中的RTM度量OMMBootLoader,生成的度量结果存储于物理可信根中,并 存储度量日志; OMMBootLoader加载并执行; ) OMMBootLoader中的度量执行点对OMMKernel进行完整性度量,OMMKernel中度量 执行点对应用程序及服务进行完整性度量; ) 由物理可信根中的RTM度量BootROM中的初始引导模块(BootBlock),生成度量结果存储 于物理可信根中,并存储度量日志; BootRom中的BootBlock加载并执行; g BootBlock中的度量执行点对MainBlock进行完整性度量,MainBlock中的度量执行点对服 务器外设和OSLoader进行完整性度量

    OMM度量应满足如下要求: a)度量内容至少包括:OMM引导程序、OMM内核、OMM核心应用程序; b)将度量值存储于物理可信根约定的PCR中:

    GB/T366392018

    c)提供度量日志查询接口。

    基于GB/T29827一2013设计和实现的服务器主板,宜根据附录A的要求实现服务器主板时

    7.1对服务器硬件系统的要求

    在启用虚拟可信组件之前,服务器硬件系统应满足如下要求: a 为虚拟化层中虚拟可信组件与非虚拟可信组件提供隔离支撑机制。 b) 物理可信根应具备如下条件: 1)已部署背书密钥; 2)已部署存储根密钥和其他附属存储密钥: 3)提供安全存储空间,用以存储密钥、证书和其他秘密数据。 c)服务器硬件系统信任链已扩展至虚拟可信组件

    除5.3所描述的要求外,虚拟可信根还应满足如下要求: a) 具备唯一标识, b) 包含可用于证实其对应VM可信状态的信息。 c) 提供与物理可信根相同的服务接口。 d) 虚拟可信根中的虚拟可信报告vRTR、虚拟可信存储根vRTS、虚拟可信根度量vRTM应基于 物理可信根密码机制来实现。 e) 对虚拟可信根中敏感信息和状态数据提供保护机制。 f) 若虚拟可信根基于软件实现,还应满足如下要求: 1) 在约定的位置定义扩展资源(如vPCRs)的分配方式和要求。 提供防回滚机制,防止虚拟可信根在非授权情况下回滚到历史状态。 3) 具备数据备份恢复功能。 4) 具备版本升级功能 5) 虚拟可信根在版本升级过程中应完成如下操作: 维护并确保永久性状态数据的可用性和完整性; 维护并确保敏感数据的机密性与完整性

    7.2.2 生命周期管理

    虚拟可信根的生命周期管理是指在VM创建、启动、运行、关闭、挂起、销毁、迁移等七种状态切换 时对虚拟可信根的运行状态的管理,如图3所示

    GB/T366392018

    图3虚拟可信根生命周期

    7.2.3虚拟可信度量根

    VM初始化代码在执行前应通过虚拟可信度量根对其进行完整性度量,并扩展度量值到虚拟可 中的vPCR中。虚拟可信度量根实现方式可参考附录B

    GB/T366392018

    7.2.4密钥与证书要求

    虚拟可信根密钥管理应满足如下要求: a)虚拟可信根背书密钥应是可认证的; b)若虚拟可信根基于软件实现,还应提供防止虚拟可信根密钥被复制的机制

    虚拟可信根应满足以下安全性要求: a) 当虚拟可信根运行或关闭时,应保护虚拟可信根的敏感信息,防止篡改或暴露; 当虚拟可信根不再被使用时,应加密存储虚拟可信根中的数据: C) 虚拟可信根运行期间,应提供访问控制机制,防止非授权访问虚拟可信根敏感信息 d) 将虚拟可信根与非可信组件进行隔离; e) 虚拟可信根中敏感信息离开受保护区域时(如数据备份、迁移等场景),应被加密; 确保VM只能通过VM中的可信基础组件接口访问虚拟可信根

    7.3虚拟可信根管理器

    虚拟可信根管理器是负责管理同一虚拟可信组件中所有虚拟可信根实例的组件,并建立和维护虚 以可信根与虚拟机一一绑定的对应关系。虚拟可信根管理器应满足如下要求: a) 虚拟可信根管理器应具备如下功能 1)提供证明虚拟可信根身份真实性的机制。 2): 提供物理可信根访问控制机制,防止虚拟可信根访问物理可信根中敏感信息或受限资源 根据用户配置,为新建的虚拟机创建一个虚拟可信根实例。 4) 当虚拟机销毁时,删除该虚拟机对应的虚拟可信根实例 5) 当虚拟机迁移时,删除该虚拟机在源服务器可信支撑平台中对应的虚拟可信根实例。 6) 若虚拟可信根基于软件实现,还应具备如下功能: ·在虚拟可信根创建时,负责初始化虚拟可信根中的基本信息(如厂商信息等); ·为虚拟可信根中的vEK提供可被认证的机制; ·维护其所在服务器可信支撑平台上所有虚拟可信根当前数据的完整性信息。 b)虚拟可信根管理器设计、实现和使用过程中应满足如下要求: 1)确保同一服务器可信支撑平台上只有一个虚拟可信根管理器; 2)是可被认证的

    7.3.2密钥与证书要求

    密钥与证书应满足如下要求: a)虚拟可信根管理器标识密钥应由物理可信根产生; b)虚拟可信根管理器数据加密密钥应由物理可信根保护

    虚拟可信根管理器应满足如下安全要求: a)基于服务器可信支撑平台信任链机制保障虚拟可信根管理器的完整性; b)提供虚拟可信根管理器敏感信息保护机制:

    GB/T366392018

    c)支持远程证明; d)提供评估虚拟可信根管理器及虚拟可信组件的身份合法性及可信状态的机制。

    性和完整性,可信迁移组件应满足如下要求: a)可被外部实体认证的; b) 提供虚拟可信根数据安全性保障机制,确保可信迁移过程中虚拟可信根数据的安全性; 提供防回滚机制,防止迁移过程中回滚虚拟可信根状态; 提供虚拟可信根状态数据加解密机制

    远程证明组件用于负责向外部实体证明所在平台可信状态。参与远程证明过程的角色包括远程证 明验证者、远程证明组件等。远程证明组件用于生成并发送本平台可信报告及身份信息给远程证明验 证者;远程证明验证者是远程证明请求的发起方,并根据远程证明组件提供的可信报告及身份信息验证 平台身份合法性及可信状态。服务器可信支撑平台远程证明应满足如下要求: a)远程证明过程中证明的信息包括平台身份信息、平台完整性报告。 b 远程证明流程应符合GB/T29829一2013中4.3.1.4的要求。 c) 远程证明过程中所使用的证书应符合物理可信根相关规范要求。 在虚拟化环境下,还应满足如下要求: 1)具备检测虚拟机监控器是否运行于服务器硬件系统之上的能力; 2)虚拟机监控器提供的证明信息中应不包含任何虚拟可信根的敏感信息

    虚拟可信根可信迁移特指在服务器可信支撑平台上,虚拟机迁移时,其对应的虚拟可信根迁移的过 程。虚拟可信根可信迁移应满足以下基本要求: a) 参与虚拟可信根可信迁移的角色包括源服务器可信支撑平台、目标服务器可信支撑平台、可信 方等; b) 参与虚拟可信根可信迁移的服务器可信支持平台中的可信迁移组件应满足7.4要求; c) 虚拟可信根可信迁移过程中远程证明应满足7.5要求; 可信迁移应仅在虚拟可信根对应的VM迁移时触发; e) 虚拟可信根迁出平台为源服务器可信支撑平台; f) 虚拟可信根迁人平台为目标服务器可信支撑平台; g) 虚拟可信根迁移前,应先完成源服务器可信支撑平台和目标服务器可信支撑平台间的双向远 程证明,确保参与可信迁移过程的双方均是可信的; 迁移过程中同一时刻虚拟可信根只能在一个服务器可信支撑平台上运行

    虚拟可信根可信迁移基本流程如图4所示

    GB/T366392018

    图4虚拟可信根可信迁移流程

    源可信迁移组件、目标可信迁移组件与可信方协同,完成源服务器可信支撑平台与目标服务器 可信支撑平台的双向远程证明; b) 虚拟可信根可信迁移目标平台接收到可信迁移请求后,源服务器可信支撑平台与目标服务器 可信支撑平台建立安全传输通道; C 目标服务器可信支撑平台创建一个空的虚拟可信根实例,准备接收源服务器可信支撑平台发 送的虚拟可信根相关数据; d) 源服务器可信支撑平台收集源虚拟可信根实例状态数据(如NVRAM、密钥、授权等数据); e) 源服务器可信支撑平台通过安全通道传输源虚拟可信根状态数据到目的服务器可信支撑 平台; 0 目标服务器可信支撑平台检查状态数据的完整性;检查通过后,使用接收到的状态数据初始化 并启动虚拟可信根,并与对应的虚拟机绑定; g 待目标服务器可信支撑平台完成虚拟机与虚拟可信根绑定后,源服务器可信支撑平台删除源 虚拟可信根实例

    GB/T366392018

    基于GB/T29827一2013设计和实现的服务器可信支撑平台,宜根据其8.1的要求对物理可信根 和服务器主板及其他部件之间的上电及开机启动时序实施控制,实现服务器上电后,在OMM和CPU 启动前,由物理可信根先对OMMROM中的BootLoader和BootROM中的BootBlock实现完整性 变量。物理可信根中的RTM度量完OMMROM和BootROM后,物理可信根发出控制信号启动 CPU、芯片组等通用设备。服务器硬件时序控制逻辑如图A.1所示

    A.2服务器主板上电时序

    服务器主板上电时序为: a) 服务器上电, b) 时序控制电路给物理可信根上电,物理可信根自我初始化。 C) 物理可信根执行RTM,RTM度量ROM数据: 1)RTM可靠地读取OMMROM,并度量其中的BootLoader代码的完整性; 2)RTM可靠地读取BOOTROM,并度量其中的BootBlock代码的完整性。 d) 物理可信根根据RTM对ROM的度量结果,向时序控制电路输出对应的指令。 时序控制电路根据物理可信根的输出指令来判决是否给OMM和CPU系统上电 f) OMM上电后,开始执行OMMROM代码。 g) CPU上电后.开始执行BOOTROM代码

    GB/T366392018

    A.3服务器主板复位时序

    服务器主板复位时序为: a)CPU系统触发复位后应通知物理可信根; b)由物理可信根中的RTM可靠地读取BOOTROM,并度量其中的BootBlock代码的完整性; C 物理可信根把RTM对BOOTROM的度量结果,向时序控制电路输出对应的指令; d) 时序控制电路根据物理可信根的度量反馈结果来判决是否进行CPU系统的复位; CPU开始执行BOOTROM代码

    服务器主板复位时序为: a)CPU系统触发复位后应通知物理可信根; b)由物理可信根中的RTM可靠地读取BOOTROM,并度量其中的BootBlock代码的完整性; 物理可信根把RTM对BOOTROM的度量结果,向时序控制电路输出对应的指令; 时序控制电路根据物理可信根的度量反馈结果来判决是否进行CPU系统的复位; CPU开始执行BOOTROM代码

    桥梁工程A.4服务器OMM复位时序

    服务器OMM复位时序为: a)OMM系统触发复位后应通知物理可信根; 由物理可信根中的RTM可靠地读取OMMROM的BootLoader代码: 物理可信根根据RTM对OMMROM的度量结果,向时序控制电路输出对应的指令; 时序控制电路根据物理可信根发送的指令来决定是否进行OMM系统的复位; OMM开始执行OMMROM代码

    GB/T366392018

    以下给出三种虚拟可信根的实现方法,供参考使用: a)如果VM采用模拟固件启动,可在模拟固件中嵌入虚拟可信度量根,VM通过模拟可信固件 启动。该方法的参考实现如下: 1)虚拟机监控器为VM启动提供包含vBIOS和虚拟可信度量根虚拟引导固件环境; 2)vBIOS包含从vRTM到VM启动阶段信任链传递所需要的其他组件; 3)vRTM扩展度量结果到虚拟可信根的vPCRs中; 4)月 虚拟可信根的vPCRs中包含vRTM的度量结果; 5)虚拟可信根vPCRs的分配方式应遵循相应物理可信根PCRs分配要求; 6)为模拟可信固件配备安全策略,并提供保护这些安全策略的机制GB/标准规范范本,防止非授权篡改。 b) 在VM启动前,可通过一个可信组件对VM启动序列进行完整性度量。该方法的参考实现 如下: 1) VMM或操作系统中的其他可信组件初始化一个封装层,将VM置于封装层中启动;该 组件的可信状态是虚拟可信根的一部分; 2) VMM应度量为VM初始化启动环境的组件,并扩展度量值到虚拟可信根的vPCRs中; 3) 虚拟可信度量根的度量对象包含虚拟机启动前的所有组件,直到虚拟机接收信任链,并 可以继续传递信任链; 4)度量内容应包括虚拟机的配置数据。 在VM启动前和运行过程中,通过VMM或操作系统中的其他可信组件,为VM提供动态的 可信度量根服务,并在VM启动前使用该组件完成对可执行的VM镜像文件的度量。该方法 的参考实现如下: 1)如果VM没有模拟固件或其他类似组件,启动VM的代码应为VM构建并初始化一个封 装层,将VM置于封装层中启动; 2)虚拟机监控器应度量为VM构建启动环境的程序,并扩展度量值到虚拟可信根的 vPCRs 中; 3)虚拟可信组件中与VM关联的证书应包含如何填充虚拟可信根PCRs的定义

    GB/T366392018

    1028一2007信息安全技术服务器安全技术要

    ....
  • 相关专题: 信息安全技术  
专题: 体育标准 |检验检疫标准 |生产标准 |国家标准 |煤炭标准 |

常用软件