Mecanismos de autenticação em serviços baseados em Cloud - PDF
Download "Mecanismos de autenticação em serviços baseados em Cloud"
Ana Vitória Assunção Estrada
1 UNIVERSIDADE DA BEIRA INTERIOR Engenharia Mecanismos de autenticação em serviços baseados em Cloud João José Teles Gouveia Dissertação para obtenção do Grau de Mestre em Engenharia Informática (2º ciclo de estudos) Orientador: Professor Doutor Paul Crocker Co-orientador: Professor Doutor Simão Melo de Sousa Covilhã, outubro de 2013
2 ii Mecanismos de autenticação em serviços baseados em Cloud
3 Agradecimentos Em primeiro lugar gostaria de agradecer aos meus pais, pelo apoio que me deram durante a concretização de mais esta etapa académica, pelo enorme esforço, carinho, incentivo e confiança que depositaram nas minhas capacidades. Sem a vossa dedicação e o vosso amor incondicional seria impossível atingir este objetivo. Da mesma forma, quero agradecer ao meu irmão por tudo isso e pelos momentos de descontração proporcionados. Ter um irmão é um presente, admiro-te muito e quero-te sempre ter ao meu lado. Deixo um agradecimento muito especial a todos os meus restantes familiares, que de uma forma ou de outra, me apoiaram e ajudaram na conclusão desta caminhada. Sei que estão felizes por mim, e feliz eu serei graças a vocês. Quero também agradecer à minha namorada e melhor amiga, Maria Manuel Casteleiro, porque apesar da distância que nos separava foi sempre capaz de ter uma palavra, um sorriso, a força que eu precisava para continuar a lutar pelos meus objetivos. Agradeço-te todos os dias que escolheste ficar ao meu lado enquanto trabalhava, por todos os momentos de diversão, alegria e carinho proporcionados, as palavras certas na altura certa, por todo o amor que sentes por mim. Espero algum dia conseguir retribuir na mesma proporção tudo aquilo que fizeste e fazes por mim. És sem dúvida alguma a melhor namorada do mundo, a melhor amiga, a melhor confidente. Obrigado por tudo isso e muito mais. Agradeço profundamente ao meu orientador Professor Doutor Paul Andrew Crocker pela sua enorme dedicação, força de vontade e energia contagiante. A oportunidade que me foi dada de integrar o projeto PRICE e o seu papel como orientador foram fatores decisivos para eu considerar este como o meu melhor ano académico. As suas explicações, observações, o seu precioso tempo perdido comigo foram determinantes para o meu sucesso neste projeto. Obrigado pelas agradáveis conversas proporcionadas ao longo do ano e pela sua constante alegria e otimismo. Igualmente, agradeço ao meu co-orientador Professor Doutor Simão Melo de Sousa por todos os minutos dispendidos para me aconselhar, todo o esforço e sentido crítico sempre presente. O que mais me contagia é a sua energia e dedicação aos projetos da sua vida. Quero realmente agradecer por todo o apoio, indispensável ao longo dos vários meses de trabalho. Ao Ricardo Azevedo da PT Inovação o meu muito obrigado por todo o interesse demonstrado e apoio incondicional, que me foi dado ao longo do desenvolvimento da dissertação. Agradeço todas as opiniões, sugestões e reuniões onde as discussões foram extremamente benéficas para o projeto. Não poderia deixar de agradecer ao meu amigo, colega de Mestrado e também colega no projeto PRICE João Silveira pelo espírito de entreajuda, discussões, todas as noites mal dormidas de trabalho árduo, pelos momentos de desânimo em que me apoiou e obrigou a continuar a minha caminhada e, acima de tudo, por todos os momentos de alegria, distração e boa disposição proporcionados. Obrigado por tudo isso amigo. iii
4 Não poderia faltar o meu enorme agradecimento a todos os meus amigos, pelos mais variados momentos de descontração proporcionados, por todo o apoio nesta caminhada, pelo sorriso ou abraço quando ele mais falta fazia, pela sincera amizade que mantemos e espero vir a manter para o resto da minha vida. Sem vocês a minha vida seria diferente, sem cor, com menos alegria e menos vivências. É graças a vocês também que termino mais esta fase da minha vida. O meu muito obrigado João Manuel Casteleiro, Ruben Santo, Samuel Dias, Leopoldo Ismael, Pedro Querido, Daniel Piedade, Gonçalo Félix, João Alberto Casteleiro, João Oliveira, José Varejão, Luís Ferreira, Miguel Casteleiro, Miguel Machado, Pedro Proença, Romão Vieira, Rui Santos, Ana Santos, Catarina Valério, Maria Figueiredo, Rita Mineiro e Sara Pais. Por todos os momentos passados e por todos aqueles que hão-de estar para chegar. iv
5 Resumo Esta dissertação descreve duas arquiteturas distintas para autenticação e acesso uniforme a dados armazenados em fornecedores de armazenamento e serviços na Nuvem. A primeira arquitetura aproveita as vantagens do mecanismo de autorização OAuth aliado ao mecanismo de autenticação forte dos Cartões de Identidade Eletrónica Nacionais (Eid cards), no nosso caso o Cartão de Eid Português ou Cartão de Cidadão (CC). Será apresentada uma comparação de mecanismos de autorização e acesso aos fornecedores de armazenamento na Nuvem, comparando os mecanismos de autorização OAuth 1.0, OAuth 1.0a e OAuth 2.0. Para utilizar a arquitetura proposta foi desenvolvida uma implementação que fornece acesso Web uniforme aos fornecedores de armazenamento e serviços na Nuvem mais populares, tais como a Dropbox, Skydrive, Meo Cloud e Google Drive usando o mecanismo de autenticação do Cartão de Cidadão como Token de acesso único. Para possibilitar o acesso uniforme a estes serviços serão descritas as diferenças entre as diferentes REST APIs pertencentes aos fornecedores considerados. Finalmente, será apresentada a aplicação Web que permite aos utilizadores que possuam cartões de Eid aceder aos diferentes fornecedores de armazenamento na Nuvem considerados a partir de um ponto único de acesso. A segunda arquitetura proposta aproveita as vantagens do mecanismo de autenticação OpenID. Será apresentada uma arquitetura que engloba o OpenID e o mecanismo de autenticação forte do CC. O principal objetivo deste sistema é dar ao utilizador a possibilidade de usar o seu Cartão de Eid (CC) para se autenticar em qualquer aplicação ou serviço Web que permita a delegação do processo de autenticação, através do protocolo OpenID. No final, foram criadas duas aplicações Web como prova de conceito deste sistema. Palavras-chave Nuvem, Armazenamento, Cartões Inteligentes, Segurança, Confidencialidade, Privacidade, Autenticação, Autorização, Certificado, OAuth, OpenID, REST, JSON v
6 vi Mecanismos de autenticação em serviços baseados em Cloud
7 Abstract This dissertation describes two different architectures for authentication and uniform access to protected data stored on Cloud Storage Service Providers. The first architecture takes advantage of the OAuth authorization mechanism and the strong authentication mechanism of the National Electronic Identity (Eid) Cards, in our case the Portuguese Eid card or Cartão de Cidadão (CC). It will be presented a comparison of authorization mechanisms and access to popular cloud storage providers, comparing the different authorization mechanisms OAuth 1.0, OAuth 1.0a and OAuth 2.0. Using the proposed architecture it was developed an implementation of this architecture that provides a uniform Web based access to popular Cloud Storage Service Providers such as Dropbox, Skydrive, Meo Cloud and Google Drive using the authentication mechanism of the Eid card as a unique access token. In order to provide a uniform access to these services the differences in the various REST APIs for the targeted providers will be described. Finally the Web application that allows users that hold Eid cards a single point of access to their various cloud storage services will be presented. The second one takes advantage of the OpenID authentication mechanism. It will be presented an architecture that includes OpenID and the strong authentication mechanism of the CC. The main objective of this system is to give the user the capability to use your Eid card (CC) to log into any application or Web service that allows the delegation of the authentication process, through the OpenID protocol. Finally, two Web applications were created as a proof of concept of the system. Keywords Cloud, Storage, Smartcards, Security, Confidentiality, Privacy, Authentication, Authorization, Certificate, OAuth, OpenID, REST, JSON vii
8 viii Mecanismos de autenticação em serviços baseados em Cloud
9 Índice 1 Introdução Objetivo Motivação Contribuição Organização Estado da arte Sistemas de gestão de identidades Protocolos de autenticação e autorização Protocolo de autenticação SAML Protocolo de autorização OAuth Protocolo de autenticação OpenID Cartões de identificação digital Práticas internacionais Cartão de Cidadão Português REST APIs Trabalhos relacionados Implementação Autenticação com CC via sessão SSL Certificados de servidor Certificados de cliente Autenticação com CC em fornecedores de armazenamento na Nuvem API uniforme para interação com os diferentes fornecedores de armazenamento Arquitetura do sistema Simploud Integração da API desenvolvida numa aplicação proprietária Implementação de um esquema de IBE e políticas de acesso a ficheiros Servidor OpenID proprietário Arquitetura do sistema Resultados Aplicação Web Simploud Servidor OpenID proprietário Testes e tempos de execução Conclusão e Trabalho Futuro 55 Bibliografia 57 A Anexos 61 A.1 Classe SecureController.cs A.1.1 Código para autenticação e validação de certificado do Cartão de Cidadão 61 A.1.2 Função que executa o pedido de autorização OAuth à API A.2 Classe AuxiliarFunctions.cs ix
10 A.2.1 Função para verificar se o certificado apresentado pertence aos certificados do Cartão de Cidadão A.2.2 Função que executa o pedido à API para obtenção de Token de acesso.. 62 A.3 Classes pertencentes à API desenvolvida A.3.1 Classe OAuthBaseCloudpt.cs A.3.2 Classe OAuthDropbox.cs A.3.3 Classe DropboxCloudProvider.cs A.3.4 Modelos criados para desserializar as respostas JSON x
11 Lista de Figuras 2.1 Mecanismo do protocolo de autorização OAuth Exemplo de formulário OpenID na página de autenticação do Yahoo Mecanismo do protocolo de autenticação OpenID Identificação dos dados visíveis no Cartão de Cidadão Cadeia dos certificados de chave pública de autenticação eletrónica e assinatura digital do Cartão de Cidadão Português Cadeia dos certificados de chave pública construída para as arquiteturas Simploud e OpenID Provider Esquema de utilização do Certificado de Autenticação Esquema geral da arquitetura do sistema Simploud Modelo da base de dados que suporta a arquitetura Simploud Attack Tree para a arquitetura proposta Esquema geral do processo de Upload de um ficheiro Esquema geral da arquitetura do sistema OpenID implementado Modelo de base de dados que guarda todos os dados relativos ao registo de entidades Em cima, janela de autenticação do utilizador na aplicação Simploud. Na parte inferior, erros de autenticação obtidos Janela para escolha do fornecedor de armazenamento pretendido Janela que permite a visualização sobre os recursos protegidos, após autorização completada Popups que contêm as funções de gestão de pastas (à esquerda) e de ficheiros (à direita) Popups para envio de ficheiros sem serem cifrados (à esquerda) e recorrendo a cifra (à direita) Janela inicial do provedor OpenID Autenticação do utilizador perante o provedor OpenID Registo do utilizador na base de dados do provedor OpenID Janela principal da aplicação que delega a autenticação Janela restrita a membros autenticados na aplicação que delega a autenticação Janela do provedor OpenID que permite autenticar o utilizador na aplicação que confia a autenticação Janela restrita a membros autenticados na aplicação que delega a autenticação, com este processo concluído Gráfico que demonstra a relação dos tempos de execução da aplicação Simploud e os tempos médios de execução do formulário de Login dos fornecedores de armazenamento na Nuvem xi
12 xii Mecanismos de autenticação em serviços baseados em Cloud
13 Lista de Acrónimos API CA CC CRL DI ECC EEPROM Eid GSS-API HTML HTTP IBE ICAO IdM IEC ISO IT JSON LID OAuth OCSP OpenID PIN PKG PKI PUK RA REST SASL SCEE UBI VA Web XML XRDS XRI Yadis Application Programming Interface Certification Authority Cartão de Cidadão Certificate Revocation List Departamento de Informática European Citizen Card Electrically-Erasable Programmable Read-Only Memory Electronic Identity Generic Security Service Application Program Interface HyperText Markup Language HyperText Transfer Protocol Identity Based Encryption International Civil Aviation Organization Identity Management System International Electrotechnical Commission International Organization for Standardization Instituto de Telecomunicações Javascript Object Notation Light-Weight Identity Open Source Authorization Protocol Online Certificate State Protocol Open Identification Protocol Person Identification Number Private Key Generator Public Key Infrastructure PIN Unlock Key Registration Authority Representational State Transfer Simple Authentication and Security Layer Sistema de Certificação Eletrónica do Estado Universidade da Beira Interior Validation Authority World Wide Web extensible Markup Language Extensible Resource Descriptor Sequence extensible Resource Identifier Yet another distributed identity system xiii
14 xiv Mecanismos de autenticação em serviços baseados em Cloud
15 Capítulo 1 Introdução Ao longo de toda a história da Humanidade, as áreas do conhecimento têm sido alvo de constante evolução e em nenhuma destas áreas se assistiu até hoje à estagnação do conhecimento e sabedoria por ser impossível encontrar avanços necessários ao acompanhamento da evolução da história. A Informática e a Ciência de Computadores inserem-se perfeitamente neste contexto pois representam duas disciplinas nas quais as mudanças e consequentes evoluções são constantes. Deste modo, a Cloud representa um dos principais avanços ao nível da computação, recentemente. Juntando a este novo paradigma o crescimento exponencial da Web, onde todos os dias se assiste ao aparecimento de novas aplicações e novos serviços, é inevitável que se garanta a identidade de um utilizador, bem como a autenticidade do mesmo nos diferentes serviços a que está subscrito. Com a expansão de aplicações e serviços disponíveis aos utilizadores surge um novo problema que necessita de rápida intervenção. A propagação de identidades digitais é um problema existente na atual conjuntura e que requere toda a atenção da comunidade científica. Atualmente, cada utilizador possui diversos serviços Web ativos, cada qual com a sua identidade digital (normalmente desdobrada no conjunto nome de utilizador e palavra-passe), levando a um aumento das mesmas identidades com o decorrer do tempo, o que se torna claramente num problema de segurança. O igual avanço nos últimos anos do tema Cloud tem alastrado este problema e é imperativo que a segurança dos dados dos utilizadores se mantenha intata apesar do aumento exponencial das suas identidades digitais. Para ir ao encontro desta necessidade surgem os sistemas de gestão de identidades. Estes sistemas têm como principais características gerir identidades individuais, a sua autenticação e autorização, papéis e privilégios para um dado serviço, ou conjunto de serviços. Estes sistemas são capazes de facilitar o acesso a dados protegidos num serviço, a terceiras entidades, sem ser necessária a partilha de informações confidenciais, como o nome de utilizador ou a palavra-passe. Com este novo paradigma corrigem-se vários problemas ao nível de multiplicidade de identidades, autenticação e confidencialidade. O OAuth e OpenID são exemplos deste tipo de sistemas que gerem de forma particular a identidade de um utilizador. O OAuth surge como um protocolo focado para autorização, possibilitando a autorização para terceiros acederem a dados pessoais guardados em diferentes serviços. Já o OpenID recolhe toda a problemática envolvente do tema de propagação de identidades e resolve-a, surgindo como um protocolo de delegação de autenticação. Se aliado a um destes protocolos estiver a autenticação forte de cartões Eid podemos ter garantias de ter um sistema robusto e com uma componente importante no processo de autenticação, que é o facto de possuir um elemento físico e através deste conseguir aceder aos diferentes serviços onde o utilizador esteja registado. 1
16 1.1 Objetivo O principal objetivo deste trabalho é criar um novo mecanismo de autenticação em ambientes Cloud, nomeadamente nos fornecedores de armazenamento Cloud mais conhecidos e utilizados. Para isso foi utilizada a autenticação forte do cartão de cidadão português. A vantagem da utilização do cartão de cidadão é clara, sendo um sistema que necessita o uso de um objeto físico (cartão), aliado a um Pin de autenticação. A utilização do cartão de cidadão em detrimento do sistema de autenticação mais utilizado (nome de utilizador e palavra-passe) eleva o grau de segurança ao nível da autenticação numa aplicação ou serviço. Os objetivos principais previstos no plano de trabalhos são os seguintes: ˆ Revisão da literatura sobre serviços de autenticação de identidade em plataformas de computação Cloud; ˆ Estudo, análise e familiarização com as APIs dos fornecedores comuns, como o exemplo da Dropbox, Skydrive e/ou Google Drive; ˆ Estudo e análise dos protocolos de autenticação e autorização existentes; ˆ Especificação de um sistema de autenticação baseado no CC e proposta de alteração de um serviço de identidade para a Cloud; ˆ Instalação e configuração de um sistema de autenticação que aproveita o cartão de cidadão permitindo que um utilizador se identifique em qualquer aplicação Web. 1.2 Motivação O presente trabalho é o resultado de uma parceria entre o grupo de investigação RELiable and SEcure Computation (RELEASE) da Universidade da Beira Interior e a empresa Portugal Telecom (PT) Inovação no âmbito do projeto PRICE - Privacy, Reliability and Integrity in Cloud Environments. Este projeto envolve vários trabalhos para além da presente dissertação e tem como objetivo a criação e disponibilização de soluções de autenticação, privacidade, confiança e integridade em plataformas Cloud para a possível utilização pela PT Inovação. O projeto foi financiado por uma bolsa de investigação fornecida pela PT Inovação, através do Instituto de Telecomunicações (IT). 1.3 Contribuição A contribuição deste projeto para as disciplinas de Informática e Ciências de Computadores é notória pois torna possível a utilização do cartão de cidadão como objeto de autenticação para qualquer serviço Web, nomeadamente para os serviços de armazenamento na Cloud mais comuns, como o caso da Dropbox, Google Drive, Cloudpt e Skydrive. O que potencia esta utilização global do cartão de cidadão como mecanismo de autenticação é a criação de um servidor OpenID proprietário que regista e inicia sessão de utilizadores que possuam este cartão. O sistema desenvolvido aplica-se a todos os serviços que aceitem a delegação de acesso a servidores 2
17 OpenID. Sabendo que todos os fornecedores de armazenamento Cloud anteriormente destacados utilizam o protocolo OAuth, foi criada uma solução intitulada Simploud que permite a autorização por parte de utilizadores que possuem o cartão de cidadão aceder aos seus recursos protegidos que se encontram nesses serviços. Para a construção desta última plataforma foi ainda criada uma API que integra de forma uniforme todos os pedidos OAuth feitos aos fornecedores de armazenamento, bem como para obtenção de informação acerca dos dados guardados nesses mesmos fornecedores. Esta dissertação resultou ainda na publicação de um artigo científico na conferência internacional CloudCom 1 13 [GCdSA13]. 1.4 Organização A presente dissertação está organizada em vários capítulos que mostram sequencialmente o processo de investigação desenvolvido. Neste primeiro capítulo foi descrito o projeto, as motivações, os objetivos assim como a contribuição da presente dissertação. Os seguintes capítulos encontram-se organizados da seguinte forma: ˆ Capítulo 2 - Estado da arte: Neste capítulo são descritas todas as tecnologias abordadas ao longo da dissertação. Inicialmente é apresentada a problemática que originou a existência dos sistemas de gestão de identidades e são demonstrados diversos sistemas existentes, bem como protocolos de autenticação e autorização que se inserem nesta problemática. De seguida é elaborado um estudo sobre cartões inteligentes, autenticação multifatorial e especificamente sobre o cartão de cidadão português, objeto de estudo aprofundado e de trabalho nesta dissertação; ˆ Capítulo 3 - Implementação: Neste capítulo descrevem-se todas as tecnologias utilizadas, todas as ferramentas criadas e todas as componentes necessárias para a execução dos objetivos propostos. Este capítulo é dividido em dois cenários (o primeiro representa a ferramenta de acesso a dados protegidos em fornecedores externos como a Dropbox e o segundo cenário trata o servidor proprietário OpenID; ˆ Capítulo 4 - Resultados: O capítulo dos resultados pretende demonstrar, de uma forma mais visual e não conceptual, as duas implementações desenvolvidas durante este projeto. Este capítulo apresenta ainda alguns testes efetuados às duas implementações; ˆ Capítulo 5 - Conclusão e Trabalho Futuro: O último capítulo refere as conclusões do trabalho desenvolvido e descreve as tecnologias e funcionalidades que podem ser integradas de forma a complementar os sistemas apresentados nesta dissertação. 1 3
18 4 Mecanismos de autenticação em serviços baseados em Cloud
19 Capítulo 2 Estado da arte A expansão da Web como a conhecemos no presente obriga a que exista uma evolução noutros domínios da ciência de computadores e informática. Aspetos como segurança, integridade, confidencialidade, autenticidade e não-repúdio são testados, corrompidos e debatidos com o decorrer do tempo. Os desafios impostos são imensos e cada vez mais assistimos a ataques que obrigam à criação de novas arquiteturas ou protocolos, ou ainda à alteração dos já existentes. De seguida serão expostos os principais avanços na última década no campo da segurança e as principais ideias que estão a surgir para o futuro da computação e principalmente da Web, nomeadamente ao nível do aparecimento recente da infraestrutura Cloud. 2.1 Sistemas de gestão de identidades Com a exponencial evolução da internet e semelhante aumento do número de serviços disponíveis para os utilizadores deparamo-nos com a propagação de identidades digitais de tal forma que no período mais recente da história da internet se tem feito um esforço enorme para arranjar soluções que ajudem a resolver os problemas relativos à explosão de identidades digitais. O igual avanço nos últimos anos do tema Cloud tem alastrado este problema e é imperativo que a segurança dos dados dos utilizadores se mantenha intata apesar do aumento exponencial das suas identidades digitais. A gestão de múltiplas identidades (normalmente associadas ao par nome de utilizador e palavrapasse) não é apenas um incómodo, é também uma das principais fraquezas a nível de segurança da internet. Muitos dos serviços disponíveis possuem o seu próprio formulário de registo e obriga o cliente a registar-se para obter acesso aos seus serviços. Pior que isto é o facto adquirido de que sempre que um utilizador se regista num destes serviços vai fazê-lo usando um nome de utilizador e palavra-passe iguais ou idênticos aos já existentes, o que consiste numa má prática de segurança. Neste sentido surgiram, em 2001, os primeiros grandes esforços para corrigir esta problemática, com o aparecimento de sistemas de gestão de identidades e standards abertos à comunidade de autenticação e autorização. Os sistemas de gestão de identidades, tal como o nome indica, têm como principal objetivo gerir a identidade digital de um utilizador individual, a sua autenticação, autorização, papéis e privilégios em qualquer serviço ou aplicação Web, com o intuito de melhorar a segurança, produtividade ou até mesmo tarefas repetitivas. A evolução dos sistemas de gestão de identidades digitais acompanha o crescimento da internet, pois só desta forma é possível que um utilizador navegue com certos padrões de segurança. As principais soluções destes sistemas podem-se dividir em quatro grandes grupos: 5
20 ˆ Gestão de identidades Active Directory foi criada pela Microsoft para gerir a autenticação e autorização de todos os utilizadores e computadores num domínio de rede, ou seja, ao invés do utilizador ter uma palavra-passe para aceder ao sistema principal da empresa, uma senha para ler os seus s, uma senha para se autenticar num computador, entre outras, com a utilização do AD, os utilizadores poderão ter apenas uma chave que lhe permita aceder a todos os recursos disponíveis na rede. Para este caso podemos definir uma diretoria como sendo uma base de dados que armazena as informações dos utilizadores; O Fornecimento de Contas de Utilizador refere-se à criação, manutenção e desativação de objetos e atributos pertencentes a um dado utilizador, guardados em diversos sistemas de informação de uma empresa. Este tipo de sistemas tem como objetivo tornar mais rápido, eficiente e seguro os diferentes processos de criação, manutenção ou desativação de dados e registos de utilizador. As principais funcionalidade pelas quais se deve reger um sistema deste tipo são a sincronização de identidade (quando um utilizador altera os seus dados num dado sistema de base de dados, todas as base de dados que possuam estes dados replicados devem ser atualizadas também), o auto-fornecimento e auto-desativação (quando um utilizador se regista numa base de dados, esse utilizador deve ser automaticamente inserido em todos os outros sistemas de informação da empresa. O mesmo processo de atualização de base de dados acontece com a auto-desativação, processo em que um utilizador é eliminado do sistema), possibilidade de alteração de informação de perfil por vontade própria, permitir que utilizadores executem pedidos para aceder a determinados sistemas e aplicações, e permitir pedidos de delegação de acesso; A Sincronização de Palavra-passe tem como principal objetivo a sincronização de uma palavra-passe entre diferentes sistemas de TI. Normalmente este processo é suportado por software, e a qualquer momento um utilizador pode alterar a palavrapasse, afetando sempre todos os serviços associados a este software. Contudo este processo é considerado menos seguro que o Single Sign-on, pois a descoberta da palavra-passe torna todos os serviços associados vulneráveis e inseguros. ˆ Controlo de acesso Os sistemas de Gestão de Palavra-passe são aplicações que ajudam o utilizador a organizar as suas próprias palavras-passe e códigos PIN. Por norma estas aplicações recorrem a uma base de dados local ou a ficheiros que guardam os dados cifrados correspondentes a todas as palavras-passe do utilizador, seja para aplicações e serviços Web, seja para autenticação em outros computadores, a verdade é que este tipo de dados são comumente utilizados no dia a dia do utilizador e a memorização destes sem o apoio deste tipo de sistema seria praticamente impensável, nomeadamente para pessoas que possuam diversas palavras-passe; O Single Sign-on (SSO) é uma propriedade do controlo de acesso que relaciona múltiplos sistemas de software, que são independentes entre si. Esta propriedade permite que um utilizador se possa autenticar e automaticamente ganhe acesso a todos os serviços relacionados com o sistema principal, sem que para isso necessite fazer autenticação entre cada um deles. Apesar deste sistema trazer os benefícios óbvios, ao tema do controlo de propagação de identidades digitais, é necessário que 6
21 este seja coadjuvado por smartcards ou Tokens OTP, pois a perda de acesso a este serviço causaria que todos os outros serviços anteriormente ligados ao SSO estariam comprometidos; O Controlo de acesso baseado em papéis tem hoje em dia um papel importante no mundo comercial. A grande maioria das empresas utiliza este sistema pois este permite que se restrinja o acesso apenas a utilizadores autorizados. Numa organização, os papéis são hoje em dia muito importantes e criados consoante as funções de trabalho dessa empresa. Não faz sentido que um empregado de escritório tenha o mesmo tipo de acesso a um sistema de informação que o diretor, por exemplo. ˆ Os Serviços de diretoria são fundamentais para o bom funcionamento dos idm e podem-se dividir entre repositórios de dados de identidade (para administração de atributos e contas de utilizador), replicação e sincronização de dados, virtualização de diretorias, sistemas eletrónicos de diretorias escaláveis e ainda os sistemas de próxima geração, como o CADS (Composite Adaptive Directory Services), cuja definição consiste num sistema de diretorias que engloba a problemática da gestão de identidades. ˆ Os principais Protocolos standard desenvolvidos nesta área são o SAML, OpenID e OAuth, possibilitando a autenticação de utilizadores (no caso dos dois primeiros) e a autorização para aceder a recursos protegidos (no caso do OAuth). Na seção 2.2 são descritos estes protocolos em pormenor. 2.2 Protocolos de autenticação e autorização Como referido anteriormente, no tema dos sistemas gestores de identidades, existem diversos sub-ramos em que estes sistemas se dividem, incluindo alguns standards abertos disponibilizados para a comunidade e que vêm fornecer novas formas de autenticação e de autorização. Os exemplos óbvios e que sobressaem na área nestes últimos anos são os dos protocolos de autorização OAuth e de autenticação OpenID, e ainda o protocolo SAML, assente nas propriedades de SSO. Atualmente, estes protocolos são necessários visto que permitem que um utilizador possa partilhar recursos ou mesmo efetuar autenticação num serviço sem que para isso tenha que possuir uma conta associada ao mesmo. Deste modo, é oferecido aos programadores e utilizadores um leque muito maior de opções que podem ser inseridas e usadas nos processos de autenticação e autorização de acesso das suas aplicações Protocolo de autenticação SAML O protocolo SAML (Security Assertion Markup Language) foi criado em 2001, pelo comité de segurança OASIS, e teve a sua última revisão em 2005, com a sua versão 2.0 [OAS05]. O SAML consiste numa framework baseada em XML para troca de dados de autenticação e autorização entre entidades, em particular, entre um provedor de identidade e um fornecedor de serviços. O único requisito de grande importância para esta linguagem é o SSO. O SAML define três entidades para definir o seu mecanismo: o utilizador, o provedor de identidade (idp) e o fornecedor de serviço (SP). O primeiro passo consiste no envio de um pedido do utilizador para o SP, para que possa utilizar um dos seus serviços. De seguida, o SP faz um pedido e obtém uma afirmação de identidade por parte do idp. Na base desta afirmação, o SP 7
22 define se pretende que o utilizador aceda ao seu serviço ou não. O protocolo SAML foi revisto pro duas vezes durante a sua existência, existindo as versões [OAS04] e [OAS05]. A necessidade da revisão deste protocolo prende-se com detalhes como a alteração do esquema e estrutura do protocolo, alteração das normas de assinatura digital, regras de processamento e de clarificação Protocolo de autorização OAuth Como referido por Leiba [Lei12], o OAuth é um protocolo de autorização que se situa na categoria de sistemas de gestão de identidades, pois este permite a partilha de recursos entre serviços eletrónicos. Este protocolo surge no ano de 2007, com a sua última revisão a ser publicada em [Ed.10] no ano de 2010, como mecanismo de autorização de acesso. O modo de operação do OAuth é relativamente simples e baseia-se na possibilidade de uma terceira entidade poder aceder, através do nosso consentimento, aos nossos dados protegidos num dado serviço sem que seja necessário o utilizador fornecer as suas credenciais de acesso (que normalmente se designam pelo par nome de utilizador e palavra-passe). Um caso de uso simples onde é percetível a aplicação deste protocolo é o exemplo de autorização de um serviço de impressão (consumidor), aceder a fotos privadas que se encontram noutro serviço (o fornecedor de serviço), sem que o consumidor exija ao utilizador as suas credenciais de acesso ao fornecedor de serviço. A vantagem deste mecanismo centra-se na capacidade de permitir que uma terceira entidade aceda aos dados protegidos do utilizador, sem que esta saiba quais são os dados de autenticação do utilizador no serviço que possui os dados. Figura 2.1: Mecanismo do protocolo de autorização OAuth A Figura 2.1 é ilustrativa de como se processa todo o mecanismo deste protocolo, sendo que este pode ser dividido em três processos principais. O consumidor faz um pedido de autoriza- 8
23 ção para o proprietário dos recursos. A resposta do proprietário dos recursos deverá vir sob a forma de token, indicando que foi autorizado o acesso por parte do proprietário dos recursos ao consumidor. De seguida o consumidor envia um novo pedido onde inclui o token obtido para ser autorizado, agora pelo servidor onde estão alojados os dados confidenciais do proprietário dos recursos. Caso o proprietário permita a partilha de dados com esta terceira entidade, é enviado um novo token, definitivo, e até este ser revogado ou eliminado pelo proprietário dos recursos ou servidor, o consumidor terá acesso aos dados protegidos, com o consentimento prévio dado pelo proprietário. É ainda importante referir que a cada consumidor é associado a uma chave única por parte da entidade que protege os recursos, e que todos os tokens gerados durante o processo de autorização do mecanismo OAuth são gerados com base nesta chave. O que isto quer dizer é que a esta chave ficarão associados todos os tokens gerados por ele, e sem ele nenhum deles funcionará. Na prática, um atacante que consiga ter acesso ao access token não conseguirá nada mais que isso, pois precisa da chave atribuída ao consumidor para poder assinar os pedidos feitos ao fornecedor da chave. Para além da versão 1.0 existem hoje mais duas versões do protocolo - [et 09a] e [Ed.12]. A versão 1.0a do protocolo OAuth veio resolver um problema especificado em [et 09b], que se centrava num potencial ataque de fixação de sessão. O atacante podia interromper o protocolo e mais tarde fornecer o seu url de obtenção do token de autorização a outro utilizador, para de seguida receber esse mesmo token e poder continuar o mecanismo, neste caso com permissões de acesso aos dados do utilizador atacado. Este erro afetava de forma grave todo o mecanismo do OAuth, comprometendo-o, mas foi detetado sem que existissem ainda casos de uso deste potencial erro grave. Esta especificação veio corrigir este problema de forma muito simples, introduzindo um código de verificação entre o pedido de autorização e o pedido de obtenção do token de acesso, para que o servidor que autoriza o consumidor final saiba se é o mesmo consumidor que faz todos os pedidos. A versão mais recente do OAuth, 2.0, veio introduzir novas considerações de segurança para a geração de tokens. As principais alterações efetuadas ao protocolo permitem agora a introdução de diferentes escopos e ainda o conceito de Refresh Token [M. 13]. A introdução de escopos neste protocolo foi importante pois veio possibilitar que um utilizador possa fornecer acesso a uma terceira entidade apenas a algumas partes dos seus dados. Um exemplo prático desta situação é a Live API, da Microsoft, onde o utilizador pode apenas querer partilhar os seus dados de utilizador da conta de , ou então apenas os seus dados guardados no Skydrive. O conceito de Refresh Token foi igualmente importante pois isto permitiu que se evitassem ataques de sessão ou mesmo tentativas de obtenção dos tokens guardados, pois a criação deste novo conceito alterou a estrutura dos tokens até aqui utilizados. A principal alteração à estrutura foi a introdução de um campo de tempo de sessão, sendo que quando este campo expira o consumidor necessita iniciar o mecanismo de Refresh Token para obter um novo token válido. O mecanismo de refresh token é bastante mais simples. Enquanto que para se obter um token de acesso um consumidor apenas envia o token anteriormente concedido (token de autorização), no Refresh Token é necessário, para além disso, o client_id e client_secret, parâmetros que fazem parte da estrutura dos pedidos OAuth. Assim, este problema foi resolvido 9
24 e sempre que um token expira o utilizador apenas tem que usar um pedido de refrescamento para obter um novo token e continuar com o acesso anteriormente concedido Protocolo de autenticação OpenID O protocolo de autenticação OpenID original foi desenvolvido em Maio de 2005 [Bra05] por Brad Fitzpatrick enquanto trabalhava para a empresa Six Apart. Foi inicialmente intitulado de projeto Yadis (Yet another distributed identity system) e só passou a ser chamado de OpenID quando a empresa Six Apart registou o domínio openid.net para seu uso. O OpenID foi rapidamente implementado no LiveJournal 1, um popular website comunitário criado por Fitzpatrick, que rapidamente ganhou a atenção da comunidade de identidades digitais. Mais tarde neste mesmo ano, iniciaram-se algumas discussões entre os utilizadores deste protocolo e programadores da empresa de software NetMesh, que usava o protocolo LID (Light-Weight Identity), de sua autoria. Os resultados diretos desta colaboração resultam na descoberta do protocolo Yadis, posteriormente intitulado OpenID. A entrada de programadores de XRI para este projeto [OAS06], contribuindo com o formato XRDS (Extensible Resource Descriptor Sequence) [OAS10], resultam na introdução deste formato no protocolo. Figura 2.2: Exemplo de formulário OpenID na página de autenticação do Yahoo O OpenID [RR06, Ope07] é um protocolo aberto que permite aos utilizadores autenticarem-se através de outras aplicações Web cooperantes com a aplicação que estão a aceder. Estas entidades cooperantes são conhecidas no protocolo como Relying Party e usam um serviço considerado como uma terceira entidade para fornecer autenticação. Com isto elimina-se a necessidade de cada serviço ou aplicação Web ter o seu próprio formulário de autenticação e consegue-se consolidar a identidade digital do utilizador. Na prática, o que este mecanismo vem potenciar é a possibilidade de um utilizador que esteja registado numa aplicação Web que suporte OpenID a capacidade de se registar com essa mesma identidade digital em outros serviços que permitam a delegação do processo de autenticação a um provedor OpenID. Ao olhar para a Figura 2.2 percebe-se as potencialidades deste mecanismo, pois para um utilizador se autenticar em toda a plataforma Yahoo 2 pode delegar o processo de autenticação a outros serviços, como o Facebook ou a Google https://login.yahoo.com/ 10
25 Figura 2.3: Mecanismo do protocolo de autenticação OpenID A Figura 2.3 demonstra todo o mecanismo deste protocolo em pormenor. Existem cinco passos essenciais que suportam este protocolo. Primeiro o utilizador apresenta um identificador OpenID que pretende provar ser seu. De seguida, a entidade à qual o utilizador pretende aceder descobre qual o fornecedor OpenID correspondente ao identificador do utilizador e redirecionao para este fornecedor, para que se proceda à autenticação. O utilizador autentica-se perante o seu fornecedor OpenID e após o sucesso da operação o fornecedor redireciona o utilizador de novo para a entidade confiante que pretende aceder. A entidade confiante recebe os dados do utilizador e estabelece um novo pedido ao fornecedor OpenID para validar a autenticação. O último passo deste processo passa pelo envio da resposta de validação de autenticação e, em caso do pedido ser validado, o utilizador tem finalmente acesso ao serviço que pretende usar. Assim, caminhamos rapidamente para uma era em que uma única identidade digital servirá para que um utilizador se registe em qualquer serviço que suporte este ou outro protocolo, que siga as mesmas filosofias e mecanismos do OpenID. 2.3 Cartões de identificação digital Práticas internacionais Nos últimos anos, à escala global, tem-se verificado uma acentuada e progressiva criação de cartões de acesso a serviços eletrónicos, com frequentes associações a tecnologias de certificados digitais. A procura de uma maior eficiência e eficácia na prestação dos serviços e a adoção de tecnologias potenciadoras de criação de caminhos alternativos à via presencial e manual (principalmente no âmbito do acesso ao Governo Eletrónico), tem resultado numa constante preocupação de assegurar o nível de segurança adequado à prossecução das transações, pretendendo-se adequar às diferentes ameaças desenvolvidas através da criação das tecnologias 11
26 mais recentes. Os casos mais conhecidos dentro da Europa, e que serviram de base de estudo para o Cartão de Cidadão, acontecem na Áustria, Bélgica, Estónia, Finlândia e Suécia. Cada um destes casos tem condicionantes específicas, pois em muitos casos a própria constituição dos países não permite certos tipos de situações relacionadas com a identificação dos cidadãos, e aquilo que se pode considerar como identificação eletrónica destes. Procede-se de seguida a uma breve análise destas caraterísticas e de algumas das condicionantes para os casos dos países mencionados, bem como de casos específicos de outros países. No caso da Áustria, foi criado o conceito de cartão de cidadão que permite ao cidadão aceder a determinados serviços da Administração Pública de forma eletrónica e segura. Este caso tem a particularidade de permitir ao cidadão o uso de qualquer cartão que seja emitido por uma entidade que cumpra com os requisitos definidos para este projeto. Na Europa, esta é a situação onde existe uma maior diversidade de cartões que servem para os mesmos fins. O conceito de cartão definido pelo governo Austríaco permite que este documento digital sirva para assinatura e identificação eletrónica. O acesso ao certificado digital de autenticação encontra-se protegido por um PIN e, caso o portador do cartão falhe o código PIN três vezes este fica automaticamente bloqueado, sendo o desbloqueio efetuado através da introdução de um código PUK. Como documento físico substitui o passaporte nacional, permitindo que qualquer cidadão deste país possa viajar entre a União Europeia, Área Económica Europeia e Suíça. Os próximos passos deste conceito focam a criação de um sistema de integração de cartões Eid estrangeiros no sistema nacional. Na Bélgica, o cartão de identidade eletrónico existe desde 2004, e surge como principal objetivo de se tornar no único instrumento para o acesso a eservices Públicos ou Privados. O conceito do cartão belga introduz um cartão com as mesmas funções que os cartões de identidade tradicionais e consiste no principal instrumento de identificação e autenticação para o acesso a serviços de egovernment. O cartão possui ainda suporte para assinatura digital e substitui o passaporte de viagem para os países do espaço Shengen. Este sistema tem ainda a vantagem de possuir um registo centralizado de população atualizado. Uma das condicionantes deste sistema é o facto da constituição belga apenas permitir que seja atribuída uma identificação aos cidadãos com idade superior a doze anos. Para contornar este problema, surgiu em 2009, o cartão Kids ID, que contém apenas dados comuns, como o nome, idade e contacto do cidadão. Este cartão possui um certificado de autenticação, mas não de assinatura, já que este procedimento não tem legalidade jurídica para menores de idade. No que diz respeito à Estónia, o projeto para a criação de um cartão de identificação eletrónica foi iniciado em 1997 com o objetivo de fomentar o uso da identidade eletrónica a nível nacional. Este documento digital tem como funcionalidade a autenticação e assinatura digital. Este projeto foi ambicioso e a prova disso é que, em 2007, a Estónia torna-se o primeiro país a nível mundial a implementar o voto eletrónico ao nível institucional. A partir do ano de 2004, este documento substitui o documento de viagem até então utilizado, devido à entrada da Estónia na União Europeia. Os principais avanços apontados por parte deste programa indicam a interoperabilidade entre este e outros projetos homólogos de outros países, a introdução de dados biométricos para identificação eletrónica e a implementação de WPKI (Wireless Public 12
27 Key Infrastructure), arquitetura que adota os métodos PKI existentes para o uso em ambientes wireless, assegurando comércio móvel seguro. A Finlândia criou o seu cartão de cidadão nacional com os objetivos de substituir o cartão de identidade nacional, o documento de viagem no espaço Schengen e servir como cartão de acesso a serviços eletrónicos públicos e privados que necessitem de autenticação forte. Deste modo, este conceito tem sido, desde o seu início, implementado como objeto de autenticação numa entidade bancária finlandesa (OKO Bank). A Finlândia é um país pioneiro na implementação do conceito de identificação eletrónica, visto que o primeiro projeto por parte das entidades governamentais surgiu em 1999, embora este não tenha sido bem sucedido. Dado que a emissão deste cartão trazia elevados custos aos cidadãos, e associando isto ao facto da licença de condução neste país permitir identificar o cidadão em praticamente todos os casos, este projeto foi dado como dispensável por parte dos cidadãos e, mais tarde, pelo estado. O caso da Suécia difere de todos os outros anteriormente apresentados, pois este projeto iniciado em 2005 oficialmente, introduz um cartão de identificação eletrónica que contém um chip, com rádio frequência RFID, destinado para leitura de dados biométricos. Para além desta caraterística, este contém os dados do portador e ainda um chip utilizado para aceder a serviços de egovernment de forma segura. Áustria Bélgica Estónia Finlândia Suécia Chip Sim Sim Sim Sim Sim Certificados Digitais Sim Sim Sim Sim Sim Autenticação Eletrónica Sim Sim Sim Sim Sim Assinatura Digital Sim Sim Sim Sim Sim RFID Não Não Não Não Sim Dados biométricos Não Não Não Não Sim Tabela 2.1: Quadro resumo com caraterísticas de cartões internacionais Os casos anteriormente enumerados são os casos pioneiros da Europa, sendo que nos últimos anos têm surgido mais projetos que seguem as mesmas normas, os mesmos standards e implementam a grande maioria dos desafios propostos anteriormente. Os casos mais flagrantes disto são os da França, Alemanha, Holanda, Espanha e Itália, todos eles com suporte para autenticação e assinatura digital. O quadro 2.1, acima especificado, resume a grande maioria das caraterísticas especificadas para os projetos pioneiros europeus na área dos cartões inteligentes de identificação. Este estudo foi feito pois havia a necessidade de perceber quais as compatibilidades entre estes cartões e o principal objeto de estudo de trabalho desta dissertação, o Cartão de Cidadão Português. Todos os projetos apresentados dos diferentes países têm muitas caraterísticas em comum, seguem as mesmas normas como documentos de identificação e, em alguns casos, como documento de viagem. Podemos identificar as caraterísticas comuns através da seguinte lista: ˆ Todos os cartões apresentados seguem as normas estipuladas pela da ECC (European Citizen Card); ˆ Nos casos aplicáveis, todos aplicam as normas definidas pela ICAO (International Civil Aviation Organization) para documentos de viagem internacionais [Int08]; 13
28 ˆ Aplicação dos padrões 7501, 7810 e 7816 definidos pela ISO (International Organization for Standardization), sendo que o primeiro refere-se à criação de uma zona de leitura ótica para documentos de viagem; o segundo indica as dimensões padrão para este tipo de cartões e a terceira define, entre outras coisas, a posição do chip no cartão e ainda os mecanismos do chip e interação com estes por parte dos leitores; ˆ Em todos os casos de estudo é possível a identificação eletrónica, através da utilização do certificado de autenticação, e a assinatura digital de documentos; ˆ À exceção da Suécia, todos os restantes casos implementam uma PKI que serve tanto o setor público como o setor privado. Analisando estas caraterísticas comuns a todos os cartões fabricados, e relembrando que apenas foram verificados os casos europeus, pode-se concluir que todo o trabalho efetuado no âmbito desta dissertação a nível de autenticação, através de cartões inteligentes de identificação eletrónica, pode ser facilmente utilizada por outras entidades que não apenas portadores do Cartão de Cidadão Português. Qualquer utilizador que possua um cartão de identificação eletrónica que siga as normas anteriormente apresentadas pode utilizar o sistema proposto e implementado, como os casos dos portadores de cartões Eid da Aústria, Bélgica, Estónia, Finlândia, Suécia e ainda os casos mais recentes da França, Alemanha, Holanda, Espanha e Itália Cartão de Cidadão Português O Cartão de Cidadão Português começou a ser emitido em Fevereiro de 2007, como documento de cidadania, com o objetivo de substituir o bilhete de identidade, cartão de contribuinte, cartão de segurança social e cartão de utente do serviço nacional de saúde. Como documento físico, permite ao cidadão identificar-se presencialmente de forma segura. Como documento tecnológico, permite a identificação, ou autenticação, perante serviços informatizados e assinatura de documentos eletrónicos. Na sua dimensão agregadora, junta num só documento as chaves indispensáveis ao relacionamento rápido e eficaz dos cidadãos com diferentes serviços públicos. O Cartão de Cidadão representa um projeto de desenvolvimento tecnológico e na sua vertente digital, promove o desenvolvimento das transações eletrónicas dando-lhes a segurança da autenticação forte e da assinatura eletrónica. Os principais objetivos que lhe estão associados passam por: ˆ Garantia de maior segurança na identificação dos cidadãos; ˆ Harmonização do sistema de identificação civil dos cidadãos nacionais com os requisitos da União Europeia; ˆ Facilitação da vida dos cidadãos, através da agregação física de vários cartões; ˆ Promoção do uso de serviços eletrónicos, com recurso a meios de autenticação e assinatura digital; ˆ Melhoria da prestação dos serviços públicos, alinhando a modernização organizacional e tecnológica; 14
29 ˆ Racionalização de recursos, meios e custos para o Estado, para os cidadãos e para as empresas; ˆ Promoção da competitividade nacional por via da reengenharia e da simplificação de processos e de procedimentos Caraterísticas do Cartão O Cartão de Cidadão segue as normas internacionalmente recomendadas para que este seja um documento de identificação e um documento de viagem reconhecido oficialmente. Assim, este encontra-se alinhado pelas as orientações correntes da União Europeia, nomeadamente as do grupo de trabalho para o ECC, pelas normas definidas pela ICAO para documentos de viagem internacionais (documento 9303) e os padrões 7501, 7810 e 7816 definidos pela ISO. O formato do Cartão de Cidadão é o de um cartão ID-1, definido pela norma ISO/IEC 7810 (dimensões 85,60 x 53,98 mm) e correspondente ao formato TD-1 de machine readable travel documents (MRTD) definido pela ICAO no Documento 9303, Parte 3, Secção III. Esta norma deve ser complementada pela norma ISO , que define a posição e funcionamento do chip embebido no cartão. Em função dos objetivos de utilização, das aplicações previstas e das soluções perspectivadas, o chip do Cartão de Cidadão tem as seguintes características: ˆ É um chip Java Card, multi-aplicação; ˆ Suporta a versão mais recente da plataforma Java Card e o uso de logical channels; ˆ Possui uma capacidade de memória EEPROM (ou equivalente) mínima de 64KB; ˆ Suporta múltiplos PINs. anteriormente; Os PINs estão em conformidade com as normas apresentadas ˆ Suporta mecanismos de bloqueio em caso de erro na introdução do PIN após N tentativas e respetivo desbloqueio por meio da introdução de PUK e chave administrativa de acesso ao cartão; ˆ Suporta mecanismos de geração de novo PIN mediante a introdução do PUK do cidadão; ˆ Possui um motor criptográfico interno que suporta: Assinatura e verificação RSA de 1024 bits; Assinatura digital qualificada; DES e TDES (Data Encryption Standard e Triple Data Encryption Standard respetivamente); MD5, SHA-1 e SHA-256, no mínimo; MAC (Message Authentication Code); PKCS#1 (RSA Cryptography Standard) e PKCS#15 (Cryptographic Token Information Format Standard); é compatível com leitores de cartões na norma EMV-CAP, para funcionamento de autenticação multi-canal baseada em One Time Password; Resistente a ataques conhecidos como "Hardware attack", "Timing attack", "Simple power analysis" e "Differential power analysis". 15
30 Mecanismos de autenticação em serviços baseados em Cloud A nível físico o cartão de cidadão tem um aspeto idêntico ao apresentado na Figura 2.4, contém diversas informações acerca do cidadão, como o nome, data de nascimento, nacionalidade, fotogra a e os diversos números de identi cação representativos dos diferentes serviços públicos do estado, cujo cartão vem substituir. Figura 2.4: Identi cação dos dados visíveis no Cartão de Cidadão O cartão foi lançado, como parte de um plano de desenvolvimento tecnológico, com os objetivos de juntar num só documento, os documentos necessários em vários serviços públicos e promover a identi cação eletrónica através do mecanismo de autenticação forte e da assinatura digital e a interação com diferentes serviços públicos e privados. As principais funcionalidades pensadas para este smartcard aquando do seu lançamento são: Guardar informação privada que o titular pode utilizar mas não conhecer nem partilhar. Dentro deste campo podemos identi car três diferentes chaves criptográ cas: Chave simétrica de autenticação do titular; Chave privada de um par de chaves assimétricas RSA para autenticação do titular; Chave privada de um par de chaves assimétricas RSA para assinatura digital; Guardar informação pessoal para validação interna de identidade do titular. Esta validação consiste num mecanismo de Match-on-Card, que permite comparar os dados biométricos guardados dentro do smartcard, neste caso especí co a comparação entre a impressão digital do titular guardada no cartão e uma impressão digital comunicada ao mesmo, para validação de identi cação; Guardar informação reservada. Esta informação refere-se unicamente à morada do titular do cartão e pode ser disponibilizada a quem desejar ou a quem tiver autorização para 16
31 obter esta informação, sendo necessário para isso que o titular do cartão introduza um PIN de desbloqueio desta informação; ˆ Guardar informação pública. Esta informação de conhecimento público, como referido anteriormente, consiste na fotografia digital do titular do cartão, nos certificados de chave pública de autenticação e assinatura digital e ainda de toda a informação do titular visível fisicamente no cartão; ˆ Efetuar operações criptográficas, através da utilização das chaves privadas fornecidas pelo cartão. O cartão possui ainda três códigos PIN, cada um constituído por quatro algarismos, para efetuar três tipos de operações: ˆ Autorização de indicação de morada; ˆ Autenticação eletrónica do titular do cartão; ˆ Produção de assinatura digital por parte do titular do cartão. A camada adicional de segurança que se consegue com a introdução destes códigos PIN no cartão impedem que, em caso de extravio ou perda do cartão, outra entidade que esteja na posse deste documento físico não possa aceder a dados confidenciais do titular do cartão, nem fazer uso das funcionalidades deste smartcard Cadeia de certificados e Certificação No campo da certificação existem muitos passos até que um certificado esteja pronto para executar a tarefa para a qual foi criado, como por exemplo a autenticação digital. Os certificados do Cartão de Cidadão não são alheios a todo este processo de certificação. Mas para se perceber todo o processo de certificação de um certificado é necessário começar pelo início de todo o processo, sendo para isso necessário falar de PKI, ou caso a inexistência desta, explicar o que é uma CA (Certification Authority). Como definição de PKI pode-se dizer que é o conjunto de todo o hardware, software, pessoas, políticas e procedimentos para criar, gerir, distribuir, usar ou revogar certificados digitais. Normalmente uma PKI designa-se por um órgão, público ou privado, que gere uma estrutura de emissão de chaves públicas, baseando-se sempre no princípio de terceira parte confiável, estabelecendo a ponte de credibilidade e confiança em transações entre partes que utilizam certificados digitais. Uma CA é a entidade certificadora da infra-estrutura de chaves públicas e o seu principal objetivo é gerir a ligação de chaves públicas a outras entidades, sendo que cada entidade deve ser considerada única no domínio da CA para que se possa estabelecer a ligação entre esta e uma chave pública gerada pela CA. Numa infraestrutura PKI podem-se ainda considerar as entidades VA e RA (Validation Authority e Registration Authority, respetivamente). Enquanto que a VA exerce o papel de registo de um utilizador na infraestrutura, a segunda atribui-lhe uma chave pública, concluindo o processo de ligação entre os dois. O estado português, a par de vários exemplos descritos em na Secção 2.3.1, criou então a sua própria estrutura de gestão de certificados (X.509), conhecida por SCEE, ou Sistema de Certificação Eletrónica do Estado. A arquitetura da SCEE constitui assim uma hierarquia de confiança, 17
32 que garante a segurança eletrónica do Estado. Para o efeito a SCEE compreende uma Entidade Gestora de Políticas de Certificação que aprova a integração de entidades certificadoras na SCEE pronunciando-se igualmente sobre práticas e políticas de certificação, uma Entidade Certificadora Eletrónica Raiz, que constitui o primeiro nível da cadeia hierárquica de certificação, e as várias Entidades Certificadoras do Estado a esta subordinadas. Podemos assim dizer que a PKI do estado funciona então como intermediária entre os portadores do CC e as entidades confiáveis de raiz. A entidade de raiz que se encontra no topo da cadeia de certificação dos certificados do Cartão de Cidadão é a GTE Cyber Trust Global Root, uma entidade confiável a nível mundial que emitiu o certificado ECRaizEstado que, consequentemente, herdou o nível de fiabilidade da primeira. Posto isto, a PKI do estado possuidora do seu próprio certificado emitido por uma entidade confiável por si só, é capaz de criar, gerir e revogar os seus próprios certificados. Ao olhar para a Figura 2.5, podemos analisar esta situação e como está estruturada toda a cadeia de certificados do Cartão de Cidadão. Figura 2.5: Cadeia dos certificados de chave pública de autenticação eletrónica e assinatura digital do Cartão de Cidadão Português Para além do certificado de autenticação identificado na Figura 2.5 (EC de Autenticação do Cartão de Cidadão 0001) existem ainda mais sete certificados, criados para o mesmo fim. A razão pela qual a SCEE estabeleceu este tipo de arquitetura de certificados é que caso, por algum motivo, exista uma falha no sistema ou um possível ataque contra este certificado, apenas os certificados inferiores nesta cadeia serão afetados. Na prática esta situação faria com que apenas os cidadãos que tivessem este certificado na cadeia de certificação fossem obrigados a fazer um novo cartão, e não toda a população que possua o Cartão de Cidadão. Outro aspeto importante a considerar na certificação é existirem processos de verificação e validação de identidade. É estritamente necessário que, em todo este sistema de certificação, a Entidade Certificadora possua mecanismos que provem a veracidade, autenticidade e validade dos certificados apresentados a esta, isto para que uma terceira entidade que queira verificar, 18
33 autenticar e validar, digitalmente, uma entidade possuidora de certificados possa enviar um pedido para a CA desse mesmo certificado e esta lhe possa responder afirmativa ou negativamente, consoante o estado do certificado do cidadão. Os mecanismos de validação de certificados mais conhecidos, e suportados pela SCEE, são os métodos OCSP (Online Certificate State Protocol) [MAM + 99] e CRL (Certificate Revocation List) [CSF + 08]. O primeiro mecanismo aparece em substituição do segundo e na correção de alguns problemas comuns às CRLs. As CRLs são ficheiros atualizados e mantidos pela CA, numa média global de vinte e quatro em vinte e quatro horas. É fornecido um caminho para que qualquer entidade que queira comprovar a validade de um certificado gerado pela CA possa descarregar esta lista e proceder a essa verificação. Um dos problemas das CRLs está associado a esta troca de informação pela rede inclusive o processamento dos dados no lado do cliente. O mecanismo OCSP vem corrigir esse problema, pois é a CA que processa o pedido do cliente e fornece uma resposta booleana relativa ao estado do certificado apresentado. Para além disto, as CRLs sofriam de outro problema: o tempos de atualização das listas. Como exemplo, caso uma lista seja apenas atualizada de hora a hora e no espaço de uma hora um certificado tenha sido revogado, qualquer pedido de certificação desse certificado será dado como válido, quando na realidade não o é. O uso do mecanismo CRL pode-se considerar como uma vantagem, principalmente para ambientes que não tenham uma ligação de rede fluída e estável, pois este não exige uma ligação constante à rede para obter o estado dos certificados. No nosso caso, optou-se pela utilização deste mecanismo dado que se verifica esta situação. No caso específico do Cartão de Cidadão a CA tem permissões para emitir, validar, suspender e revogar um certificado. Noutros casos uma CA poderia renovar certificados, mas essa prática não é suportada pela SCEE Autenticação eletrónica Como visto anteriormente, a autenticação de um utilizador dentro de um serviço eletrónico pode ser efetuada de diversas formas. A utilização do método nome de utilizador e palavrapasse é, atualmente, a forma mais utilizada para autenticação, mas o avanço da tecnologia requere outros métodos, outras tecnologias. A introdução de certificados digitais como método de autenticação eletrónica veio permitir adicionar uma camada de segurança nos mecanismos de autenticação. A entrada dos certificados na segurança eletrónica veio permitir que, não só possibilite autenticação de um utilizador, como a assinatura de documentos, excertos de texto, mails, entre outros, e ainda a comunicação segura entre a aplicação e o cliente, por via SSL. Existem hoje cada vez mais fatores de autenticação, e podemos classificá-los em três grupos distintos: ˆ Identificação do utilizador. Podem-se incluir neste grupo fatores como impressão digital, retina do olho, sequência de ADN, reconhecimento de voz e assinatura ou qualquer outro dado biométrico; ˆ O que o utilizador tem, seja um cartão de identificação, Token de segurança, Token de 19
34 software ou telefone; ˆ O que o utilizador conhece, como a palavra-passe, frase de segurança ou PIN. Aliando a estes fatores um objeto físico que agrega certificados digitais e mecanismos de autenticação temos em posse um documento suportado por fatores muito fortes de segurança, que engloba todos os fatores de autenticação. A autenticação com CC pode ser realizada de duas formas, seja por EMV-CAP (Europay, Mastercard and Visa Chip Authentication Program) ou através do par de chaves assimétricas de autenticação. Com o primeiro método, o utilizar consegue gerar uma OTP (One-time Password) inserindo o cartão num leitor pessoal e introduzindo o PIN de autenticação. A OTP obtida pode ser enviada a uma entidade que a consiga verificar e assim autenticar o titular. Usando o segundo método, cada vez que o titular pretenda usar a sua chave privada do par de chaves assimétricas de autenticação, o PIN tem que ser enviado para o smartcard. O smartcard possui um certificado X.509 com a chave pública de autenticação, que pode ser comunicado, posteriormente verificado e a chave privada de autenticação validada Middleware O middleware desenvolvido pelo estado português permite a interação entre o sistema operativo do smartcard do CC e o sistema operativo do computador do cliente e integra três interfaces diferentes, visto que o principal objetivo de desenvolvimento do middleware é o funcionamento multi-sistema operativo. São elas: ˆ Crypto API/CSP; ˆ PKCS#11; ˆ eid lib (biblioteca de desenvolvimento). A primeira apenas se encontra disponível para sistemas Windows, pois a comunicação do CSP (proprietária do middleware) com as aplicações é mediada pela Crypto API, enquanto que as outras duas interfaces se encontram disponíveis para Windows, Linux e Mac OS X. As duas primeiras interfaces são standards para operações criptográficas, enquanto que a última é principalmente direcionada para operações não criptográficas, isto é, para manipulação das informações básicas como nome, números de identificação, fotografia, entre outras. 2.4 REST APIs Recentemente, a arquitetura REST (REpresentational State Transfer) foi proposta como alternativa aos serviços Web existentes [Fie00]. Nesta era, marcada pelo aparecimento da Cloud e da expansão da internet, muitos serviços eletrónicos têm adotado esta arquitetura, principalmente devido ao aumento do número de dispositivos móveis e de todos os serviços feitos para eles. Esta arquitetura possui diversas vantagens em relação às até então existentes. Para além de ser uniforme e atribuir a cada recurso, ou informação, o seu próprio identificador, este é ainda um sistema fácil de construir, escalável e que comunica baseado em "pedidos/resposta", assente no 20
35 protocolo HTTP, aproveitando os pedidos do protocolo HTTP como GET e POST. Em verdade, todos esses pedidos são perfeitamente mapeados para as necessidades de aplicações com sistemas de informação por trás, podendo equivaler os métodos POST, GET, PUT, DELETE a Criar, Ler, Atualizar e Remover. As respostas enviadas para o utilizador podem seguir vários formatos, como XML ou HTML, mas o mais comum nos dias de hoje é o formato JSON. Este formato é nativo da linguagem Javascript e é baseado na notação "atributo : valor" onde o atributo representa o nome com o qual identificamos uma propriedade e o valor o atual valor dessa propriedade. Apesar de nascer dentro e para esta linguagem, este formato de resposta ganhou muita força, principalmente devido ao fato do JSON poder representar confortavelmente estruturas diferentes. Devido a esta conjetura, alguns dos serviços de armazenamento na nuvem possuem já as suas próprias REST APIs, como é o caso do Dropbox, Skydrive, Google Drive, MEO Cloud, que foram objeto de estudo detalhado no âmbito desta dissertação. Todos estes fornecedores de armazenamento implementaram as suas APIs proprietárias, os seus próprios objetos e também o formatos JSON mais convenientes para cada objeto criado. Este aspeto vem dificultar a tarefa de construir uma API uniforme para interação com todos eles. 2.5 Trabalhos relacionados Conforme os objetivos da dissertação não só é importante a análise de sistemas que implementam REST para se perceber como funcionam estas arquiteturas, como é necessário avaliar as capacidades dos protocolos de autenticação e autorização aliadas com Eid smartcards que possuam mecanismos de autenticação forte. Muitos trabalhos já foram desenvolvidos na área e têm por base a utilização de muitas destas componentes. Pascal Urien é o exemplo claro disso mesmo e em [Uri10] descreve um esquema baseado no protocolo de autenticação OpenID e um sistema de autenticação baseado em smartcards. O esquema especificado neste artigo é relativamente simples. A autenticação do utilizador é feita através de sessão SSL, aberta automaticamente pelo smartcard, aproveitando a autenticação forte oferecida por este dispositivo, isto é, ambos os lados lidam com certificados X.509 e chave privada RSA. O primeiro passo do mecanismo do sistema passa por ligar um smartcard a um dispositivo USB, com memória flash. Consequentemente este dispositivo é conectado ao computador e é estabelecida automaticamente a ligação entre o smartcard e o computador do utilizador. Ao iniciar uma sessão HTTP com o consumidor é mostrado um pequeno formulário para que o utilizador introduza o seu OPID (OP indentifier). Mais tarde, e conforme o utilizador necessite de se autenticar, será iniciado o processo apelidado de Discovery, que representa o passo em que a Entidade Confiante vai à procura do fornecedor OpenID correspondente ao OPID do utilizador. Posto este passo procede-se à validação da autenticação do utilizador. Enquanto que nas implementações clássicas de provedores a autenticação do utilizador é feita através da introdução da palavra-passe, no sistema de Urien a autenticação do utilizador é feita através de uma sessão SSL com autenticação mútua. Todo o restante processo de autenticação através do protocolo OpenID é seguido sem alterações. 21
36 Mais recentemente, Urien, implementa um novo sistema [Uri11], muito idêntico ao apresentado anteriormente, onde a principal diferença incide na introdução do mundo móvel e da possibilidade de utilização de smartcards das operadoras telefónicas, desde que estes possuam as funcionalidades de segurança necessárias. Outro trabalho que envolveu o protocolo OpenID foi a criação de um padrão publicado em RFC [LTHM12] onde a principal contribuição deste foi a especificação de um mecanismo para as frameworks SASL e GSS-API que permite a integração dos provedores de autenticação OpenID em aplicações que usem estas frameworks. Os sistemas de Urien incidem dentro do segundo cenário proposto para esta dissertação, pois os objetivos do sistema proposto são fundamentalmente iguais, com a diferença de que esta implementação funciona para cartões de identificação eletrónica nacionais, como o caso do Cartão de Cidadão Português. Apesar desta semelhança entre os sistemas de Urien e o nosso, explicado mais detalhadamente à frente, a primeira solução proposta neste trabalho está relativamente dispersa dos fundamentos destas. Enquanto que Urien utiliza um servidor OpenID baseado em autenticação através de certificados, com sessão SSL, a primeira arquitetura implementada neste trabalho utiliza o protocolo OAuth para autorização de uma terceira entidade, no nosso caso o CC, a aceder a recursos protegidos. Existem igualmente diversos trabalhos na área da autorização utilizando o protocolo OAuth, como [AS11a, AS11b], onde Al-Sinani descreve uma arquitetura que integra sistemas de cartões de informação, como o CardSpace (projeto atualmente descontinuado) ou o Higgins, e protocolos de autenticação e autorização, como o OpenID e o OAuth. Como já foi referido várias vezes, nesta dissertação foi considerada a utilização do Cartão de Cidadão que permite autenticação forte em serviços públicos e privados. Os cartões nacionais de Eid como o CC nasceram também como token de autenticação para serviços governamentais, como é o caso em Portugal onde o Cartão de Cidadão é atualmente utilizado para efetuar o processo de autenticação no Portal das Finanças Nacional. Mas outras implementações e estudos já surgiram para o CC, estando entre elas um sistema de autenticação e-health para profissionais de saúde [GCZ07], e ainda um sistema de gestão de identidades federado [PTP10]. O REST é uma arquitetura cheia de potencialidade e que trouxe grandes vantagens aos serviços Web e a todas as aplicações na internet. Como visto na secção 2.4 esta é uma arquitetura perfeitamente escalável, que possibilita a atribuição de um identificador único a cada objeto e torna o acesso a estes relativamente simples. Apesar desta arquitetura estar implementada em grande escala a muitos serviços de e-bussiness é de realçar que existam ainda muitos poucos casos da utilização desta arquitetura em sistemas de gestão, principalmente em sistemas de gestão de infraestrutura Cloud. Neste sentido Hyuck Han et al. cria um sistema capaz de fazer esta gestão de infraestruturas Cloud com base na arquitetura REST, chamando-lhe CMS (RESTful Cloud Management System). Neste artigo é demonstrado como os elementos geridos se podem tornar recursos REST e como operações existentes em sistemas podem ser avaliadas usando os quatro métodos REST, ou combinações entre eles. Para além disto é ainda descrito como componentes de sistemas de gestão 22
37 existentes podem ser lidos como serviços Web, em formato REST. Um estudo elaborado por Giuseppina Cretella et al. [CDM12] demonstra todas as técnicas de anotação existentes para descrição semântica de APIs expostas como serviços Web através de protocolos baseados em REST. No cenário da Cloud, os requisitos funcionais, como os pedidos ao nível dos serviços, são particularmente importantes para a caraterização de serviços Cloud. A técnica apresentada neste artigo inclui a descrição semântica de tais requisitos para a classificação de serviços Cloud. Em [VVE10], Toby Velte et al., analisam toda a infraestrutura Cloud, bem como todos os seus componentes incluindo a arquitetura REST e o formato de resposta JSON. A API desenvolvida no âmbito desta dissertação possui várias vantagens que se destacam das demais existentes, começando com o facto de ser livre (open source) e estar disponível para revisões e alterações. Para a partilha da biblioteca foi criado um repositório no Github 3 que contém toda a biblioteca desenvolvida. Nos casos de aplicações como o Otixo 4 ou o Jolidrive 5 o principal problema encontra-se neste fator, o não conhecimento público da API desenvolvida para integrar de forma uniforme todos os fornecedores implementados por eles. Ambas as aplicações implementam o protocolo de autorização OAuth, tal como no caso da API desenvolvida. Existem ainda outras bibliotecas públicas e que lidam com sistemas de Cloud, como a Delta- Cloud 6, que implementa diversos fornecedores de serviços na Nuvem. Contudo, esta biblioteca está desenvolvida e focada para a computação na Nuvem, e não tanto para aceder aos serviços de armazenamento. São poucos os fornecedores de armazenamento suportados por esta biblioteca e todos eles encontram-se fora do pretendido para esta dissertação, pois não existe suporte para OAuth, quer da parte desta biblioteca, quer dos fornecedores que ela implementa, à exceção do Google Storage. Tendo todos estes parâmetros em consideração optou-se por desenvolver uma API proprietária que correspondesse diretamente às exigências e necessidades da arquitetura proposta mais à frente, intitulada de Simploud. 3 https://github.com/joaojosegouveia/simploudapi.git 4 5 https://drive.jolicloud.com/welcome 6 23
38 24 Mecanismos de autenticação em serviços baseados em Cloud
39 Capítulo 3 Implementação Neste capítulo são apresentados os dois sistemas implementados no âmbito dos objetivos propostos para esta dissertação. Na primeira parte do capítulo será estudada e aprofundada a arquitetura e sistema implementados (com o nome de Simploud) para permitir a autenticação e autorização de utilizadores em fornecedores de armazenamento na Nuvem externos com o Cartão de Cidadão Português. Será apresentada também uma API que gere de forma completamente uniforme os pedidos e respostas obtidas por parte dos fornecedores externos abordados. O objetivo da segunda implementação é criar um serviço que permita o suporte da autenticação via Cartão de Cidadão em qualquer serviço que permita delegação de autenticação. Para isso foi criado um sistema que engloba duas aplicações, uma com um fornecedor OpenID e outra com uma Entidade que delega a autenticação ao primeiro. 3.1 Autenticação com CC via sessão SSL Em ambas as implementações, o Cartão de Cidadão funciona como método de autenticação fazendo uso do seu certificado para esse efeito. Ambas as soluções criadas são desenvolvidas em linguagens Web, mais precisamente ASP.Net MVC. A principal razão de escolha de uma aplicação Web, em vez de uma aplicação desktop, centra-se no suporte dos navegadores Web existentes para sessões SSL através da troca de certificados digitais. Outra razão óbvia refere-se ao facto de ser necessário que a troca dos parâmetros do certificado de autenticação do CC se processe dentro de uma sessão SSL, bem como todos pedidos e respostas obtidas do protocolo OAuth. Por estas razões optou-se por uma aplicação assente no navegador Web do cliente Certificados de servidor Primeiro que tudo é importante entender qual a diferença existente entre este tipo de certificados e os certificados de cliente. Um certificado de servidor é um certificado digital emitido para qualquer aplicação ou serviço Web por uma entidade certificadora confiante, conhecidas e abordadas nesta dissertação por CA. Um certificado de servidor verifica a identidade de uma dada organização ao cliente para que o cliente possa navegar, com segurança, através das aplicações e serviços Web dessa organização. Estabelece-se então uma relação de confiança em que o cliente sabe à partida que: ˆ as aplicações e serviços aos quais acede pertencem, de facto, a essa organização e não a um impostor; ˆ as transações entre servidor e cliente são cifradas. Neste caso os certificados funcionam como a identidade das aplicações e serviços Web perante os navegadores dos diversos utilizadores. Eles certificam o navegador de que aquela aplicação é quem diz ser. O esquema é tão simples quanto isto, embora na realidade seja necessário 25
40 algo mais para autenticar uma entidade na Web. Se uma aplicação Web criasse o seu próprio certificado de autenticação facilmente outro indivíduo mal intencionado poderia recriar este certificado e enviá-lo para o navegador dos utilizadores, sem que estes dessem conta de que estavam a aceder a aplicações falsas. Estaríamos perante um ataque de Phishing clássico, onde um indivíduo mal intencionado se faz passar por quem realmente não é para obter dados pessoais de utilizadores. A resolução deste problema está na criação de Autoridades de Certificação, reconhecidas a nível mundial como entidades confiáveis e onde, como já foi dito na secção , podem delegar este nível de confiança e fiabilidade aos certificados que ela própria cria. A validação e verificação da cadeia de certificados de uma dada aplicação passa a ser feita por estas entidades, delegadas pelo navegador do cliente. Falta então perceber como é feita a verificação destes certificados e como é que o canal estabelecido entre o servidor e o cliente é cifrado. Cada certificado possui uma chave de conhecimento público e uma chave privada. Esta chave privada apenas é do conhecimento da entidade tutora do certificado e da CA que o emitiu. As transações executadas entre servidor e cliente são cifradas com base neste par de chaves. Todos os dados que forem cifrados com a chave privada do certificado do servidor, apenas poderão ser decifrados com a chave pública do mesmo, e vice-versa. O processo de autenticação baseada em certificados é facilmente compreendido, podendo ser dividido em quatro fases: ˆ Primeira Fase: Caso a data atual não esteja em conformidade com o intervalo de tempo admitido pelo certificado, então quer dizer que o certificado se encontra fora do período de validade, o que faz com que o processo de autenticação termine imediatamente. Caso contrário o utilizador prossegue para o passo seguinte; ˆ Segunda Fase: Cada cliente SSL habilitado mantém uma lista de certificados de autoridade de certificação confiáveis. Esta lista determina quais os certificados de servidor que o cliente aceitará. Se o nome distinto (DN) da autoridade de certificação emissora coincide com o nome distinto da autoridade de certificação na lista de autoridades de certificação confiáveis do cliente, então a CA é uma autoridade de certificação confiável e o cliente procede para a próxima fase. Se a CA não estiver na lista, o servidor não é autenticado, a menos que o cliente encontre e possa verificar uma cadeia de certificados, terminando com uma autoridade de certificação que está na lista; ˆ Terceira Fase: O cliente faz uso da chave pública do certificado da autoridade de certificação (que deverá encontrar na lista de CAs confiáveis) para validar a assinatura digital da autoridade de certificação no certificado do servidor. Se as informações no certificado do servidor foram alteradas desde que este foi assinado pela autoridade de certificação, ou caso a chave pública do certificado de autoridade de certificação não corresponda à chave particular que foi usada pela CA para assinar o certificado de servidor, o cliente não autentica a identidade do servidor. Se a assinatura digital da autoridade de certificação pode ser validada, o cliente prossegue. Neste ponto, o cliente determinou como válido o certificado do servidor. ˆ Quarta Fase: Apesar deste passo não ser obrigatório, nem constar nas especificações do protocolo SSL, serve para evitar um conhecido problema criptográfico, dado pelo nome 26
41 de Man-In-the-Middle, ou Homem-no-Meio. Para evitar este ataque, o cliente apenas necessita verificar se o nome de domínio no certificado do servidor corresponde ao nome de domínio do próprio servidor. Caso estes nomes não coincidam, o cliente deverá recusar a ligação, pois poderá estar sob este tipo de ataque. No final deste processo o cliente e servidor estão aptos a comunicarem entre si de forma segura, tendo o cliente a certeza da identidade do servidor, através do seu certificado Criação da cadeia de certificados de servidor Para a criação da cadeia de certificados de servidor foi utilizado o software XCA (X Certificate and key management), que permite a criação e gestão de certificados X.509, pedidos de certificados, chaves privadas RSA, DSA e curvas elípticas, Smartcards e CRLs. Tudo o que for necessário para uma Autoridade Certificadora é implementado neste programa. Todas as CAs podem assinar CAs de camadas inferiores recursivamente, possibilitando a criação de cadeias de validação de certificados. O uso deste software foi importante exatamente para esse processo, a criação do certificado de servidor utilizado, bem como da cadeia de certificados que valida o próprio. A cadeia construída para a validação de certificados segue a estrutura da Figura 3.1, onde foram criados três certificados por esta entidade: o certificado da CA, o certificado assinado por esta e utilizado como certificado de servidor para a aplicação Simploud e ainda o certificado de servidor, igualmente assinado por esta CA, para o servidor OpenID. A implementação desta estrutura de certificação permite que a entidade emissora criada consiga gerir todos os certificados assinados por ela. Desta forma, para além de podermos ter um número de certificados ilimitados e totalmente controlados por esta entidade, podemos ter vários servidores a correr as aplicações de forma distribuída. Sempre que um certificado for comprometido ou simplesmente revogado, a aplicação continuará a correr através de outros servidores, assentes em certificados idênticos. Figura 3.1: Cadeia dos certificados de chave pública construída para as arquiteturas Simploud e OpenID Provider 27
42 Para a criação dos certificados é necessário criar uma base de dados local, acedida pela própria aplicação, para guardar todo o trabalho desenvolvido. Como esta base de dados guarda informações importantes, e é necessário que ninguém para além do criador da mesma aceda a ela, é guardada localmente completamente cifrada. Posto isto, para a criação do certificado de raiz da CA basta configurar o software XCA da seguinte forma: ˆ Clicar no botão New Certificate; ˆ Definir o formato do certificado a ser criado como [default] CA; ˆ Selecionar o separador Subject: Escolher um Internal Name, nome com a função de identificar o certificado na ferramenta; Preencher os dados referentes ao Distinguished Name, onde o Common Name, no nosso caso, foi Spocs Certificate Authority. Caso se pretenda podem ser adicionados parâmetros adicionais a este campo; Selecionar a chave privada desejada, podendo-se optar pelos tamanhos de 1024, 2048, 4096 bits e pelos algoritmos criptográficos RSA, DSA ou Curva Elíptica. ˆ Clicar de seguida no separador de extensões e definir o parâmetro de Time Range. Um valor aceitável para este intervalo de validade deverá ser de dez anos; ˆ Por fim é importante definir um URL para a CRL da CA, algo do género /crl/crl.der. Para a criação do certificado de servidor é necessário que se sigam os mesmos passos, com pequenas alterações: ˆ O formato a utilizar é [default] HTTPS_server; ˆ Na secção Signing, é necessário escolher o certificado que vai assinar o novo certificado a ser criado; ˆ O parâmetro Common Name deverá conter o caminho especificado para o site, pois considera-se uma boa prática. Assim sendo deverá ser algo como spocs.it.ubi.pt:444/simploud; ˆ Caso exista uma CRL (criada no primeiro certificado), o campo da CRL deverá ser preenchido com o mesmo endereço colocado em cima. Posto estes dois processos executados, deverá estar criada a estrutura considerada para esta implementação, com um certificado de raiz da CA com o nome de Spocs Certificate Authority e um certificado de servidor intitulado de spocs.it.ubi.pt:444/simploud, assinado com a chave privada da CA referida acima. 28
43 3.1.2 Certificados de cliente Em muitos casos de implementações, é necessária a autenticação através de certificados de cliente, para que o cliente prove a sua identidade ao servidor e assim se estabeleça uma ligação de confiança mútua entre ambas as partes. Na secção anterior falou-se de certificados de servidor, onde o cliente procura autenticar a identidade do servidor. Mas desde sempre as aplicações e serviços Web precisaram de métodos de autenticação dos seus utilizadores. Um dos mecanismos que mais benefícios traz aos sistemas desenvolvidos pela internet fora baseia-se em certificados de cliente. Este processo consiste, ao contrário dos certificados de servidor, na necessidade do servidor autenticar a identidade do cliente. Este processo traz enormes vantagens e exemplos disso são: ˆ através de sessão SSL, fazer autenticação em aplicações e serviços Web; ˆ permitir autenticação multi-fator (uma aplicação Web poderia pedir informação que apenas o utilizador conhece, por exemplo palavra-passe, e o que possui, como o certificado). Atualmente é possível criar nestes serviços uma instrução de obrigação para que quem acede a eles necessite apresentar um certificado digital, algo que apenas este indivíduo possui. Seguindo este raciocínio foi implementada esta função na aplicação desenvolvida, para que apenas utilizadores titulares de cartões Smartcard se possam autenticar e utilizar esta aplicação. Para implementar a autenticação forte através do certificado de autenticação do Cartão de Cidadão foi necessário proceder a algumas adaptações. De modo a que o servidor efetue o pedido do certificado existente no Cartão de Cidadão, são necessários diversos passos, apresentados de seguida Instalação de certificados de raiz do CC De modo a ser validada a totalidade da cadeia de certificação do certificado presente no Cartão de Cidadão, é necessário adicionar os respetivos certificados à loja de certificados do Windows, sistema operativo que se encontra instalado no servidor onde foi instalada a aplicação Web. Para se proceder à instalação de todos os certificados do Cartão de Cidadão basta fazer a transferência dos certificados 1 e colocá-los dentro da pasta Trusted Root Certification Authorities. Uma das formas possíveis de validar que os certificados ficaram corretamente instalados, é abrindo o certificado cliente na máquina onde está a ser efetuada a instalação. O certificado não deverá apresentar nenhum erro ou aviso, sendo que a cadeia de certificação deverá aparecer com a indicação de que o estado de cada certificado é OK Configurar o servidor para ligações SSL Configurar o servidor para ligações SSL é acima de necessário, obrigatório, não só por causa do uso de certificados digitais mas também porque todo o protocolo OAuth assim o obriga. Este processo é simples e apenas requere que aquando da publicação da aplicação Web no servidor 1 Certificados do Cartão de Cidadão disponíveis em n=com_content&task=view&id=113&itemid=100&lang=pt.html 29
44 Spocs, pertencente ao Instituto de Telecomunicações da Universidade da Beira Interior, seja criada a cadeia de certificados referida em e que a aplicação tenha como certificado para criação de sessão SSL o certificado de servidor dessa cadeia. No IIS, este processo requere a criação de um novo website, e ligar o suporte para sessão SSL, ao selecionar a opção Bindings, depois adicionar uma nova ligação com o tipo definido como HTTPS e colocar o certificado de servidor SSL criado para o efeito Configurar o servidor para aceitar certificados digitais de clientes A configuração do servidor para aceitar certificados digitais de clientes pode ser efetuada através da alteração do ficheiro de configuração da aplicação Web.config servindo para isso colocar as linhas de código apresentadas em 3.1. Outra possibilidade para alterar esta configuração é, selecionar a aplicação no gestor do IIS, clicar de seguida em SSL Settings e marcar a opção para requerer SSL e não esquecer que é necessário colocar o estado da variável Client Certificates como Required. < s e c u r i t y > < access s s l F l a g s = " Ssl, S s l N e g o t iatecert " /> </ s e c u r i t y > Código 3.1: Alteração da configuração para permitir a aceitação de certificados de cliente Configurar o servidor para aceitar o certificado do Cartão de Cidadão Os servidores estão normalmente configurados para pedir e aceitar certificados clientes que sejam emitidos pelo seu LDAP (Lightweight Directory Access Protocol). O manual técnico do Cartão de Cidadão indica que se deva configurar o servidor de modo a aceitar igualmente certificados emitidos pela entidade certificadora emissora dos certificados presentes no Cartão de Cidadão, mas através do código anterior qualquer tipo de certificado de cliente instalado na loja de certificados pode ser escolhido pelo utilizador Validação aplicacional do certificado De forma a garantir que só são aceites certificados presentes nos Cartões de Cidadão, o código desenvolvido para autenticação deve validar um conjunto de parâmetros presentes no certificado, de forma a garantir a origem do certificado. Para efetuar esta validação é necessário efetuar todas as verificações abordadas na secção e ainda garantir que apenas os certificados do Cartão de Cidadão podem autenticar-se neste serviço, tendo que se recorrer a uma função de filtragem construída a nível aplicacional (ver Anexo A.2.1), através da análise dos parâmetros que constituem o Nome Distinto do certificado (DN) Validação de validade do certificado A última validação é efetuada pela entidade emissora do certificado, de modo a garantir que o certificado não foi revogado. Para isso a aplicação Web envia um pedido de verificação para a CA do certificado e esta verifica a sua validade, bem como suspensão ou revogação através do recurso à sua CRL. O esquema 3.2 é representativo de como se processa a troca de informações entre cliente, aplicação e PKI do estado, ao longo do processo de autenticação do cliente que tenta aceder à aplicação. 30
45 Figura 3.2: Esquema de utilização do Certificado de Autenticação 3.2 Autenticação com CC em fornecedores de armazenamento na Nuvem A arquitetura deste sistema tem como objetivo principal aumentar os padrões de segurança atualmente utilizados pelos principais fornecedores de armazenamento na Nuvem existentes, como o caso do Dropbox, MEO Cloud e Skydrive. Em todos estes serviços, e seguindo a principal tendência da Web nos dias de hoje, todos estes serviços têm como método de autenticação o par nome de utilizador e palavra-passe. Com a evolução da internet é essencial que a segurança dos sistemas, aplicações e serviços que estão assentes nela, evolua lado a lado com esta tendência de exponenciação de serviços existentes. Seguindo esta ideia e olhando para a atual conjetura da Web percebemos que o foco principal desta dissertação deve ser as infraestruturas na Nuvem, não só porque existe uma evolução clara neste sentido, como cada vez mais os utilizadores adotam estas soluções para guardar os dados. Desta forma, a implementação do sistema Simploud foca-se nos fornecedores de armazenamento na Nuvem mais conhecidos e utilizados para guardar recursos, como o caso da Dropbox, MEO Cloud e Skydrive, casos de estudo desta dissertação. Para estes fornecedores é essencial, para além das condições e capacidades de armazenamento oferecidas aos utilizadores, que existam fortes políticas de segurança e privacidade, pois convém dizer que não é fácil para todos os utilizadores confiar os seus dados privados a estas entidades. Mais difícil ainda será convencer outras empresas, com dados privados que podem comprometer o seu próprio negócio, a guardar os seus dados na Nuvem. Neste sentido o Simploud agrega, numa primeira fase, todos os três fornecedores anteriormente falados e aproveita a implementação do protocolo OAuth por parte destes serviços para criar um novo método de autenticação, que alia ao OAuth a autenticação forte disponibilizada pelo Cartão de Cidadão. 31
46 3.2.1 API uniforme para interação com os diferentes fornecedores de armazenamento Ao criar uma aplicação que tem como função principal agregar num único ponto de acesso diferentes fornecedores de armazenamento na Nuvem é normal que se encontrem em pedidos semelhantes (obter um ficheiro por exemplo), diferenças notórias, pois cada fornecedor tem as suas próprias implementações dos mecanismos de acesso e autorização. Desta forma foi desenvolvida uma API para fazer a agregação dos diferentes fornecedores e interagir de forma uniforme com as suas APIs baseadas em REST. Como explicado anteriormente, cada fornecedor implementa as suas próprias versões do protocolo OAuth, define os seus objetos e formatos JSON devolvidos nas respostas. De facto, a escolha dos fornecedores não incidiu apenas no facto de que são os fornecedores mais conhecidos e utilizados pelos utilizadores, mas também porque cada um deles implementa uma versão diferente do protocolo OAuth. Assim sendo, podemos afirmar que para além de termos uma API que suporta vários fornecedores de armazenamento, existe ainda um suporte extensivo ao protocolo OAuth. Todos estes parâmetros que diferenciam as diferentes APIs significam em pequenas diferenças que tornam a tarefa de criar uma API cuidadosa e trabalhosa, mas necessária. O desenvolvimento da API é separada em dois módulos distintos: um módulo destinado para as transações do mecanismo OAuth e outro que executa todos os pedidos relacionados com a gestão dos ficheiros e pastas do utilizador. O primeiro módulo foi construído com o objetivo de implementar todos os métodos e passos para a obtenção de um Token de autorização, recorrendo ao protocolo OAuth. Para apoiar esta implementação usou-se uma adaptação da classe OAuthBase.cs (Anexo A.3.1), disponibilizada pelos criadores deste mecanismo e que gere a criação de uma assinatura correspondente ao pedido efetuado, um Timestamp e um Nonce. Estes parâmetros têm como função definir um intervalo de tempo aceitável para a aceitação de um determinado pedido e atribuir a esse pedido um código único, respetivamente. Esta adaptação da classe de base fornecida pelo OAuth foi necessária para implementar o parâmetro de verificação oauth_verifier respeitante ao fornecedor MEO Cloud e também a necessidade de gerar assinaturas de pedidos que contivessem o parâmetro de redirecionamento junto com os parâmetros desses pedidos. Para a Dropbox, que implementa a versão 1.0 do OAuth, o pedido de redirecionamento é feito durante o envio do pedido de autorização (Anexo A.3.2, método GetAuthorizeUri), com o redirecionamento a ser incluído num dos parâmetros do pedido. Já no caso do MEO Cloud o pedido de redirecionamento entra como parâmetro no primeiro passo do protocolo, no pedido de obtenção do Request Token e este parâmetro adicional entra no processo da geração de assinatura para esse pedido. Daí a necessidade de adaptação desta classe previamente fornecida para este caso específico. O módulo de OAuth foi totalmente implementado, contendo as diversas fases de autorização deste protocolo, como de resto se pode verificar no Anexo A.3.2. Primeiro são definidas as variáveis dos endereços finais, variáveis essas que complementam todos os URLs de pedidos feitos à API do fornecedor. Os métodos GetRequestToken, GetAuthorizeUri e GetAccessToken são implementados de seguida e implementam todo o mecanismo OAuth para obtenção de autorização. O primeiro destes três envia um pedido para a obtenção de um Request Token e a resposta é guardada no objeto Token (Código 3.2), criado para o efeito. De seguida é enviado um 32
47 pedido para obter autorização por parte do proprietário dos recursos, sendo para isso necessário que este se autentique com as suas credenciais no Website do fornecedor e autorize o acesso ao consumidor de recursos, neste caso a aplicação Simploud. O passo final diz respeito ao envio do pedido de Access Token, onde o utilizador irá receber um Token. O método referente ao pedido de assinatura foi criado exatamente para assinar os diferentes pedidos especificados anteriormente. public c l a s s OAuthToken public OAuthToken ( s t r i n g token, s t r i n g secret ) Token = token ; Secret = secret ; public s t r i n g Token get ; p r i v a t e set ; public s t r i n g Secret get ; p r i v a t e set ; Código 3.2: Classe OAuthToken criada para guardar todos os Tokens obtidos Existem algumas diferenças a enunciar durante todo este processo em relação aos diferentes fornecedores considerados: ˆ introdução do parâmetro oauth_verifier para a implementação da API do fornecedor MEO Cloud, devido à utilização da versão 1.0a do protocolo OAuth, enquanto que as versões implementadas para a Dropbox e Skydrive são, respetivamente, as versões 1.0 e 2.0. É ainda de referir que em Julho de 2013, a Dropbox implementou a versão 2.0 do OAuth, continuando a suportar a versão anterior; ˆ o modo de redirecionamento para a aplicação é diferente nos três fornecedores: na Dropbox e Skydrive o redirecionamento é efetuado junto com o pedido de autorização, logo não requer assinatura, enquanto que na MEO Cloud o parâmetro de redirecionamento é feito junto do pedido de Request Token, sendo assim necessário adaptar a classe OAuthBase.cs para permitir assinar pedidos que contenham mais este parâmetro; ˆ no Skydrive o método RequestToken não é implementado pois o mecanismo de autorização envia este objeto junto com a resposta ao pedido de autorização; ˆ no Skydrive, a obtenção do Access Token processa-se através do método HTTP POST e o conteúdo deve estar especificamente formatado sob a forma application/x-www-formurlencoded e a resposta obtida, em formato JSON é desserializada para o objeto AccessToken A.3.4, enquanto que na Dropbox e MEO Cloud o método HTTP utilizado é GET e usa-se o objeto OAuthToken para guardar a resposta obtida. Concluído o processo de autorização é então permitido ao utilizador, através do uso da aplicação Web, gerir da forma que bem entender o acesso que este detém sobre os recursos. Desta forma, foi necessária a implementação de um segundo módulo na API que consiste no tratamento uniforme dos pedidos feitos aos diferentes fornecedores. Existem também neste módulo diversas diferenças entre fornecedores, enumeradas de seguida: ˆ Dropbox: Implementa três tipos diferentes de respostas JSON, uma para caraterizar os detalhes de conta de utilizador, outra para informação acerca de ficheiros e por último 33
48 uma para diretorias. A diferença entre os objetos File e Folder é o atributo contents que está presente apenas no objeto Folder e representa a listagem de conteúdos de uma diretoria (Anexo A.3.4). A especificação de acesso a conteúdos do utilizador é feita através da notação de caminho, sendo única para cada conteúdo; ˆ MEO Cloud: Os formatos JSON atualmente utilizados por este fornecedor são idênticos aos usados pela Dropbox, bem como os objetos considerados, um tipo para ficheiros e outro para diretorias; ˆ Skydrive: Implementa a versão 2.0 do OAuth e faz uso de todas as alterações associadas à versão deste protocolo, como a implementação do conceito de Token de refrescamento e escopos. Quando o protocolo se inicia é necessário especificar quais os escopos a serem utilizados nesta aplicação (consideramos ser apenas necessários os escopos wl.basic e wl.skydrive_update; o primeiro serve para retirar informações do perfil de utilizador, sendo que no caso desta aplicação apenas serve para retirar informação acerca do espaço de armazenamento ocupado e disponível; o segundo permite acesso à leitura e escrita em ficheiros guardados no Skydrive). Após este procedimento, a aplicação está apenas autorizada pelo utilizador a aceder aos escopos designados. Com esta versão do OAuth, e olhando particularmente para este fornecedor, os tokens de acesso obtidos contêm uma data de expiração, de uma hora, e no final deste período é necessário refrescar o acesso do consumidor ao serviço. Utilizando o mecanismo de refrescamento do protocolo OAuth é possível obter um novo token sem que o utilizador se aperceba deste processo. Sobre as respostas JSON, o Microsoft Live Connect, API REST do Skydrive possui objetos para Activity, Album, Application, Audio, Calendar, Comment, Contact, Error, Event, File, Directory, Friend, Permission, Photo, Quota, Tag, User and Video. Apesar da existência de todos estes objetos, apenas alguns deles são necessários para o Skydrive. A API desenvolvida apenas implementa os objetos File, Directory, Quota e User, pois estes são os necessários para o funcionamento mínimo da aplicação. Os últimos dois são necessários para extrair o do utilizador autenticado e também informação acerca do espaço de armazenamento ocupado e disponível, guardados na estrutura Quota e Account (ver Anexo A.3.4 para mais detalhes). O último detalhe que distingue este fornecedor dos anteriores é o acesso aos conteúdos, pois em vez de fazer uso de especificação de caminhos, cada objeto de ficheiro ou pasta possui um parâmetro id que representa o seu identificador único. Apesar de todas as diferenças especificadas todos eles possuem semelhanças em alguns aspetos. Por exemplo, apesar da estrutura dos pedidos URL ser diferente para cada fornecedor, os passos que compõem o processo de autorização até ao acesso final aos recursos protegidos são idênticos, tal como todos os fornecedores implementam o mesmo tipo de funções e operações sobre ficheiros: Download, Upload, listagem, partilha, cópia, renomear, histórico de versões para recuperação de ficheiros, mover e apagar. A API desenvolvida implementa praticamente todas estas operações, à exceção da partilha de conteúdos com outros utilizadores e a recuperação de versões anteriores, como se pode verificar pelo exemplo do Anexo A.3.3, onde estão implementadas os métodos: ˆ GetAccountInfo para obter informação acerca da conta do proprietário dos recursos; 34 ˆ GetFiles para obter o conteúdo de uma pasta, e consequentemente listá-lo;
49 ˆ CreateFolder, Rename e Delete para criar uma pasta, renomear e remover um ficheiro ou pasta, respetivamente; ˆ DownloadFile e UploadFile para transferência e carregamento de ficheiros Arquitetura do sistema Simploud A arquitetura do sistema tem em consideração os objetivos principais deste projeto e, desta forma, podemos considerar quatro principais entidades a considerar para a realização dos objetivos propostos: ˆ Cartão de Cidadão: é talvez a entidade central dentro da arquitetura proposta. No Simploud o CC tem como principal função o uso do certificado de autenticação para que o titular do cartão se possa autenticar no sistema; ˆ Aplicação: A aplicação Web construída tem como principal função fazer a ligação entre o Cartão de Cidadão e o ambiente Cloud. É função desta entidade garantir a validação da autenticação e, posto isto, gerar os tokens de acesso aos recursos protegidos e também executar todos os pedidos às APIs dos fornecedores de armazenamento na Nuvem; ˆ API: Foi necessário para esta implementação criar uma API que possibilitasse o acesso uniforme a todos os fornecedores implementados. É normal que, apesar de existirem normas e definições protocolares obrigatórias a seguir, cada fornecedor implemente próprias definições de objetos, atributos e haja diferenças na utilização dos protocolos implementados. Para normalizar estas disparidades aos olhos de um programador adicionou-se esta camada adicional que estabelece a ligação entre a aplicação proprietária e os fornecedores de armazenamento na Nuvem; ˆ Ambiente Cloud: Esta entidade representa todos os fornecedores de armazenamento na Nuvem, todos os seus protocolos, métodos, objetos e atributos. É a API desenvolvida que estabelece a ligação com esta camada e gere os pedidos feitos e respostas obtidas à Nuvem. O esquema geral da arquitetura do sistema apresentado na Figura 3.3 relaciona as quatro entidades anteriormente referidas, através de processos, pedidos e respostas entre elas. Tudo começa com a autenticação do titular do cartão. O processo de autenticação de um utilizador está relacionado com a validação do certificado que este apresenta (1). Se o certificado não for validado, o utilizador não se consegue autenticar e o processo é interrompido. Caso o primeiro e segundo passo (2) sejam efetuados com sucesso, a aplicação vai usar dados referentes ao certificado e guardá-los numa base de dados (3). Caso, após os dados serem guardados na base de dados, o utilizador se tente autenticar com o mesmo certificado e se este for dado como revogado, expirado, suspenso ou inválido, então os dados referentes a este certificado são eliminados da mesma, afim de garantir a segurança, integridade e consistência dos dados. O principal objetivo desta base de dados é guardar dados referentes ao processo de autenticação e à geração de Tokens pelo protocolo OAuth, relacionando estas duas entidades, o cartão de Cidadão como identificador digital do utilizador e os fornecedores de armazenamento como gestores dos recursos desse mesmo utilizador. A Figura 3.4 representa o Modelo da base de dados proposta na integra. 35
50 Figura 3.3: Esquema geral da arquitetura do sistema Simploud Esta base de dados está dividida em três tabelas distintas: ˆ A tabela Certificate representa e guarda os dados necessários correspondentes ao certificado de autenticação do Cartão de Cidadão. Contém os atributos: IssuerName: contém o nome do certificado e o nome do emissor; SerialNumber: representa o número de série do certificado. Juntamente com o IssuerName formam a chave primária da tabela, servindo de identificador único do certificado; PublicKey: é ainda guardada a chave pública do certificado, embora não seja aplicada em nenhum contexto específico. ˆ A tabela Cloud guarda os dados referentes aos diferentes fornecedores de armazenamento considerados para este sistema. Fazem parte dela os seguintes atributos: CloudID: identificador único e também chave primária da tabela que guarda um valor para entrada na tabela; Name: representa o nome dos fornecedores de armazenamento na Nuvem considerados. ˆ A tabela Register estabelece a ligação entre as duas tabelas anteriores, sendo que a chave primária desta tabela é uma chave conjunta das chaves primárias das tabelas anteriores. Podemos identificar como chave primária os atributos IssuerName, SerialNumber e CloudID. Para além destes atributos, esta tabela reserva ainda espaço para armazenar a informação relativa aos Tokens obtidos: AccessToken: representa o identificador do Token obtido; AccessTokenSecret: guarda a informação referente ao segredo do Token obtido. Para efeitos de segurança são apenas guardados, na base de dados, os valores do hash dos dados referentes ao Cartão de Cidadão. O mesmo procedimento não pode ser efetuado para os dados 36
51 Figura 3.4: Modelo da base de dados que suporta a arquitetura Simploud referentes aos tokens de acesso dos fornecedores de armazenamento, visto serem definitivos, exceto no caso do Skydrive, e ser necessário saber o seu valor real para efeitos de autorização de pedidos em próximas sessões que não a primeira. A cifra destes dados poderia ser efetuada através de mecanismos de cifra simétricos ou assimétricos, gerados pelo próprio servidor de base de dados, onde esta se encontra guardada, mas este processo não é necessário devido ao facto do potencial acesso à base de dados e consequente roubo do token de acesso levar a nenhuma consequência, a não ser que o atacante consiga também saber qual a chave que o consumidor (a nossa aplicação) guarda. A consequência de não guardar estes dados implicava que, a cada sessão iniciada com a aplicação, fosse necessário dar nova autorização para se aceder aos recursos protegidos na Nuvem. De qualquer das formas, é sempre assegurada a comunicação SSL entre cliente e servidor. Focando de novo a arquitetura da aplicação. Ao guardar os dados referentes à autenticação da identidade do utilizador, a API desenvolvida tem como objetivo interagir com o protocolo OAuth afim de obter todos os tokens necessários até à obtenção do token de acesso, o símbolo final deste protocolo que garante acesso aos dados protegidos, com autorização do proprietário dos recursos (4). Ao obter este token final, que lhe permite aceder aos recursos protegidos, é importante guardá-lo na base de dados (5), pois caso contrário sempre que o utilizador criar uma nova sessão é necessário iniciar de novo o mecanismo OAuth. Com o token guardado na base de dados e também os dados referentes à autenticação procede-se de seguida à ligação entre estas duas entidades, envolvendo ainda uma variável que indica qual o fornecedor escolhido, e assim ligar o utilizador ao token respetivo a um dado fornecedor (6). Com o token guardado na base de dados e autenticação efetuada o utilizador está em condições de gerir e manipular (7) os dados protegidos na Nuvem referentes a um fornecedor de armazenamento específico Modelo de segurança Os requisitos básicos de segurança que um sistema criptográfico deve fornecer são Confidencialidade, Integridade, Autenticação e Não-Repúdio. A segurança deste sistema como um todo, irá depender de cada um dos elementos que o constitui. Assim, o sistema depende do Cartão de Cidadão como objeto de autenticação de identidade eletrónica, através do certificado de autenticação que este possui, nos canais de comunicação utilizados entre o cliente e a aplicação 37
52 Web, e entre a aplicação e a base de dados, sendo que esta guarda dados sensíveis, na resistência a ataques que possam ocorrer durante o processo de autorização através do protocolo OAuth e ainda a segurança do esquema IBE (Identity Based Encryption) implementado para o carregamento e transferência de ficheiros cifrados para o fornecedor de armazenamento na Nuvem. Neste tipo de sistema, em que a autenticação se processa através da troca de certificados de cliente, é importante que seja impossível para um atacante fazer-se passar por um utilizador válido, neste caso um titular do Cartão de Cidadão. Pressupõem-se que os canais de comunicação entre a aplicação e o cliente sejam seguros, e para isso todas as comunicações decorrem sobre o protocolo SSL, onde é impossível para um atacante obter a chave privada do certificado do servidor, estando assim impossibilitado de decifrar os dados que vão passando pelo canal. De igual forma, pressupõem-se que os canais de comunicação entre a aplicação e a base de dados sejam seguros, e que apenas os utilizadores fidedignos da aplicação (que já provaram a sua identidade) possam aceder a esta, tanto para efeito de leitura, como de escrita. Em relação ao CC, é pressuposto que um atacante não consegue alterar informação sensível guardada no chip do mesmo, como por exemplo o par de chaves que suportam o certificado de autenticação. É igualmente pressuposto que, durante o processo de autenticação, seja estabelecida uma relação de confiança entre a CA emissora do certificado do CC e a aplicação. O sistema pressupõem ainda que não existam qualquer tipo de falhas no mecanismo do protocolo OAuth para obtenção de autorização de acesso a recursos protegidos Esquematização da Attack Tree para esta arquitetura As Attack Trees estão relacionadas com o formalismo de Fault Trees, usado inicialmente pela NASA (National Aeronautics and Space Administration) em [VDF + 02], e representa um conjunto de falhas relacionadas através de expressões booleanas e que, acontecendo em sucessão poderiam provocar falhas graves determinadas na raiz dessa árvore. Esta metodologia foi trespassada para várias ciências e, atualmente, é muito utilizada em segurança para descrever esquemas que potencialmente levariam ao colapso de toda a segurança do sistema. As Attack Trees fornecem a possibilidade de modelar potenciais ameaças contra os sistemas informáticos de forma metódica [Sch99]. O primeiro elemento a ser definido neste modelo é qual o objetivo do ataque. Este elemento será a raiz da árvore. Posto isto, é necessário encontrar e identificar as diferentes maneiras de conseguir este objetivo. Estas representações seguem a definição de que os Children nodes são condições que devem ser satisfeitas, para que o Parent node seja verdade. Seguindo esta nomenclatura, a árvore que demonstra os ataques possíveis para satisfazer a premissa maior deste sistema, que consiste no acesso a dados protegidos por parte de um atacante, é apresentada na Figura 3.5. Esta árvore indica dois caminhos possíveis para satisfazer a condição principal: ˆ O atacante aceder à base de dados do fornecedor de armazenamento e conseguir retirar os dados de login de um utilizador, aliado à posse do cartão de identificação eletrónica desse mesmo utilizador, e consequentemente conhecer o PIN de autenticação deste cartão. Se estas três condições forem satisfeitas, o utilizador é capaz de gerar um token de acesso sem o consentimento do real proprietário dos recursos e o atacante passa a ter acesso aos dados privados deste; 38
53 Figura 3.5: Attack Tree para a arquitetura proposta ˆ O atacante aceder à base de dados do Simploud e obter os tokens de acesso, aliado ao conhecimento da chave de consumidor, que só consegue obter através da análise do código compilado em tempo de execução. Se estas duas condições forem satisfeitas, o atacante passa a ter acesso aos dados protegidos correspondentes aos tokens anteriormente obtidos. Ao identificarmos os possíveis caminhos que dariam a um atacante a possibilidade de obter acesso a dados que não lhe pertenciam (falha ao nível da Confidencialidade e Disponibilidade dos dados) foram tomadas medidas que, de certa forma, permitem reforçar a segurança com a finalidade de evitar que este cenário seja possível. Podemos dizer que embora existam quatro caminhos possíveis, apenas dois são da nossa responsabilidade e que, representando um perigo para a segurança do utilizador foram tidas em conta as seguintes alterações: ˆ os dados referentes ao token de acesso guardado na base de dados passaram a ser guardados e cifrados com recurso ao esquema de chave simétrica implementado pelo próprio servidor de base de dados (no nosso caso o SQL SERVER 2012); ˆ utilização de técnicas de ofuscação de código para proteger o acesso às chaves de consumidor e o seu respetivos segredos (um par para cada fornecedor implementado nesta solução) Integração da API desenvolvida numa aplicação proprietária A aplicação desenvolvida para estabelecer ligação entre o Cartão de Cidadão e os fornecedores de armazenamento foi criada, como referido anteriormente, na linguagem ASP.Net MVC e faz uso de todos os mecanismos dos navegadores Web mais recentes para estabelecer uma sessão SSL com o cliente e de seguida iniciar todas as transferências protocolares até à obtenção de acesso aos recursos protegidos. A API desenvolvida permite implementar fácil e uniformemente todos os pedidos executados às arquiteturas REST dos fornecedores de armazenamento considerados, seja durante o processo 39
54 de autorização, seja através dos pedidos para gestão de ficheiros. Como se pode analisar através do Anexo A.1.2, apesar dos métodos AuthorizeDropbox, AuthorizeCloudPT e AuthorizeSkydrive corresponderem à autorização nos diferentes fornecedores considerados, os métodos da API chamados são iguais, mudando apenas o nome do fornecedor que estamos a considerar. O mesmo acontece com o pedido para obter o token de acesso e todos os outros pedidos referentes a gestão dos recursos (Anexo A.3.3). Deste modo podemos concluir que a API desenvolvida satisfaz os propósitos para que foi inicialmente criada, tornando os métodos de autorização e de gestão de recursos completamente uniformes, apesar de se estar a trabalhar com diferentes fornecedores de armazenamento na Nuvem Implementação de um esquema de IBE e políticas de acesso a ficheiros No âmbito do projeto PRICE surgiram vários trabalhos paralelos a este, entre eles, a implementação de vários serviços de IBE baseados nas propriedades criptográficas do Cartão de Cidadão. O objetivo deste trabalho consistia na criação de vários sistemas que permitissem, através de um sistema de IBE aliado ao processo de autenticação forte do Cartão de Cidadão, cifrar e decifrar ficheiros. Para implementar este sistema de IBE nesta aplicação Web foi utilizada uma biblioteca desenvolvida em C#, que utiliza o esquema Emribe e permite implementá-lo num sistema para a cifra e decifra de ficheiros. Esta biblioteca tem como funcionalidades principais a geração de parâmetros públicos e privados, a geração de chaves privadas correspondentes a uma identidade e a cifra para múltiplas identidades e respetiva decifra de ficheiros. A função do PKG é gerar os parâmetros de sistema necessários (parâmetro privado s e parâmetros públicos P, Q, P pub e ê(q,p pub )) e a geração de uma chave pública para cada identidade. A geração destes parâmetros pode ser efetuada com recurso às funções presentes na biblioteca: ˆ byte[] GenerateMasterKey(string curve); ˆ byte[] GeneratePparam(string curve); ˆ byte[] GenerateQparam(string curve); ˆ byte[] CalculatePpubparam(string curve, byte[] Pbyte, byte[] masterkey); ˆ byte[] CalculatePairQPpub(string curve, byte[] Qbyte, byte[] Ppubbyte); Após o uso destas funções a chave privada pode ser gerada, mas deve ser apenas do conhecimento do PKG. Todos os restantes parâmetros, são de conhecimento público e são utilizados para a cifra e decifra de ficheiros. As funções disponibilizadas para cifra e decifra tem a seguinte assinatura: ˆ MemoryStream EncryptStream(string[] identities, string policy, MemoryStream streamin, string originalfilename, string curve, byte[] paramp, byte[] paramq, byte[] parameqppub); 40
55 ˆ MemoryStream DecryptStream(string identity, byte[] privatekey, MemoryStream streamin, string curve, byte[] paramppub); Como se pode verificar pela assinatura das funções, a função de cifra recebe como parâmetro uma lista de identidades, aquelas com as quais o utilizador pretende cifrar o ficheiro, sendo que no processo de decifra, e esta é uma das capacidades deste tipo de sistemas, apenas os utilizadores que se encontrem nessa lista inicial, com a qual o ficheiro foi cifrado, poderão decifrá-lo. Aliado a isto foi ainda implementado um esquema de políticas de acesso a ficheiros que permite, para além de restringir a cifra e decifra a um grupo de identidades através do esquema IBE, limitar o acesso a estes dados cifrados através de diferentes parâmetros: ˆ intervalo de endereços IP: limitar o acesso ao ficheiro apenas para um certo intervalo de IPs. Se pensarmos em ambientes empresariais onde normalmente são utilizadas redes privadas, caso estejamos fora dessa rede seria impossível decifrar um ficheiro anteriormente cifrado com essa condição; ˆ intervalo de tempo: limitar o acesso ao ficheiro a um dado intervalo de tempo. Se pensarmos no exemplo do intervalo de tempo, estabelecido durante a cifra, entre 1/1/2020 e 1/1/2025, teríamos a certeza que o ficheiro nunca seria decifrado antes da data 1/1/2020 ou após 1/1/2025; ˆ nível de segurança: limitar o acesso ao ficheiro a um determinado nível de segurança. Se considerarmos que um ficheiro é cifrado com nível de segurança 1, nenhum outro utilizador fora deste valor poderá decifrar o ficheiro. Figura 3.6: Esquema geral do processo de Upload de um ficheiro A Figura 3.6 demonstra o processo de Upload de um ficheiro para o fornecedor de armazenamento, onde o utilizador que está a utilizar o Simploud passa a ter a possibilidade de enviar um ficheiro de três maneiras diferentes. Se o utilizador necessitar apenas de guardar os dados sem 41
56 a necessidade de serem cifrados, então deverá proceder à utilização da opção (A), indicada no esquema. Caso contrário, o utilizador poderá recorrer ao esquema IBE implementado e guardar o ficheiro de duas formas: recorrendo apenas à cifra baseada em identidade (B); utilizar a cifra baseada em identidade e acrescentar algumas políticas de acesso ao ficheiro (C). O processo da transferência de ficheiros, neste caso inverso ao envio, tem implementado igualmente estas três situações, tendo sempre a salvaguarda de que se o utilizador fizer a transferência de um ficheiro cifrado em texto limpo, sem o decifrar, o conteúdo deste nunca será percetível ao utilizador. A utilização de políticas de acesso a ficheiros aliada ao esquema IBE implementado nesta aplicação Web tem como principal objetivo aumentar os padrões de segurança, nomeadamente ao nível da privacidade dos dados. O esquema montado foi pensado para ambientes empresariais, onde esta solução poderia ser uma solução realmente capaz, assente em fortes medidas de segurança e privacidade, onde esta última é a principal causa do afastamento das empresas deste tipo de sistemas de armazenamento na Nuvem. Por último referir que o PKG e todo o sistema de políticas está integrado no código da aplicação. Desta forma, tanto a cifra e decifra de ficheiros como o cumprimento das políticas é da responsabilidade da própria aplicação. 3.3 Servidor OpenID proprietário A segunda implementação desenvolvida no âmbito desta dissertação teve como principal objetivo a criação de um serviço que permite que utilizadores titulares do Cartão de Cidadão possam usar este Token como mecanismo de autenticação em qualquer aplicação ou serviço Web, desde que este suporte o protocolo OpenID. O mecanismo deste protocolo já foi explicado anteriormente (secção 2.2.3), e para a sua implementação foi utilizada a biblioteca DotNetOpenAuth 2, disponibilizada publicamente, e adaptada conforme as necessidades para permitir a autenticação através do Cartão de Cidadão, em vez do utilizador se autenticar no fornecedor OpenID com o par nome de utilizador/palavra-passe. Para melhor compreender o protocolo OpenID e as aplicações utilizadas da biblioteca referida em cima foi utilizado, como guia de apoio, o livro Openid: The Definitive Guide [RRM12] Arquitetura do sistema A biblioteca DotNetOpenAuth possui diversas funcionalidades, e uma delas é o suporte do protocolo OpenID para a linguagem ASP.Net. A arquitetura deste sistema utiliza dois exemplos implementados para esta linguagem: ˆ OpenIdProviderMvc: Este projeto implementa um provedor de OpenID, que possibilita o registo de utilizadores, associando uma conta OpenID a cada registo. O principal objetivo desta aplicação Web é autenticar um utilizador em terceiras entidades de confiança, utilizando para isso o perfil utilizado
57 ˆ OpenIdRelyingPartyMvc: Este projeto simula uma aplicação Web que implementa a parte da delegação de autenticação do protocolo OpenID. O processo de autenticação nesta aplicação é delegado ao provedor OpenID e cabe a este geri-lo. Figura 3.7: Esquema geral da arquitetura do sistema OpenID implementado As principais alterações efetuadas na estrutura dos projetos já fornecidos centram-se na introdução do Cartão de Cidadão como Token de autenticação. Para implementar este mecanismo de autenticação foi necessário alterar ambos os projetos. No caso do provedor de autenticação foi obrigatório estabelecer uma sessão SSL para este comunicar com o CC. Visto que todo o código existente no processo de registo de um utilizador baseava-se no esquema nome de utilizador e palavra-passe, foi necessário alterar todo este código para substituir este mecanismo pela autenticação via Cartão de Cidadão. Para validar o certificado do Cartão de Cidadão apresentado foi implementado o código apresentado no Anexo A.1.1, bem como a função para filtragem dos certificados (Anexo A.2.1). Em relação à entidade que delega o processo de autenticação foi necessário alterar os pedidos de delegação de acesso para permitir que se mantenha a sessão SSL. Para guardar os dados de autenticação para futuras utilizações foi criada uma simples base de dados, que segue o modelo da Figura 3.8. Esta base de dados é composta apenas por uma única tabela que tem como função guardar os dados relativos ao processo de registo. Os atributos que a compõem são Username, IssuerName, SerialNumber e . Nesta tabela apenas se considerou atribuir a chave primária ao atributo Username pois é este que é utilizado em todas as delegações de autenticação feitas, podendo-se classificar então como identificador único e que diferencia uns pedidos dos outros. A Figura 3.7 representa toda a arquitetura deste sistema. Esta encontra-se dividida em três entidades principais: o Cartão de Cidadão como Token de autenticação, a entidade que delega o processo de autenticação e o provedor OpenID que gere a autenticação do utilizador. O primeiro passo consiste na tentativa do utilizador se autenticar perante uma entidade (1), onde este irá fornecer o seu identificador OpenID. Assim que esta entidade recebe este identificador, tenta procurar o provedor OpenID e assim que o encontra delega o serviço de autenticação para o provedor OpenID (2). Caso o certificado apresentado seja válido (3), o processo de autenticação encontra-se completado e o utilizador é redirecionado de volta para a entidade onde se quis 43
58 Figura 3.8: Modelo de base de dados que guarda todos os dados relativos ao registo de entidades autenticar(4). A partir daqui o utilizador tem acesso a todos os recursos e todos os serviços desta entidade (5) Modelo de segurança Tal como no modelo de segurança da primeira implementação, a segurança deste sistema como um todo irá depender de cada um dos elementos que o constitui. Desta forma, o sistema depende do Cartão de Cidadão como objeto de autenticação de identidade eletrónica, através do certificado de autenticação que este possui, nos canais de comunicação utilizados entre o cliente e o provedor OpenID e na resistência a ataques por parte do protocolo OpenID. Neste tipo de sistema, em que a autenticação se processa através da troca de certificados de cliente, é importante que seja impossível para um atacante fazer-se passar por um utilizador válido, neste caso um titular do Cartão de Cidadão. Pressupõem-se que os canais de comunicação entre a aplicação e o cliente sejam seguros, e para isso todas as comunicações decorrem sobre o protocolo SSL, onde é impossível para um atacante obter a chave privada do servidor, estando assim impossibilitado de decifrar os dados que vão passando pelo canal. Em relação ao CC, é pressuposto que um atacante não consegue alterar informação sensível guardada no chip do mesmo, como por exemplo o par de chaves que suportam o certificado de autenticação. É igualmente pressuposto que, durante o processo de autenticação, seja estabelecida uma relação de confiança entre a CA emissora do certificado do CC e a aplicação. O sistema pressupõem ainda que não existam qualquer tipo de falhas no mecanismo do protocolo OpenID. 44
59 Capítulo 4 Resultados Neste capítulo são apresentados os principais passos que envolvem o utilizador desde o ato de autenticação até ao acesso a recursos protegidos, com a exemplificação de janelas de visualização das aplicações criadas. Na primeira secção demonstra-se todos os passos, em ambiente gráfico, que envolvem o utilizador desde o processo de autenticação até ao exemplo do envio de ficheiros para um dos fornecedores de armazenamento. Na segunda parte deste capítulo é abordado a implementação da aplicação que delega a autenticação a um servidor OpenID proprietário, com exemplos de imagens retiradas da interface destas duas aplicações. É acompanhado todo o processo desde a autenticação no provedor OpenID até à autenticação do utilizador na aplicação que delega este processo. Para ambos os casos serão ainda apresentados alguns testes que provam, essencialmente, que a autenticação através de cartões Eid não é despropositada e que o tempo de execução deste mecanismo é inferior, comparado com o tempo de execução do mecanismo de autenticação baseado em nome de utilizador/palavra-passe. 4.1 Aplicação Web Simploud Como referido anteriormente, esta aplicação teve como principal fundamento a necessidade de aliar o mecanismo de autenticação forte do Cartão de Cidadão à gestão de recursos armazenados em fornecedores Cloud. Assim sendo, existe a necessidade do utilizador se autenticar perante a aplicação Simploud, sendo para isso necessário que o utilizador selecione o certificado de cliente que pretende utilizar para autenticação (Figura 4.1), com a garantia prévia de que apenas os certificados de cliente do Cartão de Cidadão serão aceites e consequentemente validados. A seleção e correta introdução do PIN que protege o acesso ao certificado de autenticação do Cartão do Cidadão faz com que a aplicação aceite este certificado e, consequentemente, o valide. As janelas na parte inferior da Figura 4.1 demonstram os resultados visuais dos diferentes erros obtidos caso o processo de autenticação falhe. À esquerda, a janela à qual o utilizador tem acesso caso selecione o certificado errado. À direita, o erro mostrado se o certificado de autenticação do Cartão de Cidadão estiver revogado, suspenso ou expirado. Em ambos os casos o acesso à fase de autorização é interdito. A conclusão bem sucedida do processo de autenticação resulta na janela exemplo mostrada na Figura 4.2, onde é mostrado o nome completo do titular do cartão e, em baixo, uma listagem com os diferentes fornecedores de armazenamento considerados para este trabalho. A função 45
60 Figura 4.1: Em cima, janela de autenticação do utilizador na aplicação Simploud. Na parte inferior, erros de autenticação obtidos. desta janela é permitir que o utilizador escolha o fornecedor ao qual pretende ter acesso. Ao clicar em qualquer um dos ícones, em representação do seu próprio fornecedor de armazenamento, o utilizador inicia imediatamente o processo de autorização OAuth. Como sabemos pelo funcionamento deste mecanismo, o pedido de autorização é efetuado na aplicação Web do próprio fornecedor, com a necessidade de autenticação do proprietário dos recursos, que em teoria deverá ser a mesma entidade que o utilizador autenticado. Deste modo, o utilizador da aplicação é redirecionado para o Website do fornecedor para o proprietário dos recursos dar permissão ao utilizador, e este aceder aos dados protegidos. A conclusão deste processo com ou sem sucesso envia o utilizador de volta para aplicação Simploud, sendo que o resultado da autorização influencia o resultado final mostrado ao utilizador. A autorização bem sucedida resulta na Figura 4.3, com toda a informação acerca dos recursos protegidos no fornecedor anteriormente selecionado, enquanto que o contrário redireciona o utilizador para a página exemplificada na Figura 4.2. Esta janela pode ser dividida em cinco diferentes zonas: ˆ A informação dos dados da conta, onde é mostrado ao utilizador o nome da conta à qual estamos a aceder, assim como o espaço de armazenamento disponível e utilizado; ˆ O Menu principal, que contém diversos ícones para melhorar a experiência do utilizador na aplicação e permitir a fácil gestão dos seus recursos. Este menu encontra-se dividido em quatro ícones que efetuam operações diferentes: 46
61 Figura 4.2: Janela para escolha do fornecedor de armazenamento pretendido O primeiro ícone permite que se volte sempre à diretoria raiz do fornecedor; O segundo ícone permite que se efetue o envio de ficheiros para a pasta que está atualmente em visualização; De forma idêntica, o terceiro ícone trata o envio de ficheiros, neste caso particular cifrados, para a diretoria atualmente em visualização; Finalmente, o último ícone possibilita que se crie uma nova diretoria na pasta atualmente em visualização. ˆ A lista de recursos, onde são mostrados todos os conteúdos (ficheiros e diretorias) que se encontram dentro da diretoria atualmente em visualização. O acesso às funções para edição de ficheiros e diretorias é feito através de uma janela de popup, que aparece assim que o utilizador clique em cima de qualquer ficheiro ou diretoria. O duplo clique numa diretoria envia o utilizador para a janela de visualização do conteúdo desta. Neste caso, esta diretoria que foi clicada será adicionada à lista de navegação; ˆ A lista de navegação, onde é mostrado ao utilizador todo o caminho percorrido. Para voltar a uma diretoria anterior, basta que o utilizador clique em cima do nome da pasta em questão; ˆ Finalmente, é apresentada novamente a listagem de todos os fornecedores de armazenamento implementados nesta aplicação para que, através de um simples clique em qualquer um deles, o utilizador possa alterar o fornecedor ao qual está a aceder. Como referido anteriormente, o clique em qualquer um dos recursos visualizados permite que seja mostrada uma janela de popup que contém as restantes operações suportadas pela aplicação (Figura 4.4). Como deve ser óbvio, a popup é diferente consoante o tipo de conteúdo. Desta forma temos: ˆ Popup para diretorias: contém as funções de partilha, renomear, mover e remover, embora as funções de partilha ainda não se encontrem implementados na API desenvolvida; ˆ Popup para ficheiros: contém as funções de transferência (é possível transferir um ficheiro em texto limpo ou recorrendo a decifra através dos algoritmos IBE), partilha, renomear, 47
62 Figura 4.3: Janela que permite a visualização sobre os recursos protegidos, após autorização completada mover e remover. Também neste caso, e pelas mesmas razões, a função de partilha não é suportada. Figura 4.4: Popups que contêm as funções de gestão de pastas (à esquerda) e de ficheiros (à direita) A Figura 4.5 demonstra ainda o processo de envio de ficheiros: sem recorrer à cifra (à esquerda); cifrado (à direita). Se o utilizador pretende simplesmente enviar um ficheiro, sem utilizar qualquer mecanismo de cifra, então basta selecionar o ícone sem cadeado que abre automaticamente a popup apresentada do lado esquerdo da Figura 4.5. Nesta janela basta indicar a localização do ficheiro em causa e clicar em OK para que o processo de envio inicie. Já no caso do ficheiro em causa ser motivo para a utilização dos mecanismos de cifra implementados no Simploud, o utilizador tem que clicar no ícone de envio que contém um cadeado e, imediatamente, é aberta a janela exemplificada à direita na Figura 4.5. Neste caso, são dadas algumas opções ao utilizador: ˆ Indicar a localização do ficheiro que pretende enviar cifrado; ˆ Ativar ou não a introdução de mecanismos de políticas de acesso. A não ativação deste mecanismo indica que o ficheiro será apenas cifrado com base na identidade do utilizador, enquanto que a opção inversa permite, para além disto, introduzir algumas políticas que controlem o processo de decifra deste. Essas políticas incluem o intervalo de tempo em que o ficheiro estará disponível para cifrar e o intervalo de IPs que poderão decifrar o respetivo ficheiro; ˆ Carregar um ficheiro de políticas existente no computador, desde que para isso cumpra e 48
63 contenha políticas implementadas neste trabalho. O não cumprimentos deste passo faz com que o ficheiro cifrado com essas políticas não volte a poder ser decifrado. Figura 4.5: Popups para envio de ficheiros sem serem cifrados (à esquerda) e recorrendo a cifra (à direita) Ao selecionar todas as opções pretendidas, basta ao utilizador clicar em Confirm para que o ficheiro seja cifrado e guardado com a extensão.ibc, ou ibz no caso de conter políticas. 4.2 Servidor OpenID proprietário A criação de um servidor OpenID foi essencial para a disponibilização de um serviço que permita autenticar um utilizador titular de um cartão de identificação eletrónica em diferentes entidades que suportem este mecanismo. Neste sentido, foram desenvolvidas duas aplicações que implementam toda a estrutura OpenID, desde o processo de autenticação no provedor OpenID até ao acesso a dados privados de entidades que confiam nestes servidores de autenticação. Para o sistema em causa é, primeiro que tudo, necessário referir que foi utilizada a biblioteca DotNetOpenAuth e dois dos seus projetos exemplo que implementam as duas entidades base no qual o protocolo está assente: o projeto OpenIdProviderMvc, que implementa um provedor de autenticação OpenID, e OpenIdRelyingPartyMvc, que se refere à entidade que confia a delegação de acesso. O mecanismo OpenID pode ser iniciado em ambas as aplicações, existindo a possibilidade do utilizador se autenticar no início do processo ou apenas quando a Relying Party delega este processo ao servidor. Vamos considerar que um utilizador utiliza o primeiro cenário. Neste caso, o primeiro passo consiste na realização do processo de autenticação do utilizador no provedor OpenID. Para isso basta ao utilizador selecionar uma das opções existentes na caixa de autenticação (Login ou Register) existente na janela principal (Figura 4.6). Figura 4.6: Janela inicial do provedor OpenID 49
64 Se estivermos perante a primeira utilização da aplicação, mesmo que o utilizador clique em Login será redirecionado para a página de registo, onde o primeiro procedimento da aplicação será executar o pedido de certificado do cliente (Figura 4.7) e, assim que o processo de validação do certificado esteja concluído, ligar o nome associado ao certificado apresentado juntamente com um para encerrar o processo de registo do utilizador (Figura 4.8). Figura 4.7: Autenticação do utilizador perante o provedor OpenID Figura 4.8: Registo do utilizador na base de dados do provedor OpenID Ao concluir o processo de autenticação e registo, focamos agora o comportamento do utilizador na aplicação que irá delegar o acesso ao provedor OpenID (Figura 4.9). Imaginemos esta situação como um utilizador que abre uma aplicação Web e pretende autenticar-se através do seu identificador OpenID. É este procedimento que estamos prestes a completar. Figura 4.9: Janela principal da aplicação que delega a autenticação Ao entrar na área restrita, onde apenas membros autenticados pela aplicação poderão ver os conteúdos desta secção, o utilizador depara-se com uma caixa para introdução do seu identificador OpenID (Figura 4.10). A estrutura base deste identificador deverá seguir o seguinte formato: endereço do provedor de autenticação que gerou este identificador seguido do nome de utilizador guardado no provedor. Este identificador gera um pedido de delegação de autenticação, por parte da aplicação Web que se está a tentar aceder, ao provedor OpenID. 50