Криптомодуль 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.
  • Все остальные исправления кода отключены для модуля, включая статические ключи и, следовательно, точки трассировки, а также перехватчики поставщиков.

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

Любые реализованные алгоритмы, на которые распространяются требования 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 , хотя различия между версиями ядра отмечаются там, где это необходимо.

Алгоритм Реализации Утвержденный Определение
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: поддерживаются все размеры ключей AES. Шаблон 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
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 Нет Версия 2.2.0 Jitter RNG : пользователи этого интерфейса получают свои собственные экземпляры 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.