【ITニュース解説】IEC 60870-5-104 Security: From APCI State Activation to IEC 62351

このニュース記事は、電力システムなどで使用される遠隔制御プロトコル「IEC 60870-5-104」（通称IEC 104）のセキュリティについて、基礎的な動作原理から、現代的なセキュリティ対策の導入までを詳細に分析したものだ。システムエンジニアを目指す人にとって、プロトコルがどのように機能し、どのようなセキュリティ上の課題を抱え、そしてどのように解決されるのかを理解するための実践的な洞察が提供されている。

まず、IEC 104プロトコルの基本的な仕組みから解説しよう。このプロトコルは、TCP/IPネットワーク上で動作し、変電所などの電力設備の監視（テレメトリ）や制御コマンドの送信に利用される。記事では、単に「ポート2404が開いている」という表面的な議論に留まらず、その内側のプロトコルアーキテクチャに深く踏み込んでいる。

TCP接続が確立された後、IEC 104はすぐさまアプリケーションデータを交換するわけではない。まずAPCI（Application Protocol Control Information）と呼ばれる制御フレームを用いて、プロトコル独自の「リンク状態」を確立する。APCIには、主に三つの種類がある。I-フォーマットフレームは実際のアプリケーションデータ（ASDU：Application Service Data Unit）を運び、S-フォーマットフレームは受信確認、U-フォーマットフレームはリンクの開始（STARTDT）、停止（STOPDT）、テスト（TESTFR）といった制御を行う。この研究では、特にU-フォーマットフレームによるリンクの「アクティベーション（活性化）」に着目している。

最初の実験では、ターゲットとなるサーバーにTCP接続後、U-フォーマットの「STARTDT ACT」フレームを送信してリンクを活性化した。サーバーは「STARTDT CON」で応答し、データ転送可能な状態になった。ここで重要な発見は、このリンク活性化のプロセスにおいて、通信相手の身元確認、パスワード交換、暗号学的なチャレンジ、認証といったセキュリティステップが一切行われなかったことだ。つまり、TCP接続が確立されさえすれば、誰でもプロトコルのリンクを活性化し、次の段階に進むことが可能になる。これは、ベースとなるIEC 104プロトコルが通信状態の遷移メカニズムは提供するものの、通信相手を認証する境界を持たないことを示している。

リンクが活性化された後、次の段階ではASDUレイヤーに焦点を移し、アプリケーションデータのやり取りを調べた。IEC 104では、IOA（Information Object Address）とCA（Common Address）を組み合わせてアプリケーションデータを識別する。実験では、テレメトリデータの受信や、単一コマンド（C_SC_NA_1）、一般呼出し（C_IC_NA_1）といったコマンドの送信を行った。サーバーは要求に応答するだけでなく、定期的にテレメトリを送信しており、その挙動も確認された。また、TCPストリーム内には複数のAPDU（Application Protocol Data Unit）が存在する可能性があり、単にソケットから読み込んだデータが1つのIEC 104フレームに対応するとは限らないため、アプリケーションレベルでストリームを解析する仕組みが必要であることも示された。

さらに、プロトコルの不正な利用を試みる実験も行われた。例えば、リンクが活性化される前にI-フォーマットフレームを送信したり、リンクが停止された後にI-フォーマットフレームを送信したりすると、サーバーは接続を終了させた。これは、プロトコルの状態機械が一定のルールを適用していることを示している。しかし、シーケンス番号（N(S)とN(R)）の操作については、サーバーが連続性を失ったジャンプ（例えばN(S)=5000）を受け入れても、すぐに接続をリセットしないなど、実装によっては標準のセマンティクス（意味）が厳密に強制されない場合があることが分かった。

特に重要な発見は、Type ID 45（C_SC_NA_1）の単一コマンドを直接送信した際に、サーバーがこれを承認前に実行してしまったことだ。これは、産業制御システムにおいて一般的に推奨される「Select-Before-Operate」（選択してから操作する）という安全手順が、この特定の実験環境では強制されていなかったことを意味する。この結果から、ネットワークに到達でき、アドレス体系が分かっていれば、認証なしに直接制御機能を操作できる可能性があることが明らかになった。

また、意図的に壊れたパケット（不正な開始バイト、過大な長さ、未サポートのタイプID、不完全なデータなど）を送信して、プロトコルパーサーの挙動もテストした。結果として、サーバーはこれらの不正な入力に対してクラッシュすることなく動作を続けた。これは実装の堅牢性としては良い点だが、同時に、一部の不正な入力が診断応答なしに静かに破棄される場合もあった。このことは、プロトコルが「構造的に有効か」をチェックすることと、「通信元がコマンドを送信する権限があるか」を判断することは全く異なる問題であることを示唆している。

これらの実験を通じて明らかになったのは、ベースとなるIEC 104プロトコルのAPCIレイヤーはプロトコルの状態を管理するが、通信相手の身元を保証しない。ASDUレイヤーはアプリケーションのセマンティクスを提供するが、自動的に権限を付与しない。シーケンスカウンターは順序を保証するが、データの改ざん防止は行わない。そして、パケットパーサーは構造的に不正なフレームの多くを拒否するが、正当なマスターと未承認のマスターを区別できない、ということだ。

これらのセキュリティ上の課題を解決するため、研究の最終段階では「IEC 62351」というセキュリティ拡張を導入した環境で比較実験を行った。これは、TLS（Transport Layer Security）やmTLS（mutual TLS）といった技術を使って、通信チャネル自体を保護するアプローチだ。

クリアテキスト環境ではTCP接続後にSTARTDT ACT/CONでリンクが活性化されていたが、セキュアな環境では、まずクライアントがTLSによる認証境界を満たす必要があった。認証されていないクライアントは、IEC 104のリンク活性化に到達する前に、TLS接続の確立段階で拒否される。これは、セキュリティ上の根本的な失敗ポイントが大きく異なり、未承認の通信がアプリケーション層に到達するのを防ぐ効果がある。有効な証明書を持つクライアントがTLS接続を確立すると、その後IEC 104のトラフィックは暗号化されたチャネル内でやり取りされるため、パケットを傍受してもその内容を直接見ることはできなくなる。

しかし、暗号化と認証だけではすべての問題が解決するわけではない。TLSが「誰が通信しているか」を証明しても、「その認証された通信者が特定の制御点を操作することを許可すべきか」は自動的には決定されない。そこで、セキュアな環境にはさらに「認可」のレイヤーが追加された。実験では、認証されたクライアントが特定のIOAへの制御要求を送信した際、サーバー側の認可ロジックがその役割に基づいてアクセスを拒否した。これは、認証が身元確認を行うのに対し、認可はその身元に許可された行動を制限する、という二つのメカニズムの明確な違いを示している。

この研究全体を通して得られた結論は、IEC 104プロトコルが各レイヤーで特定の機能を果たす一方で、ベースラインの実装では暗号学的な身元確認や認可の境界線が確立されていなかったということだ。プロトコルの正確な動作とセキュリティ上の認可は異なる特性であり、堅牢なシステムを構築するためには、TCPからAPCI、ASDU、IOA、そして最終的な制御機能、さらに認証と認可といった通信の全経路を体系的に評価する必要がある。この研究は、単に「IEC 104はセキュアではない」と結論付けるのではなく、プロトコルと実装を体系的に調査し、どこにセキュリティの境界線が存在し、どこに存在しないのかを明確にするための方法論を示している。