Módulo de criptografia GKI certificável para FIPS 140-3

O kernel GKI inclui um módulo do kernel do Linux chamado fips140.ko que atende aos requisitos do FIPS 140-3 para módulos de software criptográficos. Esse módulo pode ser enviado para certificação FIPS se o produto que executa o kernel GKI exigir isso.

Os seguintes requisitos da FIPS 140-3 precisam ser atendidos antes que as rotinas de criptografia possam ser usadas:

• O módulo precisa verificar a própria integridade antes de disponibilizar algoritmos criptográficos.
• O módulo precisa exercitar e verificar os algoritmos criptográficos aprovados usando autotestes de resposta conhecida antes de disponibilizá-los.

Por que um módulo de kernel separado

A validação FIPS 140-3 se baseia na ideia de que, depois que um módulo de software ou hardware é certificado, ele nunca é alterado. Se ele for alterado, será necessário recertificá-lo. Isso não corresponde facilmente aos processos de desenvolvimento de software em uso hoje. Como resultado desse requisito, os módulos de software FIPS são geralmente projetados para serem o mais focados possível nos componentes criptográficos para garantir que as mudanças não relacionadas à criptografia não exijam uma reavaliação da criptografia.

O kernel GKI foi projetado para ser atualizado regularmente durante todo o ciclo de vida com suporte. Isso torna inviável que todo o kernel esteja dentro do limite do módulo FIPS, já que um módulo desse tipo precisaria ser recertificado a cada atualização do kernel. Definir o "módulo FIPS" como um subconjunto da imagem do kernel mitigaria esse problema, mas não o resolveria, já que o conteúdo binário do "módulo FIPS" ainda mudaria com muito mais frequência do que o necessário.

Antes da versão 6.1 do kernel, outra consideração era que o GKI era compilado com a LTO (Link Time Optimization, otimização de tempo de vinculação) ativada, já que ela era um pré-requisito para a Integridade do fluxo de controle, um recurso de segurança importante.

Portanto, todo o código coberto pelos requisitos do FIPS 140-3 é empacotado em um módulo de kernel separado fips140.ko, que depende apenas de interfaces estáveis expostas pela fonte do kernel GKI de que foi criado. Isso significa que o módulo pode ser usado com diferentes versões do GKI da mesma geração e que ele precisa ser atualizado e reenviado para certificação apenas se algum problema for corrigido no código contido no próprio módulo.

Quando usar o módulo

O próprio kernel GKI tem um código que depende das rotinas de criptografia também incluídas no módulo do kernel FIPS 140-3. Portanto, as rotinas criptográficas integradas não são movidas para fora do kernel da GKI, mas copiadas para o módulo. Quando o módulo é carregado, as rotinas criptográficas integradas são desregistradas da CryptoAPI do Linux e substituídas pelas rotinas do módulo.

Isso significa que o módulo fips140.ko é totalmente opcional e só faz sentido implantá-lo se a certificação FIPS 140-3 for um requisito. Além disso, o módulo não oferece recursos extras, e carregá-lo desnecessariamente só vai afetar o tempo de inicialização, sem trazer nenhum benefício.

Como implantar o módulo

O módulo pode ser incorporado ao build do Android seguindo estas etapas:

• Adicione o nome do módulo a BOARD_VENDOR_RAMDISK_KERNEL_MODULES. Isso faz com que o módulo seja copiado para o ramdisk do fornecedor.
• Adicione o nome do módulo a BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD. Isso faz com que o nome do módulo seja adicionado a modules.load no destino. modules.load contém a lista de módulos carregados por init quando o dispositivo é inicializado.

A autoverificação de integridade

O módulo de kernel FIPS 140-3 usa o resumo HMAC-SHA256 das próprias seções .code e .rodata no tempo de carregamento do módulo e o compara com o resumo registrado no módulo. Isso acontece depois que o carregador de módulos do Linux já fez as modificações usuais, como o processamento de realocação ELF e a correção de alternativas para erratas da CPU nessas seções. As seguintes etapas adicionais são realizadas para garantir que o resumo possa ser reproduzido corretamente:

• As relocações ELF são preservadas dentro do módulo para que possam ser aplicadas de forma inversa à entrada do HMAC.
• O módulo reverte todos os patches de código feitos pelo kernel para a pilha de chamadas dinâmicas. Especificamente, o módulo substitui todas as instruções que enviam ou removem da pilha de chamadas de sombra pelas instruções do Código de Autenticação de Ponteiro (PAC) que estavam presentes originalmente.
• Todo o restante patch de código é desativado para o módulo, incluindo chaves estáticas e, portanto, pontos de rastreamento e hooks do fornecedor.

Os autotestes de resposta conhecida

Todos os algoritmos implementados que estão cobertos pelos requisitos da FIPS 140-3 precisam realizar um autoteste de resposta conhecida antes de serem usados. De acordo com o FIPS 140-3 Implementation Guidance 10.3.A, um único vetor de teste por algoritmo usando qualquer um dos comprimentos de chave compatíveis é suficiente para cifras, desde que a criptografia e a descriptografia sejam testadas.

A CryptoAPI do Linux tem uma noção de prioridades de algoritmo, em que várias implementações (como uma que usa instruções criptográficas especiais e um fallback para CPUs que não implementam essas instruções) do mesmo algoritmo podem coexistir. Portanto, é necessário testar todas as implementações do mesmo algoritmo. Isso é necessário porque a CryptoAPI do Linux permite que a seleção baseada em prioridade seja ignorada e que um algoritmo de prioridade mais baixa seja selecionado.

Algoritmos incluídos no módulo

Todos os algoritmos incluídos no módulo FIPS 140-3 estão listados abaixo. Isso se aplica às ramificações do kernel android12-5.10, android13-5.10, android13-5.15, android14-5.15, android14-6.1 e android15-6.6, embora as diferenças entre as versões do kernel sejam observadas quando apropriado.

Algoritmo	Implementações	Aprovável	Definição
aes	aes-generic, aes-arm64, aes-ce, biblioteca AES	Sim	Criptografia de bloco AES simples, sem modo de operação: todos os tamanhos de chave (128 bits, 192 bits e 256 bits) são compatíveis. Todas as implementações, exceto a da biblioteca, podem ser compostas com um modo de operação usando um modelo.
cmac(aes)	cmac (modelo), cmac-aes-neon, cmac-aes-ce	Sim	AES-CMAC: todos os tamanhos de chave AES são compatíveis. O modelo cmac pode ser composto com qualquer implementação de aes usando cmac(<aes-impl>). As outras implementações são independentes.
ecb(aes)	ecb (modelo), ecb-aes-neon, ecb-aes-neonbs, ecb-aes-ce	Sim	AES-ECB: todos os tamanhos de chave AES são compatíveis. O modelo ecb pode ser composto com qualquer implementação de aes usando ecb(<aes-impl>). As outras implementações são independentes.
cbc(aes)	cbc (modelo), cbc-aes-neon, cbc-aes-neonbs, cbc-aes-ce	Sim	AES-CBC: todos os tamanhos de chave AES são compatíveis. O modelo cbc pode ser composto com qualquer implementação de aes usando ctr(<aes-impl>). As outras implementações são independentes.
cts(cbc(aes))	cts (modelo), cts-cbc-aes-neon, cts-cbc-aes-ce	Sim	AES-CBC-CTS ou AES-CBC com roubo de texto criptografado: a convenção usada é CS3. Os dois blocos finais de texto criptografado são trocados incondicionalmente. Todos os tamanhos de chave AES são aceitos. O modelo cts pode ser composto com qualquer implementação de cbc usando cts(<cbc(aes)-impl>). As outras implementações são independentes.
ctr(aes)	ctr (modelo), ctr-aes-neon, ctr-aes-neonbs, ctr-aes-ce	Sim	AES-CTR: todos os tamanhos de chave AES são compatíveis. O modelo ctr pode ser composto com qualquer implementação de aes usando ctr(<aes-impl>). As outras implementações são independentes.
xts(aes)	xts (modelo), xts-aes-neon, xts-aes-neonbs, xts-aes-ce	Sim	AES-XTS: na versão 6.1 e anteriores do kernel, todos os tamanhos de chave AES são compatíveis. Na versão 6.6 e mais recentes, apenas AES-128 e AES-256 são compatíveis. O modelo xts pode ser composto com qualquer implementação de ecb(aes) usando xts(<ecb(aes)-impl>). As outras implementações são independentes. Todas as implementações implementam a verificação de chave fraca exigida pelo FIPS. Ou seja, chaves XTS cujas primeira e segunda metades são iguais são rejeitadas.
gcm(aes)	gcm (modelo), gcm-aes-ce	Não1	AES-GCM: todos os tamanhos de chave AES são compatíveis. Somente IVs de 96 bits são compatíveis. Assim como em todos os outros modos AES neste módulo, o autor da chamada é responsável por fornecer os IVs. O modelo gcm pode ser composto com qualquer implementação de ctr(aes) e ghash usando gcm_base(<ctr(aes)-impl>,<ghash-impl>). As outras implementações são independentes.
sha1	sha1-generic, sha1-ce	Sim	Função hash criptográfica SHA-1
sha224	sha224-generic, sha224-arm64, sha224-ce	Sim	Função hash criptográfica SHA-224: o código é compartilhado com SHA-256.
sha256	sha256-generic, sha256-arm64, sha256-ce, biblioteca SHA-256	Sim	Função de hash criptográfica SHA-256: uma interface de biblioteca é fornecida para SHA-256, além da interface CryptoAPI padrão. Essa interface de biblioteca usa uma implementação diferente.
sha384	sha384-generic, sha384-arm64, sha384-ce	Sim	Função hash criptográfica SHA-384: o código é compartilhado com SHA-512.
sha512	sha512-generic, sha512-arm64, sha512-ce	Sim	Função hash criptográfica SHA-512
sha3-224	sha3-224-generic	Sim	Função hash criptográfica SHA3-224. Presente apenas na versão 6.6 e mais recentes do kernel.
sha3-256	sha3-256-generic	Sim	Igual ao anterior, mas com comprimento de resumo de 256 bits (SHA3-256). Todos os tamanhos de resumo usam a mesma implementação do Keccak.
sha3-384	sha3-384-generic	Sim	Igual ao anterior, mas com comprimento de resumo de 384 bits (SHA3-384). Todos os tamanhos de resumo usam a mesma implementação do Keccak.
sha3-512	sha3-512-generic	Sim	Igual ao anterior, mas com comprimento de resumo de 512 bits (SHA3-512). Todos os tamanhos de resumo usam a mesma implementação do Keccak.
hmac	hmac (modelo)	Sim	HMAC (código de autenticação de mensagens de hash com chave): o modelo hmac pode ser composto com qualquer algoritmo ou implementação SHA usando hmac(<sha-alg>) ou hmac(<sha-impl>).
stdrng	drbg_pr_hmac_sha1, drbg_pr_hmac_sha256, drbg_pr_hmac_sha384, drbg_pr_hmac_sha512	Sim	HMAC_DRBG instanciado com a função de hash nomeada e com a resistência à previsão ativada: as verificações de integridade são incluídas. Os usuários dessa interface recebem as próprias instâncias de DRBG.
stdrng	drbg_nopr_hmac_sha1, drbg_nopr_hmac_sha256, drbg_nopr_hmac_sha384, drbg_nopr_hmac_sha512	Sim	Igual aos algoritmos drbg_pr_*, mas com a resistência à previsão desativada. O código é compartilhado com a variante resistente a previsões. Na versão 5.10 do kernel, o DRBG de maior prioridade é drbg_nopr_hmac_sha256. Na versão 5.15 e mais recentes do kernel, é drbg_pr_hmac_sha512.
jitterentropy_rng	jitterentropy_rng	Não	O Jitter RNG, versão 2.2.0 (versão do kernel 6.1 e versões anteriores) ou 3.4.0 (versão do kernel 6.6 e versões mais recentes). Os usuários dessa interface recebem as próprias instâncias de RNG de Jitter. Elas não reutilizam as instâncias usadas pelos DRBGs.
xcbc(aes)	xcbc-aes-neon, xcbc-aes-ce	Não
xctr(aes)	xctr-aes-neon, xctr-aes-ce	Não	Presente apenas na versão 5.15 do kernel e em versões mais recentes.
cbcmac(aes)	cbcmac-aes-neon, cbcmac-aes-ce	Não
essiv(cbc(aes),sha256)	essiv-cbc-aes-sha256-neon, essiv-cbc-aes-sha256-ce	Não

Criar o módulo da origem

No Android 14 e versões mais recentes (incluindo android-mainline), crie o módulo fips140.ko da origem usando os comandos a seguir.

• Crie com o Bazel:

  tools/bazel run //common:fips140_dist

• Criar com build.sh (legado):

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

Esses comandos realizam um build completo, incluindo o kernel e o módulo fips140.ko com o conteúdo do resumo HMAC-SHA256 incorporado.

Orientações para usuários finais

Orientações para o oficial de criptografia

Para operar o módulo do kernel, o sistema operacional precisa ser restrito a um único modo de operação do operador. Isso é processado automaticamente pelo Android usando hardware de gerenciamento de memória no processador.

O módulo do kernel não pode ser instalado separadamente. Ele é incluído como parte do firmware do dispositivo e carregado automaticamente na inicialização. Ele só opera em um modo de operação aprovado.

O Crypto Officer pode fazer com que os autotestes sejam executados a qualquer momento reiniciando o dispositivo.

Orientação ao usuário

O usuário do módulo do kernel são outros componentes do kernel que precisam usar algoritmos criptográficos. O módulo do kernel não fornece lógica adicional no uso dos algoritmos e não armazena parâmetros além do tempo necessário para realizar uma operação criptográfica.

O uso dos algoritmos para fins de compliance com o FIPS é limitado aos algoritmos aprovados. Para atender ao requisito de "indicador de serviço" da FIPS 140-3, o módulo fornece uma função fips140_is_approved_service que indica se um algoritmo foi aprovado.

Erros no autoteste

Em caso de falha no autoteste, o módulo do kernel faz com que o kernel entre em pânico e o dispositivo não continue a inicialização. Se uma reinicialização do dispositivo não resolver o problema, ele precisará ser inicializado no modo de recuperação para corrigir o problema com uma nova atualização.