BRPI0615628A2 - método para sincronização criptográfica de pacotes de dados - Google Patents
método para sincronização criptográfica de pacotes de dados Download PDFInfo
- Publication number
- BRPI0615628A2 BRPI0615628A2 BRPI0615628-2A BRPI0615628A BRPI0615628A2 BR PI0615628 A2 BRPI0615628 A2 BR PI0615628A2 BR PI0615628 A BRPI0615628 A BR PI0615628A BR PI0615628 A2 BRPI0615628 A2 BR PI0615628A2
- Authority
- BR
- Brazil
- Prior art keywords
- data packet
- transmitter
- value
- receiver
- roc
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/12—Transmitting and receiving encryption devices synchronised or initially set up in a particular manner
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
- H04L9/16—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms the keys or algorithms being changed during operation
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
- Small-Scale Networks (AREA)
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 PEDIDOS RELACIONADOS
Este pedido reivindica o benefício de Pedido Provisório US N0 60/715.873, depositado em 9 de setembro de 2005, a exposição de qual está incorporada aqui por referência. CAMPO TÉCNICO DA INVENÇÃO
Em geral, a invenção está relacionada ao campo de comunicações e, em particular, ao campo de comunicações seguras. FUNDAMENTO DA INVENÇÃO
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 aplicativo. 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 criptografia mensagem simétrica; transporte seguro de dados a nível de aplicativo; e métodos de não rejeição.
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 seqüência a cada pacote ou usando um número de seqüência já existente. Tais números de seqüência são então entrados a um algoritmo criptográfico, junto com a chave própria, e sincronização é obtida em uma base por pacote. A abordagem anterior é preferida, porém, desde que não aumenta a quantidade de dados e, assim, a largura de banda necessária.
Devido às propriedades de transformadas criptográficas, o mesmo número de seqüência nunca deveria ser usado duas vezes com a mesma chave. Contadores embutidos convencionais, porém, são tipicamente só de 16 bits e, assim, em comunicações de alta velocidade, um espaço de número de seqüência de 16 bits pode "envolver" em questão de segundos, conduzindo à ineficiência devido a re-chaveamento freqüente necessário. Por exemplo, com um número de seqüência de 16 bits, todo 216 pacote conterá números de seqüência idênticos, e assim um receptor é incapaz de distinguir tais pacotes.
Para contornar este problema, um contador de mudança de número ("ROC") pode ser usado para definir um número de seqüência "estendido". Para um número de seqüência de 16 bits (sequencejiumber), um número de seqüência estendido (EXTENDED_SEQ) poderia ser igual a sequence_number + ROC*216. Em tais sistemas, o ROC deveria ser atualizado nos lados de transmissor e receptor sempre que sequencejiumber "envolve" módulo 216. 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 re-ordem/perda de pacote não seja mais que 215, é 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), "Secure Real-time Transport Protocol" ("SRTP").
Em algumas aplicações onde usuários podem se unir ou deixar uma sessão em andamento (por exemplo, serviços de Multi-difusão e radiodifusão de 3 GPP (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 atual e não é trivial como transferir precisamente a informação para os usuários. SRTP atualmente não provê um F mecanismo para prover o valor de ROC usando sinalização em banda. E 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 administração de chave é executada tipicamente 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. 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 seqüência estendido. Por exemplo, assuma que o número de seqüê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. A seguir, 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 re-ordenados no caminho entre o servidor de mídia e o usuário, o primeiro pacote mídia (SRTP) que o usuário recebe poderia ser um pacote atrasado que acontece ter, por exemplo, um número de seqüência igual a OxFFFF. Nesta situação, SRTP pode processar esse pacote (atrasado) com um valor de ROC que é um alto demais. Também, o próximo pacote de SRTP recebido é provável ter um número de seqüência igual a 0x0000. Nesta situação, SRTP adivinharia, ou estimaria o número de seqüê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 tempo que o ROC envolveu pelo menos uma vez, o problema reaparece.
Por conseguinte, há uma necessidade na técnica por métodos para sincronização criptográfica segura e eficiente em largura de banda. Preferivelmentej tais métodos deveriam fazer uso eficiente de largura de banda e proteger contra manipulação não autorizada.
SUMÁRIO DA INVENÇÃO
Para superar as deficiências da técnica anterior, a presente
invenção expõe métodos para sincronização criptográfica segura e eficiente em largura de banda. Em geral, 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 seqüência de pacote iguala um valor predeterminado. O ROC sincroniza efetivamente a transformação
criptográfica dos pacotes de dados.
De acordo com uma concretização exemplar descrita mais
completamente em seguida, 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 seqüência de pacote para o
pacote de dados é divisível uniformemente por Rs 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)5 Transporte em Tempo Real Seguro (RTSP), e 'Multimedia
Internet Keying' (MIKEY).
Se o número de seqüência de pacote for divisível
uniformemente por R, o transmissor computa e anexa um código ao pacote de
dados, em que o código é uma função de uma chave de autenticação associada
com o pacote de dados e um valor de contador de mudança de número (ROC) de transmissor. O valor de ROC de transmissor corresponde a um contador no transmissor que é incrementado sempre que contador de número de seqüência no transmissor excede. 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 seqüê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.
No 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 seqüê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 é suprimido e não é ademais processado. Caso contrário, se a integridade do pacote de dados for confirmada, o valor de ROC de receptor é fixado ao valor
de ROC de transmissor.
O antecedente esboçou, bastante amplamente, os princípios da
presente invenção de forma que aqueles qualificados na técnica possam entender melhor a descrição detalhada das concretizações exemplares que seguem. Aqueles qualificados na técnica deveriam apreciar que eles podem usar prontamente a concepção exposta e concretizações exemplares como uma base para projetar ou modificar outras estruturas e métodos para efetuar os mesmos propósitos da presente invenção. Aqueles qualificados na técnica também deveriam perceber que tais construções equivalentes não partem do espírito e extensão da invenção em sua forma mais ampla, como definida pelas reivindicações providas em seguida. BREVE DESCRIÇÃO DA FIGURA Para ilustrar as características e funções da invenção,
referência é feita agora à descrição detalhada seguinte tomada junto com o
desenho acompanhante, em que:
Figura 1 ilustra um sistema, e métodos nele, para
sincronização criptográfica segura e eficiente em largura de banda de acordo com os princípios da invenção. DESCRIÇÃO DETALHADA
Figura 1 ilustra um sistema, e métodos nele, para sincronização criptográfica segura e eficiente em largura de banda de acordo com os princípios da invenção. O sistema inclui um transmissor 101 e receptor 102, cada um operativo para executar certas operações de acordo com os princípios descritos em seguida. 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 qualificados 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.
Para implementar os princípios da invenção em um sistema
baseado em SRTP, um algoritmo de autenticação de mensagem, referido aqui como Código de Autenticação de Mensagem Estendida (XMAC), pode ser adicionado à estrutura 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 estrutura de SRTP, como aqueles qualificados na técnica reconhecerão da descrição que segue, XMAC trabalha essencialmente como qualquer outro algoritmo de MAC. Além de uma chave de autenticação, porém, XMAC inclui um parâmetro R, que é um inteiro na gama de 0-216. 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 Keying1 (MIKEY).
De acordo com o método, um pacote de dados é recebido no
transmissor 101 para transmissão ao receptor 102 (Etapa 103). A seguir (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 que a proteção de integridade é para ser aplicada (por exemplo, qualquer possível criptografia de SRTP deveria ser executada durante esta etapa).
Etapas subseqüentes 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 seqüê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 seqüência de pacote não 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 seqüência de pacote for divisível uniformemente por R, uma etiqueta de MAC é para ser computada para o pacote de dados. 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 mudança de número de transmissor (ROC)s expressa em fórmula como HMAC(key, RTP^packet || ROC). O valor de ROC de transmissor corresponde a um contador no transmissor que é incrementado sempre que um contador de número de seqüência no transmissor excede. A seguir (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) Il ROC. Etapas 106 e 107 têm o efeito de adicionar o valor de ROC de transmissor, integridade protegida por um valor de MAC5 para todo R-ésimo pacote. A entrada para o MAC (isto é, RTPjsacket || ROC) será automaticamente (de acordo com a rFC3711) formatada deste modo pela estrutura de SRTP e provida como entrada. Aqueles qualificados 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.
Finalmente, como com pacotes de dados tendo um número de
seqüê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. Aqueles qualificados 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.
No recebimento de um pacote de dados (Etapa 110), processamento de SRTP é executado até, mas não incluindo, a etapa de derivação de chave de SRTP. A seguir (Etapa 112), é determinado se um valor de contador de mudança de número 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 seqüência de pacote for divisível uniformemente por R (isto é,
sequence jiumber = O mod R). 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 seqüência (SEQ) no pacote de dados
recém recebido e o número de seqüê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 V\ S_L é três (0x0003) e o SEQ recebido é Oxffff, 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 qualificados na técnica reconhecerão que depois de
SEQ = Oxffff, o próximo SEQ envolverá e o próximo 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, na realidade, 216 - 3 pacotes
consecutivos foram perdidos. Este cenário, porém, é menos provável, assim
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
consistente mínima de perda/reordenação/atraso aconteceu.
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). A seguir (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 MMAC_INPUT" 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. A seguir, compute t = HMAC(key, MAC JNPUT || t'{4}) e compare isto ao valor t'[4] como incluído no pacote, em que X[n] denota a sub-carreira correspondendo a todos, exceto os η bytes mais à direita de X5 e X{n} denota os η bytes mais à direita de X. O XMAC é verificado se
e só se os valores t e t'[4] forem iguais.
Se a integridade do pacote de dados não for confirmada (Etapa
115), o pacote de dados é suprimido (Etapa 116). Caso contrário, se a
integridade do pacote de dados for confirmada (Etapa 115), o valor de ROC
de receptor é fixado ao valor de ROC de transmissor contido no pacote de
dados (Etapa 117), por esse meio sincronizando os valores de ROC do
transmissor 101 e receptor 102. A seguir, 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 exemplo, decifração) no pacote de
dados (Etapa 119). Finalmente, o pacote de dados pode ser saído para um
aplicativo (Etapa 120).
Em uma concretização alternativa àquela descrita, todos os
pacotes de dados com sequencejiumber = 0 mod R levarão um MAC,
computado através do pacote de dados e o ROC, mas só toda R-é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 para parte da saída do MAC para todo R-ésimo pacote. Esta concretização pode ser usada se todos os pacotes de dados em uma sessão sempre deveriam ser protegidos em
integridade.
Aqueles qualificados na técnica familiares com o protocolo de
SRTP reconhecerão que a única mudança para a estrutura de SRTP necessária para implementar a sincronização de ROC exposta aqui é 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 qualificados 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.).
Em outras concretizações 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 seqüência no conjunto {0,1}. Uma função (F) é primeiro acordada entre transmissor e receptor. O transmissor (e receptor) então aplicam F a números de seqüê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.
Do antecedente, será reconhecido que a invenção provê
vantagens significantes sobre a técnica anterior. Primeiro, meio de re- sincronização para valores de ROC é provido com mudanças mínimas a protocolos existentes, tal como SRTP. Segundo, largura de banda pode ser economizada fixando apropriadamente o valor de parâmetro R, como só um pacote em todo R-ésimo pacote de dados terá bits extras. Além disso, 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ção de re-sincronização (isto é, um valor de ROC de transmissor) sem "indicadores" ou outros bits extras.
Claims (16)
1. Método para sincronização criptográfica de pacotes de dados em um transmissor, em que ditos 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- tarefa de Engenharia da Internet (IETF)5 caracterizado pelo fato de que inclui as etapas de: receber um pacote de dados para transmissão; executar processamento de SRTP em dados dito pacote, exceto para transformada de integridade; determinar se um número de seqüê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 seqüê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 seqüê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 mudança de número de transmissor (ROC), dito valor de ROC de transmissor correspondendo a um contador em dito transmissor que é incrementado sempre que contador de número de seqüência em dito transmissor excede; 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 de que dita etapa de executar processamento de SRTP em dito pacote de dados inclui 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 seqüência inclui 16 bits.
5. Método de acordo com a reivindicação 4, caracterizado pelo fato de que R está na gama de 1 a 216.
6. Método de acordo com a reivindicação 3, 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).
7. Método para sincronização criptográfica de pacotes de dados em um receptor, em que dito pacotes de dados são recebidos de um transmissor 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), caracterizado pelo fato de que inclui 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 mudança de número de transmissor (ROC) está anexado a dito pacote de dados, em que a presença de um valor de ROC de transmissor é indicada se o número de seqüência de pacote for divisível uniformemente por R, onde R é um inteiro concordado previamente 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 em lugar de um valor de ROC de receptor; determinar a integridade do pacote de dados; e, se a integridade de pacote de dados dito não for confirmada, suprimir dito pacote de dados; caso contrário, se a integridade de pacote de dados dito for confirmada: fixar 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 inclui 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 216.
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, 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 seqüência de pacote; determinar se uma função F(s) de dito número de seqüê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 mudança de número de transmissor (ROC), dito valor de ROC de transmissor correspondendo a um contador em dito transmissor que é incrementado sempre que um contador de número de seqüência em dito transmissor excede; 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 a dito receptor; determinar se dito valor de ROC de transmissor está anexado a dito 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: executar processamento de segurança usando o valor de ROC de transmissor em lugar de um valor de ROC de receptor, dito processamento de segurança incluindo as etapas de: determinar a integridade do pacote de dados; e, se a integridade de dito pacote de dados não for confirmada, suprimir dito pacote de dados; caso contrário, se a integridade de dito pacote de dados for confirmada: fixar 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 seqüência inclui 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).
Applications Claiming Priority (7)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US71587305P | 2005-09-09 | 2005-09-09 | |
| US60/715873 | 2005-09-09 | ||
| US60/715,873 | 2005-09-09 | ||
| US11/470,554 US7725709B2 (en) | 2005-09-09 | 2006-09-06 | Methods for secure and bandwidth efficient cryptographic synchronization |
| US11/470,554 | 2006-09-06 | ||
| US11/470554 | 2006-09-06 | ||
| PCT/SE2006/001040 WO2007030074A1 (en) | 2005-09-09 | 2006-09-08 | Methods for secure and bandwidth efficient cryptographic synchronization |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| BRPI0615628A2 true BRPI0615628A2 (pt) | 2012-12-18 |
| BRPI0615628B1 BRPI0615628B1 (pt) | 2020-02-11 |
Family
ID=37464202
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| BRPI0615628-2A BRPI0615628B1 (pt) | 2005-09-09 | 2006-09-08 | Método para sincronização criptográfica de pacotes de dados |
Country Status (9)
| Country | Link |
|---|---|
| US (1) | US7725709B2 (pt) |
| EP (1) | EP1922836B1 (pt) |
| JP (1) | JP4608000B2 (pt) |
| CN (1) | CN101258706B (pt) |
| AT (1) | ATE439711T1 (pt) |
| BR (1) | BRPI0615628B1 (pt) |
| CA (1) | CA2616153C (pt) |
| DE (1) | DE602006008487D1 (pt) |
| WO (1) | WO2007030074A1 (pt) |
Families Citing this family (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7404080B2 (en) | 2001-04-16 | 2008-07-22 | Bjorn Markus Jakobsson | Methods and apparatus for efficient computation of one-way chains in cryptographic applications |
| CN101370004A (zh) * | 2007-08-16 | 2009-02-18 | 华为技术有限公司 | 一种组播会话安全策略的分发方法及组播装置 |
| US8265593B2 (en) * | 2007-08-27 | 2012-09-11 | Alcatel Lucent | Method and system of communication using extended sequence number |
| US8464053B2 (en) * | 2007-09-05 | 2013-06-11 | Radvision Ltd | Systems, methods, and media for retransmitting data using the secure real-time transport protocol |
| CN101159533A (zh) * | 2007-11-06 | 2008-04-09 | 中兴通讯股份有限公司 | 一种分组传送网中时钟链路自动保护的方法 |
| WO2010026637A1 (ja) | 2008-09-04 | 2010-03-11 | 富士通株式会社 | 送信装置、受信装置、送信方法および受信方法 |
| US8504818B2 (en) | 2010-04-15 | 2013-08-06 | Microsoft Corporation | Method and system for reliable protocol tunneling over HTTP |
| US8724548B2 (en) * | 2010-04-22 | 2014-05-13 | Qualcomm Incorporated | Counter check procedure for packet data transmission |
| US9755788B2 (en) * | 2014-05-30 | 2017-09-05 | Apple Inc. | Messages with attenuating retransmit importance |
| US10341311B2 (en) * | 2015-07-20 | 2019-07-02 | Schweitzer Engineering Laboratories, Inc. | Communication device for implementing selective encryption in a software defined network |
| JP6534913B2 (ja) * | 2015-11-06 | 2019-06-26 | 日立オートモティブシステムズ株式会社 | 情報処理装置および不正メッセージ検知方法 |
| JP6814549B2 (ja) * | 2016-04-27 | 2021-01-20 | 日立オートモティブシステムズ株式会社 | 演算装置、認証システム、認証方法 |
| CN114205219A (zh) * | 2021-10-26 | 2022-03-18 | 深圳市潮流网络技术有限公司 | 基于srtp协议的加密流的容灾处理方法及相关设备 |
Family Cites Families (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE3527856A1 (de) * | 1984-08-03 | 1986-02-27 | Nissan Motor Co., Ltd., Yokohama, Kanagawa | Verfahren und vorrichtung zur steuerung einer brennkraftmaschine |
| US4974148A (en) * | 1987-07-06 | 1990-11-27 | Motorola Computer X, Inc. | Bus arbiter with equitable priority scheme |
| US5699392A (en) * | 1995-11-06 | 1997-12-16 | Stellar One Corporation | Method and system for the recovery of an encoder clock from an MPEG-2 transport stream |
| KR100684056B1 (ko) * | 1999-01-28 | 2007-02-16 | 코닌클리케 필립스 일렉트로닉스 엔.브이. | 데이터 패킷 전송 시스템에서의 해독 키들의 동기화 |
| US6980658B1 (en) * | 1999-09-30 | 2005-12-27 | Qualcomm Incorporated | Method and apparatus for encrypting transmissions in a communication system |
| EP1452000A2 (en) * | 2001-12-07 | 2004-09-01 | Telefonaktiebolaget LM Ericsson (publ) | Lawful interception of end-to-end encrypted data traffic |
| US7406082B2 (en) * | 2002-09-30 | 2008-07-29 | Lucent Technologies Inc. | Sequence number schemes for acceptance/rejection of duplicated packets in a packet-based data network |
| ATE552709T1 (de) * | 2003-09-26 | 2012-04-15 | Ericsson Telefon Ab L M | Verbesserter sicherheitsentwurf für die kryptographie in mobilkommunikationssystemen |
| US7372856B2 (en) * | 2004-05-27 | 2008-05-13 | Avaya Technology Corp. | Method for real-time transport protocol (RTP) packet authentication |
-
2006
- 2006-09-06 US US11/470,554 patent/US7725709B2/en active Active
- 2006-09-08 CN CN2006800328147A patent/CN101258706B/zh active Active
- 2006-09-08 DE DE602006008487T patent/DE602006008487D1/de active Active
- 2006-09-08 CA CA2616153A patent/CA2616153C/en active Active
- 2006-09-08 BR BRPI0615628-2A patent/BRPI0615628B1/pt active IP Right Grant
- 2006-09-08 JP JP2008529960A patent/JP4608000B2/ja active Active
- 2006-09-08 EP EP06784170A patent/EP1922836B1/en active Active
- 2006-09-08 WO PCT/SE2006/001040 patent/WO2007030074A1/en active Application Filing
- 2006-09-08 AT AT06784170T patent/ATE439711T1/de not_active IP Right Cessation
Also Published As
| Publication number | Publication date |
|---|---|
| CA2616153C (en) | 2015-05-19 |
| CN101258706A (zh) | 2008-09-03 |
| US7725709B2 (en) | 2010-05-25 |
| CN101258706B (zh) | 2011-08-10 |
| CA2616153A1 (en) | 2007-03-15 |
| EP1922836A1 (en) | 2008-05-21 |
| JP2009508390A (ja) | 2009-02-26 |
| EP1922836B1 (en) | 2009-08-12 |
| JP4608000B2 (ja) | 2011-01-05 |
| DE602006008487D1 (de) | 2009-09-24 |
| ATE439711T1 (de) | 2009-08-15 |
| BRPI0615628B1 (pt) | 2020-02-11 |
| WO2007030074A1 (en) | 2007-03-15 |
| US20070113085A1 (en) | 2007-05-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| BRPI0615628A2 (pt) | método para sincronização criptográfica de pacotes de dados | |
| US10587399B2 (en) | Data conversion systems and methods | |
| US9674204B2 (en) | Compact and efficient communication security through combining anti-replay with encryption | |
| Moskowitz et al. | Host identity protocol | |
| US10542425B2 (en) | Method and apparatus for reducing overhead for integrity check of data in wireless communication system | |
| WO2007059558A1 (en) | Wireless protocol for privacy and authentication | |
| WO1999014888A2 (en) | Security method for transmissions in telecommunication networks | |
| JP2007140566A (ja) | 効率的なパケット暗号化方法 | |
| US7139679B1 (en) | Method and apparatus for cryptographic protection from denial of service attacks | |
| US20130136145A1 (en) | Time message processing method, apparatus and system | |
| Wool | A note on the fragility of the" Michael" message integrity code | |
| Baugher et al. | The use of timed efficient stream loss-tolerant authentication (TESLA) in the secure real-time transport protocol (SRTP) | |
| JP2011045064A (ja) | 無線通信システムにおけるデータの完全性検査のためのオーバーヘッドを低減させるための方法及び装置 | |
| Singh et al. | A key hiding communication scheme for enhancing the wireless LAN security | |
| Callas et al. | ZRTP: Media path key agreement for unicast secure RTP | |
| JP5355408B2 (ja) | メッセージデータの非順次着信に対する許容度を有するメッセージ完全性のための処理方法 | |
| Degabriele | Authenticated Encryption in Theory and in Practice | |
| Doomun et al. | Modified Temporal Key Integrity Protocol for Efficient Wireless Network Security | |
| Baugher et al. | RFC 4383: The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP) | |
| Doomun et al. | LOTKIP: Low Overhead TKIP Optimization for Ad Hoc Wireless Network | |
| Jensen et al. | Cryptography project The rise and fall of WEP | |
| Roy et al. | CCM-R: Secure Counter Synchronization for IoT Wireless Link | |
| Heer et al. | RFC 7401: Host Identity Protocol Version 2 (HIPv2) | |
| Zheng | A new protocol with unbalanced RSA for authentication and key distribution in WLAN. | |
| Heer | Host Identity Protocol draft-moskowitz-hip-rfc5201-bis-02 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| B06G | Technical and formal requirements: other requirements [chapter 6.7 patent gazette] |
Free format text: SOLICITA-SE A REGULARIZACAO DA PROCURACAO, UMA VEZ QUE BASEADO NO ARTIGO 216 1O DA LPI, O DOCUMENTO DE PROCURACAO DEVE SER APRESENTADO NO ORIGINAL, TRASLADO OU FOTOCOPIA AUTENTICADA. |
|
| B06F | Objections, documents and/or translations needed after an examination request according [chapter 6.6 patent gazette] | ||
| B15K | Others concerning applications: alteration of classification |
Free format text: A CLASSIFICACAO ANTERIOR ERA: H04L 9/12 Ipc: H04L 9/12 (1990.01), H04L 9/16 (1990.01) |
|
| B06A | Patent application procedure suspended [chapter 6.1 patent gazette] | ||
| B09A | Decision: intention to grant [chapter 9.1 patent gazette] | ||
| B16A | Patent or certificate of addition of invention granted [chapter 16.1 patent gazette] |
Free format text: PRAZO DE VALIDADE: 10 (DEZ) ANOS CONTADOS A PARTIR DE 11/02/2020, OBSERVADAS AS CONDICOES LEGAIS. |