CN109818731A - 一种流式协议强化DSoD策略方法 - Google Patents

Abstract

本发明涉及一种流式协议强化DSoD策略方法，所述方法将策略许可集合转换为属性集合，其中第一步是将策略描述中的许可P转换成属性集合A，从而将DSoD策略请求转换成属性级别的请求，作为流式强化模型的标准输入，第二步是通过一个流式协议对整个属性请求进行判定，从而间接强化DSoD策略集，通过本发明中的方法适用于高保密性的分布式可信计算环境下，从而提升系统的可操作性和通用性。

Description

一种流式协议强化DSoD策略方法

技术领域

本发明涉及网络空间安全领域，具体涉及一种流式协议强化DSoD策略方法。

背景技术

可信计算在整个信息安全领域有着重要地位。来自北欧的永恒之蓝病毒入侵欧洲各国，提醒着锁死文件对操作系统安全的重要影响。DSoD策略模型作为一种普遍存在的策略机制，可以有效的同文件系统可信性相结合，以策略语言的形式保证文件系统的可用性和保密性。对构建高效的可信策略模型，以及在Windows平台下部署我国的可信体系架构，进一步完善涉密机关的安全制度具有重要的理论和现实意义。

发明内容

本发明提出了一种流式协议强化DSoD策略方法，适用于高保密性的分布式可信计算环境下以提升系统的可操作性和通用性。

一种流式协议强化DSoD策略方法，其特征在于，包括：

步骤S1、基于哈希值进行用户身份验证，若验证通过则进入步骤二，否则拒绝策略请求操作；

步骤S2、获取与各线程相对应的协调器的对称密钥；

步骤S3、根据所述对称密钥对策略中的属性进行评估，并返回决策结果。

优选的，所述步骤S1还包括：

S11、对哈希链进行初始化，应用层用户U向协调器C发送自己的ID_U，请求进行实体认证；

S12、协调器C根据所述ID_U，确定该用户记录，找到该用户U当前的随机数N_U，如果N_U为1，则重新进行协调器C和用户U之间的初始化，否则返回该随机数给U，并请求口令输入；

S13、所述应用层用户U对口令PW重复计算N_U-1次，得到并在Windows环境下各主机上安装客户端，获取需要度量的文件信息与系统环境信息，以属性的形式生成DSoD策略集请求INPUT，并将评估请求以及哈希值INPUT发送给协调器C；

S14、协调器C接受应用层发送的请求后，对收到数据的前半部分再进行一次哈希运算，并检查所得到的结果是否与用户U的记录相匹配，如果收到的数据为则能通过检验，并确定对方必定是U，如果检测不通过，拒绝策略请求操作。

优选的，所述步骤S14还包括：

如果通过检验，还需更新保存的口令记录，用原随机数减1的新记录替换原记录

然后为INPUT策略评估请求分配唯一标识符，等待稍后策略决策点W处理每条请求。

优选的，所述步骤S2还包括：

S22、协调器C向可信安全管理中心S以的形式发送安全认证请求M；

S23、可信安全管理中心S针对任务对系统的影响及相关风险进行评估，决定参与到此次策略处理中工作线程Worker；

S24、决策点中的所述工作线程向S发送自己的随机数M；

S25、可信安全管理中心S决定各线程与C交互的对称密钥，并向决策点发送消息以使所述工作线程获得与他们通信的协调器C的对称密钥。

优选的，所述步骤S3还包括：

S31、协调器C收到S发送的消息，解密后获得了与所述各工作线程通信的对称密钥，然后将整个请求发送给策略决策点W，由W利用调度算法协调所述工作线程，使所述工作线程并发工作；

S32、策略决策点W向属性数据库AD发送检索属性的请求M2；

S33、属性数据库AD检索到相关属性，向策略决策点W返回属性值；

S34、策略决策点W评估请求中的策略，并向协调器C发送需要更新的属性，以及需要读取的属性，如果读取的属性没有在评估过程中被更新，把需要更新的属性进一步更新，以确保此次读取的属性是最新值，如果读取的属性在评估过程中已经更新，则将请求的优先级提高，让可信安全管理中心S分配那些任务队列短的Worker，尽快处理该请求；

S35、向应用层返回最终决策结果。

本发明涉及一种流式协议强化DSoD策略方法，所述方法将策略许可集合转换为属性集合，其中第一步是将策略描述中的许可P转换成属性集合A，从而将DSoD策略请求转换成属性级别的请求，作为流式强化模型的标准输入，第二步是通过一个流式协议对整个属性请求进行判定，从而间接强化DSoD策略集，通过本发明中的方法适用于高保密性的分布式可信计算环境下，从而提升系统的可操作性和通用性。

附图说明

下面将结合附图及实施例对本发明作进一步说明，附图中：

图1为本发明实施例一中一种可信策略模型的系统架构图；

图2为本发明实施例三中一种流式协议强化DSoD策略方法流程图。

具体实施方式

现结合附图，对本发明的较佳实施例作详细说明。

以下首先对本发明中涉及到的问题及概念进行说明。

DSoD(Dynamic Seperation of Duty)策略的定义基于以下三条需求：

一.DSoD策略必须是可信计算顶层需求的策略模型。DSoD策略规定一个任务的顶层需求，而不是面向过程的策略。通常，DSoD策略需求的所有条件必须由一组用户完成，而不限制用户需要执行哪些步骤。所以，DSoD策略更接近于某种可信计算体系下的泛型策略语言。

二.DSoD是根据策略允许执行的限制来表达的。比如，动态互斥角色(DMER)约束常用作DSoD的约束，它阻止用户在会话中同时激活互斥角色。

三.DSoD策略必须在任务用户端捕获限制条件。一般来说，用户集合是系统中所有可能存在的用户集合，但在实际条件下，任何实体中的用户数量是有限的。这使得DSoD策略更难以满足给定的访问控制状态。一些特定的方法可以加强DSoD策略的执行，这也是DSoD策略的重要前提。

UCON(Usage Control)作为一种新的访问控制模型，涵盖了如强制访问控制、可自由支配的、基于角色的访问控制等传统访问控制模型。它在SoD策略中应用广泛。UCON系统包括六个部分：主体及其属性，对象及其属性，通用权限，授权，义务和环境条件，其中授权，义务和条件是UCON控制决策的组成部分。授权是基于主体/客体属性推断的，而义务是主体或系统执行的操作，环境条件是Windows系统环境中的限制，UCON最大特点在于决策的连续性与属性的可变性。决策连续性要求策略在主体使用前和运行阶段反复检查与执行，而属性可变性意味着一个或多个主体或客体的属性值可以作为访问控制的结果返回。

Windows平台下DSoD策略形式化描述如下：

dsod{{p₁,p₂...p_m},U,k}每个Pi是一个需要完成的任务，所有Pi属于集合P，U是授权完成任务的用户集合，n是用户的个数，m,n,k是三个整数，2≤k≤min(m,n)，min返回最小值。策略dsod{P,U,k}表示应该存在一组不小于k个来源于用户集合U的用户共同完成请求任务集合P中的任务，显然一个用户可以处理多个允许请求。

UCON_A的结构描述如下：

UCON_A作为UCON的一个子模型只考虑授权过程。权限的结果由主体，客体属性和Windows系统环境属性共同决定的。我们定义UCON结构为包含4个元素的元组(C,P,U,A)C代表已授权的有限策略集，P是可能的许可集合，U是用户集合，A是属性集合。

通常，UCON_A以两种方式影响Windows系统，第一种方式是通过已认证的策略集合C来认证一个许可，使U中的主体对客体拥有特别访问权。第二种方式是C的判断过程通过某些操作改变授权系统的状态，比如：更新属性值，创建一个新的客体等。这些操作可能使原有推断结果发生改变，并引发其他许可以及Windows系统状态的变化。属性赋值用公式：u,a＝v表示，表示域中属性名和值的对应关系，其中v∈dom(a)∪{null},dom(a)是a的属性域，对所有用户的赋值集合共同构成系统的状态。

UCON_A的状态描述ε如下：

我们定义UCON_A的状态ε是一组元素(O,θ)来表示，其中O表示一组客体，而θ表示映射关系O×A→dom(A)∪{null}，此函数为每个主体或客体分配一个真实属性值或者空属性。UCON_A的状态ε＝(O,θ)直接决定了主体的属性，进而影响请求的决定。A表示认证授权过程，ATT(s),ATT(o)表示对于主体和客体授权的推断，有助于最后做出决策。认证授权只使用ATT(s),ATT(o)和许可来决定是否允许或拒绝访问请求。我们使用allowed(u，p)来表示用户u被分配到许可p，正式表述：allowed(u,p)-＞preA(ATT(u),p)。

DSoD策略的安全描述如下：

只要不是所有集合U中的u-1个用户同时拥有P中的许可,我们就认为对于dsod{P,U,k}策略的UCON_A状态ε是安全的，用safe_T(ε)来表示。形式化描述如下：

其中ATT表明u的属性，pre表明UCON_A的提前授权。所有来自用户集合U的用户覆盖完整的属性集合A

T代表了DSoD的策略集，UCON_A的状态用ε表示，整个判断safe_T(ε)是否为真的过程叫做DSoD的安全检查问题(CHECK-DSoD)。如果不是k-1个用户共同持有P中的所有许可，则不会有小于k的用户子集持有所有许可。

如果管理员想要指定一个DSoD策略，他应该首先识别一个任务的影响，然后确定判断此任务合法需要通过P集合中的哪些许可条目，用户集合U的约束集，并确定可完成此任务的最小用户数量k。一个UCON_A的状态ε对于一组DSoD策略集T来说是安全的，我们用safe_T(ε)表示，前提条件是状态ε对于每条DSoD策略t∈T都是安全的。

在系统自我维护方面，CHECK-DSoD(安全检查问题)的是NP完全问题(在某些特殊情况下可能需要指数级的时间复杂度)。

证明如下：考虑CHECK-DSoD的补集，例如：一个访问控制的状态ε和一个DSoD策略t，决定safe_t(ε)是否不为真，也就是用来表示。我们首先来证明是一个NP问题。如果一个访问控制的状态ε对于策略DSoD e＝dsod{{p₁,p₂...p_m},U,k}来说是不安全的，那么必须存在k-1个{u1...un}的用户共同拥有在策略中的m许可。证明上述策略正确可以在多项式的时间内完成，具体过程如下：计算n-1个用户权限许可的并集，并判断策略许可集合P(包含m个p)是否为这个并集的子集，计算safe_t(ε)是否为真，只需要计算每个用户集合U的许可权限并集，并和策略集合比对，时间依旧是多项式级别的，且和k有关(因为k表示U中用户集合的数量)，因此是个NP问题。

我们通过优化的集合覆盖问题来证明该问题是一个NP难题。在集合覆盖问题中，输入一个有限集合S，E＝{S1,S2...Sl}其中Si是S的子集，有一个限定次数N。我们的目标是判定是否存在N个E中的集合，使得他们的并集为S。在运筹学中把这类问题看作是NP完全问题。我们的优化过程如下，通过给定的S，E，N，我们构造如下的DSoD策略，对于每个S中的元素，我们都创建一个许可，令S的大小为m，k＝N+1，我们可以构造如下DSoD策略集：dsod{S,{u₁,u₂...u_n},N+1}并且还要构造UCON_A的状态：对于E中每个S的子集Si(-1<i<l+1)，从用户集ui中创建一个用户使得他们满足Si中的许可。结果当且仅当存在N个E中的元素的并集覆盖了整个S时safe_t(ε)不为真。

实施例一

本实施例公开了一种可信策略模型系统，所述系统在Windows环境下执行，如图1所示，整个Windows环境下的可信计算整体框架包含三个核心层：

最底层需建立可信平台控制模块TPCM，还有通用的硬件和固件，属于可信操作系统的底层支持。

中间层需在Windows平台下建立可信资源收集模块，包含IRP监视器，可信文件系统，以及应用软件。IRP监视器负责收集文件操作，将操作的主体，客体，及操作的内容等信息，包括创建，删除，修改，复制，读写，运行等转换为属性集，发送给策略度量点。

最顶层需要建立可信资源策略模型，该级别包含策略度量点，负责接收来自监控层的属性判定请求，利用属性数据库中存储的信息，获得属性值，评估文件执行的可信性，判断完成后，将结果返回可信软件基。

本实施例中提出了一种可信策略模型系统，通过设置底层、中间层和最顶层三层结构，实现了策略许可集合到属性集合的高效转换，以及完成身份认证并逐步分析属性需求，从而确保了策略决策点和协调器之间的通信可信。

实施例二

前述已证明直接强化DSoD策略是一个NP完全问题，所以直接强化DSoD是困难的，且需要较大成本，针对上述问题，本发明中采用流式强化模型来强化DSoD策略，本实施例中首先对上述采用流式强化模型来强化DSoD的方法进行可行性证明。

DSoD属性的形式化描述及安全符号描述

用符号safe_a(ε)表示UCON_A的状态ε对于属性判定请求asod{{a₁..a_m},{u₁,u₂...u_n},k}是安全的，该命题成立的前提条件为：

如果属性集合A中的每条属性请求都是安全的，则我们就认为UCON_A的状态ε对于集合A是安全的，写作safe_A(ε)。给定UCON_A的状态ε，以及一个属性集合A的请求ASoD，则判定safe_A(ε)是否为真的过程就是ASoD的安全检查问题CHECK-ASoD。

CHECK-ASoD(安全检查问题)的是NP完全问题(在某些特殊情况下可能需要指数级的时间复杂度)。

证明：只要证明每个ASoD请求的属性集合都对应到许可集合上，那么就可以证明ASoD和DSoD的对应关系。

我们在表1中描述了策略集合E转换属性A的算法。

表1属性集合A转换算法

由于要求DSoD策略是强制性的，所以可以保证每个属性有且只能有一个许可与它关联，比如在算法步骤5，假设学校网络安全管理中心的场景，每个属性集合包含有身份，角色，对文件读写执行的分配。可以得出形如：属性集合{{Student，Administrator}{7,5,5}}持有许可P1，属性集合{{Principal，Clerk}{7,6,2}}持有许可P2，当执行到算法步骤6时，假设P3关联了多个属性集合，分别是{{student|maintenance，Staff|NetworkAdministrator}{5,5,5}}，可合并成四组属性集合：{{student，Staff}{5,5,5}}{{maintenance，Staff}{5,5,5}}{{maintenance，Network Administrator}{5,5,5}}{{student，Network Administrator}{5,5,5}}，而如果每条许可Pi关联了ki个属性，则可以根据算法步骤8计算出所有属性集合A。

实施例三

针对直接强化DSoD困难的技术问题，本实施例基于实施例一中的可信策略模型系统提出了一种流式协议强化DSoD策略方法，所述方法的第一步是将策略描述中的许可P转换成属性集合A，这样就可以将DSoD策略请求转换成属性级别的请求，作为流式强化模型的标准输入，第二步是通过一个流式协议对整个属性请求进行判定，从而间接强化DSoD策略集。

本实施例中的方法应用于下述场景下：可信策略中心要向云环境下的不同用户PC端(Windows操作系统)发放策略结果，由于整个任务是基于DSoD策略集的，策略请求之前要核实PC端的身份，使用了基于哈希链的技术进行印证，分析整个请求的过程必然包含请求文件中的部分信息，可信策略中心S认为这些信息是敏感信息，所以必然会进行安全认证。协议需要满足两个约束条件：

约束条件一.Worker A和Worker B必须属于不同的用户。

约束条件二.第三步接受请求和第十六步发送请求必须是由同一协调器完成。

协调器C事先对所有用户进行初始化，发送给所有用户一个口令PW_i,i∈[1,n]，n为用户数量，随后保存每个用户的初始口令记录(ID_i,N_i,Hash^Ni(PW_i)),i∈[1,n]，其中ID_i表示该用户的身份，N_i为较大的随机数(例如3000)，Hash()为哈希函数，次方定义为哈希函数使用的次数，即每个用户只需要记住自己的口令PW_i,i∈[1,n]。当每次用户登录时，协调器都会更新自己保存的该用户的口令记录。

所述流式协议强化DSoD策略方法的流程如图2所示，总共分十六步：

一.哈希链的初始化，应用层用户U(客户端PC)向协调器C发送自己的ID_U，请求进行实体认证。

二.协调器C根据身份信息，确定该用户记录，找到该用户U当前的随机数N_U。如果N_U为1，需要重新进行协调器C和用户U之间的初始化，否则返回该随机数给U，并请求口令输入。

三.U对口令PW重复计算N_U-1次，得到由于采用哈希函数，即使n比较大时计算仍能有效完成。然后在Windows环境下各主机上安装客户端，获取到需要度量的文件信息与系统环境信息，以属性的形式生成DSoD策略集请求INPUT，并将评估请求发送外加哈希值INPUT发送给协调器C。

四.协调器C接受应用层发送的请求后，对收到的数据(前半部分)再做一次哈希运算，并检查所得到的结果是否与用户U的记录相匹配，如果收到的数据为则能通过检验，并确定对方必定是U。如果通过检验，还需更新保存的口令记录，用原随机数减一的新记录替换原记录然后为INPUT策略评估请求分配唯一标识符，等待稍后策略决策点W处理每条请求。如果检测不通过，拒绝策略请求操作。

五.由于请求协议要保证可信性，协调器C必须向可信安全管理中心S发送安全认证请求M，包含C以的形式发送，保证整个请求交互过程是安全的。

六.可信安全管理中心S评估了任务对系统的影响，及相关风险后，决定哪些Worker参与到此次策略处理中，我们假定需要Worker A和Worker B共同完成评估工作，向策略决策点的A,B发送消息M,req通知他们。

七.决策点中的A,B工作线程向S发送自己的随机数

八.可信安全管理中心S决定各线程与C交互的对称密钥，并向策略决策点发如下消息：

这样线程A,B可以获得与他们通信的协调器C的对称密钥。

九.可信安全管理中心S将要参与决策的Worker条目以及对称密钥清单反馈给协调器C消息格式：

十.协调器C收到S发送的消息，解密后获得了与各线程通信的对称密钥K_AC,K_BC，然后将整个请求发送给策略决策点W，由W利用调度算法协调A,B，使他们并发工作，

十一.策略决策点W为了评估策略中的属性，向属性数据库AD发送检索属性的请求M2。

十二.属性数据库AD检索到相关属性，向策略决策点W返回属性值。

十三.策略决策点W评估请求中的策略，并向协调器C发送需要更新的属性，以及需要读取的属性。

十四.如果读取的属性没有在评估过程中被更新，把需要更新的属性进一步更新，并且可以确保此次读取的属性是最新值。

十五.如果读取的属性在评估过程中已经更新，则将请求的优先级提高，让可信安全管理中心S分配那些任务队列短的Worker，尽快处理该请求。

十六.向应用层返回最终决策结果。

由于整个协议的前四步使用了哈希链的思想，可以保证应用层用户U发送给协调器C的值只能使用一次，而且哈希函数是单向的，所以在线窃听者不会从中获得有效信息。同理，即使窃听者获得了协调器C保存的口令表，也无法得到每个用户的具体口令PW。

本实施例中的基于流式DSoD策略强化方法不但考虑了安全需求，还把效率等实际因素考虑进去，避免了直接强化DSoD策略时会遇到的困难性，适用于各种高级安全策略的交互，并且同时可提升系统的可操作性和通用性。

实施例四

本实施例中对实施例三中的一种流式协议强化DSoD策略方法进行安全性证明：

1)协议的形式化描述

M1:C-->S

M2:S-->W M,req(A,B为S下的两个Worker)

M3:W-->S

M4:S-->W

M5:S-->C

2)协议证明的初始化假设

这里我们假设秘钥的有效性，S的可信性以及随机数的新鲜性：

A1：A|≡K_AS A2：B|≡K_BS A3：C|≡K_CS A4：S|≡K_AS

A5：S|≡K_BS A6：S|≡K_CS A7：S|≡K_AC A8：S|≡K_BC

A7：A8：A9:

A10：A11：

A12：A|≡#(N_A)A13：B|≡#(N_B)A14：C|≡#(N_C)A15：A|≡#(K_AC)

A16：C|≡#(K_AC)A12：B|≡#(K_BC)A13：C|≡#(K_BC)

3)协议目标的形式化描述

G1：A|≡K_AC G2：B|≡K_BC G3：C|≡K_BC G4：C|≡K_AC

4)协议的逻辑推理及验证

由M5可知，又由初始化假设A3，应用消息规则R1可得:

再由初始化假设A14，C|≡#(N_B)，C|≡#(N_A)以及应用随机数验证规则R4，可得

C|≡S|≡(N_C,K_AC,N_A),C|≡S|≡(N_C,K_BC,N_B) (2)

应用信仰规则R7，式(2)可得：C|≡S|≡K_AC,C|≡S|≡K_BC (3)

由初始化假设A9，以及式(3)，应用仲裁规则R5，可得：C|≡K_AC,C|≡K_BC (4)

同理，由M4可知，根据初始化假设，依次使用应用消息意义规则R1，随机数验证规则R4，信仰规则R7，应用仲裁规则R5，可得：A|≡K_AC,B|≡K_BC

本实施例用BAN逻辑证明了加强DSoD策略的流式协议是一个安全协议，因此通过实施例三中的安全认证方法，可以确定协调器和策略决策点双方的身份，避免被篡改决策的结果，实现决策点W与协调器C之间的可信通信。

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

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

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

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

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

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

Claims (5)

1.一种流式协议强化DSoD策略方法，其特征在于，包括：

步骤S1、基于哈希值进行用户身份验证，若验证通过则进入步骤二，否则拒绝策略请求操作；

步骤S2、获取与各线程相对应的协调器的对称密钥；

步骤S3、根据所述对称密钥对策略中的属性进行评估，并返回决策结果。

2.根据权利要求1中所述的一种流式协议强化DSoD策略方法，其特征在于，所述步骤S1还包括：

S11、对哈希链进行初始化，应用层用户U向协调器C发送自己的ID_U，请求进行实体认证；

S12、协调器C根据所述ID_U，确定该用户记录，找到该用户U当前的随机数N_U，如果N_U为1，则重新进行协调器C和用户U之间的初始化，否则返回该随机数给U，并请求口令输入；

S13、所述应用层用户U对口令PW重复计算N_U-1次，得到并在Windows环境下各主机上安装客户端，获取需要度量的文件信息与系统环境信息，以属性的形式生成DSoD策略集请求INPUT，并将评估请求以及哈希值发送给协调器C；

S14、协调器C接受应用层发送的请求后，对收到数据的前半部分再进行一次哈希运算，并检查所得到的结果是否与用户U的记录相匹配，如果收到的数据为则能通过检验，并确定对方必定是U，如果检测不通过，拒绝策略请求操作。

3.根据权利要求2中所述的一种流式协议强化DSoD策略方法，其特征在于，所述步骤S14还包括：

如果通过检验，还需更新保存的口令记录，用原随机数减1的新记录替换原记录

然后为INPUT策略评估请求分配唯一标识符，等待稍后策略决策点W处理每条请求。

4.根据权利要求1中所述的一种流式协议强化DSoD策略方法，其特征在于，所述步骤S2还包括：

S22、协调器C向可信安全管理中心S以的形式发送安全认证请求M；

S23、可信安全管理中心S针对任务对系统的影响及相关风险进行评估，决定参与到此次策略处理中工作线程Worker；

S24、决策点中的所述工作线程向S发送自己的随机数M；

S25、可信安全管理中心S决定各线程与C交互的对称密钥，并向决策点发送消息以使所述工作线程获得与他们通信的协调器C的对称密钥。

5.根据权利要求1中所述的一种流式协议强化DSoD策略方法，其特征在于，所述步骤S3还包括：

S31、协调器C收到S发送的消息，解密后获得了与所述各工作线程通信的对称密钥，然后将整个请求发送给策略决策点W，由W利用调度算法协调所述工作线程，使所述工作线程并发工作；

S32、策略决策点W向属性数据库AD发送检索属性的请求M2；

S33、属性数据库AD检索到相关属性，向策略决策点W返回属性值；

S34、策略决策点W评估请求中的策略，并向协调器C发送需要更新的属性，以及需要读取的属性，如果读取的属性没有在评估过程中被更新，把需要更新的属性进一步更新，以确保此次读取的属性是最新值，如果读取的属性在评估过程中已经更新，则将请求的优先级提高，让可信安全管理中心S分配那些任务队列短的Worker，尽快处理该请求；

S35、向应用层返回最终决策结果。