IoTデバイスのセキュリティで、ますますニーズが高まる暗号モジュールセキュリティ要件「FIPS140-3」の勘所とは？

ラムバスは、高速メモリーや高速バスインターフェースの技術を多くの半導体メーカーやシステムベンダーに提供してきた。またCryptography Research社を買収したり、Inside Secureの事業譲渡を受け、組み込みセキュリティ系の技術提供も行っている。現在はデータセンターからモバイルエッジに渡る幅広いセキュリティ要件に応える、高性能かつ高品質なセキュリティソリューションをカバーしている。ラムバス シニア テクニカルセールス マネージャー 星野力氏が、最新の暗号モジュールセキュリティ要件「FIPS140-3」の勘所について解説した。

組込み機器のセキュリティで重要な「FIPS140－3」とは何か？

まず今回の主題である「FIPS140-3」とは、どんな規格なのだろうか?　これは暗号化モジュールのセキュリティ要求に対するデファクトスタンダードで、ISO/IEC19790:2012と相互参照するものだ。

FIPS140-3の全体像だが、前バージョンとして20年以上前に作られたFIPS140-2があり、ISO化が図られてISO/IEC19790となった。最新のバージョンアップ版がFIPS140-3である。

前バージョンとの大きな違いは、FIPS140-2では1つのドキュメントで完結していたが、FIPS140-3は複数の参照によって構成されていること。まずはISO/IEC19790を参照し、その中にアネックスとしてSP800-140A~Fを上書きして解釈したものが、FIPS140-3の要件ということになる。

FIPS14-3が優れているのは、認証機関がしっかり運用している点だ。米国NISTとカナダCSEによって運用され、暗号モジュール評価・認定制度「CMVP」というプログラムで認証書を発行している。

ただし実際にCMVPで評価することになると、作業が膨大で大変になるので、CMVP認証ができる機関として現在NVLAP認定試験機関として21機関が存在している。これらのどこかで評価を行い、その結果をCMVPにあげて認証を発行してもらえばよい。日本ではECSEC LaboratoryとITセキュリティセンターがCMVPの認定機関になっている。

現時点（2021年8月）でFIPS140に認証されているモジュールは1117個ほどある。モジュールの定義として「ハードウェア単体」「ソフトウェア単体」「ファームウェア単体」「ソフトウェアとハードウェアのハイブリット」「ソフトウェアとファームウェアのハイブリット」という分類がなされ、それぞれを認証している。

ここでいうハードウェアとは、1つのハードウェアのセキュリティバウンダリー（境界）にソフトウェアやファームウェアが含まれているもの。ソフトウェアはソフトウェア単体、ファームウェアは上書きできないモジュール形態で、ハイブリットはハードウェアのセキュリティバウンダリーの外側にソフトウェアやハードウェアが存在する形態を指す。

各セキュリティレベルには強度に応じて1～4までの段階があり、数字が大きいほど強固なセキュリティになる。具体的な製品（モジュール）としては、ネットワーク機器や複合機（MFP）などで認定が多く取られており、サーバー機器、PCでよく使われるHSM（Hardware Security Module）などのチップも取得されている。民生品からネットワーク機器まで幅広いカバーリングだ。

FISP140-3をベースにした暗号モジュールのセキュリティ設計の流れとは？

組込み系でセキュリティを実装する際に「具体的に何をやれば良いのか分からない」「どこから手をつければよいのか分からない」という声が多く聞かれる。セキュリティ対策を講じるとき第一のハードルになるのは、どんな脅威を網羅的に分析していくかであろう。しかし、これらを自社ですべて行うのは難しい。

そこでセキュリティの肝になる要件定義の部分を、多くのエキスパートが徹底レビューして作成したFIPS140‐3を参考にすれば、実装時の大きな手助けになる。次にFISP140-3をベースにした暗号モジュールのセキュリティ設計の流れについてみていこう。

まず暗号モジュールの要件定義については、これまで紹介してきたFIPS140-3を参照すればよい。次にこの要件定義を見て、自社の製品の仕様や機能を鑑みながらセキュリティポリシーを作成する。ここでは単純に1つの機能だけでなく、網羅的な観点でセキュリティポリシーを策定することが重要になる。

次に実際の設計書で実装を行う。ここでハードルが高い点が、セキュリティが本当に正しく実装できているのか、品質をどう担保していけばよいのかという点だ。特にセキュリティ品質は計測機では測れないため難しい。そこで品質を担保するために、第三者機関の第三者の目で見てもらうことが王道になる。FIPS140-3では前出の機関が認定を行っている。

FIPS140-3の要求概要と、セキュリティ実装における勘所を伝授

ここからはFIPS140-3の要求概要を中心に紹介する。多くのセキュリティ要件があるが、その中で1番の肝になる点が、情報漏洩がない形で運用するため「セキュリティのライフサイクル」である。組織内のプロセスのように、セキュリティモジュールについても同様のライフサイクルが求められるわけだ。

たとえば、どういう権限を持った人が、モジュール初期化の鍵を持って書き込めるのか、故障した場合に手順を踏んで鍵を消去して、修理を行って再び鍵を書き込んだり、モジュールを廃棄するには鍵を消去して、中にリソースがないかを確認するといったことが大切になるだろう。

もしシステムの1部が壊れた状態でセキュリティモジュールを動作させると、中のリソースが漏れてしまうリスクがある。必ずセルフテストをかけて、モジュールが正常な状態になっているのかを確実にしなければならない。また、システムの不正侵入など異常な動作があれば、場合によっては内部のクリティカルなリソースを消去する必要があるかもしれない。

単に脅威をブロックしたり、外から鍵が見えない状態にするだけでなく、このような実務での運用面の考え方が実製品を組む際に考えるべき点で、それがFIPS140-3で整理されているため、ぜひ押さえておきたいところだ。

要件に合う形で具体的にセキュリティを実装するには、システム全体を堅牢化するのが理想的だが、膨大なコストが掛かってしまう。そこでセキュリティモジュールにバウンダリーを作り、この中を守るようにすることが基本となる。FIPS140-3でも、まず論理セキュリティの境界となるバウンダリーを明確にして、そこと外界のインターフェイス（I/F）をすべて定義する。当然だが、不明なバックドアがあったりすると、そこがセキュリティホールになりえるからだ。

ここで定義されるべきI/Fの種類には、FIPS140-2では「データ入出力」「制御信号入力」「ステータス出力」「電源入力」だったが、FIPS140-3になって、さらに「制御信号出力」も加わっている。

またモジュールで提供されるサービスを、誰が実施できるのか、役割（role）と認証方法をしっかり定義して実装することも大切だ。運用者として実際に操作する「User Role」（オペレータ）、モジュール初期化やUser登録、鍵の登録・消去が可能な「Crypte Officer Role」（管理者）などの役割がある。

モジュールの企画段階で、誰がどんな権限を持ち、どういう認証で入れるのかも明確にしておく。たとえばレベル4なら、Crypte Officerでログインする場合は二要素認証にして強化するといった形だ。

次に暗号化アルゴリズムの要件についてだが、FIPS140では「FIPSモード」（FIPS approved）と「ノンFIPSモード」（Non-FIPS approved）に分けて明記する必要がある。FIPSモードで動くときは、NISTが認証するアルゴリズムを使う。ただしモジュールによっては、FIPSモードだけで動かせないこともあるので、それ以外はノンFIPSモードのアルゴリズムを使う。

いずれにしてもFIPSモードのときは、CMVP認証の前段階でアルゴリズムの実装が正しいことを確認して、CAVP認証（Cryptographic Algorithm Validation Program）に臨まなければならないという。実はこの認証のハードルが高いそうだ。

またFIPSモードか、あるいはノンFIPSモードで暗号モジュールが動くのか、そのモードを分ける必要もある。もしセキュリティのレベルが高くなれば、現在どのモードが使われているのかを、外部インジケータなどで明示することも求められるという。

マルウェアなどのネガティブテストで、未定義のステート（状態）に落ちたり、ステートがスキップ状態になるかもしれない。テストでエラーを引き起こすシナリオに対しては、あらかじめ意図された状態に遷移するのかを確認し、実装漏れがないことをFMS（Finite State Machine）形式で試験機関に提出することが求められる。

とはいえ、エラーが起きたときのパスを実機で確認するのも一苦労だ。その場合は、シミュレーションなどで代替するなどの工夫も考えておこう。

自社製品でFIPS140-3認証を容易に通してもらうための2つのヒント

ここまでFIPS140-3認証のための要件を見てきたが、実際に自社製品を認証してもらうのが大変なことも同時にご理解いただけただろう。そこで、どうやって容易に認証を受けるかという話なのだが、最後に2つのアプローチを紹介して締めたい。

まずソフトウェアやファームウェアのモジュールの場合なら、すでに認証得済のものをバイナリで採用することがオススメだ。

たとえばラムバスの「SafeZone FIPS Cryptographic Module Security Level1」（認証番号3661）を使うと、ユーザー側でもFIPS140-3認証を受けているものと主張できる。このモジュールは国内のMFPで約70％のシェアを占めており、そのほかスマートフォンや車載製品、ネットワーク機器での実績もある。

もう1つはハードウェアモジュールでの認証の場合だ。新しいチップを設計したり、内部のソフトウェアを書き換えるときは認証が難しいだろう。その場合は「ホワイトラベル方式」で認証を加速させ、ユーザー側の製品で認証を再取得するとよい。

ユーザーデザインのセキュリティ・バウンダリー内に認証済IPをポーティングする。たとえばラムバスの「Rambus VaultIP Security Level2」（認証番号3945）を採用すれば、セキュリティポリシーなどの提出文書やテストプログラムもサポートしてくれるので、認証も手っ取り早くなるだろう。