Para este sistema, pretende-se que sejam disponibilizadas as contramedidas do tipo C2,
sendo aplicadas as t ´ecnicas de seguranc¸a do lado do cliente. Para tal, vai ser seguido o esquema de funcionamento e estrutura de dados apresentados em [35]. Tal como o referido, este sistema tem o objetivo de funcionar como uma camada de seguranc¸a, oferecendo garantias de seguranc¸a independentes do servic¸o no qual esta instalado.
Ao contrario da atitude tomada em [35, 36], este trabalho pretende enfrentar a problem ´atica da partilha de chaves atrav ´es da aplicac¸ ˜ao de CL-PKC (2.2.4). Deste modo, o sistema proposto n ˜ao tem necessidade de delegar responsabilidades de gest ˜ao de chaves para os utilizadores, nem exige confianc¸a total numa entidade de distribuic¸ ˜ao de chaves.
Numa perspetiva de expandir as funcionalidades oferecidas, o sistema deve disponibilizar a possibilidade de funcionar com esquemas de MLE (4.3). Desta forma, pode ser realizada uma adaptac¸ ˜ao ao pr ´oprio, caso as exig ˆencias de seguranc¸a sejam relax ´aveis ao ponto do MLE ser aceit ´avel para os utilizadores.
6.1.1
Crit ´erios de design
Antes de apresentar a arquitetura e a estrutura do sistema, v ˜ao ser descritos alguns crit ´erios que foram tidos em conta no desenvolvimento do mesmo. A explicac¸ ˜ao destes pontos
pode ser usada para, posteriormente, medir e justificar a validade das decis ˜oes tomadas na implementac¸ ˜ao, bem como avaliar os resultados conseguidos com o sistema em si.
• Sistema como camada. Este sistema deve funcionar como uma camada de seguranc¸a a ser aplicada sobre um servic¸o de partilha de ficheiros, n ˜ao podendo assim exigir que o sistema sobre o qual est ´a inserido providencie operac¸ ˜oes n ˜ao espect ´aveis de servic¸os do g ´enero.
• Programa minimal. Sendo um sistema que corre na m ´aquina pessoal de um utilizador de servic¸o de cloud, n ˜ao se pode esperar que esta incorra em operac¸ ˜oes pesadas a n´ıvel de processamento ou que necessitem de grande capacidade de armazenamento local.
• Performance adequada. Para a aplicac¸ ˜ao deste sistema na pr ´atica, este tem de apre- sentar n´ıveis de performance equipar ´aveis a servic¸os semelhantes. Caso contr ´ario, ´e improv ´avel que utilizadores mais exigentes a este n´ıvel mostrem interesse na sua utilizac¸ ˜ao.
• Baixa largura de banda. Este sistema deve recorrer a uma largura de banda com- par ´avel `a de servic¸os semelhantes, ou os utilizadores com fracas conex ˜oes n ˜ao po- der ˜ao usufruir do programa.
• Leve distribuic¸ ˜ao de chaves. Para o envio de chaves entre utilizadores, a comunicac¸ ˜ao extraordin ´aria ao sistema deve ser minimizada, sendo utilizado um esquema que per- mita a partilha de chaves sem exig ˆencia de excessiva informac¸ ˜ao transmitida no pro- cesso.
6.1.2
Arquitetura do sistema
O sistema ´e constitu´ıdo por dois componentes, o programa do utilizador e o daemon de atualizac¸ ˜ao - fig. 6.1.
O programa do utilizador ´e a parte do sistema que vai interagir com o pr ´oprio, sendo esse a “ponte” entre os dados que o cliente possui no disco e a pasta a ser armazenada na cloud. Este ´e o componente central e o ´unico cujo funcionamento o utilizador deve compreender de modo a poder utilizar adequadamente o sistema. Este est ´a encarregue de permitir ao
Figura 6.1: Arquitetura do sistema
utilizador aceder `as funcionalidades do mesmo, executando codificac¸ ˜oes e descodificac¸ ˜oes, bem como todas as operac¸ ˜oes relacionadas com permiss ˜oes sobre os ficheiros.
O daemon ´e um componente que pode passar despercebido ao cliente menos informado, executando em background e exigindo apenas capacidade de processamento peri ´odica. Este ´e respons ´avel pela integridade dos ficheiros de posse, o que faz com que, n ˜ao sendo um componente sobre o qual o cliente interage ou sequer tem necessidade de saber muito sobre a sua func¸ ˜ao, represente uma parte importante nas metas de seguranc¸a a atingir.
6.1.3
Estrutura dos dados
Seguindo o tipo de estrutura proposta no sistema SiRiUS, cada utilizador vai possuir apenas dois pares de chaves, que tem de gerar no inicio da utilizac¸ ˜ao do sistema: User Encryption Key (UEK), um par de chaves assim ´etricas utilizadas na cifragem/decifragem e User Sig- nature Key (USK), um par de chaves assim ´etricas utilizadas na assinatura/verificac¸ ˜ao de ficheiros. Desta forma, cada utilizador s ´o tem de armazenar a vers ˜ao privada desses pares. Para al ´em destas chaves, o sistema faz uso de quatro estruturas associadas ao armazena- mento da informac¸ ˜ao. Uma delas ´e referente aos dados, apenas associando identificadores
Figura 6.2: Ficheiro de dados: d-file
`a informac¸ ˜ao respetiva. A segunda engloba metadados referentes a ficheiros individuais. A terceira ´e a de posse, sendo que cont ´em apenas o nome do ficheiro, a lista de utilizado- res com permiss ˜oes de escrita sobre um determinado ficheiro e a assinatura do dono do mesmo. Finalmente, a quarta estrutura permite manter a atualidade dos ficheiros de posse, mantendo o hash e o timestamp assinados pelo utilizador.
• d-file, o ficheiro que cont ´em informac¸ ˜ao. Uma vez que o sistema suporta esquemas baseados em MLE, cada d-file vai estar associado a um identificador relativo `a sua informac¸ ˜ao. -6.2.
• md-file, contendo o identificador da informac¸ ˜ao para recolha, o utilizador que realizou a ´ultima alterac¸ ˜ao, o nome do ficheiro, uma lista de blocos contendo a chave do fi- cheiro, cifradas com as UEK p ´ublicas dos utilizadores com permiss ˜oes para acesso ao ficheiro e a assinatura dos dados do ficheiro md-file em quest ˜ao com USK do utilizador que realizou a ´ultima alterac¸ ˜ao -6.3.
• own-file, contendo o nome do ficheiro, uma lista de utilizadores com permiss ˜oes de escrita (que, por consequ ˆencia, podem assinar o md-file) e a assinatura do owner do ficheiro, com a sua USK -6.4.
• ownf-file, contendo o nome da diretoria, o hash dos hashes dos ficheiros own-file, concatenados de forma lexical, um timestamp e, caso se trate de um ficheiro de ownf- root, tudo isto assinado pela USK do utilizador -6.5.
6.1.4
Odaemon
e os ficheiros de atualidade
Ataques de rollback consistem na substituic¸ ˜ao de um determinado ficheiro no sistema por uma vers ˜ao mais antiga do mesmo, com objectivo de utilizar isso para contornar algum me- canismo de seguranc¸a no sistema. Como exemplo, a Alice inicialmente atribuiu permiss ˜oes
Figura 6.3: Ficheiro de dados: md-file
Figura 6.4: Ficheiro de dados: own-file
ao Bob para aceder a um dado ficheiro F , no entanto, a Alice recebeu not´ıcias que indicam que o Bob pode ser malicioso e revoga as permiss ˜oes do Bob. Neste caso, o Bob tenta subs- tituir o ficheiro de permiss ˜oes recente pelo ficheiro de permiss ˜oes existente quanto ainda tinha acesso a F , cuja assinatura ´e v ´alida, recuperando acesso ao ficheiro que pretende atacar. Atualidade trata-se de uma garantia de que os ficheiros foram verificados recente- mente e permite contrariar este tipo de ataques, rejeitando qualquer ficheiro cujo timestamp n ˜ao se encontre dentro do intervalo de tempo considerado v ´alido.
O sistema permite garantir a atualidade dos seus ficheiros de permiss ˜oes recorrendo ao mecanismo utilizado pelo SiRiUS. A soluc¸ ˜ao do mesmo passa por utilizar uma hash tree [43] que engloba todos os own-files. Cada diretoria tem um ficheiro .ownf que garante a atualidade da mesma diretoria, contendo o hash de todos os ficheiros .own e todos os .ownf de sub-diretorias, sendo o ficheiro .ownf da pasta principal chamado ownf-root. Para o processo existem tr ˆes func¸ ˜oes principais envolvidas: A gerac¸ ˜ao inicial dos ficheiros .ownf e ownf-root, a atualizac¸ ˜ao peri ´odica de ownf-root e a verificac¸ ˜ao de validade da ´arvore. O daemon ´e respons ´avel por estas func¸ ˜oes, enquanto que o programa do cliente vai reali- zar verificac¸ ˜oes e atualizac¸ ˜oes espor ´adicas, quando os ficheiros de posse tiverem de ser consultados ou alterados.
De seguida, vai ser descrito como o sistema realiza as operac¸ ˜oes indicadas acima: • Gerar ficheiros ownf :
1. Aplicar uma func¸ ˜ao de hash a cada ficheiro de posse, verificando as respetivas assinaturas.
2. Concatenar os hashes de cada ficheiro de posse com os .ownf de cada sub- diretoria em ordem lexicogr ´afica.
3. Aplicar uma func¸ ˜ao de hash `a concatenac¸ ˜ao.
4. Caso se trate de um ficheiro ownf-root, marcar com o timestamp atual, assinar o conte ´udo e armazenar em cache.
5. Armazenar o ficheiro. • Verificar atualidade da ´arvore:
1. Recalcular o ficheiro .ownf da diretoria, seguindo os 3 primeiros passos da operac¸ ˜ao anterior, e comparar ao armazenado no .ownf a avaliar. Caso a comparac¸ ˜ao falhe, abortar.
2. Se a diretoria ´e root, verificar timestamp e assinatura, caso n ˜ao seja, aplicar esta operac¸ ˜ao recursivamente subindo na ´arvore.
• Atualizar o ficheiro ownf-root: Este processo ´e realizado por ambos os componentes. O daemon tem obrigac¸ ˜ao apenas de o validar e atualizar o timestamp. Para isso, este faz uso da cache local para comparar ao ownf-root atual, refrescar o timestamp, as- sinar a nova informac¸ ˜ao e voltar a guardar em cache, tornando esta uma operac¸ ˜ao relativamente leve. Por outro lado, o programa tem de executar esta operac¸ ˜ao quando forem realizadas alterac¸ ˜oes nas permiss ˜oes. Grac¸as `a estrutura da ´arvore, mudanc¸as em ficheiros de posse alteram apenas a diretoria atual e todas as diretorias acima na ´arvore, diminuindo a quantidade de ficheiros a serem recalculados de forma seme- lhante `a descrita nos passos 1-5 da operac¸ ˜ao de gerac¸ ˜ao.