Criptografia e Certificação Digital_LIVRO-TEXTO III

Prévia do material em texto

107
CRIPTOGRAFIA E CERTIFICAÇÃO DIGITAL
Unidade III
5 GOVERNANÇA DAS CHAVES CRIPTOGRÁFICAS
5.1 Infraestrutura de chaves públicas – ICP
A ICP corresponde à PKI, nome dado ao conjunto de tecnologias, técnicas e procedimentos criado 
para gerar, validar e gerenciar certificados digitais baseado em chaves públicas, de forma escalonável, no 
âmbito individual, corporativo, governamental e até mundial, incluindo formas de unir uma identidade 
a uma determinada chave pública e também de fornecer meios de validar a autenticidade desse vínculo 
e gerenciar o ciclo de vida desses certificados digitais.
O modelo ICP utiliza o conceito de hierarquia para saber de quem é a chave privada incluída no 
certificado digital. Nesse modelo, é sempre algum tipo de autoridade, um governo, uma empresa ou um 
serviço de internet que assina os certificados. Para tanto, essa autoridade precisa de um par de chaves e 
deve garantir que sua chave privada seja mantida altamente protegida.
Figura 74 – Serviços suportados pela PKI
Para Wykes (2016), para que qualquer esquema de certificação funcione, é imprescindível que se 
tenha alto grau de confiança na AC (autoridade certificadora) responsável pela emissão dos certificados. 
Primeiramente, é necessário confiar que a AC assine somente certificados cujas informações de 
identificação são verídicas, sugerindo que deva haver algum processo para verificar as informações.
108
Unidade III
Por exemplo, a AC deveria efetuar algum processo de verificação de identidade da pessoa para quem 
será gerado um certificado, ou já deveria ter um cadastro dessas informações, como no caso de uma 
agência governamental. Em seguida, é necessário confiar que a AC mantém sua chave privada segura, 
fora do alcance de criminosos ou demais pessoas que poderão utilizá-la indevidamente para forjar ou 
fraudar certificados digitais.
Contudo, ainda assim resta o problema de como distribuir a chave pública da AC. Quando existem 
poucas autoridades, é mais fácil gerenciar essa distribuição, mas, conforme aumenta o número de ACs, 
a distribuição torna-se cada vez mais custosa.
Uma solução é delegar essa função para uma segunda autoridade, de tal forma que essa segunda 
autoridade certificará a primeira, por meio de um certificado digital emitido para a primeira, mas 
assinado pela chave privada da segunda. Assim, cria-se uma hierarquia de autoridades certificadoras e 
certificados digitais.
Hierarquias de certificados
A pedra fundamental do modelo PKI é a criação dessa cadeia de certificados, na qual cada certificado é 
assinado digitalmente pela chave privada pertencente ao nível superior da cadeia – lembrando que uma 
assinatura digital é feita utilizando a chave privada, e que a chave pública correspondente, distribuída 
por meio de um certificado, deve ser utilizada para validar a assinatura. Portanto, existem duas cadeias 
virtuais nas quais as chaves privadas sempre assinam os certificados de nível inferior, enquanto as 
chaves públicas do nível superior validam o certificado do nível inferior.
A raiz dessa hierarquia é uma única AC, a principal. Como não existe nenhuma AC superior a essa, 
não há ninguém para assinar seu certificado digital. Assim, ela mesma assina seu certificado, gerando 
um certificado digital autoassinado denominado certificado raiz, que serve como âncora para a cadeia 
inteira de certificados.
Com um certificado raiz, a assinatura serve apenas para garantir criptograficamente a integridade 
das informações contidas no certificado, incluindo obrigatoriamente a própria chave pública utilizada 
para sua validação. Segundo Wykes (2016), para se diferenciarem da AC raiz, as autoridades certificadoras 
subordinadas são denominadas ACs intermediárias, pelo papel de intermediação na cadeia entre o 
certificado raiz e os certificados dos usuários finais.
Embora tenhamos começado essa discussão a partir do problema do usuário final da ponta da 
cadeia, na prática tudo começa com a AC raiz, pois a emissão de uma cadeia de certificados deve se 
iniciar sempre na raiz.
Primeiramente, cria-se a AC raiz com seu certificado raiz, depois as intermediárias, e finalmente os 
certificados finais. Durante a emissão, inicia-se sempre pela AC raiz, mas, na validação de uma cadeia 
de certificados, o começo é sempre o certificado do usuário final, a partir do qual é criado um caminho, 
pelos certificados intermediários, até o certificado raiz.
109
CRIPTOGRAFIA E CERTIFICAÇÃO DIGITAL
Por meio desse processo de hierarquização, o problema de distribuição de, potencialmente, milhões 
de certificados digitais, com suas chaves públicas, acaba sendo reduzido a um único contratempo: como 
distribuir de forma segura o certificado raiz.
Embora nossa discussão tenha se focado em uma única cadeia de certificação, do usuário final 
até a raiz, uma entidade certificadora mundial ainda não foi de fato criada por motivos políticos e 
técnicos. Em consequência disso, deu-se origem a uma pluralidade de ACs raízes, governamentais 
e de organizações privadas, especializadas na comercialização de certificados digitais, cada qual com 
múltiplas ACs intermediárias.
Uma das soluções para garantir a autenticidade do emissor e receptor foi a criação de uma entidade 
que ateste a identidade do usuário, dando fé pública à sua chave pública e privada mediante a emissão 
de um certificado. Para isso, centraliza o repositório e a gestão das chaves, bem como a emissão de 
certificados, atribuindo prazo de validade a eles.
Essa entidade recebe o nome de autoridade certificadora (AC), pois certifica que os documentos 
apresentados pertencem ao solicitante do certificado e, portanto, garantem sua identidade. A autenticação 
é feita através da emissão de um documento digital no qual constam informações suficientes para que 
outros possam acreditar na identidade do possuidor do certificado.
Na prática, quem efetua a análise dos documentos do solicitante ao certificado é outra entidade, 
chamada de AR – autoridade de registro. Ela confere documentos e requisita que a AC emita o certificado. 
A AR efetua toda a parte física da geração do certificado, e a AC, a parte lógica.
Como deve haver a certeza da identidade do solicitante, é extremamente recomendável que haja a 
interação pessoal entre o representante da AR e o solicitante, a fim de que haja a correta identificação 
e autenticação do solicitante, evitando qualquer hipótese de dúvida sobre sua identidade.
A comparação com um cartório regular é coerente, pois em ambos ocorrem a certificação de documentos 
pela emissão de atestados de autenticidade e reconhecimento de identidades. Num cartório, o escrevente 
verifica e confere os documentos e a identidade do solicitante, conferindo a autenticação pela aposição de 
um selo, o qual é depois assinado pelo notário ou tabelião, dando fé pública às informações. No processo 
com AC e AR, o papel do escrevente cabe à AR e do notário ou tabelião, à AC.
Imagine que ao entrar no cartório, você entregou um documento que necessitava da fé pública e 
que ele pertence a você. No processo digital, algo similar ocorre, só que em vez de um documento físico, 
você entrega um arquivo digital de sua chave pública para receber o selo, a assinatura que dá fé ao 
arquivo. Essa será uma assinatura digital efetuada pela chave privada da AC.
Como no cartório regular, as pessoas podem ir até lá e confirmar se a assinatura colocada em um 
documento pertence a uma determinada pessoa. O cartório, quando reconhece a assinatura, efetua sua 
autenticação. Com as ACs é a mesma coisa, você pode verificar digitalmente que a chave pública de uma 
pessoa realmente pertence a ela apenas verificando o certificado e quem a emitiu. O documento eletrônico 
que permite todos esses trâmites de verificação e autenticação é conhecido como certificado digital.
110
Unidade III
Compete à AC emitir, expedir, distribuir, revogar e gerenciar os certificados digitais, bem como colocar 
à disposição dos usuários as listas de certificados digitais revogadose outras informações pertinentes, 
além de manter o registro de suas próprias operações.
Figura 75 – Exemplo de lista de cerificados digitais revogados – LCR
Nos documentos físicos, se não houver data, não há a localização temporal do momento em 
que foram assinados e quais leis vigoravam na época, ou o registro cronológico dos fatos ocorridos. 
Sem uma especificação temporal, fica difícil o posicionamento no tempo da ocorrência de fatos 
legais, ou em qual ordem cronológica ocorreram, o que alteraria a aplicação de penalidades ou 
exigências legais.
De modo semelhante, no mundo digital, deve-se aplicar a datação do documento. Contudo, 
equipamentos eletrônicos nem sempre estão atualizados com a correta data ou hora. Há também 
confusões quanto a fusos horários e disparidades ocorridas pela aplicação ou não do horário de verão, 
o que nem sempre ocorre de forma igual e no mesmo momento.
Para resolver esse problema no mundo virtual, foi criado o certificado de tempo, mais 
conhecido como carimbo de tempo (time stamp). Ele é atrelado a um relógio de precisão com 
reconhecimento internacional ou oficial do país que o administra, comumente conhecido como 
relógio atômico, e sua variação de atraso ou adiantamento é insignificante para as transações 
comerciais hoje realizadas.
111
CRIPTOGRAFIA E CERTIFICAÇÃO DIGITAL
NFe
NFe OK
1 – Contribuinte envia a 
Nota Fiscal eletrônica
1 – Sefaz verifica LCR 
do certificado
3 – Sefaz aguarda 
lista de LCR
3 – Sefaz responde
Autoridade 
de registro
Carimbo de 
tempo
Contribuinte SEFAZ
Sefaz
LCR
LCR
12
6
9 3
11
7
1
5
10
8
2
4
Figura 76 – Exemplo de autenticação Sefaz utilizando a LCR e registro de tempo
Cada país adota um relógio responsável pela hora oficial. No Brasil, é utilizado como gerador da hora 
oficial o relógio do Observatório Nacional, o qual possui conectado a si o equipamento gerador do carimbo 
de tempo que efetua o trabalho de datar os documentos com precisão. Esse equipamento está protegido 
por uma infraestrutura de chaves públicas para que seu certificado também tenha respaldo legal.
5.2 Certificado digital
Um certificado digital é um documento eletrônico que basicamente declara: “Eu garanto que esta 
chave pública particular está associada com um usuário específico, acredite em mim!”. Nele, podem-se 
identificar e validar vários elementos que atestam sua autenticidade e que dão fé pública, a saber: chave 
pública do titular; nome do titular, endereço de e-mail do titular; período de validade do certificado; 
nome da AC que emitiu o certificado; número de série e assinatura digital da AC.
Para Wykes (2016), os certificados digitais são documentos eletrônicos criados com o propósito de 
responder a uma pergunta muito importante: a quem pertence uma chave pública? Na essência, um 
certificado representa a associação entre essa chave e um conjunto de informações que, de alguma 
forma, identificam a pessoa ou entidade proprietária de um par de chaves.
É importante lembrar que uma identidade digital pode se referir a diversas categorias de entidade, 
além de pessoas e empresas, como equipamentos, servidores, aplicativos ou objetos inteligentes. E, sendo 
assim, são variadas as informações que se podem considerar necessárias para identificar ou caracterizar 
uma entidade, pois, dependendo da aplicação, pode ser um simples nome e endereço de e-mail, o 
endereço IP de um equipamento, um número de série de um cartão de débito, ou até as detalhadas 
informações pessoais de uma carteira de identidade civil.
Para Wykes (2016), os dois aspectos mais importantes de um certificado digital são que ele representa 
um elo confiável e facilmente verificável entre a chave pública e as informações de identificação. E isso 
significa que há sempre alguém, seja a própria entidade, um terceiro de confiança ou um grupo de 
pessoas ou equipamentos responsável por fornecer meios de confirmar a veracidade desse elo.
112
Unidade III
Antes de conhecer mais detalhes dos certificados digitais e dos diferentes modelos de confiança que 
existem, vamos analisar uma solução hipotética que, por sua simplicidade, permite entender melhor as 
principais funções de um sistema de certificados digitais.
5.2.1 Consulta on-line de identidade digital
Para Wykes (2016), essa solução seria a existência de um serviço on-line de consulta às identidades 
digitais. Para saber a quem pertence uma chave pública, bastaria enviá-la para o serviço e receber de 
volta as informações sobre seu proprietário.
Alternativamente, bastaria enviar algum dado de identificação de alguém e receber sua chave 
pública. Simplesmente funciona. E se o serviço tratasse adequadamente de questões de privacidade, 
disponibilidade e confiabilidade, sem se ater à questão de viabilidade financeira, realmente poderia ser 
uma ótima solução nessa era de conectividade 24 x 7.
 Observação
O termo 24 x 7 refere-se ao funcionamento sem interrupção dos serviços 
disponibilizados em qualquer hora do dia e em qualquer dia da semana.
A eventual indisponibilidade desse serviço, em caso de ausência de conectividade ou problemas 
técnicos, poderia ser bastante inconveniente para seus usuários. Já a questão de privacidade leva a 
questionamentos complexos e difíceis de responder sobre quem poderia acessá-lo. Seriam necessários 
meios para evitar que alguém consultasse o serviço e listasse todas as pessoas que possuem chaves 
públicas com determinados atributos, por exemplo.
Além disso, até que ponto esse serviço seria confiável? Como saber se manteria fielmente os vínculos 
entre chaves e entidades? Imagine um serviço desonesto ou cujos servidores de nuvem tivessem sido 
invadidos e que, ao ser consultado com as informações de determinada pessoa, retornasse a chave 
pública errada. E se a chave privada que corresponde à chave falsa devolvida estivesse nas mãos de 
criminosos ou de um governo que estivesse extrapolando seu papel, ferindo os direitos constitucionais 
daquele usuário?
Por fim, resta a questão sobre como custear tal serviço, que, por natureza, é um serviço de utilidade 
pública. Se tiver de cobrar de seus usuários pelo registro, vai parar de responder se o usuário deixar 
de pagar a conta? Ou será que se tornaria refém de uma busca incessante por maiores lucros? Há de se 
perguntar sobre quais os reais incentivos e fatores de motivação para tal serviço.
E, independentemente dessas questões, há um fator que predomina na discussão, pois o serviço 
on-line fará sentido somente se for possível confiar de fato em suas respostas. É nesse ponto que 
entra a criptografia.
113
CRIPTOGRAFIA E CERTIFICAÇÃO DIGITAL
Sabemos que uma forma segura de proferir autenticidade são as assinaturas digitais. Portanto, para 
criar um elo autenticável entre a chave pública e suas informações de identidade, esse serviço hipotético 
poderia gerar uma assinatura digital sobre a chave pública e as informações a ela vinculadas.
De modo geral, as informações associadas à determinada chave pública são sempre as mesmas e não 
parece muito eficiente assiná-las a cada solicitação. Assim, esse serviço hipotético poderia assiná-las 
uma vez e guardar o pacote assinado em um banco de dados.
Esse pacote seria chamado de certificado digital e conteria a chave pública da entidade, as informações 
a ela associadas e uma assinatura digital sobre ambas, anexada a elas. E o serviço on-line, em virtude de 
possuir o poder de criar esses certificados, poderia ser denominado autoridade certificadora.
Entretanto, ainda resta resolver um problema: como um usuário desse serviço poderia confiar no 
certificado recebido? Como averiguar que a resposta realmente veio da AC verdadeira, e não de algum 
outro servidor ou intruso na rede? Embora o pacote do certificado digital venha assinado, para verificar 
a assinatura, seria necessário ter a chave pública da AC em mãos.
Acabamos de trocar um problema por outro, com a diferença de que o novo problema é muito 
menor que o original, pois temos que nos preocupar com a veracidadeda chave pública de uma única 
autoridade certificadora, e não mais de todas as chaves públicas que pertencem ao nosso universo 
de entidades. Se, por exemplo, precisarmos de certificados para uma lista de 250 contatos de e-mail, 
para uma rede intranet composta de 5 mil equipamentos, ou para uma base de 10 milhões de clientes, 
ganhamos muito em termos de redução de complexidade.
Sobrou, então, apenas um último desafio: obter a chave pública da AC e guardá-la com segurança, 
garantindo sua integridade, para que ninguém possa trocá-la por outra chave pertencente a um serviço falso.
5.2.2 Avaliação da solução on-line
Por vários motivos, o serviço on-line parece uma solução interessante. Por um lado, facilita muito 
ter um ponto central para buscar informações sobre as chaves públicas e seus proprietários. Ao mesmo 
tempo, a criação e subsequente assinatura de certificados facilitou a validação da autenticidade de 
qualquer certificado recebido do serviço, pois, de posse da chave pública da AC, tornou-se igualmente 
fácil confiar na relação entre a chave pública contida no certificado e as informações associadas.
O certificado digital se adapta bem à utilização off-line, pois já contém as informações necessárias 
para identificar com segurança a quem pertence determinada chave, o que era nosso problema inicial. 
Assim, o contratempo de indisponibilidade do serviço fica parcialmente resolvido, pois basta guardar 
localmente uma cópia do certificado para uso futuro.
O uso off-line do certificado, no entanto, dificulta algumas funções bastante úteis, por exemplo, o 
cancelamento da chave pública pelo seu proprietário, na eventualidade de tê-la perdido, deletado ou de 
ela ter sido roubada. Na solução on-line, bastaria informar esse fato ao servidor para que ele passasse a 
recusar quaisquer consultas referentes àquela chave.
114
Unidade III
Por fim, resta um problema potencialmente mais grave do que todos: a obrigatoriedade de confiar 
cegamente na AC. Caso ela sofra uma invasão do sistema, um ataque interno, um roubo da chave de 
assinatura, ou tenha sido forçada em função de algum dispositivo legal a entregar uma cópia de sua 
chave ao governo, não poderíamos mais confiar nela. E isso seria um evento catastrófico para todos os 
envolvidos, pois o principal produto oferecido ou vendido por uma AC não é de fato o certificado digital, 
mas sim a confiança.
5.2.3 Modelos de confiança
Apesar de ser um modelo didático, a discussão anterior sobre o serviço on-line é bastante interessante, 
pois permite a identificação e discussão de grande parte dos verdadeiros desafios e problemas que 
devem ser enfrentados e solucionados no mundo real.
Na prática, existem dois diferentes paradigmas de confiança atualmente em uso, o modelo PKI/ICP, 
fundamentado em hierarquias rígidas de autoridades certificadoras, e o modelo PGP (pretty good 
privacy), fundamentado em redes de confiança avulsas e flexíveis, nas quais todas as entidades poderão 
assumir um papel de autoridade.
Na emissão do certificado digital, gerado após uma sucessão de envios e recebimentos de arquivos, 
que são assinados digitalmente por chaves privadas, também ocorre o contato direto com o solicitante 
a fim de averiguar as informações fornecidas, verificando se o solicitante realmente é quem diz ser.
Podemos dividir a geração do certificado nos seguintes passos: primeiro a seleção das principais 
informações de um certificado digital; segundo, o par de chaves, sempre gerado pelo titular, e a chave 
privada, que será de seu controle e conhecimento; e terceiro, cadastro de usuários e encaminhamento 
das solicitações de certificado da AC, ambos feitos pela AR.
Mas como verificar se a AC que assinou um certificado é quem ela diz que é?
2 confia em 3 e 
vice-versa pois as AC 
de ambos se confiam
Figura 77 – Infraestrutura de chaves públicas
115
CRIPTOGRAFIA E CERTIFICAÇÃO DIGITAL
A AC pode ser local, criada por uma organização, mas será acreditada apenas pelos participantes 
da empresa em questão. Qualquer um com um servidor pode criar um procedimento de geração de chaves 
públicas certificadas por si mesmo, contudo, nesse caso, só essa pessoa vai confiar nos certificados 
que emite.
Há outras AC externas que endossam suas chaves e podem ser parte de um acordo entre empresas 
que resolvem adotá-la como sua certificadora. Desse modo, os certificados emitidos por essa CA têm 
reconhecimento entre seus participantes.
Para o Brasil, somente a ICP-Brasil é reconhecida por lei (Medida Provisória n. 2.200-2). 
Apenas documentos assinados digitalmente por chaves certificadas por essa infraestrutura tem 
reconhecimento legal.
 Saiba mais
Consulte o texto da lei:
BRASIL. Medida provisória n. 2.200-2, de 24 de agosto de 2001. Institui 
a Infraestrutura de Chaves Públicas Brasileira – ICP-Brasil, transforma o 
Instituto Nacional de Tecnologia da Informação em autarquia, e dá outras 
providências. Brasília: 2001. Disponível em: https://www2.camara.leg.
br/legin/fed/medpro/2001/medidaprovisoria-2200-2-24-agosto-2001-
391394-norma-pe.html. Acesso em: 9 jun. 2020.
Para que houvesse confiança, primeiramente a infraestrutura foi institucionalizada por lei, depois 
nela foi gerado o primeiro certificado ou chave raiz que permitiu certificar todas as outras chaves 
das ACs participantes. Assim, tudo que for asseverado por essas ACs participantes da ICP-Brasil está 
alicerçado num arcabouço jurídico e tecnológico e tem reconhecimento legal.
 Lembrete
Esse arcabouço tecnológico é chamado de ICP – infraestrutura de 
chaves públicas – ou é comumente encontrado em documentos como PKI 
– public key infrastructure.
O arcabouço tecnológico de emissão de certificados digitais utilizado no Brasil é regido por uma 
autoridade certificadora raiz (AC raiz) única, que gerencia a emissão de certificados digitais. Essa AC raiz 
está sob a administração do Instituto Nacional de Tecnologia da Informação (ITI), o qual tem a função 
de credenciar e descredenciar todos os participantes da cadeia hierárquica de confiança, supervisionar 
e auditar os processos.
116
Unidade III
A AC raiz emite uma lista de certificados revogados, conhecida como LCR, e audita as outras ACs, ARs 
e outros prestadores de serviço atuantes na ICP-Brasil. A averiguação realizada busca manter as ACs em 
conformidade com normas de diretrizes estabelecidas pelo Comitê Gestor da ICP-Brasil.
Figura 78 – Infraestrutura de chaves públicas – estrutura ICP-Brasil
5.3 Tipos de certificados
Há três tipos de fatores a serem considerados na escolha de um certificado: a finalidade de uso, o 
tamanho de chave e o tipo de armazenamento da chave.
Quanto à finalidade de uso, hoje estão homologados pela ICP-Brasil dois tipos: os certificados de 
assinatura e os de sigilos, conhecidos respectivamente como tipo A e tipo S.
O tipo A é usado apenas para assinatura de documentos digitais, permitindo a correta identificação 
do assinante, bem como impedindo repúdios de transações assinadas. Já o tipo S é utilizado apenas para 
a transmissão de informações com sigilo.
Quanto ao nível de segurança, varia conforme o tamanho da chave e se o processo criptográfico 
será executado por hardware ou software. Os certificados que dependem de hardware são mais seguros, 
pois a chave não migra do dispositivo que a contém para a memória para realizar os procedimentos 
criptográficos. Pelo contrário, as informações é que são submetidas ao hardware para que este execute 
o procedimento sem exposição da chave. Já nos certificados dependentes de softwares, as chaves estão 
inseridas em um arquivo que não está protegido por hardware, mas apenas pelo PIN.
117
CRIPTOGRAFIA E CERTIFICAÇÃO DIGITAL
 Observação
O PIN é utilizado nas chaves em hardware apenas para habilitar o uso 
da chave.
Onde o certificado digital é armazenado?
ComputadorA1
A3
A3
A3
Smartcard
Token USB
HSM
Figura 79 – Tipos de chaves e seu armazenamento
5.4 Cerimoniais de chaves criptográficas
A necessidade de comunicação segura entre equipamentos,pertencentes ou não a uma mesma 
entidade, independente da distância em que estejam, exige a utilização de mecanismos de segurança 
que visem preservar a confidencialidade das informações durante todo o processo de comunicação.
O mecanismo de segurança mais comum é a utilização de algoritmo criptográfico com chave 
simétrica, no qual uma mesma chave deve ser inserida em mais de um dispositivo. Na impossibilidade de 
remeter seguramente e inserir remotamente a chave, utiliza-se do expediente chamado de cerimonial 
de chaves criptográficas.
O cerimonial é um conjunto de procedimentos, transcritos detalhadamente num formato de roteiro, 
para gerar a chave, transportá-la, inseri-la em outro sistema ou equipamento, guardá-la e descartá-la.
Para os procedimentos de transporte e inserção da chave, é necessário que ela seja decomposta em 
componentes, os quais são protegidos por custódios durante esses procedimentos.
Como o cerimonial é um conjunto não automatizado de procedimentos realizados por pessoas, cabe 
à aplicação de controles garantir e atestar que durante sua realização não houve a possibilidade de 
quebra de sigilo do conteúdo desses componentes e, consequentemente, da chave.
118
Unidade III
Uma vez que o roteiro tenha sido aprovado, sua aplicação deve ser atestada por autoridade designada 
para esse fim, a qual deve ter independência do processo de modo a não ocorrer conflito de interesse. 
Se for necessário por força de lei, por normativas de órgãos controladores, ou por obrigações contratuais, 
poderá ser exigido de uma entidade externa independente que audite e ateste os procedimentos 
realizados conforme aprovados no roteiro.
Para que haja a correta documentação sobre o que foi realizado do roteiro, deverá ser gerado 
pelo gestor um relatório descrevendo divergências ou situações ocorridas não previstas no roteiro 
original, o qual será copiado aos participantes. Deverá ser anexada a esse relatório, apenas para 
fins de arquivo, a versão original do roteiro de cerimonial executado, com todos os campos 
obrigatórios preenchidos.
O roteiro, quando não houver exigência maior, seguirá modelo padrão da organização, no qual 
constarão campos a serem preenchidos e endossados durante o cerimonial. Ele deverá conter clara e 
detalhadamente cada etapa a ser cumprida, indicando quem, onde e como executá-las. Além disso, deverá 
apontar a infraestrutura tecnológica e procedimentos logísticos para a realização das etapas.
As etapas poderão ser de conhecimento de todos ou, a critério do gestor, apenas de seus respectivos 
realizadores. Nesse último caso, o auditor, o responsável pelo cerimonial e o analista de segurança 
aprovador do roteiro deverão conhecer todo o roteiro, mantendo confidencialidade.
5.4.1 Componentes de chaves
Diferentemente do protocolo DHM, que é digital, o procedimento de transporte de chave em um 
cerimonial é físico. Portanto, a chave deve ser gerada em uma entidade, armazenada em alguma mídia, 
transportada sobre proteção, inserida na outra entidade e guardada em local seguro.
Como o procedimento é físico, essa mídia pode ficar exposta à ação de ameaças que possam roubá-la 
ou copiá-la. Portanto, há a necessidade de que, durante a geração, o transporte, a inserção e a guarda 
não tenha ocorrido qualquer possibilidade de obtenção da chave por pessoas indevidas.
Imagine a sua chave de acesso à porta principal de sua casa. Se você a perder, não entrará em casa, 
mas, pior, se alguém achá-la e puder identificar a que porta pertence, sua casa estará em risco. Agora 
imagine se fosse possível quebrar sua chave em três pedaços, e cada parte fosse entregue a um membro 
da família. Se um perder o pedaço, ou for roubado, não há risco de acesso indevido, pois o ladrão não 
teria a chave completa. É certo, então, que ninguém entraria na casa.
Para que seja possível a entrada na casa, prosseguindo com essa metáfora, faz-se necessário que 
todos os membros da família que receberam um pedaço da chave estejam presentes. A chave, então, é 
reconstituída e todos podem acessar a casa.
Uma chave criptográfica pode ser quebrada em pedaços (conhecimento dividido) ou sequências 
(componentes) que, sozinhas, não representam nada.
119
CRIPTOGRAFIA E CERTIFICAÇÃO DIGITAL
5.4.2 Conhecimento dividido
É utilizado em senhas nas quais são definidos o tamanho e a ordem em que cada uma das pessoas 
ou custódios dos pedaços deve digitar sua sequência. Não há nenhum algoritmo matemático envolvido, 
portanto, o conhecimento de cada pedaço e a ordem de inserção por alguém torna a senha compreensível.
Na prática é assim: todos os custódios criam sequências limitadas de caracteres e é acordada uma 
ordem de digitação. Como os sistemas normalmente apresentam asteriscos como retorno de tela, 
nenhum custódio consegue saber o pedaço digitado pelo anterior. Portanto, não funciona em sistemas 
nos quais seja possível ver a senha no momento da digitação.
Uma senha de conhecimento dividido não visa à autenticação de um indivíduo, pois o conhecimento 
de sua totalidade não é restrito a um indivíduo. Normalmente, ela é utilizada em equipamentos nos 
quais não se exige identificação e, portanto, a autenticação, como elementos de rastreabilidade de 
quem acessou.
É muito comum em cofres nos quais se faz necessária a presença de mais de uma pessoa para 
liberar o acesso, casos em que se divide a senha em pedaços ou cada mecanismo de segurança fica 
a cargo de um indivíduo, por exemplo: a senha eletrônica ou mecânica com um e a chave física 
com outro.
O objetivo final de uma senha de conhecimento dividido é evitar que apenas uma pessoa tenha a 
possibilidade de resgatar informações sigilosas, sem conhecimento de outras. Quanto mais pedaços 
existirem (ou mecanismo de segurança) sob a responsabilidade de pessoas distintas, menor a possiblidade 
de conluio entre os portadores das partes.
5.4.3 Componentes
Uma chave criptográfica pode ser particionada em componentes, mediante algoritmo matemático 
de modo que o conhecimento de todas as partes por si só não torne óbvio o valor da chave. Há a 
necessidade de se introduzir todos os componentes em um sistema seguro o qual, pela aplicação reversa 
do mecanismo, gerará a chave original.
Como o algoritmo matemático é de conhecimento público, a recombinação dos componentes pode 
ser efetuada por qualquer um que conheça esse algoritmo. Portanto, apesar de não ser algo claro como 
apenas a junção, em certa ordem, dos elementos de um conhecimento dividido, pode ser efetuado por 
qualquer um com conhecimento do algoritmo.
Isso nos obriga à realização do cerimonial, visando garantir que ninguém pode, em qualquer momento 
da geração, transporte, inserção, guarda, ter obtido acesso e tomado conhecimento dos componentes 
em sua totalidade.
120
Unidade III
Geração de componentes
Os componentes de uma chave criptográfica podem ser gerados por hardware ou software. 
Aconselha-se que seja utilizado um hardware para essa atividade, pois a utilização por software pode ser 
comprometida pela má codificação do algoritmo ou introdução ilícita de código malicioso. Em ambos os 
casos, poderá ocorrer geração “viciada” de chaves com baixo nível de entropia.
Figura 80 – Cerimonial de chaves criptográficas
A geração de componentes ocorre pela sensibilização por comandos desses hardwares, os quais são 
capazes de gerar sequências realmente aleatórias de tamanho definido as quais, quando reunidas, por 
meio de algoritmo matemático, recompõem uma chave.
Matematicamente, é possível criar quantas sequências aleatórias quisermos e recombiná-las todas – 
ou parte delas – para gerar uma chave. Em alguns sistemas, geram-se, por exemplo, dez componentes, 
sendo que qualquer combinação de apenas três deles recriam a chave. Isso é muito bom quando se 
precisa de alta disponibilidade dos custódios, mas não se pode contar com todos para recompor a chave.
Há outros sistemas que exigem a presença de todos os componentes gerados. Assim, por exemplo, se 
foram feitos três componentes,a presença dos três é obrigatória para a recomposição da chave.
 Lembrete
É necessário termos em mente que a inserção da chave, bem como a sua 
guarda, devem ser protegidas contra a menor possibilidade de vazamento, 
daí a importância de levar muito a sério os cerimoniais criptográficos.
121
CRIPTOGRAFIA E CERTIFICAÇÃO DIGITAL
5.5 Gestão de chaves criptográficas
Toda chave criptográfica possui um ciclo de vida que engloba:
Lembrança – 
manutenção de 
histórico
Nascimento 
– geração / 
transporte / 
inoculação
Vida útil – 
tempo de uso
Morte – descarte
Figura 81 – Ciclo de vida de chaves criptográficas
Quando falamos de cerimonial, estamos tratando somente do nascimento. A vida útil é a existência 
da chave em processos ativos, bem como a definição clara do prazo de validade, conforme análise de 
risco sobre vulnerabilidades e grau de exposição ou determinação de entidade externa.
A morte define o procedimento de remoção dos diversos locais de uso da chave, mas não de 
destruição, o qual, aliás, somente deve ser efetuado após formalização por parte dos utilizadores de que 
não há mais informação protegida necessitando da chave para ser decriptografada – caso contrário, a 
chave deve ser guardada até não mais ser necessária, num procedimento de lembrança.
O processo de gestão de chaves criptográficas deve considerar: aspectos técnicos da chave a ser 
utilizada; cerimonial; guarda da chave, documentação do cerimonial e PCN (plano de continuidade do 
negócio) para os negócios atendidos por chaves.
Os aspectos técnicos englobam o que deve ser protegido, qual o nível de segurança a ser aplicado 
e qual tecnologia criptográfica será utilizada, de modo que seja tudo compatível entre os pontos 
de comunicação. Conforme o caso, devem ser definidos quais tipos de hardwares serão utilizados, a 
interação entre eles, que aplicativo será usado; qual algoritmo criptográfico será aplicado, a variação 
de configuração do algoritmo; o tamanho de chaves e onde serão geradas, quantos componentes serão 
feitos; se a chave será apresentada em tela ou impressa, em claro ou cifrada.
122
Unidade III
Quanto ao cerimonial, deverão constar todos os procedimentos adotados para gerar a chave, 
transportá-la e inseri-la em outro sistema ou equipamento.
A guarda da chave e a documentação do cerimonial dependerão de qual modelo de gestão será 
adotado (falaremos dos modelos a seguir). A documentação deverá conter o roteiro utilizado, com 
todos os campos obrigatórios preenchidos, com aposição de assinaturas necessárias à ata final assinada 
pelo gestor, espelho de presença dos participantes com aposição das assinaturas de cada um e ficha de 
cadastro da chave criptográfica (que poderá ser um item do roteiro).
 Observação
O PCN é responsável por manter as atividades da empresa no caso de 
uma interrupção dos serviços críticos da organização, seja por ameaças 
naturais, intencionais ou acidentais.
O PCN de cada gestor deverá conter os requisitos necessários para a rápida recomposição e 
ativação de uma chave nos equipamentos relacionados ao negócio em caso de perda, seja por falha 
no equipamento, seja por troca. Também deverá haver um plano de execução de novo cerimonial caso 
haja evidências de que a chave foi corrompida. A gestão desse plano poderá ser descentralizada ou 
centralizada, depende do modelo de gestão adotado.
O modelo de gestão de chaves criptográficas se refere ao processo de gestão de chaves. Podem 
ocorrer três tipos de gestão:
• Descentralizado: modelo atual adotado nas organizações, nele cada gestor gerencia a 
guarda da chave e a documentação do cerimonial. Cabe às áreas técnicas a especificação e 
operacionalização das chaves (não acionamos o PCN, caso haja algum sinistro com a chave ou 
equipamento que a contenha).
• Centralizado: modelo ideal no qual todo o ciclo de vida de uma chave (geração, transporte, 
inserção, guarda de componentes, recuperação, descarte) está sob gestão estratégica e 
tática de uma única área, cabendo a áreas técnicas a especificação e operacionalização 
das chaves.
• Misto: mantém toda a gestão descentralizada quanto à parte tática e operacional, mas 
centraliza a documentação e o procedimento de gestão do PCN, cabendo a este núcleo 
a correta e tempestiva atuação na reativação dessa chave de modo a causar o mínimo 
impacto ao negócio.
As seções que devem compor um roteiro de cerimonial de chaves criptográficas são:
123
CRIPTOGRAFIA E CERTIFICAÇÃO DIGITAL
Quadro 7 – Roteiro para cerimonial de chaves criptográficas
Roteiro para cerimonial de chaves criptográficas
Capa com o título Nome do cerimonial, indicando dados de referência que permitam a distinção entre outros cerimoniais
Ficha para catálogo/registro
Localizada abaixo do título, indica: o departamento gestor no formato JJJJ/Nome 
Departamento; ou autor(es) do cerimonial, no formato Código – Nome, e o revisor 
da segurança corporativa, no formato Código e Nome
Os controles de versão
Finalizado em: dd/mm/aaaa HH:mm
Impresso em: dd/mm/aaaa HH:mm
Gravado em: dd/mm/aaaa HH:mm
O objetivo
Descrever qual a necessidade da aplicação do cerimonial, identificando as chaves, 
produtos e/ou participantes beneficiados e onde será feito
Informações protegidas: descrever quais informações serão protegidas pela chave
Responsabilidades das 
funções representadas pelos 
participantes
Descrever as atribuições de cada função no cerimonial, indicando o produto 
resultante. Algumas áreas já possuem a atividade pré-definida
Agente de compliance
Verificar se os controles descritos no roteiro estão em conformidade com a 
política e com as normas de segurança da informação da organização. Efetuar o 
walkthrough durante a execução do cerimonial, visando atestar se os controles 
aplicados foram eficazes
Auditor interno/externo Atestar a efetividade do cerimonial mediante relatório independente ou aposição de assinatura sobre ata/relatório final
Revisor da segurança 
corporativa
Efetuar análise de risco de Segurança da Informação dos procedimentos descritos 
no cerimonial
Condutor cerimonial
Responsável principal pelo cerimonial. Registra detalhadamente os procedimentos 
necessários para a execução do cerimonial nesse documento. No ato do cerimonial, 
verifica se os pré-requisitos foram atendidos – material; pessoal e procedimentos 
descritos. Conduz a execução do cerimonial e dos procedimentos. Preenche todos 
os anexos. Tem poder exclusivo de impugnar o processo, caso identifique algum 
risco ou violação dos protocolos de segurança definidos no roteiro do cerimonial
Custódios do HSM Responsáveis pelas atividades necessárias no HSM
Chave
Responsáveis pelos componentes ou fragmentos de senha assinam os anexos nos 
locais que lhes competem. Indica-se quantos há e se existirem procedimentos 
distintos, devem ser apontados com item da função
Observador
Pessoa que não participa do cerimonial, mas possui interesse contratual ou 
representativo de alguma entidade em atestar a execução dele. Sua presença deve 
ser indicada, bem como sua finalidade e a que entidade ele pertence
Outros Participante cuja função não é padrão em cerimoniais, mas é necessária para que ocorra. Devem ser descritas a identificação da função e sua responsabilidade
É primordial que os cerimoniais apresentem os seguintes itens antes da sua realização:
• Pré-requisitos: a área gestora da chave criptográfica deverá descrever as atividades necessárias 
que precedem o cerimonial, como alocação do ambiente; contratação de transporte; preparação 
de hardware (HW) e software (SW) e disponibilidade de agenda dos participantes.
• Recursos necessários para a realização do cerimonial: devem ser enumerados os recursos 
necessários para a execução do cerimonial, incluindo: quantidades de caneta, papel, envelopes, 
fitas adesivas, smartcards, documentos, anexos e HW e SW.
124
Unidade III
• Texto de abertura do cerimonial: deve ser informado aos participantes, de modo resumido, o objetivo 
do cerimonial e quais informações serão protegidaspela chave criptográfica. Os participantes devem 
ser alertados quando da obrigação do cumprimento exato do roteiro, bem como da confidencialidade 
a ser mantida e do esforço na proteção da chave e seus respectivos componentes.
Durante o procedimento de geração e inoculação de chaves criptográficas, devem ser seguidas as 
seguintes regras de segurança:
• Todos devem assinar a lista de presença a constar em ata do cerimonial.
• É proibido o uso de aparelhos celulares ou rádios transmissores, câmeras fotográficas ou filmadoras, 
e aparelhos de gravação durante o cerimonial, exceto os autorizados e devidamente regulados 
para fins de documentação do processo. Se alguém possuir algum desses equipamentos, solicite 
que os desligue.
• Hipótese 1: o componente em papel de uma chave criptográfica deve ser de conhecimento 
somente de seu respectivo custódio, o qual, sob hipótese alguma, deve mostrá-lo a outrem, bem 
como portá-lo em ambientes com outras pessoas sem a proteção exigida por esse cerimonial.
• Hipótese 2: o smartcard com o componente de uma chave criptográfica somente deve ser 
portado pelo seu respectivo custódio, o qual deve protegê-lo do acesso por outras pessoas.
• Os componentes, quando não estiverem sendo utilizados, devem permanecer salvaguardados 
conforme proteção exigida no cerimonial.
• O cerimonial será cancelado caso haja a suspeita ou evidências de que algum componente ou 
chave tenha sido revelado a outrem ou observado por alguém não autorizado, ou de que os 
smartcards tenham sido manipulados por não custódios. Os participantes têm o dever de informar 
esse tipo de incidente ao gestor principal do cerimonial.
• Ao final do cerimonial, todos os participantes devem assinar os anexos e fichas conforme sua 
participação no cerimonial.
• Observação: optar pela primeira hipótese, caso seja geração em papel, ou pela segunda, caso 
utilize smartcard.
5.5.1 Procedimentos a serem documentados em um cerimonial de chaves criptográficas
O roteiro do cerimonial deve conter informações suficientes para que seja possível a qualquer pessoa 
que não tenha o conhecimento sobre o assunto cumprir as instruções passo a passo. Para tanto, devem 
ser sempre indicados:
• Nome do procedimento.
125
CRIPTOGRAFIA E CERTIFICAÇÃO DIGITAL
• Responsáveis: identificar a função, por exemplo: custódio componente 1, mestre de cerimonial, 
auditor etc.
• Local onde será executado o procedimento.
• Material necessário.
• Instruções detalhadas do procedimento em ordem cronológica, indicando quem, onde e o que 
será utilizado.
Entretanto alguns procedimentos são padrões, por exemplo: a colocação do HSM em modo 
autorizado; lacrar componentes; transportar custódios e seus componentes; preencher o impresso do 
componente; fazer a gravação de smartcards etc. De fato, o único diferencial são os procedimentos 
específicos de cada chave que a especifica. Portanto, esses procedimentos padrões podem já estarem 
documentados em base de procedimento e apenas serem anexados ao roteiro ou referenciados por 
este, o qual deve indicar qual procedimento e versão foram praticados. Obviamente, quando falamos de 
versão, devemos manter histórico, inclusive com indicação de versões que substituíram a versão anterior 
e qual versão ainda deve ser praticada.
Procedimento de encerramento do cerimonial
O cerimonial deve ser encerrado pelo responsável, repetindo tudo o que foi realizado e sendo 
registrado na ata de encerramento. 
A seguir incluímos um exemplo de histórico de cerimonial de chaves criptográficas, com procedimentos 
padrões em cerimoniais. Nota: é opcional fazer a referência da versão aplicada e de valores utilizados.
1) Abertura de mídias móveis.
2) Destruição de mídias móveis e materiais impressos.
3) Uso de estações com HD/SSD para inserção de componentes.
4) Envelopamento dos componentes.
5) Abertura do envelope.
6) Guarda de envelope no cofre.
7) Transporte de componentes.
8) Ficha de preenchimento de componentes de chave criptográfica.
126
Unidade III
No transporte, se celulares devem ficar desligados, como se comunicar em caso de incidente/
acidente? Para fazê-lo, é necessária a definição de outros meios de comunicação, como telefones fixos 
ou algum tipo de código de pânico previamente convencionado.
Fora isso, é importante dar atenção aos seguintes aspectos:
• Não precisam ir todos ao cofre retirar cartões autorizantes.
• Devem ser descritos todos os passos no roteiro, inclusive com indicação de deslocamentos e acessos.
• Estudar a possibilidade de abolir, para algumas situações, o transporte separado dos custódios, 
talvez pela aplicação de outros controles ou dependendo do tipo de componente.
• Problemas com cofre (cerimonial por gaveta ou escaninho), sala-cofre, riscos, vulnerabilidades 
e ameaças.
 Saiba mais
Para compreensão lúdica da importância da proteção das chaves 
criptográficas, assista ao filme:
JOGOS de Guerra. Dir. John Badham. EUA: MGM, 1983. 114 minutos.
6 IDENTIDADES DIGITAIS
Segundo Wykes (2016), em um mundo cada vez mais virtual, as identidades digitais são de 
fundamental importância. Se, no mundo físico, já existem diversos meios de identificação, como nome, 
CPF ou número de passaporte, para citar apenas alguns, a transição para o mundo digital amplia essa 
diversidade de forma exponencial.
Afinal, a cada novo dia aumenta a quantidade de identidades on-line, nomes de login e endereços 
de e-mail que possuímos. Em função da necessidade de oferecer proteção de dados e privacidade, ao 
acessar qualquer serviço digital, seja nuvem computacional, serviço de webmail, portal de e-banking, 
servidor da empresa, serviço on-line do governo ou mesmo site de mídias sociais, aquele serviço precisa 
se certificar da identidade de quem o está acessando.
E, como já vimos, nesses ambientes on-line, as senhas, códigos e demais credenciais fixas, apesar 
de serem de fácil utilização e implementação, simplesmente não são seguras. São passíveis de cópia, 
captura, roubo, extração e reutilização. E fatores alternativos de autenticação, como a biometria e os 
emergentes fatores comportamentais, além de trazerem novos riscos, acabam, do ponto de vista dos 
sistemas computacionais, transformando-se apenas em credenciais de tamanho maior.
127
CRIPTOGRAFIA E CERTIFICAÇÃO DIGITAL
Segundo Wykes (2016), podemos dizer que a criptografia de chaves públicas, por meio de técnicas 
como a assinatura digital incorporada em protocolos de autenticação forte, é capaz de prover essa tão 
desejada segurança, mas há um problema. Uma chave pública, apesar de ser teoricamente diferente 
de qualquer outra chave, é apenas um número, uma longa sequência de dígitos, e não traz nenhuma 
informação sobre a quem pertence.
Assim, o autor (WYKES, 2016) faz pergunta: como um servidor poderia saber a quem pertence uma 
determinada chave? Se esse servidor, de antemão, tivesse feito uma associação entre uma chave e 
um nome de login, gravando, por exemplo, sua chave pública em seu banco de dados, você não teria 
maiores problemas em autenticar seu login. A principal dificuldade estaria relacionada com os custos 
de guardar e manter atualizado o banco de dados de chaves públicas, mas essa é uma solução simples, 
barata e razoavelmente segura.
Existem inúmeras situações em que um computador não necessariamente conhece a pessoa e, 
portanto, não possuirá sua chave pública. Em muitos casos, é preciso utilizar a mesma identidade em 
contextos diferentes, como quando utilizamos a identidade civil brasileira, o CPF, para nos identificarmos 
diante de diferentes repartições do governo. Os computadores desses órgãos não estão necessariamente 
interligados e, portanto, não compartilham a mesma base de dados.
Para Wykes (2016), essa dificuldade ocorre quando, por exemplo, essa mesma pessoa precisa se 
identificar pelo CPF em alguma empresa, como no site do plano de saúde, hospital local, seguradora 
do carro ou banco. É preciso haver outra forma de criar e averiguar a associação que existe entre uma 
chavepública e seu proprietário.
O mesmo problema se faz presente ao querer assinar digitalmente um documento ou contrato, pois 
de nada vale uma assinatura criptograficamente verificável, se não é possível comprovar posteriormente a 
identidade de quem assinou. E, de forma semelhante, quando se quer trocar alguma informação confidencial 
entre duas partes, a criptografia de chaves públicas pode ser de grande auxílio, mas surge a dúvida de como 
saber que determinada chave pública pertence de fato ao destinatário da mensagem cifrada.
Trazendo luz sobre esses diversos problemas, existem os diferentes modelos de identidade digital 
segura e independentemente dos detalhes de cada um, todos funcionam com base em um único 
conceito — o certificado digital.
6.1 Caso prático: PKI nos cartões de débito e crédito
Segundo Wykes (2016), embora muito se fale dos padrões de certificados digitais utilizados na 
internet e nas assinaturas digitais de documentos e contratos, há um exemplo interessante do modelo 
PKI presente em bilhões de cartões de débito e crédito pelo mundo todo. Esses cartões com chip 
incorporam vários certificados digitais no intuito de facilitar uma verificação de sua autenticidade pelos 
terminais de pagamento.
No esquema ICP de âmbito mundial, existem algumas poucas autoridades certificadoras raiz, que 
são as bandeiras de cartão, como Mastercard, Visa e Elo, para citar algumas das principais presentes no 
128
Unidade III
Brasil. Essas bandeiras, as ACs primárias, distribuem suas chaves públicas às empresas que operam as 
redes de terminais, assim, em cada terminal existe uma tabela de chaves públicas.
Os bancos que emitem os cartões também são autoridades certificadoras nesse esquema. Segundo 
Wykes (2016), elas funcionam como ACs intermediárias, e cada banco pode ter várias ACs virtuais, conforme 
os tipos de cartão que emite. Antes de iniciar a emissão de cartões daquele tipo, primeiramente o banco 
deve gerar seu par de chaves e enviar a chave pública à bandeira, juntamente com algumas informações 
adicionais sobre o banco e o tipo de cartão. A partir dessas informações, a bandeira cria um certificado 
digital, embutindo nele a chave pública do banco, e o devolve devidamente assinado ao banco.
Naturalmente, são implementados vários controles de segurança e autenticação no intuito de evitar 
que haja abuso desse serviço de certificação. De posse desse certificado, o banco já pode emitir os cartões.
O padrão EMV é complexo e extenso e permite ao banco optar entre inúmeras opções na hora 
da emissão do cartão. Uma delas, a DDA (dynamic data authentication), oferece maior segurança às 
transações, pois cada cartão também é munido de sua própria chave privada, cuja função principal 
é permitir que ocorra uma autenticação dinâmica entre o cartão e os terminais. Juntamente à chave 
privada, o cartão também carrega um certificado, assinado pela AC intermediária de seu banco emissor, 
acompanhado pelo próprio certificado da AC intermediária.
CA
Diretório
Transações 
comerciais via 
internet
A relação de credibilidade entre lojistas 
e usuários com certificados é endossada 
por uma autoridade certificadora
Lojista
Usuário
CA divulga o 
certificado em 
um diretório
O lojista pode verificar:
• Detalhes do certificado
• Relações de revogação
• Validade dos certificados
• Assinaturas
• Decriptar dados
Figura 82 – Exemplo de uso de cartão compras
Os Padrões X.509 e PKIX para certificação digital, para Wykes (2016), são para uso generalizado. 
Existe um conjunto de padrões internacionais e, normalmente, quando alguém fala em certificação 
digital, está fazendo referência aos certificados baseados no padrão conhecido como X.509.
Os documentos originais do X.509 delineavam os principais conceitos e estruturas dos modos de operação 
dos certificados digitais para uso geral, a maioria dos quais continua válido. Ao mesmo tempo, possuem 
imensa flexibilidade e muitas opções, o que pode levar a implementações em sistemas incompatíveis.
129
CRIPTOGRAFIA E CERTIFICAÇÃO DIGITAL
Pela necessidade de ajustar e evoluir o padrão para uso maciço na internet, ele foi transformado 
em uma série de recomendações conhecidas como PKIX, publicadas como um RFC, formato popular de 
especificações amplamente divulgado na internet.
A especificação original, o RFC 2459, já foi substituída várias vezes, a cada nova revisão, que trazia evolução 
e tornava obsoleta a versão anterior. Atualmente, a referência é o RFC 5280, a qual possui 151 páginas.
O certificado X.509 é definido por Wykes (2016) como um arquivo ou estrutura de dados que codifica, 
além das informações necessárias para a identificação da entidade proprietária de uma chave pública, 
dados sobre a autoridade certificadora responsável por sua emissão e assinatura.
É composto de três seções de dados, a primeira tem uma estrutura extensível, feita de uma parte fixa 
que contém informações obrigatórias em todos os certificados – como o número de série do certificado, 
o período de validade e os nomes do titular do certificado e da AC emissora – e de uma lista de atributos 
e extensões opcionais.
A segunda seção contém informações sobre a chave pública, incluindo o valor da chave pública 
propriamente dita, e um identificador do algoritmo criptográfico a ser utilizado com ela. A última seção 
é composta de uma assinatura digital sobre as duas primeiras, acompanhada de um indicador sobre o 
algoritmo de assinatura utilizado. Essa assinatura é criada pela autoridade certificadora em tempo de 
geração do certificado.
Para Wykes (2016), todo certificado X.509 tem um elemento de dados que identifica para quem foi 
emitido o certificado – o proprietário do par de chaves. Denominado em inglês subject, esse elemento 
tem sido traduzido para o português de várias formas, como assunto, sujeito ou titular, conforme o autor 
ou o aplicativo. Para facilitar, vamos utilizar o termo titular, por representar melhor o real significado 
do campo.
Além da identificação do titular, o certificado tem um segundo elemento que identifica qual AC o 
emitiu, naturalmente denominado emissor (WYKES, 2016). Um dos conceitos principais que vigorava 
na época em que foi originalmente escrita a norma X.509 era a utilização desses dois elementos para a 
reconstrução da árvore de validação.
No certificado X.509, o emissor indica o nome da autoridade certificadora, facilitando a busca e 
identificação do certificado superior. Assim, segue-se para a formação de uma cadeia de certificação 
na qual cada certificado é ligado ao próximo na hierarquia pelo elo entre pares de valores do emissor e 
titular. No final da cadeia, o certificado raiz, por ser autoemitido ou autocertificado, indica esse fato, por 
ter titular e emissor iguais.
Com o tempo, percebeu-se uma falha nesse processo, pois não existe nada no padrão X.509 que proíba 
a emissão de dois ou mais certificados com o mesmo titular. Inclusive, tais certificados podem ser emitidos 
por ACs globais, em locais diferentes, sem que o verdadeiro titular daquele nome saiba. Considerando que 
um certificado digital existe para auferir garantias de identidade e autenticidade às chaves públicas, essa 
deficiência permitiu abrir uma brecha considerável na segurança dos esquemas de PKI.
130
Unidade III
Versão
Número de série do certificado
Identificador do algoritmo de assinatura
Nome da AC – X.500
Período de validade
Nome do usuário
Informações da chave pública
Identificador único da AC
Identificador único do usuário
Extensões
Assinatura digital de AC
Versão 1
Versão 2
Versão 3
Todas as versões
Figura 83 – Padrão X.509
Segundo Wykes (2016), a vida de um certificado X.509 sempre começa com a geração de um par de 
chaves para o futuro titular do certificado. Em virtude da necessidade de ser de posse exclusiva, a chave 
privada deverá ser mantida protegida. Muitas vezes, isso implica a geração dessa chave nos confins 
seguros de algum token criptográfico portátil, como um smartcard ou uma placa HSM.
Devidamenteexportada desse dispositivo seguro, a chave pública é combinada com um conjunto 
de dados sobre o titular pretendente do futuro certificado e esse conjunto é assinado imediata e 
digitalmente com a chave privada. O arquivo de dados, denominado CSR (certificate signing request) é, 
em seguida, enviado à AC pela via mais conveniente: um aplicativo, portal on-line ou e-mail.
Dependendo da aplicação, da regulamentação aplicável, das políticas e das práticas específicas 
de cada AC, existem muitas variações no grau de verificação exigida e nos detalhes desse processo. 
Em alguns casos, essa solicitação sofre a intermediação de uma entidade conhecida como AR agente ou 
autoridade de registro. Quando isso acontece, a AR é responsável por averiguar a identidade do titular, 
eventualmente exigindo a apresentação de documentos oficiais comprobatórios.
Em outros casos, a AC efetua uma validação de identidade por vias alternativas, menos seguras, como 
e-mail, ou diretamente on-line. As informações presentes no CSR são consideradas dados preliminares, 
um protótipo das informações que constarão no certificado e deverão ser verificadas pela AR e/ou AC, 
podendo ser complementadas ou corrigidas conforme necessário.
Em seguida, o certificado será gerado e devolvido ao solicitante. Naturalmente, as operações comerciais 
também exigirão que seja efetuado o devido pagamento antes de que seja liberado o certificado.
O último passo é o armazenamento desse certificado pelo proprietário, geralmente por sua gravação 
pelo dispositivo seguro ou aplicativo de software. Então o conjunto de chave e certificado estará pronto 
para uso, de preferência protegido por uma senha ou outro mecanismo de autenticação presencial 
(WYKES, 2016).
131
CRIPTOGRAFIA E CERTIFICAÇÃO DIGITAL
Geralmente, um certificado digital terá uma vida útil de vários anos, conforme o prazo de validade 
definido pela AC em tempo de geração. Ao se esgotar o prazo, indicado pelas informações de controle 
presentes no certificado, ele vencerá automaticamente e não poderá mais ser utilizado.
Se antes do vencimento houver algum imprevisto, como roubo ou extravio do token criptográfico, 
deve-se cancelar o certificado, solicitando à AC que seja revogado. Como parte de suas atividades 
normais, a AC mantém em uma base informações sobre cada certificado emitido, inclusive sua situação 
de vida.
Revogação implica alterar o status do certificado nessa base, mas de nada adianta revogar um 
certificado se essa informação não for publicada e consultada. Consultar se um certificado está ou 
não revogado deve fazer parte de todo processo de validação de assinaturas digitais, pois sem essa 
informação não é possível fazer uma validação completa.
Existem dois diferentes mecanismos pelos quais é possível consultar o estado de revogação de um 
certificado: um arquivo chamado LCR (lista de revogação de certificados); e uma consulta OCSP 
(on-line certificate status protocol). No primeiro, a AC pública em seu portal um ou mais arquivos 
contendo listas de certificados revogados. Ao ser emitido, o certificado inclui um campo de extensão 
que indica onde pode ser encontrada essa lista, muitas vezes em forma de link ou URL. Ao consultar a 
validade de um certificado, o aplicativo ou sistema operacional acessa esse link e recupera o arquivo inteiro.
 Observação
A LCR deve estar sempre atualizada e isso fica sob responsabilidade da 
ICP-Brasil. A lista contém os números seriais dos certificados revogados, 
e é digitalmente assinada e publicada em um repositório. Ela, além disso, 
contém a data da emissão do certificado revogado e outras informações, 
tais como as razões específicas para a sua revogação.
Segundo Wykes (2016), além da lista de certificados revogados, o arquivo possui uma assinatura 
digital feita pela chave da AC, que lhe aufere garantias de integridade e autenticidade. O arquivo contém 
uma indicação de sua validação temporal, de forma que um aplicativo consiga mantê-lo em cache, como 
cópia local, durante certo tempo, e saber quando é preciso buscar uma cópia nova.
A vantagem é a otimização do processo de validação de um certificado, pois a informação de 
revogação mantida localmente pode ser utilizada de imediato, sem precisar esperar uma resposta da AC. 
Em situações de baixa comunicabilidade, isso é importantíssimo, pois pode ser inviável baixar um LCR 
de, potencialmente, alguns MB de tamanho, por conter informações sobre muitos certificados, antes 
mesmo de poder validar um único certificado.
A otimização torna-se mais importante à medida que crescem os arquivos de LCR, quando 
encontramos a principal desvantagem desse mecanismo, pois, para ACs de tamanho razoável, a lista de 
certificados revogados tende a crescer de modo significativo e pode rapidamente se tornar um gargalo.
132
Unidade III
Uma AC poderia até estender o período de validade de seus LCR, ampliando a chance de que 
determinado aplicativo já os tenha em cache, mas isso também acaba aumentando a janela de tempo 
em que um certificado reportado e devidamente revogado pode ser utilizado, por ainda não ter expirado 
a lista de revogação anterior.
O mecanismo OCSP foi criado para reduzir essa janela de tempo e, ao mesmo tempo, reduzir a 
quantidade de informações que precisam ser transmitidas. Com OCSP, é feita uma consulta on-line 
sobre determinado certificado e a resposta obtida, assinada pela AC, indica se esse certificado específico 
está ou não revogado. Na maioria das situações, torna-se uma solução muito melhor, especialmente em 
uma era de conectividade 24x7. Por outro lado, há de se admitir que isso já esteja se aproximando da 
nossa solução hipotética de um serviço on-line.
6.2 Autenticando um serviço
Segundo Wykes (2016), embora não esteja diretamente relacionado com o modelo PKI, o mecanismo 
OCSP é muito importante para as assinaturas digitais.
Um dos problemas das assinaturas digitais é que são atemporais, pois, mesmo que contenham um 
campo indicando data e hora da assinatura, esse campo é gerado pelo assinante e pode sofrer de 
imprecisão pelas inevitáveis discrepâncias entre relógios, sendo também passível de abusos.
Um serviço de carimbo de tempo é um serviço ou portal eletrônico fundamentado em uma 
fonte confiável de tempo, normalmente algum laboratório ou órgão relevante em nível nacional ou 
internacional. Esse serviço possui uma chave privada e certificado e, ao receber uma solicitação de 
carimbo de tempo, anexa uma representação precisa da data e hora aos dados recebidos, assina esse 
conjunto com sua chave e o retorna acompanhado de seu certificado digital.
Embora não seja tão difundido quanto deveria, o uso de um carimbo de tempo é um passo importante 
para aumentar o grau de validade legal das assinaturas digitais, principalmente as de documentos e 
contratos que incorporem noções de tempo.
Segundo Wykes (2016), o modelo PGP atua por meio do conceito de teia de confiança. O modelo 
de certificados PGP oferece uma alternativa ao OCSP, pois cria uma rede de confiança na horizontal, em 
vez de na vertical. Assim, cria-se uma rede dinâmica e flexível, que se configura de forma diferente para 
cada pessoa, de modo muito semelhante às redes de contato das redes sociais.
Como no modelo PKI, na base do modelo PGP também há um par de chaves assimétricas, de 
posse exclusiva de uma pessoa ou organização. Geralmente esse par de chaves está associado 
a uma identidade, composta de um nome e endereço de e-mail, entre outras informações. 
Diferentemente do modelo PKI, no modelo PGP essas informações pessoais, em conjunto com a 
chave pública, são assinadas criptograficamente, pela própria chave privada, ou seja, não existe 
nenhuma autoridade central.
133
CRIPTOGRAFIA E CERTIFICAÇÃO DIGITAL
No bloco de informações resultante poderá ser constatado o vínculo criptográfico entre as 
informações, como nome e endereço de e-mail, e a chave pública, embora não haja garantia da 
veracidade das informações. No PGP, há um enfoque na chave, e não nas informações,isso leva à 
predominância de uso do termo “chave PGP”, em vez de certificado. Entretanto, essa estrutura não deixa de 
ser um tipo de certificado digital, devendo ser tratada como tal, por ser diretamente comparável a um 
certificado digital autoassinado, informando que o assinante possui de fato o par de chaves.
A posse da chave privada pode ser comprovada pela presença de uma assinatura válida e também 
demonstra que seu proprietário deseja associar a essa chave o nome e o endereço de e-mail contidos 
no certificado. No entanto, isso não oferece nenhuma garantia de quem realmente criou o certificado, 
o que facilita a qualquer pessoa gerar um certificado falso.
Segundo Wykes (2016), para ampliar essas garantias, é preciso formar uma rede de confiança. Porém, 
por enquanto, vale apenas uma afirmação fraca: a garantia “sou eu”, bem diferente dos certificados 
digitais dos esquemas ICP, que já nascem garantidos por via de uma cadeia de autoridades certificadas.
Embora utilize um formato eletrônico diferente dos certificados X.509, podemos observar 
que esses blocos de identidade PGP têm um papel muito semelhante ao dos certificados raízes, 
presentes nessas hierarquias.
Segundo Wykes (2016), para formar uma teia de confiança, na prática, a chave PGP funciona como 
auxiliar para dois dos mais importantes serviços de segurança: a assinatura digital, que profere garantia 
de autenticidade aos arquivos e mensagens eletrônicas; e o envelopamento seguro, que provê garantias de 
confidencialidade a eles.
Como exemplo, se você quiser enviar um e-mail assinado digitalmente, como forma de comprovar 
ao destinatário que realmente foi você que o enviou, utilizará um aplicativo de e-mail devidamente 
configurado com a sua chave PGP. Quando você sinalizar seu desejo de assinar o e-mail, o aplicativo 
buscará sua identidade PGP e solicitará a digitação da frase secreta cadastrada, que serve para proteger 
sua chave privada. Em seguida, a chave será utilizada para gerar uma assinatura digital sobre o texto do 
e-mail e essa assinatura, juntamente com seu certificado digital PGP, será anexada ao e-mail que logo 
será enviado.
Contudo, vamos supor que você enviou esse e-mail para alguém que não conhece bem – alguém 
que você conheceu recentemente em um congresso, por exemplo – enfim, alguém que não possui seu 
certificado PGP. Como essa pessoa poderá verificar a veracidade do e-mail recebido?
Ao receber o e-mail, por meio de um aplicativo configurado para reconhecer mensagens protegidas 
pelo PGP, essa pessoa será informada de que, embora a mensagem tenha sido verificada como íntegra, 
não foi possível confirmar a identidade de seu originário. Ela pode ignorar o aviso ou tentar confirmar 
se realmente foi você quem enviou a mensagem.
134
Unidade III
 Observação
É importante ressaltar que essa confirmação não deveria ser feita 
por e-mail, pois se alguém estiver tentando se passar por você, poderia 
ter enviado a mensagem de um endereço de e-mail falso, mas que 
aparenta ser de sua propriedade. Por exemplo, imagine que alguém quer 
se passar por Ricardo Sewaybriker. Mesmo que ele não possua conta no 
hotmail.com, alguém mal-intencionado poderá facilmente cadastrar o 
nome sewaybriker@hotmail.com e assim usar sua identidade para falar 
com outros se passando por ele.
Ao fazer contato com você, a pessoa que recebeu seu e-mail assinado ainda poderá solicitar a 
confirmação de autenticidade da sua chave mediante uma impressão digital da chave informada na 
tela do aplicativo. Você então passará a impressão digital correta e a pessoa verificará que o valor 
apresentado coincide com o informado.
A partir disso, ao indicar ao aplicativo que a autenticidade do certificado foi confirmada, ele será 
salvo para uso em futuras mensagens, que poderão ser autenticadas automaticamente.
Principalmente devido à necessidade de confirmar diretamente com o dono a autenticidade da chave, 
a primeira verificação tende a ser penosa, porque exige a utilização de algum canal de comunicação 
diferente do e-mail e porque impacta e atrapalha o fluxo de trabalho e a leitura dos e-mails. Suponhamos 
que essa pessoa use uma ligação telefônica para confirmar a veracidade do seu certificado e, nessa 
ligação telefônica, reconhece sua voz, recordando-se do congresso onde se encontrou com você. Na prática, 
ela está verbalmente autenticando sua identidade.
Se, porventura, essa pessoa também for proprietária de uma chave PGP, a situação pode ficar 
interessante, pois ela incluiu você na rede dela quando confirmou e aceitou seu certificado. Essa pessoa 
está confiante de que o certificado pertence a você e se tornou um membro a mais na rede daqueles 
que confiam que o certificado apresentado se refere a você.
Se houvesse como tornar esse elo de confiança público, você poderia indicar essa pessoa como 
referência, não um fiador, mas um confiado, alguém que confia no seu certificado. Supondo que esse 
processo se repita com uma série de conhecidos seus, gradativamente, ao acumular pontos de confiança, 
ficará mais fácil para outras pessoas confiarem no seu certificado, sem precisar, necessariamente, ligar 
para você ou confirmar sua autenticidade por vias secundárias.
Segundo Wykes (2016), esse é o princípio de uma rede de confiança, em que vão sendo acumulados 
votos de credibilidade de diversos contatos de modo a permitir que outras pessoas possam confiar cada 
vez mais que sua identidade é fielmente representada pelo certificado. Contudo, será que é possível 
confiar na identidade de alguém que você ainda não conhece?
135
CRIPTOGRAFIA E CERTIFICAÇÃO DIGITAL
Consideremos o fenômeno que faz funcionar e crescerem as redes sociais: o fenômeno dos múltiplos, 
variados e às vezes surpreendentes elos que ligam as pessoas. Nas redes sociais, percebemos quão 
pequeno é o mundo, pois, pelo grupo de indivíduos que conhecemos diretamente, podemos chegar a 
outras pessoas afins e, a partir delas, alcançar outras mais distantes e assim por diante.
Conforme algumas pesquisas, em pouco tempo, e com poucos elos, é possível circunavegar o mundo 
e chegar a qualquer pessoa, em qualquer lugar. Quando se inclui a questão de afinidade pelos interesses 
profissionais, como área de especialização tecnológica ou pessoal, como hobbies, gostos e preferências, 
a distância entre as pessoas se reduz ainda mais.
É nessa base que se fundamenta uma rede de confiança PGP. Procura-se colher o máximo de votos 
de confiança por meio de sua rede de conhecidos, de tal forma que quando alguém procurar uma 
confirmação de autenticidade de seu certificado, haverá grande chance que encontre um elo, mesmo 
que indireto.
Sempre caberá à pessoa decidir o quanto confiará na identidade fornecida, conforme o número 
e a qualidade dos elos encontrados, como ocorre nas redes sociais, nas quais nem todos aceitam as 
solicitações de amizade provindas de conhecidos indiretos. Existe nisso uma questão de escolha e 
princípios, definições individuais sobre o que realmente significa amizade e relacionamento profissional.
Para Wykes (2016), na distribuição de chaves e certificados surge outro questionamento, sobre 
como as pessoas que já têm seu certificado vão ficar sabendo dos novos elos de confiança que você 
ganhou. Aos poucos, você vai se tornando uma pessoa munida de uma identidade confiável, mas como 
manter atualizados todos os seus contatos?
Existem diversos servidores públicos, chamados PGP key servers, que mantêm uma base atualizada 
de certificados PGP. Eles trabalham em rede, replicando entre eles as últimas modificações e 
inclusões na base, de forma que, com o passar do tempo, convergem para uma base única replicada 
em vários pontos.
O certificado PGP é uma estrutura flexível e dinâmica e sempre permite que sejam incluídas novas 
recomendações, aumentando os elos da teia de confiança, sem que o proprietário da chave privada 
precise se envolver. Os servidores PGP auxiliam nisso, pois, ao receber uma nova assinatura para um 
certificado já registrado, o servidorautomaticamente a acrescenta ao certificado. Basta alguém consultar 
qualquer um deles para obter uma cópia das informações mais recentes sobre a pessoa e seu certificado.
Segundo Wykes (2016), os elos de confiança com criptografia representam, na prática, um voto 
de confiança a uma assinatura digital calculada sobre a chave primária e as informações de identidade de 
alguém. No exemplo da pessoa que você conheceu em um congresso, ao confirmar sua identidade, ela 
utilizará sua chave privada para assinar seu certificado.
Um certificado PGP pode ter mais de uma identidade e os votos de confiança geralmente são 
referentes a uma identidade por vez. No exemplo anterior, a pessoa recebeu uma mensagem de um 
endereço de e-mail específico e não terá necessariamente como confirmar outros endereços ou 
136
Unidade III
identidades que eventualmente possa haver. Ter múltiplas identidades é uma decisão de cada um, mas 
acaba se tornando cada vez mais necessário atualmente, em função da segmentação que ocorre entre 
as nossas diferentes personalidades on-line e por questões de privacidade.
Uma única pessoa assume identidades diferentes, em momentos distintos. Ao se cadastrar para 
comprar um bilhete de avião, participar de um sorteio ou questionário on-line, utiliza uma identidade 
diferente daquela que apresentou na esfera profissional ou a bancos e à Receita Federal, por exemplo.
Para Wykes (2016), as assinaturas digitais, com suas garantias de integridade e autenticidade 
de origem das informações, são importantes diante dos sérios problemas que nossos sistemas de 
comunicação eletrônica estão enfrentando, principalmente o spam. Entretanto, diante das revelações 
de monitoramento e rastreamento maciço por governos, organizações multinacionais e regimes políticos 
repressivos, a questão de privacidade está retornando aos holofotes. Nesse sentido, o PGP possui pleno 
suporte para a encriptação de mensagens; inclusive, a privacidade foi a inspiração original da criação do 
PGP (pretty good privacy: privacidade razoavelmente boa).
Para Wykes (2016), a vulnerabilidade do PKI reside em que toda a cadeia PKI termina ao chegar no 
nível máximo de autoridade certificadora e, por definição, não há nenhuma entidade superior que possa 
garantir a veracidade de seu certificado.
Essa AC primária, portanto, se encontra na obrigação de se autogarantir pela geração de um 
certificado raiz autoassinado. Isso traz uma série de incômodos e mesmo perigos à sociedade e aos 
sistemas que dependem de certificados PKI, pois esses certificados raiz precisam ser distribuídos para 
todos os lugares em que certificados e assinaturas digitais serão validados.
E, ao ser distribuído, torna-se imprescindível que haja alguma confirmação de que realmente se trata 
de um certificado raiz verídico, antes de confiar nas cadeias de certificado abaixo dele. E se porventura 
um certificado raiz falsificado for dado como autêntico, passa-se a confiar automaticamente em toda 
uma cadeia de certificados presumivelmente também falsificados.
Esse problema é resultado da configuração vertical das hierarquias de certificado no modelo PKI. 
À medida que se sobe na hierarquia, aumenta-se a responsabilidade associada ao certificado, com o 
consequente aumento das exigências da AC no que se refere à sua confiabilidade.
Essa característica do modelo PKI, que se afunila em direção ao certificado raiz, tende a criar pontos 
de falha única. Qualquer quebra de segurança nos níveis mais altos pode ser desastrosa para milhares 
ou milhões de organizações ou pessoas, conforme testemunhado quando falhas desse tipo realmente 
aconteceram com ACs como a DigiNotar e a Comodo, para citar apenas alguns exemplos públicos. Foram 
gerados certificados válidos para empresas como Google, Yahoo, Skype, Mozilla e Microsoft, entre outras, 
sem que, no entanto, essas empresas soubessem de sua existência, permitindo que os responsáveis pelos 
ataques pudessem criar sites falsos que pareciam autênticos para os usuários desavisados.
Para Wykes (2016), os sistemas de reputação tiveram vários e sérios problemas com certas ACs, 
houve diversas propostas e iniciativas para corrigir ou, pelo menos, diminuir os riscos. Na essência, 
137
CRIPTOGRAFIA E CERTIFICAÇÃO DIGITAL
essas iniciativas funcionam à base de reputação: as redes de servidores recebem informações sobre os 
certificados digitais encontrados na internet e calculam um índice de confiabilidade desses certificados.
Como exemplo, o certificado para www.google.com raramente muda, então acumula uma boa 
reputação, a partir dos milhões de navegadores que recebem esse certificado e avisam os servidores 
de reputação. Contudo, se aparecer um certificado novo, falso, para esse mesmo domínio, os 
servidores de reputação não o reconhecerão e lhe darão uma nota baixa, permitindo que os usuários 
sejam avisados por com mensagens como “esse certificado para Google.com ainda não foi visto, 
podendo ser indício de um ataque ou evidência que você acessou um site falso. Sugerimos verificar”.
Para Wykes (2016), o modelo PGP sofre com uma série de inconvenientes, principalmente em relação 
à necessidade de criar e manter atualizada uma rede de confiança. Enquanto com o modelo PKI basta 
solicitar ou adquirir seu certificado, para usar seu certificado plenamente confiável de imediato, uma 
chave PGP nasce não confiável e vai ganhando credibilidade à medida que pessoas de sua rede atribuem 
a ela maiores graus de confiança.
A criação de uma rede de confiança pode ser trabalhosa, por ser uma atividade manual, precisando 
galgar assinaturas de confiança, pessoa por pessoa. Como consequência, nem sempre existe um elo 
intermediário entre duas pessoas e, na falta de intermediários, um desconhecido pode não querer 
reconhecer sua chave como confiável.
6.3 Modelos híbridos
Para Wykes (2016), existe certo paradoxo em relação à situação atual do modelo PKI, ao considerar 
que ele fica obrigado a conviver com algumas centenas de raízes, ao passo que funciona plenamente 
no caso de existir uma única raiz.
Como não podemos mais confiar nos certificados gerados por essa multiplicidade de ACs públicas, 
passamos a consultar algum servidor de reputação na internet sobre se realmente podemos confiar em 
determinado certificado. Efetivamente, transferimos o elo de confiança, por não confiar mais na AC, 
e passamos a dar crédito aos servidores de reputação, muitas vezes sendo necessário consultar vários 
deles para tirar uma média.
O paradoxo está justamente nessa mudança de paradigma, na qual o modelo PKI gradativamente 
se aproxima do modelo PGP. Ao analisar os dois, não resta dúvida de que ambos sofrem de sérias 
deficiências, o que leva à conclusão de que a criação de um modelo novo, híbrido, talvez seja o mais 
indicado. Um argumento a favor dessa conclusão é, por exemplo, o de que o PGP já é por natureza um 
sistema de reputação e, portanto, pode trazer importantes lições para a mesa de discussões sobre como 
melhorar o modelo PKI.
Por outro lado, já existem organizações globais conhecedoras da identidade da maioria dos sites, das 
pessoas e das relações comuns entre elas que talvez pudessem servir como autoridades certificadoras. 
Assim, ao criarmos um modelo híbrido, descentralizado, mas unificado, poderíamos resolver grande 
parte dos problemas atuais. Além disso, as diferentes graduações de reputação necessárias poderiam ser 
138
Unidade III
fundamentadas nas redes sociais já existentes ou, no caso dos sites, averiguadas por meio dos acessos 
já efetuados pelos robôs de busca.
6.3.1 Estudo de caso: ICP-Brasil
O sistema brasileiro de certificação digital – ICP-Brasil foi criado em 2001 a partir de uma medida 
provisória e um decreto da Presidência da República que contempla uma cadeia de certificados 
digitais com raiz única, um arcabouço legislativo, uma estrutura administrativa e um conjunto de 
normas técnicas.
O ICP-Brasil tem o propósito de viabilizar a emissão de certificados digitais para a identificação 
virtual