O que é PKI?

PKI é um acrônimo para infraestrutura de chave pública, que é a tecnologia por trás dos certificados digitais. Um certificado digital cumpre um propósito semelhante a uma carteira de motorista ou passaporte – é uma peça de identificação que prova sua identidade e fornece certas permissões. Um certificado digital permite que seu proprietário criptografe, assine e autentique. Da mesma forma, PKI é a tecnologia que permite criptografar dados, assinar documentos digitalmente e autenticar-se usando certificados.

Existem vários requisitos que as empresas têm em relação à implementação de infraestruturas de chave pública eficazes. Em primeiro lugar, se os usuários não puderem tirar proveito da criptografia e das assinaturas digitais nos aplicativos, uma PKI não terá valor. Consequentemente, a restrição mais importante em uma PKI é a transparência. O termo transparência significa que os usuários não precisam entender como a PKI gerencia chaves e certificados para aproveitar as vantagens dos serviços de criptografia e assinatura digital. Uma PKI eficaz é transparente. Além da transparência do usuário, uma empresa deve implementar os seguintes itens em uma PKI para fornecer os serviços de gerenciamento de chave e certificado necessários:

• Certificados de chave pública
• Um repositório de certificados
• Revogação do certificado
• Backups e recuperação de chaves
• Suporte para não repúdio de assinaturas digitais
• Atualização automática de pares de chaves e certificados
• Gestão de histórias importantes
• Suporte para certificação cruzada
• Software do lado do cliente interagindo com todos os itens acima de maneira segura, consistente e confiável

Notas: O termo “lado do cliente” refere-se a clientes de aplicativos e servidores de aplicativos. Os requisitos de PKI são os mesmos para clientes e servidores de aplicativos e ambos são “clientes” dos serviços de infraestrutura.

Todos esses requisitos também devem ser atendidos para ter uma PKI automática, transparente e utilizável.

Para que a criptografia de chave pública seja valiosa, os usuários devem ter certeza de que as outras partes com as quais se comunicam são “seguras” – ou seja, suas identidades e chaves são válidas e confiáveis. Para fornecer essa garantia, todos os usuários de uma PKI devem ter uma identidade registrada.

Essas identidades são armazenadas em um formato de certificado de chave pública digital padrão X.509. As autoridades de certificação (CAs) representam as pessoas, processos e ferramentas para criar certificados digitais que vinculam com segurança os nomes dos usuários às suas chaves públicas. Ao criar certificados, as CAs atuam como agentes de confiança em uma PKI. Contanto que os usuários confiem em uma CA e em suas políticas de negócios para emitir e gerenciar certificados, eles podem confiar nos certificados emitidos pela CA. Isso é conhecido como confiança de terceiros.

As CAs criam certificados para usuários assinando digitalmente um conjunto de dados que inclui as seguintes informações (e itens adicionais):

1. O nome do usuário no formato de um nome distinto (DN). O DN especifica o nome do usuário e quaisquer atributos adicionais necessários para identificar exclusivamente o usuário (por exemplo, o DN pode conter o número de funcionário do usuário).
2. Uma chave pública do usuário. A chave pública é necessária para que outras pessoas possam criptografar para o usuário ou verificar a assinatura digital do usuário.
3. O período de validade (ou vida) do certificado (uma data de início e uma data de término).
4. As operações específicas para as quais a chave pública deve ser usada (seja para criptografar dados, verificar assinaturas digitais ou ambos).

A assinatura da CA em um certificado significa que qualquer violação do conteúdo do certificado será facilmente detectada. A assinatura do CA em um certificado é como um selo de detecção de violação em um frasco de pílulas – qualquer violação do conteúdo de um certificado é facilmente detectada. Contanto que a assinatura da CA em um certificado possa ser verificada, o certificado tem integridade. Uma vez que a integridade de um certificado pode ser determinada pela verificação da assinatura da CA, os certificados são inerentemente seguros e podem ser distribuídos de uma maneira completamente pública (por exemplo, por meio de sistemas de diretório acessíveis ao público).

Os usuários que recuperam uma chave pública de um certificado podem ter certeza de que a chave pública é válida. Ou seja, os usuários podem confiar que o certificado e sua chave pública associada pertencem à entidade especificada pelo nome distinto. Os usuários também confiam que a chave pública ainda está dentro do período de validade definido. Além disso, os usuários têm a garantia de que a chave pública pode ser usada com segurança da maneira para a qual foi certificada pela CA.

PKI é uma parte crítica da espinha dorsal estratégica de TI. A PKI é importante porque a tecnologia baseada em certificado ajuda as organizações a estabelecer assinatura, criptografia e identidade confiáveis entre pessoas, sistemas e coisas.

Com os modelos de negócios se tornando mais dependentes de transações eletrônicas e documentos digitais, e com mais dispositivos que podem se conectar à Internet na redes corporativas, o papel de uma infraestrutura de chaves públicas não está mais limitado a sistemas isolados, tais como e‑mail seguro, cartões inteligentes para acesso físico ou tráfego web criptografado. Atualmente se espera que as PKIs suportem um maior número de aplicativos, usuários e dispositivos em ecossistemas complexos. Com as normas de segurança de dados governamentais e industriais mais rigorosas, os principais sistemas operacionais e aplicativos comerciais estão se tornando mais dependentes do que nunca de PKIs para garantir a confiança.

O que é autoridade certificadora ou roubo de chave privada de raiz?

O roubo da autoridade certificadora (CA) ou da chave privada de raiz permite que o invasor assuma o controle da infraestrutura de chaves públicas (PKI) de uma organização e emita certificados falsos, como aconteceu no ataque Stuxnet. Qualquer comprometimento desse tipo pode forçar a revogação e a reemissão de alguns ou de todos os certificados emitidos anteriormente. Um comprometimento de raiz, como um roubo de chave privada, destrói a confiança na PKI e pode facilmente obrigar a restabelecer uma nova raiz e uma subsidiária que emite infraestrutura de AC. Isso pode ser muito caro, além de prejudicar a identidade corporativa da empresa.

A integridade das chaves privadas de uma organização em toda a infraestrutura, desde a raiz até a emissão de ACs, fornece a base de confiança essencial da PKI e, como tal, deve ser protegida. A melhor prática reconhecida para proteger essas chaves fundamentais é usar um módulo de segurança de hardware (HSM) com certificado FIPS 140‑2 Nível 3, um dispositivo com proteção inviolável que atende aos mais altos padrões de segurança e garantia.

PKI e SSL, embora diferentes, são ambas soluções baseadas em certificados que estabelecem “confiança” com certificados emitidos por uma autoridade de certificação (CA) – seja ela pública (SSL) ou privada (PKI).

PKI é uma estrutura completa que consiste em hardware, software, políticas e muito mais. Uma PKI também inclui uma CA, que emite os certificados digitais para estabelecer a confiança. Normalmente, esse CA é governado internamente de acordo com políticas e procedimentos que se alinham com os níveis de segurança e garantia exigidos da organização.

SSL é um dos principais casos de uso de PKI. Também envolve uma CA que emite certificados, mas deve ser reconhecida pelos navegadores como uma CA publicamente confiável. E embora haja muitos casos de uso para PKI, o objetivo do SSL é proteger dados confidenciais transferidos por meio de comunicações on-line, como transações bancárias on-line ou de comércio eletrônico.

Os principais casos de uso de PKI podem ser determinados observando-se os aplicativos que mais comumente usam certificados digitais, como:

Casos de uso tradicionais

Estas aplicações comerciais críticas deixam claro que a PKI é uma parte estratégica da espinha dorsal da TI central.

• Certificados SSL para sites e serviços públicos
• Redes privadas e redes privadas virtuais (VPNs)
• Programas e serviços de nuvem pública
• Aplicativos baseados em nuvem privada
• Segurança de e-mail
• Autenticação do usuário de empresa
• Autenticação de dispositivos
• Autenticação privada baseada na nuvem
• Assinatura de documento/mensagem
• Code signing

(Veja detalhes no quadro abaixo).

Casos de uso novos e emergentes

Também houve uma retomada da PKI a partir de casos de uso relacionados ao DevOps, que estão impulsionando uma maior adoção, por exemplo:

• Serviços baseados em nuvem
• Consumidor móvel
• Internet das coisas (IoT)
• Aplicações móveis orientadas ao consumidor
• Políticas de trazer o seu próprio dispositivo (BYOD) e gerenciamento de dispositivos móveis internos
• e-commerce

(Veja detalhes no quadro abaixo).

E alguns especialistas estão prevendo casos de uso futuros conforme a tecnologia e a inteligência artificial se tornam ainda mais avançadas.

A diferença entre as chaves privadas e públicas é que uma é usada para criptografar, enquanto a outra é usada para descriptografar.

Uma chave pública é usada para criptografar informações, basicamente tornando-as ilegíveis para qualquer pessoa que não seja o destinatário pretendido. Então, esse destinatário mantém uma chave privada com a qual é capaz de descriptografar as informações.

Além disso, uma chave pública está disponível publicamente para um conjunto de usuários que precisam enviar informações confidencialmente. Por exemplo, a chave pública de alguém estaria disponível para seus colegas dentro de uma organização por meio de um diretório compartilhado. Por outro lado, uma chave privada é acessível apenas pela pessoa que recebe as informações e, portanto, seria a única pessoa capaz de descriptografar com êxito o que foi criptografado.

Juntas, as chaves públicas e privadas garantem que as informações, dados e comunicações sejam criptografados antes de serem transmitidos e descriptografados com segurança pela parte apropriada.

Uma empresa deve ser capaz de recuperar dados criptografados quando os usuários perdem suas chaves de descriptografia. Isso significa que a empresa à qual o usuário pertence requer um sistema para fazer backup e recuperar as chaves de descriptografia.

Existem dois motivos pelos quais o backup e a recuperação de chave são tão importantes para as empresas:

1. Os usuários esquecem as senhas. É potencialmente catastrófico para uma empresa perder dados quando os usuários esquecem as senhas necessárias para acessar suas chaves de descriptografia. Informações valiosas seriam perdidas para sempre se não houvesse a capacidade de recuperar essas chaves com segurança. Além disso, a menos que os usuários saibam que sempre podem recuperar seus dados criptografados (mesmo se esquecerem suas senhas), alguns usuários não criptografam suas informações mais valiosas e confidenciais por medo de perdê-las – embora essas informações precisem ser protegidas ao máximo.
2. Os usuários podem perder, quebrar ou corromper os dispositivos nos quais suas chaves de descriptografia estão armazenadas. Por exemplo, se as chaves de descriptografia de um usuário são armazenadas em um cartão magnético, o campo magnético no cartão pode ser corrompido. Novamente, a perda permanente dessas chaves de descriptografia pode ser desastrosa. Os usuários são impedidos de recuperar dados criptografados, a menos que seja feito backup de suas chaves de descriptografia.

A diferença entre backup de chaves e a custódia de chaves

Os requisitos comerciais para backup e recuperação de chaves podem ser completamente independentes dos requisitos de aplicação da lei para custódia de chaves, um tópico amplamente discutido na mídia.

• A custódia de chaves significa que um terceiro (como um agente federal) pode obter as chaves de descriptografia necessárias para acessar as informações criptografadas. O objetivo do depósito de chaves é ajudar na aplicação da lei e é amplamente debatido por causa da linha tênue entre o interesse público (como a segurança nacional) e a liberdade e privacidade individuais.
• Os principais requisitos de backup e recuperação se concentram nas necessidades comerciais fundamentais existentes, independentemente dos requisitos de aplicação da lei.

Quais chaves requerem backup?

As únicas chaves que exigem backup são as chaves de descriptografia do usuário. Contanto que um agente confiável (por exemplo, a CA) faça backup com segurança das chaves de descriptografia dos usuários, a segurança não é comprometida e os dados do usuário sempre podem ser recuperados. No entanto, as chaves de assinatura têm requisitos diferentes das chaves de descriptografia. Na verdade, como a próxima seção descreve, o backup das chaves de assinatura destrói um requisito básico de uma PKI.

O repúdio ocorre quando um indivíduo nega envolvimento em uma transação. Por exemplo, quando alguém alega que um cartão de crédito foi roubado, ele ou ela está repudiando a responsabilidade por transações que ocorram com aquele cartão a qualquer momento após relatar o roubo.

O não repúdio significa que um indivíduo não pode negar com sucesso o envolvimento em uma transação. No mundo do papel, a assinatura de um indivíduo o vincula legalmente às suas transações (cobranças de cartão de crédito, contratos comerciais, etc.). A assinatura impede o repúdio dessas transações.

No mundo eletrônico, a substituição da assinatura baseada em caneta é uma assinatura digital. Todos os tipos de comércio eletrônico exigem assinaturas digitais porque o comércio eletrônico torna obsoletas as assinaturas tradicionais baseadas em caneta.

A chave privada de assinatura

O requisito mais básico para não repúdio é que a chave utilizada para criar assinaturas digitais – a chave de assinatura – seja gerada e armazenada de forma segura, de modo que esteja sempre sob o controle exclusivo do usuário. Não é aceitável fazer backup da chave de assinatura. Ao contrário dos pares de chaves de criptografia, não há requisitos técnicos ou comerciais para fazer backup ou restaurar pares de chaves de assinatura anteriores quando os usuários esquecem suas senhas ou perdem, quebram ou corrompem suas chaves de assinatura. Nesses casos, é aceitável que os usuários gerem novos pares de chaves de assinatura e continuem a usá-los a partir de então.

A necessidade de dois pares de chaves

É difícil oferecer suporte simultâneo ao backup e à recuperação de chaves e para o não repúdio. Para oferecer suporte ao backup e recuperação de chaves, o backup das chaves de descriptografia deve ser feito com segurança. Mas para suportar o não repúdio, as chaves usadas para assinatura digital não podem ser copiadas e devem estar sob o controle exclusivo do usuário o tempo todo.

Para atender a esses requisitos, uma PKI deve oferecer suporte a dois pares de chaves para cada usuário. A qualquer momento, um usuário deve ter um par de chaves atual para criptografia e descriptografia e um segundo par de chaves para assinatura digital e verificação de assinatura. Com o tempo, os usuários terão vários pares de chaves que devem ser gerenciados de maneira adequada.

Os pares de chaves criptográficas não devem ser usados para sempre – eles devem ser atualizados com o tempo. Como resultado, toda organização precisa considerar duas questões importantes:

1. Atualização de pares de chaves dos usuários – O processo de atualização dos pares de chaves deve ser transparente para os usuários. Essa transparência significa que os usuários não precisam entender qual atualização de chave precisa ocorrer e eles nunca terão uma “negação de serviço” porque suas chaves não são mais válidas. Para garantir a transparência e evitar a negação de serviço, os pares de chaves dos usuários devem ser atualizados automaticamente antes de expirarem.
2. Preservação, quando apropriado, do histórico dos pares de chaves anteriores – Quando os pares de chaves de criptografia são atualizados, o histórico das chaves de descriptografia anteriores deve ser mantido. Este “histórico de chaves” permite que os usuários acessem qualquer uma de suas chaves de descriptografia anteriores para descriptografar dados. (Quando os dados são criptografados com a chave de criptografia de um usuário, apenas a chave de descriptografia correspondente – a chave emparelhada – pode ser usada para descriptografar). Para garantir a transparência, o software do lado do cliente deve gerenciar automaticamente os históricos de chaves de descriptografia dos usuários.

O histórico de chaves também deve ser gerenciado com segurança pelo sistema de backup e recuperação de chaves. Isso permite que os dados criptografados sejam recuperados com segurança, independentemente de qual chave pública de criptografia foi usada para criptografar originalmente os dados (e, por extensão, independentemente de quando os dados foram criptografados).

Quando um par de chaves de assinatura é atualizado, a chave de assinatura anterior deve ser destruída com segurança. Isso evita que qualquer outra pessoa tenha acesso à chave de assinatura e é aceitável porque não há necessidade de reter as chaves de assinatura anteriores.

Conforme mencionado anteriormente, a CA atua como um terceiro confiável, emitindo certificados aos usuários. As empresas também devem distribuir esses certificados para que possam ser usados pelos aplicativos. Os repositórios de certificados armazenam certificados para que os aplicativos possam recuperá-los em nome dos usuários.

O termo “repositório” refere-se a um serviço de rede que permite a distribuição de certificados. Nos últimos anos, o consenso na indústria de TI é que a melhor tecnologia para repositórios de certificados é fornecida por sistemas de diretório que são compatíveis com LDAP (Lightweight Directory Access Protocol). O LDAP define o protocolo padrão para acessar os sistemas de diretório.

Vários fatores impulsionam essa posição consensual:

• Armazenar certificados em diretórios e fazer com que os aplicativos recuperem certificados em nome dos usuários fornece a transparência necessária para uso na maioria das empresas
• Muitas tecnologias de diretório que suportam LDAP podem ser dimensionadas para:
  • suportar um grande número de entradas
  • responder de forma eficiente às solicitações de pesquisa devido aos seus métodos de armazenamento e recuperação de informações
  • ser distribuído por toda a rede para atender aos requisitos até mesmo das organizações mais distribuídas

Além disso, os diretórios que oferecem suporte à distribuição de certificados podem armazenar outras informações organizacionais. Conforme discutido na próxima seção, a PKI também pode usar o diretório para distribuir informações de revogação de certificado.

Além de verificar a assinatura da CA em um certificado (conforme discutido anteriormente em Quais são as funções dos certificados e autoridades de certificação?), O software aplicativo também deve ter certeza de que o certificado ainda é confiável no momento de uso. Os certificados que não são mais confiáveis devem ser revogados pela CA. Existem vários motivos pelos quais um certificado pode precisar ser revogado antes do final de seu período de validade. Por exemplo, a chave privada (a chave de assinatura ou a chave de descriptografia) correspondente à chave pública no certificado pode estar comprometida. Alternativamente, a política de segurança de uma organização pode determinar que os certificados de funcionários que deixam a organização devem ser revogados.

Nessas situações, os usuários do sistema devem ser informados de que o uso contínuo do certificado não é mais considerado seguro. O status de revogação de um certificado deve ser verificado antes de cada uso. Como resultado, uma PKI deve incorporar um sistema escalonável de revogação de certificado. O CA deve ser capaz de publicar com segurança informações sobre o status de cada certificado no sistema. O software aplicativo, em nome dos usuários, deve então verificar as informações de revogação antes de cada uso de um certificado.

A combinação de publicação e uso consistente de informações de revogação de certificados constitui um sistema completo de revogação. O meio mais popular para distribuir informações de revogação de certificado é a CA criar listas seguras de revogação de certificado (CRLs) e publicar essas CRLs em um sistema de diretório. CRLs especificam os números de série exclusivos de todos os certificados revogados.

Antes de usar um certificado, o aplicativo do lado do cliente deve verificar a CRL apropriada para determinar se o certificado ainda é confiável. Os aplicativos do lado do cliente devem verificar se há certificados revogados de forma consistente e transparente em nome dos usuários.

A certificação cruzada estende as relações de confiança de terceiros entre os domínios da Autoridade de certificação. Por exemplo, dois parceiros comerciais, cada um com sua própria CA, podem querer validar certificados emitidos pela CA do outro parceiro. Como alternativa, uma organização grande e distribuída pode exigir várias CAs em várias regiões geográficas. A certificação cruzada permite que diferentes domínios de CA estabeleçam e mantenham relacionamentos eletrônicos confiáveis.

O termo certificação cruzada se refere a duas operações:

1. Estabelecer uma relação de confiança entre duas CAs (executado com pouca frequência). No caso de certificação cruzada bilateral, duas CAs trocam com segurança suas chaves de verificação. Estas são as chaves usadas para verificar as assinaturas dos CAs nos certificados. Para concluir a operação, cada CA assina a chave de verificação da outra CA em um certificado denominado “certificado cruzado”.
2. Verificar a confiabilidade de um certificado de usuário assinado por uma CA com certificação cruzada (executado com frequência). Isto é. A operação, feita pelo software do lado do cliente, costuma ser chamada de “caminhar por uma cadeia de confiança”. A “cadeia” se refere a uma lista de validações de certificado cruzado que são “percorridas” (ou rastreadas) da chave CA do usuário verificador para a chave CA necessária para validar o certificado do outro usuário. Ao percorrer uma cadeia de certificados cruzados, cada certificado cruzado deve ser verificado para garantir que ainda seja confiável. Os certificados do usuário devem poder ser revogados; o mesmo deve acontecer com os certificados cruzados. Este requisito é frequentemente esquecido em discussões sobre certificação cruzada.

Ao discutir os requisitos para PKIs, as empresas frequentemente negligenciam os requisitos de software do lado do cliente. (Por exemplo, muitas pessoas se concentram apenas no componente CA ao discutir PKIs). Em última análise, no entanto, o valor de uma PKI está vinculado à capacidade dos usuários de usar criptografia e assinaturas digitais. Por esse motivo, a PKI deve incluir software do lado do cliente que opere de maneira consistente e transparente em todos os aplicativos da área de trabalho (e-mail, navegação na web, formulários eletrônicos, criptografia de arquivo/pasta etc.).

Uma implementação de PKI consistente e fácil de usar no software do lado do cliente reduz os custos operacionais da PKI. Além disso, o software do lado do cliente deve ser tecnologicamente habilitado para oferecer suporte a todos os elementos de uma PKI. A lista a seguir resume os requisitos que o software do lado do cliente deve atender para garantir que os usuários em uma empresa recebam uma PKI utilizável e transparente (e, portanto, aceitável).

• Certificados de chave pública Para fornecer confiança de terceiros, todos os aplicativos habilitados para PKI devem usar certificados de maneira consistente e confiável. O software do lado do cliente deve validar a assinatura da CA nos certificados e garantir que os certificados estejam dentro de seus períodos de validade.
• Backup e recuperação de chave Para garantir que os usuários fiquem protegidos contra perda de dados, a PKI deve oferecer suporte a um sistema para backup e recuperação de chaves de descriptografia. Com relação aos custos administrativos, é inaceitável que cada aplicativo forneça seu próprio backup e recuperação de chave. Em vez disso, todos os aplicativos clientes habilitados para PKI devem interagir com um único sistema de backup e recuperação de chave. As interações entre o software do lado do cliente e o sistema de backup e recuperação de chaves devem ser seguras e o método de interação deve ser consistente em todos os aplicativos habilitados para PKI.
• Suporte para não repúdio Para fornecer suporte básico para o não repúdio, o software do lado do cliente deve gerar os pares de chaves usados para assinatura digital. Além disso, o software do lado do cliente deve garantir que as chaves de assinatura nunca tenham backup e permaneçam sob o controle dos usuários o tempo todo. Esse tipo de suporte deve ser consistente em todos os aplicativos habilitados para PKI.
• Atualização automática dos pares de chaves Para permitir a transparência, os aplicativos do lado do cliente devem iniciar automaticamente a atualização dos pares de chaves dos usuários. Isso deve ser feito de acordo com as políticas de segurança da organização. É inaceitável que os usuários saibam que seus pares de chaves precisam ser atualizados. Para atender a esse requisito em todos os aplicativos habilitados para PKI, o software do lado do cliente deve atualizar os pares de chaves de maneira transparente e consistente.
• Gerenciamento de históricos de chaves Para permitir que os usuários acessem facilmente todos os dados criptografados para eles (independentemente de quando foram criptografados), os aplicativos habilitados para PKI devem ter acesso aos históricos de chaves dos usuários. E o software do lado do cliente deve ser capaz de recuperar com segurança os históricos principais dos usuários.
• Repositório de certificados escalonável Para minimizar os custos de distribuição de certificados, todos os aplicativos habilitados para PKI devem usar um repositório de certificados comum e escalonável.

Suporte a novas aplicações

Geralmente, é difícil usar PKI em aplicativos. De acordo com o Relatório de tendências de PKI e IoT de 2019 do Ponemon Institute, os dois desafios mais significativos que as organizações continuarão enfrentando, com relação à habilitação de aplicativos para usar PKI, são a incapacidade de um PKI existente de suportar novos aplicativos e a incapacidade de alterar aplicativos legados.

(Veja detalhes no quadro abaixo).

Falta de propriedade clara

A mesma pesquisa também constatou que o principal desafio de implantação de PKI continua sendo a falta de propriedade clara da função da PKI. Mas no ambiente de PKI de hoje, há uma necessidade de gerenciamento adequado, especialmente quando você considera:

• A infraestrutura é distribuída, com muitos certificados emitidos para muitas pessoas, lugares e coisas
• Precisamos proteger mais “coisas” agora do que nunca e lidar com certificados de vida mais curtos
• Os certificados protegem os aplicativos de negócios críticos, e as interrupções podem ser caras e difíceis de diagnosticar

Para obter a visibilidade adequada dos certificados em sua infraestrutura, ele ajuda não apenas a centralizar o gerenciamento de PKI em um departamento específico, mas também com uma ferramenta de software que fornece um único painel de vidro para monitoramento e relatórios de certificados.

Existem vários padrões e regulamentos diferentes, especialmente em nível regional e/ou governamental, mas as duas principais certificações de segurança mais importantes ao implantar PKI são:

• Common Criteria EAL Nível 4+
• FIPS 140-2 Nível 3