Escovamos bits com Diego Aranha na UNICAMP
E aprendemos muito sobre computação com dados cifrados para ambientes em nuvem
Diego Aranha é professor do Instituto de Computação (IC) e pesquisador do Laboratório de Segurança e Criptografia Aplicada (LASCA), da Unicamp.
Fora do meio acadêmico, seu nome é familiar para frequentadores de conferências de segurança da informação como o responsável por um importante estudo que demonstrou as vulnerabilidades da urna eletrônica brasileira. Recentemente ele foi reconhecido pela MIT Technology Review — revista de inovação do Massachussets Institute of Technology — como um dos pesquisadores com menos de 35 anos mais brilhantes do Brasil.
Tempos atrás, em uma edição do YSTS Pocket, Rafael Cruz — um estudante da Unicamp orientado por Diego — apresentou o resultado de uma pesquisa que analisava vulnerabilidades de apps bancários na plataforma Android para uma plateia de profissionais do mercado de segurança, com resultados muito positivos.
Conversamos com o Diego alguns dias após o evento sobre como em vários países, e de forma especial no Brasil, existe um abismo de distância entre a produção acadêmica e o mercado de segurança da informação. Ele não só concordou como propôs que nós visitássemos o IC e o LASCA para conhecer e divulgar o que está se produzindo de conhecimento na graduação e na pós-graduação.
A oportunidade surgiu algumas semanas atrás, com a divulgação de que um dos seus orientandos — o Hilder Vitor — tinha sido premiado com uma bolsa do Google para custear sua pós-graduação em sistemas de criptografia para computação em nuvem.
No encontro, além de conhecer a fundo o trabalho do Hilder e do LASCA, conversamos sobre outros assuntos como financiamento público e privado de pesquisas acadêmicas e, claro, a divisão entre academia e mercado.
Dividimos a entrevista em duas partes. A primeira, que você lê agora, trata dos aspectos técnicos da pesquisa de Hilder.
Nos próximos dias, publicaremos a segunda parte dessa entrevista, onde conversamos sobre as questões de financiamento e divisão entre academia e mercado.
Como começa a história da bolsa do Google?
Com um aluno nosso, o Hilder [Vitor] que teve pedidos de bolsa negados na Fapesp repetidas vezes. Daí submetemos o tema de pesquisa dele para o Google. Ele é um aluno muito bom, que veio da USP, tinha recebido prêmio de mérito acadêmico, publicado no exterior em conferências internacionais, um aluno muito qualificado, mas num cenário de corte de gastos… aparentemente a Fapesp está sofrendo com isso também…
Teve muita concorrência?
Foram mais de 300 inscrições de toda a América Latina apenas 12 contemplados, oito ou nove do Brasil. Aqui na Unicamp foi o único aluno contemplado. É muito curioso porque não tem nenhum tipo de restrição [ao tema de pesquisa] óbvio que temos que trabalhar no tema que a gente propôs, mas os dados são públicos, não tem nenhum tipo de patente… então quando eu fui fazer a burocracia aqui ninguém sabia como enquadrar a bolsa: não era consultoria… o Google está dando uma bolsa de pesquisa para um aluno e uma bolsa para mim, para que eu faça o que eu já faço, que é orientar o aluno. Então é como se fosse um prêmio que cai todo mês, num certo dia (risos).
No fim todos concluímos que não precisava fazer burocracia nenhuma, porque não se enquadrava em nenhuma categoria, mas eu fiquei muito feliz porque o aluno estava se sentindo desestimulado por causa das frequentes recusas…
E qual é o tema da pesquisa?
É uma linha de pesquisa que estou tentando abrir faz algum tempo aqui que se chama computação com dados cifrados… a ideia é: se você quer delegar a computação para a nuvem, o ideal é que você faça isso sem precisar revelar os dados necessários para aquela computação. Por mais que você possa enviar dados cifrados pra nuvem, algoritmos vão precisar decifrar esses dados antes de utilizá-los, então esses dados estão expostos para o servidor na nuvem. Esse servidor pode não ser confiável… a gente conhece aí a relação íntima entre provedores de computação em nuvem e NSA, e agências de inteligência… ou ele pode simplesmente ser alvo de um ataque. De vez em quando, serviços de internet são invadidos e dados são vazados.
Então a ideia é construir algoritmos para resolver um certo problema na nuvem, que é um problema relacionado a inteligência artificial, que opere sobre dados cifrados. O provedor de computação em nuvem sabe qual o algoritmo que ele está operando, mas não tem ideia de quais são os dados de entrada nem os dados de saída. A saída volta pro usuário cifrada também. Então é o usuário que tem a chave que cifra os dados e decifra a saída.
Como é que funciona a gestão de chave disso, então?
O cliente fica com todas as chaves, ou seja, ele não tem que delegar nada para o servidor. O algoritmo é construído de forma que o servidor consegue fazer operações sobre dados cifrados sem precisar de nenhuma chave para decifrá-los ou fazer a operação em si… ele simplesmente faz as operações. Acontece que existe uma classe de sistemas que se enquadram na classe de criptografia homomórfica, ou cifração homomórfica que funciona da seguinte maneira: você cifra os dados conservando parte da estrutura deles e outra parte pode fazer operações de soma desses dados, por exemplo, sem precisar decifrá-los, porque aí quando estiver fazendo operações nos criptogramas — nas mensagens cifradas — essas operações são equivalentes a operações feitas no texto claro.
Então se você conseguir expressar o algoritmo como uma sequência de somas e multiplicações, você cifra os dados para o servidor de computação em nuvem, ele faz as operações, retorna o resultado — que ele não tem a menor ideia do que seja — e você decifra e tem acesso ao resultado do algoritmo que rodou em uma plataforma não confiável.
É como somar coisas que você não sabe o que são…
Você faz uma operação… uma multiplicação de polinômios, que seja, quando você olha pra estrutura dessa operação, quando feita sobre dados cifrados ela corresponde a uma soma nos dados em texto claro. O problema é o impacto em desempenho, que é cerca de 1 milhão de vezes mais lento [do que uma operação com dados em texto claro]. Não há almoço grátis (risos).
Claro que esse é o estágio atual. Já passamos da época em que isso simplesmente não era possível. Essa ideia na verdade vem do Ronald Rivest — o R da RSA — que nos anos 1970 teve essa ideia brilhante de que se a gente tivesse construções dessa forma, poderíamos fazer computação que preserve a privacidade. Claro, a internet estava nascendo, quem ia imaginar que o modelo de negócio na internet hoje ia ser esse, trocar serviços por dados… ninguém ia imaginar isso, mas esses caras enxergavam muito além.
Aí em 2009… antes de 2009, entre os anos 70 e 2009 havia na literatura uma sequência de esquemas que permitiam apenas somas, depois apenas multiplicações, aí no começo dos anos 2000 apareceu um esquema que fazia algumas somas e uma multiplicação e em 2009 surge o primeiro esquema que permite um número arbitrário de somas e multiplicações. O que estamos usando é um esquema intermediário, com número arbitrário de somas mas com número de multiplicações limitado para reduzir o impacto no tempo.
Então o desafio é: como construir um algoritmo pra resolver esse pequeno problema de inteligência artificial, com um número de multiplicações limitado pelo parâmetros do sistema, que tem as propriedades homomórficas para ganhar a privacidade, mas ser ao mesmo tempo um sistema razoável, viável. Não adianta nada ficar o resto da idade do universo fazendo multiplicações (risos). Imagina, o Sol vira uma gigante vermelha e os dados estão computando ainda.
Nesse cenário você precisa de um client comum e um server parrudo. Você imagina esse tipo de computação funcionando numa rede peer-to-peer baseada em blockchain?
É complicado porque quem faz as operações sobre dados cifrados paga o custo computacional de preservar a privacidade do cliente. Se a gente conseguir encontrar sistemas de cifração homomórfica que sejam muito mais eficientes do que os que a gente tem hoje permitindo várias multiplicações e somas em dados cifrados, sim.
Como o estado da arte envolve um custo muito alto para quem vai fazer as operações, então a solução natural é mandar para a nuvem, porque aí você tem data centers, resfriamento, conexões de terabits…ou seja, funcionaria mais nesse aspecto assimétrico, onde o cliente é fraco e está delegando processamento para a nuvem porque ele não tem poder computacional pra rodar aquele algoritmo e ele faz isso na nuvem tentando preservar a privacidade das informações.
Mas claro que o cliente não precisa ser um usuário final, pode ser uma empresa, uma pequena empresa que não tenha condições de montar seu próprio data center e seja obrigada a contratar o serviço de terceiros.
E qual a entrega que o Google está esperando? O algoritmo pronto?
Isso não foi negociado em nenhum momento, então eu acredito que eles entendam que isso é um projeto de pesquisa. O que a gente colocou como objetivo era construir um algoritmo e a definição da prova de conceito… mostrar que de fato funciona com resultados reais, com bases reais.
O algoritmo que a gente elaborar precisa produzir uma saída próxima da saída original em texto claro. E tem que ser um algoritmo que resolva o mesmo problema rodando num tempo razoável. Eu conversei diversas vezes com o aluno e disse “olha, a gente não pode ficar triste se a gente tiver um milhão de penalidades de desempenho porque não há mágica”.
Mas o impacto de desempenho é muito mais relacionado a esse esquema de cifração homomórfica do que ao algoritmo que a gente vai projetar. Ele é super eficiente, o problema é que quando as operações são feitas sob dados cifrados, ficam um milhão de vezes mais lentas.
Uma pergunta leiga: como é projetar um algoritmo na prática?
Bom… ele escolheu trabalhar em dois problemas. Um problema que a gente chama de PCA, que é Analise de Componente Principal, que é um algoritmo para redução de dimensionalidade. Então imagine que você tem dados, um número muito grande de variáveis. Você quer reduzir o número de variáveis para tornar a coisa mais fácil de analisar. Então, de certa forma você tem que projetá-los em um número menor de variáveis: esse é um dos problemas a resolver. Outro é o problema de classificação: pegar um conjunto de dados e classificá-los em classes distintas e eu acho que esse problema é mais fácil para as pessoas entenderem.
Por exemplo, você pode ter um banco de dados original, classificado por um humano especialista. Tal dado é da classe 1, esse outro da classe 2, esse terceiro da classe 1 novamente, e assim por diante. Aí é uma questão de treinar o modelo com essa base para que o algoritmo passe a ser capaz de classificar novos elementos. Existem várias estratégias distintas para classificar elementos, mas a ideia é: tem que ter uma intuição — muitas vezes ela é geométrica — para esse problema que ele está trabalhando e isso precisa ser expresso como contas, em operações aritméticas. Nesse problema específico, é assim que os algoritmos são projetados, claro que para problemas distintos, as estratégias podem ser completamente diferentes.
Pra quem projeta o outro algoritmo, que faz a cifração homomórfica por exemplo, a estratégia é outra: trata-se de criar uma forma de cifrar dados, que transporte esses dados para um outro espaço, uma outra representação, que não tenha mais uma relação clara com os dados originais sem o conhecimento da chave, mas que ainda assim permita fazer as operações que seriam feitas no espaço original, mesmo sem o conhecimento das chaves. Normalmente você transforma esses dados em polinômios grandes, e faz as operações com esses polinômios de forma que você não consiga voltar ao dado original sem a chave.
Como você lida com a questão da segurança? Essa questão que você falou da criptografia…Você vai criar esse mecanismo, e o resultado não pode ser decifrável sem o conhecimento da chave. Como você lida com isso?
É… aqui estamos numa situação confortável, porque o algoritmo criptográfico em si foi proposto por outros autores, né? Então ele já passou por alguma revisão na literatura, algumas pessoas já encontraram ataques…
Mas quando você mexe nele… você não pode estar criando uma vulnerabilidade?
Em tese sim, mas normalmente esses algoritmos vem com uma “receita” de como utilizá-los de maneira segura. Então a gente sabe que a chave tem que ter um tamanho mínimo, porque… Existem formas de atacar esses algoritmos de chave pública que são mais eficientes que tentar todas as chaves, né? Com logaritmos discretos você tenta resolver um logaritmo, por exemplo, descobrir uma certa potência de um elemento de um grupo. Aqui é a mesma coisa. Tem vários tipos de ataques a esse criptosistema e que não tem a ver com testar todas as chaves…
Quer dizer, você pode testar todas as chaves mas, pelo tamanho da chave, isso não vai ser a abordagem mais eficiente. Um cuidado que a gente tem que ter é escolher o tamanho de parâmetros suficientes, senão você tem um algoritmo que fornece uma oportunidade para o adversário. Tem que ter uma implementação correta, senão a coisa não funciona. Outra coisa: numa situação real, o cliente tem que manter sigilo da sua própria chave. Então nesse caso a gente mantém tanto a chave de cifração quanto a chave de decifração em sigilo
Apesar de ser um algoritmo de chave pública, como o provedor de computação em nuvem não precisa da chave pública pra fazer operações, a gente pode manter a chave pública em segredo e isso limita um ataque, que é natural pra criptografia assimétrica, que é tentar cifrar um monte de mensagens pra ver se alguma delas bate com o criptograma, né? … isso não acontece aqui porque a chave pública é secreta também. Então o provedor de computação em nuvem nem pode receber os dados cifrados e dizer “ah, agora eu vou cifrar dados que seguem essas características aqui pra ver se algum deles bate com o que eu recebi. Se algum deles bate eu sei como descobrir o texto sem precisar decifrar de fato”.
Porque criptografia assimétrica, já que você não precisa revelar a chave?
Essa é uma ótima pergunta! Existem sistemas simétricos pra fazer essas operações — e que até são um pouco mais eficientes que os assimétricos — mas quando a gente tentou aplicá-los… em certo momento o servidor de computação em nuvem precisava de alguma informação privilegiada pra fazer as operações, então dos sistemas que a gente analisou, apenas os sistemas assimétricos fariam sentido. Porque a gente não pode dar absolutamente nenhum segredo pro provedor de computação em nuvem. Ele não sabe de nada, mas a gente supõe que ele é um atacante… a gente chama de atacante honesto, mas curioso, né: ele vai executar o protocolo, ele vai fazer as operações sobre os dados cifrados, mas a todo tempo ele vai tentar saber que dados são manipulados ali. Ele fica pensando: “será que esses dados são da Petrobrás? De jazidas de petróleo? (risos).
Não quer dizer que todos os serviços de computação em nuvem sejam maliciosos, mas claro que a gente sempre está se protegendo de alguém.
Você disse que em termos teóricos esse criptosistema já tinha sido elaborado antes.
Sim. Alguns trabalhos já usam. Nos últimos cinco anos já tem trabalhos que usam esse especialmente… Refinamentos, né? Porque as coisas vão sempre melhorando. Então tem trabalhos que usam esse sistema para outros problemas de computação sobre dados cifrados. Por exemplo, tem um grupo da Microsoft que trabalha muito bem nesse tema especificamente, e eles utilizam esse mesmo criptosistema pra resolver outros problemas de Inteligência Artificial… como avaliar uma rede neural. Nesse caso eles chegaram a um resultado negativo, porque a rede neural é uma rede complexa demais pra conseguir avaliar sobre dados cifrados, mas pelo menos eles geraram alguns dados teóricos interessantes sobre os obstáculos disso.
Eles também têm um trabalho de predição de doenças… então vamos supor que você mande seus sintomas para a nuvem — cifrado, porque obviamente você não quer que o provedor de computação em nuvem saiba seu histórico médico — e aí a nuvem pode utilizar essa informação, comparar com os sintomas de outras pessoas e retornar uma reposta cifrada de que doença você potencialmente tem. Usando o mesmo criptosistema assimétrico.
O obstáculo que eles tiveram é: como construir um algoritmo que faz essa operação de inferência, de tentar descobrir que doença você tem à partir de um conjunto de sintomas. Um problema diferente do nosso, que é de redução de dimensionalidade e de classificação.
Uma coisa que não dá pra fazer mais é dividir. Dividir é muito caro. Então não temos como fazer operações de divisão de dados cifrados. A gente pode multiplicar e somar. Também não dá pra comparar. Não posso pegar dois elementos e dizer “esse é menor do que esse, que é maior do que aquele” porque isso também é uma operação muito cara. Então a gente evita o máximo possível.
Você não acha que tecnologias como Machine Learning, e coisas do gênero, não poderiam ser usados para também identificar esses padrões pelo servidor de Cloud?
Possivelmente. A criptografia sempre se move na alternância entre ataques e defesas. Já existe uma área nascente de cripto que é atacar algoritmos usando aprendizado de máquinas e coisas assim, e de repente pode ser o caso de que lá na frente a gente descubra que ou esse criptosistema vaza ou a nossa solução pro problema de certa forma ainda vaza informações pro provedor em nuvem. Difícil dizer.
E tem a questão da computação quântica…
A longo prazo tem a computação quântica…Esse sistema usa dados reticulados. Se eu não me engano, a premissa de segurança dele ainda é intratável por um computador quântico. A ideia funciona mais ou menos assim: a gente tem um criptosistema, as pessoas estão tentando atacar o criptosistema, mas ele vem resistindo razoavelmente bem então a gente utiliza na nossa pesquisa. A gente bola um algoritmo usando esse criptosistema, e publica… “ó, tivemos essa ideia”. Aí a comunidade vai olhar e falar… A ideia é eficiente ou “toma aqui uma ideia melhor, bobão” (risos).
Siga-nos no Facebook, Twitter e Linkedin. Assine nossa newsletter e receba novidades toda a semana.
