O kernel GKI inclui uma
Módulo do kernel do Linux chamado fips140.ko
, que está em conformidade com
Requisitos do FIPS 140-3
para módulos de software criptográfico. Este módulo pode ser enviado para FIPS
certificação se o produto que executa o kernel de GKI precisar dela.
Os seguintes requisitos FIPS 140-3 especificamente devem ser cumpridos antes de as rotinas de criptografia podem ser usadas:
- O módulo precisa verificar a própria integridade antes de criar algoritmos criptográficos disponíveis.
- O módulo precisa usar 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 baseia-se na ideia de que, uma vez que um software ou hardware baseado em módulo for certificado, ele nunca será alterado. Se alterado, deverá ser que receberá uma nova certificação. Isso não corresponde prontamente aos processos de desenvolvimento de software usam atualmente e, como resultado dessa exigência, os módulos de software FIPS são geralmente são desenvolvidos com foco nos componentes criptográficos possível, para garantir que alterações não relacionadas à criptografia não que exigem uma reavaliação da criptografia.
O kernel de GKI precisa ser atualizado regularmente durante todo o suporte vida útil. Isso torna inviável que todo o kernel esteja dentro dos FIPS limite de módulo, portanto, um módulo precisaria ser certificado novamente em cada kernel atualizar. Definir o "módulo FIPS" para ser um subconjunto da imagem do kernel o problema, mas não o resolveria, já que o conteúdo binário dos "Módulo FIPS" ainda mudasse com muito mais frequência do que o necessário.
Antes da versão 6.1 do kernel, outra consideração era que a GKI era compilada com A Otimização do tempo de vinculação (LTO) está ativada, já que ela era um pré-requisito das seções Controle Integridade de fluxo, que é um recurso de segurança importante.
Assim, todo o código coberto pelos requisitos FIPS 140-3 é empacotado
para um módulo de kernel separado fips140.ko
, que depende apenas de instâncias
interfaces expostas pela origem do kernel de GKI a partir da qual ele foi criado. Isso
significa que o módulo pode ser usado com diferentes versões GKI do mesmo
e que precisam ser atualizados e reenviados somente para certificação
se algum problema foi corrigido no código carregado pelo próprio módulo.
Quando usar o módulo
O próprio kernel de GKI carrega código que depende das rotinas de criptografia que são também empacotados no módulo kernel FIPS 140-3. Portanto, a criptomoeda integrada não são retiradas do kernel de GKI, mas são copiadas para o no módulo. Quando o módulo é carregado, as rotinas de criptografia integradas são registrado na CryptoAPI do Linux e substituídos pelos mais tarde neste módulo.
Isso significa que o módulo fips140.ko
é totalmente opcional e só torna
sentido implantá-lo se a certificação FIPS 140-3 for um requisito. Além disso,
o módulo não fornece recursos adicionais, e carregá-lo desnecessariamente pode
provavelmente afetaria o tempo de inicialização, sem oferecer nenhum benefício.
Como implantar o módulo
O módulo pode ser incorporado no build do Android seguindo estas etapas:
- Adicione o nome do módulo a
BOARD_VENDOR_RAMDISK_KERNEL_MODULES
. Isso faz com que o 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 amodules.load
no destino.modules.load
contém a lista de módulos que são carregados porinit
quando o inicializações de dispositivos.
Autoverificação de integridade
O módulo do kernel FIPS 140-3 usa o resumo HMAC-SHA256 do próprio .code
e .rodata
no tempo de carregamento do módulo e o compara com o resumo
gravados no módulo. Isso ocorre depois que o carregador de módulos do Linux
já fez as modificações usuais, como processamento de realocação de ELF e
patches alternativos para errata da CPU para essas seções. O seguinte
etapas adicionais são tomadas para garantir que o resumo possa ser reproduzido
corretamente:
- As realocações de ELF são preservadas dentro do módulo para que possam ser aplicadas voltar à entrada do HMAC.
- O módulo reverte quaisquer patches de código feitos pelo kernel para Dynamic Pilha de chamadas sombra. Especificamente, o módulo substitui todas as instruções que enviar ou remover da pilha de chamadas paralelas com o código de autenticação do ponteiro (PAC) que estavam presentes originalmente.
- Todos os outros patches de código estão desativados no módulo, incluindo chaves estáticas e portanto, tracepoints e hooks de fornecedores.
Autotestes de resposta conhecida
Quaisquer algoritmos implementados que estejam cobertos pelos requisitos do FIPS 140-3 devem realizar um autoteste de resposta conhecida antes de ser usado. De acordo com o FIPS 140-3 Orientações para implementação 10.3.A, um único vetor de teste por algoritmo usando qualquer um dos comprimentos de chave suportados é suficientes para criptografias, contanto que a criptografia e a descriptografia sejam testadas.
A Linux CryptoAPI tem uma noção de prioridades de algoritmo, em que vários (como uma que usa instruções de criptografia especiais e uma para CPUs que não implementam essas instruções) do mesmo algoritmo pode coexistir. Portanto, é necessário testar todas as implementações da mesma algoritmo. Isso é necessário porque a CryptoAPI do Linux permite que a prioridade a seleção baseada em nuvem seja desviada, e um algoritmo de menor prioridade seja selecionada.
Algoritmos incluídos no módulo
Todos os algoritmos incluídos no módulo FIPS 140-3 estão listados abaixo.
Isso se aplica aos seguintes formatos: android12-5.10
, android13-5.10
, android13-5.15
As ramificações de kernel android14-5.15
, android14-6.1
e android15-6.6
as diferenças entre as versões do kernel são observadas quando apropriado.
Algoritmo | Implementações | Aprovável | Definição |
---|---|---|---|
aes |
aes-generic , aes-arm64 , aes-ce , biblioteca do 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 suportados. Além da implementação da biblioteca, todas as implementações 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 últimos blocos de texto criptografado são trocados incondicionalmente.Todos os tamanhos de chave AES são compatíveis.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 suportados. 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: no kernel versão 6.1 e anteriores, todos os tamanhos de chave AES são compatíveis; No kernel versão 6.6 e superior, apenas AES-128 e AES-256 são suportados. 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 com a primeira e a segunda metades iguais são rejeitadas. |
gcm(aes) |
gcm (modelo), gcm-aes-ce |
Não1 | AES-GCM: todos os tamanhos de chave AES são suportados. 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 de hash criptográfica SHA-224: o código é compartilhado com o 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 ao SHA-256, além da interface padrão da CryptoAPI. Esta interface de biblioteca usa uma implementação diferente. |
sha384 |
sha384-generic , sha384-arm64 , sha384-ce |
Sim | Função de hash criptográfica SHA-384: o código é compartilhado com o SHA-512. |
sha512 |
sha512-generic , sha512-arm64 , sha512-ce |
Sim | Função de hash criptográfico SHA-512 |
sha3-224 |
sha3-224-generic |
Sim | Função hash criptográfica SHA3-224. Presente apenas no kernel versão 6.6 e superior. |
sha3-256 |
sha3-256-generic |
Sim | Igual ao anterior, mas com tamanho 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 tamanho 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 um 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 mensagem de hash com chave): o modelo hmac pode ser composto com qualquer implementação ou algoritmo 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 hash nomeada e com 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 do 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 . No kernel versão 5.15 e mais recentes, ele é drbg_pr_hmac_sha512 . |
jitterentropy_rng |
jitterentropy_rng |
Não | O Jitter RNG, a versão 2.2.0 (kernel versão 6.1 e anteriores) ou 3.4.0 (kernel versão 6.6 e mais recentes). Os usuários dessa interface recebem as próprias instâncias de RNG de instabilidade. Eles 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 no kernel versão 5.15 e 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 a partir da origem
Para o Android 14 e versões mais recentes (incluindo
android-mainline
), crie o módulo fips140.ko
a partir da origem usando o
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 executam um build completo, incluindo o kernel e a fips140.ko
com o conteúdo do resumo HMAC-SHA256 incorporado.
Orientação ao usuário final
Orientação para oficial de criptografia
Para operar o módulo do kernel, o sistema operacional deve estar restrito a uma modo de operação de operador único. Isso é processado automaticamente pelo Android usando um hardware de gerenciamento de memória.
O módulo do kernel não pode ser instalado separadamente. ela é incluída como parte firmware do dispositivo e carregados automaticamente na inicialização. Ele só opera em uma e aprovado.
O Crypto Officer pode fazer com que os autotestes sejam executados a qualquer momento reiniciando o dispositivo.
Orientação do 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 o uso de algoritmos e não armazena parâmetros além do tempo para executar uma operação criptográfica.
O uso dos algoritmos para fins de conformidade com o FIPS é limitado aos requisitos
algoritmos. Para satisfazer o "indicador de serviço" do FIPS 140-3 requisito, o
fornece uma função fips140_is_approved_service
, que indica se
quando um algoritmo é aprovado.
Erros de autoteste
Em caso de falha no autoteste, o módulo do kernel faz com que ele entrar em pânico e o dispositivo não continua a inicializar. Se a reinicialização do dispositivo não resolver o problema, o dispositivo deve ser inicializado no modo de recuperação para corrigir o o problema ao atualizar o dispositivo novamente.
-
Espera-se que as implementações AES-GCM do módulo possam ser "algoritmos" aprovado" mas não "módulo aprovado". Eles podem ser validados, mas o AES-GCM não pode ser considerado um algoritmo aprovado do ponto de vista do módulo do FIPS. Isso ocorre porque os requisitos de módulo FIPS para o GCM são incompatíveis com Implementações do GCM que não geram seus próprios IVs. ↩