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

A.1 Item de Dados CBOR

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

Conclus˜ao

7.1 Resumo da Soluc˜ao

Neste cap´ıtulo é feita uma s´ıntese do trabalho desenvolvido, expondo os objetivos alcan¸cados e os trabalhos que podem ser desenvolvidos na sequência. O cenário de adapta¸cão de uma solu¸cão de autentica¸cão interoperável com o protocoloFIDOimpôs dois pilares para a implementa¸cão do trabalho. O primeiro é a solu¸cão e a maneira de aplicar o protocolo nos poss´ıveis casos de uso de maneira que mantenha a usabilidade para o cliente e agrege a seguran¸ca proposta pelo protocolo. O segundo é o protocolo, que prevê a especifica¸cão de um servidor que utiliza chaves públicas para autentica¸cão e um cliente que cria e gere as credenciais, sendo dois componentes independentes que criam um v´ınculo de confian¸ca mútua.

Durante a análise de requisitos é poss´ıvel clarificar onde o protocolo pode ser aplicado e em quais casos de uso vai agregar seguran¸ca e compatibilidade com o padrão pretendido. Com base nestas informa¸cões o trabalho gera um resultado que atende casos de uso espec´ıficos e cria uma base para expansão do procolo em outros casos de uso que fa¸cam sentido para a empresa e seus clientes.

7.2 Objetivos Conclu´ıdos

Entre os três casos de uso levantados para aplica¸cão do protocolo FIDO na solu¸cão de autentica¸cão da empresa Loqr SA, foram atendidos dois. Levando em conta as

caracter´ısticas do produto, são os casos de uso mais relevantes para o negócio, pois permitem que o servidor receba autenticadores externos compat´ıveis com o protocolo e qualificam, através do protocolo, a comunica¸cão entre o servidor de autentica¸cão e a aplica¸cão da empresa Loqr SA.

Os padrões definidos pelo protocolo são completamente atendidos no servidor, com a API WebAuthn as fun¸cões propostas são implementadas e compat´ıveis. Desta forma, o servidor pode interagir com os autenticadores que implementam o protocolo e permite ao usuário utilizar dispositivos que já utiliza em outras plataformas. Estes dispositivos estão se tornando cada vez mais comuns e utilizados, levando em conta que os principais desenvolvedores estão adotando o padrãoFIDO como uma op¸cão de autentica¸cão em seus sistemas.

A aplica¸cão desenvolvida têm compatibilidade com o protocolo, que atende ao caso de uso que envolve a aplica¸cão da empresa Loqr SA e o servidor da empresa Loqr SA. Os padrões do protocolo são atendidos, uma vez que as credenciais são criadas e geridas de acordo com as defini¸cões. O fluxo dos processos de registro e autentica¸cão proposto pelo protocoloFIDOé atendido pela aplica¸cão, limitada a se comunicar com o servidor pré-definido da organiza¸cão.

7.3 Trabalhos Futuros

A limita¸cão de comunica¸cão da aplica¸cão desenvolvida com o servidor da organiza¸cão é reflexo da impossibilidade de implementa¸cão da interfaceCTAPcom o sistema operacional. Num cenário com este componente operacional a aplica¸cão faria a comunica¸cão indireta com o servidor, sendo intermediada por um navegador compat´ıvel. Mas para que isso seja poss´ıvel é necessário que a aplica¸cão seja reconhecida pelo navegador como um autenticador FIDO e estar conectada com o sistema operacional através do componente com a interfaceCTAP.

Desta limita¸cão surge um trabalho futuro em potencial que pode utilizar a estrutura desenvolvida na aplica¸cão. Para que a biblioteca criptográfica possa ser utilizada por um futuro projeto, a estrutura já segue o padrão de comunica¸cão em hardware

CTAP definido pelo FIDO. O componente necessário para tornar a aplica¸cão um autenticador operacional com outros servidores é um emulador do hardware de um

autenticador com um drive de hardware que seja reconhecido pelo sistema operacional como um dispositivo FIDO. Através deste canal, a solu¸cão pode utilizar a biblioteca criptográfica para criar e gerenciar as chaves e credenciais de acordo com o padrão

CTAP e expandir o uso do autenticador tornando a aplica¸c˜ao um autenticador FIDO

virtual.

7.4 Considera¸c˜oes Finais

Este trabalho, desde sua proposta, me interessou pela área de aplica¸cão e pelo para- digma que sempre desafiou os arquitetos e desenvolvedores dos meios de autentica¸cão. O protocoloFIDOé de interesse direto de empresas como Google, Microsoft, Facebook e outras gigantes da área de tecnologia, além de ser um potencial ”método de autentica¸cão do futuro”. A atualidade do protocolo e a relevância da área (autentica¸cão) para a seguran¸ca da informa¸cão me instigaram a buscar conhecimento sobre como implementar o padrão no servidor e no cliente e o resultado me satisfaz. O servidor WebAuthn, exposto por um template, expõe quais as necessidades para implementar o protocolo e como isso agrega seguran¸ca para o processo. A aplica¸cão desenvolvida, que implementa o cliente WebAuthn, tem uma camada baseada no padrão CTAP, alinhada com o protocolo utilizado pelos autenticadores comerciais.

Baseado no resultado da implementa¸cão, tenho a certeza que embarquei no desafio certo e que aproveitei a oportunidade para aprender, evoluir e contribuir com meu trabalho. Acredito que o conhecimento aqui compartilhado possa ser aproveitado pela Faculdade de Ciências em novos projetos e pela empresa Loqr SA na implementa¸cão da adapta¸cão da sua solu¸cão ao protocolo FIDO.

RFC 7049 - Concise Binary Object

Representation (CBOR)

Segundo a Request for Comments (RFC) 7049[5], CBOR (Concise Binary Object Representation) é um formato de dados que permite a cria¸cão de mensagens de tamanho extremamente pequeno sem a necessidade de negoci¸cão de versões, como costuma ser necessário em outros formatos. O modelo de dados é uma versão estendida do modelo de dados JSON (RFC 4627), mas não utiliza diretamente a estrutura do formato JSON, em vez disso é definido um novo modelo de dados que come¸ca com

JSON.

A.1 Objetivos

Os principais objetivos da Representa¸cão Concisa de Objetos Binários (CBOR) são: • A representa¸cão deve ser capaz de codificar inequivocamente a maioria dos

formatos de dados usados em padr˜oes de Internet;

• O c´odigo para um codificador ou decodificador deve ser compact´avel para ofere- cer suporte a sistemas com capacidade limitada;

• Os dados devem ser decodificados sem a descri¸c˜ao do esquema;

• A serializa¸cão deve ser razoavelmente compacta, mas a compacta¸cão dos dados é secundária à compacta¸cão do código para o codificador ou decodificador;

• O formato deve ser aplic´avel em sistemas restritos ou com alto volume de dados; • O formato deve suportar a convers˜ao de e para o formato JSON;

• O formato deve ser extens´ıvel e os dados estendidos devem ser decodific´aveis por decodificadores de vers˜oes anteriores.

Assim como oJSON, é baseado em pares de chave e valor que caracterizam um item de dados. Cada item de dados possui um tipo que define a maneira de codifica¸cão e decodifica¸cão do dado. Os tipos de dados podem ser:

• Tipo 0: n´umero inteiro sem sinal; • Tipo 1: n´umero inteiro negativo; • Tipo 2: uma string de bytes;

• Tipo 3: uma string de texto codificado como Unicode Transformation Format (UTF)-8 (RFC 3629);

• Tipo 4: uma matriz de itens de dados;

• Tipo 5: um mapa de pares de itens de dados;

• Tipo 6: marca¸c˜ao semˆantica para outros tipos de dados;

• Tipo 7: números de ponto flutuante, tipos de dados simples que não precisam de conteúdo ou o código de parada ”break ”.

Utilizando a referˆencia para o tipo de dado, cada item de dado deve ter a estrutura da tabela A.1.

Dado CBOR Item de Dados

Bytes 1byte Variável Variável Estrutura Tipo Informa¸cão Tamanho do dado Dados

adicional (opcional)

Bits 3 bits 5 bits 8 bits x vari´avel 8 bits x vari´avel Tabela A.1: Item de Dados CBOR

RFC 8152 - CBOR Object Signing

and Encryption (COSE)

De acordo com a RFC 8152[6], o formato COSE ´e a utiliza¸c˜ao do formato CBOR

(apêndice A) para a cria¸cão e processamento de assinaturas, códigos de autentica¸cão de mensagens e criptografia, de forma que apresentem as mesmas caracter´ısticas das mensagens no formato CBOR. A estrutura dos objetos seguem um padrão que identifica o tipo de objeto sobre uma matrizCBOR, os primeiros três elementos sempre contêm as mesmas informa¸cões:

• 1 - O conjunto de parˆametros protegidos contidos em uma string de bytes; • 2 - O conjunto de parˆametros desprotegidos como um mapa;

• 3 - O conte´udo da mensagem, apropriado ao tipo de mensagem;

Para representa¸cão de chaves, o formato prevê a defini¸cão de parâmetros que apon- tam informa¸cões sobre o conteúdo e o tipo de chave representado. Os parâmetos a seguir contêm informa¸cões básicas sobre as chaves:

• kty: este parˆametro utiliza a chave 1, que identifica a informa¸c˜ao no objeto

CBOR,é utilizado para identificar a fam´ılia de chaves da estrutura representada e é obrigatório quando o objeto for do tipo chave;

• alg: este parˆametro utiliza a chave 3 para identificar a informa¸c˜ao no objeto

CBORe define o algoritmo utilizado pela chave representada no objeto. 107

No contexto deste trabalho, o tipo de objeto utilizado é para transporte de chaves baseadas em curvas el´ıpticas. Para esse tipo de representa¸cão existem duas versões de cria¸cão do objeto: A primeira versão utiliza as coordenadas X e Y para representar a chave (EC2); A segunda versão utiliza apenas a coordenada X e a coordenada Y deve ser recalculada se necessário para uma opera¸cão de acordo de chaves (OKP).

A versão utilizada é a que representa as duas coordenadas, e neste contexto a chave ”kty”é definida com o valor 2 e a chave ”alg”é definida com o valor -7, que identifica o algoritmo de curvas el´ıpticas. Além destes valores, o objeto deve receber essencialmente mais três valores:

• curve: utiliza a chave -1 no objetoCBORe define a curva utilizada para gera¸c˜ao da chave representada;

• x: utiliza a chave -2 no objetoCBORe define o valor da coordenada X da chave; • y: utiliza a chave -3 no objetoCBORe define o valor da coordenada Y da chave.

[1] FIDO Alliance. Authenticator allowed cryptography list. https: //fidoalliance.org/specs/fido-security-requirements-v1.

1-fd-20171108/fido-authenticator-allowed-cryptography-list-v1. 1-fd-20171108.pdf, acessado em 20/09/2020.

[2] FIDO Alliance. Client to authenticator protocol (ctap).

https://fidoalliance.org/specs/fido-v2.0-ps-20190130/

fido-client-to-authenticator-protocol-v2.0-ps-20190130.html, acessado em 20/09/2020.

[3] FIDO Alliance. Fido alliance certification. https://fidoalliance.org/ certification/, acessado em 20/09/2020.

[4] Instituto Nacional de Tecnologia da Informa¸c˜ao Brasil. Estrutura icp. https: //estrutura.iti.gov.br/, acessado em 20/09/2020.

[5] IETF. Rfc 7049 - concise binary object representation (cbor). https://tools. ietf.org/html/rfc7049, acessado em 20/09/2020.

[6] IETF. Rfc 8152 - cbor object signing and encryption (cose). https://tools. ietf.org/html/rfc8152, acessado em 20/09/2020.

[7] IETF. Rfc 8446 - the transport layer security (tls) protocol version 1.3. https: //tools.ietf.org/html/rfc8446, acessado em 20/09/2020.

[8] Duo Labs. Github - api webauthn. https://github.com/duo-labs/webauthn, acessado em 20/09/2020.

[9] Duo Labs. Github - webauthn.io. https://github.com/duo-labs/webauthn. io, acessado em 20/09/2020.

[10] MIT. Kerberos documentation. https://web.mit.edu/kerberos/, acessado em 20/09/2020.

[11] NIST. Advanced encryption standard (aes). https://fidoalliance. org/specs/fido-security-requirements-v1.1-fd-20171108/

fido-authenticator-allowed-cryptography-list-v1.1-fd-20171108.pdf, acessado em 20/09/2020.

[12] NIST. Elliptic curve cryptography. https://csrc.nist.gov/Projects/ elliptic-curve-cryptography, acessado em 20/09/2020.

[13] NIST. Fips 186-4 - digital signature standard. https://csrc.nist.gov/ publications/detail/fips/186/4/final, acessado em 20/09/2020.

[14] NIST. Recommendation for key management. https://csrc.nist.gov/ publications/detail/sp/800-57-part-1/rev-5/final, acessado em 20/09/2020.

[15] NIST. Secure hash standard (shs). https://csrc.nist.gov/publications/ detail/fips/180/4/final, acessado em 20/09/2020.

[16] Oracle. Class keypairgenerator. https://docs.oracle.com/javase/10/docs/ api/java/security/KeyPairGenerator.html, acessado em 20/09/2020.

[17] C. Paar and J. Pelzl. Understanding Cryptography: A Textbook for Students and Practitioners. Springer Berlin Heidelberg, 2009.

[18] W3C. Web authentication: An api for accessing public key credentials. https: //www.w3.org/TR/webauthn-1/, acessado em 20/09/2020.

[19] Yubico. Github - java-webauthn-server. https://github.com/Yubico/ java-webauthn-server, acessado em 20/09/2020.

No documento Interoperabilidade FIDO (páginas 99-110)