CerticomとQNXによるセキュリティ認証要件の達成

このホワイト ペーパーでは、FIPS 140-2検証プロセスに関連するいくつかの主要な課題を検討し、QNX® Neutrino® RTOSとCerticom Security Builder Government Security Edition (GSE) 暗号化ライブラリが、FIPS 140-2準拠ソフトウェアの構築と配信の負担を軽減するのにどのように役立つかについて説明します。 

COTSとセキュリティ

他の組織と同様に、政府機関も、競合ベンダーが提供する専門知識とコスト削減を活用するために、市販の既製 (COTS) 製品を使用したいと考えています。ただし、これらの機関が使用するには、これらのCOTSベンダーの製品が、米国では国防総省 (DoD)、国家安全保障局 (NSA)、国立標準技術研究所 (NIST) などの組織によって定められた厳格なセキュリティ要件を満たしている必要があります。FIPS 140-2は、最も重要なコンピュータ セキュリティ指令の共通基準です。たとえば、国防総省は、機密データの通信を管理する指令でこの標準を参照しています4。

医療および金融サービス部門も、特に個人を特定できる情報の開示件数が急増していることから、同様に情報セキュリティ要件の影響を受けています。これらの業界のデータ セキュリティ要件は、医療提供者に対する医療保険の携行性と責任に関する法律 (HIPAA) や経済的および臨床的健全性のための医療情報技術 (HITECH) 法、銀行や金融会社に対する消費者プライバシーに関するグラム・リーチ・ブライリー法 (GLBA) 規則などの政府法によって推進されています。これらの要件により、ベンダーは暗号化とデータ セキュリティに関するガイダンスとしてFIPS 140-2に自然に従うことになります。

HIPAA規制では、「移動中のデータに対する有効な暗号化プロセスは、連邦情報処理標準 (FIPS) 140-2の要件に準拠したものである」と規定されています。5この同じ文書では、保存中のデータはNIST特別出版物800-1116に従って保護する必要があると規定されており、FIPS認定の暗号化アルゴリズムの使用が推奨されています。さらに、HITECH法は、FIPS認定製品を使用する組織に監査の軽減を提供することで、実績のあるセキュリティ テクノロジの使用を促進します。

ただし、FIPS 140-2の重要性はここで終わりません。ガスパイプライン配給やスマートグリッド制御システムなどの重要なインフラストラクチャ システムのネットワーク化が進むにつれて、これらの業界では転送中のデータを保護するために使用される暗号化に対して同様に厳格な制御が採用される可能性が高く、FIPS認定の暗号化ソリューションに対する需要が高まります。

この成長する市場のより大きな部分を獲得するために、あるいは現在の地位を維持するために、従来は高度なセキュリティの専門知識を必要としなかったCOTSベンダーは、 

進化するFIPS要件を注意深く監視しながら、現在のセキュリティ標準と暗号化テクノロジ、および開発中のセキュリティ標準と暗号化テクノロジに関する理解を深める以外に選択肢はありません。また、組み込みシステムでこれらの要件をサポートするという大きな課題に対処する方法も見つけなければなりません。

強固な基盤

安全なシステムの基本要件は、信頼できるOS上で実行されることです。信頼性の保証を提供できないOS上に安全なシステムを構築することは、土の床に銀行の金庫室を建てることと非常に似ています。やがて誰かがこの根本的な弱点に気づき、それを悪用するでしょう。

QNX Neutrino RTOSがCerticomのGSE暗号化ライブラリに最適なOSである主な特徴は次のとおりです。

リアルタイムの信頼性の保証: リアルタイム オペレーティング システム (RTOS) のみが、要求に対してタイムリーに正確かつ予測通りに応答する必要があるシステム専用に設計されています7。

マイクロカーネル アーキテクチャ: QNX Neutrino RTOSのマイクロカーネル アーキテクチャでは、アプリケーション、デバイス ドライバー、ファイル システム、およびネットワーク スタックはすべてカーネルの外部の個別のアドレス空間に存在するため、カーネルからも互いからも分離されます。1つのコンポーネントに障害が発生してもシステム全体が停止することはなく、回復メカニズムによって障害が発生したプロセスを再起動できます。

プリエンプティブな低優先度カーネル呼び出し: リアルタイムのコミットメントを満たすために、QNX Neutrino RTOSでは、低優先度カーネル呼び出しを高優先度プロセスでプリエンプトできます。プリエンプションが発生しない時間枠は非常に短いです。さらに、プリエンプションが保留され、割り込みが無効になる時間には上限があり、開発者は最悪の場合のレイテンシを確認できます。

優先度の継承: QNX Neutrino RTOSは優先度の継承を実装しています。これは、ブロックされた高優先度タスクの優先度を、ブロックしているタスクが完了するまで、ブロックしている低優先度スレッドに割り当てることで、優先度の逆転 (1997年7月にMars Pathfinderプロジェクトを悩ませた悪名高い問題) を防ぐ手法です。

アダプティブ パーティショニング: QNX Neutrino RTOSは、アダプティブ パーティショニングを使用して、プロセスまたはスレッドがCPUサイクルを独占し、他のプロセッサまたはスレッドが不足するのを防ぎます。アダプティブ パーティショニングを使用すると、開発者はプロセスとスレッドに保証されたCPU時間の予算を割り当てることができ、動的スケジューリング アルゴリズムによって、CPUサイクルが、使用されていないパーティションから追加の処理時間の恩恵を受けることができるパーティションに動的に再割り当てされます。パーティション バジェットは、CPUが最大容量まで実行されている場合にのみ適用されます。利用可能なサイクルは必要に応じてすべて使用されますが、複数のパーティション内のプロセスがサイクルを競合する場合、パーティション分割によってリソース予算が強制され、リソース不足が防止されます。 

高可用性フレームワーク: 完全に障害のないシステムはありません。継続的な可用性を確保するために、QNX Neutrino RTOSは、プロセスの障害を監視するウォッチドッグ、再起動せずに障害が発生したプロセスを再開する自動メカニズム、必要に応じてウォッチドッグの役割を引き継ぐために常に待機しているミラー プロセス、およびシステム設計者がウォッチドッグが特定の障害にどのように対応するかを決定できるプログラミング インターフェイスを含む高可用性フレームワークをサポートします。

マルチプロセッサ機能: 移行中および移行後の安定性とマルチコア システムでの効率性の両方を確保するために、QNX Neutrino RTOSは、開発者がスレッドの実行マスク継承を指定できるようにするプロセッサ アフィニティ (またはスレッド アフィニティ) のQNX固有の拡張であるバウンド マルチプロセッシング (BMP) を使用します。BMPは、開発者が特定のコアに対して指定されたスレッドだけでなくその子スレッドも制限する実行マスクを設定できるようにすることで、マルチコアに移行したシステムを、シングルコア プロセッサ用に記述されたコードをマルチコア システム上で信頼できないものにするFIFOスケジューリングなどの潜在的なバグや設計機能から保護するのに役立ちます。また、対称型マルチコア処理によく伴うキャッシュ スラッシングなどの問題の解決にも役立ちます。システムをマルチコアに移行する開発者は、スレッド階層全体を単一のプロセッサにバインドして、新しい環境で不快な驚きが生じないようにすることができます。

140-2の認証

米国では、政府のセキュリティ要件はFIPS出版物によって規制されています。NISTは、すべての政府機関で使用するためにこれらの出版物を開発しています。連邦政府から新しいセキュリティおよび相互運用性の標準に対する強い要求がある場合、新しいFIPS出版物を開発して発行します。

FIPS 140-2は、機密扱いではないが機密扱いではない用途でソフトウェアおよびハードウェア製品が満たす必要がある米国連邦政府の暗号化要件を規定しています。FIPS 140-2は、指定された暗号化機能を実行するためにアプリケーションが使用する必要がある完全なモジュールの検証を指します。下記の「FIPS検証」を参照してください。楕円曲線デジタル署名アルゴリズム (ECDSA) の使用を規定するFIPS 186-2や、Advanced Encryption Standard (AES) を規定するFIPS 197などのその他のFIPSは、FIPS 140-2検証済みモジュールに含まれる暗号化アルゴリズムの特定の実装です。

2002年、連邦情報セキュリティ管理法 (FISMA) により、政府機関がFIPS非承認製品の購入に対して免除を発行することを許可する条項が削除されました。この削除により、今後は暗号化を実装し、米国連邦政府に販売されるすべての製品に対してFIPS 140-2検証が必須となりました。FIPS 140-2の検証がなければ、製品は米国政府の顧客には考慮されません。さらに、米国以外では、英国やカナダ（通信保安機構 (CSE) を通じて）などの国々が、セキュリティ要件としてFIPS 140-2を採用しています。

同様に、医療および金融分野のアプリケーションではFIPS検証が必ずしも必要ではありませんが、それでも必須となることがよくあります。たとえば、患者データを転送するためにワイヤレス技術が導入されている米国政府施設の医療設備では、この技術が必須となっています。FIPS検証が明示的に要求されていない場合でも、データのセキュリティが必要な場合はFIPS検証を強くお勧めします。つまり、FIPS認定製品はこれらの市場で競争上の優位性を獲得します。 

FIPS 140-2検証

ほとんどのベンダーでは、FIPS検証には2つのレベルがあります。最初のレベルでは、FIPS 186-2やFIPS 197で参照されているような特定のアルゴリズムで使用される暗号化手法を検証します。これらのアルゴリズムには、AES、DES、3DES、RSAなどの対称暗号化アルゴリズム、SHA-1などのハッシュ アルゴリズム、RSAやECDSAなどのデジタル署名が含まれます。FIPSでは、これらのアルゴリズムがどのように定義され、検証を実現するためにどのように実装する必要があるかが指定されています。NISTの暗号化アルゴリズム検証プログラム (CAVP) がこれらの検証を実行します。

2番目の、より高レベルでより重要な検証はFIPS 140-2です。この規格では、安全なシステム内で実行される暗号化モジュールがシステム内の情報を保護するために満たす必要のある11のセキュリティ領域が指定されています。この暗号化モジュールは、ハードウェア、ファームウェア、またはソフトウェアのいずれかになります。使用されるシステムのセキュリティ サービスに対する責任を負い、暗号化、認証、乱数生成などの暗号化機能を実行します。 

FIPS 140-2では、指定する11のセキュリティ領域ごとに1から4までの4つのセキュリティ レベル (4が最も安全) を定義し、セキュリティ モジュールに単一の総合評価を割り当てます。これらのレベルの詳細については、Certicomのアプリケーション ノート「Certicom Security for Government Suppliers」(www.certicom.com/fips) を参照してください。

FIPS 140-2認証を受けるには、暗号化モジュールは次の要件を満たす必要があります。

•  明確に定義された暗号境界を持ち、すべての機密セキュリティ情報が製品の暗号コア内に留まるようにする

•  正しく実装され、暗号境界が損なわれていないFIPS承認アルゴリズムを少なくとも1つ使用する

  アルゴリズムまたはFIPS 140-2暗号化モジュールを検証するプロセスの概要は、上の図1に示されています。FIPSモジュールで使用される少なくとも1つのアルゴリズムは、 CMVPを通じてFIPS 140-2検証プロセスに入る前に、CAVPによって検証される必要があります。その後、FIPSモジュール全体を、CAVPと同様にNISTによって運営されている暗号モジュール検証プログラム (CMVP) を通じて検証する必要があります。CMVPに基づくすべてのテストは、National Voluntary Laboratory Accreditation Program (NVLAP) に基づいて認定された暗号モジュール テスト (CMT) ラボの1つによって実施されます。 

  市場参入障壁と課題

  政府市場は魅力的で収益性が高いものの、多くのベンダーにとってFIPS検証プロセスは参入の大きな障壁となります。政府機関（あるいは多くの医療機関や金融機関）に販売したいと考えているベンダーが利用できる選択肢は限られています。製品をゼロから構築するか、商用ベンダーからFIPS-140-2認定の暗号化モジュールを購入するかのどちらかです。

  構築を検討している人は、検証プロセスには8 ～ 12か月かかり、複数の開発者の関与が必要であり、最初の検証コストだけで約50,000ドルかかることに留意する必要があります。この初期費用に、同じモジュールを後続で提出するたびに10,000 ～ 15,000ドルのコスト (更新、バグ修正、初期エラーの修正など) を追加する必要があります。したがって、開発コストを考慮すると、モジュール検証には簡単に10万ドル以上かかります。

  また、暗号化ソフトウェア モジュールを検証のために提出する場合、ベンダーは、セキュリティ ポリシー、有限状態マシン、ソフトウェア モジュールの説明、暗号化境界内のすべてのソフトウェアのソース コード リスト、モジュールの役割とサービスの説明、キー管理ライフサイクルの説明、およびアルゴリズム適合証明書などのドキュメントを提供する必要があることにも注意してください。検証はプラットフォーム固有であり、プラットフォームごとに個別の検証証明書番号が必要です。さらに、検証済みの製品に変更や追加を加えると、その製品に新たな検証サイクルが課せられ、追加コストも発生します。

  さらに、FIPS 140-2標準に準拠した暗号化モジュールの構築は複雑なだけでなく、失敗率も高くなります。NISTによれば、新規申請者が提出した暗号モジュールの48% と、返却された申請者のモジュールの20% にセキュリティ上の欠陥が含まれています。NISTによってテストされたアルゴリズムの30% がFIPS標準に準拠していません9。この失敗率は、企業がFIPS検証を必要とするソリューションの開発にかなりの時間と費用を費やし、それを最長1年かかるテスト プロセスに提出した結果、ソリューションに欠陥があり、さらなる作業と費用をかけなければFIPS検証ができないことが判明する可能性があることを示しています。

  最後に、FIPS検証のコストは、製品が最初の検証を受けた時点で終了するわけではありません。進化するセキュリティ標準と業界のトレンドを監視するには社内の専門知識が必要です。これにより、市場の需要を満たすために製品に変更を加えたり、新しいFIPS要件に対応したりする必要が生じる可能性があります。FIPS 140-2標準は5年ごとに更新され、標準の改善、業界のトレンドへの適合、より堅牢な標準となるように新しいアルゴリズムが追加されます。FIPS標準が変更されても既存の検証は有効なままですが、ベンダーが標準の新しいアルゴリズムを利用したい場合は、製品を更新して再度検証のために送信する必要があります。

  ベンダーは、独自の暗号モジュールを構築する代わりに、事前に検証された暗号モジュールを購入し、それを自社の製品に組み込むことができます。 

  製品。このアプローチの利点には、検証プロセスを完全にバイパスしながらのFIPS 140-2検証、最小限の開発コスト、市場投入までの時間の短縮、コア コンピテンシーに重点を置いた開発努力などがあります。以下の考慮事項は、暗号モジュールの正しい選択に役立ちます。

  拡張可能なアーキテクチャ: 共通APIを提供するプラットフォームにより、最小限のコード書き換えで新しいアルゴリズムやセキュリティ プロトコルをサポートしやすくなります。

  更新の柔軟性: 事前検証済みのモジュールを使用すると、製品ベンダーは製品またはソリューションに変更を加え、セキュリティのために同じモジュールを再利用することでFIPS検証を維持できます。FIPSモジュール サプライヤーは、FIPS標準の監視、モジュールへの変更、更新されたモジュールの検証の責任を負います。製品ベンダーは、FIPS検証を維持するために、製品内のFIPSモジュールを交換するだけで済みます。

  プラットフォームの柔軟性: 複数のシステム プラットフォームでFIPS 140-2検証が必要な場合、FIPSモジュール サプライヤーは、必要なすべてのプラットフォームに対して検証済みのセキュリティ モジュールを提供する必要があります。

  リソース制約: リソースが制限されたデバイス向けに特別に設計されたFIPS検証済みモジュールを使用すると、CPU帯域幅とメモリ要件が削減され、システム パフォーマンスが大幅に向上します。この利点は、バッテリー寿命が大きな懸念事項となるモバイル デバイスでは特に当てはまります。

  結論

  FIPS認定製品の開発に伴う障壁と利点を考慮すると、製品を迅速かつ最小限のリスクで市場に投入できる信頼性の高いFIPS実装を見つけることが、成功と失敗の違いを意味する可能性があります。

  QNX Software SystemsとCerticomは提携して、開発者がCerticomのSecurity Builder GSE FIPS検証済み暗号化ライブラリを簡単かつコスト効率よく活用できるようにする共有オブジェクト モジュール ライブラリを提供しています。このソリューションにより、デバイス メーカーや独立系ソフトウェア ベンダーは、実績のあるRTOS基盤上でFIPS 140-2セキュリティ認定テクノロジを使用したソリューションを顧客に提供できるようになります。