Enterprise edição

Validação de HSM e FIPS

Visão geral

A assinatura do NextPDF Enterprise conecta-se a módulos de segurança de hardware (HSMs) por meio do PKCS#11 e executa a criptografia com módulos validados pelos Federal Information Processing Standards (FIPS). A chave privada associada a uma assinatura permanece dentro de hardware certificado, e a criptografia é executada dentro de um módulo validado de forma independente. Você obtém as duas propriedades de garantia de que dependem os fluxos de trabalho de assinatura regulamentados e de alto valor.

Esta página apresenta provas e garantias para compradores. Ela explica os padrões seguidos pela integração de assinatura, as classes de dispositivos com as quais ela funciona, a postura de interoperabilidade e as evidências de validação que você pode solicitar antes de assumir o compromisso. Ela não descreve detalhes de implementação. Para uma visão geral da conformidade com os padrões, consulte Conformidade e compatibilidade.

Suporte a módulos de segurança de hardware

Um módulo de segurança de hardware é um dispositivo certificado que gera e mantém chaves privadas e executa operações criptográficas para você, de modo que o material da chave nunca sai do dispositivo. O NextPDF Enterprise assina por meio desses dispositivos usando PKCS#11. PKCS#11 é a interface de programação padrão amplamente adotada, também conhecida como Cryptoki, para dispositivos que mantêm informações criptográficas e executam funções criptográficas. Ele também define como as chaves são gerenciadas em um token criptográfico, o que permite que uma única integração padrão alcance uma ampla variedade de dispositivos.

Como a integração segue o PKCS#11 em vez de uma interface específica de fornecedor, ela funciona com as classes comuns de custódia de chaves em hardware:

HSMs de rede e de appliance usados para centralizar a custódia de chaves em frotas de serviços de assinatura.
Serviços de HSM em nuvem que apresentam uma interface PKCS#11 para aplicações executadas em um ambiente gerenciado.
Cartões inteligentes e tokens de assinatura usados quando um signatário mantém a chave em um dispositivo pessoal.

A custódia de chaves em hardware se combina com o perfil de assinatura de arquivamento de longo prazo, de modo que uma assinatura parte de uma chave protegida e permanece verificável por anos. Consulte Conformidade e compatibilidade para os perfis de assinatura e seus padrões.

Criptografia validada pelo FIPS

Para implantações com requisitos de garantia criptográfica, o NextPDF Enterprise opera com módulos criptográficos validados pelo FIPS. O FIPS 140-3 é o padrão dos Estados Unidos para requisitos de segurança de módulos criptográficos. Ele substitui o FIPS 140-2 e está alinhado ao padrão internacional ISO/IEC 19790.

A validação é um processo independente, não uma alegação do fornecedor. A conformidade de um módulo com os requisitos de segurança de módulos criptográficos é estabelecida por testes credenciados com base em um conjunto definido de asserções. A autoridade de validação mantém a lista dos módulos validados. Quando você usa um módulo validado, a criptografia por trás de uma assinatura é executada dentro de hardware que passou por esse processo independente, em vez de ser executada por código não verificado.

O NextPDF Enterprise não emite sua própria validação FIPS; ele opera com módulos validados para que a sua assinatura herde a garantia deles. O módulo aplicável depende do hardware ou do serviço em nuvem que você implanta.

Por que funciona assim

A integração tem como alvo a interface padrão PKCS#11, não uma API de fornecedor. Uma única integração padrão então alcança HSMs de rede, serviços de chaves em nuvem, cartões inteligentes e tokens de assinatura como uma classe. O NextPDF opera com módulos validados pelo FIPS em vez de emitir sua própria validação. A validação se vincula a um módulo criptográfico, não ao software que o invoca, portanto herdar a garantia de um módulo é a posição honesta e durável. A custódia de chaves para na fronteira do dispositivo, e a garantia que um comprador confirma é a validação publicada do módulo junto à autoridade de validação. Isso mantém o caminho de assinatura em conformidade com os padrões e neutro em relação a fornecedores, de modo que uma assinatura parte de uma chave protegida e permanece verificável de forma independente.

Contexto de projeto: Assinatura baseada em HSM.

Interoperabilidade e evidências de validação

O NextPDF Enterprise foi desenvolvido para interoperar com hardware em conformidade com os padrões, não com um único fornecedor. A postura de interoperabilidade é:

Interface padrão. A assinatura acessa o hardware por meio do padrão PKCS#11, de modo que dispositivos com uma interface em conformidade são suportados como uma classe.
Módulos validados. A criptografia é executada com módulos validados pelo FIPS cuja validação é estabelecida de forma independente.
Assinaturas baseadas em padrões. As assinaturas produzidas seguem os perfis baseline das PDF Advanced Electronic Signatures (PAdES), incluindo o nível de arquivamento de longo prazo para verificabilidade durável. Consulte Conformidade e compatibilidade.

Se você for um comprador ou auditor e precisar confirmar essas informações antes de assumir o compromisso, o NextPDF pode fornecer evidências mediante solicitação, incluindo:

As classes de módulos de segurança de hardware com as quais a integração de assinatura é testada e a postura de interoperabilidade para o dispositivo de destino.
Os módulos validados pelo FIPS em uso e como confirmar a validação deles junto à autoridade de validação.
Os perfis de assinatura produzidos e como um verificador independente os valida.

Solicite um relatório de validação

Para solicitar um relatório de validação ou discutir os requisitos de hardware e garantia antes de comprar, entre em contato com a equipe de vendas por meio do portal de licenças. Informe o módulo de segurança de hardware de destino ou o serviço de chaves em nuvem e o seu nível de garantia FIPS. Mapearemos esse requisito para as classes de dispositivos suportadas e as evidências de validação disponíveis para ele.

Limite de publicação

Esta página documenta apenas o comportamento observável externamente e a superfície pública de API suportada. Caminhos de namespace internos, classes auxiliares, tabelas de mecanismos, nomes de arquivos de runbook e prefixos de tíquetes estão fora do escopo.