A dificuldade de integrar uma carteira de habilitação digital em um dispositivo móvel (mDL) não está em chamar uma API para verificar a identidade, mas em compreender o que acontece por trás dessa interface: onde as credenciais são armazenadas, quem protege as chaves do dispositivo, como os certificados de confiança são gerenciados e o que continua funcionando quando a rede cai ou o provedor de serviços fica indisponível. O artigo publicado na InfoQ apresenta uma visão arquitetural de sistemas mDL construídos de acordo com o padrão ISO/IEC 18013-5, destinada a instituições que escolhem um provedor, um SDK, uma plataforma de carteira ou um serviço de verificação.
Separação entre prova de identidade e emissão da credencial
O quadro proposto começa separando duas etapas distintas no ciclo de vida da identidade. Na etapa de prova de identidade, o usuário captura imagens de sua carteira de habilitação física e um vídeo para verificação de vivacidade; em seguida, as evidências e os dados extraídos são enviados ao sistema de verificação. A autoridade competente, como o departamento de veículos automotores, analisa essas evidências de forma automatizada ou manual antes de emitir uma decisão de aprovação ou rejeição.
Após a aprovação, começa a etapa de provisionamento. O dispositivo cria chaves assimétricas dentro de um Secure Enclave ou elemento seguro e envia a chave pública, os certificados de atestação e uma referência ao processo de prova à autoridade emissora. A autoridade vincula os dados da habilitação à chave dentro de um Mobile Security Object assinado; depois, criptografa o pacote de credenciais e o envia à carteira para armazenamento em uma área apoiada por hardware.
A instituição não precisa necessariamente executar essas etapas por conta própria, mas deve identificar a parte responsável por cada etapa e a parte que detém a decisão de confiança resultante.
O que deve ser examinado por trás da interface do provedor?
O artigo considera que o sucesso de uma demonstração que chama funções como verifyCredential() ou requestPresentation() não é suficiente para avaliar o provedor. A análise deve abranger seis eixos inter-relacionados:
- Arquitetura criptográfica: criação e proteção das chaves, atestação do dispositivo, algoritmos e ciclo de vida das chaves.
- Confiança e infraestrutura de chaves públicas: âncoras de confiança, certificados de Document Signer, listas de confiança e de revogação.
- Privacidade e minimização de dados: divulgação seletiva, telemetria, retenção de dados de apresentação e riscos de vinculação entre transações.
- Operação offline: materiais armazenados em cache, estado de revogação desatualizado e comportamento do sistema durante uma interrupção da rede.
- Interoperabilidade: conformidade com a ISO/IEC 18013-5 e possibilidade de interação com carteiras e verificadores independentes.
- Resiliência operacional: impacto da indisponibilidade do provedor, continuidade da credencial e mecanismos de recuperação e tratamento de falhas.
Criptografia e certificados não são detalhes de implementação
O artigo propõe o uso de Hybrid Public Key Encryption de acordo com a RFC 9180 para proteger operações de transporte pela internet e trocas de API, com a definição de parâmetros que incluem DHKEM(P-256, HKDF-SHA256), HKDF-SHA256 e AES-128-GCM. No entanto, segundo o quadro apresentado, a criptografia não deve ser tratada como um recurso separado do modelo de confiança; é necessário saber onde a criptografia começa e termina, quem cria e protege as chaves, como elas são rotacionadas e quais componentes estão dentro dos limites de confiança do provedor.
As comunicações entre servidores de carteiras, plataformas de emissão e sistemas de verificação também precisam de autenticação mútua por TLS e de uma arquitetura de certificados clara. O artigo apresenta diferentes funções para os certificados, desde a raiz de confiança armazenada em um módulo de segurança de hardware offline até certificados de Document Signer de curta duração, certificados mTLS e certificados de atestação de chaves de dispositivos. A questão decisiva continua sendo a distribuição de responsabilidades: qual arquitetura é gerenciada pelo provedor, qual está sob o controle da instituição e quais relações de confiança permanecem nas mãos da autoridade emissora.
O que muda na prática quando o serviço fica indisponível?
O projeto distingue entre operações síncronas que ocorrem durante a verificação, como a troca de dados por NFC ou a verificação direta por API, e operações assíncronas que podem ser executadas em segundo plano, como a análise da prova de identidade, o provisionamento da credencial, a rotação de chaves e a sincronização de listas de confiança.
Essa separação permite continuar apresentando uma credencial existente e verificá-la offline quando as políticas assim permitirem, enquanto a sincronização das listas de confiança ou as atualizações de revogação podem ser adiadas. O artigo propõe testar a apresentação e a verificação sem rede, credenciais expiradas, listas de revogação antigas, desvio do relógio do dispositivo, restauração da conectividade e o comportamento do sistema durante a indisponibilidade do provedor. A dependência de um provedor altamente disponível ainda pode representar um ponto único de falha se cada verificação exigir conexão com seus serviços de back-end.
Divulgação seletiva e prevenção da dependência do provedor
Os dados necessários variam conforme o caso. Um ponto de controle em um aeroporto pode precisar do nome, da fotografia, da data de nascimento, do número do documento e da autoridade emissora, enquanto uma loja pode se limitar a uma declaração lógica que prove que a idade do usuário é superior a 21 anos, acompanhada de uma fotografia, sem o nome, o endereço ou o número do documento. Portanto, não basta testar o provedor com um único cenário; é necessário avaliá-lo com base nas políticas da instituição e nas categorias reais de transações.
O material propõe manter a lógica de negócios independente da arquitetura do provedor, de modo que os aplicativos expressem uma política como solicitar prova de que a idade é superior a 21 anos, em vez de disseminar estruturas de dados específicas do provedor por todo o sistema. Detalhes como a serialização CBOR, a construção de mensagens APDU e as chamadas de bibliotecas criptográficas podem ser ocultados, mas os pontos de confiança, a identidade da autoridade emissora, os atributos divulgados, o estado do certificado e da revogação, a dependência do provedor e os recursos de operação offline devem permanecer visíveis para a instituição.
Leitura da certi.news
A mudança real destacada pelo artigo é transferir a avaliação de mDL do teste de uma função do SDK para a revisão de um sistema de confiança completo. Essa abordagem é útil para as equipes de segurança, identidade e compras porque define o que pode ser comprado e o que deve permanecer sob a governança da instituição: é possível comprar a implementação da carteira, os protocolos NFC e as bibliotecas criptográficas, enquanto as políticas de divulgação, autorização e auditoria, bem como a governança do gerenciamento de chaves e certificados, da privacidade, da disponibilidade e da interoperabilidade, devem ser construídas.
No entanto, o quadro, por si só, não resolve questões como os requisitos locais de conformidade ou os modelos de governança entre autoridades emissoras e verificadores. Além disso, garantir a validade da assinatura não assegura a privacidade se os sistemas mantiverem registros excessivos ou vincularem as operações de apresentação aos usuários. Por isso, questões de rastreabilidade, revogação com preservação da privacidade e responsabilidade em caso de falha do provedor continuam exigindo decisões institucionais e regulatórias antes da entrada em produção.