RED29004-2014-1-Seminario2-Heartbleed
Sobre a página
Pagina desenvolvida para o seminário da disciplina de Redes de Computadores I.
- Professor/Orientador: Arliones
- Alunos: Mathias Silva da Rosa, André Felippe Weber e Guilherme Evangelista de Albuquerque
Introdução
A Internet busca tornar-se um meio ao acesso de informações privilegiadas e possibilitar a operação remota de serviços que exigem uma certa segurança. A internet baseia-se numa pilha de protocolos ( HTTP / TCP / IP ) onde, em nenhum momento, há uma preocupação com autenticidade ou privacidade dos dados. Assim, muitas soluções foram e estão sendo apresentadas como, uma delas, o SSL (Secure Sockets Layer), que é um protocolo de criptografia. Porém há pouco tempo houve uma falha na biblioteca OpenSSL que permitiu o acesso a dados protegidos em sistemas finais que possuíam esse sistema, esta falha denomina-se Heartbleed.
Apresentação utilizada no seminário
Segurança
O conceito de segurança no contexto da internet significa privacidade, integridade, autenticidade de entidades e não repudiação.
Privacidade
É a garantia de que a mensagem deve ser entendida somente pelo emissor e receptor, para os demais a mensagem deve ser vista como lixo, ou seja, incompreensível. Quando um cliente se comunica com o seu banco, espera que a comunicação seja totalmente confidencial. A privacidade é feita pela criptografia dos dados.
Integridade
É a garantia de que os dados não serão modificados, acidentalmente ou intencionalmente, no percurso emissor-receptor.
Autenticidade de entidades
O emissor e o receptor precisam confirmar a identidade da outra parte envolvida em comunicação, ou seja, confirmar que a outra parte é quem alegar ser. A autenticidade é feita por alguma informação compartilhada entre as entidades. O usuário ao receber um e-mail necessita saber se quem enviou tal e-mail é seu amigo.
Não repudiação
"O Não-Repúdio deve ser visto sob a ótica legal e técnica. Sob uma perspectiva legal, o Não-Repúdio é definido pela American Bar Association PKI Assessment Guidelines como sendo "... suficiente evidência para persuadir a autoridade legal (juiz, jurado ou árbitro) a respeito de sua origem, submissão, entrega e integridade, apesar da tentativa de negação pelo suposto responsável pelo envio".
Em termos gerais, repudiar algo é negar sua existência e, para tanto, os serviços de Não-Repúdio usam os métodos de criptografia que impedem que um indivíduo ou uma entidade neguem a execução de uma ação particular relacionada aos dados (tais como mecanismos para a não-rejeição de autoridade, fornecendo prova da origem; para a prova da obrigação, da intenção, ou do compromisso; ou para a prova da posse)."PNDE
A segurança das transações é dependente das chaves de criptografia. Se uma dessas chaves cair em mãos erradas, pode ser facilmente duplicada e usada para comprometer a segurança. Um sistema totalmente seguro deve ser capaz de detectar impostores ou, ainda melhor, se prevenir contra a duplicação das chaves. Isto é executado por um hardware baseado em ficha única. O SSL não suporta sozinho esta implementação, mas a realiza em conjunto com Fortezza.
- Fortezza: é um sistema de criptografia usado pelas agências do governo americano para manejar informações sensíveis porém não confidenciais. Ele provê uma implementação de hardware de duas criptografias desenvolvidos pelo governo: Fortezza KEA e SKIPJACK. A criptografia Fortezza para SSL usa o KEA ao invés do RSA Key Exchange, e o DSA (Digital Signature Algorithm) para autentificação do cliente.
Criptografia
A criptografia é uma técnica que permite que um remetente disfarce os dados de modo que um intruso não consiga obter nenhuma informação dos dados interceptados. O destinatário deve estar habilitado a recuperar os dados originais. Um algoritmo de criptografia utiliza um sistema de chaves, uma chave é uma cadeia de números ou caracteres que serve como entrada para o algoritmo de criptografia. O algoritmo pega a chave e os dados a serem protegidos e produz um texto cifrado como saída. O destinatário possui outra chave para a decriptação que o algoritmo usa para obter os dados originais. Existem dois sistemas de chaves, sistema de chaves simétricas e sistemas de chaves públicas.
Criptografia de chaves simétricas
A criptografia de chaves simétricas é uma das formas mais simples de criptografia. A mensagem que será criptografada é enviada a um algoritmo, que a partir da combinação da mensagem original e de uma chave secreta, gera uma nova mensagem, que é a mensagem codificada. Esta mensagem codificada pode então ser enviada ou armazenada, e somente quem possuir a mesma chave secreta utilizada no algoritmo, conseguirá decodificar a mensagem codificada e obter o seu conteúdo.
Uma das técnicas de criptografia simétrica é a cifras de bloco. As técnicas de cifras de bloco são utilizadas em muitos protocolos seguros da Internet, incluindo PGP (para e-mail seguro), SSL (para conexões TCP seguras) e Ipsec (é uma extensão do protoloco IP que visa ser o método padrão para fornecimento de privacidade do usuário). Na cifra de bloco, a mensagem a ser criptografada é processada em blocos de k bits. Por exemplo, se k = 64, então a mensagem é dividida em blocos de 64 bits, e cada bloco é criptografado de maneira independente. Para criptografar um bloco, a cifra utiliza um algoritmo para mapear o bloco de k bits de texto aberto para um bloco de k bits de texto cifrado. Existem diversos algoritmos de cifras de bloco conhecidos, incluindo DES (abreviação de Data Encryption Standard [Padrão de Criptografia de Dados]), que utiliza um bloco de 64 bits e também usa uma chave para criptografar, de modo que a descriptografia somente é possível, teoricamente, por aqueles que conhecem a chave particular utilizada para criptografar. A 3DES funciona de forma similar, porém com 3 blocos de 64 bits, de forma que os dados são encriptados com a primeira chave, decriptados com a segunda chave e finalmente encriptados novamente com uma terceira chave. Isto faz o 3DES ser mais lento que o DES original, porém em contrapartida oferece maior segurança. E o AES (abreviação de Advanced Encryption Standard [Padrão de Criptografia de Dados]) utiliza um bloco de 128 bits e substitui o DES, mas ainda funcionando de forma similar, encriptando todos os blocos com as mesmas chaves, porém agora estas chaves têm 128, 192 ou 256 bits.
Criptografia de chaves assimétricas
Na criptografia de chaves assimétricas cada parte envolvida na comunicação usa duas chaves diferentes, uma privada e outra pública. A chave pública pode ficar disponível para qualquer pessoa que queira se comunicar com outra de modo seguro, mas a chave privada deverá ficar em poder apenas de cada titular. É com a chave privada que o destinatário poderá decodificar uma mensagem que foi criptografada para ele com sua respectiva chave pública. A principal vantagem deste método é a sua segurança, pois não é preciso compartilhar a chave privada. Em uma analogia, vamos supor que Ana quer enviar dados a Beto, antes disso Ana sabe que Beto distribuiu sua chave pública na rede e pega essa chave para codificar o dado que ela quer enviar, pórem depois que Ana códifica o dado ela não pode mais decodificar, pois isso é somento feito ela chave privadada de Beto, quando Beto recebe os dados pela rede, decodifica com a chave privada e extrai os dados.
O algoritmo de criptografia RSA é o principal algoritmo assimétrico. A criptografia RSA atua diretamente na internet, por exemplo, em mensagens de emails, em compras on-line e o que pode-se imaginar; tudo isso é codificado e recodificado pela criptografia RSA. Esse algoritmo fundamenta-se na teoria clássica dos números.
ICP - Infraestrutura de Chave Pública
Uma ICP é toda uma estrutura desenvolvida com o intuito de autenticar e identificar usuários e serviços, garantir que as informações trocadas não sejam reveladas a entidades que não devam ter conhecimento destas, e que se uma determinada entidade realizar uma ação, esta não terá como negar que realizou tal ação. O funcionamento das ICPs está intimamente relacionado com a distribuição e a verificação da autenticidade de chaves públicas. Para cada usuário ou serviço que deseje participar da infraestrutura, é gerada uma chave privada que fica de posse deste usuário ou serviço, e um certificado, que contém informações importantes a respeito deste usuário e de quem delegou este certificado, além é claro, da chave pública do usuário. Desta forma, quando alguém desejar se comunicar de forma segura com um usuário fictício Bob, ela pode obter o certificado de Bob que contém sua chave pública, verificar a autenticidade desta chave pública através da consulta a uma autoridade certificadora e a utilizar para codificar uma mensagem que somente Bob será capaz de decodificar. Dentre as tecnologias conhecidas que utilizam ICP, podemos citar o Secure Sockets Layer (SSL), o Secure / Multipurpose Internet Mail Extensions (S/MIME) e o Pretty Good Privacy (PGP). A certificação digital é a principal função de uma ICP. Os certificados possuem uma forma segura de se divulgar as chaves públicas, de forma que a validade destas pode ser verificadas. Um certificado contém as informações essenciais para associar uma entidade a qual pertence o certificado a uma chave pública. As informações mais comumente presentes, podemos citar a identificação do dono do certificado, a sua chave pública, as informações referentes a autoridade que assinou o certificado e a sua validade. Utilizando-se de certificação digital, é possível, por exemplo, evitar que hackers interceptem ou adulterem as mensagens trocadas na internet. Também possível, com certeza, quem foi o autor de uma transação ou de uma mensagem, ou ainda, manter dados confidenciais protegidos contra leitura de usuários não autorizados.
Composição de uma ICP
- Autoridade Certificadora (AC):é a entidade mais importante de uma estrutura de uma ICP. É responsavél por gerar e assinar os certificados para os usuários e serviços que desejam utiliza a infraestrutura de chaves públicas. E revogar certificados caso seus donos infrinjam as políticas estabelecidas pela autoridade. Ela é uma entidade confiável, que se responsabiliza pela autenticação, ou seja, de que os usuários e serviços a ela vinculados são realmente o que eles dizem ser
- Autoriade de Registro (AR): é uma entidade opcional. Ela pode atuar como um intermediário entre os assinantes de um serviço de certificação e a autoridade certificadora. Com isso, a autoridade de registro recebe os pedidos de certificados e informações à respeito do usuário e as repassa para autoridade certificadora. Em algumas situações, a autoridade certificadora pode delegar a responsabilidade de alguns tipos de certificados para autoridade de registro, de modo que os certificados assinado por ela possuem a mesma validade do que se fossem assinados pela autoridade certificadora.
- Assinante: é a entidade que deseja receber o certificado da autoridade certificadora.
- Usuário do serviço protegido por certificados (Relying Party): O Relying Party é o usuário que recebeu uma informação assinada digitalmente, ou que deseja utilizar um serviço protegido por um certificado. Este usuário precisa verificar a autenticidade desta informação assinada digitalmente e a autenticidade do serviço protegido por um certificado.
- Repositório de Certificados: está é uma solução eficiente para um ambiente fechado (uma intranet) ou para ambientes isolados de processamento aonde a chave pública é distribuída localmente. A distribuição dos certificados pode ser efetuada através da publicação dos mesmos em um diretório controlado pela AC ou AR. O diretório deve ser lido por todos, mas somente o AC pode escrever nele.
- Ancora de Confiança (Trust Anchor): Uma âncora de confiança é uma chave pública que um usuário de um serviço protegido por certificados confia para assinar certificados. Em uma cadeia de certificados, o primeiro certificado, que começa a cadeia de certificação, precisa ter sido assinado com esta âncora de confiança.
- Certificados de chave pública: São os certificados em si. Existem diversos padrões como o X.509.
Certificação
Um certificado contém as informações essenciais para associar uma entidade a qual pertence o certificado a uma chave pública. Dente as informações mais comumente presentes, podemos citar a identificação do dono do certificado, a sua chave pública, as informações referentes à Autoridade Certificadora que assinou o certificado, e a sua validade.
- Certificação Cruzada:
Supondo de que nem todas as entidades vão confiar na mesma AC para proteger os seus certificados, foi elaborado um método para criar certificados entre duas ACs. Este método, chamado de Certificação Cruzada, permite que duas autoridades que confiem uma na outra emitam um par de certificados cruzados. Desta forma, a AC 1 valida AC2 e AC2 valida AC1. Em casos onde uma AC confia em outra, mas a recíproca não é válida, ocorrerá à criação da certificação em apenas um sentido.
- Caminhos de Certificação:
Em um universo composto de um grande número de ACs, onde nem todas estão conectadas através de um método de certificação cruzada, um número arbitrário de ACs precisa validar umas as outras, até que um certificado seja de fato obtido.
No exemplo da imagem, a entidade A precisa da chave pública da entidade B. Como A não confia diretamente na AC3, ele precisa se comunicar com uma entidade AC1 de sua confiança, que por sua vez confia em AC2, que confia em AC3. Esta última conhece a chave pública de B, que é então enviada para a entidade A.
Relação entre Autoridades de uma ICP
Para ampliar o uso de uma dada ICP, as suas funções devem atender a um grande número de usuários mantendo um número aceitável de caminhos de certificação. As três estruturas de relacionamentos entre ACs são:
- Hierarquia Generalizada:
Na hierarquia Generalizada, cada AC certifica a sua entidade “pai” (Autoridade de maior importância que certifica a entidade em questão), e certifica suas entidades filhas). No exemplo da imagem logo abaixo, se a entidade B precisa certificar uma mensagem da entidade D, ela precisa seguir o caminho de certificação composto por AC5, AC2, AC1, AC3, AC6, estas duas autoridades podem criar um par de certificados cruzados entre si para reduzir o caminho para AC5, AC6.
- Hierarquia Top-Down:
A hierarquia Top-Down é a hierarquia mais utilizada em pequenas ICPs. Nesta hierarquia, existe uma entidade de nível superior, chamado de AC raiz. Além disso, cada AC certifica somente suas ACs filhas. No exemplo da figura, de a entidade B precisa certificar uma mensagem da entidade D, ela precisa seguir o caminho de certificação AC1, AC3, AC6. O ponto principal neste tipo de hierarquia é que todos os usuários precisam confiar totalmente na AC raiz.
- Teia de Confiança:
Algumas ICPs não seguem nenhuma das estruturas já citadas. Elas dependem exclusivamente dos certificados cruzados entre as Autoridades. Cada AC baseia sua confiança nos certificados de outras ACs. Os usuários desta PKI trocam chaves e assinam os certificados digitais uns dos outros para estabelecer um relacionamento de confiança.
Ao se utilizar o esquema de certificação digital com assinatura, pode parecer que todos os problemas de segurança estão resolvidos. No caso das ICPs, existem diversos elos, ou etapas, que não são baseados em métodos criptográficos. Além disso, encontramos na ponta da estrutura de ICP o elo mais fraco de todos no que tange a segurança: as pessoas que utilizam o serviço.
É possível perceber que um dos maiores problemas de uma PKI é: Como proteger a sua chave privada? Podemos afirmar com certeza que a maioria dos usuários não possui um sistema computacionalmente seguro, com restrições de acesso, robustez a ataques, dentre outras proteções. De fato, é praticamente impossível adquirir tais proteções em um computador convencional. Outro ponto importante a ser discutido é a questão do não repudio. Partindo do pressuposto que os algoritmos de assinatura digital e a criptografia empreendida no par de chaves são computacionalmente invioláveis para os padrões atuais, não podemos assumir que todo conteúdo assinado por uma chave privada é de completa responsabilidade do dono da chave. Justamente pela dificuldade de se manter a segurança nos elos mais fracos da cadeia de segurança, o fato de uma pessoa não ter controle completo e irrestrito sobre sua chave privada não pode responsabilizar esta pessoa por qualquer crime cometido e ratificado com esta mesma chave privada. Mesmo que os sistemas da ICP ofereçam uma grande ferramenta de segurança, ainda podemos esbarrar em problemas que podem colocar toda esta segurança por água abaixo.
SSL
Para contornar os problemas de segurança encontrados na rede, e garantir a comunicação entre duas pessoas para por exemplo o uso para fins comerciais da internet é utilizado principalmente o SSL(Secure Socket Layer) que é um protocolo de criptografia de dados, desenvolvido originalmente pela Netscape Communications Corporation, e que aprimora o protocolo de Transporte TCP.
- Uma conexão utilizando SSL é sempre iniciada pelo cliente. Quando um usuário solicita a conexão com um site seguro, facilmente identificável pelo “https://” no início da URL, o navegador web (Firefox, Internet Explorer, Opera, Chrome, etc.) solicita o envio do Certificado Digital e verifica se o certificado enviado é confiável, válido e se está relacionado com o site que o enviou.
O SSL implementa uma camada intermediaria entre a camada de transporte e a de aplicação (Figura 1). E é nessa camada -SSL- que estão implementadas os critérios de segurança (privacidade, integridade, autenticidade de entidades e não repudiação) já especificados.
O SSL suporta uma variedade de diferentes algoritmos criptográficos, ou Ciphers, como por exemplo DES e 3DES, para uso em operações de autentificação do servidor e do cliente, transmissão de certificados, e estabelecimento de sessões. Clientes e servidores podem suportar um Cipher diferente, ou um conjunto de Ciphers, dependendo de fatores como qual versão de SSL eles (cliente e servidor) suportam, políticas da companhia a respeito da força aceitável de criptografia, e restrições governamentais para exportação do software SSL.
Funcionamento do SSL
O protocolo SSL, é o responsável por encriptar e identificar os usuários de uma conexão. Para garantir que os dados do usuário chegue ao destino sem nenhum tipo de intromissão por terceiros, ocorre a encriptação, que será detalhado em 5 passos:
1.Computadores (cliente e servidor) concordam em como encriptar:
- Na primeira parte do SSL handshake, o cliente entra em contato com um servidor enviando uma mensagem de “olá” que contém mais detalhes sobre os algoritimos de troca de chaves[Obs 1] (e.g KEA e RSA Key Exchange), sobre algoritmos criptográficos, e as Hash’s (utilizada para gerar uma mensagem de autentificação) dísponiveis por ele para ser utilizado numa conexão SSL. E ainda, nesta mensagem “olá”, o cliente envia a versão do SSL deles, e um número randômico (utilizado para o cálculo da chave de encriptamento).
- O servidor, então, responde dizendo: “Eu escolho esta chave, esse algoritmo criptográfico, e esse método Hash”. Com isso, eles concordaram a forma de encriptação e estão prontos para o próximo passo.
[Obs 1] Algoritmos de troca de chaves como KEA e RSA Key Exchange governam a maneira pela qual clientes e servidores determinam as chaves simétricas que usarão durante uma sessão com SSL. O mais comumente usado é o RSA Key Exchange.
2.Servidor envia um certificado: Este certificado contém informações como:
- Para quem este servidor pertence;
- A validade deste certificado;
- Um número Serial;
- E o mais importante, informações sobre a chave publica.
3.Cliente diz: “Comece a encriptar”: Este passo se baseia em 3 mensagens:
- Troca de chave: Quando esta mensagem é enviada, o cliente e o servidor calculam um código secreto que será utilizado daqui por diante na encriptação das mensagens.
- Troca para o algoritmo criptográfico especificado: Que é o algoritmo acordado entre os dois no passo 1. E também é quando o cliente pede que o servidor comece a encriptar as mensagens.
- Fim: “Vamos começar agora”
4.Server diz: “Ok, vamos encriptar”: Ele então envia duas mensagens:
- Troca para o algoritmo criptográfico especificado: Que é uma resposta a mensagem enviada pelo cliente no passo 3. Onde ele concorda que só enviará mensagens encriptadas utilizando o algoritmo acordado entre os dois no passo 1
- Fim: O servidor envia uma mensagem “Vamos começar!”, ja encriptada, para o cliente.
5.Todas as mensagens serão encriptadas:
- Deste passo em diante todas as mensagens serão encriptadas. Qualquer tentativa de intromissão nesta comunicação só resultará em lixo.
O SSL existe para além de encriptar as mensagens também identificar os indivíduos envolvidos, afim de garantir que o computador o qual você está conectado é aquele que você confia. Pois você pode ter um certificado SSL, mas isso não significa que o computador que você está conectado é quem você acha que é, isso apenas significa que a conexão (troca de mensagens) é segura.
Usualmente, quando um usuário vai enviar informações utilizando SSL, é possível obter informações sobre o destino das informações que ele esta enviando dando um clique duplo sobre o cadeado que aparece na barra de endereço do navegador. Porém, por trás disso há toda uma infraestrutura.
Infraestrutura do SSL
1.Companhia pede um certificado a uma CA[Obs 2]:
- Para garantir sua confiabilidade à seus clientes a companhia precisa pedir um certificado para uma CA. E para isso a companhia deve informar a esse CA sobre o seu servidor, o que é a companhia, e localização dela. Para que a CA verifiquei a autenticidade destas informações.
[Obs 2]: Certification Authority: Empresa que vende certificados digitais.
2.CA cria um certificado e assina isso:
- Um certificado contém informações de versão, validade, Serial number, ID, identificação do CA, detalhes da companhia, informações da chave publica (Algoritimo e chave), dentre outras informações que são todas condensadas em um número utilizando uma função Hash, e então este número é encriptados utilizando uma chave privada.
3.Instalar certificado no servidor:
- Após o passo 2 ser concluído, o CA devolve este certificado para a companhia que deverá instalar e configurar o seu servidor para utilizar o certificado.
4.Browser checa CA:
- Quando o cliente tenta obter informação de um site a apartir do SSL, o browser procura na seu banco de dados informações do CA para garantir a autenticidade na conexão.
5.Browser confirma autenticidade dos certificados assinados:
- Com as informações do CA obtidas no passo 4 há a chave publica deste CA. Então quando o cliente recebe um certificado de algum site ele pode verificar que a assinatura é autentica.
OpenSSL e HeartBleed
Como o SSL é um sistema padronizado e possui direitos autorais, sendo assim foi criado o OpenSSL que é uma plataforma de código aberto mantida por uma comunidade de desenvolvedores espalhados pela internet, que implementa o protocolo SSL e vários algoritmos e primitivas criptográficas de uso comum, incluindo algoritmos de troca de chaves, funções de hash, algoritmos simétricos e assimétricos. O OpenSSL sendo um “Open source” não requisita o pagamento de direitos autorais. O OpenSSL se apresenta na forma de duas bibliotecas e um conjunto de programas que implementam as rotinas por elas disponibilizadas. Uma vulnerabilidade encontrada em umas dessas bibliotecas nas versões 1.0.1 à 1.0.1f do OpenSSL permitiu que qualquer pessoa na internet fosse capaz de ler uma parte da memória ram dos sistemas protegidos pelo OpenSSL. A versão 1.0.1 foi lançada em 14 de Março de 2012, sendo assim, essa vulnerabilidade foi mantida até 7 de Abril de 2014 com o lançamento da versão 1.0.1g para a correção do bug. A estimativa é que a falha tenha atingido cerca de 17.5% dos sites da internet, cerca de 500 milhões, mas o número pode ser bem maior, pois a falha também afeta outros serviços que podem utilizar a mesma biblioteca, como SMTP, VPN, IMAP e MySQl. Esse bug foi encontrado em uma função denominada heartbeat (significa batimentos cardíacos) que é uma requisição enviada ao servidor com o intuito de identificar se o mesmo ainda está em operação, para não haver necessidade de renegociação de chaves. Ao enviar essa requisição a função especifica o pacote e o seu tamanho na mensagem enviada, quando o servidor recebe essa mensagem, somente transmite em eco da mesma.
A vulnerabilidade está na informação do tamanho do pacote, que pode ser modificado causando um comportamento inadequado do servidor. Sendo assim, é possível enviar um pacote que possui 5 bytes sendo que na informação do tamanho pode ser de até 64 Kbytes que é o tamanho da variável do tipo “short” solicitada pela função heartbeat. Porém não há uma limitação do ataque de 64 Kbytes, pois o invasor poderá fazer diversas conexões durante uma sessão TLS ativa e continuar extraindo partes de 64 Kbytes até que o conteúdo desejável seja todo revelado. Quando o servidor recebe, retorna um eco com os dados dentro do pacote e o resto com outros dados que estão armazenados na memória do servidor, entre estes dados podem estar informações privadas como chaves compartilhadas, senhas, login’s entre outros.
Enquanto as versões que apresentam a falha estiverem em uso, as aplicações poderão ser atacadas. Fabricantes de sistema operacional, distribuidores, vendedores de solução, desenvolvedores independentes, para corrigir esse bug, devem adotar a nova versão corrigida e notificar seus usuários. Caso isso não seja possível, desenvolvedores pode recompilar o OpenSSL sem o parâmetro do heartbeat utilizando a opção “DOPENSSL_NO_HEARTBEATS” no momento da compilação.
Testar vulnerabilidade ao Heartbleed
Refêrencias
| Chave simétrica e publica | ||
|---|---|---|
|
| ICP - Infraestrutura de chave pública |
|---|
|
| OpenSSL e HearthBleed |
|---|