Para definir as funcionalidades necess´arias para o cliente e o servidor, ´e necess´ario analisar a arquitetura da solu¸c˜ao e os casos de uso a serem implementados. O sistema adaptado ao protocolo FIDO envolve trˆes componentes: o servidor WebAuthn, o navegador e o autenticador do cliente, neste caso a aplica¸c˜ao a ser desenvolvida. Cada um dos componentes possui suas fun¸c˜oes 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:
• 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˜ao conhecidos e pr´e-definidos ´e necess´ario a implementa¸c˜ao da API WebAuthn no servidor para permitir a utiliza¸c˜ao das credenciais FIDO. Na aplica¸c˜ao ´e necess´ario o acr´escimo de um componente que crie as credenciais FIDOe efetue registro e autentica¸c˜ao no servidor.
Neste caso de uso o servidor da empresa Loqr SA, atrav´es da API WebAuthn, se comunica diretamente com a aplica¸c˜ao da empresa Loqr SA e permite o uso de credenciais FIDO. Com esta implementa¸c˜ao a solu¸c˜ao de autentica¸c˜ao da empresa Loqr SA ganha uma op¸c˜ao de emparelhamento para o dispositivo do usu´ario 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˜ao vai ser intermediada com o navegador do cliente, que mant´em a sess˜ao das opera¸c˜oes e envia ao autenticador FIDOos dados necess´arios para gerar as credenciais e assinaturas seguindo o protocolo WebAuthn.
Este caso de uso ocorre quando o servidor da empresa Loqr SA se comunica com uma solu¸c˜ao de autentica¸c˜ao FIDO de terceiros. A API WebAuthn ´e o componente que garante a compatibilidade com o cliente, independente da estrutura que o autenticador apresente. Na figura4.4´e representado o caso em que o servidor da empresa Loqr SA se comunica com um navegador do cliente e este com um autenticadorFIDO.
Figura 4.4: Servidor Loqr SA e Autenticadores de Terceiros
4.3.3
Aplica¸c˜ao Loqr SA e Servidores de Terceiros
Para a aplica¸c˜ao da empresa Loqr SA se comunicar com outros servidores ´e necess´ario que seja reconhecida pelo sistema operacional como um autenticador e consequente- mente tornar-se uma op¸c˜ao de autenticador para o navegador. Esta implementa¸c˜ao demanda a emula¸c˜ao de um dispositivo virtual que se conecta ao sistema operacional e utiliza a aplica¸c˜ao como o autenticador.
Neste caso de uso o desafio ´e implementar uma interface CTAP entre o sistema operacional do cliente e o m´odulo autenticador compat´ıvel com as credenciais FIDO
da aplica¸c˜ao da empresa Loqr SA a ser desenvolvido. A figura 4.5 representa os componentes envolvidos no caso de uso, onde o componente destacado deve fazer a interface com o m´odulo do autenticador FIDO da aplica¸c˜ao da empresa Loqr SA previsto no caso de uso 4.3.1.
4.3.4
Adapta¸c˜ao ao FIDO
A solu¸c˜ao da empresa Loqr SA implementa um protocolo pr´oprio que executa auten- tica¸c˜ao forte, similar a fun¸c˜ao do protocoloFIDO. Mas o fluxo dos dados que garantem a autentica¸c˜ao no sistema da empresa Loqr SA e no protocolo FIDOs˜ao distintos. A comunica¸c˜ao da aplica¸cao com o servidor utiliza endere¸cos fixos e a comunica¸c˜ao do servidor com a aplica¸c˜ao utiliza padr˜oes de push notification.
O FIDO n˜ao utiliza recursos baseados em notifica¸c˜ao, utiliza a infraestrutura de chaves p´ublicas para verificar o identidade do autenticador e chaves p´ublicas para validar as autentica¸c˜oes. Por estas distin¸c˜oes, a implementa¸c˜ao que faz sentido para a solu¸c˜ao se tornar compat´ıvel com FIDO´e o acr´escimo daAPI WebAuthn no servidor e a implenta¸c˜ao de um componente que permita o usu´ario da aplica¸c˜ao utilizar esta
API para registrar-se e autenticar-se.
Para o servidor ´e necess´ario o acr´escimo de uma op¸c˜ao para o usu´ario efetuar o registro de uma credencial FIDO. O registro deve ser permitido somente para um usu´ario autenticado, assim como no registro do protocolo Loqr, e utilizar os dados existentes dos usu´arios, acrescendo as credenciaisFIDO`a base de dados que armazena as informa¸c˜oes dos usu´arios. A aplica¸c˜ao necessita de um m´odulo, que pode ser utilizado como um autenticadorFIDOe se conecta com o servidor da Loqr, utilizando a API WebAuthn e se conecta ao sistema operacional do cliente por uma interface
CTAP. Os componentes necess´arios s˜ao trˆes:
• 1) API WebAuthn no servidor da empresa Loqr SA;
• 2) M´odulo de autentica¸c˜ao FIDOna aplica¸c˜ao da empresa Loqr SA;
• 3) Interface CTAP na aplica¸c˜ao da empresa Loqr SA para se comunicar com o sistema operacional do cliente.
A figura 4.6 representa um diagrama da solu¸c˜ao pretendida com os respectivos componentes a serem desenvolvidos em destaque.
Figura 4.6: Adapta¸c˜ao do Sistema Loqr
4.4
Requisitos de Seguran¸ca
Baseado nas metas de seguran¸ca definidas pelo protocoloFIDO(se¸c˜ao3.4), a solu¸c˜ao prevˆe a implementa¸c˜ao de medidas de seguran¸ca atrav´es dos seguintes mecanismos:
• MI-1 Prote¸c˜ao da chave: somente com a confirma¸c˜ao do usu´ario pode ocorrer alguma opera¸c˜ao com chaves;
• MI-2 Chaves de autentica¸c˜ao exclusiva: gera¸c˜ao de pares de chaves distintos para cada conta;
• MI-5 Consentimento do usu´ario: solicita¸c˜ao de confirma¸c˜ao do usu´ario para efetuar opera¸c˜oes com as credenciais;
• MI-7 Canal seguro de autentica¸c˜ao de servidor: utiliza¸c˜ao de HTTPS na comu- nica¸c˜ao;
• MI-8 Protocolo Nonce: cria¸c˜ao de desafios no servidor atrav´es de bibliotecas para gera¸c˜ao de n´umeros aleat´orios;
• MI-10 Confirma¸c˜ao de transa¸c˜ao: confirma¸c˜ao das opera¸c˜oes na interface do usu´ario;
• MI-11 Integridade na comunica¸c˜ao: o servidor utiliza dados cifrados para con- firmar a integridade das mensagens;
• MI-14 Defini¸c˜ao de identificador da parte confi´vel: os dados do servidor em cada opera¸c˜ao incluem um identificador;
• MI-15 Contador de assinaturas: um atributo das credenciais no formato de n´umero inteiro e denominado counter ;
• MI-16 Uso de protocolos criptogr´aficos modernos: utiliza¸c˜ao de protocolos reco- mendados peloFIDO;
• MI-26 Valida¸c˜ao dos dados de entrada: o autenticador e o servidor validam os dados de entrada antes de executar qualquer opera¸c˜ao.
Entre as medidas de seguran¸ca que n˜ao s˜ao previstas, mas que s˜ao definidas pelo protocolo, est˜ao a¸c˜oes que envolvem o cen´ario da solu¸c˜ao atual da empresa Loqr SA: A certifica¸c˜ao do autenticador e a inclus˜ao de dados do estado do dispositivo dependem da estrat´egia posterior a implanta¸c˜ao do protocolo em produ¸c˜ao na solu¸c˜ao da empresa Loqr SA; O uso das bases de dados no servidor e na aplica¸c˜ao da empresa Loqr SA que j´a possuem mecanismos seguros para armazenamento de dados sens´ıveis; A estrat´egia para garantir anonimidade do usu´ario deve ser definida de acordo com o planejamento da utiliza¸c˜ao do protocolo na solu¸c˜ao da empresa Loqr SA.