Resumo

  • PSK e RSA podem entregar o material necessário em uma mensagem; os modos Diffie-Hellman e RSA-R dependem de uma resposta. Por isso, a escolha do modo altera o instante em que o iniciador consegue decifrar mídia que chega cedo.
  • O recibo precisa separar modo selecionado, resposta autenticada, chave derivada, chave instalada e primeiro pacote decifrado, além de registrar PFS, contribuições, replay, certificados e alcance de cada TEK.

O tempo faz parte da propriedade

RFC 5197 chama atenção para duas formas de early media. A mídia pode chegar antes da resposta de sinalização porque os caminhos têm latências diferentes; ou o destinatário pode enviar áudio antes do 200 OK, como em filas e tons personalizados. Em ambos os casos, um pacote protegido pode preceder o evento que completa a troca de chaves.

PSK e RSA são esquemas de meia viagem: o iniciador consegue transportar o material necessário em sua primeira mensagem. O respondedor pode ter as chaves antes de emitir mídia. DH-SIGN, DH-HMAC, o desenho DH-SAML e RSA-R exigem material de resposta. Até recebê-lo, o iniciador não tem a chave final.

Essa diferença não torna Diffie-Hellman inadequado. DH-SIGN e DH-HMAC oferecem PFS e participação dos dois lados, propriedades ausentes em PSK e RSA. Ela apenas impõe uma sequência diferente. Se o produto registra MIKEY selected como SRTP ready, apaga justamente o intervalo em que a política precisa decidir se retém, descarta, atrasa ou impede a mídia.

O mesmo pode acontecer sem um serviço clássico de early media. A resposta SIP/SDP pode atravessar vários proxies, enquanto os pacotes seguem diretamente entre endpoints. A evidência correta compara relógios: proposta, contribuição do respondedor, conclusão da transcrição, instalação da chave, primeiro pacote recebido e primeiro decrypt bem-sucedido.

Escolher PFS cria outros pré-requisitos

DH-SIGN autentica o acordo Diffie-Hellman com assinaturas. Ambos participam do segredo e a sessão ganha PFS: comprometer material de longo prazo no futuro não deveria revelar as antigas chaves derivadas. Em escala, porém, os certificados ainda precisam de uma infraestrutura confiável, e o modo se ajusta principalmente a relações ponto a ponto.

DH-HMAC troca as assinaturas por um HMAC baseado em segredo pré-compartilhado. Também entrega contribuição mútua e PFS, sem exigir PKI. É atraente quando um servidor central confiável já mantém segredos com muitos clientes. Ainda assim, exige provisionar os PSK e não transforma automaticamente a sessão em uma solução de chave de grupo.

O modo RSA-R resolve outro problema: fornece o certificado do respondedor em banda, útil quando forking ou retargeting impede saber de antemão quem atenderá. Ele também precisa de uma resposta. A participação opcional do iniciador por RAND não força comportamento honesto do outro lado; por isso não oferece PFS verdadeira.

As propriedades não formam um pacote promocional. Mais PFS pode custar uma viagem adicional; melhor descoberta de certificado pode não melhorar o passado; evitar PKI pode aumentar o trabalho de provisionar segredos. A política deve escolher conscientemente.

Um relógio para replay, outro para prontidão

MIKEY usa timestamps e cache de mensagens no tratamento de replay. Sem sincronização suficiente, esse mecanismo pode falhar; o tamanho do cache precisa acompanhar o desvio admitido. Portanto, o tempo participa de dois controles independentes: decidir se uma mensagem é antiga e decidir se a chave ficou pronta antes da mídia.

Misturá-los gera diagnósticos ruins. Um timestamp aceito não comprova que a resposta necessária já chegou. Uma resposta recente não comprova que não foi vista antes. O recibo deve guardar fonte de tempo, skew, horizonte e geração do cache, bem como os tempos da troca e da instalação.

O pacote de sessões também precisa ser aberto

Um Crypto Session Bundle pode conter várias Crypto Sessions que compartilham TGK e parâmetros, derivando TEK distintas. Para o operador, CSB complete é apenas o início da explicação. É preciso mapear cada TEK ao fluxo, ao endpoint e à ramificação que a recebeu.

Em forking, material de uma modalidade forward pode chegar a vários destinos. Se duas ramificações utilizarem a mesma TEK e escolherem o mesmo SSRC de 32 bits, a derivação SRTP pode repetir chaves e vetores de inicialização, produzindo risco de two-time pad. A baixa probabilidade não substitui a observação concreta de branches e colisões.

Um recibo que encerra no media, não na seleção

Registre identidades, modo executado e pré-requisitos: PSK, certificados, validação e revogação, serviço de credenciais ou endpoints da camada inferior. Registre a contribuição de cada lado e a conclusão sobre PFS. Preserve hash da transcrição, resultado de autenticação, estado anti-replay e qualquer resposta opcional realmente recebida.

Ligue o CSB às Crypto Sessions, TGK, escopos de TEK, branches e SSRC. Depois acrescente proposta, resposta, chave derivada, instalação, primeiro pacote e primeiro decrypt. Se houve fallback ou buffer, registre a decisão e sua autoridade.

Esse modelo não altera o protocolo de RFC 5197. Ele impede que uma propriedade de projeto seja promovida a fato operacional antes de acontecer. Implementado, permitido, escolhido, concluído e utilizável são camadas distintas. A mídia em execução tem a última palavra sobre prontidão; o modo explica as condições sob as quais ela deveria chegar lá.

Fontes

  1. RFC 5197 em HTML
  2. RFC 5197 em texto
  3. Página informativa do RFC 5197
  4. IETF Datatracker: RFC 5197
  5. Histórico do RFC 5197
  6. Referências do RFC 5197
  7. Errata do RFC 5197
  8. RFC 3830 — MIKEY
  9. RFC 3711 — SRTP
  10. RFC 4650 — DH-HMAC
  11. RFC 4738 — RSA-R
  12. RFC 4567 — extensões de chave para SDP e RTSP
  13. RFC 4568 — descrições de segurança
  14. RFC 5027 — precondições de segurança
  15. RFC 4086 — requisitos de aleatoriedade
  16. RFC 4082 — TESLA
  17. RFC 4442 — inicialização do TESLA
  18. Heng Lu — camadas da realidade e poder simbólico
  19. Heng Lu — especificação inicial mínima
  20. Heng Lu — primazia do código em execução