作成者：JenniferBradyとApurvaVaralikar

これまでに、計画されているFIPS 140-3移行の予想されるタイムラインを示しました（キーFIPS 1 40-3日付）、および知っておく必要のある主要な用語と定義（パート1：主要な用語と定義）。今日、私たちのブログシリーズはFIPS140-2とFIPS140-3の違いを続けています。この投稿では、ISO / IEC 1970 / ISO / IEC 24759（FIPS 140-3と呼びます）の個々のセクションを取り上げ、それらがFIPS140-2標準および現在のIGのセクションにどのようにマッピングされて異なるかを特定します。 。この投稿では、FIPS 140-2と関連するIGの最初の3つのセクション、およびISO / IEC 19790のセクション7.2-7.4、つまり、それぞれ暗号化モジュールの仕様、暗号化モジュールのインターフェイスと役割、およびサービスと認証のセクションに焦点を当てます。

暗号化モジュールの仕様

暗号化モジュールの種類/暗号化境界

FIPS 140-2標準（2001年発行）は、元々、すべてのモジュールがハードウェアモジュールでした。さまざまなタイプのモジュール（ハイブリッド、ソフトウェア、およびファームウェア）がIGに追加され、定義されたのは後になってからでした（IG 1.9、1.16、および1.17）。さらに、FIPS 140-2 IG1.9はハイブリッドモジュールをFIPS140-2レベル1検証に制限しました。

FIPS140-3には、ハードウェアモジュール、ファームウェアモジュール、ソフトウェアモジュール、ハイブリッドソフトウェアモジュール、およびハイブリッドファームウェアモジュール。これは、規格のセクション7.2.2で各タイプのモジュールを明示的に定義しています。新しい規格でハイブリッドモジュールを検証できるレベルについても制限はありません。これは、レベル1よりも高いレベルでの検証を検討しているハイブリッドモジュールを使用しているベンダーにとって朗報です！

動作モード

2つの新しい用語。 「通常の操作」と「劣化した操作」はFIPS140-3 19790で導入され、前のブログに記載されています。

通常の操作では、暗号化モジュールの完全な機能を利用できるか、構成可能です。つまり、すべてのアルゴリズム、セキュリティ機能、およびサービス。

劣化した操作とは、エラー状態からの再構成の結果として、機能のサブセットが使用可能または構成可能である場所です。

モジュールが劣化した操作をサポートしている場合、劣化した操作動作モードに入ることができるのは、モジュールがエラー状態を終了したときだけです。どういう意味ですか？メカニズムまたは機能に障害が発生し、モジュールがエラー状態になり、エラーインジケータを出力しました。一度エラー状態になると、この劣化した動作をサポートするモジュールは、動作の劣化モードに移行し、機能の低下した動作を継続することができます。新しい標準に向けてモジュールを準備するときに覚えておく必要のある追加の要件がいくつかあります。モジュールは、劣化動作モードに入るときにステータス情報を提供する必要があり、失敗した機能を分離する必要があります。劣化モードで暗号化機能を使用する前に、すべての条件付きセルフテストを実行する必要があります。劣化した操作モードで、非操作アルゴリズム、セキュリティ機能、またはプロセスを使用しようとした場合。サービスは、そのような試みが行われたことを示す必要があります。

ープFIPS 140-3に記載されているように、劣化した操作に関する追加のコメントが1つあります。セクション7.2.4.3の最後の文は、「モジュールが操作前のセルフテストに失敗した場合、モジュールは劣化した操作に移行してはならない」と述べています。ちょっと待ってください、セルフテストなどが失敗したときに劣化操作を使用するつもりだったのですが、ここでは入力できないと言っていますか？エラー状態からのみ劣化モードに入ることができます。 、モジュールは最初にエラー状態に入り、次に劣化した動作に入る必要がありますが、上記で説明した他の要件も満たします。

追加の概念

SPに注意してくださいISO 19790：2012 / ISO 24759：2014規格で扱われなかったFIPS140-2のIGが特別刊行物の1つで扱われているかどうかを確認するためにCMVPが今後数か月にわたってリリースする800-140ドキュメント。セクション1は、WebベースのCMVP管理マニュアルに夢中になり、他のセクションは引き続きIGとして扱われる可能性があります。

暗号化モジュールインターフェイス

前のブログでは、インターフェイスの種類について触れました。 ISOドキュメントで紹介されています（HMI：ハードウェアモジュールインターフェイス、SFMI：ソフトウェアまたはファームウェアモジュールインターフェイス、HSMI ：ハイブリッドソフトウェアモジュールインターフェイスまたはHFMI：ハイブリッドファームウェアモジュールインターフェイス）なので、現時点ではそれらについては説明しません。代わりに、入力インターフェイスと出力インターフェイスについて説明します。

従来のインターフェイスと新しいインターフェイス

FIPS140-2とFIPS140-3の両方に、4つの論理インターフェイスのデータ入力、データ出力、制御入力、およびステータス出力が含まれています。 FIPS 140-3は、制御出力インタフェースと呼ばれる5つ目のインタフェースを導入している。制御出力インタフェースは、コマンドの出力に使用される。信号と制御データは、動作状態を制御または示すために使用される。この制御出力は、他の暗号モジュールに送られる情報かもしれない。電源インターフェイスは、ソフトウェアモジュールを除くすべてのモジュールで必要なインターフェイスでもあります。

信頼できるチャネル

FIPS 140-3で導入された別の概念は、「信頼できるチャネル」の概念です。 「信頼できるパス」のFIPS140-2の概念（セクション4.7.4およびIG 2.1）に似ています。これは、暗号化モジュールと、モジュールとの間でデータを送受信するエンドポイントデバイス間の安全な通信リンクであり、保護されていないCSPを保護することを目的としています。

FIPS 140-2IGと同様です。 2.1、FIPS140-3のセキュリティレベル1および2に信頼できるチャネルを使用するための要件はありません。 FIPS 140-3は、モジュールと送信者/受信者の間で送信されるときに信頼されたチャネルを使用する必要がある、保護されていないプレーンテキストCSP、鍵コンポーネント、および認証データのような、セキュリティレベル3と4にいくつかの要求を持っている。信頼されたチャネルは、不正な変更、置換、および開示を防止する必要がある。信頼できるチャネルを使用するサービスは、IDベースの認証を採用する必要があり、モジュールは、信頼できるチャネルを使用するときにステータスインジケータを提供する必要があります。

FIPS 140-3は、信頼できるチャネルを使用するモジュールに追加の要件を以前のFIPS140-2またはIG2.1では見られなかったセキュリティレベル4。信頼できるチャネルを使用するレベル4モジュールは、信頼できるチャネルを使用するすべてのサービスに対して、多要素IDベースの認証を使用する必要があります。

役割、サービス、および認証

役割

FIPS 140-2標準（セクション4.3.1）では、モジュールが暗号担当者の役割とユーザーの役割の両方をサポートする必要があり、保守の役割のサポートはオプションでした。 FIPS 140-3はまだこれら3つのロールを持っていますが、暗号オフィサーの役割のみが要求されています（セクション7.4.2）。ユーザーロールとメンテナンスロールはオプションになりました。

サービス

必要なサービス

FIPS 140-2標準には、次の3つの必要なサービスがあります。ステータスの表示、セルフテストを実行し、承認されたセキュリティ機能を実行します（セクション4.3.2）。 FIPS 140-3では、これらの同じ3つのサービスに加えて、2つの追加の必須サービスが必要です。モジュールのバージョン情報を表示し、ゼロ化を実行します（セクション7.4.3.1）。 「showmodule’s versioning information」では、暗号化モジュールがモジュール名/識別子とバージョン情報を出力する必要があります。これらは検証証明書と照合して検証できます。ゼロ化サービスの仕様はセクション7.9.7で定義されており、将来のブログ。

バイパスサービス

FIPS140-2とFIPS140-3の両方に、オプションのバイパスサービスが含まれています。FIPS140-3は、バイパスを構成できるオペレーターに特に呼びかけています。モジュールの機能は許可された役割を引き受ける必要があります。FIPS140-2標準はその要件を具体的に述べていませんが、サービスを使用してCSPを開示したり、保護された情報のセキュリティに影響を与えたりする可能性があるため、許可された役割に対するほとんどの想定認証が必要でしたモジュール（IG 3.1）による。

自己開始暗号化出力

FIPS 140-3で扱われる新しい機能は、「自己開始暗号化出力機能」です。ここで、モジュールは、オペレーターの介入なしに、暗号化操作またはその他の承認されたセキュリティ機能を実行できます。 Crypt-Officerはこの機能を構成できますが、この構成は再起動後も保持される場合があります。サービスをアクティブ化するには2つの内部アクションが必要であり、モジュールはサービスがアクティブ化されていることを示す必要があります。

ソフトウェア/ファームウェアのロード

ソフトウェア/ファームウェアのロードはFIPS140-2で対処されています標準、およびIG 9.7では、ソフトウェア/ファームウェアをロードするときに必要なセルフテストのコンテキストで。 FIPS 140-2は、FIPS 140-3（セクション7.4.3.4）に見られるように、サービスとしては扱いません。ドキュメントに記載されている要件の一部には、モジュールが検証済みモジュールのままであるために、ロードされるソフトウェア/ファームウェアが検証機関によって検証される必要があることが含まれます。ここでは、ソフトウェア/ファームウェアが正常に完了するまで、すべてのデータ出力を禁止する必要があります。コードを実行する前に、ソフトウェア/ファームウェアの負荷テストを実行する必要があります。モジュールは、操作前のセルフテストが正常に実行されるまで、ロードされたコードを実行しないものとします。最後に重要なこととして、モジュールのバージョン情報は、ソフトウェア/ファームウェアの追加/更新を反映するように更新する必要があります。

追加コメント

認証されていないサービスはFIPS140-3で明示的に対処されていないため、現在のIG3.1で対処されているこの概念が引き継がれているかどうかを確認する必要があります。 SP800-140ドキュメントのいずれかに。これについては、今後のブログで詳しく説明します。

認証

FIPS 140-3は、セキュリティレベル1〜3での認証についてはFIPS 140-2に似ています：（ISO 19790：レベル1-認証要件なし、レベル2 –最小の役割ベースの認証、レベル3 – IDベースの認証）。最大の違いは、レベル2では、「最小」という単語が追加されたことです。これは、IG 3.4で対処されている説明に対応しています。ISOベースのFIPS140-3標準のレベル4認証では、認証が使用されます。 IDベースの認証を要求するだけでなく、レベル。レベル4の認証の場合、多要素IDベースである必要があります。

このセクションで注意すべき追加の項目は、FIPS140-2です。モジュールに必要な認証の強度を指定しました。強度はFIPS140-3で定義されていませんが、モジュールのセキュリティポリシーで指定する必要があります。ほとんどの場合、各検証機関は追加のドキュメントに認証の強度を含めます。

承認された認証メカニズムは、文書化された手順やセキュリティルール（ポリシーなど）では実装できません。つまり、モジュールでパスワードサイズの制限を構成して適用する必要があります。これは、現在のモジュールのいくつかの動作に影響を与える可能性があります。 、モジュールをISO要件に合わせて準備するときは、このことに注意してください。

要するに

FIPS140-2とFIPS140-3の違いについて学ぶことはたくさんあります。無数の類似点がありますが、かなりの数の変更もあります。このテーマに関する私たちのシリーズは継続され、各投稿で新しい領域に取り組みます。ご不明な点がございましたら、お気軽に直接お問い合わせください。私たちのチームはいつでもお手伝いします。