一种安全目标的分解与建模方法及相关设备与流程

本申请涉及计算机软件领域，尤其涉及一种安全目标的分解与建模方法及相关设备。

背景技术：

安全目标是在系统安全性上需要达到的技术效果。在软件设计开发之前，根据期望达成的安全目标提出安全策略(又称安全协议或安全技术方案)，将安全目标分解为一个个安全属性，通过对安全属性进行验证其安全性以确保安全策略能达成安全目标。

针对于安全目标的安全属性验证，在软件系统设计领域引入了基于数理逻辑的形式化验证方法来分析安全策略能否满足预期的安全目标。安全目标一般是用自然语言描述的，其中，采用数学逻辑公式无二义对安全目标进行刻画得到安全目标的可验证属性。对于上述基于数理逻辑的形式化验证方法而言，将安全目标进行分解，并使用数学逻辑公式进行准确地描述显得至关重要，若安全目标不能准确地对自然语言描述的安全目标进行描述，则采用上述基于数理逻辑的形式化验证方法得到的不准确的验证结果。

在安全性验证领域，对于自然语言描述的安全目标到数理逻辑的转化，一般基于安全策略进行总结分析，提取出安全目标对应的安全属性，使得得到的安全属性具有很大的随机性，与安全目标之间不存在明确的对应关系，并不能客观准确地描述自然语言描述的安全目标。

技术实现要素：

本申请提供了一种安全目标分解与建模方法及相关设备，用于提高安全目标进行分解的准确性，提升安全目标形式化验证的可靠性。

本申请第一方面提供了一种安全目标分解与建模方法，包括：

根据安全策略的统一建模语言时序图和状态图中的至少一个，获取所述安全策略的n类实体信息，所述n为不小于2的正整数，所述实体信息为所述安全策略的各进程及进程间的信道、数据和活动流程中的至少一项；

根据安全属性描述库中的可验证属性类型确定所述n类实体信息中每一类实体信息的可验证属性；

根据数学逻辑公式模板和每一类实体信息生成每一类实体信息的数学逻辑公式，所述数学逻辑公式模板与所述每一类实体信息的可验证属性对应。

从以上技术方案可以看出，本申请具有以下优点：

从安全策略的umlsequencediagram和umlstatediagram中的至少一个中获取其安全策略的实体信息即各进程之间的信道、数据和活动流程，并将实体信息划分为n类，最后，基于安全描述库中的可验证属性对每一类实体信息进行进一步分解得到每一类实体信息的数学逻辑公式。可以理解，基于安全属性描述库中的可验证属性对应的数学逻辑公式是经过实际验证得到的，准确性较高，并且基于umlsequencediagram和umlstatediagram对安全策略中的实体信息进行分解，客观性更强和普遍适用性更强。因此，本申请中安全目标分解和建模方法可以使得安全属性的数理逻辑化描述更加准确，适用性更强，以提高安全目标的验证准确性。

结合本申请的第一方面，在第一方面的第一种可能的实现方式中，在所述根据数学逻辑公式模板和每一类实体信息生成每一类实体信息的数学逻辑公式之后，所述方法还包括：

根据用户指示对所述每一类实体信息的数学逻辑公式进行筛选，得到每一类实体信息的待验证数学逻辑公式。

该种实现方式中，根据用户指示对每一类实体信息对应的数学逻辑公式进行筛选，可以排除对安全目标刻画不准确的数学逻辑公式，提高安全目标分解的准确性。

结合本申请的第一方面或第一方面的第一种可能的实现方式，在第一方面的第二种可能的实现方式中，在所述根据数学逻辑公式模板和每一类实体信息生成每一类实体信息的数学逻辑公式之前，所述方法还包括：

从所述安全属性描述库中，获取所述每一类实体信息的可验证属性的所有数学逻辑公式；

根据每一类实体信息的实体信息类别，从所述每一类实体信息的可验证属性的所有数学逻辑公式中确定所述数学逻辑公式模板。

在第二种可能的实现方式中，通过数学逻辑公式与实体信息类别，确定数学逻辑公式模板，可以客观地描述出不同类别的实体信息对应的数学逻辑公式模板，避免使用对数学逻辑公式对不需要验证的实体信息类别进行验证，避免造成资源浪费，提高效率。

结合本申请的第一方面、第一方面的第一种可能的实现方式或第一方面的第二种可能的实现方式中任一种实现方式，在第一方面的第三种可能的实现方式中，所述n类实体信息包括：进程间通信信道、进程间通信数据、进程间关键活动流程、进程本地数据、进程本地关键活动流程；

所述根据安全策略的统一建模语言时序图或状态图，获取所述安全策略的n类实体信息，包括：

根据所述安全策略的统一建模语言时序图确定所述安全策略中的各进程节点、各进程间通信信道、各进程通道数据和各进程间关键活动流程；

根据所述安全策略中每一个进程节点的统一建模语言状态图确定所述安全策略中的每一个进程节点的本地关键活动流程和本地数据。

从安全策略的umlsequencediagram和umlstatediagram中的至少一个中获取其安全策略的实体信息即各进程之间的信道、数据和活动流程，并将实体信息划分为n类，可以准确、全面地获取到安全目标或安全策略对应的所有实体信息，避免遗漏实体信息造成后续形式化验证结果不准确。

结合本申请第一方面的第一种可能的实现方式，在本申请的第一方面的第四种可能的实现方式中，在所述根据用户指示对所述每一类实体信息的数据逻辑公式进行筛选，确定每一类实体信息的待验证数学逻辑公式之后，所述方法还包括：

根据所述每一类实体信息的可验证属性，调用形式化验证工具验证对所述每一类实体信息的待验证数学逻辑公式进行数理逻辑验证，得到验证结果。

第二方面，本申请实施例提供一种分析建模设备，该分析建模设备具有实现上述方法实施例中分析建模设备行为的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。

第三方面，本申请实施例提供一种分析建模设备，包括：处理器、存储器、总线、输入设备和输出设备；该存储器用于存储计算机执行指令，该处理器与该存储器通过该总线连接，当该分析建模设备运行时，该处理器执行该存储器存储的该计算机执行指令，以使该分析建模设备执行如上述第一方面任意一项的安全目标分解与建模方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，用于储存为上述分析建模设备所用的计算机软件指令，当其在计算机上运行时，使得计算机可以执行上述第一方面中任意一项的安全目标分解与建模方法。

第五方面，本申请实施例提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机可以执行上述第一方面中任意一项的安全目标分解与建模方法。

另外，第二方面至第五方面中任一种设计方式所带来的技术效果可参见第一方面中不同设计方式所带来的技术效果，此处不再赘述。

附图说明

图1为本申请实施例中安全目标分解与建模方法的系统架构图；

图2为本申请实施例中安全目标分解与建模方法的一个实施例示意图；

图3为本申请实施例中安全策略和协议分解器基于umlsequencediagram和umlstatediagram的安全策略分解示意图；

图4为本申请实施例中的一个安全目标分解流程示意图；

图5为本申请实施例中的一个安全目标分解逻辑树示意图；

图6为本申请实施例中的一个建模层的建模流程示意图；

图7为客户端应用程序和可信应用程序之间交互的一个信令示意图；

图8为客户端应用程序对可信应用程序鉴权策略的umlsequencediagram图；

图9为客户端应用程序对可信应用程序鉴权策略打开会话阶段的检测节点3的的umlstatediagram图；

图10为本申请中分析建模设备的一个实施例示意图；

图11为本申请中分析建模设备的另一个实施例示意图；

图12为本申请中分析建模设备在一个硬件设备中实现的硬件结构示意图；

图13为本申请中分析建模设备在对个硬件设备中实现的硬件结构示意图。

具体实施方式

本申请提供了一种安全目标分解与建模方法，用于提高安全目标的数理逻辑化描述准确性，以提高安全目标的验证准确性。下面将结合本申请中的附图，对本申请中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。

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

安全属性描述库中存储有各种可验证属性对应的数学逻辑及其构建的模板。可验证属性是指将能够被数学逻辑公式无二义刻画的安全目标，其中，安全属性是将安全目标细化后得到的，是系统达成安全目标所要满足的安全属性。可验证属性可以分为多种类别，其中较为典型的是保密属性secrecy、安全属性safety和活性属性liveness。保密属性是指系统交互的信息不被非授权用户获取，即断言系统“保证交互的敏感信息不被泄露”，如协议私钥、公钥是否被攻破等。安全属性是指系统不能进入异常状态，即断言系统“不会做坏事”，如系统的死锁，互斥锁，死循环等。活性属性是指系统最终要到达预期的状态，即断言系统“终究会做好事”。活性属性较为复杂，主要用于刻画系统行为需要满足的时序逻辑特性，活性又可被分为多个种类，如线性时序逻辑(lineartemporallogic，ltl)属性，对应性correspondence属性，可计算树逻辑(computationaltreelogic，ctl)属性等。

基于数理逻辑的形式化验证技术是将待验证系统(如安全策略)抽象为一个定义好的数学对象，使用数学逻辑精准描述其行为。形式化验证最主要的技术是模型检测modelchecking和定理证明theoremproving。模型检测的主要思想是用一个有限状态机对软件系统的程序状态和状态之间的迁移关系进行抽象建模，用时态逻辑公式对性质规约进行刻画，然后通过状态空间遍历的方法来验证性质规约是否被满足。相关的模型检测工具包括：smv，nusmv，uppaal，spin，satmc。

定理证明把软件系统是否满足性质规约的问题转化成定理的形式，然后通过数学逻辑公式和推导演绎规则进行验证。使用定理证明能够证明安全协议的正确性，相关的定理证明工具包括：proverif，cl-atse。

如图1所示为本申请实施例中安全目标分解与建模方法的系统架构图，包括：分解层、建模层和验证层，其中，分解层用于对安全策略或安全协议，以及自然语言描述的安全目标进行分解，一方面，基于umlsequencediagram和umlstatediagram进行分解，得到分解结果，图1中基于统一建模语言时序图和状态图的安全策略和协议分解器用于实现上述对安全协议和策略的分解功能；另一方面，图1中基于安全属性描述库的安全目标分解器，结合自然语言描述的安全目标以及上述安全策略和协议分解器的分解结果进行分解。

建模层，用于根据上述安全目标分解器得到的分解结果进行建模，得到将安全协议及安全目标抽象化之后的数学逻辑公式，其中，安全属性自动化建模工具可使用上述模型检测工具实现。验证层，用于将上述建模得到的数学逻辑公式进行形式化验证，以便验证上述安全策略能否达到上述安全目标，其中，形式化验证器可以使用上述定理证明工具实现。

本申请实施例中的安全目标分解与建模方法主要涉及模型检测技术，将安全目标具体化后的安属性进行准确分解，并通过数理逻辑进行正确、全面的描述。为了便于理解本申请实施例的上述方法，下面结合具体的实施例对本申请技术方案进行详细描述。

201、根据安全策略的统一建模语言时序图和状态图中的至少一个获取安全策略的n类实体信息。

在软件系统设计过程中，为达到某一个安全目标制定相应的安全策略，例如根据“防止恶意软件实体访问可信执行环境，仅允许被内置授权软件实体访问”的安全目标制定名称为“客户端应用程序对可信应用程序的鉴权策略”。在根据安全策略进行软件系统开发之前，需要对上述安全策略以安全目标进行分解、验证，在验证结果为安全策略能到达成安全目标之后才进行软件系统开发。

根据安全策略的umlsequencediagram和umlstatediagram中的至少一个获取其安全策略的实体信息，并将获取到的实体信息划分为n类，n为不小于2的正整数，实体信息包括安全策略的各进程节点及各进程间的通信信道、通信数据和活动流程中的至少一项实体信息。

可选的，将获取到的实体信息分为进程间通信信道、进程间通信数据、进程间关键活动流程、进程本地数据、进程本地关键活动流程共五类实体信息；采用如下方法获取上述五类实体信息：根据安全策略的umlsequencediagram确定安全策略中的各进程节点、各进程间通信信道、各进程间通信数据和各进程间关键活动流程；根据安全策略中每一个进程节点的umlstatediagram确定每一个进程节点的本地关键活动流程和本地数据。

在一个具体示例中，基于上述图1中所述的安全策略和协议分解器执行如图3所示的步骤获取安全策略中的上述五类实体信息，具体操作如下：

s1：遍历安全策略的统一建模语言时序图中的各进程节点，输出进程列表，记为p；

s2：遍历安全策略的统一建模语言时序图中的进程列表p中各进程之间的通信信道以及信道间传递的信息列表，输出信道列表和信道信息列表，分别记为i和id；

s3：获取安全策略的统一建模语言时序图中的进程列表p中各进程之间的交互活动，遍历所有交互活动之间的组合关系，输出关键活动流程列表，记为ps；

s4:遍历进程列表p中每一个进程的统一建模语言状态图，根据每一个处理活动，提取出其中的本地处理数据，输出本地数据列表，记为ld；

s5：遍历进程列表p中每一个进程的统一建模语言状态图，遍历状态图中活动的所有组合关系，输出本地关键活动流程列表，记为ls。

应理解，umlsequencediagram和umlstatediagram是在软件系统设计过程中，设计人员围绕安全目标设计的安全策略而得到的一种安全策略表现形式。将用于体现安全策略和安全协议对应的umlsequencediagram和umlstatediagram输入安全策略和协议分解器中，输出如下分解结果：进程列表p、进程间信道列表i、进程间信道信息列表id、各进程间的关键活动流程列表ps、进程内的本地数据列表ld和进程内的本地关键活动流程列表ls。

需要说明的是，对于实体信息的分类不仅局限于上述分类方法，也可以是基于umlsequencediagram和umlstatediagram其他分类方法，对此本申请不做任何限制。

202、根据安全属性描述库中的可验证属性类型确定每一类实体信息的可验证属性。

根据安全属性描述库中的可验证属性，针对自然语言描述的安全目标进行细化分层得到每一类实体信息的可验证属性。

具体的，根据上述保密属性secrecy、安全属性safety和活性属性liveness的定义确定安全策略中每一类实体信息的可验证属性。结合上述步骤201中图3对应的示例中，将上述五类实体信息的可验证属性确定为：

1、各进程间通信信道(即进程信道列表i)的可验证属性为：保密属性和安全属性；

2、各进程间通信数据(即进程间信道信息列表id)的可验证属性为：保密属性和安全属性；

3、各进程间关键活动流程(即关键活动流程列表ps)的可验证属性为：活性属性；

4、每一个进程节点的本地关键活动流程(即本地关键活动流程列表ls)的可验证属性类型为：安全属性和活性属性；

5、每一个进程节点的本地数据(即本地数据列表ld)的可验证属性为：保密属性和安全属性。

203、可选的，根据每一类实体信息的实体信息类别，从每一类实体信息的可验证属性的所有逻辑公式中确定数学逻辑公式模板。

遍历每一类实体信息的可验证属性对应的所有数学逻辑公式，进而结合每一类实体信息的实体信息类别将不需要验证的数学逻辑公式筛选出来，并将剩余的数学逻辑公式确定为数学逻辑公式模板。

具体的，例如安全属性、保密属性和活性属性对应的所有数学逻辑公式的数量分别为：6个，8个和10个。对于各进程间通信信道的安全属性只需要验证上述6个数学逻辑公式中的4个，对于其保密属性需要全部验证上述8个逻辑公式，同样，对于各进程间通信数据的安全属性可能只需要验证上述6个数学逻辑公式中的2个，对于其保密属性可能需要验证上述8个逻辑公式中的6个，对于筛序其他三类实体信息的数学逻辑公式模板的方法与上述两类的方法类似，对此此处不再赘述。

204、根据数学逻辑公式模板和每一类实体信息生成每一类实体信息的数学逻辑公式。

将每一类实体信息中的各元素进行组合，带入数学逻辑公式模板中得到每一类实体信息的数学逻辑公式，例如某类实体信息中有5个元素c、d、e、f和g，其可验证属性对应的数学逻辑公式有且仅有1个为：[](a-><>(b)，其中a和b为命题，其他为数理逻辑符号，那么，该类实体信息的数学逻辑公式一共有2⁵-1个，分别为：[](c-><>(d)、[](c-><>(e)、[](c-><>(e)、[](c-><>(f)、[](c-><>(g)等一共31个数学逻辑公式。

205、可选的，根据用户指示对每一类实体信息的数学逻辑公式进行筛选，得到每一类实体信息的待验证数学逻辑公式。

在获取到每一类实体信息的数学逻辑公式之后，向用户询问每个数学逻辑公式是否有意义，若用户指示为无意义，则将无意义的数学逻辑公式删除，若用户指示为有意义，则将其保留，得到待验证的数学逻辑公式。

在一种示例中：

首先将上述步骤201中的分解结果以及自然语言描述的安全目标输入到上述如图1中所示的安全目标分解器中，安全目标分解器按照图4所示的安全目标分解流程对安全目标进行分解构建如图5所示的安全目标分解逻辑树。

如图4所示的操作如下：

s6：以输入的安全目标为根节点，创建安全目标分解逻辑树；

s7：将实体信息从五个维度进行划分得到五个第二层节点，依次为：信道列表i、信道信息列表id、关键活动流程列表ps、本地数据列表ld、本地关键活动流程列表ls；

s8：遍历安全属性描述库中的可验证属性类型，分别确定上述二层节点的可验证属性，创建第三层节点；

s9：针对第三层节点中的可验证属性，遍历可验证属性的所有数学逻辑公式，并结合上述第二层节点中的实体信息类别确定第三层节点对应的数学逻辑公式模板。

需要说明的是，在上述步骤s9中，若第三层节点中某一节点内的元素之间存在包含关系，则重复执行步骤s9，对具有包含关系的每一个元素均创建相应的数学逻辑公式模板；若无包含关系，则结束创建。例如，第三层节点中元素a与元素b之间具有包含关系，则分别创建元素a和元素b对应的数学逻辑公式模板。

其次，将上述图5所示的安全目标分解逻辑树输入至如图1所示的安全属性自动化建模器中，安全属性自动化建模器执行如图6所示的操作对图5中的第四层节点进行刷新，得到待验证数学逻辑公式。

图6中所示的操作如下：

s10：获取上述图5中四层节点中每个节点对应的实体信息；

s11：遍历上述四层节点中的每个节点，将其节点的可验证属性的数学逻辑公式和实体信息进行组合得到所有可能的数学逻辑公式；

s12：若用户指示数学逻辑公式无意义，则删除用户指示为无意义的数学逻辑公式；

s13：若用户指示数学逻辑公式有意义，则保存用户指示为有意义的数学逻辑公式。

206、可选的，根据每一类实体信息的可验证属性，调用形式化验证工具验证对每一类实体信息的待验证数学逻辑公式进行数理逻辑验证，得到验证结果。

调用形式化验证器如proverif，cl-atse工具，对上述步骤205中得到的待验证数学逻辑公式进行形式化验证，若实体信息的可验证属性不满足安全要求，则返回验证结果包括验证反例；若实体信息的可验证属性满足安全要求，则验证通过。

本实施例中，从安全策略的umlsequencediagram和umlstatediagram中获取其安全策略的实体信息即各进程之间的信道、数据和活动流程，并将实体信息划分为n类，最后，基于安全描述库中的可验证属性对每一类实体信息进行进一步分解得到每一类实体信息的数学逻辑公式。可以理解，基于安全属性描述库中的可验证属性对应的数学逻辑公式是经过实际验证得到的，准确性较高，并且基于umlsequencediagram和umlstatediagram对安全策略中的实体信息进行分解，客观性更强和普遍适用性更强。因此，本申请中安全目标分解和建模方法可以使得安全属性的数理逻辑化描述更加准确，适用性更强，以提高安全目标的验证准确性。其次，使用列表的形式输出实体信息，便于检索，提高了安全协议分解的速度。

通过基于安全描述库的安全目标分解器，逐步从抽象的安全目标逐层进行分解形成逻辑树结构，是一种面向协议、系统组成角度进行的分解方法，分析的颗粒度小提升了分析的全面性，可以有效降低验证盲区。下面集合一个具体的应用场景对本申请中的安全目标分解和建模方法进行详细说明，具体如下：

应用场景：

如图7所示为不可信执行环境(richexecutionenvironment，ree)中的客户端应用(clientapplication，ca)与可信执行环境(trustedexecutionenvironment，tee)中的可信应用(trustedapplication，ta)进行交互的信令图，其中，ree环境可为android操作系统，即富操作系统，是一种不可信的，而tee环境为某tee操作系统，是可信的，该ree与tee环境的交互及其接口完全满足国际标准组织(globalplatform，gp)对tee所指定的行业标准。

图7中示出了初始化上下文initializecontext，打开会话opensession，调用命令invokecommand，关闭会话closesession，结束上下文finishcontext等5个主要过程。访问opensession接口的ca大多由第三方开发，运行于非可信执行环境中，因此需要对非可信执行环境中的软件实体的身份进行鉴别，防止恶意软件攻击可信执行环境，从而威胁终端安全。针对该问题，设计了一套安全策略用于防止恶意软件实体访问可信执行环境，即本专利所述的安全设计方案和安全策略的实例，假设其名称为：ta对ca鉴权策略，其目的在于仅允许被内置授权软件实体访问，安全策略所期待满足的安全目标即为：防止恶意软件实体访问可信执行环境，仅允许被内置授权软件实体访问。

如图8所示为ta对ca鉴权策略的会话打开opensession阶段对应的umlsequencediagram图；图9为ta对ca鉴权策略中opensession阶段的检测节点3(checkpoint3)的umlstatediagram图。

结合图1中所述的系统架构，执行如下操作：

s14：调用基于图8所示的umlsequence和图9所示的umlstate图的安全策略和协议分解器，对名称为“ta对ca鉴权策略”的安全设计方案和安全策略进行分解，获取其中包含的实体信息，具体操作流程为上述图3所示的步骤s1至s3，下面以图8和图9所示的操作流程为例对获取“ta对ca鉴权策略”中所有实体信息进行说明；

1、遍历图8中的进程节点，安全策略和协议分解器输出进程列表p，p中包括如下进程节点:客户端应用程序进程(caprocess)，可信执行环境中的客户端应用程序接口(teeclientapi)，安全域驱动(tzdriver)，全局任务进程(globaltask)，可信应用程序进程(taprocess)；

由于上述caprocess和teeclientapi位于同一虚线框内，因此为同一个进程，所以最终列表p为：caprocess，tzdriver，globaltask，taprocess。

2、遍历图8中的各进程间的通信信道，输出信道列表i，和信道间传递的信息列表id，如表1所示：

表1

3、获取图8中的各进程间的交互活动，遍历所有活动间所有组合关系，输出进程间的关键活动流程集合ps，ps列表中包括如下组合时序关系：

(caprocess，通过上下文打开会话opensessionbycontext)，(tzdriver，requestforopensession)，(globaltask，检测节点3checkpoint3)，(globaltask，loadta)，(globaltask，requestforopensession)，(taprocess，加载白名单loadwhitelist)，(taprocess，检测节点4checkpoint4)，(taprocess，opensession)，(taprocess，returnsuccess)，(taprocess，返回会话returnsession)，(globaltask，returnsession)，(tzdriver，returnsession)。

由于上述活动有12项，因此遍历总数量为2¹²-1，由于其中的大量活动都与安全目标没有直接关系，仅仅只是返回会调用操作，因此实际中可以通过用户标识关键活动信息，简化上述遍历数量，例如在用户标注(caprocess，opensessionbycontext)，(globaltask，checkpoint3)，(globaltask，requestforopensession)，(taprocess，checkpoint4)，(taprocess，returnsession)为关键活动的情况下，遍历总数量可以降低到2⁵-1，并生成具有前后关系的时序组合。

4、遍历“ta对ca鉴权策略”安全策略中每一个进程的umlstatediagram图，根据每个处理活动，提取其中的本地数据，进而得到每一个进程的本地数据列表，记为ld；

以图9中globaltask进程节点的opensession阶段的checkpoint3为例，ld包括：ca的签名ca’ssignature，ca代码的散列函数hashofca’scode，会话锁opensessionlocker，session。

5、遍历“ta对ca鉴权策略”安全策略中每一个进程的umlstatediagram图，遍历每个umlstatediagram图中活动间的所有组合关系，输出每个进程的本地关键活动集合，记为ls；

图9中globaltask进程节点的opensession阶段的checkpoint3为例，根据用户标识进行关键活动标记得到ls包括：读取ca的签名readca’ssignature，计算ca代码的散列函数calculatehashofca’scode，获取会话锁acquiretheopensessionlocker，为打开会话，将ca的散列函数值和签名作为特征发送至teesendca’shashvalueandsignatureasparameterstoteeforopeningsession，打开会话锁unlocktheopensessionlocker。

s15：调用基于安全属性描述库的安全目标分解器，以输入的自然语言描述的安全目标为根节点，构建安全目标分解逻辑树，其具体构建步骤如4所示，此处不再赘述；

假设安全属性描述库中活性属性对应的所有数学逻辑公式为：[](a-><>(b)，[]<>(a)，a＝b||c，a＝bc和a＝！a共5个数学逻辑公式，其中，a，b和c为命题，其余符号为数理逻辑符号；以图9所示的进程内关键活动为例，确定其活性属性对应的数学逻辑公式模板为：[](a-><>(b)，[]<>(a)共两个，可以理解，上述两个逻辑公式模板即为图5所示的四层节点中的其中一个节点。

s16：调用安全属性自动化建模器，以步骤s15生成的安全目标分解逻辑树为输入，依据安全目标分解逻辑树的四层节点所包含的实体信息，利用可验证属性构建模板，自动生成与其对应的数学逻辑公式，构建安全目标分解逻辑树的最终四层节点，进而刷新安全目标分解逻辑树，其具体操作详见图6所示的操作，此处不再赘述；

以上述图9所示的进程内关键活动得到的ls，以及步骤s15中确定的数学逻辑公式模板为例对安全目标分解逻辑树的刷新进行详细说明，具体如下：

1、获取步骤s15的节点集合，即为：[](a-><>(b)和[]<>(a)。

2、遍历上述1中所述节点，按照其对应的数学逻辑公式模板和图9所示的进程内关键活动集合ls，组合得到所有可能的数学逻辑公式，具体如下：

图9所示的进程内关键活动集合ls包括如下实体信息：readca’ssignature，calculatehashofca’scode，acquiretheopensessionlocker，sendca’shashvalueandsignatureasparameterstoteeforopeningsession，unlocktheopensessionlocker；

针对[](a-><>(b)数学逻辑公式模板创建：[](readca’ssignature-><>(calculatehashofca’scode)，[](readca’ssignature-><>(acquiretheopensessionlocker)，[](readca’ssignature-><>(sendca’shashvalueandsignatureasparameterstoteeforopeningsession)，[](readca’ssignature-><>(unlocktheopensessionlocker)….等，共2^5-1个数学逻辑公式；

针对[]<>(a)数学逻辑公式模板创建：[]<>(readca’ssignature)，[]<>(calculatehashofca’scode)，[]<>(acquiretheopensessionlocker)，[]<>(sendca’shashvalueandsignatureasparameterstoteeforopeningsession)，[]<>(unlocktheopensessionlocker)共5个数学逻辑公式；

因此，根据上述[](a-><>(b)和[]<>(a)两个数学逻辑公式模板一共得到上述进程内关键活动集合对应的36个数学逻辑公式。

3、针对上述36个数学逻辑公式中的每一个数学逻辑公式，向用户询问其公式是否有意义，并删除用户指示为无意义的数学逻辑公式，保留用户指示为有意义的数学逻辑公式；

通过用户交互，获取到：[](readca’ssignature-><>(sendca’shashvalueandsignatureasparameterstoteeforopeningsession)，[](acquiretheopensessionlocker-><>(unlocktheopensessionlocker)，[]<>(readca’ssignature)，[]<>(acquiretheopensessionlocker)，[]<>(sendca’shashvalueandsignatureasparameterstoteeforopeningsession)和[]<>(unlocktheopensessionlocker)共六个数学逻辑公式，并使用上述6个数学逻辑公式替换原先节点中的36个数学逻辑公式，实现对四层节点的刷新操作。

s17：调用形式化验证器，以刷新后的安全目标分解逻辑树为输入，按照四层节点的可验证属性类别，自动地调用形式化验证工具包、及其对应的安全设计方案和安全策略的形式化模型，来进行自动形式化验证，输出验证结果。

1、获取上述步骤s17中刷新后的节点上的6个数学逻辑公式：[](readca’ssignature-><>(sendca’shashvalueandsignatureasparameterstoteeforopeningsession)，[](acquiretheopensessionlocker-><>(unlocktheopensessionlocker)，[]<>(readca’ssignature)，[]<>(acquiretheopensessionlocker)，[]<>(sendca’shashvalueandsignatureasparameterstoteeforopeningsession)和[]<>(unlocktheopensessionlocker)；

2、按照上述6个数学逻辑公式对应的可验证属性类型，获取对应的攻击模型及安全设计方案的形式化模型，以[](acquiretheopensessionlocker-><>(unlocktheopensessionlocker)的活性属性为例，其为ltl描述的线性时序逻辑属性，需要调用如spin(simplepromelainterpreter)模型检测器来进行形式化验证，若[](acquiretheopensessionlocker-><>(unlocktheopensessionlocker)满足活性属性，则spin工具返回验证通过的验证结果；若不满足活性要求，则spin工具返回的验证结果为验证反例和其溯源路径([](acquiretheopensessionlocker-><>(unlocktheopensessionlocker)的叶子节点->[](a-><>b)->活性->tzdriver进程->进程内关键活动->opensession过程仅允许授权实体访问->安全目标为防止恶意软件实体访问可信执行环境，仅允许被内置授权软件实体访问)。

需要说明的是，“ta对ca鉴权策略”中图5中所示的四层节点中的数学逻辑公式的分解、建模和验证方法与上述应用场景中描述的方法类似，对此此处不再一一赘述。

上述实施例对本申请中的安全目标的分析和建模方法进行了详细说明，下面对本申请中的分析建模设备进行详细说明，具体如下：

如图10所示，本申请实施例中的分析建模设备10，包括：

获取模块1001，用于根据安全策略的统一建模语言时序图和状态图中的至少一个，获取安全策略的n类实体信息，n为不小于2的正整数，实体信息为安全策略的各进程及进程间的信道、数据和活动流程中的至少一项；

确定模块1002，用于根据安全属性描述库中的可验证属性类型确定n类实体信息中每一类实体信息的可验证属性；

生成模块1003，用于根据数学逻辑公式模板和每一类实体信息生成每一类实体信息的数学逻辑公式，数学逻辑公式模板与每一类实体信息的可验证属性对应。

如图11所示，在一种示例中，分析建模设备11还包括：

筛选模块1104，用于根据用户指示对每一类实体信息的数学逻辑公式进行筛选，得到每一类实体信息的待验证数学逻辑公式。

如图11所示，在一种示例中，获取模块1101还用于：

从安全属性描述库中，获取每一类实体信息的可验证属性的所有数学逻辑公式；根据每一类实体信息的实体信息类别，从每一类实体信息的可验证属性的所有数学逻辑公式中确定数学逻辑公式模板。

如图11所示，在一种示例中，n类实体信息包括：进程间通信信道、进程间通信数据、进程间关键活动流程、进程本地数据、进程本地关键活动流程；

获取模块1101具体用于：

根据安全策略的统一建模语言时序图确定安全策略中的各进程节点、各进程间通信信道、各进程通道数据和各进程间关键活动流程；

根据安全策略中每一个进程节点的统一建模语言状态图确定安全策略中的每一个进程节点的本地关键活动流程和本地数据。

如图11所示，在一种示例中，分析建模设备11还包括：

调用模块1105，用于根据每一类实体信息的可验证属性，调用形式化验证工具验证对每一类实体信息的待验证数学逻辑公式进行数理逻辑验证，得到验证结果。

本实施例中，分析建模设备还用于执行上述方法实施例中以及应用场景中的其他相关操作，可参阅上述方法实施例中的相关描述部分，此处不再赘述。

另外，本实施例中的分析建模设备达到的有益效果与上述方法实施例的有益效果一样，此处也不再赘述。

本申请中的分析建模设备可以集成在一个硬件设备中实现，也可以采用分布于多个硬件设备中实现，下面将从上述两个方面：一、集成于整机中实现，二分布于多个硬件设备中实现，对本申请中的分析建模设备的硬件构成进行详细说明：

一、集成于一个硬件实现

如图12所示，分析建模器12包括：输入模块1201、安全策略和协议分解模块1202、安全目标分解模块1203、安全属性自动化建模模块1204、形式化验证模块1205和输出模块1206；

其中，输入模块1201，用于输入安全策略、安全协议或安全设计方案，以及自然语言描述的安全目标；

安全策略和协议分解模块1202、安全目标分解模块1203、安全属性自动化建模模块1204和形式化验证模块1205的功能与上述图2对应的方法实施例中的描述类似，用于执行上述方法实施例中的相关描述执行相关的操作，对此此处不再赘述。

输出模块1206，用于输出验证结果。

本实施例中，分析建模器12中各模块的具体操作以及有益效果可参阅上述图2对应的方法实施例中的相关描述，此处不载再赘述。二、分布于多个硬件设备

如图13所示，分析建模设备包括四个硬件设备，分别为：安全策略和协议分解器13、安全目标分解器14、安全属性自动化建模器15和形式化验证器16，如图所示，四个硬件设备分别通过三个通信接口连接，其中，对于各通信接口的类型及连接方式可以根据实际应用场景进行确定，对此本申请不做任何限定。

同样，其上述四个硬件设备的的功能与上述图2对应的方法实施例中的描述类似，用于执行上述方法实施例中的相关描述执行相关的操作，对此此处不再赘述。

本实施例中，安全策略和协议分解器13、安全目标分解器14、安全属性自动化建模器15和形式化验证器16的具体操作以及有益效果可参阅上述图2对应的方法实施例中的相关描述，此处不载再赘述。

本申请实施例还提供了一种计算机存储介质，用于储存为上述终端所用的计算机软件指令，当其在计算机上运行时，使得计算机可以执行上述分析建模设备所执行的安全目标的分解与建模方法。

本申请实施例还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机可以执行上述分析建模设备所执行的安全目标的分解与建模方法。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

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

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

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read-onlymemory，rom)、随机存取存储器(randomaccessmemory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案范围。