2017, Vol. 49引用本文 |
2. 可信计算北京市重点实验室, 北京 100124;
3. 信息安全等级保护关键技术国家工程实验室, 北京 100124
2. Beijing Key Lab. of Trusted Computing, Beijing 100124, China;
3. National Eng. Lab. for Critical Technologies of Info. Security Classified Protection, Beijing 100124, China
TCP/IP技术在ICS中的广泛应用使远程监控ICS现场设备的需求得到满足，但也为原本封闭的私有ICS协议引入了更多安全风险。Modbus/TCP协议[1]是一种使用广泛的主流现场总线协议Modbus的扩展协议。由于Modbus/TCP协议设计时并没有考虑安全性，一旦攻击者通过TCP/IP网络进入ICS内部的Modbus/TCP网络，就可以通过冒充或篡改Modbus/TCP客户机和服务器、窃听本地网络通信等方式获取ICS中的敏感操作和数据信息[2-3]。因此，必须研究如何改进Modbus/TCP协议，从通信方认证角度入手保护ICS网络通信安全[4]。
Modbus/TCP采取C/S通信模式，每次通信由Modbus/TCP客户机发起请求，Modbus/TCP服务器响应。Modbus/TCP客户机可以是ICS中的控制服务器等监控服务器，Modbus/TCP服务器可以是ICS中的现场控制设备，如可编程逻辑控制器(programmable logic controller，PLC)等。安全Modbus/TCP协议的实现途径可以是改造控制服务器、服务器和现场PLC之间的网关通信协议栈[5]，也可以是改造控制服务器和现场PLC上的通信协议栈[6]。第1种方法提出的改进协议运行在Modbus/TCP客户机和网关之间，能够为两者通信提供安全保障。但由于网关和Modbus/TCP服务器间的通信还是原始的Modbus/TCP协议或直接采用Modbus现场总线协议，现场控制设备(如PLC)与网关之间的通信安全仍然无法得到保护。第2种方法提出的改进协议运行在Modbus/TCP客户机和服务器之间。Hayes等[6]采用SCTP协议，通过在原始Modbus/ TCP协议处理单元(protocol data unit，PDU)上增加的哈希消息认证码(Hash-based message authentication codes，HMAC)字段保证通信双方身份可认证性和通信数据完整性。但HMAC密钥需要预先共享，一旦被攻击者获取，认证性就无从保证。另外，由于SCTP协议至今未得到广泛使用，该方案的推广仍存在一定问题。
此外，上述单纯通过改进Modbus/TCP协议进行ICS通信保护的方法对攻击者冒充和篡改Modbus/TCP服务器和客户机的安全风险仍然无法防范[7]。Papa等[8]介绍了可信锚点(trust anchor)的逻辑概念，提出4种在ICS嵌入式设备中设计可信锚点，从而保护嵌入式设备的方法，但没有涉及工业控制服务器及协议安全。可信计算组织(Trusted Computing Group，TCG)将可信计算概念[9]引入ICS，提出可以在ICS互联设备中使用可信平台模块(trusted platform module，TPM)内置密钥进行HTTPS/TLS或隧道通信，从而保障不同的现场网络远程安全互连[10]，但对本地现场设备、控制设备之间的安全通信问题未加以考虑。Knowles等[2]提出可以利用专用设备(如TPM)或者参照通用评估准则定义的系统保护框架(system protection profile，SPP)获取终端设备状态信息，用于安全评估；Wang等[11]提出可以通过可信计算平台加密保护现场设备数据、评估终端网络设备可信状态，但以上文献都未针对ICS通信协议安全给出具体方法。目前还没有其他公开文献研究将可信组件引入到Modbus/TCP协议中以保证现场设备通信安全。
本文提出的可信Modbus/TCP协议采用同时改造控制设备与现场设备原有的Modbus/TCP通信协议栈的方式，避免了仅修改控制设备和网关导致的只能单方认证的问题；在ICS网络中引入可信硬件，采用远程证明方法对Modbus/TCP客户机、服务器的身份和安全状态进行双重认证，不仅解决了Modbus/TCP网络敏感操作数据易被攻击者窃取和篡改的问题，还解决了因合法通信实体系统被篡改导致安全认证信息、ICS敏感信息等数据泄露，从而危害ICS安全通信的问题。
1 威胁模型及可信Modbus/TCP协议设计安全需求ICS主要分为监控与数据采集系统(supervisory control and data acquisition，SCADA)和集散控制系统(distributed control systems，DCS)两类。典型的SCADA由包括控制服务器(control server，CS)、人机交互界面(human machine interface，HMI)工作站等过程控制和监控设备的控制网以及包括PLC等现场控制设备的现场网组成。其中：控制网可以有多个，通过以太网甚至互联网连接；现场网可以通过Modbus/TCP或Modbus现场总线协议连接。本文以SCADA系统为例，讨论ICS中采用Modbus/TCP协议的网络所面临的安全通信威胁。
由于Modbus/TCP协议采用C/S方式通信，CS、HMI作为Modbus/TCP客户机，使用组态软件(industrial control configuration software，ICCS)与作为Modbus/TCP服务器的PLC通信，PLC程序(PLC program)采集现场数据后回传给CS和HMI。
图 1为包含威胁攻击点的SCADA系统Modbus/TCP网络安全通信威胁模型，灰色方框表示威胁点。为了简化叙述，图 1及后文以CS为Modbus/TCP客户机代表进行描述，包含“恶意”标记的设备为冒充设备。
 |
| 图1 SCADA系统安全通信威胁模型 Fig. 1 Threat model of SCADA for secure communication |
如图 1所示，威胁攻击点包括ICS中的ICCS漏洞、CS冒充者、PLC冒充者、PLC程序4个部分。根据Dolev-Yao敌手模型可知，攻击者可以任意窃听、重放、篡改、构建Modbus/TCP网络的任意报文。结合攻击者能力和Modbus/TCP网络通信安全威胁点可以得出相应攻击方式如下:
1)基于CS冒充者的威胁攻击
由于Modbus/TCP协议自身没有身份认证机制，PLC无法分辨恶意CS。冒充者可以通过窃听网络通信流量，获取PLC通信地址后构造Modbus/TCP请求报文，向PLC发送恶意命令获取现场设备敏感信息或引发故障。因为冒充者没有预先共享的密钥信息，基于通信双方CS和PLC身份认证的Modbus/TCP安全增强协议[4-6]可以防范此类攻击。
2)基于CS上的ICCS漏洞威胁攻击
攻击者能利用CS中ICCS漏洞控制CS向PLC发送恶意命令，获取本机和现场设备敏感信息或引发故障，还可以篡改PLC的应答报文使得CS用户无法发现攻击[2]。如果攻击者通过被控制的CS获取了预设密钥，基于通信双方身份认证的Modbus/TCP安全增强协议[4, 6]将无法防范此类攻击。
3)基于PLC冒充者的威胁攻击
由于Modbus/TCP协议自身没有身份认证机制，CS无法分辨恶意PLC。冒充者可以通过窃听网络通信流量，获取PLC通信地址后构造Modbus/TCP应答报文，冒充正常工作的PLC发送虚假数据给CS，引发故障。基于CS和网关认证的Modbus/TCP安全增强协议[5]无法识别恶意PLC，因此也无法防范此类攻击。因为冒充者没有预先共享的密钥信息，基于通信双方身份认证的Modbus/TCP安全增强协议[4, 6]可以防范此类攻击。
4)基于PLC Program的威胁攻击
由于现场PLC通常没有口令保护或者采用弱口令保护机制，攻击者可以直接或通过破解口令等方式将恶意PLC程序下载到PLC中，覆盖原PLC程序，从而使得PLC运行恶意程序，获取敏感信息或引发故障，进而达到攻击目的。如果攻击者通过被控制的PLC获取了预先共享的密钥信息，基于通信双方身份认证的Modbus/TCP安全增强协议[4, 6]将无法防范此类攻击。
对应上述威胁模型可将攻击者攻击类型分为窃听敏感数据、篡改协议数据、冒充通信方、拒绝服务攻击4种。除抵抗上述4种攻击外，在进行可信Modbus/TCP协议设计时还应考虑抵抗重放协议数据攻击，以免协议状态被重置为非法状态泄露敏感信息。
由此可归纳可信Modbus/TCP协议设计安全需求为完整性、可认证性、新鲜性和机密性。具体而言：1)完整性用于保证协议信息在传输过程中不被篡改。2)可认证性用于验证通信双方设备身份和系统状态。其中，验证系统状态是为了防止合法通信设备遭到攻击后被利用、实施预期之外的恶意行为(例如，震网病毒通过0-day漏洞篡改组态软件库，向PLC发出恶意指令)。3)新鲜性用于保证协议数据(如随机数)每次使用时更新，防止重放攻击。4)机密性用于加密保护关键的操作命令内容，保证攻击者即使窃听到也无法理解通信内容。
前3点安全需求是可信Modbus/TCP协议设计的基本要求，由于提供机密性会增加性能开销，因此机密性只作为附加安全需求，在安全要求较高的情况下使用。
2 可信Modbus/TCP协议设计 2.1 协议基本要素可信计算[9, 12]通过设备BIOS中的可信度量根(core root of trust for measurement, CRTM)和TPM度量设备软硬件，度量结果以不可篡改的方式存储在TPM内部的平台配置寄存器(platform configuration register，PCR)中，供用户远程验证，从而保障设备软硬件系统行为符合预期。
每个终端设备初始化时都将用TPM创建包含一对公私密钥的身份证明密钥(attestation identity key，AIK)，代表设备身份。由于AIK的私钥不能离开设备TPM，通过验证AIK签名可保证设备身份的真实性。
TPM还能加密保护用户创建的密钥，由于解密过程总是在TPM内部进行，可以保证解密过程不泄露私钥。绑定密钥BindKey是TPM用于加解密小规模数据(如密钥)的一对公私密钥对，被加密数据必须在拥有BindKey私钥的设备(TPM)上才能解密。
本文提出的可信Modbus/TCP协议包括认证子协议、通信子协议和更新验证子协议3个部分，假设CS、AS以及PLC均基于TPM硬件实现了上述可信功能。所有以TPM_开头的命令都在TPM硬件芯片中完成，所有以TSS_开头的命令直接由TPM功能调用软件库完成。增加在线的证明服务器(attestation server，AS)为CS和PLC提供身份和安全状态信息的周期性验证与更新。
协议运行前，通信参与者已具备的知识如下：
1) AS已知SCADA系统中所有终端设备的预期可信信息，即可信白名单。AS使用签名私钥Ks_Pri对需要验证的预期可信信息签名后，发送给验证方。
2) CS、PLC已知AS的签名密钥公钥Ks_Pub，用于验证AS发送的白名单相关信息。
3) PLC已知CS的白名单信息。该信息在SCADA系统初始化和每次CS信息发生变动时，由AS通过签名私钥Ks_Pri签名后推送给PLC。该方式能减少PLC和CS的认证交互，提高通信效率。
2.2 认证子协议认证子协议的功能是在CS和PLC通信之前，由通信双方相互认证对方身份和系统状态是否可信。
图 2为认证子协议流程，如图 2所示，A为Modbus通信中的客户机(CS)，B为服务器(PLC)。注意B作为Modbus/TCP服务器无法发起请求询问AS的CS状态信息，也无法主动向A发起Modbus/TCP请求，因此所有通信必须由A发起。
 |
| 图2 认证子协议 Fig. 2 Authentication sub-protocol |
具体协议步骤如下：
步骤1~9描述了A和B在AS的参与下，通过向对方发送设备状态信息(PCR值)的AIK签名，完成双方身份和状态的双向认证过程。其中，使用了TPM_Quote和TPM_Sign命令分别进行对PCR的签名和对协议数据的签名。
步骤9~15描述了认证成功后，客户机A生成第2个子协议(通信子协议)所需要的对称密钥Kms和Ke。其中:Kms用于通信子协议中的HMAC计算，保障通信数据的完整性；Ke用于高安全级别通信所需的操作数据对称加密。使用TPM_UnBind命令保证拥有绑定密钥私钥的设备(TPM)才能解密对称密钥Kms和Ke。
2.3 通信子协议认证通过后，通信双方将利用上述认证子协议中生成的密钥Kms和Hash算法字段指定的Hash算法协议数据进行HMAC运算，保证通信过程中数据的完整性和双方身份的可认证性。当安全字段为2时，Modbus/TCP将使用Ke进行协议数据加密传输，保证关键报文信息的机密性。该子协议较为简单，限于篇幅不再给出具体流程描述。
2.4 验证与更新子协议AS使用验证子协议通过周期性质询CS和PLC的PCR，通过对比白名单信息发现是否出现非预期的设备状态变化，从而保证SCADA系统的终端设备在运行过程中没有被篡改。此过程与认证子协议中的认证过程步骤8~10(图 2)类似，因此不再重复描述。
根据验证结果是成功或失败，AS将决定是否进行ICS设备状态更新：1)如果验证成功，AS不做任何操作；2)如果验证失败，或者若SCADA管理员通过安全进程在可信服务器AS上更新了某实体在白名单上的信息，则由AS发起更新流程。
根据更新实体设备类型不同，AS将进行不同操作：1)若更新实体的设备类型为Modbus/TCP客户机，并且实体名称为CS或HMI，则AS通过将实体新的白名单信息签名后推送到Modbus/TCP网络所有服务器(如PLC)中完成更新；2)若更新实体的设备类型为Modbus/TCP网络服务器(如PLC)，则AS通过TCP/IP网络向CS或HMI广播更新实体状态信息改变的消息。接收到AS发起更新通知后，CS或HMI将之前在通信子协议中协商的相关对称密钥Kms和Ke设置为无效，重新发起认证子协议。
3 可信Modbus/TCP协议实现首先，基于包括可信硬件芯片及相关软件在内的可信组件实现可信Modbus/TCP协议。如图 3所示，在现有Modbus/TCP网络的客户机和服务器端分别进行3处修改(详见虚线框内灰色框图部分)：1)在传统C/S客户机(即CS)增加TPM、协议处理模块(protocol processing module，PPM)和TPM功能调用软件库(TSSlib)。其中：TPM用于提供可信密码相关功能；PPM用于提供本文提出的可信Modbus/TCP协议封装解封功能，取代原协议栈。2)在客户机端增加在线的AS，为CS和PLC提供身份和安全状态信息周期性集中验证与更新，减轻两者相互认证的负担。AS与CS之间通信仍然通过传统TCP/IP网络进行。3)在C/S服务器(即PLC)上增加TPM、PPM以及TPM功能调用软件库(TSSlib)。
 |
| 图3 基于TPM的可信Modbus/TCP协议实现 Fig. 3 Implementation of trusted Modbus/TCP protocol based on TPM |
另外，作者通过增加可信白名单和修改Modbus/TCP协议PDU实现可信Modbus/TCP协议。
1)可信白名单
AS中维护了一张保存所有设备信息的可信白名单，以便对通信双方的身份和状态可信性进行验证，其格式如图 4所示。其中：Name为设备名称；IP为设备IP地址；Type标记设备是客户机还是服务器；AIK_pub代表设备的AIK公钥；SIGK_pub代表设备的签名公钥；BINDK_pub代表设备用于加密客户机和服务器协商的对称通信密钥的绑定密钥公钥；PCRs用来验证通信设备的状态是否可信，PCRs值对应的度量对象包括Modbus/TCP客户机和服务器的操作系统OS内核模块及工控组态软件。白名单的更新由ICS管理员授权，通过特定程序实现。
 |
| 图4 可信白名单数据格式 Fig. 4 Data format of trusted whitelist |
2)可信Modbus/TCP PDU
可信Modbus/TCP协议PDU数据格式如图 5所示，使用HMAC保护协议数据完整性和来源真实性，根据操作码的安全级别保护高安全级别操作数据。
 |
| 图5 可信Modbus/TCP PDU数据格式 Fig. 5 Data format of trusted Modbus/TCP PDU |
图 5中：Hash Algorithm为1个字节，由报文发送端根据设备计算能力选择Hash算法。Hash Item因选择的Hash算法不同而长度不同，Hash Item=HMAC (Kms, Modbus/TCP PDU)，Kms由CS维护，在身份认证过程中生成。Security Level为1个字节。本文对Modbus/TCP功能码进行了读和写两级分类，因此取值范围为1或2，也可根据系统需求自定义相应功能码级别。Encryption Algorithm为1个字节，是可选项，仅在Security Level字段为2时，由通信双方根据需要选择。若Security Level字段为1，Data为明文；否则，Data为原始Modbus/TCP PDU加密后的数据。
4 安全性及性能分析 4.1 安全性分析采用基于角色的形式化协议语言HLPSL描述可信Modbus/TCP协议，然后使用SPAN工具验证协议的安全性。SPAN工具能对HLPSL语言描述的协议功能和入侵者行为进行模拟，如果协议是不安全的，点击攻击模拟按钮会得到攻击路径。
以认证子协议为例，需用HLPSL语言描述参加协议的3个角色(客户机、服务器和AS)过程和混合角色过程。其中，角色过程定义了其代表的实体变量及接收和响应消息的通信过程，混合角色过程定义了协议变量、攻击者知识和协议检验目标。
本文使用alice表示Modbus/TCP客户机即图 2中的实体A, 使用bob代表Modbus服务器即图 2中的实体B，使用server代表AS即图 2中的实体S。由于alice状态最丰富，图 6(a)以alice角色为例说明实体A的通信过程。图 6(b)为攻击者知识。包括协议过程中的实体(即a、b和s)及明文信息，其中，明文信息指密码算法(h)和用到的公钥(即Ka、Kb、Ks和Ki)。图 6(c)为协议检验目标。认证子协议的安全目标是保证后续将在通信子协议中用到的HMAC密钥和加密密钥的机密性(即k1和k2的机密性)、PCR (即pra和prb)以及协议过程中使用的所有随机数(如na等)具有强认证性(即真实性和防止重放攻击的新鲜性)。
 |
| 图6 认证子协议的HLPSL语言描述 Fig. 6 HLPSL description of the authentication sub-protocol |
SPAN给出的认证子协议的消息序列图从入侵者角度分析子协议安全性，结果未能形成入侵路径。虽然攻击者具有获取Modbus/TCP网络中传递的明文消息(如随机数、PCR等)的能力，但无法获得AIK和签名密钥，因而无法伪造篡改PCR和随机数签名；同时攻击者也无法获取TPM绑定密钥，因而无法解密对称密钥Kms和Ke。
如图 7所示，认证子协议的SPAN验证结果为安全的(SAFE)，这与用SPAN的OFMC端进行协议安全性分析得到的结果是一致的，表示该子协议能够达到安全认证A和B的身份和状态信息，并且能安全交换后续通信将使用的对称密钥Kms和Ke。
 |
| 图7 认证子协议的SPAN验证结果 Fig. 7 SPAN results of the authentication sub-protocol |
通信子协议的安全目标是A和B (CS和PLC)双方能保证交换的协议数据机密性(高安全等级情况下)和完整性，使用的随机数具有强认证性；验证与更新子协议的目标与认证子协议类似，是保证ICS运行期间CS和PLC的PCR具有强认证性(不可伪造篡改)。上述子协议的描述方式和验证过程类似，SPAN验证结果也是安全的(SAFE)，不再赘述。
综上所述，本文提出的可信Modbus/TCP协议能够保证工控网络通信双方的身份和系统状态可认证性、协议数据完整性、随机数新鲜性，在高安全等级要求下满足协议数据机密性，能够满足第1节提出的协议设计安全需求。
4.2 性能分析与原有协议相比，本文提出的可信Modbus/TCP协议的性能消耗包括增加加解密、签名验签等关键安全功能的时间开销以及增加协议数据包字段造成的通信时间开销。
安全功能通过为Modbus/TCP客户机、服务器增加专用可信硬件及软件库实现。主要包括2个部分：1)基于TPM硬件的Bind/Unbind加/解密功能和Quote/Sign/VerifySignature签名及验证签名功能，2)软件实现的对称加解密和HMAC计算功能。本文针对时间开销较大的TPM功能相关操作进行了测试，使用Atmel TPM的2 048位RSA密钥对160位随机数进行加解密和签名验签测试。表 1给出了3个子协议的使用频率及上述关键操作的时间开销。
| 表1 子协议关键安全功能使用频率及时间开销 Tab. 1 Frequency and time costs of key operations of the sub-protocols |
 |
由表 1所示：认证子协议开销为7.194 s，时间较长，但此协议仅在设备状态信息发生改变时(如第1次通信前初始化、验证出现失败后)才发起。分3种情况讨论：1)在正常的情况下，通信双方在成功认证一次之后就不需再次认证了，所以对实际业务操作性能影响仅是一次性的。2)在因合法设备系统遭到篡改导致AS验证失败后，合法服务器或客户机将在收到AS更新信息后终止之前建立的双向通信，直到新的认证子协议成功为止。因为如果验证失败，表示设备可能遭到恶意篡改，相较于安全性的提升，该性能影响是可以忽略的。3)在有攻击者冒充合法客户机或服务器设备的情况下，因为攻击者无法通过AS的周期性验证，合法服务器或客户机将在收到AS更新的AIK信息后将拒绝响应或连接攻击者。在这2种情况下，认证子协议不会使用，也不产生开销。
通信子协议没有TPM功能相关时间开销，因为认证成功后如果双方身份和系统状态没有变化，将不需要额外调用可信硬件的安全功能。
验证子协议开销为1.866 s，但验证频率可根据系统业务负荷变动。选择空闲时段验证可较好地避免性能影响；更新用于在验证失败或系统升级后，为服务器发送新的客户机验证值(1.793 s)，客户机不需要通过Modbus/TCP网络更新，因此验证更新子协议对通信性能影响较小。
以上数据都在通用可信硬件(即TPM芯片)上测试获得，针对ICS环境采用速度更快的专用硬件，如SM2加密芯片，加密256位数据耗时约为本测试加密160位数据的0.4倍[13]，可见采用专用芯片后安全功能时间开销将会大幅降低。
表 2给出了在百兆以太网环境下，原有协议和本文提出协议常用功能码的相关数据包长度、本文提出协议与原协议数据包相比的数据包长度增量和数据包增量带来的时间开销。结果表明时间开销为2~3 μs，性能影响极小。
| 表2 数据包大小及时间开销 Tab. 2 Packet size and time overhead |
 |
5 结论
针对ICS控制网与现场网通信面临的安全威胁，设计了一种可信Modbus/TCP协议，通过在传统Modbus/TCP客户机和服务器上增加可信组件和经过修改的通信模块，提出了可信Modbus/TCP协议的实现方法，不但能解决现有Modbus/TCP网络敏感操作数据易被非法通信实体窃取和篡改的问题，还能在一定程度上解决因合法通信实体系统被篡改导致安全认证信息泄露，从而危害安全通信的问题。本文提出的可信Modbus/TCP协议安全性经过SPAN工具验证，协议字段增加造成的通信开销影响较小。虽然采用通用可信芯片测试发现安全功能时间开销较高，但在采用ICS专用安全芯片后开销将会大幅降低。下一步研究工作是为ICS通信双方设计动态的可信性验证方法，为本文中的验证更新子协议提供更好的安全性保障。
| [1] |
Modbus IDA.Modbus messaging on TCP/IP implementation guide rev 1.0[R/OL].(2006-10-24)[2016-03-30].http://www.modbus.org.
|
| [2] |
Knowles W, Prince D, Hutchison D, et al. A survey of cyber security management in industrial control system[J]. International Journal of Critical Infrastructure Protection, 2015, 9: 52-80. DOI:10.1016/j.ijcip.2015.02.002 |
| [3] |
Beijing NSFOCUS Information Technology Co., Ltd.Industrial control systems security report[R/OL].(2013-12-31)[2016-03-30].http://www.nsfocus.com.cn/ 北京神州绿盟信息安全科技股份有限公司.工业控制系统安全报告[R/OL].(2013-12-31)[2016-03-30].http://www.nsfocus.com.cn. |
| [4] |
Liao G, Chen Y, Lu W, et al. Towards authenticating the master in the modbus protocol[J]. Transactions on Power Delivery, 2008, 23(4): 2628-2629. DOI:10.1109/TPWRD.2008.2002942 |
| [5] |
Fovino I, Carcano A, Masera M, et al.Design and Implementation of a secure modbus protocol[C]//Proceedings of the third annual IFIP international Conference on Critical Infrastructure Protection.Hanover, New Hampshire:Springer, 2009:83-96.
|
| [6] |
Hayes G, El Khatib K.Securing modbus transactions using Hash-based message authentication codes and stream transmission control protocol[C]//Proceedings of the 20133rd International Conference on Communications and Information Technology (ICCIT-2013):Networks and Internet Technologies.Beirut:IEEE, 2013:179-184.
|
| [7] |
Green B, Prince D, Busby J, et al.The impact of social engineering on industrial control system security[C]//Proceedings of the first ACM Workshop on cyber-physical Systems-Security and/or Privacy.Denver:ACM, 2015:23-29.
|
| [8] |
Papa S, Casper W, Nair S.Placement of trust anchors in embedded computer systems[C]//Proceedings of the IEEE International Symposium on Hardware-oriented Security and Trust (HOST).San Diego:IEEE, 2011:111-116.
|
| [9] |
Trusted Computing Group.TCG architecture overview, version 1.4[R/OL].(2007-08-02)[2016-03-30].http://www.trustedcomputinggroup.org/tcg-architecture-overview-version-1-4/.
|
| [10] |
Trusted Computing Group.TCG trusted network connect IF-MAP metadata for ICS security specification version1.0 revision 45[R/OL].(2014-09-15)[2016-03-30].http://www.trustedcomputinggroup.org/wp-content/uploads/ICSJWG2012-IFMAP-Metadata-for-ICS-Security.pdf.
|
| [11] |
Wang Jingpei, Liu Jie, Yang Shengming, et al.Integrated trusted protection technologies for industrial control systems[C]//Proceedings of the 18th international Conference on advanced Communication Technology (ICACT).PyeongChang:IEEE, 2016:70-75.
|
| [12] |
Shen Changxiang, Zhang Huanguo, Wang Huaimin, et al. Survey on trusted computing and its development[J]. Scientia Sinica (Informationis), 2010, 40(2): 139-166. [沈昌祥, 张焕国, 王怀民, 等. 可信计算的研究与发展[J]. 中国科学(信息科学), 2010, 40(2): 139-166.] |
| [13] |
Ding Jiali.Development of networked power monitoring system using SM2 encryption algorithm[D].Zhenjiang:Jiangsu University, 2016. 丁佳莉.基于SM2加密算法的网络型电压监测系统的研发[D].镇江:江苏大学, 2016. |