Криптомодуль GKI, сертифицированный по FIPS 140-3

Ядро GKI включает модуль ядра Linux под названием fips140.ko , который соответствует требованиям FIPS 140-3 для модулей криптографического программного обеспечения. Этот модуль можно отправить на сертификацию FIPS, если этого требует продукт, работающий под управлением ядра GKI.

Прежде чем можно будет использовать криптопрограммы, в частности, должны быть выполнены следующие требования FIPS 140-3:

  • Модуль должен проверить свою целостность, прежде чем предоставлять доступ к криптографическим алгоритмам.
  • Модуль должен протестировать и проверить утвержденные криптографические алгоритмы с помощью самотестирования с известным ответом, прежде чем сделать их доступными.

Зачем отдельный модуль ядра

Проверка FIPS 140-3 основана на идее, что после сертификации программного или аппаратного модуля его нельзя изменить. В случае изменения необходимо пройти повторную сертификацию. Это не совсем соответствует процессам разработки программного обеспечения, используемым сегодня, и в результате этого требования программные модули FIPS обычно проектируются так, чтобы быть как можно более сосредоточенными на криптографических компонентах, чтобы гарантировать, что изменения, не связанные с криптографией, не будут реализованы. Не требуется переоценки криптографии.

Ядро GKI предназначено для регулярного обновления в течение всего срока его поддержки. Это делает невозможным нахождение всего ядра в границах модуля FIPS, поскольку такой модуль необходимо будет проходить повторную сертификацию при каждом обновлении ядра. Определение «модуля FIPS» как подмножества образа ядра смягчит эту проблему, но не решит ее, поскольку двоичное содержимое «модуля FIPS» по-прежнему будет меняться гораздо чаще, чем необходимо.

До версии ядра 6.1 еще одним соображением было то, что GKI компилировался с включенной LTO (оптимизация времени соединения), поскольку LTO был необходимым условием для целостности потока управления , что является важной функцией безопасности.

Таким образом, весь код, на который распространяются требования FIPS 140-3, упаковывается в отдельный модуль ядра fips140.ko , который полагается только на стабильные интерфейсы, предоставляемые исходным кодом ядра GKI, на основе которого он был создан. Это означает, что модуль можно использовать с разными выпусками GKI одного поколения и что его необходимо обновлять и повторно отправлять на сертификацию только в том случае, если какие-либо проблемы были исправлены в коде, который содержит сам модуль.

Когда использовать модуль

Само ядро ​​GKI содержит код, который зависит от криптографических процедур, которые также упакованы в модуль ядра FIPS 140-3. Таким образом, встроенные криптографические процедуры фактически не выносятся из ядра GKI, а копируются в модуль. Когда модуль загружается, встроенные криптографические процедуры отменяются от регистрации в Linux CryptoAPI и заменяются теми, которые содержатся в модуле.

Это означает, что модуль fips140.ko является совершенно необязательным, и его имеет смысл развертывать только в том случае, если требуется сертификация FIPS 140-3. Помимо этого, модуль не предоставляет никаких дополнительных возможностей, и его ненужная загрузка может только повлиять на время загрузки, не принеся никакой пользы.

Как развернуть модуль

Модуль можно включить в сборку Android, выполнив следующие действия:

  • Добавьте имя модуля в BOARD_VENDOR_RAMDISK_KERNEL_MODULES . Это приведет к копированию модуля на виртуальный диск поставщика.
  • Добавьте имя модуля в BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD . Это приведет к тому, что имя модуля будет добавлено в modules.load на целевом объекте. modules.load содержит список модулей, которые загружаются программой init при загрузке устройства.

Самопроверка целостности

Модуль ядра FIPS 140-3 принимает дайджест HMAC-SHA256 своих собственных разделов .code и .rodata во время загрузки модуля и сравнивает его с дайджестом, записанным в модуле. Это происходит после того, как загрузчик модулей Linux уже внес в эти разделы обычные изменения, такие как обработка перемещения ELF и альтернативные исправления для ошибок ЦП. Для обеспечения правильного воспроизведения дайджеста предпринимаются следующие дополнительные шаги:

  • Перемещения ELF сохраняются внутри модуля, поэтому их можно применять в обратном порядке по отношению к входу HMAC.
  • Модуль отменяет любые исправления кода, внесенные ядром для стека динамических теневых вызовов. В частности, модуль заменяет любые инструкции, которые помещают или извлекают из стека теневых вызовов, инструкциями кода аутентификации указателя (PAC), которые присутствовали изначально.
  • Все остальные исправления кода отключены для модуля, включая статические ключи и, следовательно, точки трассировки, а также перехватчики поставщиков.

Самотестирование с известным ответом

Любые реализованные алгоритмы, на которые распространяются требования FIPS 140-3, перед использованием должны выполнить самопроверку с известным ответом. Согласно Руководству по внедрению FIPS 140-3 10.3.A , одного тестового вектора для каждого алгоритма, использующего любую из поддерживаемых длин ключей, достаточно для шифров, при условии, что проверяются как шифрование, так и дешифрование.

В Linux CryptoAPI есть понятие приоритетов алгоритмов, при котором могут сосуществовать несколько реализаций (например, одна, использующая специальные криптографические инструкции, и резервная версия для процессоров, которые не реализуют эти инструкции) одного и того же алгоритма. Следовательно, необходимо протестировать все реализации одного и того же алгоритма. Это необходимо, поскольку Linux CryptoAPI позволяет обойти выбор на основе приоритета и вместо этого выбрать алгоритм с более низким приоритетом.

Алгоритмы, включенные в модуль

Все алгоритмы, включенные в модуль FIPS 140-3, перечислены ниже. Это относится к ветвям ядра android12-5.10 , android13-5.10 , android13-5.15 , android14-5.15 , android14-6.1 и android15-6.6 , хотя различия между версиями ядра отмечены там, где это необходимо.

Алгоритм Реализации Утвержденный Определение
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 можно составить с любой реализацией aes используя cmac(<aes-impl>) . Остальные реализации являются автономными.
ecb(aes) ecb (шаблон), ecb-aes-neon , ecb-aes-neonbs , ecb-aes-ce Да AES-ECB: поддерживаются все размеры ключей AES. Шаблон ecb можно составить с любой реализацией aes используя ecb(<aes-impl>) . Остальные реализации являются автономными.
cbc(aes) cbc (шаблон), cbc-aes-neon , cbc-aes-neonbs , cbc-aes-ce Да AES-CBC: поддерживаются все размеры ключей AES. Шаблон cbc можно составить с любой реализацией aes используя ctr(<aes-impl>) . Остальные реализации являются автономными.
cts(cbc(aes)) cts (шаблон), cts-cbc-aes-neon , cts-cbc-aes-ce Да AES-CBC-CTS или AES-CBC с кражей зашифрованного текста: используется соглашение CS3 ; последние два блока зашифрованного текста меняются местами безоговорочно. Поддерживаются все размеры ключей AES. Шаблон cts можно составить с любой реализацией cbc используя cts(<cbc(aes)-impl>) . Остальные реализации являются автономными.
ctr(aes) ctr (шаблон), ctr-aes-neon , ctr-aes-neonbs , ctr-aes-ce Да AES-CTR: поддерживаются все размеры ключей AES. Шаблон ctr можно составить с любой реализацией aes используя ctr(<aes-impl>) . Остальные реализации являются автономными.
xts(aes) xts (шаблон), xts-aes-neon , xts-aes-neonbs , xts-aes-ce Да AES-XTS: в ядре версии 6.1 и ниже поддерживаются все размеры ключей AES; в ядре версии 6.6 и выше поддерживаются только AES-128 и AES-256. Шаблон xts можно составить с любой реализацией ecb(aes) с помощью xts(<ecb(aes)-impl>) . Остальные реализации являются автономными. Все реализации реализуют проверку слабого ключа, требуемую FIPS; то есть ключи XTS, первая и вторая половины которых равны, отклоняются.
gcm(aes) gcm (шаблон), gcm-aes-ce1 AES-GCM: поддерживаются все размеры ключей AES. Поддерживаются только 96-битные IV. Как и во всех других режимах AES в этом модуле, за предоставление IV отвечает вызывающая сторона. Шаблон gcm может быть составлен с использованием любых реализаций ctr(aes) и ghash , используя gcm_base(<ctr(aes)-impl>,<ghash-impl>) . Остальные реализации являются автономными.
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
sha3-224 sha3-224-generic Да Криптографическая хэш-функция SHA3-224. Присутствует только в ядре версии 6.6 и выше.
sha3-256 sha3-256-generic Да То же, что и предыдущее, но с длиной дайджеста 256 бит (SHA3-256). Все длины дайджеста используют одну и ту же реализацию Keccak.
sha3-384 sha3-384-generic Да То же, что и предыдущее, но с длиной дайджеста 384 бита (SHA3-384). Все длины дайджеста используют одну и ту же реализацию Keccak.
sha3-512 sha3-512-generic Да То же, что и предыдущее, но с длиной дайджеста 512 бит (SHA3-512). Все длины дайджеста используют одну и ту же реализацию Keccak.
hmac hmac (шаблон) Да HMAC (код аутентификации сообщения с использованием хеш-ключа): шаблон hmac может быть составлен с использованием любого алгоритма или реализации SHA с использованием hmac(<sha-alg>) или hmac(<sha-impl>) .
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_* , но с отключенной устойчивостью к прогнозированию. Код используется совместно с устойчивым к предсказанию вариантом. В версии ядра 5.10 DRBG с наивысшим приоритетом — drbg_nopr_hmac_sha256 . В ядре версии 5.15 и выше это drbg_pr_hmac_sha512 .
jitterentropy_rng jitterentropy_rng Нет Jitter RNG либо версии 2.2.0 (версия ядра 6.1 и ниже), либо версии 3.4.0 (версия ядра 6.6 и выше). Пользователи этого интерфейса получают свои собственные экземпляры Jitter RNG. Они не используют повторно экземпляры, используемые DRBG.
xcbc(aes) xcbc-aes-neon , xcbc-aes-ce Нет
xctr(aes) xctr-aes-neon , xctr-aes-ce Нет Присутствует только в ядре версии 5.15 и выше.
cbcmac(aes) cbcmac-aes-neon , cbcmac-aes-ce Нет
essiv(cbc(aes),sha256) essiv-cbc-aes-sha256-neon , essiv-cbc-aes-sha256-ce Нет

Сборка модуля из исходного кода

Для Android 14 и более поздних версий (включая android-mainline ) создайте модуль fips140.ko из исходного кода, используя следующие команды.

  • Сборка с Базелем:

    tools/bazel run //common:fips140_dist
  • Сборка с помощью build.sh (устаревшая версия):

    BUILD_CONFIG=common/build.config.gki.aarch64.fips140 build/build.sh

Эти команды выполняют полную сборку, включая ядро ​​и модуль fips140.ko со встроенным в него содержимым дайджеста HMAC-SHA256.

Руководство для конечного пользователя

Руководство для крипто-специалиста

Для работы модуля ядра операционная система должна быть ограничена режимом работы одного оператора. Android обрабатывает это автоматически, используя аппаратное обеспечение управления памятью в процессоре.

Модуль ядра не может быть установлен отдельно; он включен в прошивку устройства и загружается автоматически при загрузке. Он работает только в утвержденном режиме работы.

Крипто-специалист может запустить самотестирование в любое время, перезапустив устройство.

Руководство пользователя

Пользователем модуля ядра являются другие компоненты ядра, которым необходимо использовать криптографические алгоритмы. Модуль ядра не обеспечивает дополнительную логику использования алгоритмов и не сохраняет никаких параметров, превышающих время, необходимое для выполнения криптографической операции.

Использование алгоритмов для целей соответствия FIPS ограничивается утвержденными алгоритмами. Чтобы удовлетворить требованию FIPS 140-3 «индикатор обслуживания», модуль предоставляет функцию fips140_is_approved_service , которая указывает, одобрен ли алгоритм.

Ошибки самотестирования

В случае сбоя самотестирования модуль ядра вызывает панику ядра и устройство не продолжает загрузку. Если перезагрузка устройства не решает проблему, устройство необходимо загрузить в режиме восстановления, чтобы устранить проблему путем перепрошивки устройства.


  1. Ожидается, что реализации AES-GCM модуля могут быть «утверждены алгоритмом», но не «утверждены модулем». Их можно проверить, но AES-GCM нельзя считать утвержденным алгоритмом с точки зрения модуля FIPS. Это связано с тем, что требования к модулю FIPS для GCM несовместимы с реализациями GCM, которые не создают свои собственные IV.

,

Ядро GKI включает модуль ядра Linux под названием fips140.ko , который соответствует требованиям FIPS 140-3 для модулей криптографического программного обеспечения. Этот модуль можно отправить на сертификацию FIPS, если этого требует продукт, работающий под управлением ядра GKI.

Прежде чем можно будет использовать криптопрограммы, в частности, должны быть выполнены следующие требования FIPS 140-3:

  • Модуль должен проверить свою целостность, прежде чем предоставлять доступ к криптографическим алгоритмам.
  • Прежде чем сделать их доступными, модуль должен протестировать и проверить утвержденные криптографические алгоритмы с помощью самотестирования с известным ответом.

Зачем отдельный модуль ядра

Валидация FIPS 140-3 основана на идее, что после сертификации программного или аппаратного модуля его нельзя изменить. В случае изменения необходимо пройти повторную сертификацию. Это не совсем соответствует процессам разработки программного обеспечения, используемым сегодня, и в результате этого требования программные модули FIPS обычно проектируются так, чтобы быть как можно более сосредоточенными на криптографических компонентах, чтобы гарантировать, что изменения, не связанные с криптографией, не будут реализованы. Не требуется переоценки криптографии.

Ядро GKI предназначено для регулярного обновления в течение всего срока его поддержки. Это делает невозможным нахождение всего ядра в границах модуля FIPS, поскольку такой модуль необходимо будет проходить повторную сертификацию при каждом обновлении ядра. Определение «модуля FIPS» как подмножества образа ядра смягчит эту проблему, но не решит ее, поскольку двоичное содержимое «модуля FIPS» по-прежнему будет меняться гораздо чаще, чем необходимо.

До версии ядра 6.1 еще одним соображением было то, что GKI компилировался с включенной LTO (оптимизация времени соединения), поскольку LTO был необходимым условием для целостности потока управления , что является важной функцией безопасности.

Таким образом, весь код, на который распространяются требования FIPS 140-3, упаковывается в отдельный модуль ядра fips140.ko , который полагается только на стабильные интерфейсы, предоставляемые исходным кодом ядра GKI, на основе которого он был создан. Это означает, что модуль можно использовать с разными выпусками GKI одного поколения и что его необходимо обновлять и повторно отправлять на сертификацию только в том случае, если какие-либо проблемы были исправлены в коде, который содержит сам модуль.

Когда использовать модуль

Само ядро ​​GKI содержит код, который зависит от криптографических процедур, которые также упакованы в модуль ядра FIPS 140-3. Следовательно, встроенные крипто-процедуры фактически не выходят из ядра GKI, а скорее копируются в модуль. Когда модуль загружается, встроенные криптографические процедуры отменяются от регистрации в Linux CryptoAPI и заменяются теми, которые содержатся в модуле.

Это означает, что модуль fips140.ko является совершенно необязательным, и имеет смысл развернуть его только в том случае, если сертификация FIPS 140-3 является требованием. Помимо этого, модуль не предоставляет никаких дополнительных возможностей, и его ненужная загрузка может только повлиять на время загрузки, не принеся никакой пользы.

Как развернуть модуль

Модуль может быть включен в сборку Android, используя следующие шаги:

  • Добавьте имя модуля в BOARD_VENDOR_RAMDISK_KERNEL_MODULES . Это приводит к скопированию модуля на поставщика Ramdisk.
  • Добавьте имя модуля в BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD . Это приведет к добавлению имени модуля в modules.load на целевом объекте. modules.load содержит список модулей, которые загружаются программой init при загрузке устройства.

Самопроверка целостности

Модуль ядра FIPS 140-3 принимает дайджест HMAC-SHA256 своих собственных разделов .code и .rodata во время загрузки модуля и сравнивает его с дайджестом, записанным в модуле. Это происходит после того, как загрузчик модулей Linux уже внес в эти разделы обычные изменения, такие как обработка перемещения ELF и альтернативные исправления для ошибок ЦП. Следующие дополнительные шаги предприняты для того, чтобы убедиться, что дайджест может быть правильно воспроизведен:

  • Перемещения ELF сохраняются внутри модуля, поэтому их можно применять в обратном порядке по отношению к входу HMAC.
  • Модуль отменяет любые исправления кода, внесенные ядром для стека динамических теневых вызовов. В частности, модуль заменяет любые инструкции, которые помещают или извлекают из стека теневых вызовов, инструкциями кода аутентификации указателя (PAC), которые присутствовали изначально.
  • Все остальные исправления кода отключены для модуля, включая статические ключи и, следовательно, точки трассировки, а также перехватчики поставщиков.

Самотестирование с известным ответом

Любые реализованные алгоритмы, на которые распространяются требования FIPS 140-3, перед использованием должны выполнить самопроверку с известным ответом. Согласно Руководству по внедрению FIPS 140-3 10.3.A , одного тестового вектора для каждого алгоритма, использующего любую из поддерживаемых длин ключей, достаточно для шифров, при условии, что проверяются как шифрование, так и дешифрование.

В Linux CryptoAPI есть понятие приоритетов алгоритмов, при котором могут сосуществовать несколько реализаций (например, одна, использующая специальные криптографические инструкции, и резервная версия для процессоров, которые не реализуют эти инструкции) одного и того же алгоритма. Следовательно, необходимо протестировать все реализации одного и того же алгоритма. Это необходимо, поскольку Linux CryptoAPI позволяет обойти выбор на основе приоритета и вместо этого выбрать алгоритм с более низким приоритетом.

Алгоритмы, включенные в модуль

Все алгоритмы, включенные в модуль FIPS 140-3, перечислены ниже. Это относится к ветвям ядра android12-5.10 , android13-5.10 , android13-5.15 , android14-5.15 , android14-6.1 и android15-6.6 , хотя различия между версиями ядра отмечены там, где это необходимо.

Алгоритм Реализации Утвержденный Определение
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 можно составить с любой реализацией aes используя cmac(<aes-impl>) . Остальные реализации являются автономными.
ecb(aes) ecb (шаблон), ecb-aes-neon , ecb-aes-neonbs , ecb-aes-ce Да AES-ECB: поддерживаются все размеры ключей AES. Шаблон ecb можно составить с любой реализацией aes используя ecb(<aes-impl>) . Остальные реализации являются автономными.
cbc(aes) cbc (шаблон), cbc-aes-neon , cbc-aes-neonbs , cbc-aes-ce Да AES-CBC: поддерживаются все размеры ключей AES. Шаблон cbc можно составить с любой реализацией aes используя ctr(<aes-impl>) . Остальные реализации являются автономными.
cts(cbc(aes)) cts (шаблон), cts-cbc-aes-neon , cts-cbc-aes-ce Да AES-CBC-CTS или AES-CBC с кражей зашифрованного текста: используется соглашение CS3 ; последние два блока зашифрованного текста меняются местами безоговорочно. Поддерживаются все размеры ключей AES. Шаблон cts можно составить с любой реализацией cbc используя cts(<cbc(aes)-impl>) . Остальные реализации являются автономными.
ctr(aes) ctr (шаблон), ctr-aes-neon , ctr-aes-neonbs , ctr-aes-ce Да AES-CTR: поддерживаются все размеры ключей AES. Шаблон ctr можно составить с любой реализацией aes используя ctr(<aes-impl>) . Остальные реализации являются автономными.
xts(aes) xts (шаблон), xts-aes-neon , xts-aes-neonbs , xts-aes-ce Да AES-XTS: в ядре версии 6.1 и ниже поддерживаются все размеры ключей AES; В версии ядра 6.6 и выше поддерживаются только AES-128 и AES-256. Шаблон xts может быть составлен с любой реализацией ecb(aes) с использованием xts(<ecb(aes)-impl>) . Остальные реализации являются автономными. Все реализации реализуют слабую проверку ключей, требуемую FIPS; То есть ключи XTS, чьи первые и вторые половины равны, отклоняются.
gcm(aes) gcm (шаблон), gcm-aes-ce1 AES-GCM: поддерживаются все размеры ключей AES. Поддерживаются только 96-битные IV. Как и во всех других режимах AES в этом модуле, вызывающий ответственность отвечает за предоставление IV. Шаблон gcm может быть составлен с использованием любых реализаций ctr(aes) и ghash , используя gcm_base(<ctr(aes)-impl>,<ghash-impl>) . Остальные реализации являются автономными.
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
sha3-224 sha3-224-generic Да Криптографическая хэш-функция SHA3-224. Присутствует только в ядре версии 6.6 и выше.
sha3-256 sha3-256-generic Да То же, что и предыдущее, но с длиной дайджеста 256 бит (SHA3-256). Все длины дайджеста используют одну и ту же реализацию Keccak.
sha3-384 sha3-384-generic Да То же, что и предыдущее, но с длиной дайджеста 384 бита (SHA3-384). Все длины дайджеста используют одну и ту же реализацию Keccak.
sha3-512 sha3-512-generic Да То же, что и предыдущее, но с длиной дайджеста 512 бит (SHA3-512). Все длины дайджеста используют одну и ту же реализацию Keccak.
hmac hmac (шаблон) Да HMAC (код аутентификации сообщения с использованием хеш-ключа): шаблон hmac может быть составлен с использованием любого алгоритма или реализации SHA с использованием hmac(<sha-alg>) или hmac(<sha-impl>) .
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_* , но с отключенной устойчивостью к прогнозированию. Код используется совместно с устойчивым к предсказанию вариантом. В версии ядра 5.10 DRBG с наивысшим приоритетом — drbg_nopr_hmac_sha256 . В ядре версии 5.15 и выше это drbg_pr_hmac_sha512 .
jitterentropy_rng jitterentropy_rng Нет Jitter RNG либо версии 2.2.0 (версия ядра 6.1 и ниже), либо версии 3.4.0 (версия ядра 6.6 и выше). Пользователи этого интерфейса получают свои собственные экземпляры Jitter RNG. Они не используют повторно экземпляры, используемые DRBG.
xcbc(aes) xcbc-aes-neon , xcbc-aes-ce Нет
xctr(aes) xctr-aes-neon , xctr-aes-ce Нет Присутствует только в ядре версии 5.15 и выше.
cbcmac(aes) cbcmac-aes-neon , cbcmac-aes-ce Нет
essiv(cbc(aes),sha256) essiv-cbc-aes-sha256-neon , essiv-cbc-aes-sha256-ce Нет

Сборка модуля из исходного кода

Для Android 14 и более поздних версий (включая android-mainline ) создайте модуль fips140.ko из исходного кода, используя следующие команды.

  • Сборка с Базелем:

    tools/bazel run //common:fips140_dist
  • Сборка с помощью build.sh (устаревшая версия):

    BUILD_CONFIG=common/build.config.gki.aarch64.fips140 build/build.sh

Эти команды выполняют полную сборку, включая ядро ​​и модуль fips140.ko со встроенным в него содержимым дайджеста HMAC-SHA256.

Руководство для конечного пользователя

Руководство для крипто-специалиста

Для работы модуля ядра операционная система должна быть ограничена режимом работы одного оператора. Это автоматически обрабатывается Android с использованием оборудования для управления памятью в процессоре.

Модуль ядра не может быть установлен отдельно; Он включен как часть прошивки устройства и загружается автоматически на загрузке. Он работает только в утвержденном режиме работы.

Крипто-специалист может запустить самотестирование в любое время, перезапустив устройство.

Руководство пользователя

Пользователем модуля ядра являются другие компоненты ядра, которым необходимо использовать криптографические алгоритмы. Модуль ядра не обеспечивает дополнительную логику использования алгоритмов и не сохраняет никаких параметров, превышающих время, необходимое для выполнения криптографической операции.

Использование алгоритмов для целей соответствия FIPS ограничивается утвержденными алгоритмами. Чтобы удовлетворить требованию FIPS 140-3 «индикатор обслуживания», модуль предоставляет функцию fips140_is_approved_service , которая указывает, одобрен ли алгоритм.

Ошибки самотестирования

В случае сбоя самотестирования модуль ядра вызывает панику ядра и устройство не продолжает загрузку. Если перезагрузка устройства не решает проблему, устройство необходимо загрузить в режиме восстановления, чтобы устранить проблему путем перепрошивки устройства.


  1. Ожидается, что реализации AES-GCM модуля могут быть «утверждены алгоритмом», но не «утверждены модулем». Их можно проверить, но AES-GCM нельзя считать утвержденным алгоритмом с точки зрения модуля FIPS. Это связано с тем, что требования модуля FIPS для GCM несовместимы с реализациями GCM, которые не создают свои собственные IV.