Interoperabilidade FIDO

(1)

Interoperabilidade

FIDO

Mateus de Campos

Mestrado em Segurança Informática

Departamento de Ciência de Computadores 2020

Orientador

Manuel Barbosa, Professor Auxiliar, FCUP

Coorientador

(2)

(3)

Authentication has always been a challenge for information systems and has resorted to the most varied protocols to create a secure flow for the process. The storage of the secret to be verified in authentication is a process that requires effort from system architects and application of protocols and technologies. The present work was developed in compatibility with the Fast Identity Online protocol (FIDO), which aims to facilitate and standardize a secure means for authentication, based on asymmetric keys.

The work developed aims to create subsidies for the interoperability of the Loqr SA company system to the FIDO protocol. Through a requirements analysis and a study of the use cases of the protocol, possible scenarios are defined to be integrated into the system of the company that has its own protocol. The result is the specification for the implementation of the WebAuthn protocol on the company’s server and an authenticator module compatible with the FIDO protocol and integrable with the mobile solution of the Loqr SA system.

(4)

(5)

A autentica¸cão sempre foi um desafio dos sistemas de informa¸cão e recorreu aos mais variados protocolos para criar um fluxo seguro para o processo. O armazenamento do segredo a ser verificado na autentica¸cão é um processo que exige esfor¸co dos arquitetos dos sistemas e aplica¸cão de protocolos e tecnologias. O presente trabalho foi desenvolvido em compatibilidade com o protocolo Fast Identity Online (FIDO), que visa facilitar e padronizar um meio seguro para a autentica¸cão, baseado em chaves assimétricas.

O trabalho desenvolvido visa criar subs´ıdios para a interoperabilidade do sistema da empresa Loqr SA ao protocolo FIDO. É feita uma análise de requisitos e um estudo dos casos de uso do protocolo poss´ıveis de serem integrados ao sistema da empresa que possui um protocolo próprio. O resultado é a especifica¸cão para a implementa¸cão do protocolo WebAuthn no servidor da empresa e um módulo autenticador compat´ıvel com o protocolo FIDO e integrável a solu¸cão móvel do sistema da empresa Loqr SA.

(6)

Agrade¸co a todos que de alguma forma influenciaram minha vida, minha carreira e meu desejo de buscar conhecimento.

(7)

(8)

Abstract 3

Resumo 5

Lista de Tabelas 12

Lista de Figuras 14

Lista de Blocos de C´odigo 15

Lista de Abreviaturas 18 1 Introdu¸cão 20 1.1 Apresenta¸cão do Projeto . . . 20 1.2 Metodologia . . . 21 1.3 Organiza¸cão do Documento . . . 22 2 Conceitos Básicos 25 2.1 Fun¸cão Hash . . . 25 2.1.1 SHA-256 . . . 26 2.2 Assinatura Digital. . . 27 2.2.1 ECDSA . . . 28 8

(9)

2.2.3 Autentica¸c˜ao com Assinatura Digital . . . 30

2.2.4 Atesta¸c˜ao . . . 30

2.3 Algoritmo AES . . . 32

2.4 Infraestrutura de Chaves P´ublicas . . . 32

2.5 Protocolo TLS. . . 34 3 FIDO2 37 3.1 Introdu¸c˜ao . . . 37 3.2 WebAuthn . . . 39 3.2.1 Registro . . . 39 3.2.2 Autentica¸c˜ao . . . 41 3.3 CTAP . . . 43 3.3.1 MakeCredential . . . 43 3.3.2 GetAssertion . . . 45 3.4 Requisitos de Seguran¸ca . . . 46 3.5 Estado da Arte . . . 50

4 An´alise de Requisitos 53 4.1 Introdu¸c˜ao . . . 53

4.2 Solu¸c˜ao Loqr SA . . . 53

4.3 Arquitetura . . . 56

4.3.1 Servidor Loqr SA e Aplica¸c˜ao Loqr SA . . . 57

4.3.2 Servidor Loqr SA e Autenticadores de Terceiros . . . 57

4.3.3 Aplica¸c˜ao Loqr SA e Servidores de Terceiros . . . 58

4.3.4 Adapta¸c˜ao ao FIDO . . . 59 9

(10)

4.5 Servidor WebAuthn . . . 61 4.5.1 Registrar. . . 62 4.5.2 Autenticar . . . 63 4.6 Autenticador FIDO . . . 63 4.6.1 Registrar. . . 64 4.6.2 Autenticar . . . 66 5 Desenvolvimento 69 5.1 Servidor WebAuthn . . . 69 5.1.1 Registro . . . 72 5.1.2 Autentica¸c˜ao . . . 73 5.2 Autenticador FIDO . . . 74

5.2.1 Componente Cliente WebAuthn . . . 75

5.2.1.1 Interface de Registro . . . 76

5.2.1.2 Interface de Autentica¸c˜ao . . . 77

5.2.2 Componente Token FIDO . . . 78

5.2.2.1 M´etodo CreateCredential() - Classe Authenticator . . 79

5.2.2.2 M´etodo GetAssertion() - Classe Authenticator . . . 86

6 Resultados 91 6.1 Ambiente de Execu¸cão . . . 91 6.2 Processo de Registro . . . 93 6.3 Processo de Autentica¸cão. . . 96 7 Conclusão 101 7.1 Resumo da Solucão . . . 101 10

(11)

7.3 Trabalhos Futuros. . . 102

7.4 Considera¸c˜oes Finais . . . 103

A RFC 7049 - Concise Binary Object Representation (CBOR) 105

A.1 Objetivos . . . 105

B RFC 8152 - CBOR Object Signing and Encryption (COSE) 107

Referˆencias 110

(12)

3.1 Rela¸c˜ao de Metas de Seguran¸ca X Medidas Implementadas . . . 50

5.1 Conte´udo do Objeto authData . . . 82

5.2 Conte´udo do Objeto attestedCredentialData . . . 83

A.1 Item de Dados CBOR . . . 106

(13)

3.1 Fluxo FIDO2 (WebAuthn + CTAP) . . . 39

3.2 Fluxo de Registro WebAuthn . . . 41

3.3 Fluxo de Autentica¸c˜ao WebAuthn . . . 42

3.4 Objeto AuthData . . . 44

3.5 Objeto signature . . . 45

4.1 Emparelhamento Sistema Loqr SA . . . 55

4.2 Autentica¸c˜ao Sistema Loqr SA. . . 56

4.3 Servidor Loqr SA e Aplica¸c˜ao Loqr SA . . . 57

4.4 Servidor Loqr SA e Autenticadores de Terceiros . . . 58

4.5 Autenticador Loqr SA e Servidores de Terceiros . . . 58

4.6 Adapta¸c˜ao do Sistema Loqr . . . 60

4.7 Casos de Uso do Servidor . . . 61

4.8 Diagrama de Sequˆencia - Registro . . . 62

4.9 Diagrama de Estados - Registro . . . 62

4.10 Diagrama de Sequˆencia - Autentica¸c˜ao . . . 63

4.11 Diagrama de Estados - Autentica¸c˜ao . . . 63

4.12 Casos de Uso do Cliente (Autenticador). . . 64

4.13 Diagrama de Estados - Registrar . . . 65 13

(14)

5.1 Diagrama de Classes (Reduzido) do Autenticador . . . 75

5.2 Sequˆencia da Interface de Registro . . . 77

5.3 Sequˆencia da Interface de Autentica¸c˜ao . . . 78

5.4 Diagrama de Classes - Registrar . . . 80

5.5 Diagrama de Classes - Autenticar . . . 87

6.1 P´agina HTML do Servidor . . . 92

6.2 Solicita¸c˜ao de Registro Windows Hello . . . 94

6.3 Solicita¸c˜ao de Registro Solo Key . . . 94

6.4 Hardware Solo Key . . . 95

6.5 Informa¸c˜ao de Registro na P´agina HTML do Servidor . . . 95

6.6 Fluxo de Registro Autenticador . . . 96

6.7 Sele¸c˜ao do Dispositivo para Autentica¸c˜ao . . . 97

6.8 P´agina com as Credencias Registradas . . . 98

6.9 Fluxo de Autentica¸c˜ao Autenticador . . . 99

(15)

5.1 Gera¸c˜ao do Objeto authData . . . 83

5.2 Gera¸c˜ao do Objeto attestedCredentialData . . . 84

5.3 Codifica¸c˜ao da Chave P´ublica no Formato COSE . . . 85

5.4 Gera¸c˜ao do Array de Bytes para Assinatura . . . 89

5.5 Gera¸c˜ao do Objeto signature . . . 89

6.6 Container Servidor em Execu¸c˜ao. . . 92

6.7 Log do Evento de Autentica¸c˜ao no Container Servidor. . . 99

(16)

AES Advanced Encryption Standard AIK Attestation Identity Key

API Application Programming Interface CA Certification Authority

CBOR Concise Binary Object Representation

COSE Concise Binary Object Representation (CBOR) Object Signing and Encryption

CRL Certificate Revocation List

CTAP Client to Authenticator Protocol DAA Direct Anonymous Attestation DoS Denial of Service

EC Elliptic Curve

ECC Elliptic Curve Cryptography

ECDAA Eliptic Curve Direct Anonymous Attestation ECDSA Elliptic Curve Digital Signature Algorithm EK Endorsement Key

FIDO Fast Identity Online

FIPS Federal Information Processing Standards FTP File Transfer Protocol

(17)

HMAC Hash-based Message Authentication Code HTML Hypertext Markup Language

HTTP Hypertext Transfer Protocol

HTTPS Hypertext Transfer Protocol Secure ICP Infraestrutura de Chaves P´ublicas IDE Integrated Development Environment

IEEE Institute of Electrical and Electronics Engineers IETF Internet Engineering Task Force

IPSec IP Security Protocol JAR Java Archive

JSON JavaScript Object Notation NFC Near Field Communication

NIST National Institute of Standards and Technology PKI Public Key Infrastructure

RA Registration Authority RFC Request for Comments RSA Rivest Shamir Adleman

SMTP Simple Mail Transfer Protocol SSH Secure Shell

SSL Secure Sockets Layer SSO Single Sign-On

SHA Secure Hash Algorithm

TCP Transmission Control Protocol 17

(18)

TPM Trusted Platform Module URL Uniform Resource Locator USB Universal Serial Bus

UTF Unicode Transformation Format W3C World Wide Web Consortium

(19)

(20)

Introdu¸

c˜

ao

Este cap´ıtulo apresenta uma visão geral sobre o projeto e como surgiu a necessidade que motivou seu desenvolvimento. Em seguida é apresentado o método para seu desenvolvimento e por fim uma descri¸cão do documento e do conteúdo de cada cap´ıtulo.

1.1 Apresenta¸

c˜

ao do Projeto

A proposta do projeto surgiu com a parceria entre a empresa Loqr SA e a Faculdade de Ciências da Universidade do Porto. O objetivo foi conciliar o ambiente de pesquisa e desenvolvimento da Faculdade com um cenário de mercado em que a empresa Loqr SA está inserido.

Desenvolvido no âmbito da disciplina de Disserta¸cão do mestrado em Seguran¸ca Informática, ministrado no Departamento de Ciência de Computadores. A proposta do trabalho era analisar a solu¸cão de autentica¸cão existente da empresa Loqr SA e elaborar um plano de adapta¸cão para alcan¸car a interoperabilidade com o protocolo Fast Identity Online (FIDO). Para a Loqr SA o projeto representa um acréscimo nos protocolos suportados por sua solu¸cão, que diretamente amplia a tecnologia que pode ser utilizada por seus clientes e os servi¸cos que podem ser integrados ao seu sistema.

O FIDO é um protocolo criado por uma alian¸ca de empresas que foi denominada FIDO Alliance e posteriormente foi padronizado pelo World Wide Web Consortium (W3C). O FIDO, Fast IDentity Online, é um protocolo de autentica¸cão baseado em

(21)

chaves públicas. Sua estrutura prevê um protocolo para o servidor, o WebAuthn, e outro para o cliente, o Client to Authenticator Protocol (CTAP). Entre eles o navegador do cliente deve ter compatibilidade com o protocolo, pois é o navegador que faz a interlocu¸cão da comunica¸cão.

O desafio é permitir que um cliente possa utilizar um autenticador FIDO para autenticar-se no servidor da empresa Loqr SA. E também permitir que a aplica¸cão cliente da Loqr efetue esta autentica¸cão utilizando o mesmo padrão. Mas, sem que essa integra¸cão do novo protocolo interfira no funcionamento da solu¸cão existente, que utiliza um protocolo próprio e serve a vários clientes.

Este trabalho expõe uma solu¸cão aplicável a parte dos cenários de utiliza¸cão, mas que permite a expansão da implementa¸cão para atender a todos os cenários poss´ıveis. A implementa¸cão é definida por um servidor WebAuthn que pode ser integrado ao servidor atual da empresa Loqr SA e um autenticador que segue os padrões do protocolo desenvolvido na linguagem Java e que pode ser integrado à aplica¸cão da empresa Loqr SA para sistema Android. Em um cenário comum, esta comunica¸cão ocorre através de um navegador, o que se tornou um desafio adicional, já que a aplica¸cão desenvolvida não utiliza um navegador e efetua a interlocu¸cão direta com o servidor.

1.2 Metodologia

Para a implementa¸cão do projeto é utilizada uma metodologia baseada em quatro etapas principais. O primeira passo é um debate técnico com a equipe da empresa Loqr SA, seguido da análise de requisitos da solu¸cão debatida. Após é feito o desen-volvimento da solu¸cão e a análise dos resultados.

O debate técnico sobre a solu¸cão é permeado pela preocupa¸cão em atingir o objeto da interoperabilidade do protocolo sem interferir no funcionamento do protocolo exis-tente. O fluxo da comunica¸cão dos protocolos é diferente e demanda um estudo dos casos de uso a serem implementados. O resultado do planejamento é a cria¸cão de um módulo servidor e outro autenticador independentes da solu¸cão.

(22)

A análise de requisitos leva em conta dois pontos de análise, o sistema Loqr SA e o protocolo FIDO. O primeiro passo é a análise do sistema Loqr SA, dos seus cenários de utiliza¸cão e das poss´ıveis aplica¸cões do protocolo FIDO em sua arquitetura. O segundo passo é uma análise de requisitos de seguran¸ca, levando em conta as diretrizes do protocolo FIDO. Na sequência é necessário a defini¸cão dos requisitos do servidor, seguindo o protocolo WebAuthn. Depois é efetuada a análise de requisitos do cliente autenticador, que deve levar em conta as fun¸cões do navegador na interlocu¸cão da comunica¸cão e doCTAP, que cria e gere as credenciais.

O desenvolvimento da solu¸cão é divido em duas etapas: a primeira é a execu¸cão de um servidor WebAuthn implementado pela Duo Labs, que utiliza um padrão de comunica¸cão Hypertext Transfer Protocol (HTTP) e que implementa uma Application Programming Interface (API) WebAuthn de código aberto; a segunda etapa é a im-plementa¸cão de uma aplica¸cão na linguagem Java que autentica no servidor composta por duas camadas: uma executando as fun¸cões de comunica¸cão desempenhadas por um navegador, utilizando os endpoints de cada processo do servidor; a outra camada implementa as fun¸cões do CTAP para criar e gerir as credenciais.

Por fim é feita a análise dos resultados, utilizando compara¸cões com outros au-tenticadores para analisar a eficácia do módulo desenvolvido. É poss´ıvel comparar a utiliza¸cão da aplica¸cão autenticadora com autenticadores FIDO que utilizam o navegador, levando em conta a chave gerada em cada um dos casos.

1.3 Organiza¸

c˜

ao do Documento

Esta sessão apresenta a disposi¸cão dos cap´ıtulos e o conteúdo dos mesmos, expondo uma visão geral sobre os capt´ıtulos que sucedem a introdu¸cão.

No cap´ıtulo 2 são expostos conceitos necessários para o entendimento do conteúdo do trabalho, assim como fundamentos técnicos utilizados pelo protocolo FIDO. Apre-senta uma visão geral sobre protocolos utilizados num ambiente web, o conceito de autentica¸cão com base em assinaturas e o protocolo Transport Layer Security (TLS), que estabelece a seguran¸ca na maior parte dos protocolos na Internet.

(23)

No ca´ıtulo 3 é apresentado o conceito do protocolo FIDO, como deve ser a im-plementa¸cão dos processos e a visão geral de como é feita a comunica¸cão entre a parte confiável e o cliente que faz a autentica¸cão. Também é feita uma rela¸cão do protocoloFIDO e a implementa¸cão do projeto com o desafio de aprimorar o processo de autentica¸cão. É exposta uma visão da maturidade da implementa¸cão em face às implementa¸cões mais comuns existentes no mercado.

O cap´ıtulo 4 apresenta a análise de requisitos, com uma análise de requisitos de seguran¸ca, os requisitos da implementa¸cão do servidor, seguido dos requisitos do cliente autenticador. São apresentados casos de uso, diagramas de estados e de classes para cada um dos componentes, fazendo uma rela¸cão entre os processos do servidor e do cliente.

O cap´ıtulo 5 expõe o desenvolvimento da solu¸cão. Primeiro exibindo o processo de execu¸cão do container com o servidor e posteriormente o autenticador, as bibliotecas utilizadas e os protocolos empregados através da linguagem Java.

No cap´ıtulo 6, dedicado a mostrar os resultados da implementa¸cão, são exibidos os resultados dos processos de registro e autentica¸cão, em compara¸cão com outros autenticadores. Permitindo a comprova¸cão da eficácia da solu¸cão desenvolvida.

Por fim, o cap´ıtulo 7 expõe a conclusão do trabalho, analisando os resultados em face ao objeto inicial do projeto. Além de expor o que seriam trabalhos futuros com potencial utilizando a base de conhecimento e os artefatos criados pelo trabalho.

(24)

(25)

Conceitos B´

asicos

Os conceitos básicos são uma fundamenta¸cão teórica para facilitar o entendimento dos próximos cap´ıtulos, descrevendo mecanismos e padrões utilizados no desenvolvimento deste trabalho. Serão descritos conceitos de criptografia, assinaturas, infraestrutura de chaves públicas e o protocolo TLS que sustenta a comunica¸cão segura de muitos protocolos na Internet.

2.1 Fun¸

c˜

ao Hash

A fun¸cão hash é uma opera¸cão criptográfica que transforma dados de tamanho variável em um valor de tamanho fixo. Esta fun¸cão tem diversas aplica¸cões na criptografia moderna, a principal delas é a verifica¸cão da integridade de uma mensagem.

O hash de uma mensagem enviada ou armazenada é utilizado para comparar com o hash gerado após o recebimento ou processamento da mesma mensagem e atestar a integridade dos dados. Para que a fun¸cão cumpra seu objetivo de forma correta e segura é necessário que o algoritmo da fun¸cão possua algumas carater´ısticas:

• Unidirecionalidade: conhecido um hash de uma mensagem, deve ser imposs´ıvel obter a mensagem atrav´es dele. Caracter´ıstica que denomina a fun¸c˜ao hash uma one-way-function.

• Compress˜ao: independente do tamanho de uma mensagem, o resultado de sua fun¸c˜ao hash possui um tamanho fixo.

(26)

• Facilidade de cálculo: deve ser fácil gerar o valor hash a partir da mensagem. • Difusão: todos os bits de uma mensagem devem influenciar no resultado da

fun¸c˜ao. Exemplo: se um bit da mensagem mudar, o valor hash deve ter mudan¸ca de grande quantidade dos bits.

• Colis˜ao simples: conhecido o hash de uma mensagem, deve ser imposs´ıvel en-contrar outra mensagem com o mesmo resultado de hash.

• Colis˜ao forte: deve ser imposs´ıvel encontrar duas mensagens com o mesmo resultado de hash.

2.1.1 SHA-256

O Secure Hash Algorithm (SHA), traduzido como Algoritmo de Dispersão Seguro, é um grupo de fun¸cões hash projetadas pela Agência de Seguran¸ca Nacional dos Estados Unidos. O SHA-256 faz parte do grupo de fun¸cões publicadas na versão SHA-2, em 2001, pelo National Institute of Standards and Technology (NIST), através da publica¸cão 180-4[15] do Federal Information Processing Standards (FIPS). Além do SHA-256 bits, a versão SHA-2 define outras cinco fun¸cões com hashes de tamanhos 224, 384, 512, 512/224 e 512/256 bits.

O SHA-256 gera um hash com 256 bits e em seu algoritmo utiliza blocos com 512 bits e palavras (divisões dos blocos) com 32 bits. Por ter esta estrutura, o primeiro passo do algortimo é o preenchimento da mensagem para que se torne divis´ıvel em blocos de 512 bits. A segunda etapa é a divisão em blocos e cada bloco em palavras (dezesseis palavras). São definidas oito variáveis de código hash com 32 bits que compõem o valor final do hash e que serão alteradas pelo processamento dos blocos.

A repeti¸cão de opera¸cões em cada bloco segue uma sequência:

• Estender as 16 palavras para 64 palavras; • Iniciar vari´aveis funcionais;

• Repeti¸cão de uma nova fun¸cão 64 vezes; • Atualiza variáveis hash.

(27)

As fun¸cões repetidas nos blocos envolvem opera¸cões de rota¸cão bit a bit das palavras e XOR (opera¸cão lógica OU exclusivo), que agregam complexidade e caracterizam o algoritmo não revers´ıvel. O SHA-2 possui um sucessor (SHA-3) desde 2015, mas ainda ´

e muito utilizado em sistemas e protocolos.

2.2 Assinatura Digital

A assinatura digital é um mecanismo onde a criptografia assimétrica pode ser aplicada. O objetivo da assinatura digital é garantir a integridade e a autenticidade das mensa-gens, consequentemente o não repúdio. Ou seja, a assinatura digital visa permitir a verifica¸cão que a mensagem está ´ıntegra e foi remetida pelo proprietário da identidade digital.

O algoritmo de assinatura digital deve incluir um processo que assina e outro que verifica a assinatura. Cada signatário possui um par de chaves, uma pública conhecida por todos e outra privada. Com a chave privada o signatário assina a mensagem e o receptor utiliza a chave pública para verificar a assinatura. O algoritmo deve garantir que a gera¸cão da assinatura seja poss´ıvel somente com a chave privada e a verifica¸cão da assinatura seja poss´ıvel somente com a respectiva chave pública.

De acordo com o padrão FIPS 186-4 [13], que define os padrões de assinaturas digitais segundo o NIST, o processo de assinatura de uma mensagem consiste na gera¸cão de um hash da mensagem e posteriormente a assinatura (Sign) com a chave privada(Sk) deste valor hash. A mensagem assinada consiste na soma da assinatura do hash com a mensagem: (Sign(Sk, H(mensagem)), mensagem).

Este processo não garante privacidade para as mensagens, uma vez que a mensagem não é cifrada. Garante a integridade e a autenticidade da mensagem através do processo de verifica¸cão, que inicia após o recebimento do pacote com a mensagem e a assinatura. A mensagem é utilizada na verifica¸cão, onde o hash da mensagem é utilizado para compara¸cão com o hash assinado.

A verifica¸cão da assinatura (Ver) é baseada em uma fun¸cão que recebe a chave pública (Pk) junto com a assinatura (signature). O resultado é o conteúdo que foi

(28)

assinado, posteriormente comparado com o hash da mensagem. Se a assinatura é au-tentica e o conteúdo da mensagem não foi alterado, o resultado da fun¸cão de verifica¸cão da assinatura deve ser igual ao hash da mensagem recebida: (V er(P k, signature) = H(mensagem)).

2.2.1 ECDSA

O Elliptic Curve Digital Signature Algorithm (ECDSA) é um algoritmo de assinaturas digitais que utiliza chaves geradas com criptografia de curvas el´ıptcas, Elliptic Curve Cryptography (ECC). As curvas el´ıpticas são obtidas de uma equa¸cão cúbica, mas já são pré-definidas com um n´ıvel de complexidade que garante a seguran¸ca do algoritmo, o FIPS 186-4[13] recomenda quinze varia¸cões de curvas para a gera¸cão das chaves.

A defini¸cão de uma curva el´ıptica é baseada nos valores dos coeficientes a e b da equa¸cão y2 = x3+ a ∗ x + b, e um número primo p para criar um grupo finito e c´ıclico, que possui uma ordem q e pelo menos um elemento primitivo A[17]. Baseado neste conceito matemático, é gerado um par de chaves:

• Gera-se um n´umero aleat´orio d, tal que: 1 ≤ d ≤ q − 1; • Calcula-se o ponto B = d ∗ A.

A chave privada é o número d e a chave pública é o conjunto de valores p, a, b, q, A, B. A assinatura de uma mensagem utiliza os valores do par de chaves para assinar uma mensagem m utilizando os valores r e s com mesmo tamanho de bits de q. A assinatura ocorre da seguinte forma:

• Define-se um n´umero aleat´orio k, tal que 0 < k < q;

• Calcula-se R = k ∗ A e associa-se o valor da coordenada x de R na curva ao elemento r;

• Calcula-se s ≡ (h(m) + d ∗ r) ∗ k−1_{(mod q).}

O valor h(m) é o hash da mensagem m a ser assinada, cujo algoritmo utilizado compõe a defini¸cão do algoritmo de assinatura. O conjunto transmitido é composto pela mensagem e os valores calculados, na forma (m, (r, s)).

(29)

A verifica¸cão da assinatura é feita com o conhecimento da mensagem recebida (m), do conjunto de valores da chave pública (p, a, b, q, A, B) e dos valores da assinatura (r, s). A verifica¸cão é feita da seguinte forma:

• Calcula-se w ≡ s−1 _{(mod q);}

• Calcula-se u1 ≡ w ∗ h(m) (mod q); • Calcula-se u2 ≡ w ∗ r (mod q); • Calcula-se P = u1 ∗ A + u2 ∗ B

O valor P é um ponto na curva, cuja coordenada x deve equivaler ao valor de r módulo q para que a assinatura seja considerada válida. O valor h(m) é o hash da mensagem (m) gerado pelo verificador da assinatura.

2.2.2 Assinatura Digital RSA

A assinatura digital utilizando o algoritmo Rivest Shamir Adleman (RSA) consiste em um par de chavesRSA, a privada é utilizada para assinar as mensagens, enquanto a pública verifica a assinatura gerada. A chave pública é um módulo n, que é produto de dois números primos (p e q), e um expoente e, logo, a chave pública é um par de valores (n, e). A chave privada corresponde ao mesmo módulo n com um expoente privado d, que depende de n e do expoente de chave pública e.

O tamanho do valor n influencia no grau de seguran¸ca atingido pela chave e através da recomenda¸cão que trata da gestão de chaves SP 800-57[14] doNIST, são definidos três comprimentos de chave: 1024, 2018 e 3072 bits. Utilizando os parâmetros de comprimento adequados, a gera¸cão de um par de chaves consiste em:

• Escolhe-se dois n´umeros primos p e q; • Calcula-se n = p ∗ q;

• Calcula-se φ(n) = (p − 1)(q − 1);

• Escolhe-se um e tal que 1 < e < φ(n) e que e e φ(n) sejam co-primos; • Calcula-se d de forma que de ≡ 1(modφ(n)).

(30)

O propriet´ario da chave privada (d, n) executa a opera¸c˜ao s = hd _{mod n para gerar}

a assinatura s, onde h deve ser o hash da mensagem a ser assinada. A verifica¸cão é feita pelo receptor da mensagem utilizando o inverso multiplicativo de d, o valor da chave pública e através da opera¸cão: se _{= (h}d₎e _{mod n = h mod n. O receptor deve}

utilizar o valor de hash da mensagem recebida para comparar com o valor gerado pela verifica¸c˜ao da assinatura.

2.2.3 Autentica¸

c˜

ao com Assinatura Digital

Autentica¸cão é o processo que confirma a autenticidade de algo ou alguém. No ambiente virtual esse processo pode ser efetuado utilizando diferentes mecanismos e com diferentes propósitos. Quando feita com assinatura digital, a autentica¸cão utiliza chaves assimétricas, a chave pública é utilizada para verificar a identidade do interlocutor que envia a assinatura como prova de autenticidade.

Baseado nesta estrutura, o processo de autentica¸cão deve utilizar mecanismos ade-quados para garantir a autenticidade das credencias. O diretório de chaves públicas deve ser confiável, a inclusão de uma chave pública fraudulenta no diretório pode permitir que um atacante autentique-se sem ser detectado. O diretório de chaves pode fazer parte do sistema ou estar vinculado a um servidor de chaves públicas.

Se as chaves públicas do usuários estiverem no sistema é importante criar um método para registro das credenciais utilizando certificados de atestado para as chaves, garan-tindo a autenticidade das credenciais. Se as chaves públicas estiverem armazenadas em um servidor externo é necessário que exista uma cadeia de confian¸ca que interligue o sistema com o diretório que armazena as credenciais. A utiliza¸cão de assinaturas ´

e utilizada em diversos sistemas, de forma ampla aplicada ao protocolo Kerberos[10], que utiliza as chaves para autenticar e criar as sess˜oes dos ativos no sistema.

2.2.4 Atesta¸

c˜

ao

A atesta¸cão é um mecanismo criptográfico utilizado para testemunhar, confirmar ou autenticar. No contexto do WebAuthn, a atesta¸cão é utilizada para confirmar a autenticidade de um autenticador e dos dados gerados por ele, ou seja, as credenciais e os objetos que acompanham as chaves.

(31)

A atesta¸c˜ao pode ser efetuada de diversas formas, o protocolo WebAuthn prevˆe cinco tipos:

• Basic: o par de chaves de atestado do autenticador é o mesmo para os autenti-cadores de um mesmo modelo. O fabricante instala um par de chaves válido no dispositivo que é utilizado para assinar os atestados das credenciais geradas por ele. Isso torna o usuário anônimo, pois a chave do atestado está vinculada ao dispositivo, impedindo a revoga¸cão de uma chave de atestado comprometida; • Auto: o autenticador não possui uma chave de atestado, mas utiliza a própria

chave privada da credencial para assinar o objeto de atesta¸cão. Geralmente este método indica que o autenticador não possui uma medida de prote¸cão significativa das chaves privadas;

• AttCA: o autenticador é baseado em um Trusted Platform Module (TPM), um microcontrolador criptográfico, que possui uma chave de endosso, Endorsement Key (EK), espec´ıfica do autenticador. Esta chave é utilizada para se comunicar com a entidade confiável, geralmente vinculada ao fabricante do autenticador, e solicitar a assinatura de uma chave de identidade de atestado, Attestation Identity Key (AIK). O atestado é gerado com a assinatura da chave AIK, limitando a exposi¸cão da chave EK.

• Eliptic Curve Direct Anonymous Attestation (ECDAA): o autenticador utiliza atesta¸cão anônima direta baseada em curvas el´ıpticas. A atesta¸cão anônima direta, Direct Anonymous Attestation (DAA), permite que o autenticador derive chaves de atesta¸cão a partir de uma chave instalada em sua fabrica¸cão, de modo que a atesta¸cão seja atual e anônima, sem vincular a identidade do usuário que está utilizando a credencial atestada, mas que pode ser rastreada e revogada, pois utiliza uma chave de atesta¸cão sempre atual;

• None: o autenticador n˜ao gera atesta¸c˜ao para a credencial;

Através desse métodos, o servidor pode verificar a autenticidade da chave gerada e do dispositivo que a criou. Os métodos que utilizam processos que envolvem uma terceira parte confiável (AttCA e ECDAA) são considerados mais seguros. O modo de atesta¸cão básico (Basic) é um meio intermediário, pois é baseado em uma única chave que atesta todas as credenciais de uma grande quantidade de autenticadores. O modelo autoassinado (Auto) não agrega garantias de autenticidade da chave gerada.

(32)

2.3 Algoritmo AES

O Advanced Encryption Standard (AES) traduzido como Padrão de Criptografia Avan¸cado foi estabelecido pelo Instituto Nacional de Padrões e Tecnologia (NIST) dos EUA em 2001 [11]. Mas também é utilizado em larga escala na indústria, adotado em protocolos como IP Security Protocol (IPSec),TLS, Secure Shell (SSH) e também no padrão de criptografia WiFi Institute of Electrical and Electronics Engineers (IEEE) 802.11i.

´

E um padrão de criptografia simétrica que implementa a cifra de bloco Rijndael com blocos de 128 bits e chaves de tamanho 128, 192 ou 256 bits. O algoritmo utiliza dados que são denominados: S-Box, é uma tabela de substitui¸cão estática; estado, é o bloco de dados de 128 ( bits) fracionado da mensagem; a chave secreta conhecida somente pelas partes confiáveis; e a chave de expansão, derivada da chave. Estes dados são utilizados num algoritmo de cifragem baseado em quatro etapas:

• SubBytes: Substitui bytes do estado por bytes da S-Box

• ShiftRows: Desloca os bytes do estado de acordo com a fileira do bloco. • MixColumns: Multiplica os bytes do estado por um polinˆomio.

• AddRoundKey: Combina os bytes do estado com os bytes da chave de expans˜ao.

Este procedimento é aplicado ciclicamente sobre a mensagem de acordo com o tamanho da chave utilizada. O processo que decifra a mensagem é a execu¸cão do algoritmo de forma inversa. Por ser um algoritmo de chave simétrica é mais eficaz e exige menos processamento para execu¸cão se comparado com os algoritmos de chaves assimétricas.

2.4 Infraestrutura de Chaves P´

ublicas

A Infraestrutura de Chaves Públicas (ICP), ou Public Key Infrastructure (PKI), é uma organiza¸cão que inclui entidades públicas e privadas afim de criar uma estrutura de confian¸ca digital [4]. É composta por entidades com diferentes fun¸cões e que visam atribuir e verificar as identidades virtuais.

(33)

A organiza¸cão é baseada em algumas constantes que permeiam a confian¸ca mútua entre as entidades e os utilizadores:

• Autoridade de Certifica¸c˜ao Raiz, Root Certification Authority (CA): organiza¸c˜ao com mais alto n´ıvel de confian¸ca na hierarquia;

• Autoridade de Certifica¸cão (CA): organiza¸cão de confian¸ca dependente de uma Autoridade de Certifica¸cão Raiz;

• Autoridade de Registro, Registration Authority (RA): organiza¸cão que envia pedidos de cria¸cão de identidades virtuais para as Autoridades de Certifica¸cão;

• Lista de Revoga¸cão de Certificado, Certificate Revocation List (CRL): lista que reúne identidades consideradas não confiáveis após sua cria¸cão.

Essa estrutura pode ser particular, criada em um sistema, mas existe de forma pública e considerada confiável em todo o ambiente virtual. E para fazer parte as autoridades precisam cumprir diversos requisitos impostos pela organiza¸cão. A estrutura que identifica a autoridades e qualquer identidade é o certificado digital, que possui, entre outras informa¸cões, as assinaturas baseadas em chaves assimétricas do proprietário da identidade e das autoridades que a certificam.

AICPé utilizada em diversos sistemas, para autenticar e-mails, documentos e prin-cipalmente na web, validando a identidade de sites, dando base para vários protocolos, entre eles o TLS e o processo de valida¸cão da atesta¸cão no FIDO. As identidades dos sites são validadas pelos clientes através da infraestrutura de chaves públicas, onde os pacotes recebidos pelo cliente possuem a assinatura da chave privada do site.

O que permite a valida¸cão das identidades pelo cliente é a lista de chaves de Autoridades de Certifica¸cão Raiz Confiáveis instaladas nos sistemas operacionais.

´

E através dessas chaves que as Autoridades de Certifica¸cão e as identidades por elas assinadas são reconhecidas como autênticas. Com essa lista de Autoridades de Certifica¸cão Raiz também são obtidas as Lista de Revoga¸cão de Certificados.

(34)

2.5 Protocolo TLS

Na Internet, na maior parte das comunica¸cões, é fundamental que haja privacidade, além da integridade das informa¸cões. Isto significa que um observador externo não seja capaz de visualizar ou de alterar as mensagens. O protocolo TLS é a base para a comunica¸cão segura na web, que permite a confian¸ca entre o cliente e o servidor. O TLS sucedeu o Secure Sockets Layer (SSL), considerado obsoleto pela Internet Engineering Task Force (IETF), passou por atualiza¸cões de sua implementa¸cão e sua versão 1.3, lan¸cada em agosto de 2018[7], tornou-se a versão confiável do protocolo.

OTLSestabelece uma conexão privada através da utiliza¸cão de criptografia simétrica, o que torna a comunica¸cão mais rápida em compara¸cão a criptografia assimétrica. Mas para construir este cenário, é necessário que haja uma troca de chaves, que ocorre através de um protocolo HandShake.

O HandShake, traduzido como aperto de mãos, é o processo que permite ao cliente e ao servidor estabelecerem confian¸ca mútua entre as partes. O processo é baseado em no m´ınimo quatro etapas:

• No primeiro passo o cliente envia ao servidor uma mensagem ClientHello junto com o CipherSuite, uma lista de protocolos de criptografia aceitos pelo cliente; • O servidor envia para o cliente uma resposta contendo uma mensagem

Ser-verHello junto com o CipherSuite, baseado na lista de protocolos aceitos pelo cliente, al´em do certificado digital do servidor;

• O cliente verifica o certificado digital do servidor e baseado na lista de protocolos definido no CipherSuite, o cliente envia ao servidor uma sequência de bytes que permite o cálculo da chave secreta cifrados com a chave pública recebida pelo certificado do servidor;

• Por fim, o servidor decifra os bytes, gera a chave secreta e responde ao cliente uma mensagem de HandShake conclu´ıdo, cifrada com a chave secreta, sinalizando ao cliente que pode iniciar a comunica¸c˜ao.

Com este processo, a sessão segura é estabelecida e as mensagens possuem garantia de privacidade. Mas para a garantia da integridade é utilizado outro mecanismo

(35)

criptográfico, o Hash-based Message Authentication Code (HMAC), um hash para autentica¸cão de mensagens. O mecanismo consiste na aplica¸cão de uma fun¸cão hash sobre a mensagem a ser enviada para garantir a integridade da mensagem. O protocolo consiste numa sequência de dois passos:

• Aplica¸cão de um hash sobre uma fun¸cão XOR entre a chave secreta (K) e uma sequência de bytes 0x36 de tamanho idêntico a chave (ipad) junto com a mensagem a ser enviada: H(K ⊕ ipad, mensagem);

• Aplica¸cão de um segundo hash sobre uma fun¸cão XOR entre a chave sercreta (K) e uma sequência de bytes 0x5C de tamanho idêntico a chave (opad) junto com o hash anterior: H(k ⊕ opad, H(K ⊕ ipad, mensagem));

Desta forma, somente os conhecedores da chave secreta têm a capacidade de gerar novamente o hash que autentica a mensagem. O protocolo TLS é contru´ıdo sobre a camada de transporte, podendo servir a diversas aplica¸cões e protocolos, comoHTTP, File Transfer Protocol (FTP), Simple Mail Transfer Protocol (SMTP) e outros. Esta camada de segura¸ca é transparente para as aplica¸cões e pode ser utilizada por diversos protocolos.

(36)

(37)

FIDO2

3.1 Introdu¸

c˜

ao

A autentica¸cão é aplicada por diversos mecanismos nos sistemas, que acabam sendo um vetor de ataque muito explorado por hackers. O desafio é implementar um meio seguro e user frendly, ou seja, fácil de utilizar na óptica do usuário.

A usabilidade costuma ser o oposto de seguran¸ca no cenário da autentica¸cão, um meio fácil de ser utilizado acaba sendo inseguro na maioria das vezes. A complexidade acaba sendo o pre¸co a se pagar pela seguran¸ca, senhas extensas e com vários critérios garantem eficiência contra ataques de dicionários, de for¸ca bruta e outros. Mas isto acaba criando uma resistência do usuário para utilizar o sistema e seguir a normas de seguran¸ca previstas. O resultado geralmente é um post-it com a senha na mesa de trabalho.

O outro lado do desafio é manter o segredo da senha armazenada de forma segura no servidor. O uso de hashes para armazenar a senha, de salt para evitar um ataque por rainbow table, são mecanismos seguros e complexos mas que não suprimem a necessidade de armazenar o segredo da senha em uma base de dados.

O protocolo denominado FIDO (Fast IDentity Online, traduzido de forma literal como identidade rápida online) foi projetado pela FIDO Alliance e utiliza chaves assimétricas para autentica¸cão. A organiza¸cão surgiu depois que em 2009, as empresas

(38)

Validity Sensors e PayPal discutiram a necessidade de implementar um padr˜ao de autentica¸c˜ao sem o uso de senhas.

Em 2012 esse grupo de empresas aumentou, juntaram-se Lenovo, Nok Nok Labs, In-fineon e Agnitio para o in´ıcio da implementa¸c˜ao do protocolo passwordless (sem uso de senhas) anteriormente debatido. Em fevereiro de 2013 a organiza¸c˜ao foi publicamente estabelecida.

Atualmente a organiza¸cão conta com a participa¸cão das maiores empresas de tecno-logia (Google e Microsoft), redes sociais (Facebook, Twitter), operadores financeiros (Paypal e VISA) e órgãos governamentais (NIST). Foi desenvolvida a segunda versão do protocolo, FIDO2, que utiliza o padrão de autentica¸cão web (WebAuthn) doW3C

(World Wide Web Consortium) e especifica o protocolo de autentica¸c˜ao do cliente

CTAP (Client to Autheticator Protocol ).

O FIDO2 faz o uso do protocolo WebAuthn para utilizar chaves públicas na auten-tica¸cão. O servidor implementa a API WebAuthn que envia ao cliente os dados para as opera¸cões de registro e autentica¸cão. Através destas opera¸cões, o servidor recebe os dados para para armazenar uma chave pública de um usuário, quando ocorre um registro. Ou o servidor recebe os dados de uma assinatura para comparar com a chave pública previamente armazenada, quando ocorre uma autentica¸cão.

O FIDO2 também especifica o CTAP para comunica¸cão da plataforma do cliente com um autenticador f´ısico que cria as credenciais e armazena as chaves privadas. O CTAP define um padrão para as requisi¸cões e as respostas na comunica¸cão do autenticador com a plataforma. Parte das defini¸cões é o tipo de comunica¸cão f´ısica, que pode ser Universal Serial Bus (USB), Bluetooth ou Near Field Communication (NFC). O autenticador ainda pode ser virtual e estar conectado na plataforma, por exemplo, o Windows Hello. Um dispositivo virtual neste formato está conectado na plataforma, reconhecido como um autenticador e vai gerar uma resposta com os mesmos objetos previstos peloCTAP, sem a necessidade de haver transporte f´ısico entre o autenticador e a plataforma.

(39)

Entre o servidor e o autenticador, o navegador faz a interlocu¸cão dos protocolos, os dados recebidos do protocolo WebAuthn são interpretados e encaminhados para a plataforma do cliente para utiliza¸cão dos autenticadores compat´ıveis. É o navegador que mantém a sessão com o servidor no per´ıodo que o autenticador efetua as opera¸cões. Por fim, o navegador ainda encapsula os objetos para gerar a resposta enviada ao servidor WebAuthn.

Figura 3.1: Fluxo FIDO2 (WebAuthn + CTAP)

3.2 WebAuthn

O WebAuthn[18] especifica umaAPI web que permite a utiliza¸cão de chaves públicas para autentica¸cão e suporta autenticadoresFIDOem plataformas e navegadores com-pat´ıveis. Essa especifica¸cão foi conclu´ıda através da parceria entre o W3Ce a FIDO Alliance e estabelecida como um padrão de autentica¸cão da web W3C em mar¸co de 2019.

A API WebAuthn implementa principalmente dois processos que se comunicam diretamente com a API dispon´ıvel nos navegadores suportados. Os navegadores executam a comunica¸cão com os autenticadores e retornam a informa¸cão necessária para continuar com os processos. Os dois processos essenciais para um servi¸co online são o registro e a autentica¸cão.

3.2.1 Registro

O processo de registro cria uma credencial para posterior utiliza¸cão no processo de autentica¸cão. Para um servi¸co online (servidor ou Relying Party Server ) iniciar esse processo é necessário adequar o fluxo de acesso do usuário para que seja poss´ıvel incluir esse meio de autentica¸cão.

(40)

O primeiro passo é submeter um objeto PublicKeyCredentialCreationOptions para o navegador do cliente iniciar o processo de cria¸cão de um novo par de chaves através do método navigator.credentials.create(). Neste objeto estão as seguintes informa¸cões:

• challenge: buffer randômico para evitar ataques de repeti¸cão; • rp: informa¸cões do servidor/servi¸co;

• user: informa¸c˜oes do usu´ario;

• pubKeyCredParams: array de objetos com os tipos de chaves aceitas pelo servi-dor seguindo o formato CBORObject Signing and Encryption (COSE);

• authenticatorSelection: defini¸c˜ao de autenticadores pretendidos no processo. Permite ao servidor exigir um tipo de autenticador.

• timeout : tempo de espera em milissegundos para resposta;

• attestation: define o tipo de atesta¸cão pretendida pelo servidor. A atesta¸cão é uma assinatura do autenticador com a chave da autoridade de atestado, ins-talada no autenticador pelo fabricante. Os tipos podem ser: none, indicando que o servidor não analisa a atesta¸cão; indirect : indica que o servidor aceita atesta¸cão anônima; direct : indica que o servidor espera uma atesta¸cão publica-mente válida.

Após o envio destas informa¸cões ao cliente, o servidor mantém a sessão em espera de resposta pelo tempo definido em timeout. Nesse per´ıodo o autenticador gera um par de chaves e retorna através da plataforma do cliente as informa¸cões para concluir o registro no servidor.

A resposta deve conter um objeto AuthenticatorAttestationResponse, que cont´em a credencial gerada pelo autenticador. A credencial segue com alguns dados que servem para validar sua autenticidade:

• id: identificador da credencial gerado pelo autenticador, codificado em base64; • rawId: o mesmo identificador em formato bin´ario;

(41)

• response:clientDataJSON:informa¸cões trocadas entre o navegador e o autentica-dor: challenge: mesmo buffer aleatório enviado pelo servidor que serve para verifica¸cão. origin: endere¸co do servidor. type: deve conter a string ”we-bauthn.create”, caso contrário o autenticador efetuou uma opera¸cão incorreta. • response:attestationObject: contém a credencial de chave pública gerada e a

assinatura que valida a autenticidade: authData: dados do autenticador e a chave pública em formatoCOSE. fmt: formato da atesta¸cão. attStmt: atesta¸cão da credencial contendo a assinatura com a chave da autoridade de atestado.

Se os dados forem validados, a chave pública é armazenada no servidor para ser utilizada na autentica¸cão do usuário junto com os dados de valida¸cão da credencial (id e rawId).

Figura 3.2: Fluxo de Registro WebAuthn

3.2.2 Autentica¸

c˜

ao

O processo de autentica¸cão requer um processo de registro anterior, pois a chave pública registrada será utilizada para verifica¸cão da assinatura enviada na auten-tica¸cão. O fluxo de autentica¸cão baseado no WebAuthn pode ser adequado com o cenário do servi¸co online, podendo inclusive ser o único meio e fator de acesso.

O primeiro passo, após o servidor receber uma requisi¸cão de autentica¸cão de um usuário, é o envio de um objeto publicKeyCredentialRequestOptions para o navegador do cliente através do método navigator.credentials.get(). O objeto contém as seguintes informa¸cões:

(42)

• allowCredentials: uma lista com o identificador das credenciais aceitas, o tipo de credencial e o tipo de comunica¸c˜ao do autenticador;

• timeout : tempo de espera em milissegundos para resposta;

Com estas informa¸cões o autenticador consegue identificar a credencial solicitada através do endere¸co do servidor e do identificador da credencial. Se a credencial estiver presente no autenticador, será enviada a resposta contendo a assinatura da chave privada correspondente. A resposta para o servidor vai conter os dados a seguir:

• id: identificador da credencial gerado pelo autenticador durante o registro. • rawId: identificador em formato bin´ario.

• response:authenticatorData: dados do autenticador que s˜ao utilizados na assi-natura.

• response:clientDataJSON: contém informa¸cões da opera¸cão efetuada entre o navegador e autenticador: challenge: buffer randômico que valida a sessão; origin: endere¸co do servidor; type: deve conter a string ”webauthn.get”para validar o tipo da opera¸cão.

• response:signature: assinatura da chave privada da credencial, para ser validada pelo servidor com a chave p´ublica.

• response:userHandle: ´e um dado opcional que o autenticador pode utilizar para enviar o us´ario da credencial.

• type: deve conter a string ”public-key”para identificar o tipo da credencial.

(43)

3.3 CTAP

O Client to Authenticator Protocol (CTAP)[2] é o protocolo de comunica¸cão utilizado pelo autenticador durante os processos com o navegador que gere as credenciais e a intera¸cão com o usuário. O protocolo é baseado em três estruturas: AAPI de auten-tica¸cão, o mecanismo de codifica¸cão da mensagens e a conexão f´ısica do autenticador.

A conexão do autenticador e a codifica¸cão das mensagens são mecanismos dependen-tes do meio f´ısico. A codifica¸cão será efetuada de acordo com o meio de conexão, que pode ser USB, NFC ou Bluetooth. Cada meio de conexão possui suas peculiaridades e demandam de defini¸cões espec´ıficas para a comunica¸cão.

A API do autenticador prevê o desenvolvimento de dois principais métodos que serão a resposta para os processos de registro e autentica¸cão previstos no WebAuthn, MakeCredential e GetAssertion respectivamente. Além destes, existe defini¸cão de outros quatro métodos:

• GetNextAssertion: é um método complementar para casos em que a chamada do método GetAssertion retorna a informa¸cão numberOfCredentials com um valor maior que um. Neste caso o GetNextAssetion retorna a próxima credencial da lista de credenciais eleg´ıveis para o servidor em questão;

• GetInfo: para obter informa¸cões sobre o autenticador. Quando chamado, a resposta contém a lista de versões de protocolo com suporte, o AAGUID (iden-tificador do autenticador), os recursos e as capacidades do dispositivo;

• ClientPIN : para redefinir o PIN do autenticador ou criar um v´ınculo de confian¸ca com a plataforma;

• Reset : para redefinir as informa¸cões do autenticador. Quando acionado, todas as credenciais são exclu´ıdas e o autenticador redefine as configura¸cões pré-definidas em suas fabrica¸cão.

3.3.1 MakeCredential

Este método responde a requisi¸cão do servidor WebAuthn navigator.credentials.create(), tratada pelo navegador e encaminhada para o autenticador com os dados necessários.

(44)

Para a chamada deste método são necessários os seguintes parâmetros:

• clientDataHash: dados da opera¸cão com o navegador contendo principalmente o endere¸co do servidor e o challenge que será utilizado para gerar o attStmt (objeto de atesta¸cão).

• rp: identificador e endere¸co do servidor. • user : identificador e utilizador do usu´ario

• pubKeyCredParams: lista de tipos de credenciais aceitas pelo servidor em for-mato de array de objetosCBOR.

A resposta do método é o objeto AttestationObject que contém: um array de bytes com os dados da credencial denominado authData; uma string com o formato de atesta¸cão denominado fmt ; e um array de bytes contendo a atesta¸cão denominado attStmt. O processo de cria¸cão da credencial gera principalmente o objeto authData, que deve conter os dado a seguir:

• rpIdHash: hash SHA-256 do identificador do servidor (Relying Paty ID). • flags: um byte com defini¸c˜oes sobre a opera¸c˜ao: bit 0 aponta a presen¸ca do

usuário; bits 1, 3, 4 e 5 reservado para uso futuro; bit 2 aponta a verifica¸cão do usuário; bit 6 aponta a presen¸ca de dados da credencial; bit 7 aponta a presen¸ca de extensões.

• signCount : contador de autentica¸c˜oes que permite ao servidor verificar se o autenticador foi clonado. Na cria¸c˜ao da credencial, esse contado inicia em 0. • attestedCredentialData: objeto contendo o identificador do autenticador, o

iden-tificador da credencial e a chave p´ublica em formato COSE.

• extensions: dados opcionais que permitem adicionar funcionalidades ao processo, adequando-se a casos de uso espec´ıficos.

(45)

3.3.2 GetAssertion

Utilizado par autentica¸cões, este método responde a requisi¸cão navigator.credentials.get(). O navegador envia para o autenticador os dados a seguir:

• rpId : identificador do servidor.

• clientDataHash: dados da opera¸cão com o navegador contendo principalmente o endere¸co do servidor e o challenge que será utilizado para gerar o attStmt (objeto de atesta¸cão).

• allowList : informa¸c˜ao opcional com uma lista de identificadores de credenciais aceitas pelo servidor.

A resposta do autenticador deve conter principalmente dados que permitam ao servidor WebAuthn validar a identidade utilizando a chave pública previamente arma-zenada neste mesmo servidor pelo processo de registro do WebAuthn (MakeCredencial efetuado pelo CTAP). Os dados retornados contêm as informa¸cões a seguir:

• credential : descri¸c˜ao da credencial (opcional).

• authData: dados do autenticador similar ao objeto enviado na cria¸c˜ao da cre-dencial, mas sem a chave p´ublica.

• signature: assinatura dos objetos authData e clientDataHash utilizados pelo servidor para verifica¸c˜ao baseada na chave p´ublica.

• user : informa¸c˜oes do usu´ario (opcional).

(46)

3.4 Requisitos de Seguran¸

ca

Para implementa¸cão do protocolo FIDO, que compreende o servidor WebAuthn e o autenticadorFIDO, existem medidas a serem tomadas para que se alcancem as metas de seguran¸ca necessárias. Entre os objetivos do protocolo, são definidas dezesseis metas de seguran¸ca que devem ser seguidas pelo servidor WebAuthn e pelo autenticador

FIDO. Estas metas têm uma rela¸cão de vinte e nove medidas para serem alcan¸cadas de forma integral. As metas de seguran¸ca (MS) são:

• MS-1 Autentica¸c˜ao forte do usu´ario: uso de criptografia avan¸cada para reconhe-cer o interlocutor;

• MS-2 Resiliência de adivinha¸cão de credencial: prote¸cão robusta contra ataques de adivinha¸cão;

• MS-3 Resiliência de divulga¸cão de credenciais: resistência a ataques de phishing, mesmo quando o adversário tem a capacidade de manipular o tráfego de rede; • MS-4 Não vincula¸cão: prote¸cão da conversa para impedir a vincula¸cão de uma

comunica¸c˜ao a um usu´ario;

• MS-5 Resiliência a vazamentos do verificador: resistência a vazamentos de outras partes confiáveis;

• MS-6 Resiliência a vazamentos de autenticador: resistência a vazamentos de um autenticador, nada que um autenticador possa vazar pode ajudar um invasor a se passar por outro usuário;

• MS-7 Consentimento do usuário: exigência de um reconhecimento expl´ıcito sempre que ocorrer a rela¸cão com uma parte confiável;

• MS-8 Informa¸cão de identifica¸cão pessoal m´ınima: exposi¸cão m´ınima da identi-fica¸cão pessoal para as partes confiáveis;

• MS-9 Propriedades atestáveis: possibilidade de verifica¸cão do modelo/tipo do autenticador pela parte confiável;

• MS-10 Resistência Denial of Service (DoS): resiliência a ataques de nega¸cão de servi¸co, de forma a impedir inclusão de informa¸cões inválidas que neguem o acesso leg´ıtimo do usuário;

(47)

• MS-11 Resistência a falsifica¸cão: resiliência a ataques que invasores interceptam comunica¸cões para se passar por um usuário leg´ıtimo;

• MS-12 Resistência de sessão paralela: resiliência a ataques que manipulam mensagens de autentica¸cão;

• MS-13 Resistência a encaminhamento: resiliência a ataques de repeti¸cão de comunica¸cões interceptadas;

• MS-14 Não repúdio de transa¸cão: uso de criptografia para o não repúdio de transa¸cões seguras;

• MS-15 Respeito pelos limites de seguran¸ca operacional: prote¸cão do material criptográfico no ambiente operacional do dispositivo do usuário;

• MS-16 N´ıvel de seguran¸ca avaliável: uso de padrões transparentes para análise da seguran¸ca aplicada na implementa¸cão de autenticadores.

Cada medida de segura¸ca implementada possui uma ou mais metas atingidas ou parcialmente atingidas, de forma que todas as medidas implementadas alcan¸cam todas as metas estabelecidas. A única exce¸cão é a MS-16, que permeia o modelo de implementa¸cão de um autenticador. A lista de medidas a serem implementadas (MI) são:

• MI-1 Prote¸cão da chave: mecanismo de bloqueio da chave privada, exigindo a autoriza¸cão do usuário para utilizar a credencial;

• MI-2 Chaves de autentica¸cão exclusiva: um par de chaves novo é gerado para autentica¸cão em cada parte confiável e usuário distintos;

• MI-3 Atestado de classe do autenticador: utiliza¸cão de uma chave assinada por uma autoridade pública para reconhecer a procedência do autenticador. Geralmente a chave é a mesma para um modelo/tipo de autenticador;

• MI-4 Verifica¸cão de status do autenticador: os autenticadores devem informar o status para que as partes confiáveis possam acessar a informa¸cão se o dispositivo foi comprometido;

• MI-5 Consentimento do usuário: o cliente FIDOsolicita a permissão do usuário em toda a intera¸cão com uma parte confiável;

(48)

• MI-6 Base de dados do verificador criptograficamente segura: a parte confiável mantém somente a parte pública da credencial no seu cadastro;

• MI-7 Canal seguro de autentica¸cão de servidor: o protocolo TLS com auten-tica¸cão do servidor deve ser utilizado na comunica¸cão entre a parte confiável e o cliente. O Hypertext Transfer Protocol Secure (HTTPS) é imposto por um navegador ou aplica¸cão;

• MI-8 Protocolo Nonce: uso de números aleatórios nas opera¸cões para evitar ataques de repeti¸cão;

• MI-9 Certifica¸c˜ao de autenticador: mecanismo para notificar status de certi-fica¸c˜ao do autenticador;

• MI-10 Confirma¸cão de transa¸cão: exibi¸cão de dados da transa¸cão para o usuário; • MI-11 Integridade na comunica¸cão: o servidor utiliza o desafio enviado na

solicita¸c˜ao da opera¸c˜ao para verificar a integridade da mensagem;

• MI-12 Vincula¸c˜ao de canal: os servidores podem verificar a continuidade de um canal seguro com um aplicativo cliente;

• MI-13 Acesso protegido ao autenticador: o autenticador restringe o acesso às chaves, liberado mediante interven¸cão do usuário;

• MI-14 Defini¸c˜ao de identificador da parte confi´vel: o valor rpId restringe o acesso `

as chaves com este identificador, que ´e derivado automaticamente da origem da web;

• MI-15 Contador de assinaturas: toda credencial tem um contador armazenado no autenticador que remete e incrementa esse valor em toda a transa¸c˜ao. Este processo permite ao servidor a verifica¸c˜ao de uma poss´ıvel clonagem do autenti-cador/credencial;

• MI-16 Uso de protocolos criptogr´aficos modernos: uso de cifras e chaves adequa-das com os dispositivos que cumprem os n´ıveis de complexidade exigidos pela especifica¸c˜ao;

• MI-17 Resistˆencia a ataques de canal;

(49)

• MI-19 Probabilidade limitada de uma colisão de aniversário: uso de algoritmos complexos para gera¸cão de números aleatórios;

• MI-20 Autenticadores indistingu´ıveis: utiliza¸cão de chave de atesta¸cão idêntica para uma quantidade considerável de autenticadores;

• MI-21 Autentica¸cão e resistência a reprodu¸cão de informa¸cões protegidas arma-zenadas externamente;

• MI-22 Autenticadores testados e certificados FIDO;

• MI-23 Os identificadores das chaves s˜ao vinculados ao autenticador que produziu a credencial;

• MI-24 A fabrica¸c˜ao dos autenticadores certificados FIDO possuem suporte `a seguran¸ca do autenticador;

• MI-25 Um alto n´ıvel de certifica¸cão do autenticador pode suportar uma árvore de confian¸ca de todas a intera¸cões do autenticador;

• MI-26 Valida¸cão dos dados de entrada: os dados são validados pelo autenticador para evitar execu¸cão maliciosa dentro do ambiente seguro que possui as chaves privadas;

• MI-27 Prote¸cão dos dados de verifica¸cão do usuário: quando presentes, os dados biométricos ou PINs são armazenados de forma segura;

• MI-28 Resistˆencia a ataques de inje¸c˜ao de falha;

• MI-29 Resistência a ataques de cronometragem remota: não há vazamento de informa¸cões secretas a terceiros por meio da varia¸cão do tempo de execu¸cão da opera¸cão.

A tabela a seguir representa a rela¸cão entre as metas de seguran¸ca e as medidas com implementa¸cão necessária para serem alcan¸cadas:

(50)

Meta de Seguran¸ca Medidas Implementadas MS-1 Autentica¸c˜ao forte do usu´ario MI-1, MI-12, MI-14, MI-15,

MI-16, MI-17, MI-21, MI-23, MI-25, MI-29

MS-2 Resiliˆencia de adivinha¸c˜ao de credencial MI-1, MI-6, MI-16

MS-3 Resiliˆencia de divulga¸c˜ao de credenciais MI-1, MI-9, MI-15, MI-17, MI-29

MS-4 Não vincula¸cão MI-2, MI-3, MI-20 MS-5 Resiliência a vazamentos do verificador MI-2, MI-6, MI-16 MS-6 Resiliência a vazamentos de autenticador MI-9, MI-15, MI-16 MS-7 Consentimento do usuário MI-1, MI-5, MI-7, MI-10,

MI-25 MS-8 Informa¸cão de identifica¸cão pessoal m´ınima MI-2, MI-20 MS-9 Propriedades atestáveis MI-3, MI-4, MI-9 MS-10 Resistência DoS MI-8

MS-11 Resistência a falsifica¸cão MI-7, MI-8, MI-11, MI-12 MI-17, MI-23, MI-29 MS-12 Resistência de sessão paralela MI-7, MI-8, MI-11, MI-12 MS-13 Resistência a encaminhamento MI-7, MI-8, MI-11, MI-12 MS-14 Não repúdio de transa¸cão MI-1, MI-2, MI-8, MI-10

MI-11, MI-12, MI-25 MS-15 Respeito pelos limites de seguran¸ca operacional MI-13, MI-14

Tabela 3.1: Rela¸c˜ao de Metas de Seguran¸ca X Medidas Implementadas

3.5 Estado da Arte

A solu¸cão mais atual para implementar um método de autentica¸cão forte é o uso de chaves móveis, que são válidas na infraestrutura de chaves públicas e autenticadas por ela. É um método eficaz e seguro se for aplicado da maneira correta, mas implica custo para cada chave gerada. Levando em considera¸cão que uma chave não deve ser utilizada em mais de uma conta, para cada conta o usuário precisa gerar uma nova chave e pagar pela valida¸cão pública da mesma.

(51)

A proposta do protocolo FIDO2 é criar um mecanismo de autentica¸cão forte que atende as duas principais necessidades de um modelo de autentica¸cão. A senha é complexa e não está dispon´ıvel para observadores externos e ao mesmo tempo é fácil para o usuário inser´ı-la a qualquer momento. O modelo também é baseado em chaves públicas, mas o protocolo prevê a cria¸cão de chaves protegidas por um dispositivo f´ısico ou virtual e somente uma chave válida publicamente, que serve de atesta¸cão para as credenciais criadas.

Atualmente o protocolo FIDO2 possui implanta¸cões comerciais em 22 organiza¸cões, entre elas estão as empresas Google, Facebook e Github. Já existem ao menos 90 implementa¸cões de autenticadores por diversos fabricantes, entre eles as empresas Yubico e Solokeys. A alian¸ca oferece três programas de certifica¸cão[3]: teste de inte-roperabilidade funcional (para servidores, clientes e autenticadores), teste de n´ıvel de autenticador certificado (que analisa o grau de seguran¸ca oferecido por autenticadores) e teste de certifica¸cão de componente biométrico (para autenticadores aplicáveis).

Neste cenário, o acréscimo da interoperabilidade do protocolo FIDOpara a solu¸cão de autentica¸cão da empresa Loqr SA agrega seguran¸ca e visibilidade. A compatibi-lidade do servidor pode permitir ao usuário a utiliza¸cão de um autenticadorFIDO e para a aplica¸cão é a garantia de seguran¸ca e agilidade na comunica¸cão com o servidor.

(52)

(53)

An´

alise de Requisitos

4.1 Introdu¸

c˜

ao

Neste cap´ıtulo é apresentada a lista de requisitos da solu¸cão desenvolvida para ser interoperável com o padrão FIDO. Os requisitos são divididos de acordo com o cenário da solu¸cão, que compreende um servidor WebAuthn e um cliente que autentica seguindo o protocolo. Os casos de uso do servidor são conectados aos casos de uso do cliente autenticador, ou seja, os pedidos enviados ao servidor retornam informa¸cões que são a entrada de dados para os casos de uso do autenticador, mas serão analisados separadamente.

A solu¸cão de autentica¸cão implementada pela empresa Loqr SA, no in´ıcio deste trabalho, utiliza um protocolo próprio para fazer a vincula¸cão e autentica¸cão de usuários no servidor. A sessão a seguir explica o funcionamento da solu¸cão e como o padrão FIDOserá inclu´ıdo como uma op¸cão a ser utilizada pela empresa.

4.2 Solu¸

c˜

ao Loqr SA

A solu¸cão da empresa Loqr SA, a ser adequada para ter interoperabilidade com o padrãoFIDO, tem como fun¸cão aplicar autentica¸cão forte aos usuários de um servi¸co antes de permitir o acesso. A solu¸cão se comunica com o usuário através de uma aplica¸cão para dispositivos móveis, permitindo a cria¸cão de um v´ınculo do dispositivo com a identidade deste usuário. Para autentica¸cão é utilizado este v´ınculo previamente

(54)

efetuado.

O diagrama a seguir apresenta os estados do processo de emparelhamento, que vincula a aplica¸c˜ao de dispositivo ao registro do usu´ario:

• Autenticar no portal: o usuário autenticado na página web do servi¸co, utilizando um navegador, inicia a autentica¸cão;

• Apresentar página de gestão da conta pessoal: o sistema exibe a página onde, entre outras fun¸cões, permite a gestão de credenciais;

• Escolher emparelhar dispositivo: o usu´ario escolhe emparelhar dispositivo para iniciar o processo;

• Mostrar QR Code: o servidor exibe um QR Code para que a aplica¸c˜ao obtenha os dados contidos nele;

• Ler QR Code: a aplica¸cão obtém informa¸cões necessárias para o emparelhamento através do QR Code, que contém os dados de acesso a autentica¸cão ao servidor e solicita ao usuário permissão para criar o v´ınculo;

• Conceder autoriza¸cão: o usuário permite o emparelhamento através da aplica¸cão;

• Enviar informa¸cão ao sistema: tendo por base os dados contidos no QR Code, a aplica¸cão gera um conjunto de informa¸cões un´ıvocas, que associa o usuário ao dispositivo utilizando um par de chave assimétricas e envia para o sistema;

• Emparelhar dispositivo com a conta do usuário: o servidor armazena os dados de identifica¸cão do dispositivo, vinculando-o ao o usuário;

• Mostrar mensagem: por fim, o usu´ario recebe uma mensagem de sucesso no emparelhamento.

(55)

Figura 4.1: Emparelhamento Sistema Loqr SA

O processo de autentica¸cão segue um fluxo similar, mas desta vez já existe um v´ınculo de seguran¸ca entre o servidor e a aplica¸cão no dispositivo do usuário. Neste caso o servidor é que notifica a aplica¸cão sobre o processo de autentica¸cão que está ocorrendo através de uma mensagem push notification. Após a primeira autentica¸cão através da aplica¸cão, se o servi¸co ao qual o usuário pretende aceder está configurado para aceitar Single Sign-On (SSO), serão utilizados os mesmos dados da sessão exis-tente no navegador, evitando a necessidade de nova autentica¸cão forte pelo usuário. A figura a seguir representa o digrama de estados do processo:

• Aceder ao portal: o usuário acessa a aplica¸cão de acesso ao sistema Loqr; • Fazer pedido da página: o usuário acessa a página web de autentica¸cão no

navegador;

• Verificar se o usuário está autenticado: o sistema verifica se o usuário possui alguma sessão válida na aplica¸cão e encaminha para o processo se não houver; • Redirecionar para o servi¸co de autentica¸cão: o servidor verifica se há uma sessão

v´alida no navegador para seguir atrav´es de SSO se o servi¸co permitir;

• Apresentar página de autentica¸cão: o navegador exibe a página de autentica¸cão; • Inserir nome de utilizador: o usuário insere o nome de utilizador na página

exibida no navegador;

• Enviar push notification: o servidor enviar uma notifica¸cão para a aplica¸cão no dispositivo do usuário;

(56)

• Contirmar autentica¸cão: na aplica¸cão o usuário confirma a autentica¸cão em curso, dependendo do n´ıvel requerido para o servi¸co, pode ser através de PIN, fingerprint, reconhecimento facial ou simples botão;

• Validar autentica¸cão: o servidor valida a autentica¸cão feita na aplica¸cão; • Carregar dados: o servidor carrega os dados do usuário autenticado; • Apresentar página: o navegador carrega a sessão do usuário autenticado.

Figura 4.2: Autentica¸c˜ao Sistema Loqr SA

4.3 Arquitetura

Para definir as funcionalidades necessárias para o cliente e o servidor, é necessário analisar a arquitetura da solu¸cão e os casos de uso a serem implementados. O sistema adaptado ao protocolo FIDO envolve três componentes: o servidor WebAuthn, o navegador e o autenticador do cliente, neste caso a aplica¸cão a ser desenvolvida. Cada um dos componentes possui suas fun¸cões espec´ıficas e no caso do navegador, ´

e desenvolvido por terceiros e deve ser compat´ıvel com o protocolo.

Levando em conta a estrutura do sistema, h´a trˆes modelos de arquitetura de funci-onamento:

(57)

• O servidor WebAuthn Loqr SA registra e autentica as credenciais FIDO da aplica¸c˜ao Loqr SA;

• O servidor WebAuthn Loqr SA registra e autentica as credenciais de autentica-dores FIDO de terceiros;

• A aplica¸c˜ao Loqr SA registra e autentica as credenciais FIDO em servidores WebAuthn de terceiros;

4.3.1 Servidor Loqr SA e Aplica¸

c˜

ao Loqr SA

Para atender ao caso de uso onde servidor e cliente são conhecidos e pré-definidos é necessário a implementa¸cão da API WebAuthn no servidor para permitir a utiliza¸cão das credenciais FIDO. Na aplica¸cão é necessário o acréscimo de um componente que crie as credenciais FIDOe efetue registro e autentica¸cão no servidor.

Neste caso de uso o servidor da empresa Loqr SA, através da API WebAuthn, se comunica diretamente com a aplica¸cão da empresa Loqr SA e permite o uso de credenciais FIDO. Com esta implementa¸cão a solu¸cão de autentica¸cão da empresa Loqr SA ganha uma op¸cão de emparelhamento para o dispositivo do usuário com o servidor. A figura 4.3 representa o diagrama de componentes deste caso de uso.

Figura 4.3: Servidor Loqr SA e Aplica¸c˜ao Loqr SA

4.3.2 Servidor Loqr SA e Autenticadores de Terceiros

Para o cen´ario em que o servidor da empresa Loqr SA se comunica com autenticadores

FIDO de terceiros, basta que o servidor implemente a API WebAuthn. Neste caso a comunica¸cão vai ser intermediada com o navegador do cliente, que mantém a sessão das opera¸cões e envia ao autenticador FIDOos dados necessários para gerar as credenciais e assinaturas seguindo o protocolo WebAuthn.