Segundo fascículo do tutorial de criptografia
SEGURANÇA
Criptografia: teoria e prática, parte 2 Chaves públicas e privadas têm diversos usos e formas. Veja como usá-las e como elas são mal utilizadas. por Marcio Barbado Jr. e Tiago Tognozi
R
etomando o primeiro artigo desta série [1], vamos abordar agora mais alguns aspectos teóricos e práticos da criptografia. Em primeiro lugar, vamos observar as questões matemáticas envolvidas nessa área, formalizando matematicamente a criptografia assimétrica. Seja: K um conjunto dos pares de chaves e e d, tais que
E um sistema de encriptação
com uma coleção de funções Ee, ditas “E índice ezinho” e formalizadas como: Ee : e ∈ K
D um sistema de decriptação com uma coleção de funções inversas Dd, ditas “D índice dezinho” e formalizadas como:
(e,d) ∈ K;
70
e uma chave de encriptação pertencente a K, ou seja, uma
chave pública; d uma chave de decriptação pertencente a K, ou seja, uma chave privada;
Dd : d ∈ K
uma mensagem de texto puro; m c uma mensagem m, encriptada
tal que:
Ee (m) = c
e Dd (c) = m
A função de encriptação Ee possui dois parâmetros: a chave e; e a mensagem de texto puro m. Assim como a função de decriptação Dd, que possui: a chave d; e o texto cifrado c. Considerando-se os possíveis pares (Ee, Dd) para encriptação e decriptação, e uma mensagem encriptada c, não se chega a m mesmo que se conheça a coleção de funções Ee. Ou seja, conhecendo-se uma cha-
http://www.linuxmagazine.com.br
Criptografia | SEGURANÇA
ve pública e, não se chega à chave privada d correspondente. Ee contém funções ditas “trapdoor” e d é a informação “trapdoor” necessária para se obter as funções inversas Dd, que possibilitam as decriptações:
função bijetora a um número real, por exemplo, teremos um resultado. E para voltar ao real original, aplicase ao resultado a inversa da função. Exemplo para uma função de primeiro grau: f(x) = 2x + 1
Dd (Ee (m)) = m
Decifrar a si mesma
Por que uma chave pública não consegue decifrar o que ela mesma encripta? Utilizar uma chave pública e encriptar uma mensagem envolve a aplicação de uma função bijetora do tipo “trapdoor”. Tal função devolve a mensagem encriptada. Vamos relembrar alguns conceitos de funções. Considere a função:
Se desejarmos encriptar a mensagem “5” (o número cinco), aplicamos a função ao número 5 e teremos f(5)=11. Neste caso, “11” seria a “mensagem encriptada”. Para decifrá-la, é necessário obter a inversa de f(x), que é:
Figura 1 Função bijetora: injetora e sobrejetora.
x = (y-1)
Então: x = (11-1) → x=5
f(x) = y
Funções bijetoras (figura 1) são injetoras (diferentes valores de X levam a diferentes valores em Y, figura 2) e sobrejetoras (todo elemento de Y corresponde a pelo menos um elemento de X, figura 3). Portanto, uma função bijetora, sendo injetora e sobrejetora, possui o mesmo número de elementos em X e Y. Durante o período escolar básico, um contra-exemplo clássico oferecido aos alunos é a seguinte função: f(x) = x2
Note na tabela 1 que não se trata de uma função injetora. A tabela mostra que diferentes valores de X nem sempre conduzem a resultados distintos em Y. A função não é injetora, logo, não há bijeção. Ela não serve a fins de encriptação assimétrica. Convém, entretanto, salientar que a função também não é sobrejetora, pois os valores negativos de Y jamais serão alcançados. Assim como nos casos mais simples da Matemática, após aplicar uma
Linux Magazine #63 | Fevereiro de 2010
Assim, deciframos o “11” e obtivemos o “5“ original. Muitas pessoas fizeram esses cálculos a vida inteira, então não há nenhuma novidade. Decifrar uma mensagem encriptada com uma função “trapdoor” também envolve a obtenção de uma inversa. Porém, essa inversa não é facilmente obtida. Funções “trapdoor” fazem uso de mecanismos mais sofisticados, como o operador de módulo, que serve para encontrar o resto da divisão de um número por outro e, além disso, dificulta a obtenção da inversa.
Figura 2 Função injetora: cada elemento de X leva a um elemento diferente em Y.
Algoritmos assimétricos Os algoritmos apresentados a seguir se referem à componente de privacidade, ou seja, são utilizados para encriptação e decriptação: sistema ElGamal: algoritmo de criptografia assimétrica baseado em Diffie‑Hellman. O GnuPG se refere a ele como ELG‑E;
Figura 3 Função sobrejetora: cada elemento de Y corresponde a pelo menos um elemento de X.
RSA: Trata-se de uma família de funções “trapdoor” extremamente eficiente. 71
SEGURANÇA | Criptografia
Tabela 1: Função não injetora x
f(x)
2
4
-2
4
Autenticação
Considerando o contexto da criptografia, a autenticação é um conceito assimétrico empregado pelo destinatário para verificar a genuinidade de informações recebidas, providas de privacidade ou não. Assim, é possível determinar a verdadeira origem das informações recebidas. As técnicas que atribuem autenticidade a informações utilizam assinaturas digitais e são muito exploradas comercialmente no gerenciamento de identidades de pessoas físicas, jurídicas e computadores (mais sobre esse assunto em um próximo artigo).
Assinatura digital
Assinaturas tradicionais com tinta de caneta sobre papel são marcas gráficas que cumprem a função de identificar seus autores. Recordando: a criptografia assimétrica permite que duas ou mais entidades distintas possam trocar dados de forma segura, graças ao par chave pública e chave privada. Os fatores que compõem a segurança proporcionada pelo par de chaves são dois: a privacidade e a autenticidade. O primeiro artigo desta série [1] mostrou como usufruir da privacidade proporcionada pelo par de chaves. O exemplo a seguir almeja não apenas repassar conceitos, mas principalmente enfatizar a diferença entre privacidade e autenticidade: um computador no Brasil deve transmitir informações impor‑ tantes para outro que se encon‑ 72
tra em Uganda; cada computa‑ dor possui seu par de chaves e, além disso, cada um conhece a chave pública do outro; antes do envio, o equipamento bra‑ sileiro usa a chave pública do ugandense para encriptar as informações; no recebimento, o destinatário ugandense utiliza sua chave privada para acessar as informações. Esse exemplo apresenta uma situação simples na qual a troca de informações utiliza a criptografia assimétrica para um computador enviar informações com privacidade a outro. O computador ugandense consegue decifrar o recebido, mas não consegue determinar se aquelas informações realmente partiram do referido computador brasileiro, pois este não assinou digitalmente o que enviou. O exemplo a seguir é uma adaptação do anterior e mostra como o computador do Brasil deveria proceder para conferir privacidade e autenticidade ao conteúdo enviado: um computador no Brasil deve transmitir um arquivo confiden‑ cial a um outro que se encontra em Uganda, destinatário este que exige garantias da procedên‑ cia do arquivo; cada computa‑ dor possui seu par de chaves e, além disso, cada um conhece a chave pública do outro; antes do envio, o computador brasileiro usa a chave pública do ugan‑ dense para encriptar o arquivo, e sua própria chave privada para assinar digitalmente o que enviará, atribuindo ao envio a garantia que o destinatário exige; no recebimento, o equi‑ pamento ugandense utiliza sua chave privada para acessar os dados recebidos, e a chave pú‑ blica do computador brasileiro
para verificar a autenticidade do que recebeu. Esse exemplo apresenta uma situação de maior aproveitamento da criptografia assimétrica. Tanto o remetente quanto o destinatário usam uma chave de cada par e, ao final do processo, todas as quatro chaves envolvidas foram usadas. O remetente usa: chave pública do destinatário para conferir privacidade à comunicação, e sua própria chave privada para assinar (atribuir autenticidade ao “comunicado”). Ou seja, a chave pública do destinatário ugandense é utilizada para impedir terceiros de acessar as informações do arquivo em questão, e a chave privada do remetente brasileiro é utilizada para garantir a procedência do arquivo. Já o destinatário usa: sua própria chave privada para decriptar o que recebe, e a chave pública do remetente para verificar a assinatura digital e determinar se as informações realmente foram originadas por ele. Ou seja, uma chave (a privada) do destinatário ugandense, é utilizada para acessar as informações do arquivo recebido, e uma chave (a pública) do remetente brasileiro é utilizada para verificar a origem do arquivo. Um terceiro exemplo a destacar é aquele no qual a privacidade não é utilizada, mas apenas os aspectos de autenticidade (assinatura digital): um computador no Brasil deve transmitir um arquivo de do‑ mínio público a outro que se encontra em Uganda, destina‑ tário este que exige garantias da procedência das informações
http://www.linuxmagazine.com.br
Criptografia | SEGURANÇA
que recebe; cada computador possui seu par de chaves e, além disso, cada um conhece a cha‑ ve pública do outro; antes do envio, o computador brasileiro usa sua própria chave privada para assinar digitalmente o que enviará, atribuindo ao arquivo a garantia que o destinatário exige; no recebimento, o equipamento ugandense utiliza a chave pú‑ blica do computador brasileiro para verificar a autenticidade do que recebeu. A figura 4 demonstra este último cenário. Assinar com uma chave privada fornece autenticidade, não privacidade. Isso porque nesse caso, a chave usada para verificação é literalmente pública. O GnuPG, software livre para criptografia, trabalha a assinatura digital com uma função de hash, que
Arquivo original
gera um hash do conteúdo a enviar. Então, ele encripta esse valor com a chave privada do remetente, e isto é a assinatura digital. A assinatura é enviada com uma cópia completa e inalterada do conteúdo original. O destinatário não precisará utilizar um programa específico para acessar as informações recebidas. O GnuPG será utilizado, nesse caso, apenas para verificar a origem do conteúdo recebido, agindo da seguinte forma: o programa lê o conteúdo original e, com a mesma função de hash utilizada pelo remetente, gera um hash do conteúdo recebido e armazena aquele valor; em seguida, ele decripta a assinatura utilizando a chave pública do remetente, gerando um segundo valor que, sendo igual ao primeiro hash, comprova a origem do conteúdo recebido.
Caso se envie uma mensagem digitalmente assinada a um destinatário desprovido de programas de criptografia, este conseguirá acessar (ler) a mensagem, mas não será capaz de verificar sua autenticidade. Relembrando: dado um par de chaves, sendo uma delas para assinar o documento, a outra é usada para verificar sua legitimidade.
DSA
O algoritmo de natureza assimétrica DSA, Digital Signature Algorithm, foi criado pelo governo dos EUA para utilização em assinaturas digitais.
Servidores de chaves públicas É comum disponibilizar chaves públicas em serviços gratuitos oferecidos na Internet. Indubitavelmente, um dos mais notórios servidores de
Remetente (Brasil)
Destinatário (Uganda)
Chave privada
Chave pública
Assinatura digital
Arquivo digitalmente assinado
Verificação
Arquivo digitalmente verificado
Figura 4 A criptografia é capaz de garantir a privacidade e a autenticidade de um conteúdo.
Linux Magazine #63 | Fevereiro de 2010
73
SEGURANÇA | Criptografia
Tabela 2: Certificado digital e criptografia Tipo de criptografia
Componente público Componente privado
Comum
chave pública
chave privada
Certificação digital
certificado digital
chave privada
chaves para o padrão PGP é o do Massachusetts Institute of Technology, em http://pgp.mit.edu/, que oferece extrema agilidade para o cadastro de chaves públicas. Além dele, é interessante citar a rede de servidores de chaves CryptNET, cujos servidores são apresentados em http://keyserver.cryptnet.net. Um desses servidores, localizado em Boston, EUA, responde pelo nome de bos.us.ks.cryptnet.net e pode ser acessado pelo protocolo OpenPGP HTTP Keyserver Protocol (HKP) na porta 11371. Também há uma listagem de servidores, disponibilizada pelo Open Directory Project, um respeitado diretório de referências da Netscape, em [2].
O padrão OpenPGP
No ano de 1991, muitos países – inclusive os EUA – empregavam legislações pavorosamente intrusivas, restringindo o uso de criptografia como artifício fortalecedor de privacidade em transações digitais. Foi nesse contexto que um programador e ativista político chamado Phil Zimmermann apresentou ao mundo o programa PGP (Pretty Good Privacy), possuidor de uma robustez criptográfica que excedia muitas das citadas leis. Aquilo obviamente não seria facilmente aceito, e Zimmermann foi então processado como uma espécie de terrorista cibernético. Assim como hoje, as leis vigentes naquele momento não conseguiam acompanhar os avanços das tecnologias ligadas aos sistemas de informação. Tamanha era a confusão causada no âmbito legislativo 74
que, nos Estados Unidos, embora proibissem a disseminação daquelas informações em formato digital, simplesmente inexistia menção à troca dessas mesmas informações impressas em papel. Atento a essa brecha, o Massachusetts Institute of Technology publicou um livro com o código-fonte do PGP e o programa então ganhou a notoriedade de que necessitava, consolidando-se inclusive fora do meio técnico. Finalmente em 1996, as investigações sobre Phil Zimmermann cessaram e ele então fundou a empresa PGP Inc., por meio da qual foi escrito o software proprietário PGP‑5, lançado em 1997, mesmo ano em que Zimmermann solicitou autorização ao IETF para que, baseando-se no PGP‑5, pudesse escrever uma especificação mundialmente aceita, que viria a ser chamada de OpenPGP, hoje definida na RFC 2440 [3]. A PGP Inc. foi comprada pela Network Associates em 2002.
Certificado digital
Certificados digitais podem ser entendidos como “chaves públicas evoluídas” e servem principalmente a fins de e‑business. Utilizando um certificado dessa natureza, o par “chave pública e chave privada” dá lugar ao par “certificado digital e chave privada” (tabela 2). Respeitando rigores de jargão e idioma, é importante esclarecer a diferença de significado entre certificado e certificação, muito embora as duas palavras sejam utilizadas de maneira permutável sem maiores problemas de interpretação para o leitor.
“Certificado”, no presente contexto, pode designar um documento. Já o termo “certificação” diz respeito à emissão de um certificado. Remete ao ato de criação de um certificado digital. O certificado digital, especificamente, é, como se afirmou previamente, uma “chave pública evoluída”. De forma reducionista, trata-se de um documento emitido por um órgão competente, contendo uma chave pública e também algumas informações adicionais que atestam a ligação existente entre tal chave e seu detentor. Uma das informações adicionais presentes no documento é a assinatura digital do órgão que o gerou. Tecnicamente, o certificado digital é um arquivo de computador com suas peculiaridades bem definidas por um dos padrões existentes. O mais aceito entre tais padrões se chama X.509, definido pelo ITU‑T (International Telecommunication Union, Telecommunication sector). Exemplos de certificados digitais são alguns arquivos com extensão cer utilizados por websites. Pessoas físicas podem entender o certificado digital como um documento de identificação para uso na Internet, tal qual o RG e o CPF em atividades cotidianas mais convencionais. Tipicamente, um certificado digital possui:
uma chave pública; o nome da entidade que ele representa; data de expiração do certificado; nome da organização que emitiu o certificado (chamada AC, de autoridade certificadora); assinatura digital da referida organização; um número de série; e algumas informações adicionais, chamadas genericamente de “características”.
http://www.linuxmagazine.com.br
Criptografia | SEGURANÇA
Somente autoridades credenciadas podem emitir tais documentos providos de valor jurídico. Isso envolve uma entidade confiável, que é um órgão certificador chamado de “autoridade certificadora” ou “AC” (“CA”, em inglês), que atesta o caráter genuíno de chaves públicas. O par chave privada e certificado digital emitido por uma dessas autoridades serve, por exemplo, para conferir valor legal a logs de sistemas e redes, tornando tais registros aceitáveis em tribunais. Suponha que um funcionário mal intencionado de uma empresa utilize sua conta de usuário no domínio para obter acesso indevido a informações confidenciais. Seus empregadores então detectam tal comportamento por meio dos registros do domínio. Caso a empresa não possua uma ICP (infraestrutura de chaves públicas), poderá tão somente punilo como funcionário – isto é, com multa ou demissão –, mas não obterá grandes resultados denunciando-o ao poder público caso não utilize pares de chaves emitidos por um órgão
autorizado pelo Governo Federal. Portanto, nesse caso, os logs que a empresa tem como provas não possuiriam valor legal. O processo de registro de uma chave pública pode ser comparado à situação na qual cada cidadão brasileiro formaliza legalmente sua identidade civil junto a um órgão autorizado, por meio da obtenção do documento que se conhece por RG (registro geral) ou carteira de identidade. Isso origina o que se conhece por certificação digital. Qualquer pessoa, física ou jurídica, pode criar um certificado digital. Um “certificado de validação avançada” (EV certificate) é um tipo de certificado útil a bancos, pois apresenta proteção adicional. A CSR (certificate signing request, ou requisição de assinatura de certificado), é um arquivo de computador que contém uma mensagem, que é enviada a uma autoridade certificadora para solicitar um certificado digital. A tabela 3 dá alguns exemplos de situações em que certificados digitais são úteis.
ARs e ACs
Organizações supostamente confiáveis, as autoridades de registro (ARs) e as autoridades certificadoras (ACs) atuam em conjunto quando da emissão do certificado. Assim como as ARs, as ACs solicitam emissões de certificados, mas dividem‑se em dois tipos:
Autoridades de Certificação Raiz, que emitem diretamente os certificados, e Autoridades de Certificação Intermediárias, cuja emissão de certificados é repassada às Autoridades de Certificação Raiz.
Existe, portanto, uma hierarquia de ACs, que constitui uma condição necessária para a criação de uma infraestrutura de chaves públicas. Uma AC Raiz é capaz de emitir certificados digitais para outras ACs, enquanto que uma AC Intermediária cujo certificado foi emitido pela AC Raiz é capaz de emitir certificados para entidades. A confiança existe sempre de baixo para cima, isto é, a entidade confia
Tabela 3: Algumas utilidades de certificados digitais Tipo de transação
Entidades cujos certificados são envolvidos
Transações eletrônicas de risco realizadas entre empresas do mercado financeiro
Empresas participantes da transação
Serviços de “Internet banking” utilizados por pessoas físicas
Pessoas físicas e computadores do banco
Serviços de “Internet banking” utilizados por pessoas jurídicas
Pessoas jurídicas e computadores do banco
Serviços de compras online utilizados por pessoas físicas
Pessoas físicas e computadores da loja online
Serviços de compras online utilizados por pessoas jurídicas
Pessoas jurídicas e computadores da loja online
Serviços para declaração de imposto de renda para pessoas físicas
Pessoas físicas e computadores da Receita Federal
Serviços para declarações de imposto de renda para pessoas jurídicas
Pessoas jurídicas e computadores da Receita Federal
Linux Magazine #63 | Fevereiro de 2010
75
SEGURANÇA | Criptografia
na AC Intermediária, que por sua vez confia na AC Raiz. Certas vezes, uma Autoridade de Registro (AR) também é Autoridade Certificadora (AC). Antes de emitir um certificado digital, uma dada AC precisa de informações sobre quem ou o que irá utilizar aquele certificado e, além disso, essa organização fica incumbida de controlar os referidos documentos e revogá‑los se necessário. Isso ocorre por meio da manutenção de uma lista chamada CRL (Certificate Re‑ vocation List, ou lista de revogação de certificados).
CRL
A Certificate Revocation List é uma lista de revogação de certificados que contém certificados digitais que perderam a validade por alguma razão. Exemplos que tornam nulo um certificado digital: atinge-se a data de expiração do certificado, “características” contidas no certificado deixam de ser válidas, ou a chave privada referente ao certificado é comprometida.
ICP-Brasil
A ICP‑Brasil torna oficial o par “chave privada e certificado digital (chave pública)” e exige o padrão “X.509v3”. A AC raiz da ICP‑Brasil é o ITI, Instituto Nacional de Tecnologia da Informação [4], uma autarquia federal vinculada à Casa Civil brasileira.
Aberrações de “cloud”
O desespero ganancioso da indústria em impor o modelo outrora chamado “Saas” (Software as a Service), e agora “cloud computing”, cria algumas aberrações criptográficas do ponto de vista conceitual. Uma delas diz respeito aos serviços de email baseados na Web, o webmail. 76
Algumas empresas oferecem o serviço de webmail, incluindo recursos de criptografia assimétrica no padrão PGP para a troca de mensagens. ocorre que essa situação contraria o conceito de privacidade inerente às chaves privadas. Tratamse de serviços de webmail capazes de gerar pares de chaves para seus usuários sem entretanto aceitar que estes utilizem pares que já possuem. Os pares gerados ficam armazenados na tão enaltecida nuvem, ou seja, localizam-se nos servidores das empresas que oferecem o serviço. Em alguns casos de provedores no Brasil, as chaves privadas não são
reveladas aos seus usuários, apenas as públicas. O usuário do webmail pode utilizar a tal chave “privada” para decriptar mensagens recebidas e assinar mensagens que envia; contudo, não pode visualizá-la. São chaves “privadas” emprestadas. Isso significa, basicamente, que as chaves privadas geradas por tais serviços não são privadas. O armazenamento de chaves públicas em servidores da Internet faz parte da criptografia assimétrica. Já o armazenamento de chaves privadas é claramente paradoxal e representa uma ameaça à privacidade dos clientes em questão. n
Mais informações [1] Marcio Barbado Jr. e Tiago Tognozi, “Criptografia: teoria e prática”: http://lnm.com.br/article/3241 [2] Lista de servidores de chaves: http://www.dmoz.org/Computers/ Security/Products_and_Tools/Cryptography/PGP/Key_Servers/ [3] RFC 2440 do IETF: http://www.apps.ietf.org/rfc/rfc2440.html [4] Instituto Nacional de Tecnologia da Informação: http://www.iti.gov.br
Sobre os autores Marcio Barbado Jr. (marcio.barbado@bdslabs.com.br) e Tiago Tognozi (tiago.tognozi@bdslabs .com.br) são especialistas em segurança na BDS Labs (www.bdslabs.com.br).
Nota de licenciamento Copyright © 2010 Marcio Barbado Jr. e Tiago Tognozi É garantida a permissão para copiar, distribuir e modificar este documento sob os termos da Licença de Documentação Livre GNU (GNU Free Documentation License), Versão 1.2 ou qualquer versão posterior publicada pela Free Software Foundation. Uma cópia da licença está disponível em http://www.gnu.org/licenses/fdl.html
Gostou do artigo? Queremos ouvir sua opinião. Fale conosco em cartas@linuxmagazine.com.br Este artigo no nosso site: http://lnm.com.br/article/3292
http://www.linuxmagazine.com.br
Complete
a sua coleção
Mais informações Site: www.linuxmagazine.com.br