Criptografia

Por que nós embutimos criptografia?

Em três palavras: porque nós podemos.

O projeto OpenBSD é concentrado no Canadá.

A Lista de Controle de Exportações do Canadá não impõe nenhuma restrição significante quanto à exportação de software criptográfico, e é ainda mais explícita quanto à livre exportação de softwares criptográficos. Marc Plumb realizou algumas pesquisas quanto às leis criptográficas.

Por esse fato, o projeto OpenBSD embutiu criptografia em numerosos lugares do sistema operacional. Temos a necessidade de que os softwares criptográficos que utilizamos estejam disponíveis livremente e com uma boa licença. Nós não utilizamos criptografia com patentes indecentes. Nós também exigimos que tal software seja proveniente de países que possuam leis de exportação compatíveis, pois não queremos infringir lei alguma. Os componentes criptográficos que utilizamos atualmente foram escritos na Argentina, Austrália, Canadá, Alemanha, Grécia, Noruega e Suécia.

Quando criamos versões ou "snapshots" do OpenBSD, nós compilamos nossos arquivos em países livres para nos assegurarmos de que o código fonte e os binários que disponibilizamos estão livres de qualquer corrupção. No passado, nossas compilações eram realizadas no Canadá, Suécia e Alemanha.

O OpenBSD é fornecido com suporte a Kerberos V. A base de código que utilizamos é a base exportável Heimdal da Suécia. Nosso código fonte do X11 foi estendido para utilizar o Kerberos.

O OpenBSD foi o primeiro sistema operacional a incorporar a pilha IPsec. Temos incluído o IPsec desde a versão 2.1 do OpenBSD, lançado em 1997. Nossa pilha IPsec, totalmente integrada ao kernel, com aceleração por hardware em uma grande quantidade de placas, e nosso próprio daemon ISAKMP livre. Ele é utilizado como uma das máquinas do teste de conformidade IPsec, organizado pelo VPNC.

Hoje a criptografia é um importante meio de se melhorar a segurança de um sistema operacional. A criptografia usada no OpenBSD pode ser classificada em vários aspectos, descritos abaixo:

OpenSSH

Depois da versão 2.6, o OpenBSD contém o OpenSSH, uma versão do ssh absolutamente livre de patentes. O OpenSSH interopera com a versão 1 do protocolo, e possui várias características adicionais:

• todos os componentes de natureza restritiva (ou seja, patentes; veja ssl(8)) foram removidos do código fonte; qualquer componente licenciado ou patenteado utilizava bibliotecas externas.
• foi atualizado para suportar o protocolo ssh 1.5.
• contém a adição do suporte para autenticação Kerberos e passagem de tíquete.
• suporte à autenticação com senha de uso único com skey(1).

A grosso modo, nós pegamos uma versão livre do ssh e convertemos para o estilo OpenBSD. Cerca de um ano depois, estendemos o OpenSSH para suportar o protocolo 2. O resultado foi o suporte aos 3 maiores protocolos SSH: 1.3, 1.5 e 2.0.

Gerador de números pseudo-aleatórios

Um gerador de números pseudo-aleatórios (PRNG - "Pseudo Random Number Generator") disponibiliza aos aplicativos uma sequência de números aleatórios que possuem certa importância para a segurança do sistema:

• Deve ser impossível adivinhar a saída do gerador de números aleatórios, mesmo tendo conhecimento de sua saída anterior.
• Os números gerados não devem possuir padrões repetitivos, o que significa que o PRNG deve ter um ciclo muito longo.

O PRNG é normalmente um algoritmo onde os mesmos valores iniciais irão produzir a mesma sequência de saída. Em um sistema operacional multiusuário existem muitas fontes que permitem alimentar o PRNG com dados aleatórios. O kernel do OpenBSD utiliza as informações de temporização de interrupção do mouse, a latência de dados de interrupção da rede, temporização do pressionamento de teclas e informações de E/S de disco para preencher a lista de entropia. Números aleatórios estão disponíveis para as rotinas do kernel e são exportados através de dispositivos para programas no espaço do usuário. Os números aleatórios são utilizados nos seguintes lugares:

• Alocação dinâmica sin_port no bind(2).
• PIDs de processos.
• IDs de datagramas IP.
• IDs de transação RPC (XID).
• IDs de transação NFS RPC (XID).
• IDs de requisições DNS.
• Números de geração de nó-i, veja getfh(2) e fsirand(8).
• Perturbação temporal no traceroute(8).
• Melhores nomes temporários para mktemp(3) e mkstem(3)
• Randomização adicionada ao valor ISS do TCP para proteção contra ataques de "spoof".
• Preenchimento aleatório nos pacotes IPsec esp_old.
• Gerar "salts" para vários algoritmos de senha.
• Gerar falsos "challenges" S/Key.
• Verificação automática de trocas de chaves no isakmpd(8).

Funções de hash criptográficas

Uma função de hash comprime os dados recebidos em uma string de tamanho constante. Em uma função de hash criptográfica é impossível encontrar:

• duas entradas que possuam a mesma saída (imune à colisões),
• uma entrada diferente para uma entrada já disponível com a mesma saída (resistência secundária de colisões).

No OpenBSD, MD5, SHA1 e RIPEMD-160 são utilizados como funções de hash criptográficas:

• No S/Key(1) para gerar senhas que podem ser utilizadas somente uma vez.
• No IPsec(4) e no isakmpd(8) para autenticar a origem de dados dos pacotes e para garantir sua integridade.
• Para senhas MD5 no estilo FreeBSD (não-ativado, por padrão), veja login.conf(5)
• Na libssl para assinatura digital de mensagens.

Transformadores criptográficos

Os transformadores criptográficos são utilizados para cifrar e decifrar dados. Eles normalmente são utilizados com chaves de cifragem e de decifragem. A segurança de um transformador deve se basear somente no material relacionado às chaves.

O OpenBSD possui mecanismos como DES, 3DES, Blowfish e Cast disponíveis para o kernel e programas no espaço do usuário, que são utilizados em diversos locais:

• Na libc para criar senhas no formato Blowfish. Veja também o documento da USENIX sobre este tópico.
• No IPsec(4) para fornecer confidencialidade para a camada de rede.
• No isakmpd(8) para proteger as transações onde as chaves IPsec são negociadas.
• Na libssl para permitir que os aplicativos se comuniquem através do protocolo SSL (que é um padrão de facto).

Suporte a hardware criptográfico

O OpenBSD, a partir da versão 2.7, começou a suportar alguns hardwares criptográficos como aceleradores e geradores de números aleatórios.

• Desenfileiramento criptográfico do IPsec
  Nossa pilha IPsec foi modificada para que funções criptográficas sejam feitas fora de linha. A maioria das pilhas IPsec precisam realizar a criptografia no processamento de cada pacote, resultando em um desempenho síncrono. Para utilizar o hardware de forma correta e acelerar a operação era preciso separar esses dois componentes, assim como fizémos. Por sinal, essa operação resultou em um ganho de desempenho até no caso do software.

• Hifn 7751
  Placas Hifn 7751 podem ser utilizadas como aceleradores criptográficos simétricos, ou seja, o Soekris VPN1201 ou VPN1211 (como comprar) ou PowerCrypt. O desempenho atual usando uma única placa Hifn 7751 em cada ponta do túnel é de 64Mbit/sec para 3DES/SHA1/ESP, aproximadamente 600% de aumento comparando-se a uma CPU P3/550. Desenvolvimentos à parte estão corrigindo alguns problemas, porém o código é considerado estável desde 13 de abril de 2000. Nós escrevemos nosso próprio driver em vez de usar o driver da PowerCrypt (escrito nos EUA), o que permite a integração perfeita com a nossa pilha IPsec. A 7751 é considerada lenta para os padrões da indústria de hoje, e muitos fornecedores já possuem chips mais rápidos (até a Hifn possui hoje um chip mais veloz, porém mais caro). O desempenho máximo utilizando-se 3DES SHA1 ESP é de aproximadamente 64Mbit/seg.

  Após o lançamento da versão 2.9, foi adicionado o suporte ao chip Hifn 7951, uma versão simplificada do 7751 que adiciona um acelerador de chaves públicas (não-suportado) e um gerador de números aleatórios (suportado). As placas foram doadas pela Soekris Engineering.

  Após o lançamento da versão 3.0, foi adicionado o suporte ao chip Hifh 7811, uma versão mais rápida do 7751 (em torno de 130Mbit/s) com um gerador de números aleatórios. A placa foi doada pela GTGI.

  Após o lançamento da versão 3.2, foi adicionado suporte ao algoritmo de compressão LZS, utilizado pelo ipcomp(4).

  Após o lançamento da versão 3.4, foi adicionado o suporte aos chips 7955 e 7956. Com as mesmas funcionalidades do chip anterior 7951, estes adicionam a funcionalidade AES.

  A Hifn foi no início uma empresa difícil de se lidar (eles tentaram nos convencer a mudar de ideia sobre o nosso algoritmo de destravamento criptográfico de engenharia reversa não-americano), porém recentemente eles têm sido muito prestativos, disponibilizando placas e suporte.

• Hifn 6500
  Este dispositivo é uma unidade de criptografia assimétrica. Ele possui suporte aos algoritmos RSA, DSA e DH, além de outras funções relacionadas à grandes números. Ele também contém um gerador de números aleatórios de alto desempenho. Possuímos um desses, documentação completa e código de exemplo. A partir da versão 3.1 do OpenBSD, tanto o gerador de números quanto a unidade de grandes números estão funcionando no sistema.

• Hifn 7814/7851/7854
  Esse dispositivo é uma unidade de criptografia assimétrica e um processador de pacotes. Ele possui suporte aos algoritmos RSA, DSA e DH, além de outras funções relacionadas à grandes números, e também possui um gerador de números aleatórios. Atualmente, somente o mecanismo de grandes números e o gerador de números aleatórios são suportados (sem transformadores de pacotes).

• Broadcom BCM5801/BCM5802/BCM5805/BCM5820/BCM5821/BCM5822/5823/5825/5860/5861/5862 (ou chip beta Bluesteelnet 5501/5601)
  Logo após o lançamento do OpenBSD 2.7, nós conseguimos adicionar suporte preliminar a essas placas disponibilizadas a nós diretamente pelo distribuidor, especificamente com o chip de teste 5501. Esses dispositivos fornecem o melhor desempenho em criptografia assimétrica que nós já vimos.

  A Bluesteelnet foi adquirida pela Broadcom e começou a fazer outras partes. O seu novo chip BCM5805 é similar ao Bluesteelnet, exceto pelo fato da placa também suportar um mecanismo assimétrico para DSA, RSA e outros algoritmos. Com um desempenho quase quatro vezes mais rápido que as Hifn, esperamos que esse chip se torne mais comum em breve.

  O pessoal da Broadcom/Bluesteelnet foram ótimas pessoas de se lidar. Eles nos forneceram a documentação completa, código de exemplo para seus chips e um número suficiente de placas para podermos testar.

  Após a versão 2.8, este driver foi modificado para gerar números aleatórios no BCM5805 e versões similares, e alimentar a fila de entropia do kernel com esses dados.

  Após a versão 2.9, foi adicionado suporte ao chip BCM5820, que é basicamente uma versão mais rápida (64 bits, velocidade de "clock" maior) do modelo BCM5805. Suporte não-testado ao modelo BCM5821 também foi adicionado após a versão 3.0.

  Na versão 3.1, o mecanismo de grandes números foi suportado, e as operações de RSA/DH/DSA puderam ser aceleradas.

  O suporte aos chips BCM5801, BCM5802, BCM5821 e BCM5822 foi adicionado na versão 3.2 (o suporte não-testado ao BCM5821 na versão 3.1 foi quebrado por causa de alguns requerimentos de controle de interrupção não-documentados).

  Suporte parcial ao BCM5823 foi adicionado na versão 3.4.

  O suporte ao BCM5825, BCM5860, BCM5861 e BCM5862, incluindo o suporte a AES no BCM5823 ou mais novo, foi adicionado depois da versão 4.5.

• Securealink PCC-ISES
  O PCC-ISES é um novo chipset da Holanda. Nós recebemos hardware de exemplo e documentação, e o driver já está sendo desenvolvido. No momento, o driver já é capaz de alimentar a fila de entropia do kernel com números aleatórios.

• SafeNet SafeXcel 1141/1741
  Depois do lançamento da versão 3.4, foi adicionado suporte para esses dois chips (encontrados em várias placas criptográficas SafeNet). Suportam DES, Triple-DES, AES, MD5 e criptografia simétrica SHA-1, RNG, operações de chave pública e processamento de pacotes IPsec completo.

• SafeNet SafeXcel 1840
  Nós recebemos documentação e hardware para o chip de criptografia SafeNet 1840. O trabalho para suportar pelo menos a criptografia simétrica desses dispositivos já foi iniciado.

• SafeNet SafeXcel 2141
  Nós recebemos documentação e hardware para o chip de criptografia SafeNet 2141. O trabalho para suportar pelo menos a criptografia assimétrica desses dispositivos já foi iniciado.

• 3com 3cr990
  A 3Com nos forneceu um driver para suportar o componente "ethernet" desse chipset, e baseado nisso nós escrevemos nosso próprio driver. Esse driver foi agora integrado, uma vez que conseguimos uma licença livre para o microcódigo. Pelo fato da pouca documentação e falta de cooperação (parcialmente por causa das reviravoltas da 3Com), as funções de IPsec do chip não são suportadas... por consequência, isso se tornou um exercício inútil.

• IPsec Intel
  Assim como a divisão de componentes de rede da Intel sempre faz, a documentação necessária nos foi recusada. Nós conversamos com cinco pessoas da Intel tecnicamente envolvidas com o desenvolvimento destes produtos. Todos eles gostariam que nós tivéssemos acesso à documentação, e nos apoiaram pelo que nós tínhamos feito. Porém suas mãos estavam atadas a uma administração que não percebia o benefício trazido a eles próprios ao se disponibilizar a documentação. Esqueça a Intel. (Se você quiser comprar hardware ethernet gigabit, nós recomendamos qualquer outra coisa... pela mesma razão: a maioria dos drivers da Intel que temos suporte foram escritos sem documentação).

• Intel 82802AB/82802AC Firmware Hub RNG
  O chip 82802 FWH (encontrado nas placas-mãe i810, i820, i840, i850 e i860) contém um gerador de números aleatórios (RNG). IPsec de alto desempenho requer uma entropia de números mais aleatória. A partir de 10 de Abril de 2000, nós passamos a suportar o RNG. Iremos adicionar suporte a outros RNGs encontrados em outros chipsets.

• VIA C3 RNG
  A nova CPU VIA C3 contém um gerador de números aleatórios. A partir da versão 3.3, esse item é utilizado pelo kernel para preencher a lista de entropia.

• Instruções AES do VIA C3
  CPUs VIA C3 com um núcleo Nehemiah step 8 ou posterior, contém uma implementação AES acessível através de instruções simples. Na versão 3.4, o kernel suportava isso para utilização em um contexto IPsec e exportação através de /dev/crypto. Na versão 3.5, o desempenho foi significantemente ampliado e o OpenSSL agora utiliza a nova instrução diretamente, quando disponível, sem a necessidade de entrada no kernel, resultando em um grande aumento de velocidade para aplicativos que utilizam OpenSSL para efetuar criptografia AES (AES-128 medido a 780Mbyte/seg).

• OpenSSL
  Há anos, tínhamos um grande esquema para suportar placas de criptografia que podiam fazer RSA/DH/DSA automaticamente através de chamadas do OpenSSL. Com o lançamento do OpenBSD 3.2, este suporte passou a funcionar e qualquer placa que é suportada com tal funcionalidade será automaticamente utilizada por softwares de criptografia, incluindo o OpenSSH e o httpd em modo SSL. Nenhuma alteração nos aplicativos é necessária.

Caso queira ajudar a escrever drivers, venha e nos ajude.

Procura-se criptógrafos internacionais

Nosso projeto precisa de pessoas para trabalhar nesses sistemas. Se algum criptógrafo não-Americano que preencha os pré-requisitos estabelecidos anteriormente está interessado em ajudar com a criptografia integrada do OpenBSD, por favor entre em contato conosco.

Leitura adicional

Alguns documentos sobre as alterações efetuadas no OpenBSD foram escritos pelos membros da equipe do OpenBSD. As versões postscript destes documentos estão disponíveis abaixo.

• A Future-Adaptable Password Scheme.
  Usenix 1999, por Niels Provos, David Mazieres.
  paper e slides.

• Cryptography in OpenBSD: An Overview.
  Usenix 1999, por Theo de Raadt, Niklas Hallqvist, Artur Grabowski, Angelos D. Keromytis, Niels Provos.
  paper e slides.

• Implementing Internet Key Exchange (IKE).
  Usenix 2000, por Niklas Hallqvist e Angelos D. Keromytis.
  paper e slides.

• Encrypting Virtual Memory.
  Usenix Security 2000, Niels Provos.
  paper e slides.

• The Design of the OpenBSD Cryptographic Framework.
  Usenix 2003, por Angelos D. Keromytis, Jason L. Wright e Theo de Raadt.
  paper.

• Cryptography As an Operating System Service: A Case Study.
  ACM Transactions on Computer Systems, Fevereiro de 2006, por Angelos D. Keromytis, Jason L. Wright e Theo de Raadt.
  paper.