Modbus Security Protocol深度解析：TLS 加密、X.509 证书认证与工业网络セキュリティ実践
关键词：Modbus Security Protocol、Modbus Security、TLS 加密 Modbus、ポート 802、X.509 证书、工业网络セキュリティ
Modbus protocol诞生于 1979 year。在那个年代，工业控制系统运行在封闭的专有网络中，セキュリティ并ではない设计考量。四十多年后的今天，当这些系统経由イーサネット（イーサネット）和互联网相互连接时，缺乏セキュリティ机制成了 Modbus protocol最致命的短板。
2018 year，Modbus 组织正式发布了 Modbus Security Protocol规范，経由在传输层引入 TLS（Transport Layer Security）加密和 X.509v3 证书认证，为 Modbus 通信提供了身份认证、データ加密和メッセージ完全性三重保护。本記事将从原理到実践，包括的解读这一关键的セキュリティ扩展。
一、なぜか。 Modbus 需要セキュリティ？
1.1 传统 Modbus 的セキュリティ缺陷
標準的 Modbus RTU 和 Modbus TCP 协议在セキュリティ方面几乎是「不设防」的：
| セキュリティ属性 | Modbus RTU | Modbus TCP | 风险 |
|---|---|---|---|
| 身份认证 | ❌ 无 | ❌ 无 | 任何デバイス可伪装为合法マスター |
| データ加密 | ❌ 无 | ❌ 无 | 报文可被窃听和篡改 |
| メッセージ完全性 | ⚠️ 仅 CRC-16 | ⚠️ 仅 TCP checksum | 无法防止恶意篡改 |
| 重放攻击防护 | ❌ 无 | ❌ 无 | 合法报文可被录制后重放 |
| アクセス控制 | ❌ 无 | ❌ 无 | 接入バス的デバイス読み書きができる。任何レジスタ |
1.2 真实的工业セキュリティ事件
2015 年乌克兰电网攻击事件中，攻击者経由劫持 SCADA 系统向变电站送信了未認証的控制命令，导致 22.5 万人停電。もし当使用するとき了 Modbus Security Protocol（或类似的认证加密机制），这种攻击将难以实施。
2021 年佛罗里达州水処理厂攻击事件中，攻击者経由被入侵的 TeamViewer 远程连接，直接修改了 Modbus レジスタ中的氢氧化钠投加量设定值，险些造成大规模公共セキュリティ事故。
二、Modbus Security Protocol架构
2.1 プロトコルスタック对比
標準 Modbus TCP Modbus Security Protocol
┌─────────────┐ ┌─────────────┐
│ Modbus PDU │ │ Modbus PDU │
├─────────────┤ ├─────────────┤
│ MBAP Header │ │ MBAP Header │
├─────────────┤ ├─────────────┤
│ TCP │ │ TLS 1.2+ │
├─────────────┤ ├─────────────┤
│ IP │ │ TCP │
├─────────────┤ ├─────────────┤
│ Ethernet │ │ IP │
└─────────────┘ ├─────────────┤
ポート: 502 │ Ethernet │
└─────────────┘
ポート: 802关键差异：
- 使用 TLS 1.2 或更高版本进行传输层加密
- 使用 X.509v3 数字证书进行双向身份认证
- 使用ポート 802（而非標準的 502）
- PDU 和 MBAP 报头フォーマットの維持不变，完全向后兼容
2.2 セキュリティ握手流程
Modbus Security Protocol的接続の確立分为2つ阶段：
- TLS 握手：クライアント側は与サーバー·サーバー进行標準的 TLS 握手，协商加密套件、交換证书、建立加密通道
- 证书验证：双方验证对方证书的有效性（签名链、有效期、吊销ステータス）
- 角色协商：経由 X.509v3 证书中的扩展字段（Extended Key Usage）确定デバイス角色（クライアント側は/Server）
- Modbus Communication：在 TLS 加密通道内进行標準的 Modbus PDU 交換
Modbus Security Protocol握手流程（简化）:
Client Server
│ │
│──── TCP SYN (ポート 802) ──────────────────────→│
│←─── TCP SYN-ACK ──────────────────────────────│
│──── TCP ACK ─────────────────────────────────→│
│ │
│──── ClientHello (サポート的加密套件) ──────────────→│
│←─── ServerHello + サーバー·サーバー证书 ──────────────────│
│←─── CertificateRequest (リクエストクライアント側は证书) ───────│
│──── ClientCertificate + ClientKeyExchange ────→│
│──── CertificateVerify ────────────────────────→│
│──── ChangeCipherSpec + Finished ──────────────→│
│←─── ChangeCipherSpec + Finished ──────────────│
│ │
│◄═════ TLS 加密通道已建立 ═════════════════════►│
│ │
│──── Modbus PDU (加密) ────────────────────────→│
│←─── Modbus PDU (加密) ────────────────────────│
│ │三、X.509v3 证书在 Modbus Security Protocol中的应用
3.1 证书中的角色定义
Modbus Security Protocol経由 X.509v3 证书的 Extended Key Usage（EKU）扩展来定义デバイス角色：
| Role | EKU OID | 説明 |
|---|---|---|
| Modbus クライアント側は | 1.3.6.1.4.1.50316.802.1 | 发起リクエスト的一方（master） |
| Modbus Server | 1.3.6.1.4.1.50316.802.2 | レスポンスリクエスト的一方（slave） |
在 TLS 握手完成后，双方チェック对方证书中的 EKU 扩展，确保角色マッチング。例如，もしサーバー·サーバー证书中包含クライアント側は EKU，或クライアント側は证书中包含サーバー·サーバー EKU，连接将被拒绝。
3.2 证书生命周期管理
在工业自動化环境中，证书管理面临着独特的挑战：
- デバイス寿命长：工业デバイス可能运行 10~20 year，证书必须提前规划有效期
- オフライン环境：很多工业网络无法アクセス互联网，不能使用公共 CA 签发的证书
- 膨大デバイス：一个工厂可能有数千个 Modbus 节点，逐一管理证书不现实
おすすめ方案：搭建本地 PKI（公钥基础设施），使用私有 CA 签发证书：
# 使用 OpenSSL 搭建工业级私有 CA
# 步骤 1: 作成根 CA 密钥和证书
openssl genrsa -out rootCA.key 4096
openssl req -x509 -new -nodes -key rootCA.key
-sha256 -days 7300 -out rootCA.crt
-subj "/C=CN/ST=Guangdong/L=Shenzhen/O=FactoryName/CN=Factory Root CA"
# 步骤 2: 作成 Modbus サーバー·サーバー证书
openssl genrsa -out server.key 2048
openssl req -new -key server.key -out server.csr
-subj "/C=CN/ST=Guangdong/L=Shenzhen/O=FactoryName/CN=PLC-001"
# 步骤 3: 追加 EKU 扩展（Modbus サーバー·サーバー角色）
cat > server_eku.cnf <<EOF
[ext]
extendedKeyUsage = 1.3.6.1.4.1.50316.802.2
keyUsage = digitalSignature, keyEncipherment
EOF
# 步骤 4: 使用 CA 签发证书
openssl x509 -req -in server.csr -CA rootCA.crt -CAkey rootCA.key
-CAcreateserial -out server.crt -days 3650 -sha256
-extfile server_eku.cnf -extensions ext四、加密套件選択
ではないすべての TLS 加密套件都适合工业环境。需要平衡セキュリティ性和性能：
4.1 おすすめ加密套件
| 加密套件 | セキュリティ级别 | 性能影响 | おすすめ度 |
|---|---|---|---|
| TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | 高 | 低 | ★★★★★ |
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | 高 | 中 | ★★★★☆ |
| TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | 极高 | 中 | ★★★★☆ |
| TLS_AES_128_GCM_SHA256 (TLS 1.3) | 高 | 低 | ★★★★★ |
おすすめ：AES-128-GCM 在大多数 ARM Cortex-M 级别的エンベデッド·イン芯片上都有硬件加速サポート，性能损失极小。对于リソース紧张的組込みデバイス，AES-128-GCM 是最佳選択。
4.2 組込みデバイス上的 TLS 性能
TLS 握手的計算开销主要集中在非对称加密操作（证书签名验证、密钥交換）上。以下是在不同プラットフォーム上的 TLS 1.2 握手时间测试データ：
| プラットフォーム | CPU | 频率 | TLS 握手时间 |
|---|---|---|---|
| Raspberry Pi 4 | Cortex-A72 | 1.5 GHz | ~15 ms |
| STM32H7 | Cortex-M7 | 480 MHz | ~350 ms |
| ESP32 | Xtensa LX6 | 240 MHz | ~800 ms |
| STM32F4（软件 ECC） | Cortex-M4 | 168 MHz | ~3~5 秒 |
重要：在リソース极低的デバイス上（如 STM32F4 级别），建议使用 ECDSA 证书（而非 RSA），因为 ECDSA 的签名验证速度远快于 RSA。或考虑使用预共享密钥（PSK）モード，避免非对称加密操作。
五、与標準 Modbus TCP 的互操作性
Modbus Security Protocol设计为向后兼容。同一个デバイス可以同时サポート標準的 Modbus TCP（ポート 502）和 Modbus Security Protocol（ポート 802），但这带来了一个关键的セキュリティ問題：
もし一个デバイス同时开放 502 和 802 ポート，攻击者完全可以使用 502 ポート绕过すべてのセキュリティ机制！
安すべて署建议：
- 在生产环境中，Close 502 ポート，只开放 802 ポート
- もし必须保留 502（如兼容老系统），使用ファイアウォール将 502 ポート的アクセス限制在特定 IP/子网
- 在 502 ポート上实施アプリケーション層的読み取り専用限制（もしデバイスサポート）
六、Modbus Security Protocol的プログラミング実装
以下是一个使用 Python 実装 Modbus Security Protocolクライアント側は的完全な例：
#!/usr/bin/env python3
"""
Modbus Security Protocolクライアント側はサンプル
使用 TLS 加密连接到 Modbus Security Server（ポート 802）
"""
import ssl
import socket
import struct
class ModbusSecurityClient:
def __init__(self, host, port=802):
self.host = host
self.port = port
# 作成 TLS Contextより
self.ssl_context = ssl.create_default_context(
purpose=ssl.Purpose.SERVER_AUTH
)
# 加载クライアント側は证书和密钥
self.ssl_context.load_cert_chain(
certfile='client.crt',
keyfile='client.key'
)
# load CA 证书（用于验证サーバー·サーバー证书）
self.ssl_context.load_verify_locations(
cafile='rootCA.crt'
)
# 强制要求验证サーバー·サーバー证书
self.ssl_context.verify_mode = ssl.CERT_REQUIRED
# 設定最低 TLS 版本
self.ssl_context.minimum_version = ssl.TLSVersion.TLSv1_2
self.sock = None
self.transaction_id = 0
def connect(self):
"""建立 TLS セキュリティ连接"""
raw_sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
raw_sock.settimeout(5.0)
# 将普通 socket 包装为 TLS socket
self.sock = self.ssl_context.wrap_socket(
raw_sock,
server_hostname=self.host
)
self.sock.connect((self.host, self.port))
# 取得并验证サーバー·サーバー证书
server_cert = self.sock.getpeercert()
print(f"接続しました {server_cert['subject']}")
print(f"TLS 版本: {self.sock.version()}")
print(f"加密套件: {self.sock.cipher()}")
def read_holding_registers(self, unit_id, start_addr, count):
"""function code 0x03 - read holding registers"""
self.transaction_id += 1
# 构造 MBAP Header + PDU
mbap = struct.pack('>HHHB',
self.transaction_id, # Transaction identifier
0x0000, # Protocol Identifier
0x0006, # Length（unit_id + func + data）
unit_id # Unit identifier
)
pdu = struct.pack('>BHH',
0x03, # function code：read holding registers
start_addr, # starting address
count # number of registers
)
request = mbap + pdu
# 経由 TLS 加密通道送信
self.sock.sendall(request)
# 受信レスポンス
response = self.sock.recv(1024)
# Parse MBAP Header
tid, pid, length, uid = struct.unpack('>HHHB', response[:7])
if tid != self.transaction_id:
raise Exception("トランザクション ID 不マッチング！")
# Parse PDU
func = response[7]
if func & 0x80:
raise Exception(f"Exception Code: 0x{response[8]:02X}")
byte_count = response[8]
data = response[9:9+byte_count]
return data
def close(self):
if self.sock:
self.sock.close()
# 使用例の例
if __name__ == '__main__':
client = ModbusSecurityClient('192.168.1.100', 802)
try:
client.connect()
data = client.read_holding_registers(1, 0x0000, 10)
print(f"読み取り到データ: {data.hex()}")
finally:
client.close()七、安すべて署ベストプラクティス Checklist
| # | チェック项 | 优先级 |
|---|---|---|
| 1 | 使用 Modbus Security Protocol（ポート 802）替代標準 Modbus TCP（ポート 502） | 🔴 高 |
| 2 | 部署私有 PKI，使用 ECDSA 证书（优先于 RSA） | 🔴 高 |
| 3 | 使用 TLS 1.2 及以上版本，無効 TLS 1.0/1.1 | 🔴 高 |
| 4 | 在证书中正确設定 EKU 扩展，区分クライアント側は/サーバー·サーバー角色 | 🟡 中 |
| 5 | もし同时开放 502 和 802，用ファイアウォール限制 502 的アクセス範囲 | 🔴 高 |
| 6 | 建立证书生命周期管理制度（定期轮换、吊销清单） | 🟡 中 |
| 7 | 为关键レジスタ实施アプリケーション層アクセス控制（読み取り専用/読み書き分离） | 🟡 中 |
| 8 | 部署网络入侵检测系统（NIDS），モニタリング異常 Modbus 通信行为 | 🟢 低 |
| 9 | 记录并审计すべての Modbus 書き込み操作。（谁、何时、写了什么） | 🟡 中 |
八、common problems FAQ
Q1: Modbus Security Protocol会显著增加通信延迟吗？
TLS 握手阶段会有一次性的延迟（数百毫秒到数秒，取决于デバイス性能），但握手完成后，对称加密（AES-GCM）的延迟仅为微秒级。对于大多数 Modbus 通信场景（ポーリング频率 100ms ~ 1s），TLS 加密的延迟影响可以忽略不计。建议使用长连接（Keep-Alive）避免频繁握手。
Q2: 现有的 Modbus TCP デバイス可以アップグレード为 Modbus Security Protocol吗？
もしデバイス是纯硬件実装的 Modbus TCP（无法更新固件），则不能アップグレード。もしデバイス运行エンベデッド·インオペレーティングシステム且リソース充足，可以経由固件更新追加 TLS サポート。另一种方案是在デバイス前端部署サポート Modbus Security Protocol的代理ゲートウェイ。
Q3: 私用自签名证书在工业环境セキュリティ吗？
在企业内网环境中，使用私有 CA 签发的证书（而非自签名证书）是完全セキュリティ的，前提是：CA 私钥妥善保管、证书域名/IP 正确绑定、吊销机制正常运作。自签名证书（未经过 CA 签发）应避免使用，因为它无法実装有效的信任链验证。
九、未来展望
随着 IEC 62443（工业自動化和控制系统セキュリティ標準）在全球範囲内的强制推行，Modbus Security Protocol将从「可选项」逐步变为「必选项」。越来越多的工业デバイス供应商开始在旗舰产品中内置 Modbus Security Protocolサポート。对于新建项目，从一开始就采用 Modbus Security Protocol，是最具前瞻性的架构决策。
相关阅读：Modbus TCP/IP 网络部署ベストプラクティス | Modbus RTU 与 TCP 深度对比 | Modbus 在産業用IoT中的上級应用
Leave a Reply