2025-12-26 01:35:15 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文介绍电力行业通信安全标准IEC62351-5，通过在应用层ASDU中增加安全报头与报尾，利用系统标识、序列号及数字签名等技术，为传统IEC60870-5协议提供身份认证、完整性与防重放保护。该方案独立于传输层，兼容串口与网络环境，有效解决老旧协议的安全缺陷。 综合评分： 85 文章分类： 技术标准,网络安全

cover_image

【大话工控安全】工业控制系统行业知识：电力行业通信安全标准IEC62351（GB/T 25320）-PART5

原创

老付话安全

2025年12月25日 20:37 山东

点击蓝字

关注我们

始于理论，源于实践，终于实战

老付话安全，每天一点点

激情永无限，进步看得见

关注我，带给你不一样的精彩

世界因你的沉淀而出彩

严正声明

本号所写文章方法和工具只用于学习和交流，严禁使用文章所述内容中的方法未经许可的情况下对生产系统进行方法验证实施，发生一切问题由相关个人承担法律责任，其与本号无关。

特此声明！！！

本文字数：

2595字

阅读时间：

7分钟

IEC 62351标准的第五部分 (IEC 62351-5) 旨在为传统的电力系统通信协议（特别是IEC 60870-5系列及其衍生协议，如IEC 60870-5-101 (101规约)、IEC 60870-5-104 (104规约，101的升级版，跑在TCP/IP 网络上)北美的DNP3）提供专门的安全扩展。

该部分的主要内容和特点包括：

针对老旧协议的“打补丁”方案：许多传统的遥控协议（如IEC 60870-5-101、IEC 60870-5-104）在设计时没有考虑网络安全需求。IEC 62351-5 提供了一种应用层安全机制，通过向原始报文添加安全报头和数字签名/MAC（报尾）来实现安全防护。
安全目标：该标准的核心目标是解决传统协议面临的身份冒充、数据篡改和重放攻击等问题，确保通信的数据完整性和身份认证。
应用层独立性：与主要依赖传输层安全性（如TLS）的IEC 62351-3不同，IEC 62351-5 提供的是应用层安全配置文件（A-profile），这意味着它不依赖于特定的物理传输介质（如以太网或串行通信），因此也适用于串口通信等场景。
报文级安全：它在单个协议数据单元 (APDU) 级别提供端到端 (E2E) 的安全保护，即使数据通过多个中间系统转发也能维持安全。

前情回归：

本部分采用一种 “打补丁升级” 的思路，在原有的协议报文结构里塞入安全信息。使用应用层安全扩展ASDU的格式，这种方式兼容性更好，但实施相对复杂。

在不改变现有TCP连接和APCI的前提下，在应用层为原始ASDU增加安全字段，构成一个新的、安全的ASDU。目前国内采用的是传输层安全（TLS）：在TCP层建立一个加密隧道。此时，标准的IEC 104 APDU报文在进入网络前就已经被TLS加密保护，报文本身格式无需改变。这是目前主流和推荐的模式。

本部分在原本的规约报文（比如 101 或 104 的一帧数据）前面加个安全报头，在后面加个安全报尾来实现安全的。

安全的IEC 104报文格式详解

标准的IEC 104报文是由 APCI（传输控制信息） 和 ASDU（应用服务数据单元，即实际数据） 组成。即：

[APCI] + [ASDU]

IEC 62351-5的“安全”机制，是通过定义两种新的ASDU类型来实现的：

安全认证ASDU：类型标识为 0x69 (105)。这就是承载“安全”的主体。
加密ASDU：类型标识为 0x6A (106)。用于对ASDU内容进行对称加密（较少使用）。

原始报文并不会被物理地“包裹”，而是被重构为一个新的、包含安全信息的安全ASDU。逻辑上可以理解为：

[APCI] + [新的安全ASDU(其中包含了原始ASDU和安全字段)]

这个 0x69 类型的安全ASDU 内部结构如下，它完美对应了“报头”和“报尾”：

1. 安全报头 这部分是安全ASDU中的数据单元公共地址和信息对象的前几个元素。“安全报头”内容，包括身份ID和序列号，这对应着安全ASDU里的关键字段：System ID和Security Sequence Number。

系统标识符：对应“身份证”。这是一个4字节的System ID，唯一标识一个安全域（例如，一个主站或一个变电站系统），用于防止跨系统重放攻击。
安全序列号：对应“流水号”。这是一个8字节的Security Sequence Number，每个发送方独立维护并递增。接收方会维护一个接收窗口，拒绝重复或过时的序列号，这是防重放攻击的核心。
时间戳：对应“发件时间”。这是一个4字节或8字节的Time of Day，精度可达毫秒。用于辅助防重放（拒绝未来时间或过于久远的时间）和提供事件时间证据。

2. 原始ASDU 紧接着安全报头之后，完整地、未经修改地嵌入原始的ASDU（包括其类型标识、可变结构限定词、公共地址、信息对象等所有内容）。

3. 安全报尾（认证数据） 部分是安全ASDU的最后一个信息对象。“安全报尾”包括数字签名和MAC，在标准中这两种机制对应不同的Key ID范围，以及整个S-Auth-Data的构造过程（对原始报文+S-Security Header的哈希值进行签名或MAC）。接收端验证时，必须重新计算哈希并与解密/验证后的结果比对。

认证数据：这是一个可变长度的字段，里面存放的正是数字签名或消息认证码。其具体形式由 Key ID 字段标识。
数字签名：使用发送方的私钥对整个安全序列号+时间戳+原始ASDU的哈希值进行签名。接收方用发送方的公钥验证。提供不可否认性。
MAC：使用双方共享的密钥，对上述相同的数据计算MAC。提供完整性校验和身份认证，但不具备不可否认性。
Key ID：一个标识符，告诉接收方使用哪个公钥或共享密钥来验证。

工作流程

发送端（如IED）：

当需要发送一个总召唤命令（0x64）或一个测量值（0x09）时，它首先构造出原始的ASDU。
然后，安全模块根据配置，生成System ID、递增安全序列号、获取当前时间。
接着，计算认证数据（签名或MAC）。
最后，将所有部分组装成一个类型为 0x69 的新安全ASDU，通过标准的IEC 104 APCI发送出去。

接收端（如主站）：

收到报文后，识别ASDU类型为 0x69，知道这是一个安全报文。
提取安全序列号和时间戳，进行时效性和防重放检查（是否在有效窗口内？是否已接收过？）。
根据System ID和Key ID，找到对应的公钥或共享密钥。
使用该密钥，对报文中的安全序列号、时间戳和原始ASDU部分重新计算哈希，并与解密/验证收到的认证数据进行比对。
只有所有检查（序列号、时间戳、签名/MAC）都通过，接收端才会将内嵌的原始ASDU提取出来，交给上层应用程序（如SCADA）进行处理，就像收到一个普通报文一样。否则，报文将被丢弃并记录安全事件。

end

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：老付话安全老付话安全《【大话工控安全】工业控制系统行业知识：电力行业通信安全标准IEC62351（GB/T 25320）-PART5》