Resumo

  • O segredo estático e o registro mutável de índices OTS consumidos cumprem funções diferentes. Um backup pode ser íntegro e ainda estar atrasado em relação às assinaturas já liberadas.
  • A liberação da assinatura e o avanço durável do estado precisam funcionar como um só ato. Setores, intervalos reservados e janelas de tempo só ajudam quando a recuperação mantém uma posse exclusiva e sem sobreposição.
  • Autoteste do HSM e assinatura de teste válida provam capacidade funcional, não a condição inédita do índice. A ativação requer um recibo de custódia que documente fronteiras, exclusões e incerteza.

O painel de recuperação pode exibir apenas sinais verdes: arquivo descriptografado, hash correto, importação aceita, HSM saudável e assinatura de teste verificável. Em um sistema de assinatura hash com estado, essa sequência ainda não prova que a chave de uso único escolhida nunca apareceu antes.

O RFC 10033, publicado como documento Informativo no fluxo IETF, organiza esse problema operacional. XMSS e LMS combinam muitas chaves de assinatura de uso único, ou OTS, sob uma estrutura de longo prazo. Reutilizar o mesmo segredo OTS em mensagens diferentes pode expor informação suficiente para tornar uma falsificação computacionalmente viável. A segurança depende, portanto, de um segredo e de uma contabilidade que nunca retroceda.

O backup autêntico e atrasado

Considere um backup criado quando o próximo índice era 15.000. O sistema ativo libera mil assinaturas e avança até 16.000. Depois de uma falha, a equipe recupera a imagem anterior. O material secreto é legítimo, mas a cópia volta a oferecer os índices 15.000 a 15.999. Eles já foram consumidos fora do sistema.

O erro não está na autenticidade do arquivo; está na sua pretensão de representar o presente. Um checksum não revela uma versão posterior, um clone ativo ou uma resposta que saiu antes de uma queda. O RFC 9802 alerta que a duplicação e restauração comuns de chaves privadas provavelmente levam à reutilização de OTS quando o estado não é coordenado.

O NIST SP 800-208 limita seus perfis aprovados a geração de chaves e assinaturas em módulos criptográficos de hardware, sem exportação do material privado. O RFC 10033 também discute mecanismos além desse perfil. Eles não devem ser confundidos: um fluxo exportável descrito para outro contexto não autoriza exportação em uma implementação conforme ao NIST.

Segredo estático, autoridade mutável

O segredo permite produzir uma assinatura válida. O estado declara qual capacidade ainda pertence exclusivamente ao signatário. Contador, reservas, identidade do dispositivo, logs de respostas, filas, snapshots e evidência de paralisação da origem fazem parte dessa fronteira.

Assim, a recuperação é um teste de exclusividade, não apenas de integridade. Duas cópias autênticas podem assinar corretamente e, ao mesmo tempo, violar a regra de uso único. Fork de processo, clone de máquina virtual ou ativação simultânea em dois locais são caminhos para essa colisão.

Avançar o estado antes de entregar

O RFC 8391 exige atualização do estado XMSS antes da saída da assinatura; o RFC 8554 estabelece a disciplina equivalente para LMS. O RFC 10033 descreve o objetivo como uma transação com atomicidade, consistência, isolamento e durabilidade.

Persistir o avanço e falhar antes de responder desperdiça um índice, mas evita repetição. Responder e depois perder a gravação deixa uma assinatura no mundo e o índice novamente livre no sistema. Os custos não são equivalentes. Descartar capacidade incerta é visível; reutilizá-la cria um risco oculto para todos que confiam na chave pública.

Setores, intervalos e janelas

Setores podem distribuir fragmentos independentes sob a mesma chave pública. Faixas pré-atribuídas evitam disputa entre dispositivos. A reserva de intervalos compromete um bloco inteiro antes do uso e queima o restante após uma falha. Janelas temporais associam capacidade a um período, mas o relógio lógico nunca pode voltar e a sobra de uma janela vencida não pode ser reaberta.

Esses mecanismos definem unidades de custódia; não eliminam o estado. Uma transferência precisa provar que a origem parou e que destino, réplicas, equipamentos avariados e cópias offline não compartilham o mesmo domínio.

Fora do perfil NIST não exportável, o RFC descreve a preparação de árvores inferiores: uma raiz é assinada com uma OTS superior ainda não usada; semente, assinatura, índice e hash são exportados; e a origem elimina sua cópia de forma irreversível. Na recuperação, a primeira semente não usada regenera a árvore e é depois eliminada da mídia. A estrutura torna a passagem de posse explícita, mas a prova de exclusão continua difícil após desastre ou custódia por terceiros.

Recibo de custódia da recuperação

O recibo aqui proposto não é uma exigência do RFC. Ele transforma a decisão operacional em registro revisável.

Deve identificar chave pública, algoritmo e parâmetros; signatário e HSM; geração e data do backup; estado restaurado; maior índice observado numa assinatura completa; setores, intervalos e janelas; reservas queimadas; evidência de paralisação e exclusão na origem; hashes do pacote; operador, aprovador e horários de ativação e reconciliação.

A incerteza também entra no registro. Se o último estado durável é 60.000, mas a fila pode ter liberado respostas até 60.127, toda a faixa deve ser evitada. Se a origem não pode ser declarada inativa, seu setor fica em quarentena. Uma cópia offline não recuperada continua sendo risco de sobreposição.

O recibo não substitui prova criptográfica. Ele revela por que a organização acredita que o signatário restaurado controla sozinho uma região nunca usada e quanta capacidade sacrificou para tornar a dúvida segura.

Fontes