BRPI0615628B1

BRPI0615628B1 - Método para sincronização criptográfica de pacotes de dados

Info

Publication number: BRPI0615628B1
Application number: BRPI0615628-2A
Authority: BR
Inventors: Mats Näslund; Krister Raith; Vesa Lehtovirta; Karl Norrman
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2005-09-09
Filing date: 2006-09-08
Publication date: 2020-02-11
Also published as: DE602006008487D1; CN101258706A; US7725709B2; CN101258706B; JP4608000B2; US20070113085A1; EP1922836B1; ATE439711T1; JP2009508390A; EP1922836A1; CA2616153A1; BRPI0615628A2; WO2007030074A1; CA2616153C

Abstract

método para sincronização criptográfica de pacotes de dados. métodos para sincronização criptográfica de pacotes de dados.um valor de contador de mudança de número (roc) é anexado periodicamente e transmitido com um pacote de dados quando uma função do número de sequência de pacotes iguala um valor predeterminado. o roc sicroniza e efetivamente a transformação criptográfica dos pacotes de dados. embora os métodos expostos sejam geralmente aplicáveis a muitos protocolos de transmissão, eles são pa particularmente adaptáveis para uso em sistema em que os pacotes de dados são transmitidos para um receptor usando o protocolo de transporte em tempo real seguro (srtp) como definido no pedido para comentários (rfc) 3711 da força-tareda de engenharia da internet (ietf).

Description

MÉTODO PARA SINCRONIZAÇÃO CRIPTOGRÁFICA DE PACOTES DE DADOS

REFERÊNCIA CRUZADA A APLICAÇÕES RELACIONADAS [001] Este pedido reivindica o benefício de Pedido Provisório US N° 60/715.873, depositado em 9 de setembro de 2005, a divulgação de qual está incorporada aqui por referência.

CAMPO TÉCNICO DA INVENÇÃO [002] A invenção está relacionada, em geral, ao campo de comunicações e, em particular, ao campo de comunicações seguras.

FUNDAMENTOS DA INVENÇÃO [003] Um protocolo de segurança, ou criptográfico, é um protocolo abstrato ou concreto que executa uma função relacionada à segurança e aplica métodos criptográficos. Protocolos criptográficos são usados extensamente para transporte seguro de dados a nível de aplicação. Um protocolo criptográfico normalmente incorpora pelo menos alguns destes aspectos: acordo ou estabelecimento de chave; autenticação de entidade; construção de material de autenticação de mensagem e encriptação simétrica; transporte seguro de dados a nível de aplicação; e métodos de não rejeição.

[004] Um protocolo criptográfico correndo por um mecanismo de transporte não confiável requer meio para sincronizar o transmissor e receptor, por exemplo, devido à perda de pacote ou reordenação de pacote. No nível mais baixo, um receptor deve ser capaz de montar corretamente pacotes de dados em dados inteligíveis; por exemplo, deve saber se um pacote de dados está perdido de forma que possa pedir retransmissão. Sincronização é tipicamente realizada adicionando um número de sequência a cada pacote ou usando um número de sequência já existente. Tais números de sequência são então entradas para um algoritmo criptográfico, junto com a chave adequada, e sincronização é obtida em uma base por pacote. A abordagem anterior é

Petição 870190095041, de 23/09/2019, pág. 9/27

2/12 preferida, porém, desde que não aumente a quantidade de dados e, assim, a largura de banda necessária.

[005] Devido às propriedades de transformadas criptográficas, o mesmo número de sequência nunca deveria ser usado duas vezes com a mesma chave. Contadores convencionais embutidos, porém, são tipicamente apenas de 16 bits e, assim, em comunicações de alta velocidade, um espaço de número de sequência de 16 bits pode envolver em uma questão de segundos, conduzindo a ineficiência devido a rechaveamento necessário frequente. Por exemplo, com um número de sequência de 16 bits, todo 2¹⁶ pacote conterá números de sequência idênticos, e assim um receptor é incapaz de distinguir tais pacotes.

[006] Para contornar este problema, um contador de transbordamento (ROC) pode ser usado para definir um número de sequência estendido. Para um número de sequência de 16 bits (sequence_number), um número de sequência estendido (EXTENDED_SEQ) poderia ser igual a sequence_number + ROC*2¹⁶. Em tais sistemas, o ROC deveria ser atualizado nos lados de transmissor e receptor sempre que sequence_number envolve módulo 2¹⁶. O valor de ROC, porém, é tipicamente não levado nos pacotes, mas é mantido implicitamente pelo transmissor e receptor. Pode ser mostrado, porém, que contanto que reordenar/perda de pacote não seja mais que 2¹⁵, é possível manter sincronização estimando o valor de ROC baseado em métodos heurísticos; veja, por exemplo o Apêndice de Pedido para Comentários (RFC) 3711 da Força-tarefa de Engenharia da Internet (IETF), Protocolo de Transporte em Tempo Real Seguro (SRTP).

[007] Em algumas aplicações onde usuários podem se unir ou deixar uma sessão em andamento (por exemplo, serviços de multidifusão e radiodifusão 3GPP (MBMS), onde SRTP é para ser usado), porém, o mecanismo estendido não é suficiente devido ao fato que a cada usuário deve ser dado o valor de ROC

Petição 870190095041, de 23/09/2019, pág. 10/27

3/12 atual e não é trivial como transferir precisamente a informação para os usuários. SRTP atualmente não provê um mecanismo para prover o valor de ROC usando sinalização em banda. É possível, porém, sinalizar o valor fora de banda usando um protocolo de administração de chave (por exemplo, Multimedia Internet Keying (MIKEY), IETF RFC3830). O problema com esta abordagem é que a administração de chave é tipicamente executada por um processo separado e não é improvável que a administração de chave seja executada muito tempo antes de um usuário decidir se unir a uma sessão. Neste caso, o valor de ROC que era usado quando administração de chave foi executada não será válido quando um usuário se une a uma sessão.

[008] Embora administração de chave seja executada mais ou menos em sincronização com processo de fluxo de SRTP, é possível que o valor de ROC estará incorreto devido ao modo que SRTP estima o número de sequência estendido. Por exemplo, assuma que o número de sequência de mídia (SRTP) apenas envolveu ao redor (por exemplo, é igual a 0x0000) e que a administração de chave lê o valor de ROC neste ponto em tempo. Próximo, o valor de ROC é transportado ao usuário (receptor) e o usuário lê o valor de ROC e o armazena para referência. Desde que é possível que pacotes sejam reordenados no percurso entre o servidor de mídia e o usuário, o primeiro pacote de mídia (SRTP) que o usuário recebe poderia ser um pacote atrasado que acontece ter, por exemplo, um número de sequência igual a 0xFFFF. Nesta situação, SRTP pode processar esse pacote (atrasado) com um valor de ROC que é alto demais. Também, o próximo pacote de SRTP recebido é provável ter um número de sequência igual a 0x0000. Nesta situação, SRTP adivinharia, ou estimaria o número de sequência envolvido e, assim, aumentaria seu valor de ROC por um. Isto causaria perda de sincronização. Sob condições de perda de pacote pesada, ou se o usuário deixar uma sessão e se reúne depois de tal período longo de

Petição 870190095041, de 23/09/2019, pág. 11/27

4/12 tempo que o ROC envolveu pelo menos uma vez, o problema reaparece.

[009] Por conseguinte, há uma necessidade na técnica por métodos para sincronização criptográfica segura e eficiente em largura de banda. Preferivelmente, tais métodos deveriam fazer uso eficiente de largura de banda e proteger contra manipulação não autorizada.

SUMÁRIO DA INVENÇÃO [0010] Para superar as deficiências da técnica anterior, a presente invenção divulga métodos para sincronização criptográfica segura e eficiente em largura de banda. Em geral, um valor de contador de transbordamento (ROC) é anexado periodicamente e transmitido com um pacote de dados quando uma função do número de sequência de pacote iguala um valor predeterminado. O ROC sincroniza efetivamente a transformação criptográfica dos pacotes de dados.

[0011] De acordo com uma modalidade exemplar descrita mais completamente doravante, um pacote de dados é recebido a um transmissor para transmissão para um receptor; o método é particularmente adaptável para uso em sistemas em que os pacotes de dados são transmitidos a um receptor usando o Protocolo de Transporte em Tempo Real Seguro (SRTP) como definido no Pedido para Comentários (RFC) 3711 da Força-tarefa de Engenharia da Internet (IETF), que está incorporado aqui por referência. O transmissor determina primeiro se um número de sequência de pacote para o pacote de dados é divisível uniformemente por R, onde R é um inteiro concordado previamente pelo transmissor e receptor. O transmissor e receptor podem, por exemplo, se comunicar fora de banda para selecionar um valor de R; protocolos adequados para tal propósito incluem Protocolo de Iniciação de Sessão (SIP), Transporte em Tempo Real Seguro (RTSP), e Multimedia Internet Keying (MIKEY).

[0012] Se o número de sequência de pacote for divisível uniformemente por R, o transmissor computa e anexa um código ao pacote de dados, em que o

Petição 870190095041, de 23/09/2019, pág. 12/27

5/12 código é uma função de uma chave de autenticação associada com o pacote de dados e um valor de contador de transbordamento (ROC) de transmissor. O valor de ROC de transmissor corresponde a um contador no transmissor que é incrementado sempre que um contador de número de sequência no transmissor transborda. O transmissor também anexa o valor de ROC de transmissor ao pacote de dados, e o pacote de dados é então transmitido para o receptor. Se o número de sequência de pacote não for divisível uniformemente por R, porém, o transmissor simplesmente transmite o pacote de dados sem anexar o valor de ROC de transmissor.

[0013] Após o recebimento, o receptor determina se o valor de ROC de transmissor está anexado ao pacote de dados, em que a presença de um valor de ROC de transmissor é indicado se o número de sequência de pacote for divisível uniformemente por R. Se o pacote de dados não incluir um valor de ROC de transmissor, o receptor executa processamento de segurança de pacote usando um valor de ROC estimado, dependendo do valor de ROC mantido localmente do receptor. Se o pacote de dados incluir um valor de ROC de transmissor, o transmissor executa processamento de segurança de pacote usando o valor de ROC de transmissor em lugar do valor de ROC de receptor (ou estimativa do valor de ROC). Como parte deste processamento de segurança, a integridade do pacote de dados é determinada. Se a integridade do pacote de dados não for confirmada, o pacote de dados é abandonado e não é mais processado. Caso contrário, se a integridade do pacote de dados é confirmada, o valor de ROC de receptor é igualado ao valor de ROC de transmissor.

[0014] O precedente esboçou, muito amplamente, os princípios da presente invenção de forma que aqueles versados na técnica possam entender melhor a descrição detalhada das modalidades exemplares que seguem. Aqueles versados na técnica deveriam apreciar que eles podem usar prontamente a

Petição 870190095041, de 23/09/2019, pág. 13/27

6/12 concepção divulgada e modalidades exemplares como uma base para projetar ou modificar outras estruturas e métodos para realizar os mesmos propósitos da presente invenção. Aqueles versados na técnica também deveriam perceber que tais construções equivalentes não se afastam do espírito e extensão da invenção em sua forma mais ampla, como definida pelas reivindicações providas doravante.

BREVE DESCRIÇÃO DA FIGURA [0015] Para ilustrar as características e funções da invenção, referência é feita agora à descrição detalhada seguinte tomada em conjunção com o desenho acompanhante, em que:

[0016] Figura 1 ilustra um sistema, e métodos nele, para sincronização criptográfica segura e eficiente em largura de banda em acordo com os princípios da invenção.

DESCRIÇÃO DETALHADA [0017] Figura 1 ilustra um sistema, e métodos nele, para sincronização criptográfica segura e eficiente em largura de banda em acordo com os princípios da invenção. O sistema compreende um transmissor 101 e receptor 102, cada um operativo para executar certas operações em acordo com os princípios descritos doravante. O método para sincronização criptográfica é descrito especificamente aqui com respeito a um sistema exemplar em que os pacotes de dados são transmitidos a um receptor usando o Protocolo de Transporte em Tempo Real Seguro (SRTP) como definido no Pedido para Comentários (RFC) 3711 da Força-tarefa de Engenharia da Internet (IETF). Aqueles versados na técnica, porém, reconhecerão a aplicabilidade geral do método a sistemas baseados em outros protocolos de transmissão, e as adaptações, se quaisquer, requeridas para tais outros protocolos.

[0018] Para implementar os princípios da invenção em um sistema baseado

Petição 870190095041, de 23/09/2019, pág. 14/27

7/12 em SRTP, um algoritmo de autenticação de mensagem, referido aqui como Código de Autenticação de Mensagem Estendida (XMAC), pode ser adicionado ao framework de SRTP. XMAC pode ser baseado, por exemplo, no Código de Autenticação de Mensagem baseado em Reedição (HMAC) da Força-tarefa de Engenharia da Internet (IETF), ou qualquer outro MAC seguro. De uma perspectiva de framework de SRTP, como aqueles versados na técnica reconhecerão da descrição que segue, XMAC trabalha essencialmente como qualquer outro algoritmo de MAC. Em adição a uma chave de autenticação, porém, XMAC inclui um parâmetro R, que é um inteiro na gama de 0 a 2¹⁶. O transmissor 101 e receptor 102 podem concordar em MAC e um valor por R usando, por exemplo, sinalização fora de banda como conhecido na técnica; protocolos adequados para tal propósito incluem Protocolo de Iniciação de Sessão (SIP), Transporte em Tempo Real Seguro (RTSP), e Multimedia Internet Keying (MIKEY).

[0019] De acordo com o método, um pacote de dados é recebido no transmissor 101 para transmissão ao receptor 102 (Etapa 103). Próximo (Etapa 104), processamento de SRTP é executado no pacote de dados, exceto para uma transformada de integridade. Esta etapa envolve derivar chaves a serem usadas para proteção de dados (isto é, criptografia e proteção de integridade) e processar o pacote de dados até o ponto a proteção de integridade é para ser aplicada (por exemplo, qualquer possível criptografia de SRTP deveria ser executada durante esta etapa).

[0020] Etapas subsequentes constituem proteção de integridade de XMAC para o pacote de dados, incluindo cabeçalho e carga útil. Primeiro (Etapa 105), é determinado se o número de sequência do pacote de dados (sequence_number), que está disponível no cabeçalho de pacote, é divisível uniformemente por R (isto é, 0 mod R). Se o número de sequência de pacote não

Petição 870190095041, de 23/09/2019, pág. 15/27

8/12 for divisível uniformemente por R, nenhuma etiqueta de MAC é para ser adicionada ao pacote de dados e processamento do pacote de dados continua na Etapa 108, em que processamento de SRTP do pacote de dados é completado antes de transmissão (Etapa 109). Se o número de sequência de pacote for divisível uniformemente por R, uma etiqueta de MAC é para ser computada para o pacote de dados.

[0021] Na Etapa 106, uma etiqueta de MAC é computada e adicionada ao pacote de dados. O MAC é uma função da chave de autenticação de SRTP associada com o pacote de dados e um valor de contador de transbordamento de transmissor (ROC), expressa em fórmula como HMAC (key, RTP_packet 11 ROC). O valor de ROC de transmissor corresponde a um contador no transmissor que é incrementado sempre que um contador de número de sequência no transmissor transborda. Próximo (Etapa 107), o valor de ROC de transmissor também é anexado ao pacote de dados; isto é, o pacote de dados foi anexado agora com HMAC (key, RTP_packet || ROC) || ROC. Etapas 106 e 107 têm o efeito de adicionar o valor de ROC de transmissor, integridade protegida por um valor de MAC, para todo R-enésimo pacote. A entrada para o MAC (isto é, RTP_packet Il ROC) será automaticamente (de acordo com a RFC3711) formatada deste modo pelo framework de SRTP e provida como entrada. Aqueles versados na técnica deveriam notar que o valor de ROC de transmissor não será transmitido como parte da carga útil de pacote, mas como parte da etiqueta de MAC; isto é, HMAC (key, RTP_packet || ROC) || ROC pode ser visto como a etiqueta de autenticação de saída do XMAC.

[0022] Finalmente, como com pacotes de dados tendo um número de sequência não divisível uniformemente por R, processamento do pacote de dados continua na Etapa 108, em que processamento de SRTP do pacote de dados é completado antes de transmissão (Etapa 109) para o receptor 102.

Petição 870190095041, de 23/09/2019, pág. 16/27

9/12

Aqueles versados na técnica deveriam reconhecer que, embora o processo executado no receptor 102 comece com a Etapa 110, as operações de transmissor 101 e receptor 102 são assíncronas.

[0023] Após o recebimento de um pacote de dados (Etapa 110), processamento de SRTP é executar até, mas não incluindo, a etapa de derivação de chave de SRTP. Próximo (Etapa 112), é determinado se um valor de contador de transbordamento de transmissor (ROC) está anexado % ao pacote de dados. A presença de um valor de ROC de transmissor, como também XMAC, anexado a um pacote de dados é indicado se o número de sequência de pacote for divisível uniformemente por R (isto é, sequence_number = 0 mod R).

[0024] Se nenhum ROC/XMAC estiver anexado a um pacote de dados, processamento continua na Etapa 121, em que derivação de chave de SRTP padrão é executada usando estimação de ROC convencional. Em tais casos, o receptor 102 considera seu valor de ROC armazenado localmente (ROC_L), que é tipicamente o valor de ROC associado com o pacote prévio. O receptor então examina o número de sequência (SEQ) no pacote de dados recém recebido e o número de sequência previamente recebido mais alto (S_L), que também é rastreado pelo receptor. Usando esses três valores (ROC_L, SEQ e S_L), o receptor pode estimar qual valor de ROC era usado pelo transmissor na hora que o pacote de dados foi transmitido. Isto pode ser feito de vários modos, tal como descrito no Apêndice a IETF RFC 3711, referido nele como estimação de índice. Como um exemplo, se o valor de ROC_L presente for x, S_L é três (0x0003) e o SEQ recebido é 0xffff, o receptor adivinhará que o pacote de dados presente é um pacote atrasado (atrasado por quatro unidades de tempo), correspondendo a ROC = ROC_L-1 (isto é, x-1) como uma envoltura de SEQ ocorreu entre recebimento dos dois pacotes. (Aqueles versados na técnica reconhecerão que depois de SEQ = 0xffff, o próximo SEQ envolverá e o próximo

Petição 870190095041, de 23/09/2019, pág. 17/27

10/12 pacote tem SEQ = 0X0000, etc.). Poderia certamente também ser o caso que o pacote realmente corresponde ao mesmo valor de ROC_L e que, de fato, 2¹⁶ - 3 pacotes consecutivos foram perdidos. Este cenário, porém, é menos provável, então pode ser dito que o receptor usa uma técnica de estimação de probabilidade máxima; isto é, escolhe o ROC mais provável assumindo que a quantidade mínima consistente de perda/reordenação/atraso aconteceu.

[0025] Se o pacote de dados incluir um valor de ROC de transmissor (Etapa 112), derivação de chave de SRTP é executada usando o valor de ROC de transmissor em lugar do valor de ROC de receptor (Etapa 113). Próximo (Etapa 114), a integridade do pacote de dados é determinada. Isto pode ser realizado verificando o XMAC anexado ao pacote usando a chave derivada para verificar que os dados não foram corrompidos ou adulterados (em particular que o valor de ROC de transmissor está correto). Por exemplo, deixe MACJNPUT ser o valor de dados provido por SRTP como entrada de dados para XMAC (isto é, a porção autenticada do pacote de SRTP como definido em RFC 3711) e deixe t' ser a etiqueta recebida, também provida como entrada por SRTP. Próximo, compute t = HMAC (key, MACJNPUT || t'{4}) e compare isto ao valor t'[4] como incluído no pacote, em que X[n] denota a substring correspondendo a todos, exceto os n bytes mais à direita de X e X{n} denota os n bytes mais à direita de X. O XMAC é verificado se e só se os valores t e t'[4] forem iguais.

[0026] Se a integridade do pacote de dados não for confirmada (Etapa 115), o pacote de dados é abandonado (Etapa 116). Caso contrário, se a integridade do pacote de dados for confirmada (Etapa 115), o valor de ROC de receptor é igualado ao valor de ROC de transmissor contido no pacote de dados (Etapa 117), deste modo sincronizando os valores de ROC do transmissor 101 e receptor 102. Próximo, na Etapa 118, o valor de ROC de transmissor e o XMAC são removidos do pacote de dados, seguido pela conclusão de processamento de SRTP (por

Petição 870190095041, de 23/09/2019, pág. 18/27

11/12 exemplo, decriptação) no pacote de dados (Etapa 119). Finalmente, o pacote de dados pode ser saído para uma aplicação (Etapa 120).

[0027] Em uma modalidade alternativa àquela descrita, todos os pacotes de dados com sequence_number = 0 mod R levarão um MAC, computado através do pacote de dados e o ROC, mas só toda R-enésima etiqueta conterá o próprio valor de ROC. Em outras palavras, o valor de ROC de transmissor sempre é usado na entrada para a computação de etiqueta de MAC, mas o valor de ROC de transmissor só é feito parte da saída do MAC para todo R-enésimo pacote. Esta modalidade pode ser usada se todos os pacotes de dados em uma sessão sempre deveriam ser protegidos em integridade.

[0028] Aqueles versados na técnica familiares com o protocolo de SRTP reconhecerão que a única mudança para o framework de SRTP necessária para implementar a sincronização de ROC divulgada aqui e uso do valor de ROC de transmissor recebido, em lugar de o valor de ROC de receptor local, para derivação de chave. Todas as outras operações podem ser operadas internamente pela transformada de XMAC, que pode ser vista como uma caixa preta da perspectiva de protocolo de SRTP. Aqueles versados na técnica também notarão que embora a descrição precedente só mostre como um sequence_number estendido pode ser transportado, os princípios expostos aqui podem ser adaptados para levar outros tipos de dados de sincronização. Semelhantemente, os dados de sincronização, em lugar de serem transformados como parte de uma etiqueta de MAC, podem ser transportados dentro de outros locais de um pacote de dados (por exemplo, parte de um indicador de chave, carga útil, cabeçalho de pacote, etc.).

[0029] Em outras modalidades alternativas, a decisão de se incluir ROC em pacotes de dados usando métodos diferentes de divisibilidade uniforme por R é possível. Em geral, deixe F ser qualquer função mapeando os números de

Petição 870190095041, de 23/09/2019, pág. 19/27

12/12 sequência no conjunto {0,1}. Uma função (F) é primeiro acordada entre emissor e receptor. O emissor (e receptor) então aplicam F a número(s) de sequência de um dado pacote e adicionam informação de ROC se, e só se, F(s) = 1. No exemplo prévio, F(s) é 1 se e só se s for divisível por R.

[0030] Do precedente, será reconhecido que a invenção provê vantagens significantes sobre a técnica anterior. Primeiro, o meio de resincronização para valores de ROC são providos com mudanças mínimas a protocolos existentes, tal como SRTP. Segundo, a largura de banda pode ser economizada ajustando apropriadamente o valor de parâmetro R, como só um pacote em todo Renésimo pacote de dados terá overhead extra. E mais, o valor de ROC de transmissor é transferido seguramente desde que é protegido por um MAC, por esse meio evitando ataques de Negação de Serviço (DoS). Além disso, é trivial para um receptor dizer quais pacotes de dados contêm informações de resincronização (isto é, um valor de ROC de transmissor) sem indicadores ou outro overhead.

Claims

REIVINDICAÇÕES

1. Método em um transmissor para sincronização criptográfica de pacotes de dados, em que ditos pacotes de dados são transmitidos para um receptor usando o Protocolo de Transporte em Tempo Real Seguro (SRTP) como definido em Pedido para Comentários (RFC) 3711 de Força-tarefa de Engenharia da Internet (IETF), dito método caracterizado pelo fato de que compreende as etapas de:

receber um pacote de dados para transmissão;

executar processamento de SRTP em dito pacote de dados, exceto para transformada de integridade;

determinar se um número de sequência de pacote para dito pacote de dados é divisível uniformemente por R, onde R é um inteiro concordado previamente por dito transmissor e dito receptor; e, se o número de sequência de pacote não for divisível uniformemente por R: completar processamento de SRTP em dito pacote de dados; e, transmitir dito pacote de dados para dito receptor;

se o número de sequência de pacote for divisível uniformemente por R: computar e anexar um código de autenticação de mensagem (MAC) para dito pacote de dados, em que dito MAC é uma função de uma chave de SRTP associada com dito pacote de dados e um valor de contador de transbordamento (ROC) de transmissor, dito valor de ROC de transmissor correspondendo a um contador em dito transmissor que é incrementado sempre um contador de número de sequência em dito transmissor transborda;

anexar dito valor de ROC de transmissor a dito pacote de dados; completar processamento de SRTP em dito pacote de dados; e, transmitir dito pacote de dados para dito receptor.
2. Método, de acordo com a reivindicação 1, caracterizado pelo fato

Petição 870190095041, de 23/09/2019, pág. 23/27

2/5 de que dita etapa de executar processamento de SRTP em dito pacote de dados compreende a etapa de derivar uma ou mais chaves para proteção de dados de dito pacote de dados.
3. Método, de acordo com a reivindicação 1, caracterizado pelo fato de compreender ainda a etapa de dito transmissor se comunicar fora de banda com dito receptor para selecionar um valor de R.
4. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que dito contador de número de sequência compreende 16 bits.
5. Método, de acordo com a reivindicação 4, caracterizado pelo fato de que R está na gama de 1 a 2¹⁶.
6. Método, de acordo com a reivindicação 3, caracterizado pelo fato de que dito transmissor e dito receptor concordam em dito valor de R usando um protocolo selecionado do grupo consistindo em:

Protocolo de Iniciação de Sessão (SIP);

Transporte em Tempo Real Seguro (RTSP); e,

Multimedia Internet Keying (MIKEY).
7. Método em um receptor para sincronização criptográfica de pacotes de dados, em que ditos pacotes de dados são recebidos de um transmissor usando o Protocolo de Transporte em Tempo Real Seguro (SRTP) como definido em Pedido para Comentários (RFC) 3711 de Força-tarefa de Engenharia da Internet (IETF), dito método caracterizado pelo fato de que compreende as etapas de:

receber um pacote de dados de dito transmissor;

executar processamento de SRTP em dito pacote de dados exceto derivação de chave de SRTP;

determinar se um valor de contador de transbordamento (ROC) de transmissor está anexado a dito pacote de dados, em que a presença de um valor

Petição 870190095041, de 23/09/2019, pág. 24/27

3/5 de ROC de transmissor é indicada se o número de sequência de pacote for divisível uniformemente por R, onde R é um inteiro previamente concordado por dito transmissor e dito receptor;

se o pacote de dados não incluir um valor de ROC de transmissor: executar derivação de chave de SRTP padrão usando estimação de ROC convencional;

se o pacote de dados incluir um valor de ROC de transmissor:

executar derivação de chave de SRTP usando o valor de ROC de transmissor ao invés de um valor de ROC de receptor;

determinar a integridade do pacote de dados; e, se a integridade de dito pacote de dados não for confirmada, abandonar dito pacote de dados; caso contrário, se a integridade de pacote de dados dito for confirmada:

igualar dito valor de ROC de receptor ao valor de ROC de transmissor contido em dito pacote de dados;

remover dito valor de ROC de transmissor e um código de autenticação de mensagem (MAC) de dito pacote de dados; e, completar processamento de SRTP em dito pacote de dados.
8. Método, de acordo com a reivindicação 7, caracterizado pelo fato de que dita etapa de determinar a integridade do pacote de dados compreende a etapa de determinar que dito MAC é válido usando a chave de SRTP derivada usando dito valor de ROC de transmissor.
9. Método, de acordo com a reivindicação 7, caracterizado pelo fato de compreender ainda a etapa de dito receptor se comunicar fora de banda com dito transmissor para selecionar um valor de R.
10. Método, de acordo com a reivindicação 7, caracterizado pelo fato de que R está na gama de 1 a 2¹⁶.

Petição 870190095041, de 23/09/2019, pág. 25/27

4/5
11. Método, de acordo com a reivindicação 9, caracterizado pelo fato de que dito transmissor e dito receptor concordam sobre dito valor de R usando um protocolo selecionado do grupo consistindo em:

Protocolo de Iniciação de Sessão (SIP);

Transporte em Tempo Real Seguro (RTSP); e,

Multimedia Internet Keying (MIKEY).
12. Método para sincronização criptográfica de pacotes de dados, dito método caracterizado pelo fato de compreender as etapas de:

receber um pacote de dados em um transmissor para transmissão para um receptor, dito pacote de dados incluindo um número(s) de sequência de pacote;

determinar se uma função F(s) de dito número de sequência de pacote é igual a um valor predeterminado, onde F(s) é concordado previamente por dito transmissor e dito receptor;

se F(s) for igual a dito valor predeterminado:

computar e anexar um código a dito pacote de dados, em que dito código é uma função de uma chave de autenticação associada com dito pacote de dados e um valor de contador de transbordamento (ROC) de transmissor, dito valor de ROC de transmissor correspondendo a um contador em dito transmissor que é incrementado sempre que um contador de número de sequência em dito transmissor transborda;

anexar dito valor de ROC de transmissor a dito pacote de dados;

transmitir dito pacote de dados para dito receptor; caso contrário, se F(s) não for igual a dito valor predeterminado:

transmitir dito pacote de dados para dito receptor sem anexar dito valor de ROC de transmissor;

receber dito pacote de dados em dito receptor;

determinar se dito valor de ROC de transmissor está anexado a dito

Petição 870190095041, de 23/09/2019, pág. 26/27

5/5 pacote de dados, em que a presença de um valor de ROC de transmissor é indicada se F(s) for igual a dito valor predeterminado;

se o pacote de dados incluir um valor de ROC de transmissor:

desempenhar processamento de segurança usando o valor de ROC de transmissor ao invés de um valor de ROC de receptor, dito processamento de segurança compreendendo as etapas de:

determinar a integridade do pacote de dados; e, se a integridade de dito pacote de dados não for confirmada, abandonar dito pacote de dados; caso contrário, se a integridade de dito pacote de dados for confirmada:

igualar dito valor de ROC de receptor ao valor de ROC de transmissor; se o pacote de dados não incluir um valor de ROC de transmissor:

executar processamento de segurança usando dito valor de ROC de receptor ou uma estimativa de dito valor de ROC.
13. Método, de acordo com a reivindicação 12, caracterizado pelo fato de compreender ainda a etapa de dito transmissor se comunicar fora de banda com dito receptor para selecionar F(s).
14. Método, de acordo com a reivindicação 12, caracterizado pelo fato de que dito contador de número de sequência compreende 16 bits.
15. Método, de acordo com a reivindicação 12, caracterizado pelo fato de que F(s) = 1.
16. Método, de acordo com a reivindicação 12, caracterizado pelo fato de que dito transmissor e dito receptor concordam sobre dita F(s) usando um protocolo selecionado do grupo consistindo em:

Protocolo de Iniciação de Sessão (SIP);

Transporte em Tempo Real Seguro (RTSP); e,

Multimedia Internet Keying (MIKEY).