Prova de Resposta Pontual
Prova de Resposta Pontual
no Acesso ao Armazenamento Contratado na Periferia da Rede
Xxxx Xxxxxx, Cl´audio Xxxxxxx, Xxxxxx Xxxxxxx e Xxxxx Xxxxxxxxx
INESC-ID, Instituto Superior T´ecnico, U. Lisboa
{xxxx.xxxxxx,xxxxxxx.xxxxxxx,xxxxxx.x.xxxxxxx,xxx}@xxxxxxx.xxxxxxx.xx
Resumo Este trabalho aborda o problema de auditar remotamente um n´o que fornece servi¸cos de armazenamento, com o objectivo de asse- gurar que este consegue servir pedidos de leitura com uma latˆencia maxima contratada. Prop˜oe-se uma nova prova de armazenamento para este efeito, a que chamamos Prova de Resposta Pontual, que explora a existˆencia de ambientes de execuca˜o confi´aveis para evitar revelar pre- maturamente quais os ficheiros que ser˜ao alvo da auditoria, de forma a evitar que o n´o auditado possa escolher previamente quais os ficheiros que armazena ou que delegue a execu¸c˜ao do teste num outro servidor. O artigo apresenta uma avalia¸c˜ao experimental que sustenta a parame- triza¸cao do teste e que mostra que o resultado da auditoria ´e fi´avel.
1 Introdu¸c˜ao
Existem hoje v´arias situa¸c˜oes em que um utilizador ou uma organiza¸c˜ao usa o servi¸cos de armazenamento de dados, de forma a obter garantias de durabilidade, disponibilidade, ou para permitir que clientes consigam aceder aos dados com baixa latˆencia. Exemplos relevantes incluem o armazenamento na nuvem (por exemplo, Dropbox, iClould, Google Drive, entre outros), armazenamento entre- pares (por exemplo, os servi¸cos de armazenamento usados pela Blockchain [18]), redes de distribui¸c˜ao de conteu´do (por exemplo, Akamai) e, mais recentemente, servi¸cos de armazenamento na periferia da rede [19]. A computa¸c˜ao na periferia da rede ´e um modelo de computa¸c˜ao distribu´ıda que recorre a servidores colo- cados fisicamente pr´oximos dos utilizadores finais para executar tarefas que n˜ao podem ser executadas por dispositivos com recursos limitados, mas que neces- sitam de ser executadas com baixa latˆencia. Para suportar a execu¸c˜ao pontual destas tarefas os servidores podem necessitar de armazenar dados localmente.
Neste contexto, o cliente do servi¸co de armazenamento espera que o for- necedor respeite n´ıveis de servi¸co previamente acordados tais como a garantia que os dados n˜ao ser˜ao apagados nem adulterados, que ser˜ao armazenados de forma tolerante a faltas e que ser˜ao servidos a quem os solicitar de forma pon- tual. Infelizmente, um prestador de servi¸cos de armazenamento racional [11,9,5] pode preferir violar algumas destas garantias para obter proveitos adicionais, em
particular se conseguir que o desvio ao comportamento contratado passe desper- cebido. Por exemplo, pode manter menos c´opias dos dados do que as solicitadas, de forma a poupar recursos, uma vez que pode ser dif´ıcil ou mesmo imposs´ıvel para o cliente confirmar que o nu´mero desejado de r´eplicas est´a a ser mantido pelo fornecedor. Este cen´ario tem motivado o desenvolvimento de mecanismos de auditoria, capazes de extrair provas de armazenamento, isto ´e, evidˆencias de que o fornecedor de armazenamento est´a a cumprir (ou violar) o servi¸co contratado. Neste artigo abordamos o desenvolvimento de um mecanismo de auditoria adaptado ao armazenamento na periferia da rede. Mais concretamente, pretende- mos verificar se um dado n´o consegue servir pedidos de leitura com uma latˆencia m´axima contratada. Prop˜oe-se uma nova prova de armazenamento para este efeito, a que chamamos Prova de Resposta Pontual, que explora a existˆencia de ambientes de execu¸c˜ao confi´aveis, como o Intel SGX, para evitar revelar pre- maturamente quais os ficheiros que ser˜ao alvo de auditoria. O artigo apresenta tamb´em uma avaliac¸˜ao experimental que sustenta a parametriza¸c˜ao do teste e
que mostra que o resultado da auditoria ´e fi´avel.
2 Armazenamento de Dados em Entidades Remotas
Existem v´arios cen´arios em que um utilizador pode optar por armazenar dados em m´aquinas controladas por outras entidades. Os trˆes principais exemplos s˜ao: o armazenamento entre-pares (P2P), o armazenamento na nuvem e o armaze- namento na periferia da rede. Usar fornecedores de servi¸cos de armazenamento pode trazer v´arias vantagens tais como a redu¸c˜ao de custos (devido `as economia de escala que grandes centros de dados conseguem alcan¸car), tolerˆancia a faltas (mantendo v´arias c´opias dos dados, possivelmente em diferentes localiza¸c˜oes ge- ogr´aficas) e baixa latˆencia no acesso aos dados (as c´opias podem ser colocadas em locais pr´oximos aos utilizadores). Por´em, este modelo tamb´em traz desafios, tendo em vista que o fornecedor do servi¸co de armazenamento (FSA) pode n˜ao cumprir o servi¸co contratado.
Armazenamento de Dados na Periferia. No caso do armazenamento na pe- riferia da rede a principal motiva¸c˜ao ´e poder servir os cliente com baixa latˆencia. Aplica¸c˜oes como processamento de imagem [17,8] ou indexa¸c˜ao de v´ıdeo em tempo real [16] necessitam de latˆencias abaixo dos 5—30 milissegundos [15], que n˜ao conseguem ser asseguradas com um modelo de armazenamento na nuvem. O modelo de armazenamento na periferia da rede consiste em colocar recursos com- putacionais mais pr´oximos dos utilizadores para evitar longos atrasos na rede. Esta estrat´egia ´e capaz de satisfazer os requisitos de baixa latˆencia impostos pelas novas aplica¸c˜oes. Os servidores na periferia da rede, tamb´em conhecidos por fog nodes ou cloudlets, que traduzimos para n´os de nevoeiro, complementam os servi¸cos de armazenamento na nuvem. No entanto, ´e expect´avel que os re- cursos destes servidores sejam limitados, sendo necess´ario uma escolha cuidada dos dados a´ı armazenados [10,12]. Para al´em disto, ´e previs´ıvel que exista um grande nu´mero de fornecedores de n´os do nevoeiro, o que levanta preocupa¸c˜oes
sobre a confian¸ca dos seus servi¸cos [6]. Como a capacidade dos n´os de nevoeiro
´e limitada, os fornecedores de armazenamento na periferia podem ser tentados a vender mais armazenamento do que aquele que realmente possuem. Tal com- portamento pode ser ocultado recorrendo `a nuvem para armazenar os dados, e apenas obter estes dados remotos quando um utilizador os solicita, comprome- tendo o objectivo de baixa latˆencia.
Lidando com o Comportamento Racional. O uso de servi¸cos de armaze- namento tˆem o problema de ser dif´ıcil para o cliente verificar se as pol´ıticas contratadas de tolerˆancia a faltas e localiza¸c˜ao dos dados est˜ao a ser, de facto, aplicadas pelo fornecedor do servi¸co. Em particular, os fornecedores de armaze- namento na periferia da rede podem ter incentivos em manter apenas algumas copias dos dados nos n´os de nevoeiro, para poderem aumentar a quantidade de armazenamento que podem vender, penalizando a latˆencia que os clientes obser- vam no acesso aos dados. Este tipo de comportamento racional pode ser evitado com o recurso a mecanismos de auditoria que sejam capazes de aferir se o ar- mazenamento remoto respeita o nu´mero de c´opias e a sua localiza¸c˜ao. Quando a auditoria detecta um mau comportamento, este pode ser usado para penalizar o fornecedor, como por exemplo: num sistema entre-pares, um n´o parasita pode ser impedido de continuar a usar os servi¸cos fornecidos por outros n´os, e os fornece- dores de armazenamento na nuvem, ou na periferia da rede podem ser for¸cados a compensar os clientes por viola¸c˜oes do contrato estabelecido, conhecido por service level agreement (SLA).
3 Trabalho Relacionado
Provas de Armazenamento. A literatura ´e rica em t´ecnicas que permitem obter diferentes provas de armazenamento, que aferem diferentes propriedades do servico de armazenamento prestado. As mais relevantes s˜ao as Provas de Posse de Dados (PDP) [3] e as Provas de Recupera¸c˜ao (PoRet) [2], que permi- tem verificar se o fornecedor possui pelo menos algumas c´opias dos dados, Provas de Replica¸c˜ao (PoRep) [2] que permitem verificar se o fornecedor possui n c´opias dos dados (embora estas possam estar todas armazenadas na mesma m´aquina), e as Prova de Replica¸c˜ao Geogr´afica (PoGR) [4,11], que permitem verificar que o fornecedor n˜ao s´o possui n c´opias dos dados, mas que estas est˜ao armazenadas em m´aquinas diferentes e/ou em localiza¸c˜oes espec´ıficas. Todas estas provas se baseiam na constru¸c˜ao de desafios que s˜ao colocados ao fornecedor de armaze- namento por um ou mais n´os auditores. Como veremos de seguida, tipicamente um desafio obriga o fornecedor a executar opera¸c˜oes de leitura sobre um sub- conjunto dos dados armazenados e a retornar atempadamente um valor que comprova que leu os dados correctos (por exemplo, uma s´ıntese criptogr´afica dos valores lidos).
Estrutura dos Desafios. Uma maneira simples de confirmar que um fornece-
xxx possui um ficheiro seria solicitar a sua transferˆencia e confirmar a integridade do ficheiro devolvido. No entanto, a obten¸c˜ao de uma prova por este processo seria dispendiosa, pois obrigaria o fornecedor e o auditor a consumirem bastante largura de banda. Para evitar este custo, a maioria dos desafios obriga o forne- cedor a ler diferentes por¸c˜oes de um conjunto variado de ficheiros e a devolver uma s´ıntese criptogr´afica dos valores lidos. Tipicamente, a resposta tem de ser produzida dentro de um tempo pr´e-definido, calculado pelo auditor [4,11,5]. Para al´em disso, a lista dos ficheiros a ler n˜ao dever´a ser revelada na sua totalidade, aquando o envio do desafio, mas sim revelada de forma interactiva [11], de forma a que o n´o auditado s´o conhe¸ca o pr´oximo ficheiro a ler depois de ler o anterior. Isto impede que o fornecedor v´a obter os conteu´dos em falta no momento de responder ao desafio. Se o fornecedor n˜ao puder adivinhar antecipadamente os valores lidos, ter´a que manter os ficheiros localmente para responder correcta- mente e atempadamente.
Para garantir que o fornecedor mant´em v´arias c´opias dos dados, alguns au- tores obrigam o cliente a armazenar mu´ltiplas c´opias do mesmo ficheiro, cifradas com chaves distintas [2], `as quais o fornecedor n˜ao tem acesso. Na pr´atica, cada r´eplica tem de ser tratada como um ficheiro distinto, que tem de ser mantido pelo fornecedor. Infelizmente, isto n˜ao impede que todas as r´eplicas sejam armazena- das na mesma m´aquina, o que pode comprometer a disponibilidade do ficheiro em casos de falhas. Para garantir que as r´eplicas s˜ao guardadas em m´aquinas distintas, o desafio pode ser concebido de forma a que seja imposs´ıvel responder atempadamente se todos os dados estiverem armazenados na mesma m´aquina, embora seja exequ´ıvel se a prova for produzida em paralelo [11].
Os mecanismos referidos acima n˜ao s˜ao suficientes para garantir que quem produz a prova se encontra num dada localiza¸c˜ao geogr´afica. Duas t´ecnicas dis- tintas foram sugeridas para atingir este objectivo. A primeira consiste em usar o tempo de resposta para extrapolar a localiza¸c˜ao do n´o auditado, uma vez que pode ser dif´ıcil ao fornecedor dar uma resposta atempada se os dados se encon- trarem numa localiza¸c˜ao geograficamente distante, devido `a latˆencia da rede. A utiliza¸c˜ao de diferentes auditores, em posi¸c˜oes diferentes, pode aumentar a pre- cis˜ao deste mecanismo, recorrendo a t´ecnicas de triangula¸c˜ao [5,9]. A segunda consiste em recorrer a ambientes de execu¸c˜ao confi´aveis para garantir que algu- mas das opera¸c˜oes necess´arias para a produ¸c˜ao da prova s˜ao executadas numa m´aquina espec´ıfica [7]. Estes ambientes podem tamb´em facilitar a divulga¸c˜ao interactiva do desafio.
4 Prova de Resposta Pontual
Neste trabalho definimos uma Prova de Resposta Pontual (PdRP) como uma prova de armazenamento que permite obter evidˆencias de que o fornecedor con- segue aceder aos documentos armazenados com uma latˆencia m´axima δ (tipi- camente baixa). Como aplica¸c˜oes na periferia da rede necessitam de respostas dentro de 5-30 milissegundos [15] no nosso trabalho, usamos valores de δ desta magnitude.
4.1 Pressupostos Para a Constru¸c˜ao do Desafio
Como descrito na Sec¸c˜ao 3, o m´etodo mais eficaz para a obten¸c˜ao de provas de armazenamento corresponde `a execu¸c˜ao de um ou mais desafios. Desta forma, a obten¸c˜ao de uma prova de resposta pontual baseia-se, igualmente, na execu¸c˜ao de um desafio, que descrevemos em seguida.
No nosso trabalho, assumimos que o servi¸co de armazenamento a executar na nuvem ´e de confian¸ca para os clientes, e que os servi¸cos de armazenamento na periferia podem ter um comportamento desonesto para poupar custos e recursos. Como os dados replicados na periferia s˜ao, em primeira instˆancia, geridos pela nuvem, assumimos que a nuvem replica todos os dados em cada n´o de nevoeiro, mas ´e da inteira responsabilidade do servi¸co de armazenamento na periferia da rede distribuir esses dados pelos respectivos n´os de nevoeiro.
Tamb´em assumimos que cada n´o de nevoeiro possui um processador com a extens˜ao Intel SGX: aproveitamos as garantias fornecidas pelo ambiente de execu¸c˜ao confi´avel para suportar a realiza¸c˜ao do desafio. O ambiente de execu¸c˜ao confi´avel, nomeadamente o enclave, ´e um ambiente de execu¸c˜ao isolado que ga- rante integridade e confidencialidade do c´odigo e dos dados dentro do enclave [6]. Quando o enclave ´e inicializado, ´e executada a atestac¸˜ao para autentic´a-lo rela- tivamente ao auditor e ´e realizada uma troca de segredos: uma chave sim´etrica diferente para cada n´o de nevoeiro e as fun¸c˜oes pseudo-aleat´orias a usar.
4.2 Localiza¸c˜ao do Auditor
Neste trabalho opt´amos por desenhar um desafio que pudesse ser usado por um n´o auditor centralizado, que n˜ao est´a necessariamente localizado na proximidade do n´o de nevoeiro a ser auditado, mas que tem acesso a um modelo do atraso da rede entre os dois n´os. Esta op¸c˜ao foi motivada pelas seguintes observa¸c˜oes. Como os n´os a serem auditados s˜ao em elevado nu´mero e est˜ao colocados na periferia da rede, colocar um auditor perto de cada um pode ser impratic´avel. Em alternativa, seria poss´ıvel solicitar aos pr´oprios clientes que partilhassem os tempos de resposta observados. Assumindo que os clientes n˜ao adulteravam os dados reportados, isto permitiria obter informa¸c˜ao fidedigna do desempenho do fornecedor. No entanto, esta alternativa levanta problemas, pois, a partir dos dados reportados, seria poss´ıvel extrair informa¸c˜ao sobre o comportamento dos utilizadores, colocando em risco a sua privacidade [13]. Outra alternativa, con- siste em recorrer ao enclave para criar o desafio e, simultˆaneamente, medir o tempo de resposta. Por´em, a opera¸c˜ao de leitura do rel´ogio seguro, pelo SGX, demora dezenas de milissegundos e ´e vulner´avel a atrasos induzidos pelo ambi- ente envolvente (n˜ao seguro) [1]. Desta forma, n˜ao ´e vi´avel recorrer ao enclave para medir o tempo de resposta. A utiliza¸c˜ao do enclave aqui proposta, n˜ao de- pende do comportamento no tempo, mas garante que o desafio ´e efectivamente executado na m´aquina pretendida. Uma das limita¸c˜oes de lan¸car o desafio a partir de um n´o central, possivelmente distante do n´o a ser auditado, ´e que a varia¸c˜ao da latˆencia na rede entre os dois n´os ir´a introduzir um erro na estima- tiva do tempo de resposta. Mais `a frente apresentamos uma metodologia para configurar o desafio, de forma a obter resultados com um erro limitado.
4.3 Desenho do Desafio
O desafio requer que o n´o de nevoeiro aceda a um nu´mero de objectos, em sequˆencia, e que retorne um valor que depende dos valores lidos. Os objectos a serem lidos num dado desafio s˜ao apenas revelados ao n´o auditado, interactiva- mente, `a medida que o desafio ´e executado. Isto ´e poss´ıvel, pois recorremos `a utiliza¸c˜ao do enclave e garantimos que apenas o enclave pode fornecer o pr´oximo objecto e apenas o faz ap´os o objecto anterior ser lido. A rapidez com que o n´o auditado responde a este desafio permite estimar o tempo de leitura δ observado pelo fornecedor no acesso aos dados.
Tal como no trabalho relacionado, pressupomos que o auditor tem conhe- cimento completo dos dados armazenados pelo n´o auditado (quais os ficheiros, assim como o tamanho e conteu´do dos mesmos). Isto permite fazer uma pro- jec¸c˜ao l´ogica e determinista dos dados armazenados num vector de blocos de tamanho pr´e-definido. O tamanho destes blocos ´e um parˆametro de configura¸c˜ao do desafio e, tipicamente, um mu´ltiplo do tamanho do bloco usado no sistema de ficheiros. Desta forma, quando o desafio refere o bloco i deste vector, todos os participantes conseguem converter este ´ındice num bloco concreto de um ficheiro. O desafio consiste em obrigar o n´o auditado a ler uma sequˆencia pseudo- aleat´oria e imprevis´ıvel deste blocos, de comprimento N , e retornar uma s´ıntese criptogr´afica de todos os valores lidos. O tamanho N desta sequˆencia ´e outro dos parˆametros de configura¸c˜ao do desafio. Quanto maior o N mais precisa, mas menos eficiente, ser´a a prova. Posteriormente, mostramos como escolher o valor
de N para assegura que o resultado do desafio tem a fiabilidade desejada.
A sequˆencia pseudo-aleat´oria de blocos a aceder no desafio d ´e constru´ıda recorrendo a um nu´mero u´nico (nonce em inglˆes) e ao conteu´do dos blocos lidos. O nu´mero u´nico ηd, diferente em cada desafio, ´e gerado pelo auditor e enviado de forma segura juntamente com o nu´mero de blocos N a serem lidos para enclave do n´o a ser auditado. Este, por sua vez usa a s´ıntese criptogr´afica do nu´mero u´nico (h(ηd)), para seleccionar o ´ındice do vector de blocos, correspondendo ao primeiro bloco a ser lido. Ap´os ler esse bloco, o n´o auditado calcula uma s´ıntese criptogr´afica sobre o bloco e retorna este valor para o enclave. Para determinar o ´ındice do pr´oximo bloco, o enclave recorre a uma fun¸c˜ao pseudo-aleat´oria, que usa como entrada o nu´mero u´nico ηd e a s´ıntese criptogr´afica, de tamanho constante, do conteu´do dos blocos anteriormente lidos, devolvendo novamente este valor ao n´o auditado. Esta interac¸c˜ao acontece N vezes, e como a s´ıntese criptogr´afica depende do conteu´do lido e da s´ıntese h(ηd), diferente em cada desafio, o n´o auditado ´e impedido de pr´e-calcular respostas aos desafios ou de recorrer a uma m´aquina externa (na nuvem ou na periferia) para executar o desafio na sua totalidade.
4.4 Configura¸c˜ao do Desafio
Designe-se por Ti o tempo que decorre entre o auditor enviar o desafio i e receber uma resposta do n´o auditado. Este tempo, pode ser decomposto na soma de
v´arios factores, nomeadamente:
Ti = rtti + α1 + . . . + αN + δ1 + . . . + δN
(1)
i i i i
i
i
em que rtti ´e o tempo de ida-e-volta na rede (do inglˆes, roundtrip time) verificado durante a execu¸c˜ao do desafio, N ´e o nu´mero de blocos a serem lidos, αj o tempo necess´ario para a executar a func¸˜ao de s´ıntese criptogr´afica sobre o conteu´do do bloco j e computar o pr´oximo bloco a ler e δj o atraso na leitura do bloco j. Note-se que, para valores suficientemente grandes de N , vamos ter:
i i
α1 + . . . + αN N
= αi ≈ α (2)
δ 1 + . . . + δN N
= δi ≈ δ (3)
i i
Como os valores de rtti, αi, e δi s˜ao desconhecidos (e diferentes em cada desafio i), na estimativa de δ, a partir do valor observado de Ti, consideramos os valores m´edios:
δestimado =
Ti rtt Nα
− −
(4)
N
O erro desta estimativa depende da diferen¸ca entre os valores reais obser- vados durante a execu¸c˜ao do desafio e os valores m´edios. Experimentalmente, observ´amos que os valores de α variam pouco, pelo que assumimos que αi = α, ou seja, descartamos o erro induzido pela amostragem de α. Assim, o erro da estimativa δestimado ´e dominado por dois factores: i) pelo erro εδ no c´alculo de δ (que depende do tamanho da amostragem) e ii) pelo desvio do tempo de ida-e- volta observado (rtti) em relac¸˜ao ao tempo m´edio esperado (rtt), dilu´ıdo pelas N amostras tal como descrito pela Equa¸c˜ao 5:
εrtt =
rtti − rtt =
∆rtt N
(5)
N
Para configurar o desafio o utilizador deve fornecer dois parˆametros: o erro
max
m´aximo εδ
que est´a disposto a tolerar na estimativa de δ e a fiabilidade φ pre-
max
tendida para o desafio, isto ´e, a probabilidade do desafio retornar uma estimativa
de δ com um erro inferior a εδ
. A escolha do valor de N ´e feita com base nos
dois parˆametros acima, recorrendo ao conhecimento pr´evio da distribui¸c˜ao do
tempo de ida-e-volta entre o auditor e o n´o auditado e ao conhecimento sobre a distribui¸c˜ao dos atrasos na leitura dos blocos.
A partir do valor φ, pretendido para a fiabilidade, usa-se a fun¸c˜ao inversa da distribuic¸˜ao cumulativa para calcular a diferen¸ca do pior caso expect´avel entre o rtti observado e o valor m´edio rtt e, a partir da diferen¸ca entre estes dois valores, designada por ∆rtt, determinamos o valor de N , que coloca o erro da estimativa
max
do rtti abaixo de um certo valor εrtt
. Por outro lado, a partir da distribui¸c˜ao
dos atrasos na leitura dos blocos, usando a curva de aprendizagem ´e tamb´em
max
poss´ıvel calcular o valor m´aximo εδi da diferen¸ca entre a m´edia δi que resulta
da amostragem e a m´edia real δ. O valor de N deve ent˜ao ser escolhido de forma
max
a que εrtt
δi
+ ε
max
< ε
δ
max.
5 Avalia¸c˜ao
Para avaliarmos a precis˜ao da prova de resposta pontual, mont´amos uma ban- cada experimental com um n´o auditor e um n´o de armazenamento com acesso a dois sistemas de ficheiros, um local e um remoto (recorremos a um segundo n´o de armazenamento para alojar o sistema de ficheiros remoto). O n´o de armazena- mento ´e configurado para manter todos os ficheiros localmente ou remotamente. Recorremos ao emulador NetEm (Network Emulator ) disponibilizado pelo Ubuntu para introduzir artificialmente atrasos na rede de acordo com uma dada distribui¸c˜ao. Isto permite controlar o comportamento da rede entre o auditor e o n´o auditado, e a rede no acesso aos ficheiros remotos no n´o de armazenamento. Variando o tempo m´edio de acesso aos dados no n´o auditado, assim como a latˆencia da rede entre o auditor e o n´o auditado, podemos criar v´arios cen´arios para a obten¸c˜ao da prova de resposta pontual. Para cada um destes cen´arios, podemos observar a diferen¸ca entre o tempo de acesso estimado e o tempo de
acesso real e, desta forma, aferir a precis˜ao da prova por n´os proposta.
5.1 Configura¸c˜ao e Desempenho do N´o de Armazenamento
O n´o de armazenamento consiste numa m´aquina Intel NUC7i7DNKE, com um CPU Intel i7-8650U (com SGX), 8 GB de RAM e 250GB de SSD M.2 a executar Ubuntu 20.04.2 LTS. A m´aquina do n´o de armazenamento tem acesso a dois sistemas de ficheiros, um local, e outro remoto, que ´e acedido atrav´es do Se- cure Shell FileSystem (SSHFS). O sistema de ficheiros remoto executa-se numa m´aquina idˆentica `a do n´o de armazenamento. As duas m´aquinas est˜ao fisica- mente interligadas por um comutador com uma latˆencia m´edia de 0.7ms, mas, como referimos anteriormente, usamos o NetEm para artificialmente aumentar a latˆencia entre estes dois n´os e, para avaliar a nossa prova em diferentes cen´arios. Para emularmos os diferentes cen´arios, que descreveremos mais `a frente, con- figur´amos o NetEm para seguir uma distribui¸c˜ao normal com um determinado valor m´edio µ e desvio padr˜ao σ. Os valores de µ e σ resultam do ajuste, a uma distribui¸c˜ao normal, de medi¸c˜oes dos tempos de ida-e-volta em redes reais,
capturadas recorrendo `a execu¸c˜ao do ping entre as m´aquinas consideradas.
Para al´em disto, opt´amos por usar fragmentos de 64K bytes 1, por verificar- mos que a variˆancia ´e suficientemente reduzida (0.8ms para um tempo m´edio de 1.6ms). Popul´amos o sistema de ficheiros com um conjunto 520184 imagens [14] com tamanhos entre 846B e 180KB. Quando o n´o auditado ´e obrigado a ler um ficheiro com tamanho inferior a 64K, este completa o resto dos dados com 0, at´e aos 64K. A partir da s´ıntese criptogr´afica calculada sobre fragmento de 64K ´e escolhido o pr´oximo ficheiro a ler.
Para conhecer o tempo m´edio de s´ıntese α medimos, para blocos de 64KB, o tempo de c´alculo da s´ıntese criptogr´afica, juntamente com a s´ıntese criptogr´afica de tamanho 32B, gerada na itera¸c˜ao anterior, e verific´amos um valor m´edio α = 0.8ms. Recorremos `a fun¸c˜ao SHA256 para o c´alculo da s´ıntese criptogr´afica e ao algoritmo Xxxxxxxx XXX-XXX 000xxxx para cifrar o nu´mero u´nico.
1 Um mu´ltiplo de 4K, o tamanho dos blocos usado pelo sistema de ficheiros.
os | ||||||
TAA | TAT | TAL | LAA | LAT | LAL | |
Localiza¸cao | Auditor | Taguspark Taguspark Taguspark Londres Londres Londres Alameda Alameda Alameda Alameda Alameda Alameda Alameda Taguspark Londres Alameda Taguspark Londres | ||||
Auditado | ||||||
Armazenamento | ||||||
Tabela 1: Cen´arios da rede entre os n´os para avalia¸c˜ao.
5.2 Cen´arios da Avalia¸c˜ao
Agora apresentamos as redes e os cen´arios utilizados na nossa avalia¸c˜ao, onde para cada tipo de rede, alter´amos a localiza¸c˜ao do auditor e a localiza¸c˜ao do sistema de ficheiros. Desta forma, tivemos em conta duas redes reais. A primeira entre o n´o de armazenamento no nosso laborat´orio na Alameda e uma m´aquina no campus Taguspark, pertencente `a Universidade de Lisboa. A segunda rede entre, mais uma vez, o n´o de armazenamento na Alameda e uma m´aquina no centro de dados da Google em Londres. Consider´amos o centro de dados em Londres, por corresponder ao centro de dados mais perto (em latˆencia) de Lisboa. A partir do ping, amostr´amos o tempo de ida-e-volta na rede para cada uma das redes anteriores e ajust´amos os valores observados a uma distribui¸c˜ao normal, a partir da qual calcul´amos os respectivos valores m´edios e desvio padr˜ao. A rede Alameda-Taguspark pode ser descrita por uma distribui¸c˜ao normal com um tempo m´edio de ida-e-volta na rede de 8ms (µ = 8ms). A rede Alameda-Londres, por sua vez, pode ser descrita pela distribui¸c˜ao normal com valor m´edio de ida- e-volta na rede de 34.5ms (µ = 34.5ms). Para o desvio padr˜ao introduzimos no NetEm os valores σ = 0.1ms e σ = 2ms, para Alameda-Londres e Alameda- Taguspark, respectivamente. Curiosamente, observ´amos que, de acordo com os valores capturados, a rede entre a Alameda-Taguspark est´a sujeito a uma maior
varia¸c˜ao (mais inst´avel) do que a rede Alameda-Londres.
Tendo em conta as duas redes anteriores, avali´amos o nosso sistema nos diferentes cen´arios descritos na Tabela 1, em que alternamos a localiza¸c˜ao do auditor e do sistema de ficheiros entre o Taguspark e Londres, com o n´o audi- tado localizado, em todos os cen´arios, na Alameda. Recorremos ao NetEm para configurar o tempo m´edio de ida-e-volta entre as trˆes m´aquinas, consoante a rede considerada para a liga¸c˜ao entre auditor-auditado e o auditado-armazenamento. Note que, quando o armazenamento se encontra na Alameda isto representa um comportamento honesto por parte do n´o auditado.
5.3 Configura¸c˜ao do Desafio
Na configura¸c˜ao de um desafio, o factor principal ´e a escolha do nu´mero de fragmentos N a ler. Como vimos na Sec¸c˜ao 4.4, o valor de N vai afectar o erro
max
de estimativa εδ
assim como a fiabilidade φ do desafio. Estes dois indicadores
s˜ao influenciados por dois factores: i) a rede entre o auditor e o n´o auditado (quanto mais inst´avel for a rede maior ser´a o erro e menor a fiabilidade); ii) a distribui¸c˜ao do tempo de acesso aos dados no n´o auditado (quanto mais vari´avel for esta distribui¸c˜ao, maior ser´a o erro e menor a fiabilidade). No entanto, como o erro que resulta do atraso na rede entre o auditor e o n´o auditado ´e dilu´ıdo
Figura 1: As v´arias latˆencias poss´ıveis no acesso a dados na periferia da rede. Ld ´e o limiar de detec¸c˜ao, Laex ´e a latˆencia expect´avel e Lain ´e a latˆencia inaceit´avel.
pelo nu´mero N de blocos (Equa¸c˜ao 5), a distribui¸c˜ao do tempo de acesso aos dados acaba por ser o factor preponderante para o erro da estimativa.
Como os n´os correctos possuem os dados localmente, exibem um tempo de acesso aos dados mais est´avel do que os n´os racionais. Isto significa que para um dado valor de N , vamos aproximar com maior qualidade o desempenho dos n´os correctos do que o desempenho dos n´os racionais. Ou seja, iremos conseguir ter uma taxa de falso positivos (FP) mais baixa do que a taxa de falsos negativos (FN). Na pr´atica, escolhemos um N que ofere¸ca valores aceit´aveis de FP e FN. Consideramos primeiro a rela¸c˜ao entre N e a taxa de falsos positivos (FP), isto ´e, a probabilidade de n´os correctos serem assinalados como racionais. Nesta an´alise consideramos o caso em que a rede entre o auditor e o n´o auditado ´e inst´avel. Como foi referido anteriormente, um n´o correcto acede aos dados com um tempo m´edio de 1.6ms e com baixa variˆancia. Neste cen´ario, verific´amos experimentalmente que usando N = 1000, conseguimos ter um erro m´aximo
δ
ε
max
< 1ms com uma taxa de falsos positivos inferior a 0.01%, o que nos permite
colocar o limitar de detecc¸˜ao de um n´o racional no valor de 2.6ms tal como se
Consideramos agora o caso do n´o auditado ser racional. O pior cen´ario ocorre quando os dados usam uma rede inst´avel. Consideramos por isso uma rede entre o n´o auditado e o armazenamento semelhante `a da rede Taguspark-Alameda. Neste caso, ao usarmos N = 1000 garantimos que o nosso teste consegue detectar um n´o racional se a latˆencia m´edia observada por este for superior a Lain =
2.6 + 2.2 = 4.8ms, com uma taxa de falsos negativos inferior a 0.05% ao se usar o limiar de detec¸c˜ao de 2.6ms tal como referido acima.
5.4 Resultados
Execut´amos o desafio, configurado com N = 1000 (tal como descrito na sec¸c˜ao anterior), em diferentes cen´arios, nomeadamente para os cen´arios TAA, TAT e TAL. Limit´amos-nos a correr o desafio em cen´arios em que a rede entre o auditor e o n´o auditado ´e semelhante `a rede Taguspark-Alameda, por se tratar de uma rede mais inst´avel do que a rede Londres-Alameda, capturando a situa¸c˜ao menos favor´avel para o auditor. Para cada um dos cen´ario, execut´amos o desafio 500 vezes. A Figura 2 apresenta a distribui¸c˜ao dos valores estimados.
Os valores estimados pelo nosso desafio s˜ao bastante aproximados ao valor m´edio observado no n´o a ser auditado (32.6ms para o cen´ario TAT e 120.3ms
Ld Lain
32.6ms
120.3ms
0% dados remotos (cenário TAA) 100% dados remotos (cenário TAProx) 100% dados remotos (cenário TAT) 100% dados remotos (cenário TAL)
Número de Medições
300
200
100
0
0 20 40 60 80 100 120 140
Estimativa do Tempo de Leitura (ms)
Figura 2: Estimativas do tempo de leitura δ, em milissegundos, pelo auditor, para diferentes localiza¸c˜oes do sistema, com rede Taguspark-Alameda entre auditor e o n´o auditado. Em que Ld e Lain correspondem ao limiar de detec¸c˜ao e `a latˆencia inaceit´avel, respectivamente.
para o cen´ario TAL). Note-se que a latˆencia observada no n´o auditado ´e cerca de 4x superior `a latˆencia m´edia da rede. Isto deve-se ao facto do SSHFS realizar v´arias chamadas remotas (correspondentes ao open, lseek, read, etc) para exe- cutar uma leitura. Por´em, confirma-se que o auditor consegue estimar um valor m´edio de leitura muito pr´oximo do valor verificado na realidade.
Nestes cen´arios, quando o n´o ´e racional a latˆencia m´edia observada ´e muito superior ao limiar Lain = 4.8ms, pelo que os n´os racionais foram sempre de- tectados. De facto, nos 500 testes feitos n˜ao ocorreram nem falso positivos nem falsos negativos (recordamos que a probabilidade estimada de ocorrer um falso positivo ´e inferior a 0.01%).
Uma vez que nos cen´arios anteriores os valores do tempo de acesso est˜ao bas- tante afastados do limiar Lain, test´amos tamb´em o cen´ario em que o n´o de arma- zenamento externo est´a na mesma rede do n´o auditado (isto ´e, sem acrescentar artificialmente qualquer latˆencia entre o n´o auditado e o n´o de armazenamento). Xxxxxxx´amos que, neste cen´ario, o tempo m´edio de leitura ´e cerca de 7ms, ainda superior ao Lain. Desta forma, a nossa prova consegue detectar um n´o deso- nesto mesmo que os dados estejam colocados perto do n´o auditado. Na Figura 2 este cen´ario est´a representado pelo cen´ario de proximidade (Cen´ario TAProx). Neste caso, mesmo com 500 experiˆencias tamb´em n˜ao observ´amos nenhum falso negativo.
6 Conclus˜oes e Trabalho Futuro
Neste trabalho propomos e avaliamos uma nova prova de armazenamento que consegue estimar o atraso no acesso aos dados no n´o auditado. A prova recorre a um desafio que obriga o n´o auditado a aceder a N amostras, que s˜ao reveladas de forma iterativa. Mostr´amos experimentalmente que ´e poss´ıvel configurar o desa- fio de forma a reduzir os erros que resultam de se usar apenas uma amostragem dos dados e da rede entre o auditor e o n´o auditado ter uma latˆencia vari´avel. Na vers˜ao actual, a configura¸c˜ao do desafio considera que, quando o n´o ´e raci- onal, todos os dados est˜ao remotos e s˜ao lidos atrav´es do SSHFS. No entanto, o n´o auditado pode seguir estrat´egias mais sofisticadas, como manter apenas
uma frac¸c˜ao dos dados remotamente, o que resulta em distribui¸c˜oes do tempo de acesso mais complexas, ou ler os ficheiros e calcular a respectiva s´ıntese crip- togr´afica no n´o remoto. O m´etodo para configurar o desafio para estes cen´arios
´e trabalho em curso.
Agradecimentos: Este trabalho foi suportado pela FCT – Funda¸c˜ao para a Ciˆencia e a Tecnologia, atrav´es da bolsa 0000.00000.XX e dos projectos UIDB/50021/2020 e COSMOS (financiado pelo OE com a ref. PTDC/EEICOM/29271/2017 e pelo Programa Operacional Regional de Lisboa na sua componente FEDER com a ref. Lisboa-01-0145-FEDER-029271).
Referˆencias
1. Xxxxx, X., Xxxxxx, X., Xxx, X., Xxxxxxxxxx, M.: Securing time in untrusted opera- ting systems with timeseal. In: RTSS (2019)
2. Xxxxxxxxx, X., Xxxxxx, X., Xxxxx, X., Xxxxxx, G.: Mirror: Enabling proofs of data
replication and retrievability in the cloud. In: USENIX Security (2016)
4. Xxxxx, X., et al.: Proof of replication. Tech. rep., Protocol Labs Research (2017)
6. Xxxxxxx, X., Xxxxxxx, M., Xxxxxxxxx, L.: Omega: a secure event ordering service for
the edge. In: DSN (2020)
8. Drolia, U., Xxx, K., Xxx, X., Xxxxxx, X., Xxxxxxxxxx, P.: Xxxxxxx: Edge-caching
for recognition applications. In: ICDCS. pp. 276–286. Atlanta (GA), USA (2017)
00. Xxxxxx, X., Xxxxx, X., Xxxxx, X., Xxxxxxxxx, X.: Towards enabling novel edge-
enabled applications. arXiv preprint arXiv:1805.06989 (2018)
11. Xx, X., Xxxxx, L.: Proofs of physical reliability for cloud storage systems. IEEE Transactions on Parallel and Distributed Systems 31(5) (2020)
12. Xxx, X., Xxxx, X., Xxxx, X., Xxxx, K., Xxx, G.: Dats: Dispersive stable task
scheduling in heterogeneous fog networks. IEEE Internet of Things Journal (2018)
13. Xxxxx, X.: What GDPR will mean for companies tracking location. xxxxx://xxxx. org/news/a/what-the-gdpr-will-mean-for-companies-tracking-location/ (2018), [Accessed: 2021-03-12]
14. Nari: tiles 256x49. xxxxx://xxx.xxxxxx.xxx/xxxxxxxxx/xxxxx-000x00?xxxxxxx
0005f7aaab2800f6170c399693a96917_14.png (2017), [Accessed: 2021-03-12]
15. Xxxxxx, X.: A city edge cloud with its economic and technical considerations. In: SmartEdge. IEEE, Kona (HI), USA (2017)
16. Xxxxxxxxxxxxxx, X., Xxxxxxx, X., Xxxxxxx, X., et al.: Cloudlet-based just-in-time
indexing of iot video. In: IEEE GIoTS. Geneva, Switzerland (2017)
18. Swarm: Storage and communication for a sovereign digital society. https://
xxxxxxxxxxx.xxxxxx.xx/xxxxx-xxxx/ (2019)
19. Xxxxx, X., Xxxxxxxx, X., Xxxx, X., Xxxxxx, X., Xxxxx, X., Xxxxxxx, X.: On multi- access edge computing: A survey of the emerging 5g network edge cloud architec- ture and orchestration. IEEE Communications Surveys Tutorials 19(3) (2017)