FIPS 140 - FIPS 140

A série 140 de Federal Information Processing Standards ( FIPS ) são padrões de segurança de computador do governo dos EUA que especificam requisitos para módulos de criptografia .

A partir de outubro de 2020, FIPS 140-2 e FIPS 140-3 são aceitos como atuais e ativos. O FIPS 140-3 foi aprovado em 22 de março de 2019 como sucessor do FIPS 140-2 e entrou em vigor em 22 de setembro de 2019. Os testes do FIPS 140-3 começaram em 22 de setembro de 2020, embora nenhum certificado de validação FIPS 140-3 tenha sido emitido ainda. O teste FIPS 140-2 ainda está disponível até 21 de setembro de 2021 (posteriormente alterado para aplicativos já em andamento até 1º de abril de 2022), criando um período de transição sobreposto de um ano. Os relatórios de teste FIPS 140-2 que permanecem na fila CMVP ainda receberão validações após essa data, mas todas as validações FIPS 140-2 serão movidas para a Lista histórica em 21 de setembro de 2026, independentemente de sua data de validação final real.

Objetivo do FIPS 140

O Instituto Nacional de Padrões e Tecnologia (NIST) emite a 140 Publicação Series para coordenar os requisitos e padrões para módulos criptográficos que incluem componentes de hardware e software para uso por departamentos e agências do governo federal dos Estados Unidos . O FIPS 140 não pretende fornecer condições suficientes para garantir que um módulo em conformidade com seus requisitos seja seguro, muito menos que um sistema construído usando tais módulos seja seguro. Os requisitos cobrem não apenas os próprios módulos criptográficos, mas também sua documentação e (no nível de segurança mais alto) alguns aspectos dos comentários contidos no código-fonte.

Agências de usuários que desejam implementar módulos criptográficos devem confirmar se o módulo que estão usando é coberto por um certificado de validação existente. Os certificados de validação FIPS 140-1 e FIPS 140-2 especificam o nome exato do módulo, hardware, software, firmware e / ou números de versão do miniaplicativo. Para os níveis 2 e superiores, a plataforma operacional na qual a validação é aplicável também é listada. Os fornecedores nem sempre mantêm suas validações de linha de base.

O Programa de Validação de Módulo Criptográfico (CMVP) é operado em conjunto pela Divisão de Segurança de Computadores do Instituto Nacional de Padrões e Tecnologia (NIST) do Governo dos Estados Unidos e pelo Estabelecimento de Segurança de Comunicações (CSE) do Governo do Canadá. O uso de módulos criptográficos validados é exigido pelo Governo dos Estados Unidos para todos os usos não classificados de criptografia. O Governo do Canadá também recomenda o uso de módulos criptográficos validados pelo FIPS 140 em aplicações não classificadas de seus departamentos.

Níveis de segurança

O FIPS 140-2 define quatro níveis de segurança, simplesmente chamados de "Nível 1" a "Nível 4". Ele não especifica em detalhes qual nível de segurança é exigido por qualquer aplicativo específico.

  • FIPS 140-2 Nível 1 o mais baixo, impõe requisitos muito limitados; vagamente, todos os componentes devem ser de "nível de produção" e vários tipos flagrantes de insegurança devem estar ausentes.
  • O FIPS 140-2 Nível 2 adiciona requisitos para evidência de violação física e autenticação baseada em função.
  • FIPS 140-2 Nível 3 adiciona requisitos de resistência física à violação (tornando difícil para os invasores obterem acesso às informações confidenciais contidas no módulo) e autenticação baseada em identidade, e para uma separação física ou lógica entre as interfaces pelas quais " parâmetros de segurança "entram e saem do módulo e de suas outras interfaces.
  • O FIPS 140-2 Nível 4 torna os requisitos de segurança física mais rigorosos e exige robustez contra ataques ambientais.

Além dos níveis especificados, a Seção 4.1.1 da especificação descreve ataques adicionais que podem exigir mitigação, como análise de poder diferencial. Se um produto contém contramedidas contra esses ataques, eles devem ser documentados e testados, mas as proteções não são necessárias para atingir um determinado nível. Assim, uma crítica do FIPS 140-2 é que o padrão dá uma falsa sensação de segurança nos Níveis 2 e acima, porque o padrão implica que os módulos serão invioláveis ​​e / ou resistentes a adulteração, embora os módulos possam ter canal lateral vulnerabilidades que permitem a extração simples de chaves.

Escopo dos requisitos

O FIPS 140 impõe requisitos em onze áreas diferentes:

  • Especificação do módulo criptográfico (o que deve ser documentado)
  • Portas e interfaces do módulo criptográfico (quais informações entram e saem e como devem ser segregadas)
  • Funções, serviços e autenticação (quem pode fazer o quê com o módulo e como isso é verificado)
  • Modelo de estado finito (documentação dos estados de alto nível em que o módulo pode estar e como as transições ocorrem)
  • Segurança física ( evidência de violação e resistência e robustez contra condições ambientais extremas)
  • Ambiente operacional (que tipo de sistema operacional o módulo usa e pelo qual é usado)
  • Gerenciamento de chaves criptográficas (geração, entrada, saída, armazenamento e destruição de chaves)
  • EMI / EMC
  • Autotestes (o que deve ser testado e quando, e o que deve ser feito se um teste falhar)
  • Garantia de design (qual documentação deve ser fornecida para demonstrar que o módulo foi bem projetado e implementado)
  • Mitigação de outros ataques (se um módulo é projetado para mitigar, digamos, ataques TEMPEST , então sua documentação deve dizer como)

Breve história

O FIPS 140-1, emitido em 11 de janeiro de 1994, foi desenvolvido por um grupo de trabalho do governo e da indústria, composto por fornecedores e usuários de equipamentos criptográficos. O grupo identificou os quatro "níveis de segurança" e onze "áreas de requisitos" listados acima, e os requisitos especificados para cada área em cada nível.

O FIPS 140-2 , emitido em 25 de maio de 2001, leva em consideração as mudanças na tecnologia disponível e nos padrões oficiais desde 1994, e os comentários recebidos do fornecedor, testador e comunidades de usuários. Foi o principal documento de entrada para o padrão internacional ISO / IEC 19790 : 2006 Requisitos de segurança para módulos criptográficos, emitido em 1 de março de 2006. O NIST emitiu a Publicação Especial 800-29 descrevendo as mudanças significativas de FIPS 140-1 para FIPS 140-2.

O FIPS 140-3 , emitido em 22 de março de 2019 e anunciado em maio de 2019 está atualmente no período de transição sobreposto para substituir o FIPS 140-2 e alinha a orientação do NIST em torno de dois documentos de padrões internacionais: ISO / IEC 19790: 2012 (E) Tecnologia da informação - Técnicas de segurança - Requisitos de segurança para módulos criptográficos e ISO / IEC 24759: 2017 (E) Tecnologia da informação - Técnicas de segurança - Requisitos de teste para módulos criptográficos . Na primeira versão preliminar do padrão FIPS 140-3, o NIST introduziu uma nova seção de segurança de software, um nível adicional de garantia (Nível 5) e novos requisitos de Análise de Potência Simples (SPA) e Análise de Potência Diferencial (DPA). O rascunho emitido em 11 de setembro de 2009, no entanto, foi revertido para quatro níveis de segurança e limita os níveis de segurança do software aos níveis 1 e 2.

Crítica

Devido à forma como o processo de validação é configurado, um fornecedor de software é obrigado a revalidar seu módulo validado por FIPS para cada alteração, não importa quão pequena, no software; esta revalidação é necessária mesmo para bugs óbvios ou correções de segurança. Como a validação é um processo caro, isso dá aos fornecedores de software um incentivo para adiar alterações em seu software e pode resultar em software que não receberá atualizações de segurança até a próxima validação. O resultado pode ser que o software validado seja menos seguro do que um equivalente não validado.

Essa crítica foi refutada mais recentemente por alguns especialistas do setor que, em vez disso, atribuíram ao fornecedor a responsabilidade de estreitar seus limites de validação. Como a maioria dos esforços de revalidação são acionados por bugs e correções de segurança fora das operações criptográficas principais, uma validação com escopo adequado não está sujeita à revalidação comum, conforme descrito.

Veja também

Referências

links externos