Holder binding explicado: porque é que uma credencial copiada não vale nada
Uma credencial assinada é uma excelente cópia de si mesma. Quem a obtiver fica com um documento com uma assinatura válida do emissor, e verificar essa assinatura confirma-lhe sem hesitar que é autêntico. O holder binding é a peça que fecha essa lacuna: liga a credencial a uma chave que só uma pessoa pode usar, pelo que apresentá-la exige mais do que possuí-la.
Esta página é a versão em linguagem simples. Explica o que é realmente a ligação, quando é criada, como cada um dos dois formatos europeus de credenciais a implementa e a parte que a maioria das explicações omite: aquilo que o holder binding continua a não dizer a um verificador.
O problema que resolve
Os documentos digitais copiam-se na perfeição. Uma fotografia de um passaporte é uma falsificação fraca, porque o papel tem características físicas que uma fotocópia perde, mas uma credencial assinada não tem nenhum sinal desse tipo. Copie o ficheiro e a cópia verifica-se exatamente tão bem como o original, porque a assinatura do emissor abrange o conteúdo e o conteúdo não mudou.
Assim, um verificador que só verifica a assinatura do emissor está a responder à pergunta errada. Ficou a saber que as afirmações são autênticas. Não ficou a saber nada sobre se a parte à sua frente tem direito a elas, que é normalmente aquilo que precisava realmente de saber.
As afirmações
Os factos que a credencial declara: um nome, uma data de nascimento, uma categoria de carta de condução, um número de empresa. É a parte que toda a gente imagina quando pensa numa credencial.
A assinatura do emissor
A prova de que esses factos vieram do emissor e não foram alterados desde então. Não diz absolutamente nada sobre quem os tem agora.
A chave pública do titular
A peça que faz a ligação. O emissor escreve a chave pública do titular na credencial assinada, pelo que a credencial passa a indicar a chave que a pode apresentar.
Quando a ligação é criada e quando é usada
A ligação é feita uma vez, na emissão, e é exercida sempre que a credencial é apresentada. O titular não vê nada dela além do pedido de desbloqueio que já espera.
1. A carteira cria uma chave
Antes de pedir o que quer que seja, a carteira cria um novo par de chaves no próprio hardware seguro do telemóvel. A metade privada não pode ser lida para fora, nem mesmo pela aplicação da carteira.
2. O emissor inscreve-a
A carteira envia a metade pública com o seu pedido e prova que detém a privada. O emissor coloca essa chave pública dentro da credencial antes de a assinar.
3. Um verificador pede
O pedido traz um valor aleatório novo e indica quem está a pedir, pelo que a resposta só pode ser usada uma vez e apenas pela parte que a pediu.
4. A carteira assina
A carteira assina a resposta com a chave privada, normalmente após uma impressão digital ou um PIN. O verificador confirma essa assinatura com a chave que está dentro da credencial.
Onde fica realmente a chave privada
A ligação só é tão boa quanto a dificuldade de usar a chave sem o titular. É por isso que as carteiras geram estas chaves dentro de hardware dedicado, o secure element ou equivalente que também protege as credenciais de pagamento do telemóvel, em vez de as guardarem num ficheiro que o sistema operativo pode entregar a qualquer aplicação que o peça.
Um verificador não consegue ver nada disso a partir da própria apresentação. Uma assinatura prova que a chave foi usada, não que foi bem guardada. Se a chave está de facto em hardware certificado é uma garantia separada, transmitida pelas atestações que uma carteira apresenta a um emissor antes de receber o que quer que seja, e nas regras europeias é para isso que existem a atestação da carteira e a atestação de chave.
O holder binding responde
Esta resposta foi produzida pela chave para a qual a credencial foi emitida, para este pedido, agora mesmo?
A atestação de chave responde
Essa chave está guardada num sítio de onde um atacante não a consegue extrair? Pergunta diferente, prova diferente, decidida na emissão.
Como o fazem os dois formatos europeus
A ideia é a mesma nos dois formatos em que assenta a carteira europeia. A mecânica difere, o que importa a quem implementa um verificador e a quase mais ninguém.
SD-JWT VC
O emissor coloca a chave pública do titular numa afirmação de confirmação dentro da credencial assinada. Na apresentação, a carteira acrescenta um pequeno token separado, assinado com a chave privada, que abrange a identidade do verificador e o valor aleatório do pedido. Um verificador que ignore esse token verificou o emissor e mais nada.
Ler a definiçãomdoc
A chave do dispositivo é indicada no objeto assinado que protege os elementos de dados, e o telemóvel assina a transcrição da sessão em que se encontra. Como essa transcrição abrange a troca entre os dois dispositivos, a gravação de uma apresentação não pode ser reutilizada noutra, e é isso que torna segura uma verificação offline numa fiscalização na estrada ou à entrada de um edifício.
Ler a definiçãoUma carteira no ecossistema europeu transporta geralmente o mesmo atestado nos dois formatos e entrega o que a outra parte fala, pelo que uma organização que aceita credenciais tem de conseguir verificar a ligação em ambos.
O que o holder binding não prova
O holder binding prova o controlo de uma chave. Não prova quem está a segurar o telemóvel. Alguém a quem foram entregues o dispositivo e o PIN produz exatamente a mesma resposta válida que o titular legítimo, e nenhuma criptografia na credencial consegue ver a diferença.
Também não diz nada sobre o cuidado com que o emissor verificou a identidade antes de emitir. Uma credencial ligada a uma chave continua a ser apenas tão fiável quanto o processo que a criou, e é isso que o Level of Assurance serve para descrever. Ligar com muita força a uma chave uma credencial emitida de forma fraca não torna as afirmações nela contidas mais verdadeiras.
Vistas em conjunto, a divisão de tarefas é bastante clara. O holder binding impede a reutilização e a cópia, o desbloqueio da carteira liga a chave a uma pessoa presente, o Level of Assurance descreve o quão bem essa pessoa foi identificada e uma Trusted List diz que emissores aceita, afinal. Um verificador que quer uma resposta real precisa das quatro, não apenas daquela que vem de graça com a credencial.
O que isto significa para si
Emissor
As suas credenciais deixam de ter utilidade para quem roube uma cópia delas, o que elimina toda uma categoria de fraude que, de outro modo, teria de detetar depois do facto. O custo é ter de estar preparado para reemitir sempre que um titular muda de dispositivo.
Verificador
Verifique a ligação, não apenas a assinatura do emissor. Envie um valor aleatório novo em cada pedido e rejeite uma resposta que não o assine, caso contrário uma apresentação gravada pode ser reutilizada contra si mais tarde.
Titular da carteira
Nada para gerir e uma coisa a saber: as suas credenciais estão ligadas a este dispositivo, pelo que um telemóvel novo significa voltar a obtê-las em vez de as restaurar a partir de uma cópia de segurança.
Termos relacionados
Perguntas frequentes
Holder binding é o mesmo que key binding ou device binding?
Na prática, sim, e os nomes diferentes vêm de especificações diferentes e não de qualquer diferença de significado. Holder binding é a propriedade: esta credencial pertence a este titular. Key binding é o nome que o mundo do SD-JWT VC dá ao mecanismo, e o lado ISO fala de device binding ou device authentication porque a chave está num telemóvel concreto. Se um documento usar um destes termos, leia-o como a mesma ideia vista de outro ângulo.
O holder binding prova que quem apresenta a credencial é o seu sujeito?
Não, e este é o equívoco mais comum. Prova que quem produziu a resposta controla a chave para a qual a credencial foi emitida. Se a pessoa que toca no telemóvel é a pessoa descrita nas afirmações depende de como a carteira é desbloqueada, do cuidado com que o emissor verificou a identidade à partida e de o titular ter ou não entregado o dispositivo e o PIN a outra pessoa. Numa verificação de alto valor, combina-se a ligação com uma carteira que exija biometria e com uma credencial emitida a um Level of Assurance adequado ao risco.
O que acontece a uma credencial ligada quando o titular muda de telemóvel?
Não passa para o novo. O objetivo de guardar a chave privada em hardware seguro é precisamente que não possa ser exportada, pelo que uma credencial ligada ao telemóvel antigo não pode ser restaurada no novo e continuar a funcionar. O novo dispositivo gera a sua própria chave e a credencial é emitida de novo para essa chave. Encare a reemissão como um acontecimento normal e frequente, não como uma exceção, porque para os seus utilizadores é simplesmente o dia em que trocaram de telemóvel.
Existem credenciais sem holder binding?
Sim, e têm o seu lugar. Uma credencial sem holder binding é uma credencial ao portador: quem a apresenta fica com o benefício, como num bilhete em papel. É uma troca razoável para algo de baixo valor e curta duração, em que o custo de uma cópia reutilizada é pequeno e prefere não pedir ao titular que desbloqueie o que quer que seja. É a escolha errada para identidade, direitos e tudo o que um burlão consideraria digno de reutilizar.
Fontes
- IETF SD-JWT-based Verifiable Digital Credentials (SD-JWT VC), ainda em rascunho
- OpenID for Verifiable Credential Issuance, sobre a prova de posse da chave na emissão
- OpenID for Verifiable Presentations, sobre a ligação de uma resposta a um único pedido
- ISO/IEC 18013-5, sobre a autenticação do dispositivo para documentos móveis
Esta página tem caráter informativo e não constitui aconselhamento jurídico. Para a redação oficial, consulte diretamente as especificações.