FIPS140とは何か？
「FIPS140最前線」 第二回

ラムバス株式会社 FAEの古川です。前回から時間が空いてしまいましたが、今回は、FIPS140の具体的な内容について、その特徴や、掲げられているセキュリティ機能の目標、認証取得のチャレンジなどについて解説します。

注：FIPS140認証は、米国NIST・カナダCCCSから、申請者であるベンダーに対して発行されますが、ベンダーから直接NIST・CCCSに申請ができるわけではなく、認証ラボを経由して申請することになります。

FIPS140認証の難しさ：コモンクライテリアのように、製品全体や開発プロセスまでを範囲とする要件と比較すると、暗号モジュールのみに対する要件であるFIPS140の認証は、一見すると、その範囲の狭さから容易であるように感じられるかもしれませんが、以下のような認証の難しさがあり、想像するほど容易ではありません。

ーFIPS140-2/3文書単体で、要件が完結するわけではなく、暗号・鍵合意アルゴリズム、乱数器といった要件は、それぞれに対応するSP800文書が引用され、要件全体を構成する文書量は、かなりのボリュームとなり、要件理解に相応の労力が要求される。

ー暗号モジュールに範囲を限定しているが故に、かなり具体的な実装要件が多数存在する。認証取得には、この実装要件を正確に理解する必要がある。しかし、上記の文書だけでは解釈にばらつきが生じる部分もあり、補足文書として、IG(実装ガイダンス)という文書が準備されている。それでも、ラボに確認しないとはっきりしない実装要件が一定数は存在し、認証のコードレビューでのフィードバックにより、初めて認識できるような要件も存在する。 

ーハードウェアだけではなく、ソフトウェア実装のモジュールも規定されており、さらにそれらを組み合わせたハイブリッドな構成も規定。IGにある程度の解釈は示されているものの、FIPS 140-2/3文書自体は、特定の実装形態に依らない形で記述されているため、実装要件の理解に経験が要求される。

ーFIPS140認証を主張するためには、認証取得時の実装との厳密な一致が要求される。ソフトウェアモジュールの場合は、モジュールのセキュリティポリシーに規定される実行環境が使用され、モジュール自体は、バイナリレベルで同一であることが要求される。同様に、ハードウェアモジュールにおいても、ハードウェアが同一であるだけでなく、モジュール内に実装されるファームウェアにおいても、同一であることが要求される。

ー要件と実装が細部まで合致していることが要求され、その評価はコードレビューのレベルで行われる。また申請者側にて、故障を含めた取りうる全てのシナリオに対してテストを準備・実施し、その結果の提出が求められる。

ーIGは、年に一度ないしは二回程度の更新が入り、また関連SP文書にも改版が入ることがある。それに付随する形で、認証要件が時折アップデートされる。その際に必要な修正と再申請が行われない場合には、5年の認証期間満了を待たずして認証が取り消される場合もある。したがって、認証を取得して終わりというわけではなく、認証ステータスの維持には、各文書の動向把握とメンテナンスコストが求められる。

• 要件更新の例（2022年6月）：鍵合意アルゴリズムDH関連 (SP800-56Arev3)
  
  
  • IPsecやTLSなど暗号通信では、通信データの暗号にAESなどの共通鍵暗号が用いられます。共通鍵暗号方式では、通信する双方で同じ鍵を事前に共有することが必要で、この共通の鍵を双方が持つために「DH」と呼ばれる鍵合意アルゴリズムを用いることが一般的です。この時DH鍵合意では、指数サイズなど、セキュリティ強度に応じてパラメータ選択および鍵生成を行い、それらを確認することが要件として明確化されました。
    
  • これは最新のFIPS140-3要件ではもちろん、既存のFIPS140-2の要件にも含められます。対応しない場合は、取得済みのFIPS140-2認証であっても、認証が外れる事態となりましたので、注意が必要です。

FIPS140の掲げる８つの目標：セキュリティ機能目標（Functional security objectives）

• 機密情報を保護するために、承認されたセキュリティ機能を採用し、正しく実装する。
  
  
  • ここでのセキュリティ機能とは、具体的には暗号やハッシュ、メッセージ認証のアルゴリズムに関するものになります。すなわち、NISTが承認しているアルゴリズムを採用し、かつ規格書どおりに実装することが求められます。古くなったDESアルゴリズムや、短い鍵長のRSAなどは利用することができません。
    
  • FIPS140認証取得の前提条件として、前回お話した「CAVP」(Cryptographic Algorithm Validation Program)が存在します。ここでは、暗号モジュールに搭載されるアルゴリズムが承認された規格書どおりに動作していることを、入出力されるメッセージ・パラメータだけでなく、アルゴリズムが必要とする数学的な内部パラメータを含めてテストされる必要があり、別途証明書が発行されます。2020年7月から、このテストは「ACVTS」(Automated Cryptographic Validation Testing System)と呼ばれる新しいオンライン形式へと移行しています。

• 不正な操作や使用から暗号モジュールを保護する。
• 致命的なセキュリティパラメータ・CSP（Critical Security Parameters）を含む、暗号モジュール内部のコンテンツの不正な流出を防止する。
• 機密性の高いセキュリティパラメータ・SSP（Sensitive Security Parameters）の不正な変更・置換・挿入、および削除を含む、暗号モジュールと暗号アルゴリズムの不正な不可知の改変を防ぐ。
  • 注：CSP(critical security parameters) + PCP(public security parameters) = SSP(sensitive security parameters)
    
  • 上記は、暗号モジュールに対しては至極当たり前の目標ですが、これを如何に具体的な要件に落とし込むかは、それほど簡単なことではありません。要件は、モジュールのセキュリティ境界の定義、外部接続ポート定義の明確化、権限者ごとの正当な機能定義の明確化といった、必ずやるべきことを、具体性と汎用性のバランスを保ちながら積み上げています。 FIPS140は、内部コンテンツの不正な流出に関して、かなり厳格な立ち位置をとっており、次回解説する「ゼロ化」という要件が盛り込まれています。

• 暗号モジュールの動作状態を示すインジケータを提供する。
• 承認された動作モードで動作している時に、暗号モジュールが適切に動作することを確実にする。
• モジュールの動作エラーを検出し、これらのエラーに起因するSSPの危殆化を防止する。
  
  • 暗号モジュールが内部コンテンツを適切に保護するには、暗号モジュールが正常に動作していることが担保され、またオペレーションの観点からは、ユーザーおよびアプリケーションが暗号モジュールの状態を把握できる必要があります。不完全な状態で動作が継続することは、攻撃者に不要な足がかりを与えることとなってしまいます。FIPS140では、次回解説しますが、セルフテストが要件とされ、モジュールの正常動作を担保する工夫が盛り込まれています。

• 暗号モジュールの適切な設計、配布及び実装を確実にする。
  
  • 最後の「暗号モジュールの適切な設計、配布及び実装を明確に」はFIPS140-3であらたに掲げられた目標で140-2にはなかったものになります。これに対応してセキュリティ要件項目にLife-Cycle Assuranceという項目が新たに設けられモジュール開発段階から文書化や管理が求められています。対応するセキュリティレベルに応じ、例えば開発時においては、ソースコードへの注釈の記載が求められ、また高いセキュリティレベルでは配備された後の稼働時において、ベンダー提供の認証情報を用いてオペレーター認証を行うことなど、広範囲に規定が設けられています。

今回はここまでです。
次回は、FIPS140の具体的な内容について、その特徴や、セキュリティ機能の目標、認証取得のチャレンジなどについて解説します。

---

ここまでの「FIPS140最前線」の記事はこちらよりお読みください。

最新の「FIPS140最前線」記事はメールマガジンにてご案内致します。是非JAPANSecuritySummit Updateのメールマガジンにご登録ください。
メールマガジンの登録はこちらからお願いします。