Universidade do Minho
Escola de Engenharia
José Miguel Fernandes Carvalho
Criação de Assinaturas Eletrónicas
Qualificadas a partir de um Hardware
Security Module na Cloud
Universidade do Minho
Dissertação de Mestrado
Escola de Engenharia
Departamento de Informática
José Miguel Fernandes Carvalho
Criação de Assinaturas Eletrónicas
Qualificadas a partir de um Hardware
Security Module na Cloud
Mestrado em Engenharia Informática
Trabalho realizado sob orientação de
Professor Manuel Bernardo Martins Barbosa
Professor Francisco António Carneiro Pacheco de
Andrade
Agradecimentos
Quero agradecer aos meus orientadores, Professor Manuel Barbosa e Professor Francisco Andrade, por todas as recomendações que me deram, bem como ao Professor José Carlos Bacelar, cujo apoio foi muito importante na reta final da dissertação.
Ao Doutor Fernando Moreira, por me dar a oportunidade de desenvolver este projeto na DigitalSign, bem como ao meu supervisor, o Engenheiro Álvaro Matos.
Resumo
Desde o início da Era da Informação que a utilização de documentos eletrónicos se tornou uma reali-dade. A digitalização da informação trouxe inúmeros benefícios. No entanto, a autenticidade de documen-tos eletrónicos é muitas vezes questionada, o que faz com que as pessoas continuem a depositar mais confiança nos documentos assinados em papel. Isto porque, apesar de poder ser processada e trans-mitida facilmente, a informação digital é também facilmente manipulável. Para inverter esta tendência e garantir a validade legal das assinaturas eletrónicas, surgiram as assinaturas eletrónicas qualificadas, que satisfazem as exigências de segurança das assinaturas digitais - autenticidade, integridade e não-repúdio -, baseando-se na utilização de certificados qualificados e na sua criação em dispositivos seguros,
Abstract
Creating Qualified Electronic Signatures in a Cloud-based
Hardware Security Module
The use of electronic documents has become a reality since the beginning of the information age. The digitization of information has brought many benefits. However, the authenticity of electronic documents is often questioned, what causes people to continue to place greater trust in handwritten signed documents. That is because although digital information can be easily processed and transmitted, it can also be easily manipulated. Qualified Electronic Signatures appeared to reverse this trend and ensure the legal validity of electronic signatures, by meeting the security requirements of digital signatures - authenticity, integrity and non-repudiation -, based on the use of qualified certificates and on its creation in trustworthy devices, like smartcards or USB tokens. The aim of this thesis is to study a solution for Qualified Electronic Signature
Conteúdo
Contents ix
Lista de Figuras xv
Lista de Tabelas xvii
1 Introdução 1
1.1 Contexto . . . 1
1.2 Motivação . . . 3
1.3 Objetivos e Contribuições . . . 3
2 Engenharia de Segurança 5 2.1 Engenharia de Segurança de Sistemas . . . 5
2.2 Modelo de Desenvolvimento de Software Confiável . . . 6
2.3 Análise de Segurança . . . 7
2.3.1 Especificação de Requisitos de Segurança - Protection Profile . . . 10
3 Tecnologias 13 3.1 Técnicas Criptográficas . . . 13
3.1.1 Criptografia Simétrica . . . 14
3.1.2 Funções de Hash. . . 14
3.1.3 Criptografia Assimétrica . . . 15
3.2 Public Key Infrastructure . . . 18
3.3 Hardware Security Modules . . . 20
3.3.1 Segurança dos HSMs . . . 20
3.3.2 PKCS #11: Cryptographic Token Interface Standard . . . 22
3.3.3 Critérios para a seleção de um HSM . . . 22
3.5 Serviços na Cloud. . . 29
3.5.1 Cryptography as a Service . . . 30
3.5.2 Implicações do uso de HSMs na Cloud . . . 32
4 Sistema de Assinatura Remota 35 4.1 Conceito . . . 35
4.2 Assinatura Eletrónica Qualificada . . . 36
4.3 Normas e Protection Profiles . . . 39
4.4 Soluções existentes . . . 40 4.5 Funcionalidade . . . 45 4.5.1 Atores . . . 45 4.5.2 Casos de uso . . . 45 4.5.3 Componentes . . . 47 4.6 Recursos a proteger. . . 48 4.7 Atacantes. . . 49 4.8 Ameaças . . . 50
4.9 Políticas de Segurança da Organização . . . 52
4.10 Pressupostos . . . 54
4.11 Objetivos de segurança . . . 54
5 Componentes do Sistema 59 5.1 Dispositivo Criptográfico Seguro . . . 59
5.1.1 Vulnerabilidades da derivação e do encapsulamento de chaves . . . 62
5.2 Aplicação de assinatura . . . 63
5.2.1 Componente de autenticação . . . 63
5.2.2 Interface de assinatura . . . 66
5.2.3 Componente de geração de assinaturas. . . 68
5.3 Aplicação da AR . . . 68
5.3.1 Componente de gestão de tokens de segurança . . . 68
5.3.2 Componente de geração de chaves e certificados . . . 69
6 Protótipo 71 6.1 Contextualização . . . 71
6.2 Configuração do HSM. . . 74
6.3 Configuração do ADSS . . . 76
6.4 Criação do QSCD Proxy . . . 84
6.5 Interface de assinatura . . . 84
6.5.1 Go>Sign Document Viewer . . . 84
6.5.2 RESTful API . . . 87
6.6 Discussão . . . 89
7 Conclusão e trabalho futuro 91
Siglas
AC Autoridade de Certificação
ADSS Advanced Digital Signature Services AES Advanced Encryption Standard API Application Programming Interface AR Autoridade de Registo
CC Common Criteria
CRL Certificate Revocation List CSR Certificate Signing Request
FIPS Federal Information Processing Standard HSM Hardware Security Module
KEK Key Encryption Key OTP One-Time Password PKI Public Key Infrastructure PP Protection Profile
ST Security Target ToE Target of Evaluation
Lista de Figuras
3.1 CloudHSM. . . 31
3.2 Key Vault.. . . 32
4.1 ADSS Server Certification Service. . . 43
4.2 ADSS Server Signing Service. . . 44
4.3 Casos de uso do sistema de assinatura remota. . . 46
4.4 Interação entre os componentes do sistema.. . . 48
5.1 Nível 1 - autenticação baseada na aplicação.. . . 65
5.2 Nível 2 - autenticação baseada no dispositivo seguro. . . 65
5.3 Diagrama de Sequência - Protocolo de ativação da assinatura. . . 67
6.1 Exemplo do pedido getUserCerts. . . 88
6.2 Exemplo do pedido requestSignature. . . 88
Lista de Tabelas
3.1 Tamanhos das chaves dos algoritmos de assinatura e possíveis funções dehash. . . 17
3.2 Análise comparativa dos tipos de autenticaçãomobile-based. . . 28
Capítulo 1
Introdução
1.1 Contexto
A DigitalSign é uma autoridade de certificação (AC), que emite e gere certificados digitais, destacando-se em particular pela emissão de certificados digitais qualificados. A empresa atua também como autoridade de registo (AR), sendo responsável pela identificação e autenticação dos subscritores de certificados digitais,
pedidos de revogação e renovação de certificados em nome daAC.
Os certificados são entregues aos clientes em dispositivos criptográficos seguros, comosmartcardsou
tokensUSB. Apesar de estarem já bem estabelecidas, este tipo de soluções não são muito versáteis, ora porque implicam a utilização de hardware adicional (leitores), ora porque não foram concebidas a pensar em dispositivos móveis, que nos dias de hoje são os mais utilizados. Para além disso, a instalação dos controladores de hardware e/ou software exige algum conhecimento informático por parte dos utilizadores, o que requer, diariamente, pedidos de assistência à equipa de suporte técnico da empresa.
O aparecimento de soluçõesSoftware as a Service(SaaS) de assinatura naCloud, motivado pelo novo
regulamento europeu, n.º 910/2014, relativo à identificação eletrónica e aos serviços de confiança para as transações eletrónicas, mais conhecido como regulamento eIDAS, despertou o interesse da DigitalSign, no sentido de desmaterializar, quer o processo de emissão de certificados, quer a utilização dos certificados
por parte dos seus clientes. Assim, a DigitalSign pretende estudar uma solução completamenteCloud,
quer ao nível da emissão de certificados digitais qualificados, quer ao nível da assinatura de documentos, tendo em vista uma maior comodidade, confiança e segurança para os seus clientes.
Estando já bem estabelecida no mercado das soluções dePublic Key Infrastructure(PKI), a DigitalSign beneficia da parceria com outras empresas da área, destacando-se a Ascertia e a AET, que oferecem diversas soluções dePKIa nível mundial.
Para a emissão de certificados, a infraestrutura da empresa integra dois componentes fundamentais,
CAPÍTULO 1. INTRODUÇÃO
a geração de pares de chaves em tokens criptográficos, a criação de pedidos de certificado com base
na informação dos subscritores e o armazenamento do certificado resultante nesses mesmos tokens; o
software Advanced Digital Signature Services Server(ADSS), da Ascertia, onde os pedidos de certificados
são recebidos e assinados com chave da AC, sendo também responsável pela gestão da informação de
revogação dos certificados. Apesar de neste caso o ADSS ser utilizado para esse fim, esta ferramenta
oferece ainda outros serviços, nomeadamente criação de assinaturas digitais, verificação de assinaturas, validação de certificados e validação cronológica.
No âmbito deste projeto, pretende-se estudar a possibilidade de implementar um sistema de
assina-tura remota baseado no ADSS, alinhado com os requisitos do regulamento, sistema esse que, tendo em
consideração a importância da disponibilidade da solução a qualquer momento, e o potencial aumento da procura por este tipo de serviços inovadores, deverá ser projetado como um serviço naCloud.
A segurança do sistema será o principal objeto de estudo, visto que a emissão de certificados e a criação de assinaturas digitais exigem fortes requisitos de segurança. A própria definição de assinaturas eletrónicas qualificadas implica a sua criação em dispositivos criptográficos seguros, onde também os certificados
devem estar armazenados. Daí surge a necessidade de utilizar um Hardware Security Module (HSM)
para garantir o armazenamento seguro das chaves dos utilizadores e o processamento das operações criptográficas.
Um dos principais desafios surge, portanto, do facto desse dispositivo estar localizado do lado do ser-vidor, fora do alcance físico do seu portador, o que requer a utilização de mecanismos de autenticação adequados para compensar esse distanciamento. Esses requisitos têm garantidamente de ser cumpridos, dado que este tipo de assinaturas têm valor legal e são equiparadas às manuscritas, reconhecidas notarial-mente, permitindo identificar o signatário de forma unívoca, garantindo que a assinatura depende apenas da sua vontade e assegurando que o documento não sofreu alterações depois da aposição da assinatura. Será demonstrado também que estas propriedades são conseguidas através dos princípios da segurança da informação, como a autenticidade, integridade, entre outros.
A definição dos requisitos e objetivos de segurança será guiada por uma metodologia rigorosa, bem como pelos documentos normativos existentes. Para isso realizar-se-á um levantamento do trabalho que
tem sido desenvolvido a este nível, pelas organizações europeias de standardização, como o Comité
Eu-ropéen de Normalisation(CEN) e oEuropean Telecommunications Standards Institute (ETSI). No âmbito
do problema desta dissertação destaca-se em particular a norma EN 419 241Security Requirements for
Trustworthy Systems Supporting Server Signing, que no fundo será o ponto de partida para a análise de segurança.
1.2. MOTIVAÇÃO
1.2 Motivação
Segundo um estudo daGartner [1], o mercado dos dispositivos móveis continua em crescimento e o
sistema operativo mais utilizado da atualidade é oAndroid. Num outro estudo [2], prevê-se que em 2018,
50% dos utilizadores usará umtabletou umsmartphonepara todas as atividadesonline.
Face a este cenário, faz todo o sentido pensar na conceção de uma solução de assinatura compatível com todas as plataformas, não só para contribuir para a comodidade dos utilizadores, mas também para promover o uso da assinatura eletrónica.
As soluções tradicionais de assinatura, baseadassmartcardsoutokensseguros, deixam de fazer sentido nos dispositivos móveis. Mesmo nosdesktop, esse tipo de soluções implica instalação de controladores de
hardware e a instalação de aplicações locais de assinatura. Com a massificação da computação naCloud,
osoftwarepassou a ser disponibilizado na Internet, através do modelo SaaS. Os sistemas de assinatura remota adaptam-se a esta nova realidade, e são a resposta para obter a compatibilidade desejada. As cha-ves de assinatura dos utilizadores passam a estar protegidas por um dispositivo seguro, nas instalações de um provedor de serviços de confiança. Como as chaves são armazenadas de forma centralizada, estão imediatamente disponíveis após a sua geração, agilizando os processos de emissão e renovação de certi-ficados. Os custos de aquisição de dispositivos criptográficos e de transporte dos mesmos desaparecem. A integração com todo o tipo de sistemas informáticos também é possível, se o sistema disponibilizar uma
Application Programming Interface(API) que permita a criação de assinaturas.
As vantagens referidas constituem a principal motivação para a realização deste trabalho.
1.3 Objetivos e Contribuições
A conceção de um sistema de assinatura remota implica uma análise de segurança rigorosa e um estudo aprofundado sobre mecanismos de autenticação e autorização, gestão de chaves criptográficas em dispositivos seguros, políticas de segurança, entre outros. Estando inserido em contexto empresarial, espera-se que a investigação e o trabalho desenvolvido nesta dissertação possa contribuir para oknow-how
da empresa. Com a adoção do regulamento eIDAS, que prevê a disponibilização de serviços inovadores na área das assinaturas eletrónicas, este tipo de sistemas está na ordem do dia, e os provedores de serviços de confiança têm de acompanhar a mudança.
O resultado esperado desta dissertação é a conceção de uma solução segura de assinatura eletrónica
Capítulo 2
Engenharia de Segurança
Um projeto de engenharia de software com fortes requisitos de segurança exige, para além da especificação do sistema, uma cuidada análise de segurança. Neste capítulo são apre-sentados os conceitos engenharia de segurança, os processos que permitem a construção de sistemas confiáveis e os métodos que permitem avaliar as suas medidas de proteção.
2.1 Engenharia de Segurança de Sistemas
A segurança preocupa-se com a proteção de recursos, como por exemplo informação com valor, que é
armazenada, processada e transmitida por aplicações desoftware. Os proprietários dessa informação
po-dem querer que a disponibilidade, disseminação e modificação da informação seja estritamente controlada, e que os recursos estejam protegidos de ameaças através de medidas de proteção adequadas.
A Engenharia de Segurança é uma especialidade da engenharia de sistemas que tem como principal ob-jetivo o desenvolvimento de uma capacidade de proteção de recursos confiável, que satisfaça os requisitos dosstakeholders, que seja capaz de impor uma política de segurança organizacional e que esteja perfeita-mente integrada no sistema. Os processos da engenharia de segurança, recomendados pela metodologia
proposta em [3], são guiados por um conjunto de conceitos que estabelecem a base para perceber o que
deve ser protegido, para elaborar medidas de proteção específicas, e para gerir os riscos de segurança associados às proteções implementadas.
A identificação das necessidades de proteção dos recursos permite determinar quais as partes do sistema que precisam de ser protegidas, e que medidas de proteção lhes poderão ser aplicadas, para combater as ameaças e vulnerabilidades.
A política de segurança é um conjunto de regras que governa o comportamento dos indivíduos/proces-sos com relevância para a segurança, especificando as condições em que sistema é considerado seguro, em termos de confidencialidade, integridade e disponibilidade.
CAPÍTULO 2. ENGENHARIA DE SEGURANÇA
A construção de um sistema seguro prende-se com a utilização de componentes com relevância para a segurança. Esses componentes são responsáveis por aplicar a política de segurança e garantir simultanea-mente uma capacidade de proteção específica e um comportamento previsível, face a ataques maliciosos, uso indevido, erros humanos, faltas/falhas de componentes e eventos catastróficos.
A confiabilidade de um sistema assenta na garantia de que uma entidade (relevante para a segurança) irá sempre comportar-se de uma maneira previsível ao fornecer uma capacidade de proteção, face às necessidades de proteção decorrentes de certas situações que possam ocorrer no meio operacional. Essa garantia poderá ser obtida através de provas que permitam fundamentar as alegações feitas sobre as capacidades de segurança, propriedades, vulnerabilidades e a eficácia das medidas de proteção.
Por fim, a gestão de riscos de segurança visa conter o risco decorrente de vulnerabilidades a um nível administrável, desenvolvendo e levando a cabo planos para identificar, priorizar e tratar o risco. A avaliação das necessidades de proteção, das ameaças, das vulnerabilidades e do risco de segurança do sistema, bem como o tratamento do risco de segurança, constituem as atividades de gestão de riscos de segurança. Na impossibilidade de tratar o risco, é possível evitá-lo, aceitá-lo ou transferi-lo.
2.2 Modelo de Desenvolvimento de Software Confiável
Existem inúmeras metodologias de desenvolvimento desoftware, no entanto, a maior parte delas tem
em comum uma série de fases: a definição do produto ou do sistema, a análise e especificação de re-quisitos, a conceção da arquitetura do sistema, a implementação, a verificação, a validação, a operação, a manutenção e a desativação. Num projeto com fortes requisitos de segurança, essas diversas fases do desenvolvimento têm de sofrer ajustes, para que os requisitos de segurança do software ou do sistema sejam capturados e especificados por meio de metodologias rigorosas, de forma a que se materializem em medidas de proteção adequadas, que assim que integradas no sistema, deverão dar provas de que garantem a segurança do sistema.
Nesse sentido, [3] propõe um conjunto de ajustes às diferentes fases do desenvolvimento de software, orientando-o da perspetiva da engenharia de segurança, com o objetivo de tornar o software confiável.
Na definição dos requisitos dos stakeholders, são identificados os stakeholders e as proteções que
desejam e necessitam para o sistema, transformando a informação obtida em requisitos de segurança dos
stakeholders.
Na análise e especificação de requisitos, os requisitos de segurança dos stakeholderssão
transfor-mados em requisitos de segurança do sistema, garantindo que os aspetos relevantes para a proteção do sistema são recolhidos e que as características funcionais das proteções podem verificar-se. São tam-bém especificadas atividades para obter as provas para fundamentar alegações de garantia e determinar
2.3. ANÁLISE DE SEGURANÇA
a confiabilidade do sistema.
Em seguida, parte-se para a conceção da arquitetura do sistema, em função dos requisitos de segurança dos elementos com relevância para a segurança. Esses elementos serão combinados para conter o impacto de vulnerabilidades, tendo em conta a suscetibilidade a ameaças e a tolerância ao risco dosstakeholders. A implementação consiste na concretização dos elementos com relevância para a segurança do sis-tema, atendendo aos requisitos de segurança dosstakeholderse à especificação da arquitetura do sistema. A verificação demonstra que as medidas de proteção implementadas oferecem o nível de proteção desejado, sendo possível comprovar que os requisitos de segurança e da arquitetura foram satisfeitos, e
que os objetivos de confiabilidade dosstakeholdersforam cumpridos.
Na transição as proteções especificadas são colocadas no sistema e preparadas para serem utilizadas. A validação demonstra que as proteções do sistema são necessárias, suficientes e eficientes na prote-ção dos recursos do sistema, e que o sistema faz cumprir a política de segurança.
A operação estabelece um funcionamento seguro do sistema e recolhe dados relevantes para a segu-rança do sistema, que podem ser analisados para conceber e aplicar melhorias e modificações.
Na manutenção é fornecido o suporte necessário para manter as proteções do sistema e serviços de segurança.
A desativação possibilita a desintegração, remoção e reutilização do sistema, identificando métodos adequados para proceder à destruição segura de componentes, dados e informação sensível.
2.3 Análise de Segurança
No desenvolvimento de sistemas de software seguros, a análise e especificação de requisitos de segu-rança deve ser conduzida por um modelo formal e rigoroso.
ACommon Criteria for Information Technology Security Evaluation(CC) [4] é um standard internacio-nal, constituído por três partes, que surgiu com o objetivo de estabelecer uma metodologia padrão para
especificar, conceber e avaliar as propriedades de segurança de um sistema desoftware.
A primeira parte daCCexplica os conceitos e os princípios gerais pelos quais se deve guiar uma análise
de segurança. O processo começa pelo levantamento das preocupações de segurança que osstakeholders
expressam relativamente ao sistema que desejam proteger. Esse conjunto de requisitos de segurança do
sistema é então materializado num documento, aProtection Profile(PP), e são expressos de uma forma
independente da implementação, o que promove a sua reutilização porstakeholderscom necessidades
semelhantes.
CAPÍTULO 2. ENGENHARIA DE SEGURANÇA
mecanismos, propriedades e funções de segurança necessárias para dar resposta às exigências dos
sta-keholders, registadas naPP. A equipa de desenvolvimento formaliza, através de um documento designado porSecurity Target(ST), uma prova de que essas medidas de proteção, satisfazem efetivamente os
requi-sitos de segurança do sistema. O documento propõe, assim, uma implementação baseada naPP, que se
concretiza noTarget of Evaluation(ToE), isto é, o produto ou o sistema que será posteriormente sujeito a
uma avaliação. Como umaPPé independente da implementação, podem ser propostos múltiplosSTs em
resposta a uma únicaPP.
O ToEpode ser um único componente, ou pode ser composto por múltiplos componentes, também
eles consideradosToEs. UmPackageé um conjunto de componentes que são combinados para satisfazer
um subconjunto de objetivos de segurança.
A segunda parte daCCé um catálogo de requisitos funcionais de segurança, que pode ser utilizado para
descrever o comportamento esperado para oToEe para atingir os objetivos de segurança enumerados na
PPou noST. Os requisitos funcionais de segurança estão organizados sucessivamente em classes, famílias, componentes e elementos. A classe é o grupo menos específico da hierarquia, e corresponde a um grupo de requisitos que partilham um objetivo comum. São onze as classes de requisitos funcionais:
• Auditoria de segurança, cujo objetivo passa pela monitorização, captura, armazenamento, análise e relatórios relacionados com eventos de segurança;
• Comunicação, cujo propósito é garantir a identidade de emissores e destinatários da informação transmitida, bem como o não-repúdio;
• Suporte criptográfico, cuja finalidade é gerir e controlar o uso operacional de chaves criptográficas; • Proteção de dados dos utilizadores, relacionada com a proteção dos atributos de segurança
asso-ciados aos utilizadores e dos dados que são importados, exportados e armazenados;
• Identificação e autenticação, que tem como objetivo garantir uma identificação inequívoca de utili-zadores e a sua correta associação aos respetivos atributos de segurança;
• Gestão da segurança, que tem como finalidade gerir os atributos, dados e funções de segurança e definir cargos de segurança;
• Privacidade, cujo objetivo é proteger os utilizadores da divulgação e do uso indevido da sua identi-dade;
• Proteção da funcionalidade de segurança doToE, que tem como intuito manter a integridade das
funções e dos dados relacionados com a funcionalidade de segurança doToE;
• Utilização de recursos, que trata de garantir a disponibilidade dos recursos do sistema através de tolerância a falhas e da alocação de serviços por prioridade;
• Acesso aoToE, responsável pelo controlo do estabelecimento de sessões com o utilizador;
• Canais seguros, que tem como objetivo disponibilizar um canal de comunicação seguro entre os
2.3. ANÁLISE DE SEGURANÇA
utilizadores e as funções de segurança do ToE, e entre as funções de segurança do ToEe outros
produtos confiáveis;
A terceira parte daCCé um catálogo de requisitos de garantia de segurança, que são utilizados para
definir os critérios para avaliarPPs, STs e ToEs. Os requisitos de garantia de segurança também estão organizados segundo uma hierarquia, que começa pelas classes, seguidas das famílias, componentes e elementos. As classes são dez, e representam a entidade mais abrangente, a partir da qual os requisitos começam por ser selecionados:
• Avaliação da Protection Profile, que trata de demonstrar que aPPé completa, consistente e
tecni-camente correta;
• Avaliação do Security Target, responsável por demonstrar que oSTé completo, consistente,
tecni-camente correto, e adequado para ser utilizado como base para a avaliação doToE;
• Gestão da configuração, que tem como objetivo controlar o processo pelo qual oToEe a
documen-tação relacionada é desenvolvida, refinada e modificada;
• Implementação e funcionamento, cujo propósito é garantir uma entrega, instalação, geração e inicialização corretas noToE;
• Desenvolvimento, que tem como finalidade garantir que o processo de desenvolvimento é metódico, exigindo vários níveis de especificação e conceção, e avaliando a coerência entre eles;
• Documentos de orientação, cujo objetivo é garantir que todos os aspetos relevantes da operação e
uso seguros doToEsão documentados para orientação dos utilizadores e administradores;
• Apoio no ciclo de vida, responsável por garantir que são seguidos processos metódicos durante as fases de operação e manutenção, de forma a que a integridade da segurança não seja afetada; • Testes, cuja finalidade é garantir uma cobertura e profundidade adequadas dos testes, bem como
testes funcionais e independentes;
• Avaliação de vulnerabilidades, responsável por analisar a existência de potenciais
vulnerabilida-des, o uso impróprio ou a configuração incorreta doToE, a capacidade de derrotar, ultrapassar ou
comprometer credenciais de segurança;
• Manutenção da confiança, que trata de garantir que oToEvai continuar a cumprir o STà medida
que se fazem mudanças noToEou no seu meio;
Na terceira parte são ainda definidos sete níveis de avaliação da confiabilidade doToE, osEvaluation Assurance Levels(EALs), sendo que cada nível representa umpackagede componentes de confiança. O
objetivo dos EALs é garantir que o nível de confiança doToEé adequado face às restrições financeiras,
CAPÍTULO 2. ENGENHARIA DE SEGURANÇA
2.3.1 Especificação de Requisitos de Segurança - Protection Profile
Como já foi abordado na secção2.2, o desenvolvimento de software confiável deve ser orientado por
um modelo de desenvolvimento de software focado na segurança. Neste sentido, a metodologia da CCé
particularmente útil na fase de análise e especificação dos requisitos de segurança do sistema (ToE), visto
que uma PPpermite, de uma forma rigorosa, captar, definir e validar as necessidades de segurança dos
stakeholders.
A formalidade ao nível do conteúdo, do formato e da sintaxe de uma PP é fundamental para que o
documento seja interpretado de uma forma precisa e uniforme por todos os stakeholders. Uma PP é
constituida por sete secções, seis das quais obrigatórias, apresentadas em seguida:
1. Introdução: identifica a natureza, o âmbito e o estado daPP; inclui as subsecções Identificação da
PPe Visão Geral sobre aPP.
2. Descrição do ToE, descreve a funcionalidade e os limites do ToEe os recursos que precisam de
proteção; inclui duas subsecções: Funcionalidade Geral e Limites doToE. Na funcionalidade geral
são determinados os recursos a serem protegidos, bem como a importância de cada um para o
sistema. São ainda descritas as interações entre utilizadores e recursos. Nos limites do ToE, é
identificado cada componente do sistema.
3. Meio de Segurança doToE, apresenta pressupostos, analisa ameaças, e indica as políticas de
se-gurança aplicáveis à funcionalidade de sese-gurança do ToE; inclui três subsecções: Pressupostos,
Ameaças e Políticas de Segurança da Organização. Os pressupostos são um conjunto de factos
sobre o ToE que facilitam a compreensão do contexto em que se insere. Na secção das
amea-ças, estas são identificadas e caracterizadas, sendo posteriormente determinada a probabilidade de ocorrência e a gravidade das consequências. As Políticas de Segurança da Organização incluem regras, procedimentos e práticas que uma orgazinação impõe num sistema para proteger os seus recursos.
4. Objetivos de Segurança, descreve os objetivos de segurança para oToEe para o meio operacional,
isto é, as medidas de controlo que oToEimplementa face às ameaças. Essas medidas podem ser
preventivas, de deteção ou de correção. Baseia-se na análise dos pressupostos, das ameaças e das
políticas de segurança (secção 3). Inclui duas subsecções: Objetivos de Segurança para oToEe
Objetivos de Segurança para o Meio Operacional.
5. Requisitos de Segurança, seleção dos requisitos funcionais e de garantia, que implementam os objetivos de segurança; baseia-se na análise da vunerabilidade dos recursos (secção 2) a serem protegidos e no risco de comprometimento averiguado (secção 3). Inclui quatro subsecções:
• Requisitos Funcionais de Segurança: implementam os objetivos de segurança e especificam
2.3. ANÁLISE DE SEGURANÇA
as funções que o ToEvai desempenhar para antecipar, prevenir, caracterizar e responder e
recuperar das ameaças.
• Requisitos de Garantia de Segurança definem o critério para avaliar o ToE, identificando e
preparando os testes necessários para verificar a conformidade doToE.
• Requisitos de Segurança para o Meio Tecnológico correspondem à funcionalidade
tecnoló-gica, que o meio disponibiliza, para um funcionamento seguro doToE.
• Requisitos de Segurança para o Meio Não Tecnológico estão relacionados com o uso
pre-tendido e o funcionamento doToE, bem como com as políticas de segurança da organização.
6. Observações (opcional), disponibilizam informação adicional sobre o contexto do problema, para que a equipa de desenvolvimento consiga perceber o problema de segurança em questão e interpretar os requisitos funcionais de segurança corretamente.
7. Fundamento, apresenta provas de que os requisitos especificados são completos, coerentes, con-sistentes e corretos, e que implementam todos os objetivos de segurança no meio operacional. Inclui duas subsecções: Fundamento dos Objetivos de Segurança e Fundamento dos Requisitos de Segurança.
Capítulo 3
Tecnologias
Este capítulo apresenta os conceitos básicos da criptografia e as tecnologias relevantes para o âmbito da dissertação, nomeadamente dispositivos criptográficos, métodos de autenticação eletrónica e disponibilização de serviços na Cloud.
3.1 Técnicas Criptográficas
A criptografia é um ramo da matemática que estuda os princípios e as técnicas que podem ser utiliza-dos para conferir segurança aos sistemas de informação. A criptografia permite transformar informação desprotegida (texto limpo) em informação codificada (texto cifrado), por meio de algoritmos criptográficas
e chaves secretas. Através da utilização de uma chave secreta, partilhada entre Alice(emissor) e Bob
(recetor),Alicepode cifrar a informação e transmiti-la confidencialmente aBob, sem queCharlie(atacante)
tenha acesso às mensagens. No entanto, casoCharlie tenha acesso à chave secreta, ele pode fazer-se
passar porAliceouBob, ou ler as mensagens trocadas entre eles. Ainda que não tenha a chave,Charlie
pode interferir na comunicação entre as duas partes, modificando os textos cifrados, o que resulta em decifragens incorretas. Na maior parte dos sitemas de informação, a segurança depende não só de uma única propriedade de segurança, mas de uma combinação de propriedades de segurança. As quatro pro-priedades fundamentais que estão na base da segurança de sistemas são: confidencialidade, integridade, autenticidade e não repúdio.
A confidencialidade restringe o acesso a informação sensível apenas a pessoas autorizadas a ver os dados, impedindo a divulgação não autorizada de informação. A integridade relaciona-se com a modificação não autorizada ou acidental de dados, pelo que o recetor dos dados deve ser capaz de verificar que estes não foram alterados. A autenticidade permite ao recetor de informação determinar origem da transmissão, ou seja, o remetente. O não repúdio impede um indivíduo de negar que realizou uma determinada ação, e garante que o recetor da informação pode demonstrar a identidade do remetente.
CAPÍTULO 3. TECNOLOGIAS
Para dar resposta a estas propriedades de segurança, foram construídas técnicas criptográficas,
destacando-se três clasdestacando-ses fundamentais: algoritmos simétricos, algoritmos dehashe algoritmos assimétricos.
3.1.1 Criptografia Simétrica
Os algoritmos de criptografia simétrica baseiam-se na utilização da mesma chave para as operações de cifragem e decifragem, e são utilizados principalmente com o objetivo de conseguir confidencialidade, num canal de comunicação, por exemplo.
A chave utilizada como input para os algoritmos baseia-se num segredo partilhado entre as partes que desejam trocar mensagens confidenciais. O acordo desse segredo consiste precisamente na principal desvantagem das cifras simétricas, face a outros esquemas de cifra. Um atacante não deve conseguir ter acesso a esse segredo, caso contrário a confidencialidade das comunicações será comprometida. Por outro lado, caso o atacante tenha acesso aos criptogramas, ele também não deve ser capaz de extrair informação que lhe permita derivar a chave.
Assim, a segurança desta classe de algoritmos depende do estabelecimento seguro de um segredo, bem como da imprevisibilidade e da aleatoriedade da chave.
3.1.2 Funções de Hash
Uma função de hash transforma uma sequência de dados de tamanho arbitrário, numa sequência de tamanho fixo, por meio de uma função matemática de sentido único. A sequência resultante designa-se pormessage digest, e pode reproduzida a partir da mesma sequência de dados. A função de sentido único garante que é praticamente impossível criar uma sequência de dados diferente, que produza o mesmo
resultado, ou seja, o mesmo message digest. Por essa razão, diz-se que a função de hash é resistente a
colisões.
Se o hash for calculado e enviado juntamente com a mensagem que lhe deu origem, qualquer alteração na mensagem pode ser detetada através da verificação do valor de hash. Assim, as funções de hash podem ser utilizadas para fornecer integridade. No entanto, um atacante pode intercetar mensagens e substituí-las por novas mensagens e por um novo valor de hash.
Uma função de hash pode ser combinada com uma chave secreta, numa construção designada por
hash-based message authentication code (HMAC). Assim, se duas partes utilizarem uma chave secreta para autenticar as mensagens, um atacante pode até intercetar as mensagens e substituí-las por outras, mas não consegue obter um valor de hash válido sem saber a chave.
3.1. TÉCNICAS CRIPTOGRÁFICAS
3.1.3 Criptografia Assimétrica
Os algoritmos de criptografia de chave assimétrica, também conhecida como criptografia de chave pública, baseiam-se na utilização de um par de chaves, uma chave pública, e outra só conhecida e mantida em segredo pelo proprietário do par de chaves, a chave privada.
As chaves estão relacionadas matematicamente, de tal forma que os dados cifrados com uma chave, só podem ser decifrados com a outra. A segurança subjacente à criptografia assimétrica deve-se ao facto dos algoritmos se basearem em problemas matemáticos que não admitem uma solução eficiente, como a fatorização de inteiros e o logaritmo discreto. Assim, a chave pública pode ser publicada sem comprometer a segurança, visto que não é computacionalmente viável determinar a chave privada correspondente. A criptografia assimétrica apresenta assim a vantagem de não ser necessário partilhar uma chave entre as partes, como no caso dos algoritmos de chave simétrica.
No entanto, os algoritmos assimétricos não são adequados para cifrar mensagens, devido ao seu fraco desempenho em operações de cifra. Em vez disso, alguns algoritmos, por exemplo o algoritmo RSA, podem ser utilizados no transporte de chaves simétricas, visto que se forem cifradas com a chave pública
do destinatário, podem ser enviadas para ele forma confidencial. Outros algoritmos, por exemplo
Diffie-Hellman, podem ser usados para estabelecer um valor secreto entre duas partes, de forma independente, por meio de um processo designado por acordo de chaves. Esse valor secreto pode ser utilizado como chave simétrica para proteger as suas mensagens. Desta forma, os algoritmos assimétricos apoiam a confidencialidade através de uma distribuição segura de chaves, colmatando a principal desvantagem das cifras simétricas.
No entanto, o facto de não existirem garantias quanto à identidade de cada uma das partes, torna estas técnicas criptográficas assimétricas vulneráveis a ataques em que um intruso se coloca no meio da
comunicação entre as partes: man-in-the-middle. A solução consiste na introdução de uma terceira parte
confiável, que garanta uma associação entre o par de chaves e a identidade do seu titular.
Para além da importância da criptografia assimétrica na distribuição de chaves, outro grande contributo foi o de permitir a definição do conceito de assinatura digital, que confere integridade, autenticidade e não repúdio às mensagens ou documentos a que são aplicadas. Visto que as assinaturas digitais são o principal objeto de estudo desta dissertação, irão ser abordadas com mais detalhe em seguida.
Assinaturas Digitais
Conceptualmente, podemos entender as assinaturas digitais como a combinação de algoritmos assi-métricos com funções de hash, que através da compressão das mensagens, tornam a operação de cifra muito eficiente.
CAPÍTULO 3. TECNOLOGIAS
Para criar uma assinatura digital sobre uma determinada mensagem, primeiro gera-se o resumo da mensagem, e em seguida cifra-se o resumo com a chave privada. Para verificar que a mensagem foi assinada por um emissor e que não foi modificada, o recetor precisa apenas de saber a chave pública correspondente.
Na verificação, o resumo da mensagem é reproduzido e comparado com o resultado da decifragem da assinatura, com a chave pública. Se uma chave privada diferente foi utilizada para gerar a assinatura, a validação irá falhar. Se a mensagem foi alterada depois da assinatura ser criada, será produzido um resumo diferente, e a validação também irá falhar.
A assinatura dá-nos, assim, garantias de autenticidade da origem, visto que apenas o emissor possui a chave privada que produziu a assinatura, e garantias de integridade, visto que qualquer alteração na mensagem é detetada. Para além disso, se o recetor da mensagem puder recorrer a uma terceira parte que lhe garanta a ligação entre a identidade do emissor e a sua chave pública, então o emissor não poderá negar que não gerou uma determinada assinatura, visto que é possível provar que ele detém a chave privada que lhe deu origem. Neste caso, as assinaturas digitais fornecem garantias de não repúdio.
Os esquemas de assinatura digital devem resistir a ataques de texto-limpo escolhido, isto é, um adversá-rio que obtenha assinaturas de um signatáadversá-rio para quaisquer mensagens à sua escolha, não deve ser capaz de conseguir falsificar uma assinatura desse signatário numa outra mensagem. A segurança do esquema depende da utilização de funções de hash resistentes a colisões. Apesar dos algoritmos assimétricos se basearem em problemas difíceis, eles podem ser quebrados, se não for escolhido um tamanho de chave que ofereça um determinado nível de segurança (112bits, atualmente [5]).
De acordo com [6], os algoritmos e os tamanhos das chaves recomendados para assinaturas digitais
são RSA (2048bits) e ECDSA (curvas p-256 ou p-384), pelo facto de serem amplamente utilizados naPKI.
Da mesma forma que outras técnicas assimétricas, também as assinaturas digitais implicam recorrer a uma terceira parte confiável, com o objetivo de obter a garantia de que a chave pública utilizada para verificar uma assinatura, foi a chave gerada juntamente com a chave privada que originou a assinatura. A infraestrutura que nos permite depositar confiança nas chaves públicas é abordada de seguida.
3.1. TÉCNICAS CRIPTOGRÁFICAS
Nível de
segurança (bits) DSA RSA ECDSA Função de hash
112 L = 2048 N = 224 k = 2048 f = 224-255 SHA-224, SHA-512/224, SHA-256, SHA-512/256, SHA-384, SHA-512 128 L = 3072 N = 256 k = 3072 f = 256-383 SHA-256, SHA-512/256, SHA-384, SHA-512 192 L = 7680 N = 384 k = 7680 f = 384-511 SHA-384, SHA-512 256 L = 15360 N = 512 k = 15360 f = 512+ SHA-512
CAPÍTULO 3. TECNOLOGIAS
3.2 Public Key Infrastructure
APublic Key Infrastructure (PKI) consiste na combinação de hardware, software e pessoas que nos permite obter a garantia da associação entre chaves públicas e entidades envolvidas num sistema, quer sejam pessoas ou servidores.
Quando queremos estabelecer comunicação com uma entidade, temos de ter a certeza de que a outra parte é quem diz ser. Embora a outra parte se identifique com uma chave pública, precisamos de um comprovativo de que essa chave lhe pertence efetivamente. Esse comprovativo é obtido através de um certificado digital, emitido para essa entidade, por um terceiro de confiança. Se depositarmos confiança nesse terceiro, e se ele tiver emitido um certificado para a outra parte, então podemos ter a certeza da identidade da parte com quem estamos a comunicar, e iniciar um canal de comunicação seguro, ou verificar uma assinatura, por exemplo.
Na terminologia daPKI, o terceiro de confiança designa-se por autoridade de certificação (AC). Quando
uma (AC) emite um certificado, ela está a afirmar que o sujeito detém a chave privada que corresponde
à chave pública contida no certificado, e que a informação adicional incluída no certificado corresponde também ao sujeito. Para um certificado ser emitido, a informação da identidade do sujeito tem
neces-sariamente de ser validada junto de uma autoridade de registo (AR). CadaAC mantém uma lista deARs
acreditadas, responsáveis por levar a cabo os processos de validação de identidade.
Para além de validar a identidade, aARpode também gerar o par de chaves criptográficas, num
dis-positivo seguro, caso assim o utilizador o pretenda. AARgera ainda um pedido de emissão de certificado
(CSR), contendo a chave pública e a informação do sujeito, que é assinado com a chave privada e enviado para aAC. AACprocessa o pedido, cria o certificado e assina-o.
Se a chave privada correspondente a um determinado certificado for comprometida, ou se houver uma alteração nos dados do seu proprietário, por exemplo, ele deve ser revogado. Os certificados revogados são adicionados pelas ACs às listas dos certificados revogados (CRLs), que mantêm o historial do estado de revogação dos certificados. Por exemplo, uma assinatura realizada numa determinada data pode ser considerada válida se, nessa data, o certificado estava dentro do período de validade e não constava na lista de revogação.
AACdesempenha, assim, quatro funções fundamentais: emite certificados; mantém informação sobre
o estado dos certificados e emiteCRLs; publica os certificados e asCRLs em repositórios, de forma a que
os utilizadores daPKIpossam confirmar o estado dos certificados, quando pretendem verificar mensagens
assinadas digitalmente, por exemplo; mantém a informação dos certificados expirados em arquivo, no caso de ser necessário verificar quaisquer assinaturas digitais ou transações efetuadas com os certificados durante o seu período de validade, depois do término da mesma.
3.2. PUBLIC KEY INFRASTRUCTURE
As duas principais estruturas de dados utilizados nasPKIs são, assim, os certificados de chave pública
e asCRLs. Para garantir a interoperabilidade entre sistemas, praticamente todas implementaçõesPKIse
baseiam no standard X.509, que especifica os formatos para essas estruturas de dados.
UmaPKIé tipicamente constituída por muitasACs ligadas através de caminhos confiáveis. Um caminho
confiável liga uma entidade a um ou mais terceiros de confiança, de tal forma que a entidade possa
depositar confiança na validade do certificado em uso. As ACs de umaPKI podem ser organizadas de
diferentes formas, o que determina a arquitetura da PKI. Em particular, o standard adotado pela web
foi o modelo hierárquico. Neste modelo, asACs estão organizadas hierarquicamente debaixo deACs de
raiz, que por sua vez podem também emitir certificados para asACs abaixo delas na hierarquia, ou para
utilizadores. Os certificados dasACs de raiz são auto-assinados, isto é, emitidos por elas próprias, para elas próprias. Estes certificados devem ser conhecidos por todos os utilizadores daPKI. Assim, qualquer certificado pode ser verificado, através da verificação do caminho de certificação dos certificados emitidos pelasACs subordinadas até àACde raiz.
CAPÍTULO 3. TECNOLOGIAS
3.3 Hardware Security Modules
A utilização de criptografia em larga escala, em cenários de alta segurança, tem de ser suportada por dispositivos que assegurem uma alta disponibilidade e medidas de proteção adequadas face a ataques e ameaças que possam surgir.
Os Hardware Security Modules(HSMs) são dispositivos seguros dedicados ao processamento cripto-gráfico, sendo capazes de executar operações criptográficas com elevado desempenho e de proteger a confidencialidade e a integridade de material sensível. OsHSMs estão na base daPKI, visto que as chaves
privadas dasACs são geradas e armazenadas nestes dispositivos, que as protegem do uso não autorizado
ou divulgação, mantendo assim aPKIsegura. Podem também ser integrados em sistemas em que seja
necessário assegurar a execução de operações criptográficas computacionalmente exigentes, em tempo útil: no setor bancário, são utilizados para proteger a integridade de um grande número de transações; na transmissão de dados em massa, por satélite, são utilizados para garantir a confidencialidade dos dados. Podem ainda ser simplesmente utilizados para reforçar a segurança de uma base de dados, cifrando dados
sensíveis que nela tenham de ser armazenados. Os tipos mais comuns deHSMs são placas PCI, que se
anexam a um computador anfitrião, e dispositivos que se conectam diretamente à rede (network attached).
As características dos HSMs variam consoante o seu tipo e com seu o fabricante, sendo a Safenet e a
Thales, os dois principais fabricantes.
3.3.1 Segurança dos HSMs
A construção deste tipo de dispositivos é orientada pelos requisitos de segurança especificados no
Federal Information Processing Standard 140-2 (FIPS), que se estendem por onze diferentes áreas. Para
serem validados perante oFIPS140-2, osHSMs são submetidos a uma série de testes que determinam
o nível de segurança que ele oferece, que vai de 1, o nível mais baixo, a 4. A validação doHSMé muito
importante, visto que qualquer fornecedor pode afirmar que o dispositivo cumpre os requisitos doFIPS, no entanto isso não significa que foi efetivamente validado.
O nível de segurança dá-nos uma ideia dos mecanismos de proteção física e lógica implementados peloHSM. Quanto maior for o nível, mais características de segurança o dispositivo oferece, e consequen-temente maior é a probabilidade do dispositivo conseguir detetar e reagir a tentativas de violação.
Fisicamente, osHSMs podem estar sujeitos a ataques como a perfuração da sua própria caixa, a
ata-ques que interfiram com o normal funcionamento do dispositivo, como a exposição a baixas temperaturas,
variações de corrente ou tensão, ou ainda a ataques mais sofisticados, designados por side channel
at-tacks, como a análise do tempo de execução de algoritmos ou a análise do consumo energético. Qualquer
3.3. HARDWARE SECURITY MODULES
que seja o ataque, para assegurar a proteção do material armazenado, oHSMtem de ser capaz de resistir
a todos eles.
Os mecanismos de proteção física conferem-lhes uma característica designada portamper-resistance.
Um dispositivotamper-resistantutiliza sensores para detetar a ocorrência de um ataque(tamper-detective), causa danos visíveis na sua superfície caso seja violado(tamper-evident)e elimina, com segurança, todos
os dados sensíveis armazenados na memória do dispositivo(zeroisation), de modo impedir a fuga ou a
manipulação da informação que nele esteja armazenada(tamper-responsive). Para reforçar ainda mais a
proteção e tornar os ataques inviáveis, osHSMs são tipicamente colocados em instalações de alta
segu-rança e a interação com o dispositivo pode exigir a autenticação de pelo menos dois, ou mais responsáveis,
designados porkey holders(autenticação M de N).
OsHSMs estão também sujeitos a ataques lógicos, isto é, ataques através da interface de comandos
que tiram proveito de anomalias lógicas para expor informação sensível, nomeadamente sequências de comandos inesperadas, comandos desconhecidos, execução de comandos num modo de operação er-rado, passagem de dados ou parâmetros errados. A possibilidade de ocorrência destes ataques é bastante reduzida com as restrições físicas, regras procedimentais, definições de configuração do computador anfi-trião e registos de auditoria. Para mitigar os ataques, oHSMdeve ser configurado com as características
que sejam estritamente necessárias para o objetivo pretendido, visto que quanto menos comandos oHSM
suportar, menor será o número de preocupações de segurança. Em particular, deve-se configurar oHSM
com algoritmos criptográficos abertos e seguros, já com provas dadas e recomendados pelos standards,
e evitar o uso de algoritmos proprietários. A política de segurança doHSMdeve ser configurada da forma
mais condicionada possível, tendo em conta os requisitos das aplicações que utilizem o HSM. Deve-se
também garantir que nenhum acesso não autorizado à porta do computador anfitrião doHSMé possível,
e que os registos de auditoria das transações são regularmente monitorizados.
Uma gestão apropriada ao longo do seu ciclo de vida reveste-se de grande importância, por isso, as
atividades de gestão de umHSMdevem ser orientadas por procedimentos detalhados e rigorosos. Essas
atividades incluem: a instalação e inicialização doHSM; a definição dos utilizadores e permissões; a gera-ção, importação/exportação e instalação de chaves, através de um procedimento designado por cerimónia de chaves; a configuração das políticas de segurança; ativação e desativação de comandos; funções de auditoria; diagnóstico e resolução de problemas.
Para interagir com o HSM e desempenhar tarefas administrativas, podemos ligar-nos diretamente a
ele, através dispositivos de input/output, como PIN Entry Devices (PEDs), utilizandoPED keyspara nos
autenticarmos. Tipicamente, na instalação e configuração doHSM, na inicialização de partições, bem na
cerimónia de chaves, utilizam-se os PEDs e asPED keys, que são atribuídas aos diferentes utilizadores.
CAPÍTULO 3. TECNOLOGIAS
partições, através de uma ferramenta de administração na linha de comandos. Certos comandos podem, no entanto, continuar a exigir autenticação do utilizador no PED.
Para que aplicações cliente possam aceder a uma determinada partição e nela realizar operações criptográficas, utilizando aAPIdoHSM, tem de lhes ser fornecida a password de acesso a essa partição.
3.3.2 PKCS #11: Cryptographic Token Interface Standard
O PKCS#11 [7] foi inicialmente concebido para aceder a smartcards, mas acabou por se tornar também
naAPIde referência para osHSMs, apesar da maior complexidade do dispositivo. Devido à conceção inicial do standard, a sua terminologia acabou por ser influenciada por conceitos utilizados nos smartcards: um token (ex: smartcard) é um dispositivo que armazena objetos (chaves, certificados) e realiza operações criptográficas, que pode ser acedido a partir de um slot (ex: smartcard reader). Segundo esta terminologia,
podemos dizer que os HSMs estão divididos em slots, que contêm tokens, e que por sua vez contêm
múltiplos objetos (chaves).
O standard define dois tipos de utilizadores: o agente de segurança (administrador doHSM) e o utiliza-dor. O agente de segurança é responsável por gerir utilizadores, criando os tokens e definindo os respetivos
PINs. NosHSMs, o agente de segurança é tipicamente autenticado por meio de um smartcard.
Para aceder aos seus objetos e para realizar operações, um utilizador tem de autenticar-se perante o token que lhe foi atribuído, utilizando o seu PIN. A autenticação resulta no estabelecimento de uma sessão com o token, através da qual o utilizador pode usufruir da funcionalidade oferecida pelo token, fazendo chamadas através da interface ou daAPI.
Existem dois tipos de objetos: aqueles que estão armazenados na memória não volátil do token, e aqueles que são voláteis, tendo apenas a duração da sessão entre a aplicação e o token.
Cada objeto possui um conjunto de propriedades que o descrevem e controlam o seu uso. Por exemplo,
cada chave possui uma propriedade designada porkey type, que indica se uma chave é pública ou privada.
Uma chave privada possui uma propriedade que indica se pode ou não ser extraída do token.
3.3.3 Critérios para a seleção de um HSM
Para escolher umHSM, devemos ter em consideração:
• Número de chaves suportado;
• Os algoritmos e as operações que oferece, bem como a qualidade do gerador de números aleatórios; • Desempenho nas operações criptográficas;
• AAPIcriptográfica que oferece; • Gestão M de N;
3.3. HARDWARE SECURITY MODULES
• Certificação do dispositivo (FIPS140-2,CCEAL4+);
• Possibilidade de integração numcluster deHSMs, para se obter alta disponibilidade e
balancea-mento de carga;
• O sistema operativo suportado;
CAPÍTULO 3. TECNOLOGIAS
3.4 Métodos de Autenticação
A autenticação é uma propriedade de segurança utilizada em qualquer sistema de informação em que exista a necessidade de restringir o acesso a recursos. A autenticação não lida diretamente com permissões ou privilégios de acesso, no entanto, o sistema utiliza uma prova de identidade que lhe é fornecida para tomar esse tipo de decisões.
Para um utilizador se autenticar, ele identifica-se e apresenta uma prova (ou token) que permite ao sistema determinar se ele é quem diz ser, verificando se a informação fornecida pelo utilizador corresponde com a informação existente no sistema, definida numa fase de registo.
Essa prova constitui um fator de autenticação, e pode ser algo que o utilizador sabe, algo que ele possui, ou algo que ele é, isto é, uma característica física.
Em ambientes remotos, o utilizador identifica-se tipicamente por um nome de utilizador, e autentica-se usando uma password, que é também do conhecimento do sistema.
O grau de importância do recurso que está a ser protegido tem direta influência no processo de autenti-cação necessário para aceder a ele. Por isso, para proteger recursos críticos, torna-se necessário recorrer a fatores de autenticação adicionais - autenticação multifator.
Geralmente, uma autenticação multifator é mais segura que a utilização de apenas um fator. No entanto,
existem combinações que asseguram um maior nível de segurança que outras. A publicação [8] é uma
importante referência para avaliar o nível de garantia de segurança de uma autenticação multifator baseada em diversas combinações de tokens. Uma vez que no contexto desta dissertação estamos preocupados em proteger o acesso a um recurso crítico - uma chave privada de assinatura - vamos debruçar-nos sobre tokens de autenticação que, numa escala de 1 a 4, permitem atingir os níveis 3 ou 4.
• Dispositivos geradores de One-Time Passwords (OTPs): dispositivos de hardware seguros, que
armazenam uma chave simétrica que permite a geração deOTPs. Os dispositivos podem apresentar
automaticamente as OTPs (nível 3), ou então podem ser ativados por um fator adicional para as
apresentar (nível 4).
• Dispositivos criptográficos: dispositivos de hardware seguros que desempenham operações cripto-gráficas sobre um determinado input, utilizando chaves criptográficas, simétricas ou assimétricas. Permitem obter o nível 3. Se forem ativados por um fator adicional permitem obter o nível 4. • Aplicações de software de dois fatores: aplicações que utilizam chaves criptográficas armazenadas
em disco ou emkeystores, para gerarOTPs ou processar um determinadoinput. São ativadas por
um fator adicional e permitem obter o nível 3.
• Tokens out-of-band: token que pode receber um segredo através de um canal diferente daquele utilizado na autenticação. Permite obter o nível 3. Os telemóveis são um exemplo deste tipo de
3.4. MÉTODOS DE AUTENTICAÇÃO
tokens.
Autenticação baseada em SMS OTP
Este tipo de autenticação baseia-se na geração deOTPs do lado do servidor, e no seu envio por SMS
através da rede GSM/3G. É um dos tipos de autenticação mais convenientes, visto que não requer a aquisição de um dispositivo adicional.
Embora sejam muito utilizados, os mecanismos de autenticação baseados em SMSOTPs são
vulne-ráveis a uma série de ataques. Por exemplo, o utilizador pode, sem intenção, instalar malware no seu
smartphone, capaz de capturar o conteúdo das SMS. A própria cifra utilizada na rede GSM/3G, é vulnerá-vel a ataques.
Para mitigar essas vulnerabilidades, foram já propostos esquemas de cifragem de SMS ponto a ponto,
como o de [9]. Neste esquema, asOTPs são enviadas cifradas por uma chave simétrica, acordada entre o
provedor do serviço e o utilizador por meio de um protocolo de troca de chaves (ex: Diffie-Hellman), sendo
decifradas por uma aplicação, quando são recebidas. O facto de receber aOTP no seu telemóvel e de
conseguir decifrá-la, permite ao utilizador provar a pose do dispositivo.
Ainda assim, este esquema não oferece proteção contra ataques man-in-the-middle e phishing, por
exemplo. Tendo em conta possíveis atrasos na entrega das SMS, asOTPs têm de ser válidas durante mais
tempo, o que dá mais tempo aos atacantes para levarem a cabo esse tipo de ataques.
Por outro lado, tipicamente é necessário requisitar os serviços de um provedor externo ao sistema - um
SMS Gateway, que pode não ser confiável, ou pode não assegurar uma contínua disponibilidade do serviço.
Para além disso, por si só, umaOTPnão permite vincular uma transação ao utilizador que a realizou,
visto que, mesmo que tenha sido entregue ao legítimo utilizador, nada o impede de negar que o fez,
alegando por exemplo que aOTPfoi intercetada.
Autenticação baseada em chave simétrica
Neste tipo de autenticação, o utilizador possui um dispositivo de hardware ou uma aplicação de software que protege uma chave simétrica, partilhada com um servidor de autenticação. Dependendo do tipo de token, a chave pode ser utilizada para gerarOTPs, ou em protocoloschallenge-response. Estestokenstêm a vantagem de permitir obterOTPs de imediato, visto que são geradas do lado do cliente.
No primeiro caso, asOTPs são geradas a partir da chave simétrica (seed) armazenada no token,
uti-lizando algoritmos proprietários, oustandard, como o Time-Based One-Time Password (TOTP) [10], que
calcula oOTPa partir da hora atual do relógio do token, ou oHMAC-Based One-Time Password(HOTP) [11],
CAPÍTULO 3. TECNOLOGIAS
OTPé validado centralmente no servidor de autenticação, que deriva umOTPutilizando o mesmo algoritmo
e a mesma chave.
Este tipo deOTPs não oferece proteção contra ataquesman-in-the-middleephishing. Embora tenham
uma validade limitada (30 segundos, tipicamente), nada impede um atacante de criar um website para os capturar os dados de autenticação do utilizador, e utilizá-los imediatamente no servidor legítimo. Por outro
lado, nossoftware tokensque utilizam o algoritmo TOTP, é possível gerarOTPs válidos para uma hora no
futuro se adiantarmos o relógio do dispositivo.
No segundo caso, o servidor gera um desafio baseado numa transação iniciada pelo utilizador, que ele deve introduzir no token, para assinar o desafio e obter a resposta. O token pode implementar, por exemplo,
o algoritmoOATH Challenge-Response Algorithm(OCRA) [12], que calcula a resposta tendo por base uma
chave simétrica e uminput. Quando submetida, a resposta é validada no servidor de autenticação, que
possui a mesma chave.
Uma das particularidades deste algoritmo, que pode conferir alguma proteção contraphishinge ataques
man-in-the-middle, consiste na utilização de certos parâmetros das ligações TLS, negociados pelo servidor
com cada cliente que estabelece uma ligação segura, como é o caso do identificador da sessão TLS [13].
Suponhamos que um atacante faz um pedido ao servidor, para o qual é gerado um desafio. Do lado do servidor, será gerada uma resposta tendo por base o identificador da sessão TLS com o atacante. O atacante apresenta o desafio numa página falsa à vítima. Como o cliente estabelece uma ligação TLS com a página falsa, será utilizado o identificador dessa sessão para calcular a resposta. Assim, a vítima irá submeter uma resposta que será invalidada quando o atacante a reencaminhar para o servidor.
Autenticação baseada em criptografia de chave pública
Neste tipo de autenticação, o utilizador possui um dispositivo de hardware ou uma aplicação de software, que gera um par de chaves: a chave privada é protegida pelo dispositivo ou aplicação, e a chave pública é enviada para o servidor de autenticação, sendo associada ao utilizador.
O processo de autenticação consiste tipicamente num protocolochallenge-response, em que o servidor
envia um desafio, único para cada transação (nonce), que é assinado pelo cliente com a chave privada,
sendo verificado no servidor com a respetiva chave pública.
Na maior parte das aplicações móveis que implementam este tipo de autenticação, o processo é com-pletamente transparente para o utilizador. Quando o utilizador se pretende autenticar, ele recebe simples-mente uma notificaçãopush, para aceitar ou rejeitar o início de sessão. Embackground, o servidor gera e envia um desafio para a aplicação do utilizador, que trata de o assinar utilizando a chave privada gerada inicialmente, sendo a assinatura enviada de volta para o servidor, onde é, por fim, verificada. ODuo Push
[14] ou oAuthy OneTouch[15] são dois exemplos desse tipo aplicações.
3.4. MÉTODOS DE AUTENTICAÇÃO
Ao nível das soluções baseadas em dispositivos de hardware, podemos referir o protocolo Universal
2nd Factor(U2F) [16], proposto pelaFIDO Alliance, que tem vindo a destacar-se não só pela proteção que
oferece face a inúmeros ataques, inclusivephishing eman-in-the-middle, mas também pela sua simples
experiência com o utilizador, visto que um simples toque no dispositivo é suficiente para o autenticar. Para cada website em que o utilizador usa o protocolo U2F, o dispositivo gera um par de chaves, relacionado com o URL do website, e armazena-o numa estrutura chave-valor. A chave pela qual o par de chaves está indexado, bem como a chave pública gerada, são enviadas para o servidor, que associa esta informação à conta do utilizador.
Na autenticação propriamente dita, o servidor envia um desafio, a chave de indexação, o URL da aplicação que originou o pedido e o identificador do canal TLS. O URL permite validar a origem para
evitarphishinge o identificador do canal TLS funciona como um identificador de sessão, assegurando que
o utilizador que está a autenticar-se foi aquele que efetivamente iniciou o pedido, prevenindo ataques man-in-the-middle. Feitas essas verificações, a chave privada é obtida a partir da chave de indexação, sendo utilizada para finalmente assinar o desafio e gerar a resposta, que é enviada de volta para o servidor. Segurança das chaves de autenticação
A segurança dos esquemas de autenticação apresentados depende obviamente da segurança das cha-ves.
Nos dispositivos de hardware, as chaves encontram-se protegidas por mecanismostamper-resistant.
As aplicações de software implementam mecanismos para impedir a clonagem das configurações da aplicação (ex: identificador do dispositivo, PIN). Relativamente à proteção das chaves propriamente dita,
existem duas abordagens: armazená-la nakeystore do sistema ([17] [18]), que pode ser implementada
em software, ou suportada por hardware; ou armazená-la nainternal storage da aplicação, um diretório
acessível apenas pela aplicação [19].
Quer askeystores implementadas em software, quer o uso dainternal storage, levantam problemas.
O facto de naskeystoresimplementadas em software, as chaves serem carregadas para a RAM, permite
tirar partido de ataquesbuffer overflow para as expor, algo que foi demonstrado possível em versões do
Android 4.3 ou inferior [20]. Caso o utilizador tenha acessoroot, então poderá aceder a qualquer diretório, incluindo ainternal storagede qualquer aplicação, e assim obter chaves.
A alternativa mais segura é uma keystore suportada por hardware, disponível em smartphones que
possuam um secure element ou um trusted execution environment, que ainda não são características
muito comuns.
Não nos podemos esquecer também da segurança das chaves do lado do servidor. No caso dos processos de autenticação baseados em chaves simétricas, é crucial assegurar que as chaves se encontrem
CAPÍTULO 3. TECNOLOGIAS
protegidas, visto que um atacante pode também tentar obter as chaves para comprometer todo mecanismo
de autenticação, como já aconteceu com a RSA SecurID [21].
Análise comparativa dos tipos de autenticação
Dado que um dos objetivos de um sistema de assinatura remota é a desmaterialização do token cripto-gráfico, não faz sentido pensar em mecanismos de autenticação que requerem um token dedicado. Vamos, por isso, aproveitar um dispositivo que os utilizadores possuem à partida - um telemóvel. A análise que se
segue é, por isso, focada numa autenticaçãomobile-based.
SMS OTP Criptografia simétrica Criptografia assimétrica Compatibilidade Qualquer telemóvel Apenas smartphones Apenas smartphones
Estabelecimento da chave Gerada pelo servidor Acordo de chaves com o servidor de autenticação Geração de par de chaves e envio da chave pública Localização da chave secreta Do lado do servidor Do lado do cliente e do lado do servidor Do lado do cliente
Conexão à Internet Não é necessária Apenas necessária no caso do challenge-response Necessária Algoritmos/Protocolos Gerador de números aleatórios Time/Event-based OTPs, Challenge-response Challenge-response Não-repúdio Não permite Não permite Permite
Tabela 3.2: Análise comparativa dos tipos de autenticaçãomobile-based.
Do ponto de vista do provedor de serviços, uma autenticação baseada em criptografia assimétrica apre-senta claramente características muito interessantes, no que diz respeito à salvaguarda da chave secreta, desresponsabilizando-o em caso de comprometimento, e à propriedade de não-repúdio, que lhe permite provar que o utilizador que se autenticou foi efetivamente o responsável por determinada transação.
