Criptografia Teoria e Prática - Parte 2

70 http://www.linuxmagazine.com.br

SE

GU

RA

NÇ

A

Segundo fascículo do tutorial de criptografia

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

Retomando 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 matemati-camente a criptografia assimétrica.

Seja:K um conjunto dos pares de chaves e e d, tais que

(e,d) ∈ K;

�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;

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:

Dd�:�d ∈ K

�m uma mensagem de texto puro; 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 decrip-taçã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-

71

| SEGURANÇACriptografia

Linux Magazine #63 | Fevereiro de 2010

RSA: Trata-se de uma família de funções “trapdoor” extrema-mente eficiente.

ve pública e, não se chega à chave privada d correspondente.

Ee contém funções ditas “trapdo-or” e d é a informação “trapdoor” necessária para se obter as funções inversas Dd, que possibilitam as decriptações:

Dd�(Ee�(m))�=�m

Decifrar a si mesmaPor que uma chave pública não con-segue decifrar o que ela mesma en-cripta? 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 concei-tos de funções. Considere a função:

f(x)�=�y

Funções bijetoras (figura 1) são injetoras (diferentes valores de X levam a diferentes valores em Y, fi-gura 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 ofereci-do 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 sem-pre 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 sim-ples da Matemática, após aplicar uma

função bijetora a um número real, por exemplo, teremos um resultado. E para voltar ao real original, aplica-se ao resultado a inversa da função.

Exemplo para uma função de primeiro grau:

f(x)�=�2x�+�1

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, é neces-sário obter a inversa de f(x), que é:

x�=�(y-1)�

Então:

x�=�(11-1)�→�x=5

Assim, deciframos o “11” e obtive-mos o “5“ original. Muitas pessoas fizeram esses cálculos a vida inteira, então não há nenhuma novidade.

Decifrar uma mensagem encrip-tada com uma função “trapdoor” também envolve a obtenção de uma inversa. Porém, essa inversa não é fa-cilmente obtida. Funções “trapdoor” fazem uso de mecanismos mais sofis-ticados, como o operador de módu-lo, 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.

Algoritmos assimétricosOs algoritmos apresentados a seguir se referem à componente de priva-cidade, 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 1 Função�bijetora:�injetora�e�sobrejetora.

Figura 2 Função�injetora:�cada�elemento�de�X�leva�a�um�elemento�diferente�em�Y.

Figura 3 Função�sobrejetora:�cada�elemento�de�Y�corres-ponde�a�pelo�menos�um�elemento�de�X.


SEGURANÇA | Criptografia

AutenticaçãoConsiderando o contexto da cripto-grafia, a autenticação é um conceito assimétrico empregado pelo destina-tá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 auten-ticidade a informações utilizam assinaturas digitais e são muito ex-ploradas comercialmente no geren-ciamento de identidades de pessoas físicas, jurídicas e computadores (mais sobre esse assunto em um próximo artigo).

Assinatura digitalAssinaturas tradicionais com tinta de caneta sobre papel são marcas gráficas que cumprem a função de identificar seus autores.

Recordando: a criptografia assi-mé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 se-guranç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 priva-cidade 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‑

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 si-tuação simples na qual a troca de informações utiliza a criptografia assimétrica para um computador enviar informações com privacida-de a outro.

O computador ugandense con-segue 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 adap-tação do anterior e mostra como o computador do Brasil deveria pro-ceder 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 si-tuação de maior aproveitamento da criptografia assimétrica. Tanto o re-metente 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 à co-municação, e

sua própria chave privada para assinar (atribuir autenticidade ao “comunicado”).

Ou seja, a chave pública do des-tinatário ugandense é utilizada para impedir terceiros de acessar as infor-mações do arquivo em questão, e a chave privada do remetente brasileiro é utilizada para garantir a procedên-cia 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 digi-tal e determinar se as informa-ções realmente foram originadas por ele.

Ou seja, uma chave (a privada) do destinatário ugandense, é uti-lizada 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

Tabela 1: Função não injetora

x f(x)

2 4

-2 4

73



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 é li-teralmente pública.

O GnuPG, software livre para criptografia, trabalha a assinatura di-gital com uma função de hash, que

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 con-teúdo original. O destinatário não precisará utilizar um programa es-pecífico para acessar as informações recebidas. O GnuPG será utilizado, nesse caso, apenas para verificar a origem do conteúdo recebido, agin-do da seguinte forma: o programa lê o conteúdo origi-

nal e, com a mesma função de hash utilizada pelo remetente, gera um hash do conteúdo rece-bido e armazena aquele valor;

em seguida, ele decripta a assi-natura utilizando a chave públi-ca 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 desti-natário desprovido de programas de criptografia, este conseguirá acessar (ler) a mensagem, mas não será ca-paz de verificar sua autenticidade.

Relembrando: dado um par de chaves, sendo uma delas para assinar o documento, a outra é usada para verificar sua legitimidade.

DSAO 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 ofereci-dos na Internet. Indubitavelmente, um dos mais notórios servidores de

Figura 4 A�criptografia�é�capaz�de�garantir�a�privacidade�e�a�autenticidade�de�um�conteúdo.

Remetente(Brasil)

Chave privada

Arquivooriginal

Assinaturadigital Verificação

Arquivo digitalmente

assinado

Arquivo digitalmente

verificado

Chave pública

Destinatário(Uganda)



chaves para o padrão PGP é o do Massachusetts Institute of Techno-logy, 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 ser-vidores, disponibilizada pelo Open Directory Project, um respeitado diretório de referências da Netsca-pe, em [2].

O padrão OpenPGPNo ano de 1991, muitos países – inclusive os EUA – empregavam legislações pavorosamente intru-sivas, restringindo o uso de cripto-grafia como artifício fortalecedor de privacidade em transações digitais. Foi nesse contexto que um progra-mador e ativista político chamado Phil Zimmermann apresentou ao mundo o programa PGP (Pretty Good Privacy), possuidor de uma robustez criptográfica que exce-dia 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 vigen-tes naquele momento não conse-guiam acompanhar os avanços das tecnologias ligadas aos sistemas de informação. Tamanha era a confu-são causada no âmbito legislativo

que, nos Estados Unidos, embora proibissem a disseminação daque-las 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 inclu-sive fora do meio técnico.

Finalmente em 1996, as inves-tigações sobre Phil Zimmermann cessaram e ele então fundou a em-presa 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, base-ando-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 digitalCertificados digitais podem ser en-tendidos 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 certi-ficado 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 contex-to, pode designar um documento. Já o termo “certificação” diz res-peito à emissão de um certificado. Remete ao ato de criação de um certificado digital.

O certificado digital, especifica-mente, é, como se afirmou previa-mente, 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 di-gital é um arquivo de computador com suas peculiaridades bem defi-nidas 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 do-cumento de identificação para uso na Internet, tal qual o RG e o CPF em atividades cotidianas mais con-vencionais.

Tipicamente, um certificado di-gital possui:

uma chave pública; o nome da entidade que ele re-

presenta; 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”.

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

75



Somente autoridades credencia-das podem emitir tais documentos providos de valor jurídico. Isso en-volve uma entidade confiável, que é um órgão certificador chamado de “autoridade certificadora” ou “AC” (“CA”, em inglês), que atesta o ca-ráter genuíno de chaves públicas.

O par chave privada e certificado digital emitido por uma dessas au-toridades serve, por exemplo, para conferir valor legal a logs de siste-mas e redes, tornando tais registros aceitáveis em tribunais.

Suponha que um funcionário mal intencionado de uma empre-sa 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 re-gistros do domínio.

Caso a empresa não possua uma ICP (infraestrutura de chaves pú-blicas), poderá tão somente puni-lo 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 pos-suiriam valor legal.

O processo de registro de uma chave pública pode ser compara-do à 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 identi-dade. 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 certi-ficado útil a bancos, pois apresenta proteção adicional.

A CSR (certificate signing request, ou requisição de assinatura de cer-tificado), é um arquivo de compu-tador que contém uma mensagem, que é enviada a uma autoridade certificadora para solicitar um cer-tificado digital.

A tabela 3 dá alguns exemplos de situações em que certificados digi-tais são úteis.

ARs e ACsOrganizações supostamente con-fiá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 In-termediárias, cuja emissão de certificados é repassada às Au-toridades 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



Gostou do artigo?Queremos�ouvir�sua�opinião.�Fale�conosco�em��[email protected]

Este�artigo�no�nosso�site:�http://lnm.com.br/article/3292

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.�([email protected])�e�Tiago Tognozi ([email protected])�são�especialistas�em�segurança�na�BDS�Labs�(www.bdslabs.com.br).

Nota de licenciamentoCopyright�©�2010�Marcio�Barbado�Jr.�e�Tiago�Tognozi

É�garantida�a�permissão�para�copiar,�distribuir�e�modificar�este�documento�sob�os�termos�da�Li-cenç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

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 in-formações sobre quem ou o que irá utilizar aquele certificado e, além dis-so, essa organização fica incumbida de controlar os referidos documentos e revogá-los se necessário. Isso ocor-re por meio da manutenção de uma lista chamada CRL (Certificate Re‑vocation List, ou lista de revogação de certificados).

CRLA Certificate Revocation List é uma lista de revogação de certificados que contém certificados digitais que perderam a validade por alguma ra-zão. Exemplos que tornam nulo um certificado digital: atinge-se a data de expiração do

certificado, “características” contidas no cer-

tificado deixam de ser válidas, ou

a chave privada referente ao certificado é comprometida.

ICP-BrasilA 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 Tec-nologia 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 ago-ra “cloud computing”, cria algumas aberrações criptográficas do ponto de vista conceitual. Uma delas diz respeito aos serviços de email base-ados na Web, o webmail.

Algumas empresas oferecem o serviço de webmail, incluindo re-cursos de criptografia assimétrica no padrão PGP para a troca de men-sagens. ocorre que essa situação contraria o conceito de privacidade inerente às chaves privadas. Tratam-se 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 armaze-nados 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 recebi-das 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 clien-tes em questão. n

Complete a sua coleção

Mais informações

Site:

www.linuxmagazine.com.br

Tel: 11 4082-1300

pocket_atualizado.indd 61 26/01/10 18:01

Criptografia Teoria e Prática - Parte 2

Documents

Transcript of Criptografia Teoria e Prática - Parte 2