工业控制系统在电网、石油、交通和智能制造等领域得到广泛应用, 已成为国家关键基础设施的重要组成部分. 随着数字经济的发展, 工控领域的安全问题, 如身份认证和数字签名等, 越来越受到关注, 数据安全、工控安全和云安全成为热点话题.

根据国家工业信息安全发展研究中心2020年的公告, 全球发生的因网络攻击导致的严重安全事件高达70多起, 涉及范围广泛, 包括8个主要领域和16个细分领域. 这说明工业控制系统在面对互联网攻击时的脆弱性. 例如, 2010年, 伊朗政府宣布核工厂受到“震网”病毒破坏; 2018年, 加拿大的取水调度系统遭到黑客攻击, 导致取水调度计算机损坏; 2022年4月, 国家工信安全中心发布的《2021–2022年我国网络安全产融合作发展报告》指出, 我国网络安全产业热度持续上升, 出现了128起安全事件, 披露金额达147亿. 这些事件显示了工控安全事件日益严重, 迫切需要安全措施来保护工控系统.

目前, 工控系统中普遍采用口令技术进行操作人员身份认证, 但这种方式安全性有限, 容易受到字典攻击. 另外, 许多工厂采用基于生物特征的认证方式, 如人脸识别和指纹识别, 但这种方式需要昂贵的专业验证设备, 且生物特征容易被仿冒. 此外, 我国大部分工控设备和系统依赖进口, 导致一些存在漏洞的国外工控产品在国内仍在使用, 存在严重的安全隐患. 因此, 工控系统急需一种自主、可靠、高效的身份认证方案.

为了解决身份认证的安全问题, 国内外学者进行了一系列的研究, 但是在实际场景中, 认证系统的中心化以及私钥的私有权问题一直是系统安全的瓶颈^[1], 且目前在工控领域的身份认证安全问题不受重视, 相关方案也比较少.

美国国家标准与技术研究院(NIST)在2000年给出了利用公钥技术实现数字签名和认证的指导意见^[2], 促进了公钥技术在认证方面的应用. Camenisch等^[3]针对身份的匿名认证, 提出了基于双线性对的签名方案. Boneh等^[4]基于前期提出BLS短群签名方案, 可以实现多次的动态认证, 提高了认证的效率. 王中华等^[5]通过无证书公钥密码体制, 实现“口令+秘钥”的双因子认证方案, 但是此方案需要保证认证节点服务器在线, 增加了系统的负担.

Hardjono等^[6]在传统PKI基础上结合零知识证明提出匿名身份认证模型, 有效解决了身份管理机制问题. Ye等^[7]针对工业控制系统网络中数字证书管理和PKI正确部署面临的挑战, 提出PKI部署到工控系统的建议方案. 魏珊珊等^[8]在以PLC为中心的工控系统中给出证书认证模型及PKI部署设计, 并采用引擎机制给出国密算法SM2、SM3扩展到OpenSSL中的关键结构, 提出基于PKI的工控系统身份鉴别方式, 但存在证书中心权利过度集中, 使得整体效率和安全性不高.

MacKenzie等^[9]提出DSA两方签名的方案, 使得两方签名参与者对公钥生成签名, 任何一方都不能单独实现签名. Lindell等^[10]提出基于Paillier同态加密算法的ECDSA方案, 该方案直接利用Paillier算法的同态属性完成双方的签名, 提高了系统在注册阶段的效率. Doerner等^[11]提出基于秘密共享和不经意传输技术的(2, n)-门限ECDSA方案, 不需要Paillier同态加密操作但是引入了不经意传输协议, 使通信开销大大增加. Castagnos等^[12]使用哈希证明技术提出了一种新的ECDSA方案, 但整体运行效率却不高. 王婧等^[13]针对签名私钥易泄露和签名权利过度集中的问题, 通过预计算一次一密的Beaver三元组, 保证2个签名参与方在不重构完整签名私钥的情况下输出合法ECDSA签名, 但是方案依赖于两方的通信, 整体性能受通信效率的影响.

He等^[14]提出针对IEEE P1363标准的两方协同签名方案. 侯红霞等^[15]提出两方协作的SM2签名算法, 该算法将签名私钥拆成两个部分, 分别由两方来保管, 实现了合法的通信双方协作产生SM2签名. Zhang等^[16]提出了SM2签名算法的两方分布式签名协议, 也是将私钥分开存储在两个设备上, 达到了防止秘钥泄露的目的, 但是认证双方之间的频繁通信使得系统的响应时间也明显增加, 系统吞吐量受通信速度的影响较严重.

SM2数字签名算法是国家密码管理局基于椭圆曲线密码体制提出的^[17], 能够满足多种密码应用中的身份认证和数据完整性的安全需求, 与RSA和DSA签名算法相比, SM2算法依赖于求解椭圆曲线上离散对数问题的困难性^[18], 具有更高的安全性和计算效率, 目前已在国内商业密码领域应用多年.

现有的认证体制主要有公开密钥基础设施(PKI)证书认证和椭圆曲线数字签名算法(ECDSA), 但适合工业控制场景的认证体制方案并不多, 随着社会的发展, 这些认证体制已经暴露出严重不足. PKI认证体制需要可信第三方(如认证中心CA)对证书申请、签发、验证、废止、更新等环节巨大计算资源支持, 难以满足高速度、低消耗的需求. 多方协同的ECDSA签名方案虽然解决了签名权利过度集中的问题, 但是依赖于过多的通信开销, 使得整体效率不高.

密码基础逻辑(cryptography fundamental logics, CFL)是由国内学者在2009年提出的一种基于标识的证书认证体制^[19], 王海平等^[20]通过论述得出CFL可以解决的问题领域和场景, 其适用于云计算、大数据、工控系统、免疫计算平台等场景. 刘文婷等^[21]给出了CFL的密钥管理方案, 对CFL认证体制进行了进一步完善, 舒展翔等^[22]给出了CFL在区块链中的具体应用方案, 并通过实验表明系统的正确性和安全性. 王琳等^[23]将CFL认证体制应用在空间卫星认证领域, 在保证安全性的前提下, 将通信效率提升了33%. 但是目前将CFL认证体制应用于工控设备与工控系统与工作人员认证的具体认证方案还没有被提出, 本文基于此进行研究. 相比较于现有的中心化函数认证体制, CFL认证体制的实体身份认证过程无须第三方参与, 具有验证过程去中心化的优势, 因此本文提出了CFL工控系统签名方案来解决上述问题, 实现工控设备之间与工控设备和工作人员之间的高效认证, 主要贡献可以分为以下3个方面.

(1)设计了一种安全高效的CFL工控系统签名方案, 通过计算ID的哈希值生成签名私钥和验证公钥实现验证去中心化和一人一密, 同时能够保护用户的隐私.

(2)提出了设计目标, 并对本文方案进行了安全性分析, 使得本文方案更适合应用于工控系统大规模身份认证的场景.

(3)从理论分析和实验验证两个方面对本文所提方案进行对比分析, 结果表明, 本文方案在提高身份认证系统整体效率方面具有明显优势.

1 工控系统签名认证方案 1.1 工控系统认证架构

系统应用场景为工控设备启动时和员工对设备进行设置时, 认证系统对操作人员进行一次身份验证, 验证通过后在设备正常工作期间不需验证. 工控系统认证结构如图1所示. 下面分别对部署结构中的各组成部分进行简要介绍.

CGC (certificate generation center): 云端的证书生成和注销中心服务器, 负责接收来自注册端的请求并对证书签名, 完成证书的生成和注销.

注册端: 用户使用证书注册设备输入自己的ID和创建证书请求, 把CGC生成的证书存入UKey内^[24].

验证端: 对现场工控设备配备具有USB接口的验证设备, 在设备启动时对操作人员身份合法性进行一次验证, 当且仅当身份验证通过后, 才允许用户对工控设备进行启动和设置.

工控设备: 工业控制系统的现场工作设备, 用户身份信息认证通过后, 接收用户的指令并按照程序进行相应的动作.

1.2 认证方案设计 1.2.1 设计目标

本文提出的CFL工控系统签名方案应满足以下3个属性.

① 验证过程去中心化. CFL证书的注册需要通过CFL-CGC进行签名, 但CFL证书的验证可以在工控系统的其他验证设备上自主进行, 从而减轻了CFL-CGC中心的负担.

② 一人一密. 本方案在CFL-CGC进行注册时, 根据注册用户ID 的哈希值不同, 用不同的标志私钥IDSK对证书进行签名, 相较于证书生成中心所有签名只用一对公、私钥进行签名的方式, 本文方案更加安全.

③ 用户在CFL-CGC进行注册前, 首先使用随机私钥RASK进行签名, 然后与CFL-CGC的签名进行组合. 此外, 随机私钥RASK由用户在本地端自主生成, 一定程度上保护了用户的隐私^[25], 进一步提高了CFL数字签名方案的隐私性和安全性.

1.2.2 CFL-SYS工控系统结构图

CFL-SYS认证体制由CFL-CGC (CFL-certificate generation center), 注册端和验证端组成, CFL工控系统认证模型如图2所示. 系统共有两个阶段组成, 领卡注册阶段和插卡验证阶段. 领卡注册阶段由用户插入UKey输入自己的工号ID, 使用注册端的随机私钥RASK完成签名并创建证书请求发送到云端CFL-CGC服务器, 云端CFL-CGC首先审查用户提交的ID正确性, 然后通过标识私钥IDSK签名得到CFL证书, 再将证书返还到注册端并存入UKey内, 用户则可以拿着UKey到验证设备上进行身份认证^[26]. 员工对工业控制系统现场的生产设备进行启动时和设置时, 将UKey插入验证设备, 按照算法对证书进行各项验证, 并将最终的结果显示出来, 当且仅当全部验证通过后, 现场设备才会允许员工进行下一步的操作. 同时选用了SM2算法^[14]作为CFL数字签名算法的核心签名算法.

1.2.3 注册流程

注册阶段是用户需要对生产设备进行操作之前, 首先到注册端向CFL-CGC创建证书请求, 并将得到的CFL证书存入UKey内, 完成证书的注册, 如图3所示. 其中CFL-CGC会根据用户ID的哈希值选择签名数据库中的标志私钥IDSK对请求完成签名.

步骤1. 用户首先输入自己的工号ID, 然后注册系统会根据用户ID的哈希值h=Hash(ID)生成一组随机公私钥, 用随机私钥RASK对用户ID进行签名得${\mathit{sign}_{ID}} = {\mathit{SIGN}_\mathit{RASK}}\left\{ {ID} \right\}$, 待用户记下随机私钥后, 注册系统将此随机私钥进行删除.

步骤2. 用户创建证书申请${\mathit{CFL}}\_Req=\left\{ {ID\left\| {{\mathit{sign}_{ID}}} \right.} \right\}$, 将其发送到CFL-CGC.

步骤3. CFL-CGC接收CFL_Req并对比证书申请内容中的ID与用户ID数据库, 确保其满足真实性和唯一性, 验证通过后将ID输入Hash函数得h=Hash(ID), 根据h生成一组标志公私钥, 用标志私钥IDSK对证书请求进行签名得${\mathit{sign}_{\mathit{IDSK}}} = {\mathit{SIGN}_{\mathit{IDSK}}}\left\{ {ID\left\| {{\mathit{sign}_{ID}}} \right.} \right\}$, 得到经过CFL-CGC签名得CFL证书.

步骤4. CFL-CGC将CFL证书加入有效时间${T_{val}}$, 打包组成CFL证书$Cer{t_{ID}} = \left\{ {ID\| {sig{n_{ID}}\| {sig{n_{\mathit{IDSK}}}\| {{T_{val}}} } } } \right\}$, 将其发送回用户注册端, 由注册端将CFL证书存入UKey内.

1.2.4 验证流程

验证阶段是用户得到经过注册的UKey后, 到工业控制系统的生产设备上进行操作的身份认证阶段, 如图4所示.

步骤1. 验证端读取CFL证书, 会陆续判断证书ID, 有效时间, CFL-CGC的签名和用户签名的真实性.

步骤2.1. 验证端首先验证CFL证书内员工ID的真实性和唯一性, 只有员工ID正常的前提下才能继续验证.

步骤2.2. 验证端查找CFL证书内是否包含注销标识“REVOKE”, 只有证书未被注销的前提下才能继续验证.

步骤2.3. 计算当前的时间戳${T_{sta}} \leqslant {\mathit{Cert}_{ID}}.{T_{val}}$, 判断时间戳在CFL证书的有效范围之内, 有效时间满足条件后再进行下一步验证.

步骤2.4. 验证端提取$Cer{t_{ID}}.ID$, 计算h=Hash(ID), 根据h生成标志私钥IDSK对应的标志公钥IDPK, 验证 CFL-CGC的签名${\mathit{sign}_\mathit{IDSK}}$.

步骤2.5. 根据h生成随机私钥对应的随机公钥RAPK, 验证用户的签名${\mathit{sign}_{ID}}$.

步骤3. 验证端向用户界面返回本次的验证结果“TRUE/FALSE”, 告知用户本次验证的结果, 整个身份认证全部通过后, 现场设备才允许用户对设备进行设置和操作.

1.2.5 注销流程

注销阶段是向CFL-CGC申请撤销UKey内的合法CFL证书. 注销后的CFL证书将不再具有身份认证的作用, 如图5所示.

步骤1. 用户将UKey插入CFL-CGC证书生成中心, 以RASK为密钥, 对$Cer{t_{ID}}$和注销标识“REVOKE”进行签名得${\mathit{sign}_{\rm REV}}$.

步骤2. 用户向CFL-CGC发送证书注销申请RevReq.

步骤3. CFL-CGC用随机公钥RAPK验证注销签名值${\mathit{sign}_{\rm REV}}$的正确性, 同理按照“插卡验证阶段”的Step 2.3–Step 2.4验证${\mathit{sign}_\mathit{IDSK}}$和${\mathit{sign}_{ID}}$.

步骤 4. CFL-CGC以IDSK为私钥, 对ID和注销标识“REVOKE”进行签名得${\mathit{sign}_{\rm RC}}$, 将注销证书$RevCer{t_{ID}}$发送回用户端.

步骤5. 用户端将UKey内的CFL证书$Cer{t_{ID}}$更新为$RevCer{t_{ID}}$, 完成整个CFL证书注销的过程.

2 方案分析

BAN逻辑为协议的形式化分析提供了一种有效的工具^[27]. BAN逻辑只在抽象层次上讨论认证协议的安全性, 并不考虑由协议的具体实现所带来的安全缺陷和由于加密体制的缺点引发的协议缺陷. 本节对CFL工控系统签名认证方案进行形式化描述, 并对其安全性进行形式化的分析, 即证明在本方案下用户与CFL-CGC证书生成中心和验证设备之间是可互信的.

2.1 用户与CFL-CGC中心的认证属性形式化分析

假设用户A首先向CFL-CGC证书生成中心发出证书申请, 然后CFL-CGC将经过签名的证书返回用户A, 并存入UKey内, 完成CFL证书的注册阶段.

步骤1. 设领卡注册的用户为A, CFL-CGC中心为C.

协议形式化:

$ A \to C:\left\{ {ID, sig{n_{ID}}} \right\} $

(1)

$ C \to A:\left\{ {ID, {\mathit{sign}_{ID}}, {\mathit{sign}_\mathit{IDSK}}, {T_{val}}} \right\} $

(2)

步骤2. 设${I_0} = \left\{ {ID, sig{n_{ID}}} \right\}, {I_1} = \left\{ {{\mathit{sign}_\mathit{IDSK}}, {T_{val}}} \right\}$.

初始假设:

$ A \mid \equiv A \stackrel{I_0}{\rightleftarrows} C $

(3)

$ A \triangleleft\left\{I_0, I_1\right\} $

(4)

$ A \mid \equiv \#\left(I_1\right) $

(5)

$ A \mid \equiv C \Rightarrow I_1 $

(6)

步骤3. 协议目标:

$ A\mid\equiv I_1 $

步骤4. 推理验证:

由初始假设式(3)和式(4)以及公钥消息含义推理可得:

$ \frac{A \mid \equiv C \stackrel{I_0}{\rightleftarrows} A, A \triangleleft\left(I_0, I_1\right)}{A\mid\equiv C\mid \sim\left(I_0, I_1\right)} $

(7)

由初始假设式(5)和消息新鲜性推理规则可得:

$ \frac{A \mid \equiv \#\left(I_1\right)}{A \mid \equiv \#\left(I_0, I_1\right)}$

(8)

由式(7)、式(8)和临时校验规则可推出:

$ \frac{A\mid\equiv C\mid\sim\left(I_0, I_1\right), A \mid\equiv \#\left(I_0, I_1\right)}{A\mid\equiv C\mid\equiv\left(I_0, I_1\right)} $

(9)

由式(9)和信仰规则可推出:

$ \frac{A\mid\equiv C\mid\equiv\left(I_0, I_1\right)}{A\mid\equiv C\mid\equiv I_1} $

(10)

由初始假设条件式(6)与式(10), 根据仲裁规则得:

$ \frac{A\mid\equiv C \Rightarrow I_1, A\mid\equiv C \mid \equiv I_1}{A \mid \equiv I_1} $

(11)

证明结果显示, 协议可达到目标:

$ A \mid\equiv I_1 $

用户A相信从CFL-CGC证书生成中心返回证书的认证属性, 从而信任CFL-CGC的身份.

2.2 用户与验证设备的认证属性形式化分析

用户A将带有CFL-CGC证书的UKey插入验证设备, 由验证设备完成证书的验证后, 才能完成对用户A身份的信任. 设验证设备为B.

步骤1. 协议形式化:

$ A \to B:\left\{ {ID, {\mathit{sign}_{ID}}, sig{n_\mathit{IDSK}}} \right\} $

(12)

$ B \to A:\left\{ \rm{TRUE/FALSE} \right\} $

(13)

步骤2. 初始假设:

$ B \mid \equiv \xrightarrow{IDPK} C $

(14)

$ B \triangleleft\{I D\}_\mathit{IDSK} $

(15)

$ B \mid \equiv C \Rightarrow I D $

(16)

$ B \mid \equiv \#(I D) $

(17)

步骤3. 协议目标:

$ B \mid \equiv \#(I D) $

步骤4. 推理验证:

由初始假设式(14)和式(15), 根据公钥消息含义推理可得:

$ \frac{B \mid\equiv \xrightarrow{IDPK} C, B \triangleleft\{ID\}_\mathit{IDSK}}{B\mid\equiv C\mid\sim I D} $

(18)

由式(18)和初始假设式(17), 根据临时值验证规则可得:

$ \frac{B\mid\equiv C\mid\sim I D, B \mid \equiv \#(I D)}{B\mid\equiv C\mid\equiv I D} $

(19)

由式(19)和初始假设式(16), 根据仲裁规则得:

$ \frac{{B\mid\equiv C\mid\equiv ID, B\mid\equiv C \Rightarrow ID}}{{B\mid\equiv ID}} $

(20)

证明结果显示, 协议可达到目标: $B\mid\equiv ID$.

验证设备B完成对用户A的身份认证, 进而允许用户A对设备的设置及操作. 至此, 应用BAN逻辑分析完用户A对CFL-CGC的认证属性和验证设备B对用户A的认证属性^[28], 本方案实现了安全目标, 用户与验证设备之间实现了安全的认证.

3 实验分析与测试

本节将从理论分析和实验测试2个方面对本文所提方案进行性能评估, 并与PKI^[8]方案, ECDSA^[13]方案进行比较.

3.1 理论分析 3.1.1 通信开销

本节对比本文方案与PKI^[8]方案、ECDSA^[13]方案的通信开销, 由于证书的签名和验证是两个不同时发生的阶段, 因此本文对两个阶段分开讨论. 注册阶段包括用户向CGC证书生成中心发送身份信息和请求, CGC为用户端返回签名的证书; 验证阶段包括用户向验证端提供证书和验证端给用户返回验证结果^[28]. 假设RC表示用户端与CGC间1次通信, RV表示用户端与验证端1次通信, 表1为3种方案的通信开销对比.

由表1可知, 在注册阶段, PKI方案与本文提出的CFL方案都有2次RC通信, ECDSA方案有4次RC通信. 在验证阶段, PKI方案除了2次RV通信, 还有2次RC通信, ECDSA方案包括了4次RV通信, CFL方案有2次RV通信. 在实际应用场景中,

一个用户在证书有效期内只会进行一次注册和无数次验证, 因此验证阶段的通信开销对证书生命周期的总开销来说是决定性的, 由表1可知, CFL方案的通信开销比另外两种方案都具有优势.

3.1.2 计算开销

通过统计协议执行过程中使用的密码运算操作个数, 对PKI方案、ECDSA方案和本文CFL方案的计算开销进行了理论分析与比较. 定义H为哈希运算, PM为椭圆曲线点乘法运算, PA为椭圆曲线点加法运算, RNG为随机数产生. Kilinc等^[29]基于PBC库计算得出不同密码运算的平均耗时: H约为0.0023 ms, PM约为2.226 ms, PA约为0.0288 ms, RNG约为0.539 ms.

对比方案中的哈希运算H的总个数是在安全参数256的情况下进行统计的, 其中, ECDSA方案中的U1和U2分别等价为证书生成中心和注册用户, 具体比较如表2所示.

由表2可知, 在注册阶段, CFL方案算法由于涉及2次签名, 计算开销是PKI方案的2倍多; 对比ECDSA方案, CFL方案减少了3次哈希运算, 7次随机数运算, 增加了1次PM运算和3次PA运算. 在验证阶段, CFL方案对比PKI方案略有增加, ECDSA方案最慢.

3.2 实验分析 3.2.1 工控系统仿真

温湿度是工业生产过程中一个重要的被控参数. 本文以环境温湿度监控系统作为工业控制系统仿真场景, 通过LabVIEW仿真平台实现. 平台使用Proteus进行电路仿真, 以STC89C52单片机作为主控制器, LCD1602显示温湿度, 温湿度传感器采用DHT22, 外接除湿器和风扇进行温湿度控制. 硬件设计及上位机软件设计如图6和图7所示.

3.2.2 抗攻击测试实验

为了测试对比本方案防御DoS攻击的能力, 需要在实现的原型系统上进行UDP-Flood攻击实验, 攻击者通过恶意向目标工控设备发起认证响应请求, 并随机化源IP地址, 来消耗工控设备以及CFL_CGC的计算资源, 使其瘫痪. 测试工具采用hping3, 分别对3种方案进行测试, 输出数据包响应时间, 然后统计出平均响应时间, 传输的数据包为CFL证书. 实验环境配置如表3所示.

在DoS攻击实验中, 各主机都处在同一个局域网中, 使用交换机相连, 攻击方式采用UDP-Flood方式, 实验测试了3种方案原型系统在不同UDP-Flood攻击速率下平均的请求认证服务响应时间以及各攻击速率下的系统可用性, 实验数据所绘折线图如图8所示.

实验结果表明, 本文方案的抗攻击特性优于其他两种方案, 且在攻击速率达到400 Mb/s时, ECDSA方案出现了20%请求无法获得正确回应的情况. 本文方案最优的原因主要是, 只需要对证书进行验证即可, 即去中心认证, 所以大大减少了计算资源的消耗, 可以有效防御DoS攻击.

3.2.3 性能测试实验

在实验测试中, 本文以NIST标准化的secp256k1椭圆曲线为基准, 安全参数$ \lambda=256 $, 杂凑函数采用SM3, 签名和验证函数采用SM2. 测试程序基于开源密码学库Bouncy Castle实现椭圆曲线上的计算, 使用Java语言编写, 基于PC端开发, 主要运行环境如表4所示.

数据库: MySQL

操作系统: Windows 7 旗舰版

UKey: Kingston DT100G3 (32 GB)

在不考虑网络延时的情况下, 我们分别测试3种方案在注册阶段和验证阶段的工作性能.

使用压力测试工具Apache JMeter在仿真工控系统注册和验证的场景下测试执行事务的效率, 其中设置种子秘钥长度为128, 每一组数据均取20轮实验的平均值, 图9为系统注册吞吐量对比图, 图10为系统验证吞吐量对比变化图. 在证书注册阶段, 3种方案的证书生成中心都部署在云服务器上, 通过图9可知, 随着注册用户个数的增加, PKI和CFL方案的系统吞吐量变化并没有发生太大的波动, ECDSA方案吞吐量随着注册用户量的增加而缓慢增加, PKI方案与CFL方案几乎保持持平, 都高于ECDSA方案的吞吐量. 图10为证书验证阶段系统的吞吐量, 在验证用户个数为100个/s时, CFL方案的系统吞吐量比PKI方案提高了676.62%, 在用户数为400个/s时, CFL方案的系统吞吐量比ECDSA方案也有大幅提高, 且在其他验证用户个数的情况下, 也明显高于另外两种方案, 体现出CFL方案在验证阶段吞吐量方面的优越性. 具体系统响应时间如图11和图12所示. 通过对比图11注册阶段3种方案的系统响应时间可知, ECDSA方案随着注册用户数的增加系统响应时间增速最快, 并且都高于CFL方案和PKI方案, CFL方案的响应时间略高于PKI方案. ECDSA方案与PKI方案的系统响应时间都不断增加, CFL方案系统响应时间增速和总时间都明显低于另外两种方案的时间, 并且可看出CFL方案系统验证响应时间能够满足毫秒级应用. 在工控系统身份认证现实场景中, 用户一般完成一次注册后会进行多次的验证, 即系统验证阶段的性能才能决定整体性能的好坏. 通过本文的实验测试结果可知, 当证书中心的注册系统和验证系统分开后, 本文所提的CFL工控系统认证方案因为在验证阶段系统整体性能吞吐量大, 响应时间短, 提高了系统处理事务的效率, 更适合工控系统的大规模身份认证.

4 结论

工业控制系统身份认证的安全性和工作效率日益受到国际社会的关注, 针对当前身份认证系统中心化程度过高以及用户对私钥私有权的强烈需求. 本文利用国内学者提出的CFL认证体制提出了基于CFL的工控系统签名方案, 并建立了工控系统认证模型CFL-SYS. 同时引入UKey作为证书的载体, 通过计算ID的哈希值生成验证公钥, 实现了验证阶段的去中心化, 减轻了证书中心的压力, 提高了系统吞吐量, 降低了系统响应时间. 然后使用BAN逻辑分析证明本文方案的安全性和可行性, 最后通过对比实验测试表明, 本文方案在性能方面相比PKI方案, ECDSA方案具有优势, 能够为大规模的工业控制系统提供一种自主、可靠、高效的身份认证.