Este sistema ´e composto por dois componentes. O primeiro ´e o programa de codificac¸ ˜ao, que disponibiliza todas as operac¸ ˜oes executadas pelo cliente. Como tal, a inicializac¸ ˜ao do mesmo exige:
• Username - O nome do utilizador. Este nome vai ser utilizado para o programa saber que chave utilizar, quando for necess ´ario realizar operac¸ ˜oes criptogr ´aficas, e para identificar o utilizador nas alterac¸ ˜oes (para assinaturas de ficheiros .md ).
• PathToStore - A localizac¸ ˜ao da diretoria onde armazenar ficheiros codificados. • PathToRestore - A localizac¸ ˜ao da diretoria onde armazenar os conte ´udos descodifi-
cados da pasta definida em PathToStore.
• PathToKeys - Predefinido como “/tmp/keys”, ´e a localizac¸ ˜ao para o programa arma- zenar as chaves geradas e onde procurar chaves necess ´arias `as operac¸ ˜oes.
• TimeDif - A diferenc¸a de tempo (em segundos) a partir da qual um ficheiro ´e conside- rado obsoleto. Este crit ´erio define o qu ˜ao estrito vai ser o sistema contra ataques de rollback.
O segundo componente do sistema ´e o daemon de atualizac¸ ˜ao. Como o objetivo deste passa pela execuc¸ ˜ao de func¸ ˜oes em background, ´e importante a correta definic¸ ˜ao dos argu- mentos das mesmas:
• Username - Tal como no programa, utilizado para identificar o utilizador, de modo a saber que chaves utilizar.
• Path - O daemon est ´a dedicado `a pasta codificada, portanto, este argumento deve ser o mesmo utilizado em PathToStore no programa do cliente.
• PathToKeys - An ´aloga `a do componente anterior
• TimeDif - Valor igual ao escolhido no programa, neste caso representando o intervalo de tempo entre atualizac¸ ˜oes.
6.2.1
Diagramas e detalhar de func¸ ˜oes
Para a abordagem detalhada das funcionalidades do sistema, ´e importante ter em conta os algoritmos referidos em 6.4, uma vez que ser ˜ao utilizados para estes m ´etodos. As descric¸ ˜oes extensivas, por uma quest ˜ao de facilidade de leitura, podem-se consultar no anexoB
Programa de codificac¸ ˜ao
• Codificar pasta - Esta func¸ ˜ao recebe, como input, a pasta que o utilizador deseja que seja codificada, executando as cifragens e decifragens necess ´arias.
• Descodificar pasta - Operac¸ ˜ao inversa `a codificac¸ ˜ao.
• Atribuir permiss ˜oes - Operac¸ ˜ao que permite o utilizador atribuir permiss ˜oes, consoante o input da mesma (ficheiro, utilizadores e opc¸ ˜ao).
Daemon de atualizac¸ ˜ao
• Refrescar hash tree - ´Unica func¸ ˜ao do daemon. Esta ´e realizada periodicamente, sendo que a primeira iterac¸ ˜ao envolve a gerac¸ ˜ao da ´arvore (ver func¸ ˜oes auxiliares).
Func¸ ˜oes auxiliares
• Verificar atualidade da ´arvore - Esta operac¸ ˜ao deve ser realizada sempre que se ve- rifica uma assinatura, de modo a ser notific ´avel a exist ˆencia de poss´ıveis ficheiros obsoletos.
• Gerar hash tree - Esta operac¸ ˜ao ´e executada na primeira iterac¸ ˜ao do daemon e por cada vez que o utilizador alterar permiss ˜oes de escrita (o que envolve alterar ficheiros .own), consistindo na atualizac¸ ˜ao da ´arvore.
Para a melhor compreens ˜ao das func¸ ˜oes de gerar, verificar ou refrescar a ´arvore, no anexo
Cencontram-se diagramas de atividade que ilustram o seu funcionamento.
6.3
An ´alise de seguranc¸a
Esta sec¸ ˜ao visa abordar as ameac¸as de seguranc¸a listadas em3.4e apresentar contrame- didas que atendam aos requisitos de seguranc¸a referidos em3.4. Segue-se uma avaliac¸ ˜ao do risco resultante das soluc¸ ˜oes propostas, bem como uma validac¸ ˜ao dos requisitos con- templados.
De modo a atingir confidencialidade, o sistema recorre a cifras sim ´etricas para a cifragem dos dados (C1). Cada d-file vai encontrar-se sempre em criptograma, dependendo do es-
quema utilizado para garantir confidencialidade da informac¸ ˜ao armazenada. ´E importante ter em conta que, uma vez que o sistema permite a utilizac¸ ˜ao de MLE, o n´ıvel de seguranc¸a deve ter contemplar estes casos (C10).
Para proteger a integridade dos dados, o sistema recorre a um sistema de assinaturas digitais (C2). Estas v ˜ao ser utilizadas para ficheiros de metadados, como md-file, own-file e
P A AA Utilizadores Pro v edores Quebra de confidencialidade C1, C10 C1, C10 C1, C10 C1, C10
Alterac¸ ˜ao dos dados C2 C2 C2
DoS C5 C5 C5
Acesso inadvertido C2+ C3 C2+ C3 C2+ C3
Ataques por rollback C4 C4 C4
Quebra de confianc¸a C2+ C3 −
Takeover − −
Perda de chaves C3∗ C3∗ Corrupc¸ ˜ao acidental − − Divulgac¸ ˜ao da informac¸ ˜ao C1, C10
Tabela 6.1: Abrangˆencia das contramedidas apresentadas. ”−” representam amea¸cas n˜ao con- templadas no trabalho, ”∗” representam limitada cobertura `a amea¸ca.
A partilha de chaves ´e realizada atrav ´es de CL-PKE, utilizando uma metodologia seme- lhante `a dos sistemas atuais (C3). As chaves de cada ficheiro s ˜ao armazenadas em conjunto
com o mesmo e est ˜ao dependentes da integridade do pr ´oprio ficheiro de metadados. A integridade dos ficheiros de metadados ´e conseguida atrav ´es de uma hash tree (C4).
Esta ´arvore ´e gerida por um daemon de atualizac¸ ˜ao, respons ´avel por realizar constantes verificac¸ ˜oes aos ficheiros centrais do sistema. Este mecanismo ´e crucial para garantir o bom funcionamento do sistema de permiss ˜oes.
A utilizac¸ ˜ao do sistema como camada de seguranc¸a para codificac¸ ˜ao e descodificac¸ ˜ao de dados mant ´em uma c ´opia dos ficheiros localmente (C5). Desta forma, o utilizador ´e salva-
guardado contra poss´ıveis downtimes do servic¸o no qual est ´a inserido.
Na tabela 6.1, encontram-se representadas as ameac¸as protegidas pelas contramedidas abordadas.
6.3.1
Avaliac¸ ˜ao do risco
Tendo sido enumerados os agentes e as respetivas ameac¸as, bem como descritas as con- tramedidas aplicadas para responder `as mesmas, ´e importante atender ao risco associado.
Seguindo o esquema apresentado na fig. 2.1, vai ser detalhadamente analisado at ´e que n´ıvel se espera que as contramedidas propostas resolvam os problemas que se espera en- frentar. Nesta an ´alise, v ˜ao tamb ´em ser tidas em conta as suposic¸ ˜oes de seguranc¸a (3.4), relativamente `as exig ˆencias de cada ponto. Para auxilio visual, vai-se recorrer `a tabela6.1, descrevendo cada caso individualmente.
A quebra de confidencialidade deve ser analisada perante as duas vertentes. No caso de C1, s ˜ao utilizadas as cifras sim ´etricas apresentadas em 2.2.2. Recorrendo a estes es-
quemas, os dados armazenados atingem a propriedade de indistinguibilidade e, caso seja utilizado um modo CBC ou semelhante, o esquema consegue ser CPA-seguro. Quando s ˜ao utilizados esquemas de MLE (C10), os criptogramas s ˜ao distingu´ıveis para sistemas que n ˜ao possuam uma alta entropia associada `as mensagens dos mesmos. Nestes casos, o n´ıvel de seguranc¸a ´e drasticamente reduzido, n ˜ao se alcanc¸ando indistinguibilidade de criptogra- mas.
Caso os dados sejam alterados por advers ´arios, a utilizac¸ ˜ao de assinaturas digitais (C2)
permite que o utilizador se aperceba dessas mudanc¸as. A alterac¸ ˜ao de dados pode tamb ´em ser realizada indiretamente, contornando este mecanismo, mas esse ´e um tipo de ataque abordado posteriormente. Esta contramedida n ˜ao contempla a recuperac¸ ˜ao de ficheiros corrompidos, sendo poss´ıvel recorrer a sistemas tolerantes a falhas bizantinas caso sejam necess ´arias medidas adicionais de confiabilidade.
Ataques por DoS n ˜ao s ˜ao diretamente contrariados pelo sistema. No entanto, e uma vez que este funciona atrav ´es de sincronizac¸ ˜ao de pastas, o utilizador n ˜ao perde completamente o acesso `a sua informac¸ ˜ao. Este n´ıvel de seguranc¸a depende do qu ˜ao frequentes forem realizadas as operac¸ ˜oes de codificac¸ ˜ao/descodificac¸ ˜ao e pode ser reforc¸ado atrav ´es da imposic¸ ˜ao de uma pol´ıtica de seguranc¸a associada a essa atitude.
Acesso inadvertido ´e impossibilitado pela assinatura dos metadados e das chaves para leitura dos dados. De forma a realizar alterac¸ ˜oes, ´e necess ´ario ter acesso `a chave pri- vada de assinatura, e para conhecer a chave associada aos criptogramas armazena- dos, ´e necess ´ario ter acesso `a chave privada de decifragem. Assim, a contramedida C2
responsabiliza-se por n ˜ao ser poss´ıvel realizar alterac¸ ˜oes maliciosas `as permiss ˜oes de es- crita e a contramedida C3 ´e aplicada para n ˜ao ser poss´ıvel subjugar a leitura `a informac¸ ˜ao
armazenada.
Os ataques por rollback s ˜ao contrariados, principalmente, pela utilizac¸ ˜ao da ´arvore de hash (C4). Contudo, este tipo de ataques merece uma abordagem extensiva, de maneira a ser
integralmente compreendido e, como tal, os ficheiros pass´ıveis de substituic¸ ˜ao v ˜ao ser abor- dados um a um: i. no caso de ser tentado substituir um ficheiro de dados por um obsoleto, o identificador associado ao mesmo vai ser incongruente com o presente nos ficheiros de metadados. ii. No caso de ser substitu´ıdo o ficheiro de metadados por uma vers ˜ao mais antiga, o identificador no pr ´oprio vai referir o ficheiro de dados anterior, maximizando o po- tencial deste ataque ao de restituir acesso de leitura a um ficheiro j ´a revogado. Este ataque pode ser igualmente ating´ıvel atrav ´es do backup dos ficheiros acess´ıveis, considerando-se, assim, de menor relev ˆancia. iii. Caso o alvo seja um ficheiro de posse, permitindo acesso aos anteriormente referidos, C4vai garantir que apenas os own-f mais recentes sejam con-
siderados v ´alidos, negando substituic¸ ˜oes de ficheiros com timestamps mais antigos que o considerado aceit ´avel. Neste ´ultimo ponto, o intervalo tamb ´em deve ser avaliado e adaptado consoante as necessidades espec´ıficas ao sistema.
No caso da perda de confianc¸a num utilizador, ´e importante fazer uso dos mecanismos de revogac¸ ˜ao. Tendo em conta o tipo de revogac¸ ˜ao aplicada (4.3.2), se o utilizador comprome- tido tinha permiss ˜oes de leitura do ficheiro, este vai conseguir manter acesso at ´e a pr ´oxima alterac¸ ˜ao do mesmo (C3). Por outro lado, se o utilizador comprometido tinha permiss ˜oes
de leitura e de escrita sobre o ficheiro, este perde imediatamente a possibilidade de realizar alterac¸ ˜oes (C2).
O takeover do sistema acontece quando um utilizador pretende alterar os dados alterando a totalidade da hash tree para validac¸ ˜ao dos ficheiros de posse, essencialmente assumindo controlo do sistema de ficheiros. Este ataque ´e contrari ´avel quando o utilizador original se aperceber da situac¸ ˜ao, tipicamente durante uma das atualizac¸ ˜oes peri ´odicas. Apesar do sistema n ˜ao proteger diretamente este ataque, este s ´o funciona quando os utilizadores n ˜ao tiverem noc¸ ˜ao do verdadeiro owner dos ficheiros a serem acedidos.
Mesmo assumindo que o utilizador vai tentar proteger as chaves que possui, ´e sensato avaliar as consequ ˆencias de uma poss´ıvel falha. Para tal, vamos assumir que o Bob ´e o utilizador malicioso que obteve esta nova chave da Alice. Caso o Bob obtenha a chave de um dos ficheiros da Alice, este vai conseguir aceder aos dados do mesmo, sendo esta uma consequ ˆencia semelhante `a da necessidade de revogac¸ ˜ao de acesso a um utilizador com permiss ˜oes de leitura (C3). Caso o Bob obtenha a chave mestra privada de cifragem, este
vai conseguir ter acesso a todos os ficheiros aos quais tinha acesso a Alice, atribuindo- se permiss ˜oes de leitura sobre todos esses ficheiros, sendo necess ´aria uma revogac¸ ˜ao em massa da informac¸ ˜ao partilhada com a Alice (C3). Caso o Bob ganhe acesso `a chave
mestra de assinatura da Alice, apesar de n ˜ao conseguir ler a informac¸ ˜ao armazenada, passa a conseguir alterar esses ficheiros, atribuir permiss ˜oes de escrita e revogar permiss ˜oes sobre os mesmos. Este resulta em consequ ˆencias semelhantes ao takeover do sistema de ficheiros, sem a facilidade de identificac¸ ˜ao do advers ´ario.
A corrupc¸ ˜ao de dados j ´a foi referida previamente como um problema que o sistema con- segue assinalar mas n ˜ao contornar. Adicionalmente, ´e realizada uma suposic¸ ˜ao quanto `a alterac¸ ˜ao dos dados significar corrupc¸ ˜ao e n ˜ao destruic¸ ˜ao (3.4). Sobre essa assunc¸ ˜ao, o utilizador consegue sempre ter feedback de poss´ıveis alterac¸ ˜oes acidentais.
Com a mesma justificac¸ ˜ao que a quebra de confidencialidade, caso o provedor n ˜ao consiga retirar informac¸ ˜ao dos criptogramas armazenados, n ˜ao ser ´a poss´ıvel que este divulgue a informac¸ ˜ao que possui para fins menos leg´ıtimos.
6.3.2
Validac¸ ˜ao dos requisitos
Na componente funcional, foi pretendido que os utilizadores conseguissem codificar e des- codificar as suas pastas, recuperando sempre a informac¸ ˜ao armazenada. Este ponto ´e at ´e ilustrado em6.5, sendo que a pasta resultante da sequ ˆencia de operac¸ ˜oes “codificar- descodificar” tem conte ´udo semelhante `a original. Desta forma, este requisito considera- se conseguido. Para al ´em disto, definiu-se como importante que os utilizadores conse- guissem partilhar os seus documentos e categorizar essas partilhas. addPermitions() e removePermitions() ,contempladas em 6.2.1, n ˜ao s ´o permitem que o utilizador estenda o acesso dos seus ficheiros a terceiros, como tamb ´em esperam receber uma opc¸ ˜ao que define o tipo de permiss ˜ao a receber: read-only ou read-write. O programa pode ainda ser alterado em pontos como PathToStore e em PathToKeys para permitir a configurabilidade pretendida.
As func¸ ˜oes de gerar, validar e refrescar hash tree, detalhadas emB, acedem `as necessida- des referidas na sec¸ ˜ao de requisitos operacionais, certificando-se que os ficheiros de posse n ˜ao s ˜ao alvos de ataques por rollback. De notar que estes m ´etodos correm num daemon em background sem o utilizador necessitar de interagir diretamente com o mesmo, tamb ´em indicado como requisito operacional.
A n´ıvel de requisitos de seguranc¸a, a validac¸ ˜ao vai ser realizada por partes, uma vez que depende das t ´ecnicas usadas. Como adic¸ ˜ao a este ponto, ´e aconselhado consultar a sec¸ ˜ao
• Confidencialidade dos ficheiros de dados ´e assegurada do lado do cliente, signifi- cando que em nenhum ponto da transmiss ˜ao/armazenamento dos dados estes se encontram decifrados. Dessa forma, a confidencialidade depende da seguranc¸a de- finida pelas t ´ecnicas de cifragem sim ´etricas dos dados (4.3.3) e pelas t ´ecnicas de cifragem assim ´etrica das chaves (2.2.4).
• A integridade dos ficheiros ´e garantida atrav ´es de assinaturas realizadas sobre os dados e, como tal, est ´a dependente da robustez das t ´ecnicas adotadas (2.2.4). • Uma vez que o servic¸o realiza medidas de seguranc¸a do lado do cliente, e que as
partilhas de ficheiros s ˜ao realizadas do lado do cliente, o controlo de acesso ´e inde- pendente do servic¸o remoto a utilizar.
• A revogac¸ ˜ao de permiss ˜oes ´e permitida no sistema, como foi referido na componente funcional, e os seus efeitos ocorrem o mais r ´apido poss´ıvel, atendendo `a metodologia aplicada (4.3.2).
• Utilizando CL-PKE, a comunicac¸ ˜ao externa ´e limitada `a transmiss ˜ao das chaves p ´ublicas entre utilizadores e ao processo de gerac¸ ˜ao de chaves (2.2.4)
• Como explicado em6.1.3, cada utilizador apenas tem de armazenar duas chaves pri- vadas, conseguindo-se assim reduzir o espac¸o de armazenamento exigido ao cliente. Desta forma, foram abordados e atendidos todos os requisitos apresentados na sec¸ ˜ao an- terior, atendendo `as assunc¸ ˜oes relativas `a seguranc¸a do sistema (3.4).