Detalhes sobre o Funcionamento da Ferramenta de Encriptação Adotada

No capítulo anterior definiu-se, através de estudos e testes de desempenho, que a ferra- menta de encriptação a integrar o modelo-solução e que melhor se adequa à estratégia de encripta- ção escolhida e aos tipos de dados da IPBrick cloud que devem ser encriptados, seria a ferramenta de encriptação do disco eCryptfs.

4.2 Módulo de Encriptação de Dados 51

Gestor de Chaves

Utilizador Kernel

Gestor de Chaves eCryptfs

Daemon TPM OpenSSL PAM GnuPG Camada eCryptfs Kernel Crypto API

File System ext4 Estrutura do Ficheiro Meta-Dados Criptográficos

Frameworks

Figura 4.1: Arquitetura da eCryptfs no sistema operativo Linux. A representação foi inspirada na figura 1 do relatório da IBM: "eCryptfs: An Enterprise-class Cryptographic Filesystem for Linux".

Apesar de ser classificada como ferramenta de encriptação do disco, a designação mais cor- reta é a de file system criptográfica ou de encriptação, atuando no topo da pilha sobre a qual está definida a organização dos ficheiros no sistema (Figura4.1), por outras palavras, sobre uma file systemexistente, dando-se o exemplo da file system ext4 no caso do software IPBrick. A arqui- tetura da eCryptfs é composta por diversas frameworks do sistema operativo Linux das quais se destacam as seguintes: Linux kernel keyring service, kernel cryptographic API, Linux Pluggable Authentication Modules, OpenSSL, Trusted Platform Module, GnuPG keyring; pertencentes quer ao espaço dedicado ao utilizador, quer ao Linux kernel, com o objetivo de tornar a importante tarefa de gestão de chaves criptográficas simples e transparente. As operações de encriptação e desencriptação dos dados são executadas ao nível do kernel do sistema operativo tirando proveito da kernel cryptographic API, evitando-se, segundo os autores da ferramenta, overheads associa- dos às operações no contexto de trocas de elementos criptográficos entre o espaço do utilizador e o espaço do kernel [41].

Passphrase || Salt da eCryptfs i < 65536 SHA-512 SHA-512 Chave Secreta Simétrica Assinatura Chaveiro do Kernel

Figura 4.2: Protocolo para geração da chave secreta simétrica usada pela cifra AES incorporada na eCryptfs. Juntamente com a chave é gerada uma assinatura respetiva.

A eCryptfs suporta os algoritmos baseados , quer em chave simétrica, quer em chave pública, referenciados em2.3.3.1. Devido ao elevado número de operações associado ao algoritmo de en- criptação recorrendo a chave pública, este último não é tão comummente usado para encriptação dos dados com a ferramenta eCryptfs. Todas as cifras simétricas suportadas pelo Linux kernel são candidatas a incorporar os mecanismos de encriptação de dados da eCryptfs. Das cifras supor- tadas destaca-se a AES no modo de atuação por blocos, CBC. A eCryptfs possui um protocolo próprio para geração e gestão da chave secreta simétrica a utilizar para encriptação dos dados de cada ficheiro. Esse protocolo tem como elementos fundamentais, a passphrase definida como pa- râmetro de entrada pelo utilizador do sistema, um salt pré-definido, e um conjunto de operações de hash recursivas recorrendo à função de hash SHA-512. A figura4.2ilustra o protocolo interno da eCryptfs para geração da chave secreta simétrica em que a passphrase do utilizador é conca- tenada com o salt específico da ferramenta, o resultado da concatenação serve como input inicial a um conjunto de 65536 iterações da função de hash SHA-512. Os 32 primeiros bytes ou 256 bits, resultantes das sucessivas iterações, formam a chave secreta simétrica. A assinatura da chave secreta simétrica deriva da execução de mais uma iteração em que são selecionados os 8 primeiros bytes do resultado obtido [41].

4.2 Módulo de Encriptação de Dados 53

Figura 4.3: Partição do disco virtual "/dev/sda7" montada no diretório "/home1".

Figura4.4), todos os ficheiros nele gerados a partir de então, são escritos na partição do disco pre- viamente montada nesse mesmo diretório (Figura4.3), num formato encriptado após intervenção da cifra AES no modo CBC utilizando como chave de encriptação a gerada a partir do protocolo da Figura4.2que manter-se-á juntamente com a sua assinatura, em cache no chaveiro do kernel até que a eCryptfs seja desativada. Recorrendo ao uso de uma gíria descontextualizada, a eCryptfs define um caixote em que todos os dados nele depositados sofrem um processo de encriptação imediatamente antes de serem armazenados no disco. Contudo, o caixote permanece aberto, e os dados disponíveis (após sofrerem uma operação de desencriptação), enquanto que a eCryptfs estiver montada, isto depois da realização de um processo de autenticação bem sucedido utili- zando, por exemplo, a passphrase do cliente. Juntamente com o conteúdo encriptado de um dado ficheiro são também guardados meta-dados que incluem, entre vários parâmetros criptográficos, a assinatura da chave correspondente à usada para encriptar o referido ficheiro. Como foi visto no ponto correspondente ao estudo das ferramentas criptográficas em3.5, a eCryptfs não possui, na atualidade, mecanismos de verificação da integridade dos dados embora exista a previsão para a in- tegração dessa funcionalidade através do uso do procedimento MAC, já abordado no ponto2.3.3.3

do capítulo da revisão bibliográfica [41].

4.2.2 Protocolo de Gestão de Chaves Criptográficas

O fator sensível e determinante tendo em conta a tríade confidencialidade, integridade e dis- ponibilidade dos dados (Figura2.6), na IPBrick cloud, é a gestão dos diferentes tipos de chaves necessárias para a implementação de um sistema criptográfico seguro. Na Figura4.2 do ponto anterior observa-se o protocolo interno para gestão de chaves criptográficas da eCryptfs partindo do fornecimento de uma passphrase por parte do utilizador. O criptógrafo Sylvain Pelissier no artigo "How to crack Ubuntu encryption and passwords", sobre a eCryptfs, descreve um bug no protocolo interno de gestão de chaves criptográficas da ferramenta, que consiste no uso de um salt estático e conhecido, aquando da concatenação inicial com a passphrase introduzida pelo utiliza- dor, o que torna possível os ataques criptográficos conhecidos por: ataque do dicionário e ataque do arco-íris [42]. O mesmo criptógrafo conseguiu decifrar a sua passphrase através da ferramenta john the ripper, perpetrando os ataques referidos anteriormente, no período de tempo equivalente a um mês. Para serem evitados possíveis ataques como os referidos, para que exista independência em relação aos protocolos internos da eCryptfs e também para que o próprio cliente da IPBrick SA possua as suas próprias chaves únicas e distintas de todos os outros clientes, decidiu-se construir um protocolo de gestão de chaves totalmente independente da ferramenta de encriptação e cujo o objetivo é gerar uma passphrase de entrada na eCryptfs suficientemente robusta para prevenir ataques de força bruta, ataques do dicionário e ataques do arco-íris.

Figura 4.4: Diretório "/home1" montado nele próprio pela eCryptfs, encontrado-se assim prote- gido. IPBrick Salt Password do Cliente

| |

Figura 4.5: Protocolo para gestão de chaves do cliente utilizado na implementação do módulo de encriptação de dados da IPBrick cloud.

A Figura4.5ilustra o protocolo a implementar para a geração da passphrase que serve como parâmetro de entrada ao protocolo interno da eCryptfs que por sua vez, gera a chave secreta si- métrica. Na interface de administração da IPBrick cloud o cliente deverá introduzir a password que pretende para ativação do módulo de encriptação. Essa password é concatenada com um salt que só a IPBrick SA tem conhecimento. O resultado da concatenação serve ainda como parâ- metro de entrada à função de hash SHA-256. Do output da função de hash resulta a passphrase robusta e única a introduzir na eCryptfs. Caso o cliente selecione o caminho 1, a sua password é imediatamente eliminada do sistema após geração da passphrase a introduzir na eCryptfs, esta última é igualmente eliminada do sistema após o mounting dos diretórios que se querem seguros, tal como indica o caminho 3, garantindo-se assim a eficácia do sistema criptográfico, salvaguar- dando o direito de acesso aos dados apenas ao cliente da IPBrick SA, extinguindo-se qualquer tipo de backdoors que pudessem vir a existir. Apenas a chave simétrica criptográfica permanece em cacheno espaço do kernel durante o período de atividade do módulo de encriptação mas possí-

4.2 Módulo de Encriptação de Dados 55

veis ataques a essa chave exigiriam privilégios de root no sistema ou um ataque por força bruta a uma chave de 256 bits que designa o tamanho da chave secreta simétrica, tendo ainda que ser encontrado o vetor de inicialização da cifra AES em modo CBC, o que na prática, devido à ine- xistência de poder de processamento suficiente na atualidade, é considerado extremamente difícil. O caminho 2 representado na Figura4.5, foi criado para disponibilizar uma opção ao cliente que permita efetuar um backup da sua password que seria útil, por exemplo, no caso de esquecimento. Seria também útil para salvaguardar a autonomia da IPBrick cloud aquando de um reboot ines- perado (ex. falha nos servidores do CSP). Sempre que existe um reboot do sistema, a eCryptfs é desmontada e todos os dados do diretório protegido ficam disponibilizados ao cliente no formato encriptado. Para que o cliente consiga visualizar os dados em claro quando o sistema se encontra novamente ativo, é necessário que insira novamente a sua password para que a eCryptfs possa ser montada uma vez mais. O caminho 2 preveniria esta situação tornando a IPBrick cloud totalmente automática a este nível. No entanto, seguindo este caminho, existe uma redução considerável da segurança imposta uma vez que a password do cliente fica armazenada no espaço remoto da IPBrick cloud, podendo permanecer num formato ofuscado, mas ainda assim representa um me- canismo que vai contra princípios criptográficos definidos pela CSA, criando possivelmente uma backdoorindesejável. Ainda assim, essa funcionalidade está prevista no protocolo para deixar ao critério do cliente a escolha da opção que lhe seja mais conveniente.