Resumo

  • O contador de coerência de doze bits do RFC 3078 detectava perda ou quebra de ordem em pacotes MPPE. Não reconstruía o texto cifrado ausente nem demonstrava entrega à aplicação.
  • O modo sem estado podia avançar a chave pela distância do salto. O modo com estado precisava descartar, enviar CCP Reset-Request e aguardar um pacote FLUSHED antes de confiar novamente nas tabelas criptográficas.

O pacote que contou a verdade não podia ser aceito

O receptor esperava um valor e encontrou outro. O cabeçalho havia produzido um fato útil: parte da sequência não estava em sua história local. Mas o transmissor talvez já tivesse cruzado uma mudança de chave que o receptor não viu. O número novo não trazia de volta o estado RC4 correto.

No modo com estado, o RFC 3078 mandava descartar esse pacote, enviar um Reset-Request do Compression Control Protocol sem dados e descartar silenciosamente os seguintes até chegar FLUSHED. O transmissor, ao receber o pedido, reinicializava as tabelas RC4 e marcava o próximo pacote. Não era necessário Reset-Ack separado; a mudança efetiva no fluxo era o recibo.

O desenho distinguia diagnóstico, recuperação criptográfica e resultado de serviço. O salto comprovava uma descontinuidade. FLUSHED abria um novo ponto comum. Nenhum deles recuperava o conteúdo que nunca chegou.

Havia várias decisões antes da cifra

Publicado em março de 2001 como RFC Informational, o RFC 3078 descrevia Microsoft Point-to-Point Encryption para tráfego PPP e atualizava o uso da opção compartilhada com MPPC do RFC 2118. Ele não estabelecia um Internet Standard.

Os pares negociavam MPPE pela opção 18 do Compression Control Protocol. O iniciador apresentava as alternativas suportadas; o respondente normalmente escolhia uma entre 128, 56 e 40 bits. Outro bit solicitava o modo sem estado. Se a negociação não fosse tentada, o padrão era não cifrar. Se fosse tentada e falhasse, o enlace deveria ser encerrado.

Antes do primeiro datagrama MPPE, PPP precisava chegar à fase Network-Layer Protocol e CCP ao estado Opened. Autenticação bem-sucedida não era Opened. Receber uma chave não selecionava o modo. Oferecer 128 bits não provava que esse valor fora aceito. Uma política administrativa exigindo criptografia não protegia o primeiro pacote por conta própria.

Os documentos adjacentes preservavam essa divisão. O RFC 2548 transportava chaves MPPE diferentes por sentido em RADIUS. O RFC 3079 derivava chaves de materiais de autenticação. O RFC 1962 fornecia negociação e reset de CCP; o RFC 1661, as fases de PPP. O RFC 3078 tratava do estado vivo dos pacotes criptografados.

Doze bits guardavam posição, não conteúdo

O contador aumentava a cada pacote e voltava a zero depois de 4095. O receptor comparava o observado com o esperado para reconhecer lacunas, ordem incorreta e a distância pela qual o estado de chave deveria avançar.

O campo não incluía uma cópia do pacote perdido e não autenticava a causa do salto. Fila, filtro, perda física, reordenação ou alteração ativa podiam produzir sinais semelhantes. Mesmo uma sequência contínua não provava que os textos claros tinham chegado à aplicação.

O RFC dizia que MPPE não exigia um enlace confiável e que acrescentar o Reliable Transmission do RFC 1663 geralmente era sobrecarga desnecessária para sincronização. Isso não significava que a perda fosse irrelevante. A máquina criptográfica podia continuar; o protocolo superior ainda precisava reparar ou aceitar os dados ausentes.

Somente uma faixa de números de protocolo PPP passava pelo processador MPPE. O bit que indicava dados cifrados também não tinha integridade criptográfica. Ver um pacote com aparência MPPE era uma observação, não um certificado de que o tráfego correto fora protegido e decifrado.

O modo sem estado alcançava o novo ponto

No modo sem estado, a chave mudava sempre que o contador mudava, normalmente em cada pacote. O emissor avançava antes de cifrar; o receptor, depois de ler o valor e antes de decifrar. Todo pacote criptografado trazia FLUSHED.

Se o último valor fosse dois e o próximo cinco, o receptor realizava três mudanças de chave. Assim podia tentar decifrar o pacote cinco sem um Reset-Request. Os pacotes três e quatro, entretanto, continuavam ausentes.

“Sem estado” não eliminava estado compartilhado. As pontas ainda dependiam da chave inicial, do mesmo algoritmo de evolução, da semântica do contador e do modo escolhido. A diferença era a capacidade de reconstruir localmente o ponto atual a partir de cada pacote.

O modo com estado incorporava o caminho reverso

Com estado, a chave mudava no pacote cujo octeto inferior do contador fosse 0xFF. Se justamente esse pacote sumisse, o emissor avançava e o receptor não. O contador posterior denunciava a ruptura, mas o texto cifrado podia continuar indecifrável.

Reset-Request fazia do caminho de volta parte da recuperação no caminho de ida. Uma captura em uma única direção podia observar a lacuna e depois FLUSHED, mas não provar quem pediu o reset. Uma captura apenas do pedido não provava a resposta nem o primeiro texto claro válido. Era preciso juntar os dois sentidos e o resultado da decifragem.

O RFC também advertia que a reinicialização com estado podia levar dois pacotes a usar a mesma chave. Por isso, esse modo não deveria operar em ambientes sujeitos a perda, como túneis de camada dois sobre a Internet. Era um alerta sobre um mecanismo específico, não uma medição de implantação ou um incidente nomeado.

A própria negociação não tinha integridade

A negociação MPPE não era protegida contra alteração. Um atacante ativo podia modificar Supported Bits e influenciar a força aparente. Configuração local que recusasse modos fracos reduzia o efeito, mas não autenticava a conversa.

O atacante também podia alterar o contador e causar dessincronização, ou inverter o bit de dados cifrados e produzir negação de serviço. Portanto, o cabeçalho alimentava a máquina de estado; ele não servia sozinho como prova confiável para auditoria.

Também seria anacrônico transformar RC4 e uma indicação de 128 bits em recomendação moderna. O RFC 4345 tratou mais tarde de modos Arcfour melhorados para SSH, uma construção diferente. Ele lembra que comprimento nominal de chave não resume segurança, mas não prova migração nem uso atual do MPPE.

O recibo deve acompanhar a transição inteira

Preserve sessão PPP e pares, resultado de autenticação, origem e geração da chave sem revelar o segredo, propostas e respostas CCP, força e modo selecionados e o momento de Opened. Em cada direção, retenha contador esperado e recebido, voltas em 4095, lacunas, FLUSHED, fronteiras 0xFF, descartes, envio e recebimento de Reset-Request, intervalo de espera e primeiro texto claro aceito após o reset.

Depois acompanhe o protocolo superior: sequência, retransmissão, confirmação e efeito. Reunir as tabelas RC4 não fazia reaparecer uma mensagem perdida.

A disciplina de camadas de realidade de Lu Heng mantém os verbos separados. Autenticar, derivar, transportar a chave, negociar, receber, detectar perda, sincronizar, decifrar e entregar são fatos distintos. O código em execução precisa produzir cada ligação.

Fontes