Autores: Jennifer Brady e Apurva Varalikar

Até agora, apresentamos o cronograma esperado da transição planejada do FIPS 140-3 (Chave Datas FIPS 140-3) e os principais termos e definições que você precisa saber (Parte 1: Principais termos e definições). Hoje, nossa série de blogs continua com as diferenças entre FIPS 140-2 e FIPS 140-3. Esta postagem aborda as seções individuais do ISO / IEC 19790 / ISO / IEC 24759 (ao qual nos referiremos como FIPS 140-3) e identifica como eles são mapeados e diferem das seções do padrão FIPS 140-2 e IGs atuais . Esta postagem se concentrará nas três primeiras seções do FIPS 140-2 e IGs relacionados e nas seções da ISO / IEC 19790 7.2-7.4, ou seja, a Especificação do Módulo Criptográfico, Interfaces e Funções do Módulo Criptográfico e as seções Serviços e Autenticação, respectivamente.

Especificação do módulo criptográfico

Tipos de módulos criptográficos / Limite criptográfico

O padrão FIPS 140-2 (emitido em 2001) foi originalmente escrito com a ideia de que todos os módulos eram módulos de hardware. Só mais tarde é que diferentes tipos de módulos (híbrido, software e firmware) foram adicionados e definidos no IG (IGs 1.9, 1.16 e 1.17). Além disso, os módulos híbridos FIPS 140-2 IG 1.9 restringem a uma validação FIPS 140-2 Nível 1.

O FIPS 140-3 incluirá o módulo de hardware, módulo de firmware, módulo de software, módulo de software híbrido e módulo de firmware híbrido. Ele define explicitamente cada tipo de módulo na seção 7.2.2 do padrão. Também não há restrição quanto ao nível em que um módulo híbrido pode ser validado no novo padrão. Esta é uma ótima notícia para fornecedores com módulos híbridos que procuram ser validados em um nível superior ao nível 1!

Modos de operação

Dois novos termos; “Operação normal” e “Operação degradada” foram introduzidos no FIPS 140-3 19790 e observados no blog anterior.

Operação normal é onde a funcionalidade completa de um módulo criptográfico está disponível e / ou configurável, ou seja, todos os algoritmos, funções de segurança e serviços.

Operação degradada é onde um subconjunto da funcionalidade está disponível e / ou configurável como resultado da reconfiguração de um estado de erro.

Se um módulo suporta uma operação degradada, então o modo de operação só pode ser inserido quando o módulo sai de um estado de erro. O que isso significa? Um mecanismo ou função falhou e o módulo entrou no estado de erro e emite um indicador de erro. Uma vez em um estado de erro, o módulo que suporta esta operação degradada pode fazer a transição para o modo degradado de operação e continuar a operar com recursos reduzidos. Aqui estão alguns requisitos adicionais que você deve lembrar ao preparar seus módulos para o novo padrão. O módulo precisa fornecer informações de status quando o modo operacional degradado é inserido, a função que falhou precisa ser isolada, todos os autotestes condicionais devem ser realizados, antes do uso de qualquer função criptográfica no modo degradado e, por último, mas não menos importante, se houver uma tentativa, durante o modo de operação degradada, de usar um algoritmo, função de segurança ou processo não operacional; os serviços precisam indicar que tal tentativa foi feita.

Aqui está um comentário adicional sobre a operação degradada conforme declarado no FIPS 140-3. A frase final na seção 7.2.4.3 afirma “Se o módulo falhar nos autotestes pré-operacionais, o módulo não deve entrar em operação degradada”. Bem, espere, você diz, eu pensei que a operação degradada deveria ser usada quando algo como um autoteste falha, mas aqui está dizendo que você não pode entrar? Lembre-se, você só pode entrar no modo degradado a partir de um estado de erro. , o módulo deve primeiro entrar no estado de erro e depois entrar na operação degradada, ao mesmo tempo que atende aos outros requisitos conforme discutido acima.

Conceitos adicionais

Fique de olho no SP 800-140 documentos que a CMVP lançará nos próximos meses para ver se os IGs do FIPS 140-2 que não foram abordados na norma ISO 19790: 2012 / ISO 24759: 2014 são abordados em uma das publicações especiais. Vários IGs de a seção um pode ser absorvida por um manual de gerenciamento CMVP baseado na web, enquanto outras podem continuar a ser tratadas como IGs.

Interfaces do módulo criptográfico

O blog anterior abordou os tipos de interfaces introduzido no documento ISO (HMI: Hardware Module Interface, SFMI: Software ou Firmware Module Interface, HSMI : Interface de Módulo de Software Híbrido ou HFMI: Interface de Módulo de Firmware Híbrido), portanto, não vamos discutir isso neste momento. Em vez disso, vamos abordar as interfaces de entrada e saída.

Interfaces novas e tradicionais

O FIPS 140-2 e o FIPS 140-3 contêm: as quatro interfaces lógicas de entrada de dados, saída de dados, entrada de controle e saída de status. FIPS 140-3 apresenta uma quinta interface, chamada interface de saída de controle. Uma interface de saída de controle é usada para a saída de comandos. Sinais e dados de controle são usados para controlar ou indicar o estado de operação. Essa saída de controle pode ser uma informação enviada a outro módulo criptográfico. A interface de energia também é uma interface necessária em todos os módulos de software, exceto nos módulos.

Canal confiável

Outro conceito introduzido no FIPS 140-3 é o de “canal confiável”, que é semelhante ao conceito FIPS 140-2 de um “caminho confiável” (Seção 4.7.4 e IG 2.1). É um link de comunicação seguro entre o módulo criptográfico e o dispositivo de ponto final que está enviando dados e recebendo dados do módulo, com o objetivo de proteger CSPs desprotegidos.

Semelhante ao FIPS 140-2 IG 2.1, não há requisitos para o uso de um canal confiável para os níveis de segurança 1 e 2 no FIPS 140-3. O FIPS 140-3 tem vários requisitos para os níveis de segurança 3 e 4, como: CSPs de texto simples desprotegidos, componentes principais e dados de autenticação, que precisam usar um canal confiável ao serem transmitidos entre o módulo e um emissor / receptor. O canal confiável precisa evitar modificação, substituição e divulgação não autorizadas. Os serviços que usam um canal confiável precisam empregar autenticação baseada em identidade e o módulo deve fornecer um indicador de status ao usar o canal confiável.

O FIPS 140-3 impõe um requisito adicional para um módulo usando um canal confiável em nível de segurança 4 que não vimos no FIPS 140-2 ou IG 2.1 anterior. Um módulo de nível 4 usando um canal confiável deve usar autenticação baseada em identidade multifator para todos os serviços usando o canal confiável.

Funções, serviços e autenticação

Funções

O padrão FIPS 140-2 (seção 4.3.1) requer que um módulo suporte uma função de oficial de criptografia e uma função de usuário, e o suporte de uma função de manutenção era opcional. O FIPS 140-3 ainda tem essas mesmas três funções, mas apenas a função de oficial de criptografia é necessária (seção 7.4.2). A função de usuário e a função de manutenção agora são opcionais.

Serviços

Serviços necessários

Existem três serviços obrigatórios no padrão FIPS 140-2: mostrar status , realizar autotestes e funções de segurança aprovadas (seção 4.3.2). Esses mesmos três serviços são necessários no FIPS 140-3, além de dois serviços adicionais necessários: mostrar informações de versão dos módulos e executar a zeragem (seção 7.4.3.1). O “mostrar informações de versão do módulo” requer que o módulo criptográfico produza o nome / identificador do módulo e as informações de versão, que podem ser verificadas em um certificado de validação. As especificações do serviço de zeragem são definidas na seção 7.9.7 e serão abordadas em um blog futuro.

Serviço de bypass

Tanto o FIPS 140-2 quanto o FIPS 140-3 contêm o serviço de bypass opcional. O FIPS 140-3 menciona especificamente que um operador que pode configurar um bypass a capacidade no módulo deve assumir uma função autorizada. Embora o padrão FIPS 140-2 não afirme especificamente esse requisito, a maioria presumiu que a autenticação para uma função autorizada era necessária, já que o serviço poderia ser usado para divulgar CSPs e / afetar a segurança das informações protegidas pelo módulo (IG 3.1).

Saída criptográfica auto-iniciada

Um novo recurso, abordado no FIPS 140-3, é o “recurso de saída criptográfica auto-iniciada”. Aqui, o módulo pode realizar operações criptográficas ou outras funções de segurança aprovadas sem qualquer intervenção do operador. O crypto-officer pode configurar esse recurso, enquanto essa configuração pode ser persistente durante as reinicializações. Duas ações internas são necessárias para ativar o serviço e o módulo deve indicar que o serviço está ativado.

Carregamento de software / firmware

O carregamento de software / firmware é abordado no FIPS 140-2 padrão e no IG 9.7, no contexto do autoteste necessário ao carregar o software / firmware. O FIPS 140-2 não o trata como um serviço, como vemos no FIPS 140-3 (seção 7.4.3.4). Alguns dos requisitos que são declarados no documento incluem que, para o módulo permanecer um módulo validado, qualquer software / firmware carregado deve ser validado por uma autoridade de validação. Aqui, toda a saída de dados precisa ser inibida até que o software / firmware seja concluído com sucesso; o teste de carga de software / firmware deve ser executado antes que o código seja executado; o módulo não deve executar o código carregado até que os autotestes pré-operacionais tenham sido executados com sucesso e, por último, mas não menos importante, as informações de versão dos módulos devem ser atualizadas para refletir a adição / atualização do software / firmware.

Comentário adicional

Serviços não autenticados não são explicitamente endereçados no FIPS 140-3, então precisaremos ver se este conceito, que é abordado no IG 3.1 atual, é transportado em qualquer um dos documentos SP800-140. Mais sobre isso será abordado em blogs futuros.

Autenticação

FIPS 140-3 é semelhante ao FIPS 140-2 para autenticação nos níveis de segurança 1-3: (ISO 19790: Nível 1 – sem requisitos de autenticação; Nível 2 – autenticação baseada em função mínima; Nível 3 – autenticação baseada em identidade). A maior diferença é que para o nível 2, foi adicionado o acréscimo da palavra “mínimo”, que mapeia o esclarecimento que é abordado no IG 3.4. A autenticação de nível 4, no padrão FIPS 140-3 baseado em ISO, leva a autenticação até um nível, não apenas exigindo autenticação baseada em identidade. Para autenticação de nível 4, ela deve ser baseada em identidade multifatorial.

Alguns itens adicionais a serem observados nesta seção são que FIPS 140-2 especificou a força de autenticação exigida pelo módulo. A força não é definida em FIPS 140-3, mas deve ser especificada na política de segurança do módulo. Muito provavelmente, cada autoridade de validação incluirá uma força de autenticação em sua documentação adicional.

Os mecanismos de autenticação aprovados não podem ser implementados por procedimentos documentados ou regras de segurança (ou seja, política). Isso significa que as restrições de tamanho de senha devem ser configuradas e aplicadas pelo módulo. Isso pode afetar a maneira como vários dos módulos atuais operam. , esteja ciente disso ao preparar seus módulos para os requisitos ISO.

Em resumo

Há muito o que aprender sobre as diferenças entre FIPS 140-2 e FIPS 140-3. Embora haja uma infinidade de semelhanças, também há algumas mudanças. Nossa série sobre o assunto vai continuar, abordando uma nova área a cada postagem. Como sempre, se você tiver alguma dúvida, não hesite em nos contatar diretamente. Nossa equipe está sempre aqui para ajudar.