Modbusセキュリティプロトコルの詳細なParse:TLS暗号化、X.50 9証明書認証、産業用ネットワークセキュリティの実践
キーワード:Modbusセキュリティプロトコル、Modbus Security、TLS暗号化Modbus、ポート80 2、X.50 9証明書、産業ネットワークセキュリティ
Modbusプロトコルは1979 yearに生まれた。当時、産業用制御システムは閉じた独自のネットワークで動作し、セキュリティは設計上の考慮事項ではありませんでした。それから40年以上経った今日、これらのシステムがイーサネットとインターネットを介して相互に接続されているとき、セキュリティの欠如はModbusプロトコルの最も致命的な欠点です。
2018 year、Modbus OrganizationはModbus Security Protocol仕様を正式にリリースし、トランスポート層にTLS暗号化とX.50 9 v 3証明書認証を導入することで、Modbus Communicationに認証、データ暗号化、メッセージ整合性のトリプル保護を提供します。本稿では、原理から実際の運用まで、この重要なセキュリティ拡張を包括的に説明する。
なぜModbusは安全なのか?
1.1従来のModbusのセキュリティ欠陥
標準的なModbus RTUとModbus TCPプロトコルは、セキュリティに関してほぼ“無防備”です。
| セキュリティ属性 | Modbus RTU | Modbus TCP | リスクは |
|---|---|---|---|
| アイデンティティ認証 | なし | なし | 任意のデバイスが正当なホストになります。 |
| データの暗号化 | なし | なし | メッセージは盗聴·改ざんされる |
| メッセージの整合性 | ️CRC-16のみ | ️TCPチェックサムのみ | 悪意のある改ざんを防止できない |
| リプレイ攻撃保護 | なし | なし | 正当なメッセージは録音後に再生できます。 |
| アクセス制御 | なし | なし | バスにアクセスするデバイスは任意のレジスタを読み書きできます。 |
1.2実際の産業安全問題
2015 yearのウクライナ電力網攻撃では、攻撃者がSCADAシステムをハイジャックして変電所に不正な制御コマンドを送信し、22万5千人が停電した。Modbusセキュリティプロトコル(または類似の認証暗号化メカニズム)が使用されていれば、この攻撃は実行が困難でした。
2021 yearのフロリダ州の水処理プラント攻撃では、攻撃者が侵入したTeamViewerリモート接続を介してModbusレジスタの水酸化ナトリウム濃度設定値を直接変更し、大規模な公共の安全事故を引き起こす寸前でした。
Modbusセキュリティプロトコルアーキテクチャ
2.1プロトコルの比較
標準Modbus TCP Modbusセキュリティプロトコル
������������� �������������
│ Modbus PDU │ │ Modbus PDU │
├─ ── ── ── ── ── ── ┤ ├─ ── ── ── ── ── ── ┤
│ MBAPヘッダ │ │ │ │ MBAPヘッダ │ │ │
├─ ── ── ── ── ── ── ┤ ├─ ── ── ── ── ── ── ┤
│ │ │ TCP TCP │ │ │ │ │ │ TLS 1.2と反対
├─ ── ── ── ── ── ── ┤ ├─ ── ── ── ── ── ── ┤
│ │ │ IPは │ │ │ │ │ │ TCP │ │ │
├─ ── ── ── ── ── ── ┤ ├─ ── ── ── ── ── ── ┤
│ │ │ イーサネット(イーサネット) │ │ │ │ │ │ IPは │ │ │
3------------------- ├─ ── ── ── ── ── ── ┤
ポートPowerPath 502 │ │ │ イーサネット(イーサネット) │ │ │
3-------------------
ポート802主な違い:
- TLS 1.2以上を使用したトランスポート層暗号化
- X.50 9 v 3デジタル証明書による双方向認証
- ポート802を使用する(標準の502ではなく)
- PDUとMBAPのヘッダフォーマットは変更されず、完全な下位互換性がある
2.2安全なハンドシェイク
Modbusセキュリティプロトコルの接続確立は2段階で行われます。
- TLSハンドシェイク:クライアントとサーバの標準TLSハンドシェイク、暗号スイートのネゴシエーション、証明書の交換、暗号化チャネルの確立
- 証明書の検証:双方が相手の証明書の有効性を検証する(署名チェーン、有効期限、失効ステータス)
- 役割の相談:X.50 9 v 3証明書の拡張フィールド(Extended Key Usage)を使用してデバイスの役割(クライアント/サーバ)を決定する
- Modbus Communication:TLS暗号化チャネル内での標準Modbus PDU交換
Modbusセキュリティプロトコルハンドシェイクプロセス(簡素化):
クライアントは サーバ
│ │ │ │ │ │
│---TCP SYNポート802---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
│ ←--TCP SYN-ACK-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
│---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
│ │ │ │ │ │
│---ClientHelloサポートされる暗号化スイート-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
│ ←---ServerHello+サーバ証明書------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
│ ←----CertificateRequestクライアント証明書の要求-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
│---ClientCertificate + ClientKeyExchange------------------------→
│----CertificateVerify---------------→ │
│---ChangeCipherSpec + Finished-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
←--ChangeCipherSpec + Finished--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
│ │ │ │ │ │
† † † † † TLS暗号化通路已建立† † † † † † † † † † † † †
│ │ │ │ │ │
│ ― ― ― Modbus PDU(暗号化)― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ―
│ ← ― ― ― Modbus PDU(暗号化)― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ― ―
│ │ │ │ │ │ModbusセキュリティプロトコルにおけるX.50 9 v 3証明書の適用
3.1証明書内のロール定義
Modbusセキュリティプロトコルは、X.50 9 v 3証明書のExtended Key Usage(EKU)拡張を介してデバイスの役割を定義します。
| 役割の役割 | EKU OID | 説明書は |
|---|---|---|
| Modbusクライアント | 1.3.6.1.4.1.50316.802.1 | リクエストを開始した側(マスター) |
| Modbusサーバ | 1.3.6.1.4.1.50316.802.2 | 要求に応答する側(スレーブ) |
TLSハンドシェイクが完了した後、双方は互いの証明書のEKU拡張をチェックし、役割の一致を確認します。たとえば、サーバ証明書にクライアントEKUが含まれている場合、またはクライアント証明書にサーバEKUが含まれている場合、接続は拒否されます。
3.2証明書ライフサイクル管理
産業オートメーション環境では、証明書管理にはユニークな課題があります。
- 機器の長寿命:産業機器は10~20 年稼働する場合があり、証明書の有効期間を事前に計画する必要があります。
- オフライン環境:多くの産業ネットワークはインターネットにアクセスできず、公開CA発行の証明書を使用できません。
- 海洋機器:工場には数千のModbusノードがあり、証明書を1つずつ管理するのは現実的ではない。
推奨プログラム:プライベートCAを使用して証明書を発行するローカルPKI(公開鍵インフラストラクチャ)を構築する:
Open SSLを使用した産業用プライベートCAの構築
#手顺1ルートCAキーと书の作成
openssl genrsa-out rootCA.key 4096
openssl req-x 509-new-nodes-key rootCA.key
- sha256-days 7300-out rootCA.crt
-subj "/C=CN/ST=Guangdong/L= Shhen/O= FactName/CN=Factory Root CA"
#手顺2サーバ书の作成
openssl genrsa -out server.key 2048
openssl req -new -key server.key -out server.csr
-subj "/C=CN/ST=Guangdong/L= Shhen/O= FactName/CN=PLC-001"
#手顺3 EKU拡张サーバ役割の追加
cat server_eku.cnf
[Ext]
extendedKeyUsage = 1.3.6.1.4.1.50316.802.2
keyUsage = digitalSignature keyEncipherment
EOFと
#ステップ4 CAを使用した証明書の発行
openssl x 509-req-in server.csr-CA rootCA.crt-CAkey rootCA.key
- CAcreates-out server.crt -days3650-sha256
-extfile server_eku.cnf-extensions extensionIV.暗号スイートの選択
すべての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 秒。 |
重要なこと:STM 32 F 4レベルなど、非常にリソースが低いデバイスでは、ECDSAはRSAよりも署名検証が高速であるため、RSAではなくECDSA証明書を使用することをお勧めします。または、PSK Pre-Shared Keyモードを使用して、非対称暗号化操作を回避することを検討します。
標準Modbus TCPとの相互運用性
Modbusセキュリティプロトコルは下位互換性がある。同じデバイスは標準のModbus TCP(ポート502)とModbusセキュリティプロトコル(ポート802)の両方をサポートできますが、これには重大なセキュリティ問題があります。
デバイスがポート502と802の両方を開いている場合、攻撃者はポート502を使用してすべてのセキュリティメカニズムをバイパスすることができます。
安全な展開の推奨事項:
- 本番では、ポート502を闭じ、ポート802のみを开く
- 502を保持する必要がある場合(古いシステムとの互換性など)、ファイアウォールを使用してポート502へのアクセスを特定のIP/サブネットに制限します。
- ポート502でのアプリケーション層の読み取り専用制限の実装(デバイスがサポートしている場合)
Modbusセキュリティプロトコルのプログラミング実装
Pythonを使用したModbusセキュリティプロトコルクライアントの完全な例を以下に示します。
#!/ usr/bin/env Python 3の設定
"""
Modbus Security Protocolクライアントの例
TLS暗号化を使用したModbus Securityサーバへの接続(ポート80 2)
"""
SSLのインポート
ソケットのインポート
構造体のインポート
class ModbusSecurityClient
___
self.host = host
self.port = port
#TLSコンテキストの作成
self.ssl_context = ssl.__context
p
)
#クライアント証明書と鍵の読み込み
self.ssl_context.load_cert_chain
certfile ='client.crt'
keyfile ='client.key'
)
#CA証明書のロードサーバ証明書の検証に使用
self.ssl_context.load_verify_locations
cafile ='rootc.crt'
)
#サーバ証明書の検証を強制
self.ssl_context.verify_mode = ssl.CERT_IRED
TLSの最小バージョンを設定
self. ssl_context.minimum_version = ssl.TLSVersion.TLSv1_2
self.sock =なし
self.transaction_id = 0
def connect(self):
“≪ TLSセキュア接続の確立| Create TLS Secure Connection | emdw ≫”
raw_sock = s.ss.AF_INET s.SOCK_
raw_sock. setout 5.0
通常のソケットをTLSソケットにラップする
self.sock = self.ssl_context. w_s
raw_sock、
server_hostname = self.host
)
self.sock.self.host self.port
#サーバー証明書の取得と検証
server_cert = self.sock. getpeert
print f"は{server_cert['subject']}"に接続されています
print f"TLSバージョン{self.sock.version}"
print f"暗号化スイート{self.sock.pher
read_h
""
self.transaction_id = 1
MBAPヘッダ+ PDUの構築
mbap = str.pack 'HH'
self.transaction_id #トランザクション識別子
0 x 0000, #プロトコル識別子
0 x 0006、 長さ(unit_id + func + data)
_id #ユニットID
)
pdu = str.pack 'BHH
0 x 0 3、 #関数コード:読み取り保持レジスタ
start_addr #開始アドレス
Count Count #レジスタの数
)
request = mbap + pdu
TLS暗号化チャネル経由で送信
self.sock.sendall request
#応答の受信
response = self.sock.recv (1024)
#MBAPヘッダーのParse
tid pid length uid = struct.unpack 'HHHB' response [7]
もしTID ! self. transaction_id
raise Exception "トランザクションIDが一致しません! ")
#PDUのParse
func =応答[7]
if func 0x80
raise Exception f"例外コード0x{[8] 02X}"
byte_count = response[8]
data = response[9 9+ byte_count]
データの返却
def close self
if self.sock
self.sock. cl
#例を使う
if __name__== '___main__'
client = ModbusSecurityClient '192.16 8.1.100'、80 2
try
client.connect
data = client.read_hing_registers 1 0x0000 10
print f"データへの読み込み{data.hex()}")
finally:
client.close()セキュリティ導入のベストプラクティスチェックリスト
| # | チェック項目 | 優先順位は |
|---|---|---|
| 1 | Modbus TCP(ポート502)をModbusセキュリティプロトコル(ポート80 2)に置き換える | 高さを |
| 2 | ECDSA証明書を使用したプライベートPKIの導入(RSAよりも優先) | 高さを |
| 3 | TLS 1.2以上でTLS 1.0/1.1を無効にする | 高さを |
| 4 | 証明書にEKU拡張機能を正しく設定し、クライアント/サーバの役割を区別する | Celerra内 |
| 5 | 502と802を同時に開放すると、ファイアウォールで502のアクセス範囲を制限する | 高さを |
| 6 | 証明書ライフサイクルマネジメントシステムの確立(定期ローテーション、失効リスト) | Celerra内 |
| 7 | 重要レジスタのアプリケーション層アクセス制御(読み取り専用/読み取り/書き込み分離)の実装 | Celerra内 |
| 8 | ネットワーク侵入検知システム(NIDS)を導入し、異常なModbus 通信挙動を監視 | 低コスト。 |
| 9 | すべてのModbus書き込みOperation(誰が、いつ、何を書いたか)を記録し監査する。 | Celerra内 |
8.よくある質問FAQ
Q1)Modbusセキュリティプロトコルは通信遅延を大幅に増加させますか?
TLSハンドシェイクフェーズには1回限りの遅延(デバイスの性能に応じて数百ミリ秒から数秒)がありますが、ハンドシェイクが完了すると、対称暗号(AES-GCM)の遅延はマイクロ秒程度になります。ほとんどのModbus Communicationシナリオ(ポーリング周波数100ms ~ 1秒)では、TLS暗号化のレイテンシの影響は無視できます。頻繁なハンドシェイクを避けるために、ロングコネクション(Keep-Alive)を推奨します。
Q2)既存のModbus TCPデバイスをModbusセキュリティプロトコルにアップグレードすることはできますか?
デバイスがModbus TCPの純粋なハードウェア実装(ファームウェアを更新できない)の場合は、アップグレードできません。デバイスが組み込みオペレーティングシステムを実行しており、十分なリソースがある場合は、ファームウェアのアップデートでTLSサポートを追加できます。もう一つの選択肢は、デバイスのフロントエンドにModbusセキュリティプロトコルをサポートするプロキシゲートウェイを展開することです。
Q 3)プライベート自己署名証明書は産業環境で安全ですか?
イントラネット環境では、CA秘密鍵が適切に保管され、証明書ドメイン/IPが適切にバインドされ、失効メカニズムが適切に機能していれば、(自己署名証明書ではなく)プライベートCAが発行した証明書を使用することは完全に安全です。自己署名証明書(CAによって発行されていない)は、効果的な信頼チェーン検証を実現できないため、避けるべきです。
IX.今後の展望
IEC 624 43(産業オートメーションおよび制御システムの安全規格)の世界的な義務化により、Modbusセキュリティプロトコルは“オプション”から“必須”に移行します。ますます多くの産業機器ベンダーがModbusセキュリティプロトコルサポートを主力製品に組み込み始めています。新しいプロジェクトでは、最初からModbusセキュリティプロトコルを採用することは、最も先進的なアーキテクチャ上の決定です。
関連する読書:Modbus TCP/IPネットワーク導入のベストプラクティス|Modbus RTUとTCPの比較|産業用モノのインターネットにおけるModbusの高度な応用
Leave a Reply