Resumo

  • O RFC 5295 permite derivar raízes específicas por uso e por domínio a partir do EMSK, mas a separação só reduz autoridade se cada receptor receber o ramo mínimo e conservar nome, contexto, geração e prazo.
  • A evidência operacional precisa provar quem pediu a chave, qual capacidade foi concedida, como ela foi transportada e quando cópias antigas perderam efeito — sem registrar o próprio segredo.

Uma conveniência com alcance maior que a necessidade

O desenho parecia prudente: cada domínio teria material distinto. Na implementação, porém, a equipe enviou uma DSRK ao serviço que precisava de uma única função. O receptor prometeu derivar apenas a chave necessária. Nenhuma barreira técnica impedia que criasse as demais chaves daquele ramo.

O RFC 5295 reserva o EMSK para derivação. Uma Usage-Specific Root Key resulta do EMSK, de um rótulo, de um byte nulo, de dados opcionais e do comprimento. O separador impede ambiguidades de prefixo. Entradas iguais geram a mesma saída. Isso entrega separação de material; não decide quem deve possuir cada resultado.

Essa distinção muda a pergunta de auditoria. Não basta confirmar que duas funções receberam bytes diferentes. É preciso saber se cada função recebeu apenas o poder necessário.

O rótulo participa do controle

Cada uso requer uma definição e um rótulo distinto e coordenado. Os rótulos são imprimíveis e sensíveis a maiúsculas e minúsculas. Dados opcionais podem vincular contexto adicional. O nome de uma USRK pode incorporar o EAP Session-ID com o mesmo rótulo e contexto, criando uma referência sem revelar a raiz.

Uma equipe que normaliza o rótulo, outra que descarta dados opcionais e um cache indexado apenas pelo assinante podem reunir saídas separadas no mesmo endereço operacional. A função criptográfica permanece correta enquanto o namespace perde precisão.

O recibo deve conservar Usage ID, bytes exatos do rótulo, separador, hash dos dados opcionais, comprimento, versão da KDF, EAP Session-ID, nome do EMSK e nome resultante. “Derivação concluída” não permite reproduzir a escolha.

Uma DSRK é uma capacidade delegada

A Domain-Specific Root Key pertence a um domínio de gerenciamento de chaves, cujo rótulo participa da derivação. Sob ela podem existir DSUSRKs mais estreitas. O escopo de uma filha precisa estar contido no escopo da mãe.

Logo, o material entregue é parte da autorização. Um destinatário que recebe DSRK pode potencialmente derivar várias funções daquele domínio. Se a necessidade é uma só, a DSUSRK correspondente expressa tecnicamente a restrição. Políticas e contratos não substituem essa redução de capacidade.

O nome do domínio também deve ter interpretação canônica. Grafias distintas que produzem chaves distintas geram uma falha visível. O caso mais difícil é a chave certa chegar a um processo que não deveria exercer aquele domínio.

Rotação não apaga cópias antigas

Uma raiz não pode sobreviver ao EMSK. Quando o EMSK expira, as raízes derivadas deixam o uso; depois de um novo intercâmbio EAP, novas raízes devem entrar em serviço o quanto antes. A troca das chaves filhas depende da definição de cada uso.

Criar uma nova geração não demonstra que caches, réplicas e filhos antigos foram removidos. A operação precisa de inventário e de um evento observável de retirada. Um painel que mede apenas criações consegue declarar sucesso enquanto a autoridade residual continua ativa.

Prazo e geração também acompanham a distribuição. Sem validade, o receptor inventa uma. Sem identidade do pai, pode aplicar a validade à sessão errada. Tempo não é metadado decorativo; é uma dimensão da capacidade.

A interface pode entregar a resposta certa ao chamador errado

O EMSK deve permanecer perto do ponto de derivação. Uma interface fornece raízes e restringe quais chaves cada chamador pode obter. Camadas inferiores e entidades externas não devem presumir acesso ao EMSK.

Uma API ainda pode retornar a raiz correta para um chamador não autorizado. O teste de KDF aprova essa resposta. O controle de acesso deveria recusá-la. Registros seguros identificam chamador, uso, domínio, decisão, nome da chave e geração do pai, sem armazenar o segredo.

Aplicações de camada superior também não deveriam depender apenas de chaves da autenticação de acesso. Esse atalho cria acoplamento oculto à tecnologia de rede e dificulta operar caminhos sem EAP.

Sigilo de transporte não transporta significado

Quando uma raiz precisa viajar, o RFC exige confidencialidade e integridade, partes autenticadas e autorizadas, identificação da chave e restrições de uso, inclusive validade. O documento não escolhe um protocolo de transporte.

Um canal criptografado pode proteger perfeitamente um pacote semanticamente incompleto. Sem nome, domínio, uso, sessão-pai e prazo, o receptor instala uma chave sem poder provar qual capacidade recebeu. O recibo de distribuição liga remetente, destinatário, autorização, canal protegido, hash do pacote, nome, limites e confirmação da geração instalada.

A árvore não fica mais forte que a raiz

A força do material derivado não supera o EMSK nem a chave mestra interna do método EAP. Mais ramos não criam entropia. Quando uma raiz produz muitos filhos, o protocolo filho pode precisar de aleatoriedade nova fornecida pelas partes.

A hierarquia ajuda o menor privilégio, mas não corrige um pai fraco, um nome ambíguo ou um receptor amplo demais.

O recibo que falta à hierarquia

Para cada uso, ligue a sessão EAP, nome do EMSK, Usage ID, rótulo e hash do contexto, KDF e comprimento, domínio, nomes de raiz e filha, linhagem, criação e expiração, índice de cache, substituição e retirada, chamador, extremos da distribuição, identidade do canal, geração instalada, confirmação do protocolo filho e resultado posterior de acesso.

O segredo fica fora do recibo. A finalidade é demonstrar que o poder permaneceu tão estreito quanto a derivação pretendia.

Sources