CN109948327A - 一种异常状态核查方法及终端 - Google Patents

Abstract

本发明公开了一种异常状态核查方法，包括验证方接收设备发送的凭据文件，确认其完整性，然后确认所述凭据文件的合法性，若确定设备不可信，则验证方将事先接收到的第一哈希值、第二哈希值和第三哈希值与预先保存的基准值进行对比校验，以确定异常发生的位置，本发明的技术方案能够做到设备启动过程中信任链的逐级传递，可准确及时的定位到异常发生的位置和阶段，极大地提升了安全设备的安全性和可信度。

Description

一种异常状态核查方法及终端

技术领域

本发明涉及安全验证领域，特别涉及一种异常状态核查方法及终端。

背景技术

Ukey(USB KEY)内置智能卡芯片、有一定的存储空间，可以存储用户的私钥以及数字证书，利用Ukey内置的公钥算法实现对用户身份的认证。由于用户私钥保存在密码芯片中，理论上很难进行破解，故可以保证用户认证的安全性。目前的黑客技术日新月异，很难破解不等于不能破解。

目前市面上常见的TF卡(Trans-flash Card)仅有存储功能而不支持密码算法，常见的TF卡的卖点在于容量和存储速度。个别面对行业用户的安全TF卡有密码功能、可以支持商密算法，可以看作是一种SD接口形式的智能卡安全芯片，由于没有独立的设计可信状态寄存器(TCR，Trusted Condition Register)故还是不可以做到在设备启动过程中信任链的逐级传递。

发明内容

基于现有技术中存在的上述问题，有必要提出一种设备的安全验证方法，将安全设备启动各个阶段的状态信息进行保存，据此建立信任链以供安全验证以及异常问题的回溯核查，从而提升安全设备的安全性和可信度。

一种异常状态核查方法，其特征在于，包括：

步骤1：验证方接收设备发送的凭据文件，确认其完整性；

步骤2：验证方确认所述凭据文件的合法性；

步骤3：验证方将事先接收到的第一哈希值、第二哈希值和第三哈希值与预先保存的基准值进行对比校验，以确定异常发生的位置和阶段。

还包括：

在所述步骤1中，验证方先对接收到的凭据文件进行完整性验签，若不完整则说明设备状态不可信，若完整则转到步骤2执行。

还包括：

在所述步骤2中，将所述凭据文件和验证方中预先保存的基准值进行对比校验，二者相同说明状态可信；如果不相同则说明设备不可信，转到步骤3。

本发明还提供一种用于实现异常状态核查的终端，其特征在于，使用上述方法实现异常状态回溯。

本实施例的技术方案能够做到设备启动过程中信任链的逐级传递，一旦设备的启动状态有了异常将会被及时发现并做出反应，并能准确的回溯到产生异常状态的位置和阶段，极大地提升了安全设备的安全性和可信度。

附图说明

图1是本发明实施例1的一种安全验证方法的处理逻辑图；

图2是本发明实施例1的一种安全验证方法的流程图；

图3是本发明实施例2的一种安全验证方法的处理逻辑图；

图4是本发明实施例2的一种安全验证方法的流程图；

图5是本发明实施例3的一种安全验证方法的处理逻辑图；

图6是本发明实施例3的一种安全验证方法的流程图；

图7是本发明实施例4的一种异常状态回溯方法的流程图；

图8是本发明实施例5的一种异常状态回溯方法的流程图。

具体实施方式

本发明提供一种安全验证方法及终端。为使本发明的目的、技术方案及效果更加清楚、明确，以下参照附图并举实施例对本发明进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。

本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

本发明在可信终端设备内的密码存储介质内增加一个或多个可信状态寄存器TCR，所述TCR的特点为：

在一个上电周期内不能被重新初始化；

只能通过拓展的方式来变化；

签名密钥在硬件内不能导出；

每一个TCR只能同时存储一个表征设备状态的哈希值，TCR内的值总是被后来生成的值所覆盖、替代。

实施例一

本实施例提供一种安全验证方法，在安全设备的芯片中设置第一TCR，请参阅图1-2，所述安全验证方法，包括以下步骤：

步骤1：设备上电启动，根据所述设备的核心代码芯片固件计算得到第一哈希值，与所述第一TCR内保存的初始哈希值进行运算得到第二哈希值，将所述第二哈希值写入到所述第一TCR中以覆盖所述初始哈希值。

具体地，设备开机启动后，中央处理器调用密码芯片对核心代码芯片固件做哈希运算得到第一哈希值,然后通过TCR扩展接口将所述第一TCR内的初始值和对核心代码芯片固件做哈希运算得到第一哈希值一起做哈希运算得到第二哈希值，再用所述第二哈希值将密码芯片所述第一TCR内存储的初始值覆盖掉。

具体地，采用MD5算法进行上述哈希值运算。

步骤2：根据所述设备的BOOTLOADER计算得到第三哈希值，与所述第一TCR内保存的第二哈希值进行运算得到第四哈希值，将所述第四哈希值写入到所述第一TCR中以覆盖所述第二哈希值。

具体地，中央处理器加载BOOTLOADER，中央处理器调用密码芯片对BOOTLOADER做哈希运算得到第三哈希值,然后通过TCR扩展接口将对BOOTLOADER做哈希运算得到第三哈希值和所述第一TCR内存储的第二哈希值一起做哈希运算得到的第四哈希值，再用所述第四哈希值将密码芯片所述第一TCR内存储的第二哈希值覆盖掉。

步骤3：根据所述设备的OS KERNAL计算得到第五哈希值，与所述第一TCR内保存的第四哈希值进行运算得到第六哈希值，将所述第六哈希值写入到所述第一TCR中以覆盖所述第四哈希值。

具体地，中央处理器加载OS KERNAL，中央处理器调用密码芯片对OS KERNAL做哈希运算得到第五哈希值，然后通过TCR扩展接口将所述第五哈希值和所述第一TCR内的值所述第四哈希值一起做哈希运算得到第六哈希值，再用所述第六哈希值将密码芯片所述第一TCR内存储的第四哈希值覆盖掉。:

步骤4：对所述第六哈希值进行数字签名，生成凭据文件并发送给验证方。

具体地，中央处理器调用密码芯片内的可信报告接口，利用密码芯片内的可信报告根对最终所述第一TCR内的数据(第六哈希值)做签名，生成凭据文件并发给验证方。

步骤5：通过比对所述凭据文件和基准值完成安全设备的可信度校验。

具体地，首先验证方验证生成的凭据文件，确认其完整性和来源的合法性。

具体地，验签通过后对比验证后的凭据文件和基准值进行校验，二者相同说明终端设备状态可信，如果不同说明设备状态不可信。

具体地，当设备状态不可信时，设备指示灯显示出不可信的状态、由管理中心作出相应的响应。

本实施例的技术方案能够做到设备启动过程中信任链的逐级传递，一旦设备的启动状态有了异常将会被及时发现并做出反应，极大地提升了安全设备的安全性和可信度。

实施例二

本实施例提供另一种安全验证方法，在安全设备的芯片中设置第一TCR、第二TCR、第三TCR和第四TCR，请参阅图3-4，所述安全验证方法，包括以下步骤：

步骤1：设备上电启动，根据所述设备的核心代码芯片固件计算得到第一哈希值，与所述第一TCR内保存的初始哈希值进行运算得到第二哈希值，将所述第二哈希值写入到所述第一TCR中以覆盖所述初始哈希值，并将所述第一哈希值存储到所述第二TCR内。

具体地，设备开机启动后，中央处理器调用密码芯片对核心代码芯片固件做哈希运算得到第一哈希值,然后通过TCR扩展接口将所述第一TCR内的初始值和对核心代码芯片固件做哈希运算得到第一哈希值一起做哈希运算得到第二哈希值，再用所述第二哈希值将密码芯片所述第一TCR内存储的初始值覆盖掉。

具体地，同时将核心代码芯片固件做哈希运算得到的所述第一哈希值保存在所述第二TCR内。

具体地，采用MD5算法进行上述哈希值运算。

步骤2：根据所述设备的BOOTLOADER计算得到第三哈希值，与所述第一TCR内保存的第二哈希值进行运算得到第四哈希值，将所述第四哈希值写入到所述第一TCR中以覆盖所述第二哈希值，并将所述第三哈希值存储到所述第三TCR内。

具体地，中央处理器加载BOOTLOADER，中央处理器调用密码芯片对BOOTLOADER做哈希运算得到第三哈希值,然后通过TCR扩展接口将对BOOTLOADER做哈希运算得到第三哈希值和所述第一TCR内存储的第二哈希值一起做哈希运算得到的第四哈希值，再用所述第四哈希值将密码芯片所述第一TCR内存储的第二哈希值覆盖掉。

具体地，同时将对BOOTLOADER做哈希运算得到的所述第三哈希值保存在所述第三TCR内。

步骤3：根据所述设备的OS KERNAL计算得到第五哈希值，与所述第一TCR内保存的第四哈希值进行运算得到第六哈希值，将所述第六哈希值写入到所述第一TCR中以覆盖所述第四哈希值，并将所述第五哈希值存储到所述第四TCR内。

具体地，中央处理器加载OS KERNAL，中央处理器调用密码芯片对OS KERNAL做哈希运算得到第五哈希值，然后通过TCR扩展接口将所述第五哈希值和所述第一TCR内的值所述第四哈希值一起做哈希运算得到第六哈希值，再用所述第六哈希值将密码芯片所述第一TCR内存储的第四哈希值覆盖掉。:

具体地，同时将对OS KERNAL做哈希运算得到的第五哈希值存储到所述第四TCR内。

步骤4：对所述第六哈希值进行数字签名，生成凭据文件并发送给验证方。

具体地，中央处理器调用密码芯片内的可信报告接口，利用密码芯片内的可信报告根对最终所述第一TCR内的数据(第六哈希值)做签名，生成凭据文件并发给验证方。

步骤5：通过比对所述凭据文件和基准值完成安全设备的可信度校验。

具体地，首先验证方验证生成的凭据文件，确认其完整性和来源的合法性。

具体地，验签通过后对比验证后的凭据文件和基准值进行校验，二者相同说明终端设备状态可信，如果不同说明设备状态不可信。

具体地，当设备状态不可信时，设备指示灯显示出不可信的状态、由管理中心作出相应的响应。

本实施例的技术方案能够做到设备启动过程中信任链的逐级传递，一旦设备的启动状态有了异常将会被及时发现并做出反应，极大地提升了安全设备的安全性和可信度，通过在设备中设置多个TCR以实现当发生哈希值匹配失败时，可以调用设备TCR中存储的哈希值对异常状态发生的位置进行回溯。

实施例三

本实施例提供另一种安全验证方法，在安全设备的芯片中设置第一TCR、第二TCR和第三TCR，请参阅图5-6，所述安全验证方法，包括以下步骤：

步骤1：设备上电启动，根据所述设备的核心代码芯片固件计算得到第一哈希值，将所述第一哈希值写入到所述第一TCR中。

具体地，设备开机启动后，中央处理器调用密码芯片对核心代码芯片固件做哈希运算得到第一哈希值,然后通过TCR扩展接口将对所述核心代码芯片固件做哈希运算得到的第一哈希值保存到所述第一TCR中。

具体地，采用MD5算法进行上述哈希值运算。

步骤2：根据所述设备的BOOTLOADER计算得到第二哈希值，将所述第二哈希值写入到所述第二TCR中。

具体地，中央处理器加载BOOTLOADER，中央处理器调用密码芯片对BOOTLOADER做哈希运算得到第二哈希值,然后通过TCR扩展接口将对BOOTLOADER做哈希运算得到的第二哈希值保存到所述第二TCR中。

步骤3：根据所述设备的OS KERNAL计算得到第三哈希值，将所述第三哈希值写入到所述第三TCR中。

具体地，中央处理器加载OS KERNAL，中央处理器调用密码芯片对OS KERNAL做哈希运算得到第三哈希值，然后通过TCR扩展接口将所述第三哈希值保存到所述第三TCR中。

步骤4：对所述第一哈希值、第二哈希值和第三哈希值一起做签名运算，生成凭据文件并发送给验证方。

具体地，中央处理器调用密码芯片内的可信报告接口，利用密码芯片内的可信报告根对所述第一TCR内的所述第一哈希值、所述第二TCR内的所述第二哈希值和所述第三TCR内的第三哈希值一起做数字签名运算，生成凭据文件并发给验证方。

步骤5：通过比对所述凭据文件和基准值完成安全设备的可信度校验。

具体地，首先验证方验证生成的凭据文件，确认其完整性和来源的合法性。

具体地，验签通过后对比验证后的凭据文件和基准值进行校验，二者相同说明终端设备状态可信，如果不同说明设备状态不可信；其中，只有当所述第一哈希值、所述第二哈希值和所述第三哈希值均验证成功时才说明设备状态可信。

具体地，当设备状态不可信时，设备指示灯显示出不可信的状态、由管理中心作出相应的响应。

本实施例的技术方案能够做到设备启动过程中信任链的逐级传递，一旦设备的启动状态有了异常将会被及时发现并做出反应，极大地提升了安全设备的安全性和可信度，通过将利用设备各启动状态得到的哈希值发送给验证方，以实现当验证失败时在验证方进行设备异常状态的回溯。

实施例四

本实施例提供一种异常状态回溯方法，可与实施例二中的安全验证方法配合使用，参见附图7，包括以下步骤：

步骤1：验证方接收设备发送的凭据文件，确认其完整性。

具体地，验证方先对接收到的凭据文件进行完整性验签，若不完整则说明设备状态不可信，若完整则转到步骤2执行。

步骤2：验证方确认所述凭据文件的合法性。

具体地，将所述凭据文件和验证方中预先保存的基准值进行对比校验，二者相同说明状态可信；如果不相同则说明设备不可信，转到步骤3。

步骤3：验证方与设备建立通信，读取设备第二TCR、第三TCR和第四TCR中保存的第一哈希值、第三哈希值和第五哈希值，与验证方中预先保存的基准值进行对比校验，确定异常发生的位置和阶段。

本实施例的技术方案能够做到设备启动过程中信任链的逐级传递，一旦设备的启动状态有了异常将会被及时发现并做出反应，并能准确的回溯到产生异常状态的位置和阶段，极大地提升了安全设备的安全性和可信度。

实施例五

本实施例提供另一种异常状态回溯方法，可与实施例三中的安全验证方法配合使用，参见附图8，包括以下步骤：

步骤1：验证方接收设备发送的凭据文件，确认其完整性。

具体地，验证方先对接收到的凭据文件进行完整性验签，若不完整则说明设备状态不可信，若完整则转到步骤2执行。

步骤2：验证方确认所述凭据文件的合法性。

具体地，将所述凭据文件和验证方中预先保存的基准值进行对比校验，二者相同说明状态可信；如果不相同则说明设备不可信，转到步骤3。

步骤3：验证方将接收到的第一哈希值、第二哈希值和第三哈希值与预先保存的基准值进行对比校验，以确定异常发生的位置和阶段。

本实施例的技术方案能够做到设备启动过程中信任链的逐级传递，一旦设备的启动状态有了异常将会被及时发现并做出反应，并能准确的回溯到产生异常状态的位置和阶段，极大地提升了安全设备的安全性和可信度。

实施例六

本实施例提供一种安全验证终端，使用上述实施例一、实施例二和实施例三中任一实施例提供的方法进行设备安全验证。

实施例七

本实施例提供一种异常状态回溯终端，使用上述实施例四和实施例五中任一实施例提供的方法进行设备异常状态回溯。

在本发明所提供的几个实施例中，应该理解到，所揭露的方法和终端，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

另外，在不发生矛盾的情况下，上述几个实施例中的技术方案可以相互组合和替换。

所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能模块的形式实现。

对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本发明内。不应将权利要求中的任何附关联图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。系统权利要求中陈述的多个模块或装置也可以由一个模块或装置通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。

最后应说明的是，以上实施例仅用以说明本发明的技术方案而非限制，尽管参照较佳实施例对本发明进行了详细说明，本领域的普通技术人员应当理解，可以对本发明的技术方案进行修改或等同替换，而不脱离本发明技术方案的精神和范围。

Claims (4)

1.一种异常状态核查方法，其特征在于，包括：

步骤1：验证方接收设备发送的凭据文件，确认其完整性；

步骤2：验证方确认所述凭据文件的合法性；

步骤3：验证方将事先接收到的第一哈希值、第二哈希值和第三哈希值与预先保存的基准值进行对比校验，以确定异常发生的位置和阶段。

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

在所述步骤1中，验证方先对接收到的凭据文件进行完整性验签，若不完整则说明设备状态不可信，若完整则转到步骤2执行。

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

在所述步骤2中，将所述凭据文件和验证方中预先保存的基准值进行对比校验，二者相同说明状态可信；如果不相同则说明设备不可信，转到步骤3。

4.一种用于实现异常状态核查的终端，其特征在于，使用上述权利要求1-3中任一权利要求所提供的方法实现异常状态回溯。