Criptografia das mensagens

Na arquitetura de criptografia da linguagem Java, todos os algoritmos de criptografia (cifração, decifração, resumo de mensagem, geração de chaves, assina- tura digital, certificados e etc.) possuem uma mesma forma de uso, e são representados por classes-motor (engine classes). Estas classes definem as funcionalidades de cada algoritmo. As implementações destes algoritmos são feitas com o uso dos chamados Provedores de Serviços de Criptografia (Cryptographic Service Provider - CSP). Desta forma, um mesmo algoritmo pode ter implementações diferentes, desde que exista mais de um provedor configurado que forneça a implementação do algoritmo desejado.

O ambiente Java possui um provedor padrão, que acompanha a lingua- gem. Durante os primeiros desenvolvimentos do projeto JMixNet encontrou-se dificul- dades devido a limitações presentes neste provedor. Os únicos algoritmos de criptografia assimétrica implementados por este provedor são o de assinatura DSA - Digital Signa- ture Algorithm (NIST, 1994), e o de geração de par de chaves DSA. Este provedor não

dá a possibilidade, por exemplo, de se realizar apenas cifrações ou decifrações com o algoritmo DSA, e nenhuma operação com o algoritmo RSA. A realização de cifrações e decifrações assimétricas é justamente a necessidade para a criptografia das mensagens enviadas através da rede de mistura.

Fez-se então uma pesquisa por provedores de criptografia alternativos disponíveis na Internet, e optou-se pelo provedor desenvolvido pelo grupo Legion of the Bouncy Castle(www.bouncycastle.org), que é disponibilizado gratuitamente pelo grupo, e com código fonte aberto. Este provedor apresenta um número muito maior de imple- mentações de algoritmos, tanto simétricos quanto assimétricos, do que o provedor padrão do Java.

Atualmente já existem padrões para a troca de mensagens criptográficas entre sistemas distribuídos, sendo um dos mais utilizados a CMS (Cryptographic Mes- sage Syntax- Sintaxe para Mensagem Criptográfica) que é definida pela RFC 3369 (IETF, 2002). No projeto JMixNet optou-se por não utilizar este padrão, pois o mesmo causa um aumento desnecessário no tamanho das mensagens enviadas, pois em cada mensagem dados do certificado digital do destinatário (neste caso um servidor da JMixNet) também são inseridos. Foi feito um teste com alguns certificados digitais, utilizando o padrão CMS, e comparando-o com o formato definido para a JMixNet. Os certificados utilizados continham chaves públicas de 1024 bits, e ocasionaram um aumento médio no tamanho das mensagens de 430 bytes. Para o formato definido na JMixNet, o aumento no tamanho das mensagens é de 128 bytes utilizando-se certificados de 1024 bits.

Além do problema do aumento desnecessário do tamanho da mensa- gem, o provedor padrão do Java não possui suporte ao CMS. O formato definido para a JMixNet segue o procedimento de criação de um envelope digital.

O Fragmento de Código 7 mostra o procedimento utilizado pelo módulo cliente da JMixNet para a criação de mensagens a serem enviadas pela rede. A informa- ção a ser enviada é cifrada simetricamente com uma chave definida exclusivamente para aquela operação (linhas 3 e 4), criada pelo provedor de criptografia (linha 1). Para o algo- ritmo AES foram utilizadas chaves de 128 bits, e no modo CBC (Cipher Block Chaining - Encadeamento do Bloco de Cifração). Neste modo de operação o bloco de dados deve

ter como tamanho um múltiplo do tamanho da chave (no caso um múltiplo de 16 bytes), do contrário é preciso utilizar preenchimento de bloco. Assim, antes da cifração da infor- mação útil, é acrescentado um número descrevendo o tamanho desta informação (o qual ocupa 2 bytes), e se o tamanho da informação somado a estes 2 bytes não for um múl- tiplo de 16, são acrescentados tantos bytes de preenchimento quantos forem necessários. Este preenchimento é necessário apenas para o primeiro envelope, pois para os demais o conteúdo já terá um tamanho múltiplo de 16.

1 symCrypto.generateKey(); 2 //cifrar os dados

3 symCrypto.encrypt(srcBuf, 0, srcBufContentSize, 4 dstBuf, sessionKeyFieldSize);

5 srcBufContentSize += sessionKeyFieldSize;

6 //cifrar a chave simétrica e os parâmetros da cifra

7 asymCrypto.addDataToEncrypt(symCrypto.getEncodedKey(), 0, 8 symCrypto.getEncodedKey().length, dstBuf, 0);

9 encodedParameters = symCrypto.getParameters().getEncoded(); 10 asymCrypto.encrypt(encodedParameters, 0,

11 encodedParameters.length, dstBuf);

Fragmento de Código 7: Criação de mensagem pelo cliente

A figura 4.5 ilustra a necessidade de preenchimento. Na figura 4.5(a) o tamanho da informação útil somado aos 2 bytes necessários para informar este tamanho não resulta em um múltiplo de 16. Desta forma, torna-se necessário o uso de preenchi- mento para se atingir um valor deste tipo. Na figura 4.5(b) ocorre o contrário, como o tamanho da informação útil somado aos 2 bytes necessários para informar este tamanho resulta em um múltiplo de 16, não é necessário o preenchimento .

Estes dados com preenchimento são então cifrados simetricamente. Os 16 bytes componentes da chave simétrica juntamente com outros 18 bytes que compõem parâmetros internos do cifrador são tratados como entrada para o cifrador assimétrico RSA (linhas 7 a 11). Este cifrador é inicializado no modo de cifração e recebe o certi- ficado do último servidor da rede, para que sua chave pública seja utilizada na cifração da chave simétrica do envelope, utilizada no passo anterior. Os certificados emitidos para uso na JMixNet possuem um tamanho de chave de 1024 bits. Assim, o primeiro envelope

Figura 4.5: (a) Neste caso a informação útil não ocupa um espaço com tamanho adequado, sendo necessário o preenchimento. (b) Caso a informação útil possua um tamanho ade- quado, o preenchimento torna-se desnecessário.

digital consistirá nos dados cifrados simetricamente (com ou sem preenchimento), unido ao resultado da cifração assimétrica.

Para a formação do segundo envelope o processo é idêntico, sendo que agora o conteúdo deste envelope será o envelope anterior, uma nova chave simétrica será gerada, e o cifrador assimétrico será inicializado com o certificado do penúltimo servidor da rede. Este processo se repete até a criação do penúltimo envelope. Na criação do último envelope o processo é alterado para que se ocupe todo o espaço reservado para a mensagem anônima (considerando todo o espaço disponível como sendo o conteúdo do envelope), e para se evitar eventuais ataques ao anonimato (acrescentando o resumo dos dados). A figura 4.6 ilustra o processo de criação de mensagem anônima por um módulo cliente de uma JMixNet com quatro servidores.

Como é possível notar na figura, o espaço disponível para a informação útil a ser enviada de forma anônima consiste em apenas uma parte dos bytes disponíveis para a composição da mensagem. Este espaço é calculado quando o módulo cliente é iniciado. É considerado o número de servidores integrantes da rede, o espaço para o resumo criptográfico, e os dados sobre o tamanho da informação útil. Caso a informação útil a ser enviada seja maior que este espaço calculado, uma situação de erro é criada, informando sobre a restrição.

Figura 4.6: Criação de uma mensagem anônima