Para a representac¸ ˜ao do funcionamento, foi escolhido um exemplo bastante simples, constitu´ıdo apenas por 4 pastas (a principal e 3 sub-pastas) e 5 ficheiros, facilitando a visualizac¸ ˜ao das diferenc¸as entre codificac¸ ˜ao e descodificac¸ ˜ao. Executado foi: i. a operac¸ ˜ao de codificac¸ ˜ao, ii. a operac¸ ˜ao de descodificac¸ ˜ao e iii. um dos c ´alculos peri ´odicos do daemon respons ´avel pela atualizac¸ ˜ao dos ficheiros de posse:
• figura 6.6: A pasta escolhida pelo utilizador cont ´em os ficheiros num formato de uso normal. Este ´e o alvo do nosso algoritmo de codificac¸ ˜ao.
• figura 6.7: A pasta codificada. Cada ficheiro resultou em 3 a si associados (.d, .md e .own, como explicado previamente) e cada pasta possui um ficheiro de atualidade .ownf. O ficheiro de root-ownf foi tamb ´em criado no processo.
• figura 6.8: A pasta resultante. Trata-se da pasta descodificada, semelhante `a da fi- gura6.6. Como registo, existe ainda um ficheiro “Logfile.txt ”, que cont ´em informac¸ ˜oes relativas ao processo, como verificac¸ ˜ao de assinaturas, consist ˆencia de dados, per- miss ˜oes, etc. Este ficheiro n ˜ao ´e necess ´ario e a sua remoc¸ ˜ao n ˜ao tem quaisquer repercuss ˜oes negativas no sistema.
Figura 6.6: Pasta do utilizador
Figura 6.8: Pasta descodificada
De notar o processo de atualizac¸ ˜ao, produzindo hash trees de tamanho equivalente `a concatenac¸ ˜ao dos hashes individuais (explicado em 6.2.1). Como se pode observar na fig.
6.7, os ficheiros de atualidade possuem todos 32 bytes, o que ´e congruente com o output espect ´avel da func¸ ˜ao de hash utilizada. O ´ultimo passo envolve calcular o root-ownf, resul- tando num ficheiro maior (443 bytes), uma vez que este deve incluir o timestamp e deve ser assinado pelo utilizador.
Cap´ıtulo 7
Conclus ˜oes e trabalho futuro
7.1
Conclus ˜oes
Segundo a sec¸ ˜ao 1.4, os objetivos podem dividir-se em 4 pontos principais: an ´alise de seguranc¸a dos servic¸os atuais, explorac¸ ˜ao de abordagens te ´oricas, experimentac¸ ˜ao de al- ternativas e implementac¸ ˜ao de um sistema. Como tal, a apresentac¸ ˜ao das conclus ˜oes vai seguir esta mesma estrutura.
A generalidade das soluc¸ ˜oes atuais encontra-se numa posic¸ ˜ao desvantajosa a n´ıvel de ga- rantias de seguranc¸a oferecidas. A abordagem de confianc¸a total no provedor ´e prop´ıcia a falhas do mesmo, n ˜ao sendo um n´ıvel de confianc¸a aceit ´avel para entidades com informac¸ ˜ao sens´ıvel. A alternativa oposta, por outro lado, consiste em realizar a cifragem do lado do cliente, atribuindo ao sistema um n´ıvel de seguranc¸a adequado `a utilizac¸ ˜ao de servido- res remotos n ˜ao confi ´aveis. O problema desta soluc¸ ˜ao trivial ´e que vai contra a ideia do modelo de cloud, colocando peso de processamento do lado dos clientes e inutilizando a capacidade dos servidores remotos. A falta de primitivas criptogr ´aficas adequadas a esta necessidade apresenta-se como o maior obst ´aculo, n ˜ao existindo forma de realizar c ´alculo sobre informac¸ ˜ao cifrada, nem forma de partilhar chaves sem tornar o sistema demasiado obtuso.
As abordagens te ´oricas exploradas atacam dois problemas essenciais: i. partilhar informac¸ ˜ao sem confianc¸a total no servidor remoto e ii. executar operac¸ ˜oes sobre cripto- gramas.
i. Foram explorados os sistemas SiRiUS e Plutus. O SiRiUS apresentou-se como o can- didato mais adequado ao modelo de cloud (4.2.1), demonstrando o funcionamento de uma camada que permite a aplicac¸ ˜ao de t ´ecnicas de seguranc¸a do lado do cliente com partilha de ficheiros e exig ˆencias reduzidas a n´ıvel de partilha de chaves. Por ´em, o processamento criptogr ´afico exigido na sua execuc¸ ˜ao e a aus ˆencia de resposta `a pro- blem ´atica da partilha de chaves revelaram-se como as suas maiores desvantagens.
ii. Na execuc¸ ˜ao de operac¸ ˜oes sobre criptogramas, foi considerada a utilizac¸ ˜ao de esque- mas baseados em MLE. Esta primitiva permite a comparac¸ ˜ao de dois criptogramas em relac¸ ˜ao ao seu conte ´udo, de modo a poder ser realizada deduplicac¸ ˜ao. Para al ´em das exig ˆencias de processamento adicionadas, esta tem a desvantagem de reduzir drastica- mente o n´ıvel de seguranc¸a do sistema, consequ ˆencia das infer ˆencias poss´ıveis sobre os dados armazenados.
O benchmark implementado para experimentac¸ ˜ao com t ´ecnicas de MLE permite que sejam atingidas conclus ˜oes mais espec´ıficas sobre a t ´ecnica em quest ˜ao. Como apresentado em
5.2.2, os resultados dividem-se em perspetiva do cliente e perspetiva do servidor. Do lado do cliente, as t ´ecnicas de MLE n ˜ao revelaram exig ˆencias inesperadas, conseguindo-se va- lores adequados em relac¸ ˜ao aos termos de comparac¸ ˜ao escolhidos. Do lado do servidor, o
MLE apresentou efic ´acia elevada (semelhante `a da deduplicac¸ ˜ao normal), mas a tentativa
de gerar entropia nas mensagens para elevar o n´ıvel de seguranc¸a teve resultados insatis- fat ´orios. Assim, pode concluir-se que o MLE ´e uma primitiva que, a n´ıvel de deduplicac¸ ˜ao, atinge excelentes n´ıveis de efic ´acia mas que, a n´ıvel de seguranc¸a, exige um s ´erio relaxa- mento do modelo de seguranc¸a. Adicionalmente, a ideia de atribuir seguranc¸a apoiada na entropia (criptogramas sem indistinguibilidade) ´e contradit ´oria `a natureza dos sistemas com mensagens previs´ıveis, prop´ıcios `as t ´ecnicas de deduplicac¸ ˜ao.
O sistema de partilha segura de ficheiros implementado permite o desenvolvimento de dife- rentes pontos a explorar.
• A estruturac¸ ˜ao de dados e o funcionamento do SiRiUS pode ser adaptado `a utilizac¸ ˜ao de t ´ecnicas com MLE, quando acrescentada a noc¸ ˜ao de ownership partilhada e mo- vido o mecanismo de atualizac¸ ˜ao para estes novos ficheiros. Esta nova abordagem faz uso do identificador necess ´ario ao MLE para associar ficheiros de metadados com os respetivos dados.
• A utilizac¸ ˜ao de CL-PKC nas diferentes func¸ ˜oes de cifragem e assinatura ´e uma poss´ıvel soluc¸ ˜ao para o problema de distribuic¸ ˜ao de chaves. Sem necessidade do peso associado ao uso de certificados, estas t ´ecnicas n ˜ao exigem a confianc¸a total numa ´unica entidade, como seria o caso da imediata alternativa, o IBE.
• A conjugac¸ ˜ao de t ´ecnicas de MLE com partilha de ficheiros (seguindo a metodologia em 3.4) implica a utilizac¸ ˜ao de revogac¸ ˜ao lazy, resultado da ligac¸ ˜ao entre chave e mensagem associada (4.3.2).