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ção do Canadá não impõe nenhuma restrição significante quanto a exportação de software criptográfico, e é ainda mais explícita quanto a 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 sejam 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 os códigos fonte e 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 é lançado com suporte a Kerberos V. A base de códigos que utilizamos é 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 do OpenBSD 2.1 de 1997. Nossa pilha IPsec, totalmente integrada ao kernel, com aceleração por hardware suportando uma grande quantidade de placas, e nosso próprio daemon ISAKMP, é utilizada em uma das máquinas padronizadoras do projeto 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 baixo:

OpenSSH

Com o lançamento da versão 2.6, o OpenBSD incorporou em sua árvore de códigos fonte o OpenSSH, uma versão do ssh absolutamente livre de patentes. O OpenSSH, utilizando a versão 1 do protocolo, sofreu várias modificações e melhorias:

• todos os componentes de natureza restritiva (ex.: patentes, veja ssl(8)) foram removidos do código fonte; qualquer componente licenciado ou patenteado utiliza bibliotecas externas.
• foi atualizado para suportar o protocolo ssh 1.5.
• contém suporte adicionado a autenticação e passagem de ticket Kerberos.
• suportada autenticação one-time com skey(1).

A grosso modo, nós pegamos uma versão livre do ssh e convertemos para o estilo OpenBSD. Após um ano, 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

O Gerador de Números Pseudo-Aleatórios (PRNG) disponibiliza às aplicações que possuem certa importância para a segurança do sistema uma seqüência de números aleatórios:

• 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 seqüência de saída. Em um sistema operacional multi-usuário existem muitas fontes que permitirão 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 I/O 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 ambiente de 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 Inode, 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 do TCP ISS para proteção contra ataques de spoof.
• Preenchimento aleatório nos pacotes IPsec esp_old.
• Gerar salts para vários algoritmos de senha.
• Gerar disputas S/Key falsas.
• Verificação automática de trocas de chaves no isakmpd(8).

Funções Criptográficas de Hash

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

• duas entradas que possuam a mesma saída (imune a 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 criptográficas de hash:

• No S/Key(1) para gerar senhas one-time.
• No IPsec(4) e no isakmpd(8) para autenticar a origem de dados dos pacotes e para garantir sua integridade.
• Para senhas MD5 estilo FreeBSD (não ativadas por padrão), veja o passwd.conf(5)
• Na libssl para assinatura digital de mensagens.

Transformadores Criptográficos

Os transformadores criptográficos são usados para cifrar e decifrar dados. Eles são normalmente usados 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 do ambiente de usuário, que são utilizados em diversos locais:

• Na libc para criar senhas no formato Blowfish. Veja também o documento da USENIX neste tópico.
• No IPsec(4) para disponibilizar confidencialidade para a camada de rede.
• No isakmpd(8) para proteger as transações e negociações do IPsec.
• No AFS para proteger as mensagens que passam pela rede, fornecendo confidencialidade para sistemas de arquivos remotos.
• Na libssl para fornecer às aplicações comunicação sobre o protocolo SSL.

Suporte a Hardware Criptográfico

O OpenBSD, a partir da versão 2.7, começou a suportar alguns hardwares aceleradores criptográficos 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 criptografia no processamento de cada pacote resultando em uma performance síncrona. Para utilizar o hardware de forma correta e acelerar a operação era preciso separar estes dois componentes, assim como fizemos. Por sinal, esta operação resultou em um ganho de performance até no caso do software.

• Hifn 7751
  Placas Hifn 7751 pode ser utilizadas como aceleradores criptográficos simétricos, ex.:, o Soekris VPN1201 ou VPN1211 (como comprar) ou PowerCrypt. A performance 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 um CPU P3/550. Desenvolvimentos a 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 ao invés de usar o driver da PowerCrypt (escrito nos EUA), este hoje interagindo perfeitamente com a 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). A máxima performance utilizando-se 3DES SHA1 ESP é de aproximadamente 64Mbit/seg.

  Após o lançamento do 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 do 3.0, foi adicionado o suporte ao chip Hifh 7811, uma versão mais rápida da 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 do 3.2, foi adicionado suporte ao algoritmo de compressão LZS, utilizado pelo ipcomp(4).

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

  A Hifn foi no início uma empresa difícil de se lidar (eles tentaram nos convencer a mudar de idéia sobre o nosso algoritmo de destravamento criptográfico de engenharia reversa não-EUA), 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 a grandes números. Ele também contém um gerador de números aleatórios de alta performance. Possuímos um desses, documentação completa e códigos de exemplo. A partir da versão do OpenBSD 3.1, ambos gerador de números aleatórios e unidade de grandes números tiveram seu suporte incluído no sistema.

• Hifn 7814/7851/7854
  Este 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 a 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.

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

  A Bluesteelnet foi adquirida pela Broadcom. 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 uma performance quase quatro vezes mais rápida 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ódigos de exemplo para seus chips e um número suficiente de placas para podermos testar.

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

  Na versão 2.9, foi adicionado suporte ao chip BCM5820, que é basicamente uma versão mais rápida (64bit, velocidade de clock maior) do modelo BCM5805. Suporte ao modelo BCM5821 também foi adicionado na 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.

  Suporte parcial ao BCM5823 foi adicionado ao 3.4. O chip suporta AES, porém o driver não.

• 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 estes 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 RNG a criptografia simétrica destes 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 destes dispositivos já foi iniciado.

• 3com 3cr990
  A 3Com nos forneceu um driver para suportar o componente ethernet deste chipset e baseados nisso nós escrevemos nosso próprio driver. Este driver foi agora integrado uma vez que conseguimos uma licença livre para o microcode. 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 conseqüê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 a 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 alta performance 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
  O novo CPU VIA C3 contém um gerador de números aleatórios. A partir da versão 3.3 este item é utilizado pelo kernel para preencher a lista de entropia.

• Instruções VIA C3 AES
  CPUs VIA com um núcleo Nehemiah de 8 níveis ou maior contém uma implementação AES acessível via instruções simples. Com o 3.4 o kernel suportava isso para utilização em um contexto IPsec e exportação via /dev/crypto. Com o 3.5, a performance foi significantemente ampliada 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 aplicações 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 via 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 nas aplicações é necessária.

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

Criptógrafos Internacionais requeridos

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 do time 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.