GKIカーネルには、暗号化ソフトウェアモジュールのFIPS140-3要件に準拠するfips140.ko
と呼ばれるLinuxカーネルモジュールが含まれています。このモジュールは、GKIカーネルを実行している製品で必要な場合、FIPS認定のために提出できます。
暗号化ルーチンを使用する前に、特に次のFIPS140-3要件を満たす必要があります。
- モジュールは、暗号化アルゴリズムを使用可能にする前に、自身の整合性をチェックする必要があります。
- モジュールは、承認された暗号化アルゴリズムを使用可能にする前に、既知の回答のセルフテストを使用して実行および検証する必要があります。
なぜ別のカーネルモジュールなのか
FIPS 140-3の検証は、ソフトウェアまたはハードウェアベースのモジュールが認定されると、変更されることはないという考えに基づいています。変更された場合は、再認定する必要があります。これは、現在使用されているソフトウェア開発プロセスとは容易に一致しません。この要件の結果として、FIPSソフトウェアモジュールは通常、暗号化に関連しない変更が行われるように、暗号化コンポーネントに可能な限り厳密に焦点を当てるように設計されています。暗号化の再評価は必要ありません。
GKIカーネルは、サポートされている存続期間全体にわたって定期的に更新されることを目的としています。これにより、カーネル全体がFIPSモジュールの境界内にあることは不可能になります。そのようなモジュールは、カーネルが更新されるたびに再認証される必要があるためです。また、LTOは重要なセキュリティ機能であるCFIの前提条件であるため、GKIはLTO(Link Time Optimization)を有効にしてコンパイルされます。これにより、カーネルの暗号コードだけの周りにFIPSモジュールの境界を描くことができなくなります。これは、そのようなコードが、結果のバイナリで明確に定義された場所にないためです。カーネルの更新により、暗号コードも変更される場合があります。
したがって、FIPS 140-3要件の対象となるすべてのコードは、別のカーネルモジュールfips140.ko
にパッケージ化されます。このモジュールは、ビルド元のGKIカーネルソースによって公開された安定したインターフェイスのみに依存します。これにより、モジュールを同じ世代の異なるGKIリリースで使用できることが保証され、モジュール自体によって運ばれるコードで問題が修正された場合にのみ、モジュールを更新して認証のために再送信する必要があります。
モジュールを使用する場合
GKIカーネル自体は、FIPS140-3カーネルモジュールにもパッケージ化されている暗号ルーチンに依存するコードを伝送します。したがって、組み込みの暗号ルーチンは実際にはGKIカーネルから移動されるのではなく、モジュールにコピーされます。モジュールがロードされると、組み込みの暗号ルーチンはLinux CryptoAPIから登録解除され、モジュールによって運ばれるものに取って代わられます。
これは、 fips140.ko
モジュールが完全にオプションであり、FIPS140-3認定が要件である場合にのみ展開することが理にかなっていることを意味します。それを超えると、モジュールは追加機能を提供せず、モジュールを不必要にロードすると、起動時間に影響を与えるだけで、メリットはありません。
モジュールを展開する方法
このモジュールは、次の手順を使用してAndroidビルドに組み込むことができます。
- モジュール名を
BOARD_VENDOR_RAMDISK_KERNEL_MODULES
に追加します。これにより、モジュールがベンダーのRAMディスクにコピーされます。 - モジュール名を
BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD
に追加します。これにより、モジュール名がターゲットのmodules.load
に追加されます。modules.load
は、デバイスの起動時にinit
によってロードされるモジュールのリストを保持します。
整合性セルフチェック
FIPS 140-3カーネルモジュールは、モジュールのロード時に独自の.code
と.rodata
セクションのHMAC-SHA256ダイジェストを取得し、モジュールに記録されたダイジェストと比較します。これは、LinuxモジュールローダーがELF再配置処理や、これらのセクションへのCPUエラッタの代替パッチなどの通常の変更をすでに行った後に行われます。ダイジェストを正しく再現できるようにするために、次の追加手順が実行されます。
- ELFの再配置はモジュール内に保持されるため、HMACの入力とは逆に適用できます。
- 静的キー、したがってトレースポイントやベンダーフックなど、他のすべてのコードパッチはモジュールに対して無効になっています。
既知の回答のセルフテスト
FIPS 140-3要件の対象となる実装済みアルゴリズムは、使用する前に既知の回答のセルフテストを実行する必要があります。 FIPS 140-3実装ガイダンス10.3.Aによると、暗号化と復号化の両方がテストされている限り、サポートされているキー長のいずれかを使用するアルゴリズムごとに1つのテストベクトルで十分です。
Linux CryptoAPIにはアルゴリズムの優先順位の概念があり、同じアルゴリズムの複数の実装(特別な暗号命令を使用するものや、それらの命令を実装しないCPUのフォールバックなど)が共存する場合があります。したがって、同じアルゴリズムのすべての実装をテストする必要があります。これが必要なのは、Linux CryptoAPIでは優先度ベースの選択を回避し、代わりに優先度の低いアルゴリズムを選択できるためです。
モジュールに含まれるアルゴリズム
android13-5.10ソースから構築されたときにFIPS140-3モジュールに含まれるすべてのアルゴリズムは、次のとおりです。
アルゴリズム | 実装 | 承認可能 | 意味 |
---|---|---|---|
aes | aes-generic 、 aes-arm64 、 aes-ce 、AESライブラリ | はい | 動作モードのないプレーンAESブロック暗号:すべてのキーサイズ(128ビット、192ビット、および256ビット)がサポートされています。ライブラリ実装以外のすべての実装は、テンプレートを介した操作モードで構成できます。 |
cmac(aes) | cmac (テンプレート)、 cmac-aes-neon 、 cmac-aes-ce | はい | AES-CMAC:すべてのAESキーサイズがサポートされています。 cmac テンプレートは、 cmac(<aes-impl>) を使用したaes の任意の実装で構成できます。他の実装はスタンドアロンです。 |
ecb(aes) | ecb (テンプレート)、 ecb-aes-neon 、 ecb-aes-neonbs 、 ecb-aes-ce | はい | AES-ECB:すべてのAESキーサイズがサポートされています。 ecb テンプレートは、 ecb(<aes-impl>) を使用してaes の任意の実装で構成できます。他の実装はスタンドアロンです。 |
cbc(aes) | cbc (テンプレート)、 cbc-aes-neon 、 cbc-aes-neonbs 、 cbc-aes-ce | はい | AES-CBC:すべてのAESキーサイズがサポートされています。 cbc テンプレートは、 ctr(<aes-impl>) を使用してaes の任意の実装で構成できます。他の実装はスタンドアロンです。 |
cts(cbc(aes)) | cts (テンプレート)、 cts-cbc-aes-neon 、 cts-cbc-aes-ce | はい | 暗号文を盗むAES-CBC-CTSまたはAES-CBC:使用される規則はCS3 です。最後の2つの暗号文ブロックは無条件に交換されます。すべてのAESキーサイズがサポートされています。 cts テンプレートは、 cts(<cbc(aes)-impl>) を使用してcbc の任意の実装で構成できます。他の実装はスタンドアロンです。 |
ctr(aes) | ctr (テンプレート)、 ctr-aes-neon 、 ctr-aes-neonbs 、 ctr-aes-ce | はい | AES-CTR:すべてのAESキーサイズがサポートされています。 ctr テンプレートは、 ctr(<aes-impl>) を使用してaes の任意の実装で構成できます。他の実装はスタンドアロンです。 |
xts(aes) | xts (テンプレート)、 xts-aes-neon 、 xts-aes-neonbs 、 xts-aes-ce | はい | AES-XTS:すべてのAESキーサイズがサポートされています。 xts テンプレートは、 xts(<ecb(aes)-impl>) を使用してecb ecb(aes) の任意の実装で構成できます。他の実装はスタンドアロンです。すべての実装は、FIPSに必要な弱鍵チェックを実装しています。つまり、前半と後半が等しいXTSキーは拒否されます。 |
gcm(aes) | gcm (テンプレート)、 gcm-aes-ce | いいえ1 | AES-GCM:すべてのAESキーサイズがサポートされています。 96ビットIVのみがサポートされています。このモジュールの他のすべてのAESモードと同様に、呼び出し元はIVを提供する責任があります。 gcm テンプレートは、 gcm_base(<ctr(aes)-impl>,<ghash-impl>) を使用して、 ctr(aes) およびghash の任意の実装で構成できます。他の実装はスタンドアロンです。 |
sha1 | sha1-generic 、 sha1-ce | はい | SHA-1暗号化ハッシュ関数 |
sha224 | sha224-generic 、 sha224-arm64 、 sha224-ce | はい | SHA-224暗号化ハッシュ関数:コードはSHA-256と共有されます。 |
sha256 | sha256-generic 、 sha256-arm64 、 sha256-ce 、SHA-256ライブラリ | はい | SHA-256暗号化ハッシュ関数:従来のCryptoAPIインターフェイスに加えて、ライブラリインターフェイスがSHA-256に提供されます。このライブラリインターフェイスは、異なる実装を使用します。 |
sha384 | sha384-generic 、 sha384-arm64 、 sha384-ce | はい | SHA-384暗号化ハッシュ関数:コードはSHA-512と共有されます。 |
sha512 | sha512-generic 、 sha512-arm64 、 sha512-ce | はい | SHA-512暗号化ハッシュ関数 |
hmac | hmac (テンプレート) | はい | HMAC(Keyed-Hash Message Authentication Code): hmac テンプレートは、 hmac(<sha-alg>) またはhmac(<sha-impl>) を使用して任意のSHAアルゴリズムまたは実装で構成できます。 |
stdrng | drbg_pr_hmac_sha1 、 drbg_pr_hmac_sha256 、 drbg_pr_hmac_sha384 、 drbg_pr_hmac_sha512 | はい | 名前付きハッシュ関数と予測耐性を有効にしてインスタンス化されたHMAC_DRBG:ヘルスチェックが含まれています。このインターフェースのユーザーは、独自のDRBGインスタンスを取得します。 |
stdrng | drbg_nopr_hmac_sha1 、 drbg_nopr_hmac_sha256 、 drbg_nopr_hmac_sha384 、 drbg_nopr_hmac_sha512 | はい | drbg_pr_* アルゴリズムと同じですが、予測抵抗が無効になっています。コードは、予測耐性のあるバリアントと共有されます。最も優先度の高いDRBGはdrbg_nopr_hmac_sha256 です。 |
jitterentropy_rng | jitterentropy_rng | いいえ | Jitter RNGのバージョン2.2.0:このインターフェースのユーザーは、独自のJitterRNGインスタンスを取得します。 DRBGが使用するインスタンスを再利用しません。 |
xcbc(aes) | xcbc-aes-neon 、 xcbc-aes-ce | いいえ | |
cbcmac(aes) | cbcmac-aes-neon 、 cbcmac-aes-ce | いいえ | |
essiv(cbc(aes),sha256) | essiv-cbc-aes-sha256-neon 、 essiv-cbc-aes-sha256-ce | いいえ |
ソースからモジュールを構築する
fips140.ko
モジュールは、次のコマンドを使用してGKIカーネルソースから構築できます。
BUILD_CONFIG=common/build.config.gki.aarch64.fips140 build/build.sh
これにより、カーネルとfips140.ko
モジュールを使用してフルビルドが実行され、その内容の正しいHMAC-SHA256ダイジェストが埋め込まれます。
エンドユーザーガイダンス
暗号オフィサーガイダンス
カーネルモジュールを操作するには、オペレーティングシステムをシングルオペレーターモードの操作に制限する必要があります。これは、プロセッサのメモリ管理ハードウェアを使用してAndroidによって自動的に処理されます。
カーネルモジュールを個別にインストールすることはできません。これはデバイスファームウェアの一部として含まれており、起動時に自動的にロードされます。承認された動作モードでのみ動作します。
Crypto Officerは、デバイスを再起動することにより、いつでもセルフテストを実行させることができます。
ユーザーガイダンス
カーネルモジュールのユーザーは、暗号化アルゴリズムを使用する必要がある他のカーネルコンポーネントです。カーネルモジュールは、アルゴリズムの使用に追加のロジックを提供せず、暗号化操作の実行に必要な時間を超えてパラメーターを格納しません。
FIPS準拠の目的でのアルゴリズムの使用は、承認されたアルゴリズムに限定されています。 FIPS 140-3の「サービスインジケータ」要件を満たすために、モジュールは、アルゴリズムが承認されているかどうかを示す関数fips140_is_approved_service
を提供します。
セルフテストエラー
セルフテストに失敗した場合、カーネルモジュールによってカーネルがパニックになり、デバイスは起動を続行しません。デバイスを再起動しても問題が解決しない場合は、デバイスを再フラッシュして問題を修正するために、デバイスをリカバリモードで起動する必要があります。
モジュールのAES-GCM実装は「アルゴリズム承認」できますが、「モジュール承認」はできないと予想されます。それらは検証できますが、AES-GCMはFIPSモジュールの観点から承認されたアルゴリズムと見なすことはできません。これは、GCMのFIPSモジュール要件が、独自のIVを生成しないGCM実装と互換性がないためです。 ↩