Coluna do Alexandre Borges
COLUNA
Certificação e
assinaturas digitais
Em um esforço hercúleo, Alexandre Borges se desdobra
para ensinar a qualquer um os mistérios da criptografia de
chaves simétricas, assimétricas e dos certificados digitais.
E
scuto frequentemente algumas perguntas vindas
de analistas: “Como garantir que nossas compras na Internet sejam seguras? O que significa
aquele ‘cadeado’ na barra de status do navegador? Por
que, quando entramos em algum site de home banking,
solicitam-nos que aceitemos o tal do ‘certificado digital’? Afinal, para que serve tudo isso?”
Para mim é claro e cristalino que você leitor sabe as
exatas respostas para essas perguntas; contudo, de que
maneira podemos explicar essas coisas para outros analistas e pessoas leigas exemplificadas por profissionais de
outras áreas como vendedores, advogados ou médicos?
A informação somente tem valor e melhora a sociedade
quando é difundida e desfazer alguns mitos seria interessante para ajudar na conscientização da importância
dessas informações e da tecnologia no dia-a-dia.
Então quer dizer que é fácil explicar os conceitos de criptografia simétrica, assimétrica, hashing, certificado digital e
assinatura digital? Longe disso. Aliás, nada mais difícil, mesmo para técnicos que já fazem parte deste mundo de TI.
Eis como eu faço quando quero explicar as questões acima.
Imaginem duas pessoas, com suas respectivas máquinas (A e B). A pessoa A quer enviar uma informação para
a pessoa B, porém deseja que ninguém possa, no meio do
caminho, visualizar a informação. Para tanto ela usa um
algoritmo de chave simétrica. Mas o que é isso? Simples:
é um algoritmo (ou programa, para leigos) que embaralha
as informações e, para fazê-lo, usa uma espécie de senha
(chave de sessão ou key session) para codificar os dados e a
mesma senha para decodificá-los (desembaralhar os dados).
É daí que vem a palavra simétrica: a mesma chave é usada
nas duas pontas da comunicação, ou seja: para codificar e
decodificar. E então, o que as pessoas fazem?
A pessoa da máquina A combina com a pessoa da máquina B um algoritmo e uma senha (key session), e depois
codifica os dados a serem enviados como elas combinaram.
A pessoa da máquina B, ao receber estes dados, decodifica16
-os usando o algoritmo e a senha já combinados entre as partes. Aliás, por que o nome “chave de sessão” (key session)?
Porque esta senha (chave) somente vale para cada sessão de
envio de informações, ou seja, no próximo envio o usuário
pode combinar uma nova senha. Funciona? Muito bem. É
rápido? Bastante. Só tem um pequeno problema: como as
pessoas vão trocar esta senha (chave de sessão) entre si? Qualquer meio está sujeito a interceptação: email, SMS, telefone,
fax, pessoalmente, correios... Nada, absolutamente nada, é
seguro para trocar estas senhas (ou chaves). É aí que está o
risco: se alguém tiver posse desta senha (chave) e tiver uma
vaga ideia do algoritmo usado, poderá decodificar as informações trocadas e ler o que foi enviado. E agora, o que fazer?
Neste ponto, entram em jogo os algoritmos assimétricos.
Por que assimétricos? Porque a mesma chave que é usada
para codificar NÃO é a mesma usada para decodificar. Eis
como ocorre o processo: a pessoa da máquina A, através de
um algoritmo assimétrico escolhido em comum acordo entre as partes, gera um par de chaves (ou senhas, para leigos),
a pública e a privada (pub-A e priv-A). Como o nome diz,
a chave pública pode (e deve) ser conhecida por qualquer
pessoa; todavia, a privada é somente de conhecimento próprio e individual. Em seguida, a pessoa da máquina B faz o
mesmo, ou seja: gera seu par de chaves assimétricas (pub-B
e priv-B). E o que se segue é que, como a pessoa da máquina
A sabe a chave pública da pessoa da máquina B (pub-B), ela
usa esta chave (pub-B) para codificar, usando o algoritmo
simétrico combinado, a chave de sessão que elas queriam
trocar e não podiam de maneira segura. Aí a tal chave de
sessão (codificada) é enviada para a pessoa da máquina B.
Agora ambos, com a mesma chave pública, podem trocar
dados criptografados como explicado acima. Aí que está a
mágica: uma vez que uma informação é codificada dessa
forma (usando a chave pub-B), somente com a respectiva
chave privada (priv-B) é possível decodificá-la. Esse mecanismo é uma das maravilhas das chaves assimétricas: o que
é codificado com uma chave do par gerado (público e pri-
www.linuxmagazine.com.br
vado) somente pode ser decodificado com a outra chave do
mesmo par. Funciona? Sim. É rápido? Hum... aí vem um
pequeno detalhe: ao contrário dos algoritmos simétricos, os
assimétricos são muito (e coloque muito nisso) mais lentos.
Se fossem rápidos, poderíamos abandonar os simétricos e
já enviar a informação (e não apenas a chave de sessão)
com o uso do par de chaves simétricas (pública e privada).
Tudo resolvido? Não. Por quê? Porque a pergunta agora
é outra: como a pessoa da máquina A pode ter certeza absoluta de que a chave pública da pessoa da máquina B é
dela mesma? E se for de um hacker fingindo ser a pessoa
da máquina B? Aí a pessoa da máquina A teria um grande
problema: ela estaria codificando a chave de sessão com
a chave pública do hacker e enviando para a pessoa da
máquina B (que não conseguiria abrir a informação). O
hacker, interceptando os dados codificados, conseguiria
decodificar a informação (que é a chave de sessão) e poderia se passar pela pessoa da máquina B, comprometendo
toda a troca de informações entre as partes. É exatamente
agora que entra em cena o certificado digital.
Aliás, o que é esse certificado e como funciona? A parte
interessada (por exemplo, as pessoas das máquinas A e B, ou
mesmo uma empresa, em um contexto mais realista), contrata uma terceira parte (autoridade certificadora, também
conhecida como CA) e, no momento do contrato, envia sua
própria chave pública. Então essa companhia certificadora
(CA) emite o certificado dessa pessoa ou empresa. Esse certificado é um objeto (ou um selo, para leigos) emitido pela
autoridade certificadora (CA), que possui total idoneidade
internacional (Certsign, por exemplo). O certificado contém
dentro de si a chave pública enviada pela parte interessada
e algumas informações sobre a pessoa ou empresa que está
comprando o serviço de certificação digital. E aqui está a
ideia principal: quando a pessoa da máquina A pede a chave
pública da pessoa da máquina B (pub-B), a pessoa da máquina B não envia a sua chave pública diretamente, e sim seu
certificado digital emitido por uma companhia certificadora.
Assim, quem está garantindo e atestando que aquele
certificado (mais especificamente, a chave pública) vem da
pessoa da máquina B é a autoridade certificadora que tem
reconhecimento global para tal ação. Ou seja: ninguém
(nem a pessoa da máquina A e nem a da máquina B) corre o risco de se ver enganado por um hacker. Funciona?
Muito bem. Resolvido o problema? Ainda não. Por quê?
Porque quem pode garantir para a pessoa da máquina A
que aquele certificado da pessoa da máquina B, emitido
e atestado pela autoridade certificadora (CA) foi, de fato,
emitido por ela? E se foi um hacker que está se passando
pela CA e forjou um certificado? Puxa! Isso parece não ter
mais fim... Sempre há um risco, mas tem solução.
Antes de avançarmos para o próximo ponto, é útil comentar o que são e para que servem os algoritmos de hash.
Linux Magazine #85 | Dezembro de 2011
Fundamentalmente, a ideia é assegurar a integridade dos
dados, ou seja, ter certeza de que os dados enviados pela
máquina A são os mesmos recebidos pela máquina B. E
como isso acontece? Com esses dados é feita uma conta (daí
o uso do algoritmo) e esse cálculo é anexado junto aos dados
a serem enviados. Quando esses dados chegam à máquina
B, o mesmo cálculo é feito usando-se os dados recebidos, e
o resultado é comparado com o cálculo que foi feito pela
máquina A e anexado aos dados enviados. Se os resultados
forem iguais, os dados que chegaram estão íntegros e não
sofreram nenhuma alteração. Se houver discrepância, pede-se para retransmitir os dados novamente. Simples, não?
Agora sim é possível falar do último elo desta corrente,
que é a assinatura digital. E qual é o seu objetivo? Garantir que, de fato, o certificado digital foi realmente emitido
pela companhia certificadora (CA). Para tanto, ocorre o
seguinte processo: a CA (companhia certificadora), antes
de emitir o certificado para a pessoa da máquina A ou B,
faz um cálculo de hash desse certificado e criptografa esse
cálculo usando sua própria chave privada (sim... a chave
privada e não a pública, por isso chama-se assinatura digital), anexando o resultado no certificado. O usuário da
máquina A ou B, através do browser (que já tem diversas
chaves públicas cadastradas dentro dele) usa a chave pública da companhia certificadora (CA) para descriptografar o hash codificado do certificado que é, em seguida,
comparado com o cálculo feito pela própria máquina de
A ou B. Se as os hashes feitos na máquina forem iguais
ao hash que veio anexado ao certificado, pode-se garantir
que aquele certificado foi, de fato, emitido pela companhia certificadora (CA) em questão, pois a chave pública
da companhia certificadora (CA) somente decodifica os
dados criptografados com a sua respectiva chave privada.
Repare que a assinatura digital é contrária à codificação assimétrica: na assinatura digital, o dado é codificado
com a chave privada e decodificado com a pública. Na
criptografia assimétrica acontece o inverso, pois o dado
é codificado com a chave pública e decodificado com a
respectiva chave privada.
Esse processo descrito acima é à prova de bala? Sim.
As falhas são decorrentes de possíveis quebras dos algoritmos envolvidos, ou ainda erro na implementação deste
mecanismo. É exatamente por isso que os hackers (ou
melhor, crackers) costumam tentar atacar a ponta mais
fraca do processo, que é o usuário, e conseguir as senhas
(chaves) antes de tudo começar, pois durante o processo
isso é muito difícil – para não dizer impossível.
Até o mês que vem. ■
Alexandre Borges ([email protected]) é instrutor independente e ministra
regularmente treinamentos de tecnologia Oracle, Symantec e EC-Council (CEH e
CHFI), além de estar sempre envolvido com assuntos relacionados ao kernel Linux.
17