①はじめに

EUが制定したサイバーレジリエンス法（CRA：Cyber Resilience Act）をご存知だろうか？ 直訳するとCyber（サイバー空間の）、Resilience（回復力/復元力/強靭性）、Act（法律/法/法令）である。

サイバーレジリエンス法（以下 CRA）は、デジタル要素を有する製品（電子機器）のすべてに対して、サイバーセキュリティを法的に義務付ける新しい製品安全規則である。従来、サイバーセキュリティは、主にソフトウエアやネットワークの領域で議論され、実装基板や製造工程は「正しく作られていること」が暗黙の前提として扱われてきた。

しかし、CRAでは、実装基板の設計・製造・検査そのものが、製品の安全性を構成する要素として明確に位置付けられることになった。実装基板にはマイコン、SoC、フラッシュメモリ、電源回路、通信回路、セキュリティICなど、製品の機能とセキュリティを左右する要素が集約されている。どれほど安全な暗号方式や堅牢なOSを採用していても、基板上に「意図せず開放されたままのアクセス経路」が残っていれば、攻撃者はそこから内部へ侵入できる。

実装基板検査の工程にセキュリティ対策を実施し、検証する工程は、CRA時代における最後の防波堤であり、単なる品質保証にとどまらず「安全な状態で出荷したことを客観的に示す工程」へと役割が増えることになる。したがって、検査はこれまで以上に重要な位置付けとなる。

本稿では、CRAの基本的な考え方を初心者にも理解できるように整理し、実装基板検査の現場で特に重要となるJTAGポートの扱いを中心に解説する。

なぜJTAGポートが問題視されるのか、なぜ単純に無効化するだけでは現場の実務に不都合が生じるのかを順を追って説明し、現実的な解としての「制限付きJTAGポート」による「検査ファースト」を提案する。

 

②サイバーレジリエンス法 CRAとは

CRAは、「デジタル要素を備えた製品」を対象に、一定水準のサイバーセキュリティを確保することを製造者に義務付けるEUの法令である。対象はIoT機器、産業用装置、通信機器、民生機器など広範囲であり、それらに搭載される実装基板、ファームウエア、組み込みソフトウエアも規制の対象に入る。

CRAの要求事項の特徴は、図１に示す製品のライフサイクル全体（設計→製造→出荷→運用→脆弱性対応）において、セキュリティ管理を求める点にある。設計段階では、リスク分析を行い、不要な機能やインタフェースを最小化する。製造・検査段階では、設計意図どおりのセキュリティ設定が反映されていることを確認する必要がある。また、出荷後に脆弱性が発見された場合には、修正・アップデートを提供する責任を負う。

生産技術者の視点で重要なのは、CRAが「設計だけ良ければよい」とは言っていない点である。量産の現場では、設定漏れ、治具や手順の差、代替部品による挙動変化などの影響確認が求められる。CRA対応では、最終的に「出荷される個体」が安全であることを、個体の検査、もしくは工程として担保して、検査結果を管理する必要がある。

 

③CRAと実装基板検査の関係

従来の実装基板検査は、はんだ付け不良、配線ミス、部品実装ミスなどの物理的・電気的品質確認が中心であった。しかしCRAの観点では、それに加えて「セキュリティ上好ましくない状態が残っていないか」を確認することが求められる。

図２は典型的なデバッグ用インタフェースの例を示している。これらが出荷後に残存していると、攻撃者による物理アクセスの入口となり得る。LAN、UART、JTAGポートなどを、開発や製造検査時に利用している場合、テストやデバッグ機能が、出荷後もセキュリティ上好ましくない状態のまま残っていると、攻撃者にとっては格好の侵入口となる。従来は筐体を開けないと触れないから大丈夫と判断されることもあったが、実際には信号を特定されやすいテストパッドの配置、コネクタの存在、分解容易な筐体などにより、物理アクセスは想定よりも容易な場合がある。

また、CRAでは「説明責任」の側面も強くなっている。すなわち、「何をリスクと認識」し、「どのように対策」し、「出荷時点で対策が有効であること」を、技術文書や記録として示すことが重要になる。検査工程での確認項目とログは、そのままコンプライアンスの根拠資料になる。

 

④ソフトウエアのCRA対策

CRAでは、ハードウエアとソフトウエアを切り離して考えることはできない。ソフトウエアのCRA対策としては、一般的に図３に示すSecure Boot、Secure by Default、SBOM対応、脆弱性対応・管理の4つのセキュリティ対応が求められている。

 

Secure Boot（セキュアブート）とは、機器の電源投入から起動完了までの途中で、実行されるソフトウエアが改ざんされていないことを検証し、正規のものだけを起動させる仕組みである。この仕組みにより、機器が勝手に改ざんされて情報が抜き取られるリスクを低減できる。

Secure by Default（セキュア・バイ・デフォルト）とは、製品を出荷した時点（初期状態）でユーザが特別な設定をしなくても安全側の設定が標準（デフォルト）になっている状態である。例えば、ネットワーク機器が初期状態で、機器の共通パスワードになってしまう場合、セキュリティの危険性が高い状態になってしまう。製品出荷時点で、個別のパスワードが設定されていればリスクを低減できる。

SBOMは、Software Bill of Materials（ソフトウエア部品表）の略で、製品に含まれるソフトウエアを部品表のように一覧化したものである。どのようなソフトウエアを使っていて、どのバージョンであるか、説明と追跡をするための基礎資料となる。

脆弱性対応・管理は、脆弱性情報の通知と安全なアップデートの提供により、機器の安全性管理が求められている。これらのソフトウエアのセキュリティ要件を満たすためには、ハードウエア側でSecure Bootや書き換え制御、デバッグ制御が正しく実装されている必要がある。

例えば、Secure Bootで署名検証を行う設計であっても、JTAG経由でフラッシュを書き換えられる状態ならば、攻撃者は署名検証を回避するための改造を試みられる。逆に、ハードウエア側で適切に書き換え制御がかかっていれば、ソフトウエア側の防御は現実的な強度を持つ。

• 1
• 2
• 3