Implementação de mecanismos de privacidade no OpenID Connect

Transcrição

1 Implementação de mecanismos de privacidade no OpenID Connect Pedro Henrique Pereira Martins 1, Rodrigo Duarte Lopez 1, Rafael Weingärtner 1, Jorge Werner 1, Carla Merkle Westphall 1 1 Laboratório de Redes e Gerência Universidade Federal de Santa Catarina (UFSC) Caixa Postal Florianópolis SC Brasil {pedro,rodrigo,weingartner,jorge,carla}@lrg.ufsc.br Abstract. In cloud computing it is necessary to prevent data leakage that could compromise the privacy of its users. Data stored by users on a cloud identity provider must be stored using secure methods and the user must be aware of the use of his data. This work aims to develop a way to prevent attackers or administrators to have access to the cloud user data ensuring users privacy. Our model proposes encryption of data stored on the identity provider as well as request the user s permission for the dissemination of his data, whenever data is requested by any application. Thus, the user participates in the process as it provides encryption/decryption keys and allows or not the release of data when an application (service provider) requests data from the identity provider. The proposals were implemented through an extension of MITREid software that is an available implementation of OpenID Connect. Resumo. Na computação em nuvem é necessário impedir o vazamento de dados que possam comprometer a privacidade de seus usuários. Os dados guardados pelos usuários em um provedor de identidade na nuvem devem ser armazenados usando métodos seguros e o usuário deve ter ciência sobre o uso dos seus dados. Este trabalho tem como objetivo desenvolver uma maneira de impedir que invasores/administradores tenham acesso aos dados dos usuários da nuvem garantindo a privacidade dos usuários. Nosso modelo propõe cifrar os dados armazenados no provedor de identidades além de requisitar a permissão do usuário para disseminação dos seus dados, sempre que estes forem requisitados por alguma aplicação. Dessa forma, o usuário participa do processo já que fornece chaves de cifragem/decifragem e permite ou não a liberação dos seus dados quando uma aplicação (provedor de serviço) requisita dados para o provedor de identidade. As propostas foram implementadas através de uma extensão do software MITREid que é uma implementação disponível do OpenID Connect. 1. Introdução A computação em nuvem é um modelo ubíquo, conveniente e de acesso compartilhado a recursos computacionais como servidores e diferentes tipos de serviços. Este modelo Bolsista do CNPq - Brasil Bolsista do CNPq - Brasil

2 também é capaz de fornecer e liberar recursos rapidamente com baixo custo de gestão [Mell and Grance 2011]. A propagação das identidades e das informações pessoais chamadas PII (Personally Identifiable Information) deve ser controlada e monitorada de acordo com a legislação. As informações sensíveis como identidades de funcionários, ou ainda, informações sobre estruturas organizacionais, serviços e aplicações de empresas, não podem ser expostas nos provedores de serviços nas nuvens [Weingärtner 2014]. A privacidade é um direito fundamental [Lauterpacht 1948] e deve ser garantido mesmo em ambientes online [Council 2012]. A melhoria da segurança e privacidade nos ambientes de computação em nuvem é fonte de pesquisas [Sánchez et al. 2012] [Betgé-Brezetz et al. 2012] [Kalloniatis et al. 2014]. Há preocupação com a segurança dos usuários para impedir o vazamento dos seus dados sensíveis. Para gerenciar as identidades de ambientes de computação em nuvem são usados os sistemas de gerenciamento de identidades (IdM - Identity Management), que podem ser definidos como frameworks capazes de administrar informações pessoais ligadas a identidade do usuário [Bertino et al. 2009] [Hansen et al. 2008]. Uma federação é um conjunto de provedores de identidade (IdP - Identity Provider) e de serviço (SP - Service Provider) que estabelecem uma confiança mútua para aceitar e confiar nos dados trocados entre esses provedores. Usando identidades federadas usuários realizam a autenticação uma única vez no domínio de origem e podem acessar recursos e serviços de múltiplos e diferentes domínios pertencentes à federação, já que os participantes da federação confiam no resultado da autenticação feita pelos parceiros [Orawiwattanakul et al. 2010] [Bertino and Takahashi 2011]. O gerenciamento de identidades na computação em nuvem precisa de garantia e transparência nas práticas de privacidade, no controle do uso e fluxo dos dados [Weingärtner and Westphall 2014] [Santos et al. 2014]. Para isso, é necessário que mecanismos de privacidade presentes na autenticação e na autorização definam modelos e políticas de uso de atributos adequadas [Faraji et al. 2014] [Chadwick and Fatema 2012]. Nos sistemas de gerenciamento de identidade garantir a segurança de PIIs é um problema quando se assume que existem administradores ou invasores maliciosos e/ou curiosos que tem acesso aos PIIs dos clientes armazenados em um ambiente online de nuvem computacional. Neste trabalho o objetivo principal foi a inserção de características de privacidade na versão MITREid [MIT 2014] que é uma implementação do sistema de gerenciamento de identidades OpenID Connect [OpenID 2014], que não possuia controles de privacidade. O modelo proposto tem a etapa diferenciada no cadastro do usuário no provedor de identidade e é fortemente centrado no usuário, já que precisa do consentimento e ciência do próprio usuário para liberação de atributos para o provedor de serviço. Nesse sentido este trabalho apresenta uma contribuição significativa pois estende o OpenID Connect para melhorar a privacidade dos usuários. O texto está organizado em 6 seções. Na seção 2 os trabalhos relacionados são descritos. A seção 3 apresenta as ferramentas usadas no desenvolvimento. A seção 4 explica como a privacidade foi inserida no OpenID Connect. Na seção 5 a implementação realizada é descrita e as conclusões sobre o trabalho estão na seção 6.

3 2. Trabalhos Relacionados O trabalho de [Switch 2012] desenvolveu um plugin para o sistema Shibboleth que fornece ao usuário a ciência sobre a divulgação de dados repassados para um provedor de serviço. Todos os usuários do ambiente usam a mesma política de liberação que é fixa no sistema. Já no trabalho de [Orawiwattanakul et al. 2010] os usuários podem selecionar, no sistema Shibboleth, entre todos os atributos não-obrigatórios que pretendam divulgar ao SP que está sendo acessado. É um trabalho usado na federação japonesa GakuNin. Em ambos trabalhos não há cifragem dos dados no provedor de identidade. Assim, um administrador malicioso pode ter acesso aos dados existentes na base de dados do IdP. O trabalho de [Sánchez et al. 2012] propõe um protocolo de reputação para o estabelecimento dinâmico de uma federação usando a reputação das entidades. Os usuários podem verificar as reputações dos provedores da federação antes de enviar quaisquer dados aos provedores. O modelo propõe uma maneira de verificar o que está sendo feito com os dados liberados e assim os próprios usuários aumentam ou diminuem a reputação do provedor. Um protótipo usando o sistema Authentic para implementar o IdP que considera a reputação foi desenvolvido. No artigo de [Betgé-Brezetz et al. 2012] é proposta uma maneira de definir se um usuário confia ou não em um provedor de nuvem. Com base na confiança do provedor de nuvem, o usuário pode enviar seus dados em texto plano, parcialmente criptografado (com alguns metadados em texto plano) ou totalmente criptografado para a nuvem. Também foi proposto o envelope de dados privados para transportar os dados dos usuários para a nuvem. Esse envelope pode conter os dados criptografados (ou não) com algumas políticas que declaram como, onde, por quem e quando esses dados podem ser usados. 3. Ferramentas utilizadas No desenvolvimento do trabalho várias ferramentas foram estudadas e testadas: OpenId Connect, Spring, CloudStack, Cryptico e Sjcl. OpenId Connect [OpenID 2014]: O OpenId Connect é um sistema de gerenciamento de identidades que dispõe de implementações em diversas linguagens, mas tem IdP e SP escritos em Java com boa documentação. O OpenId Connect funciona como uma camada extra no protocolo OAuth2.0, permitindo que os usuários de serviços online possam observar a identidade do servidor que está requisitando seus dados e saber quais dados estão sendo requisitados pelo servidor, além de auxiliar na resolução de qual IdP usar, usando como referência o nome/aplicação/endereço do IdP. Foi usada a MITREid que é uma implementação do OpenId Connect feita pelo MIT [MIT 2014]. Na figura 1 é representado o fluxo da interação entre usuário (browser), IdP e SP no OpenID Connect. No passo 1 o usuário requisita acesso ao recurso protegido. No passo 2 o SP requisita a autenticação do usuário que é realizada no passo 3. No passo 4 o usuário pode ter a chance de consentir com a liberação de dados para o SP. No passo 5 o IdP envia a prova da autenticação para o SP que é validada no passo 6. No passo 7 o SP obtém atributos do usuário a partir do IdP para liberar ou não o acesso ao recurso no passo 8. Spring [Spring 2015]: é um framework de desenvolvimento Java com várias bibliotecas. Foi usado o Spring para auxiliar na criação e gestão de objetos Java em memória. Spring-MVC é uma parte do Spring que cuida da infraestrutura do código que foi usada

4 Figura 1. Fluxo da interação entre Usuário, IdP e SP no OpenID Connect [Weingärtner 2014] para separar a parte lógica da parte da interface do usuário. Spring-Web é uma parte do Spring que cuida do mapeamento das páginas web que foi usada para mapear todas as páginas utilizadas no projeto. Spring-Security [Spring 2015] é uma parte do Spring que cuida dos aspectos de segurança da aplicação e foi usada para proteção de URL, autenticação de usuário e redirecionamento de URL. CloudStack [Apache 2015]: é uma ferramenta usada para gerenciar os dispositivos de hardware de uma ou mais máquinas para suportar a criação de máquinas virtuais com uso dinâmico dos recursos e compatibilidade entre diferentes tipos de software. Cria um ambiente do tipo IaaS (Infrastructure as a Service). Foi usada essa ferramenta para criação de máquinas virtuais nas quais hospedamos as aplicações de IdP e SP usadas. Cryptico [Terrell 2015]: é uma biblioteca de criptografia em JavaScript. Foi usada para o desenvolvimento da cifragem dos dados do usuário usando o algoritmo RSA para geração de par de chaves assimétricas com uma semente (seed) e cifragem/decifragem de dados usando criptografia assimétrica. Sjcl [Stark et al. 2015]: é uma bibilioteca de criptografia em JavaScript que foi usada para o cálculo do valor obtido com a função PBKDF2. O PBKDF2 é uma função de derivação de chaves a partir de senhas, que usa um valor salt e repete o processo do HMAC-SHA256 inúmeras vezes, resultando num valor mais seguro, porém mais custoso também para ser gerado. 4. Extensão do OpenID Connect para melhoria da privacidade Nossa proposta de extensão do OpenID Connect é fazer o usuário, dono dos seus dados, participar de toda a interação feita entre o IdP e o SP. Essa extensão proposta foi desenvolvida em conjunto durante o trabalho de dissertação de mestrado de [Weingärtner 2014]. O modelo proposto está representado e explicado na figura 2, e demonstra todo o fluxo na interação entre usuário, IdP e SP.

5 Figura 2. Fluxo da interação entre Usuário, IdP e SP no modelo proposto No IdP o usuário cifra os dados a serem armazenados durante o processo de cadastro do usuário no provedor de identidade. No momento que a aplicação no provedor de serviço precisa dos dados do usuário, é o próprio usuário que, com sua chave, irá decifrar os dados necessários com a chave escolhida no cadastro, e então irá cifrar os dados novamente com uma chave de sessão que será enviada para o SP. No momento da decifragem o usuário tem a chance de escolher qual o conjunto de atributos será decifrado. Assim, o usuário escolhe e fica consciente sobre a disseminação dos seus dados. Foram criados alguns tipos de conjuntos de dados: total e parcial. No conjunto total todos os dados do usuário serão decifrados para serem disseminados. Já no conjunto parcial apenas alguns dados escolhidos pelo usuário serão decifrados e disseminados para o SP. Foi criada a possibilidade do provedor de serviço especificar um conjunto de dados (escopo) que será necessário para o funcionamento correto da aplicação. O IdP por sua vez irá mapear esses escopos para os atributos correlacionados. Para isso, foram criadas algumas classes: SystemScopeDao que carrega da base de dados do IdP os escopos selecionados; SystemScopeService que constrói o escopo em tempo de execução; LrgScopeClaimTranslationService que traduz os escopos carregados para tipos de atributos. 5. Resultados experimentais Para adicionar nossas propostas ao protocolo padrão do OpenID Connect foi usada a versão de código desenvolvida pelo MITRE chamada MITREid [MIT 2014]. Foi necessário realizar várias modificações nesse código do MITREid. Primeiramente o código fonte da implementação do OpenID Connect feita pelo MITRE foi obtido [MIT 2014]. Foram instaladas as aplicações OpenId Connect Spring Server e Simple Web App do MITRE e foram feitos alguns testes. As seguintes

6 modificações iniciais foram feitas no código fonte obtido: Após testar a aplicação com o IdP do MIT e ver que tudo funcionou perfeitamente, realizou-se testes com outro IdP, no caso, o IdP da Google. Então foi criado um cadastro para a aplicação em questão no IdP da Google para esta poder fazer requisições de autenticação e dados neste IdP. Logo de início foram encontrados problemas de compatibilidade entre a aplicação e o IdP, pois a aplicação obtinha o endereço do IdP através do protocolo WebFinger, que não é implementado pelo IdP da Google. Assim, foi criada uma opção extra para que na hora de selecionar o IdP, fosse possível fornecer um recurso do IdP para o WebFinger resolver o endereço do IdP. De outra forma o endereço do IdP é fornecido diretamente, para resolver tais problemas, foi criada a página da figura 3. Foi testada a compatibilidade da aplicação com outros IdPs, no caso o IdP da Google, então encontraram-se algumas inconsistências na implementação do protocolo pela parte do MITRE. Existia um atributo NONCE que sempre era requisitado pela aplicação, sendo que na especificação do protocolo, esse atributo poderia ou não ser requisitado. A aplicação estava implementada para exigir esse atributo por parte do IdP e o IdP da Google não fornece esse atributo. Com isso, modificamos as classes PlainAuthRequestUrlBuilder com a adição de um valor lógico UseNonce para adicionar o campo do nonce ou não, na formação da URL, e na classe OIDCAuthenticationFilter também foi colocado um UseNonce para que a aplicação possa suportar o uso seletivo do NONCE. Depois que essas incompatibilidades foram acertadas a aplicação passou a funcionar corretamente para o IdP da Google e do MITRE. Foram criadas novas páginas web para a aplicação: página para seleção de IdP para autenticação, página para cadastro de usuários e página para alteração dos dados dos usuários. A criação de todas essas páginas envolveu a modificação do código da plataforma OpenID Connect Seleção de IdP para autenticação Nesta página web, apresentada na figura 3, o usuário irá definir qual IdP ele gostaria de usar, informando o endereço do próprio IdP ou usando web-finger para fazer a resolução automática do IdP através de um recurso. Figura 3. Página web para seleção do IdP

7 5.2. Cadastro de usuários Na página de cadastro, representada na figura 4, novos usuários irão fornecer seus dados para serem armazenados no banco de dados do IdP. Os campos para cadastro são: nome de usuário para autenticação, senha para autenticação, nome, sobrenome, , telefone, data de nascimento, gênero, cpf, rg, além de uma chave ou uma palavra passe que o usuário irá fornecer para cifrar os dados do banco de dados do IdP. Após o usuário entrar com todos os dados em seus respectivos campos, é enviado para o IdP os valores calculados pelo PBKDF2 a partir da senha e dos dados do usuário, e, esses mesmos dados (menos a senha) são cifrados usando a chave/palavra que o usuário escolheu e enviados para o IdP. O salt usado no PBKDF2 é derivado do nome de usuário fornecido e também é enviado para o IdP onde tudo é armazenado. A chave ou palavra passe não é enviada para o IdP, apenas é usada na página e depois descartada. Figura 4. Página web para cadastro no IdP A figura 5 mostra a página gerada para retornar uma resposta para o usuário após ele ter terminado de se cadastrar. É possível verificar como os dados do usuário foram persistidos no banco de dados em sua forma cifrada Disseminação dos dados do usuário para o SP A página de disseminação de dados (figura 6) alerta o usuário dos perigos em relação ao SP e os dados que o mesmo deseja obter. Nesta página, o usuário deve informar quais dados deseja liberar para o SP. Selecionados os dados, o usuário deverá fornecer sua chave ou palavra passe, para decifrar estes dados antes de enviá-los para o SP. Para desenvolver nossa proposta de controle da disseminação foi necessário criar um conjunto de classes para armazenar os dados temporariamente. A classe UserInfo- TempController é responsável por receber uma requisição AJAX com os atributos selecionados que devem ser enviados ao SP e armazenar esses atributos utilizando o objeto chamado lrguserinfortempservice. Esse objeto lrguserinfortempservice deve ser injetado

8 Figura 5. Dados do usuário cifrados ao final do processo de cadastro no userinfouserdetailsservice que é o objeto responsável por responder as requisições do SP. Alterações no arquivo approve.jsp foram necessárias para possibilitar ao usuário escolher quais dados serão disseminados para o SP. Outra modificação realizada no arquivo approve.jsp foi a adição de um filtro para interceptar todas as requisições que utilizam este arquivo. Este filtro é responsável por carregar e definir no objeto requisitado todos os metadados necessários para auxiliar o usuário durante o processo de disseminação de dados ao SP. Todo processo de cifragem e definição de atributos a serem disseminados foi uma extensão implementada no código original. Figura 6. Processo de disseminação estendido 5.4. Alteração dos dados de usuário A página web apresentada na figura 4 é usada para alterar os dados do usuário. O usuário, após autenticado no IdP, pode alterar seus dados, inclusive a chave usada na cifragem. Para fazer isso, o usuário irá acessar esse recurso, fornecer sua chave para abrir os dados, ver qual dado ele quer trocar e alterar o dado. Para alterar a senha o usuário terá que fornecer a senha antiga e a nova senha duas vezes. Feito isso, na hora de enviar as novas informações para o IdP, toda a operação de cifrar e calcular os valores com o PBKDF2 é

9 feita novamente, como na página de cadastro, e então esses dados são alterados no banco de dados. 6. Conclusão Este trabalho de iniciação científica contribuiu na implementacao dos aspectos de privacidade propostos na dissertacao de mestrado de [Weingärtner 2014], já que existe uma grande quantidade de classes e códigos presentes no sistema MITREid. No desenvolvimento do trabalho foram criadas novas páginas para interação do usuário com o IdP, foram criadas novas classes e modificadas classes existentes e também foram feitos testes do funcionamento. O IdP foi preenchido com dados exemplo através dessas páginas, e, depois, uma aplicação de testes foi desenvolvida para usar o IdP. Com esta implementação todo usuário cadastrado no IdP tem seus dados cifrados antes da persistência no banco de dados do IdP que está executando no ambiente de computação em nuvem do LRG (Laboratório de Redes e Gerência) da UFSC. No momento que uma aplicação requisita os dados do usuário, o IdP notifica o usuário a respeito dos dados requisitados pela aplicação. O usuário então decifra estes dados com sua chave para fazer a liberação desses dados para a aplicação. Para facilitar o processo de decifragem, o usuário também pode optar por derivar um par de chaves a partir de uma palavra passe (palavra que servirá como a senha): o usuário fornece a palavra/frase e o próprio sistema deriva o par de chaves a ser usado para decifrar os dados. Assim a decisão final de liberar ou não os dados para a aplicação é do usuário, que está ciente a respeito de todo o processo. Essa foi uma grande modificação feita no funcionamento do código MITREid do OpenId Connect. Todo processo de cadastro, cifragem e definição de atributos a serem liberados foi uma extensão implementada no código original. É importante observar que toda a parte de criptografia adicionada gera um aumento no processamento e no espaço de armazenamento no banco de dados, mas é um acréscimo que garante a privacidade do usuário. Questões de usabilidade da aplicação foram facilitadas com a possibilidade de derivação de chaves com a entrada da palavra passe. Com estas precauções no manejo dos dados entre IdP e SP há uma grande melhoria na privacidade do usuário nesse ambiente de gerenciamento de identidades que pode ser usado na nuvem. Diferente dos trabalhos [Switch 2012] [Orawiwattanakul et al. 2010], que usam o sistema Shibboleth, o nosso trabalho garante a privacidade dos dados cadastrados no IdP e o usuário participa do processo de decifragem e disseminação dos seus dados, usando o OpenID Connect. Semelhante aos trabalhos [Sánchez et al. 2012] [Betgé-Brezetz et al. 2012], o nosso trabalho também é centrado no usuário, alerta os usuários antes do envio dos dados ao provedor e desenvolveu um protótipo. Referências Apache (2015). Apache cloudstack. Bertino, E., Paci, F., Ferrini, R., and Shang, N. (2009). Privacy-preserving digital identity management for cloud computing. IEEE Data Eng. Bull., 32(1): Bertino, E. and Takahashi, K. (2011). Identity Management: Concepts, Technologies, and Systems. Artech House.

10 Betgé-Brezetz, S., Kamga, G.-B., Ghorbel, M., and Dupont, M.-P. (2012). Privacy control in the cloud based on multilevel policy enforcement. In CLOUDNET 2012, pages IEEE. Chadwick, D. W. and Fatema, K. (2012). A privacy preserving authorisation system for the cloud. Journal of Computer and System Sciences, 78(5): Council, H. R. (2012). The promotion, protection and enjoyment of human rights on the internet (a/hrc/20/l.13). id= Faraji, M., Kang, J.-M., Bannazadeh, H., and Leon-Garcia, A. (2014). Identity access management for multi-tier cloud infrastructures. In NOMS 2014, pages 1 9. IEEE. Hansen, M., Schwartz, A., and Cooper, A. (2008). Privacy and identity management. Security & Privacy, IEEE, 6(2): Kalloniatis, C., Mouratidis, H., Vassilis, M., Islam, S., Gritzalis, S., and Kavakli, E. (2014). Towards the design of secure and privacy-oriented information systems in the cloud: Identifying the major concepts. Comp. Standards & Interfaces, 36(4): Lauterpacht, H. (1948). The universal declaration of human rights. Brit. YB Int l L., 25:354. Mell, P. and Grance, T. (2011). The nist definition of cloud computing. NIST. MIT (2014). Mitreid connect. OpenID (2014). Welcome to openid connect. Orawiwattanakul, T., Yamaji, K., Nakamura, M., Kataoka, T., and Sonehara, N. (2010). User-controlled privacy protection with attribute-filter mechanism for a federated sso environment using shibboleth. In 3PGCIC, 2010 Int. Conf. on, pages IEEE. Sánchez, R., Almenares, F., Arias, P., Díaz-Sánchez, D., and Marín, A. (2012). Enhancing privacy and dynamic federation in idm for consumer cloud computing. IEEE Trans. on Cons. Elec., 58(1): Santos, D. R. D., Nascimento, T. J., Westphall, C. M., Leandro, M. A. P., and Westphall, C. B. (2014). Privacy-preserving identity federations in the cloud: A proof of concept. Int. J. Secur. Netw., 9(1):1 11. Spring (2015). Spring framework. Stark, E., Hamburg, M., and Boneh, D. (2015). Stanford javascript crypto library. Stanford University. Switch (2012). uapprove - user consent module for shibboleth identity providers. Terrell, R. (2015). Cryptico library. Weingärtner, R. (2014). Controle de disseminação de dados sensíveis em ambientes federados. Master s thesis, UFSC, Florianópolis, Brasil. Weingärtner, R. and Westphall, C. M. (2014). Enhancing privacy on identity providers. In 2014 The Eighth International Conference on Emerging Security Information, Systems and Technologies (SECURWARE), pages 82 88, Lisbon, Portugal.