Container Servidor em Execu¸c˜ ao

Ap´os a execu¸c˜ao do comando que inicia o container utilizando a imagem do projeto WebAuthn, o servidor passa a responder na porta 9005 doTCP. Ao acessar o endere¸co local atrav´es de um navegador compat´ıvel, ´e poss´ıvel visualizar a p´agina ilustrada na figura 6.1.

Figura 6.1: P´agina HTML do Servidor

O servidor representa a API WebAuthn a ser integrada ao servidor da empresa Loqr SA, permitindo a intera¸c˜ao com os autenticadores FIDO de terceiros (caso de uso4.3.2) e com o m´odulo autenticadorFIDOintegrado na aplica¸c˜ao da empresa Loqr SA (caso de uso4.3.1).

O cliente autenticador ´e compilado atrav´es doIDENetBeans que permite a cria¸c˜ao do aplicativo Java. O aplicativo em formato JAR executa o c´odigo implementado de forma independente e se comunica diretamente com o container. Desta forma, o aplicativo utiliza o endere¸co http://localhost:9005 para o servidor WebAuthn.

Este aplicativo Java representa o m´odulo autenticador FIDO a ser integrado na aplica¸c˜ao da empresa Loqr SA que vai fazer a comunica¸c˜ao com o servidor da empresa Loqr SA e gerir as credenciais FIDO para autentica¸c˜ao. A sess˜ao 5.2.2 aborda a implementa¸c˜ao do Token FIDO, a parte da solu¸c˜ao que especificamente gerencia as credenciais e que n˜ao possui a interface CTAP, imposs´ıvel de ter sido implementada neste trabalho. Por essa raz˜ao, o caso de uso4.3.3n˜ao possui a solu¸c˜ao completa para testes.

Al´em do autenticador implementado neste trabalho, s˜ao utilizados o Windows Hello embebido no Windows 10 pela Microsoft e o autenticador Solo USB-A do fabricante Solo Keys. S˜ao dispositivos compat´ıveis com o padr˜ao FIDO que permitem a com- para¸c˜ao dos resultados e das chaves armazenadas pelos diferentes autenticadores. Todo o ambiente da plataforma Docker, do navegador e da aplica¸c˜ao Java s˜ao executados sobre o sistema Windows 10 em sua vers˜ao 2004, que possui compatibilidade no Windows Hello e a vers˜ao 85 do Microsoft Edge, baseada em Chromium e compat´ıvel com o protocolo FIDO.

Estes autenticadores s˜ao exemplos de autenticadoresFIDOde terceiros, que devem interagir com o servidor da empresa Loqr SA e exemplificam o caso de uso4.3.2. Este teste exibe o funcionamento da API WebAuthn do servidor da empresa Loqr SA se comunicando atrav´es do protocolo FIDO com os autenticadores externos e com os navegadores compat´ıveis.

6.2

Processo de Registro

O processo de registro, que armazena a chave gerada pelo autenticador, ´e efetuado de forma diferente com os autenticadores comerciais utilizados para compara¸c˜ao, pois necessitam do navegador para acesso `a p´agina HTML do servidor. O processo utilizando estes autenticadores inicia da mesma forma:

• Primeiro acessa-se a p´agina do servidor pelo navegador; • Em seguida insere-se o usu´ario a ser registrado;

A partir deste passo o processo ´e diferente entre os autenticadores. O Windows Hello ´e o conceito da Microsoft baseado no acesso do usu´ario ao sistema operaciona Windows e vai utilizar o meio registrado como padr˜ao para solicitar a confirma¸c˜ao do usu´ario (PIN, biometria, etc). A figura6.2 ilustra a notifica¸c˜ao solicitando o PIN para gera¸c˜ao da nova credencial.

Figura 6.2: Solicita¸c˜ao de Registro Windows Hello

Para utilizar o hardware da Solo Keys ´e necess´ario cancelar a solicita¸c˜ao recebida no Windows Hello para utilizar as outras formas de autentica¸c˜ao vinculadas no sistema operacional e reconhecidas pelo navegador. Ap´os o cancelamento da solicita¸c˜ao do PIN (Windows Hello) ´e poss´ıvel permitir a utiliza¸c˜ao do hardware j´a instalado no sistema operacional. A figura 6.3 representa a sequˆencia exibida pelo sistema solicitando a interven¸c˜ao do usu´ario no hardware do autenticador Solo USB-A.

Figura 6.3: Solicita¸c˜ao de Registro Solo Key

Enquanto o sistema tˆem o hardware instalado o LED se mant´em acesso na cor verde, apontado um estado de pronto para uso. Ap´os a confirma¸c˜ao do usu´ario permitindo a utiliza¸c˜ao do hardware exibido na figura anterior, o LED no hardware muda para a cor vermelha, se mantendo aceso e apontado o estado de aguardando interven¸c˜ao do usu´ario. Se o bot˜ao do hardware for pressionado a nova credencial ´e gerada. A figura

6.4 ilustra a aparˆencia do hardware no estado pronto e posteriormente aguardando intercen¸c˜ao do usu´ario.

Figura 6.4: Hardware Solo Key

Se o processo for confirmado pelo autenticador do Windows Hello e/ou Solo USB- A o resultado ser´a a exibi¸c˜ao de uma mensagem que ´e poss´ıvel efetuar ”Login”com a credencial gerada. ´E a confirma¸c˜ao do processo que registra a chave p´ublica no servidor e armazena a chave privada no autenticador. A figura 6.5 representa o resultado do procedimento na p´agina HTML do servidor.

Figura 6.5: Informa¸c˜ao de Registro na P´agina HTML do Servidor

O autenticador desenvolvido neste trabalho se comunica diretamente com o servidor e manipula os dados das requisi¸c˜oes, fun¸c˜ao exercida pelo navegador nos autenticadores anteriores. Para iniciar o processo de registro ´e necess´ario executar a aplica¸c˜ao Java que abre a interface principal, onde se define a fun¸c˜ao a ser executada, neste caso ”Registrar”. Na janela de registro ocorrem duas etapas para concretiza¸c˜ao da opera¸c˜ao:

• Primeiro o usu´ario inclui o nome e pressiona o bot˜ao ”Registrar”para receber na interface os dados para gerar a credencial. Este processo equivale a opera¸c˜ao efetuada na p´agina HTMLcom o bot˜ao ”Register”;

• Em seguida, com os dados de gera¸c˜ao da credencial e de sess˜ao da opera¸c˜ao exibidos na interface, o usu´ario pressiona o bot˜ao ”Criar Credencial”para con- firmar a opera¸c˜ao. Esta etapa equivale a confirma¸c˜ao do usu´ario atrav´es do

Windows Hello ou pelo hardware dos autenticadores f´ısicos. Ao final, a interface do autenticador exibe uma mensagem com o ID da chave gerada.

Figura 6.6: Fluxo de Registro Autenticador

6.3

Processo de Autentica¸c˜ao

O processo de autentica¸c˜ao mant´em a diferen¸ca entre os autenticadores utilizados na compara¸c˜ao e o autenticador desenvolvido neste trabalho. O processo nos autentica- dores utilizados inicia pelo navegador e como esperado depende de um registro pr´evio. Ap´os o registro a autentica¸c˜ao inicia com trˆes etapas:

• Acesso `a pagina HTML do servidor atrav´es do navegador; • Inser¸c˜ao do usu´ario a ser autenticado;

• Clique no bot˜ao ”Login”.

Estas etapas obtˆem os dados das credenciais registradas e dispon´ıveis para a auten- tica¸c˜ao, o que encaminha o pedido para os autenticadores instalados no sistema opera- cional. Neste momento os autenticadores avaliam as credenciais listadas pelo servidor para definir se possuem uma credencial v´alida armazenada para a autentica¸c˜ao.

Se houver credencial v´alida, o autenticador ´e exibido como op¸c˜ao para a autentica¸c˜ao e o usu´ario deve confirmar usando o processo adequado com o tipo do autenticador. Neste teste, ambos autenticadores (Windows Hello e Solo USB-A) possuem credenciais v´alidas para o processo de autentica¸c˜ao e s˜ao exibidos para que o usu´ario escolha

qual utilizar para a autentica¸c˜ao. A figura 6.7 representa o processo de sele¸c˜ao do autenticador.

Figura 6.7: Sele¸c˜ao do Dispositivo para Autentica¸c˜ao

Para utilizar o Windows Hello, basta incluir o PIN para que o autenticador virtual submeta os dados para autentica¸c˜ao ao navegador que encaminha ao servidor. Se a op¸c˜ao for utilizar o autenticador f´ısico, ´e preciso escolher a op¸c˜ao ”Chave de Segu- ran¸ca”durante a sele¸c˜ao do autenticador, o que vai iniciar o processo no hardware do autenticador. O LED ´e alterado para a cor vermelha, que aponta a necessidade de interven¸c˜ao do usu´ario, e se ocorrer a confirma¸c˜ao atrav´es do bot˜ao do hardware, o autenticador envia os dados de autentica¸c˜ao para o navegador, que encaminha ao servidor.

Ap´os o processo de autentica¸c˜ao utilizando os dois autenticadores comerciais dentro do navegador, o usu´ario ´e encaminhado para uma tela que visualiza as credenciais cadastradas para o usu´ario. S˜ao exibidos o RawID (identificador da credencial) e a chave p´ublica armazenada de todas as credenciais registradas para o usu´ario em quest˜ao. Neste teste ´e pos´ıvel identificar as trˆes credencias que foram registras para o usu´ario ”user”, utilizado para as opera¸c˜oes de registro. A figura6.8apresenta a tabela exposta no servidor com os dados das credenciais.

Figura 6.8: P´agina com as Credencias Registradas

O autenticador desenvolvido neste trabalho n˜ao utiliza o navegador para a comu- nica¸c˜ao, por isso o procedimento de autentica¸c˜ao tamb´em ´e efetuado diretamente na interface da aplica¸c˜ao Java. Atrav´es da interface principal da aplica¸c˜ao ´e necess´ario pressionar o bot˜ao ”Autenticar”para acessar a interface que efetua o processo de autentica¸c˜ao. Na janela do processo ocorrem duas etapas em sequˆencia:

• Primeiro o usu´ario insere o nome e pressiona o bot˜ao ”Autenticar”para receber os dados para definir a credencial de autentica¸c˜ao. Esta etapa equivale `a a¸c˜ao do bot˜ao ”Login”da p´agina HTML;

• A segunda etapa ocorre ap´os o recebimento dos dados de sess˜ao e a lista de credenciais que s˜ao exibidas na interface. Com estes dados o usu´ario deve acionar o bot˜ao ”Gerar Assinatura”para enviar os dados de autentica¸c˜ao ao servidor. Este processo equivale `a confirma¸c˜ao no autenticador e o envio dos dados ao servidor. Por fim, o autenticador exibe uma mensagem da autentica¸c˜ao efetuada e o ID da credencial utilizada.

Figura 6.9: Fluxo de Autentica¸c˜ao Autenticador

Ap´os da execu¸c˜ao da autentica¸c˜ao utilizando qualquer um dos autenticadores o ser- vidor gera uma mensagem de log informando o procedimento realizando e o usu´ario que efetuou. Desta forma, ´e poss´ıvel visualizar no terminal que mant´em a sess˜ao do container a informa¸c˜ao exposta no bloco de c´odigo 6.7.

1 level=info msg="Finishing authentication with user: user\n"