BRPI0621674A2 - método e sistema para autenticação fora de banda de fluxos de dados transmitidos através de uma rede de comunicação - Google Patents

método e sistema para autenticação fora de banda de fluxos de dados transmitidos através de uma rede de comunicação Download PDF

Info

Publication number
BRPI0621674A2
BRPI0621674A2 BRPI0621674-9A BRPI0621674A BRPI0621674A2 BR PI0621674 A2 BRPI0621674 A2 BR PI0621674A2 BR PI0621674 A BRPI0621674 A BR PI0621674A BR PI0621674 A2 BRPI0621674 A2 BR PI0621674A2
Authority
BR
Brazil
Prior art keywords
data
sender
receiver
control module
reprint
Prior art date
Application number
BRPI0621674-9A
Other languages
English (en)
Inventor
Lutus Paolo De
Corrado Moiso
Caprio Gaetano Di
Original Assignee
Telecom Italia Spa
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telecom Italia Spa filed Critical Telecom Italia Spa
Publication of BRPI0621674A2 publication Critical patent/BRPI0621674A2/pt
Publication of BRPI0621674B1 publication Critical patent/BRPI0621674B1/pt

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • H04L63/123Applying verification of the received information received data contents, e.g. message integrity
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • H04L63/126Applying verification of the received information the source of the received data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/18Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

MéTODO E SISTEMA PARA AUTENTICAçãO FORA DE BANDA DE FLUXOS DE DADOS TRANSMITIDOS ATRAVéS DE UMA REDE DE COMUNICAçãO. Um método e sistema para autenticação fora de banda de mensagens transmitidas, por exemplo como pacotes, em uma rede de comunicação (4), por meio de que um primeiro fluxo de dados é recebido por um módulo de controle de remetente (10) de um remetente (2); o primeiro fluxo de dados é transmitido através de primeiro canal, por exemplo um canal de dados não seguro (7), para um módulo de controle de receptor (11); o módulo de controle de remetente gera dados de autenticação do primeiro fluxo de dados; os dados de autenticação são transmitidos do módulo de controle de remetente (10) para o módulo de controle de receptor (11) em um segundo canal, por exemplo um canal de dados seguro (8), distinto do primeiro canal (7); e um fluxo de dados recebidos pelo módulo de controle de receptor (11) é verificado usando os dados de autenticação. Antes de enviar os dados de autenticação, o módulo de controle de remetente (10) transmite uma mensagem de controle incluindo dados de sincronização para o módulo de controle de receptor (11) através do segundo canal (8).

Description

"MÉTODO E SISTEMA PARA AUTENTICAÇÃO FORA DE BANDA DE FLUXOS DE DADOS TRANSMITIDOS ATRAVÉS DE UMA REDE DE COMUNICAÇÃO"
CAMPO TÉCNICO DA INVENÇÃO
A presente invenção relaciona-se em geral ao campo de redes de comunicação, e em particular a um método de autenticação fora de banda para transmissão em fluxo e comunicação de mensagem discreta por uma rede de dados. Mais particularmente, a invenção relaciona-se a uma solução assegurando a integridade dos dados e a autenticidade das partes de uma conexão para troca de dados usando uma rede de comunicação pública do tipo de pacote, por exemplo uma rede de Protocolo da Internet (IP). FUNDAMENTOS DA TÉCNICA
Como é conhecido, o uso de sistemas implementando redes de comunicação públicas como pacote, como a rede de IP, para troca de dados e/ou transmissão em fluxo de multimídia requer o uso de soluções de segurança capazes de assegurar a integridade dos dados e a autenticidade das partes em uma conexão.
As soluções mais usadas para implementar tais medidas de segurança provêem geralmente uma extensão dos protocolos de comunicação existentes em virtude da introdução de novas porções (por exemplo campos específicos) ou a modificação de campos já existentes dentro de protocolos de aplicativo.
Em geral, todo protocolo de aplicativo (tais como Protocolo de Acesso de Objeto simples - SOAP; Protocolo de Transferência de hipertexto HTTP; Invocação de Método Remoto de Java - RMI; Protocolo Inter-orbe da Internet - IIOP) define um ou mais campos cujo conteúdo está definido de acordo com o protocolo específico. Por exemplo, SOAP, usado na invocação de serviços da web, inclui um "cabeçalho" e um "corpo", usados para descrever o conteúdo da mensagem transmitida. Uma extensão "segura" de SOAP, chamada Segurança-WS, introduz campos específicos ambos para transmitir informação sobre a identidade do aplicativo invocador (por exemplo, no cabeçalho de SOAP) e para assegurar a integridade do pedido ou a resposta de invocação de serviço da web (contida no corpo de SOAP).
A abordagem anterior não pode ser sempre aplicada desde que não é sempre possível modificar ou estender os protocolos existentes ou os aplicativos usando-os (aplicativos de "legado") assim para adicionar informação de autenticação e integridade às mensagens transmitidas. Exemplos de protocolos que não podem ser modificados são RTP (Protocolo em Tempo Real), FTP (Protocolo de Transferência de Arquivo), Protocolo de Telnet e muitos outros protocolos do grupo Protocolo de Controle de transmissão - TCP/IP/Protocolo de Internet, desde que estes protocolos foram projetados sem levar em conta quaisquer requisitos de segurança.
Outras soluções para implementar medidas de segurança incluem usar protocolos de aplicativo que são "seguros" a um nível de transporte ou de rede (de acordo com a Interconexão de Sistema Aberto (OSI) - modelo de ISO/OSI da Organização de Padrões Internacionais (ISO)). Exemplos de tais soluções são SSL (Camada de Receptáculo Seguro) ou protocolos provendo túneis seguros, tal como IPSEC (IPSecurity). Esta abordagem provê geralmente codificação e autenticação de mensagem encapsulando o fluxo de comunicação original em mensagens do protocolo de comunicação seguro.
US 6.842.860 expõe uma solução usando um código de* autenticação de mensagem parcial, em que um código de autenticação de mensagem é aplicado só a algumas porções da mensagem.
US 2005/0228983 expõe um sistema incluindo um canal lateral seguro e um canal de legado inseguro. Em uma concretização, um cliente reedita algum do conteúdo enviado através do canal inseguro e envia a reedição através do canal seguro. O servidor então reedita o conteúdo recebido através do canal inseguro e compara a reedição que gera à recebida através do canal seguro para determinar se a mensagem postada através do canal inseguro foi alterada.
US 200370120924 expõe um método para verificar a integridade de uma mensagem transmitida entre um remetente e um recebedor. Na ponta transmitida, um valor de autenticação é gerado de uma mensagem a ser enviada. Um código de verificação é formado do valor de autenticação e uma carreira aleatória. A primeira mensagem é transferida do remetente ao recebedor por um primeiro canal, e o código de verificação é transferido por um segundo canal seguro. Na ponta de recepção, uma verificação de autenticação é formada baseada na mensagem recebida. A integridade da mensagem recebida é verificada comparando os valores de verificação na ponta de recepção.
OBJETIVO E SUMÁRIO DA INVENÇÃO
O Requerente observou que soluções usando mecanismos de segurança operando a nível de transporte ou rede provêem uma proteção de ponta a ponta, mas são menos adequadas quando mensagens transmitidas deveriam passar por uma pluralidade de nós intermediários que precisam acessar a informação transmitida. Além disso, tais soluções são desvantajosas quando é importante que nenhum atraso seja introduzido na transmissão de fluxo de informação, tal como em comunicações em tempo real, como Voz através de IP, desde que qualquer atraso poderia deteriorar a qualidade de serviço.
Além disso, métodos de autenticação incluindo uma verificação off-line sobre a autenticidade das mensagens, não pode ser estendida a tráfego em tempo real ou transmissão em fluxo, em que mensagens geradas dinamicamente são enviadas continuamente (tal como em VoiceIP).
O Requerente também observou que soluções usando mecanismos de código de autenticação de mensagem aplicados às mensagens transmitidas freqüentemente requerem uma modificação dos aplicativos de cliente e servidor para administrar as mensagens modificadas, que não é sempre possível ou desejável.
O objetivo da presente invenção é portanto prover um método e um sistema para autenticação de mensagem que seja capaz de superar as desvantagens anteriores das soluções conhecidas.
Mídia digital pode ser transmitida através de uma rede em um fluxo contínuo, um método de entrega de conteúdo conhecido como transmissão em fluxo. O processo de transmissão em fluxo começa quando um arquivo de mídia é dividido em pedaços menores que assim podem ser transferidos e executados quando cada um dos pedaços é recebido, em lugar de esperar pelo arquivo inteiro ser transferido antes que reprodução comece. Em geral, fluxo de dados se refere a uma seqüência de sinais codificados digitalmente usados para representar informação em transmissão.
Mídia contínua, tal como áudio ou vídeo em tempo real (por exemplo, estações de Rádio ou TV da Internet), é geralmente transferida (por exemplo, carregada) e executada usando tecnologias de transmissão em fluxo. Especialmente no caso de transmissão de fluxo contínua, o comprimento do fluxo de dados levando a informação pode ser a priori desconhecido ou, para os propósitos da administração da transmissão em fluxo, considerado infinito.
O Requerente entendeu que, especialmente enquanto lidando com transmissão em fluxo contínua, um mecanismo de autenticação deveria habilitar sincronização entre o remetente dos dados de informação e o receptor de forma que o receptor possa definir os dados de quais começar a verificação até mesmo se o tempo ao qual a transmissão de dados começou for desconhecido ao receptor.
De acordo com a presente invenção, é provido um método e um sistema para autenticação fora de banda de mensagens transmitidas por uma rede de comunicação, como definido nas reivindicações 1 e 14, respectivamente.
Em particular, o método usa dois canais diferentes: um primeiro, que pode ser baseado em uma rede de comunicação do tipo de pacote com características seguras limitadas, por exemplo, Internet, para transmitir dados e/ou fluxos de dados (por exemplo, multimídia e dados em tempo real); e um segundo, que é preferivelmente um canal seguro, para enviar informação utilizável para verificar a integridade e/ou a autenticidade dos dados recebidos. Em particular, o método de autenticação pode ser usado para verificar integridade de dados, isto é, para verificar que os dados enviados são os mesmo dados que são recebidos, e/ou pode ser usado para a autenticação de origem, isto é, para verificar que os dados eram enviados de fato pelo remetente reivindicado. A fim de operar corretamente em fluxos de dados, dados de sincronização são trocados entre um módulo de remetente e um módulo de receptor. Assim, os módulos de remetente e receptor podem ser sincronizados, e o módulo de receptor pode executar as operações de verificação em tempo real.
BREVE DESCRIÇÃO DOS DESENHOS
Para um entendimento melhor da presente invenção,concretizações preferidas, que são planejadas puramente como exemplos e não são para serem interpretadas como limitantes, serão descritas agora com referência aos desenhos anexos, em que:
Figura 1 mostra um diagrama de bloco de um sistema de autenticação de acordo com uma primeira concretização da presente invenção;
Figura 2 mostra um diagrama de bloco de um sistema de autenticação de acordo com uma segunda concretização da presente invenção;
Figura 3 é um diagrama de tempo de uma transmissão entre um remetente e um receptor; Figuras 4a, 4b e 4c são fluxogramas de uma concretização do método de autenticação de acordo com a presente invenção; e
Figura 5 descreve um possível fluxo entre um remetente e um receptor, de acordo com uma concretização do presente método.
DESCRIÇÃO DETALHADA DE CONCRETIZAÇÕES PREFERIDAS DA INVENÇÃO
Figura 1 mostra um sistema 1 para autenticar dados transmitidos por um remetente 2 para um receptor 3 por uma rede pública 4, de acordo com uma primeira concretização da presente invenção. Na concretização da Figura 1 ("solução de borda"), o remetente 2 e o receptor 3 são dois nós de comunicação dentro de uma LAN (Rede local) 5, 6, respectivamente. Por exemplo, o remetente 2 e o receptor 3 podem estar incluídos em uma rede de extranet empresarial formada por LANs confiadas diferentes, controladas por uma única unidade de controle central e conectadas entre si por uma rede de área extensa (WAN), por exemplo, a Internet.
Em particular, o remetente 2 e o receptor 3 podem ser por exemplo, um computador, um PDA (Assistente Digital Pessoal), um laptop, um computador portátil com capacidade sem fios, um telefone de VoIP, uma câmera da Web ou um telefone de IP sem fios.
A rede pública 4, por exemplo a Internet, inclui um primeiro canal 7 e um segundo canal 8. Primeiro e segundo canais 7 e 8 são canais de dados lógicos não correspondendo necessariamente a canais físicos diferentes desde que um canal físico pode ser compartilhado por mais canais lógicos.
Exemplos de canais físicos podem ser cabos ou canais de rádio no caso de comunicação móvel, tais como Canais de Dados de Pacote (PDCH) em GPRS, cada canal estando associado com um intervalo de tempo de um quadro de TDMA.
Primeiro canal 7 é usado para transmitir dados, preferivelmente dados de pacote, tanto como mensagens discretas ou como fluxos de dados (por exemplo, multimídia e dados em tempo real) e tem características de segurança não especificadas (por exemplo, limitadas). Segundo canal 8 é preferivelmente um canal seguro e é implementado de qualquer modo conhecido para transmitir dados de controle de um modo seguro. Protocolos de segurança que operam a nível de aplicativo, de transporte ou de rede, por exemplo podem ser implementados por SSL (Camada de Receptáculo Seguro) ou IPSEC (IPSecurity) pode ser empregado no segundo canal 8.
Cada nó de comunicação 5 e 6 inclui um módulo de controle 10 e 11, respectivamente, conectado ao remetente 2 e, respectivamente, ao receptor 3.
Módulo de controle de remetente 10 é arranjado a jusante do remetente 2 e inclui uma memória temporária de dados de remetente 12 e um 15 processador de remetente 13. Memória temporária de dados de remetente 12, por exemplo uma fila de FIFO, está conectada ao canal de dados 7 e armazena os dados enviados pelo remetente 2. Processador de remetente 13 está conectado e adquire dados da memória temporária de remetente 12 e gera dados de controle enviados pelo canal seguro 8.
Módulo de controle de receptor 11 está arranjado a montante do receptor 3 e inclui uma memória temporária de dados de receptor 18, uma memória temporária de controle de receptor 19 e um processador de receptor 20. Memória temporária de dados de receptor 18, por exemplo uma fila de FIFO, está conectada ao canal de dados 7 e armazena os dados recebidos no canal de dados 7. Memória temporária de controle de receptor 19, por exemplo uma fila de FIFO, está conectada ao canal seguro 8 e armazena a informação de controle recebida no canal seguro 8. Memória temporária de controle de receptor 19 pode ser um componente físico ou pode ser implementada e ser inerente ao protocolo usado. Por exemplo, protocolos de TLS (Segurança de camada de Transporte) e IPSEC (IPSecurity) têm uma memória temporária funcionando de um modo seqüencial, que pode implementar a memória temporária de controle de receptor 19.
Processador de receptor 20 está conectado e adquire dados de ambas a memória temporária de dados de receptor 18 e a memória temporária de controle de receptor 19 e executa as operações necessárias para a sincronização com o módulo de controle de remetente 10, como também as operações para verificar a autenticidade dos dados transmitidos em canal de dados 7, como explicado em detalhes em seguida, com referência às Figuras 3, 4a, 4b e 4c. O processador de receptor 20 também pode estar conectado ao receptor 3 para enviar a ele mensagens de erro, de uma maneira não mostrada. Em alternativa, mensagens de erro podem ser enviadas a um servidor de administração (não mostrado) que pode tomar medidas adequadas.
O módulo de controle de remetente IOeo módulo de controle de receptor 11 pode ser implementado como nós físicos ou como aplicativo de software que são executados por recursos já existentes das LANs 5, 6 ou da rede 4.
Figura 2 mostra uma concretização diferente, em que o módulo de controle de remetente 10 e o módulo de controle de receptor 11 estão arranjados dentro da rede de comunicação de transporte e interconexão (coluna vertebral). Por exemplo, um operador de telecomunicação pode oferecer um serviço de autenticação e integridade para fluxos de dados, inserindo os módulos de controle de remetente e receptor 10, 11 dentro de sua infra-estrutura. Por exemplo, o remetente 2 e receptor 3 podem ser telefones de VoIP conectados à Internet por redes de acesso de ADSL (Linha de Assinante Digital Assimétrica).
Em detalhes, o remetente 2 e o receptor 3 são dois nós de comunicação conectados à rede pública 4; o processador 13 de módulo de controle de remetente 10 está conectado a um servidor de identidade 26; e processador 20 dentro do módulo de controle de receptor 11 está conectado a um servidor de registro/contabilidade 27.
O servidor de identidade 26 permite ao processador 13 do módulo de controle de remetente identificar o remetente 2 que está 5 gerando o fluxo de dados, por exemplo mapeando o endereço de IP usado para transmitir pacotes em uma rede de acesso de ADSL (Linha de Assinante Digital Assimétrica). O servidor de registro/contabilidade 27 tem o objetivo de levar em conta os vários eventos, tais como os erros de autenticação e os dados de contabilidade de processamento. 10 O módulo de controle de remetente e o módulo de controle
de receptor 11 podem ter função operacional semelhante àquelas dos mesmos elementos na Figura 1; assim, a operação dos dois sistemas será descrita em seguida para ambos os sistemas.
Na descrição seguinte, é assumido que o remetente 2 começa uma transmissão para o receptor 3 a um certo tempo inicial e envia um fluxo de dados de um tal comprimento que o remetente 2 e o receptor 3 sejam comprometidos simultaneamente na comunicação, isto é, para uma porção grande da transferência da informação do remetente para o receptor, o receptor recebe os dados enquanto o remetente ainda está transmitindo. Isto implica que o remetente 2 começa a transmissão a um tempo não conhecido ao receptor 3 e o receptor 3 começa a receber os dados transmitidos quando o remetente 2 ainda está transmitindo. Tal situação é descrita na Figura 3, em que a tempo tO o remetente 2 começa a transmissão de um fluxo de dados incluindo bytes [a1, a2, ..., a1, ..., aM]; a tempo t1 > tO, o receptor 3 começa a receber um fluxo de dados incluindo bytes [bi, b2,..., bj, ..., bN]; a tempo t2 > t1, o remetente 2 termina a transmissão de bytes [a1, a2, ..., a1, ..., aM] (isto é, depois de enviar byte aM); e a tempo t3 > t2, o último byte bN é recebido pelo receptor 3.
O presente método de autenticação é visado em verificar que [a1, a2, ..., aM]; = [bi, b2, bj, ..., bN], mas para vários erros que são permitidos pelo sistema (por exemplo, perda ou deterioração de um número limitado de bytes definidos pelo sistema ser permissível). Tais erros podem ser detectados e sinalizados pelo método de autenticação. Para este fim, o fluxo de dados gerado pelo remetente 2 é transmitido inalterado pelo canal de dados 7.
Além disso, o módulo de controle de remetente divide o fluxo enviado pelo remetente 2 em uma pluralidade de blocos As = [as, ..., as+L], cada bloco incluindo L unidades de mensagem, por exemplo quatro 10 unidades de mensagem, calcula um valor de autenticação para cada bloco e envia o valor de autenticação pelo canal seguro 8 para o módulo de controle de receptor 11. Aqui, o termo "unidades de mensagem" se refere, em geral, a bytes; porém, em transmissões como pacote, pode se referir a pacotes. Por causa de simplicidade, na descrição seguinte, referência será feita a byte, a menos que especificado diferentemente.
O valor de autenticação de cada bloco é calculado usando uma função de reedição H. Como conhecido, uma função de reedição é uma transformação que gera uma carreira de tamanho fixo que é "difícil de inverter" (quer dizer, dado um valor de reedição h, é computacionalmente impossível achar uma entrada χ tal que H(x) = h) e é resistente à colisão (quer dizer, é computacionalmente impossível achar duas entradas x, y, tal que H(x) = H(y)).
O módulo de controle de receptor 11 divide o fluxo recebido pelo canal de dados 7 em blocos, calcula um valor de autenticação próprio dos blocos recebidos e compara o valor de autenticação próprio com o valor de autenticação recebido por canal seguro 8 para verificar a integridade dos blocos recebidos.
A fim de permitir transmissão de fluxo de dados de comprimento desconhecido, enviado a um momento desconhecido pelo remetente para o receptor, de acordo com um aspecto da invenção, os módulos de controle de remetente e receptor 10, 11 executam uma fase de sincronização, como abaixo discutido em detalhes em seguida, com referência ao fluxograma das Figuras 4a-4c, como também às Figuras 1, 2. Em particular, Figura 4a se refere às operações executadas pelo módulo de controle de remetente 10 e Figuras 4b e 4c se referem às operações executadas pelo módulo de controle de receptor 11.
Na Figura 4a, o módulo de controle de remetente é ativado assim que se torna ciente da transmissão de um fluxo de dados [al5 a2, ..., aÍ5 10 ..., aM], etapa 30; então, o fluxo de dados é remetido, inalterado, no canal de dados 7 e é duplicado simultaneamente e carregado na memória temporária de remetente 12. Na alternativa, o fluxo de dados pode ser copiado na memória temporária de remetente 12 em qualquer momento adequado. Depois da acumulação de m bytes, o processador de remetente 13 extrai um subseqüência de k bytes consecutivos Pl = [ak,..., ak+p], chamado um padrão, com k+p < m, em que ρ é um número fixo independente de m (por exemplo, ρ = 1024), etapa 32.
O padrão Pl é selecionado preferivelmente assim para minimizar a probabilidade que o padrão Pl seja igual a outra subseqüência do 20 fluxo. Seleção do padrão também depende do tipo de tráfego; em particular, o padrão pode ser uma seqüência de dados/byte cujo comprimento reduz a probabilidade de uma colisão. De acordo com uma concretização preferida, o processador de remetente 13 extrai uma seqüência de bytes de tamanho relativamente grande (por exemplo, 8 pacotes de 500 bytes) dos primeiros blocos a serem verificados pelo sistema de autenticação, assim há uma probabilidade muito pequena de colisão.
O processador de remetente também pode verificar que o padrão selecionado P1 não é só formado de seqüências de bytes padrão, por exemplo, de uma carreira representando uma palavra de um idioma natural ou similar.
Então, etapa 34, o processador de remetente 13 gera uma primeira mensagem de controle contendo dados de sincronização II, uma função de reedição Heo comprimento L dos blocos. Em particular, os dados de sincronização II podem ser o mesmo padrão selecionado Pl ou qualquer informação que identifica univocamente o padrão PL Por exemplo, em protocolos que associam um número às mensagens dentro de um fluxo de dados, tal como o RTP - Protocolo em Tempo Real - que provê um número de seqüência, os dados de sincronização Il podem ser o número de seqüência de 10 protocolo.
Em uma concretização, a mensagem de controle pode incluir um comando de fim, por exemplo instruindo o controle de módulo de receptor 11 para interromper o processo de autenticação depois de um dado número N de blocos ou depois de um dado tempo (por exemplo, depois de dez minutos) 15 ou ao receber um comando ou informação específica.
A primeira mensagem de controle [II, H, L] é então enviada sobre o canal seguro 8, etapa 38. Em particular, a primeira mensagem de controle pode ser transmitida usando quaisquer dos sistemas bem conhecidos (por exemplo protocolo de TLS - Segurança de camada de Transporte - ou IPSEC).
Além disso, o fluxo de dados gerado pelo remetente 2 é dividido em blocos As = [as, ..., as+L] tendo o comprimento L enviado com a primeira mensagem de controle e cada bloco é acumulado na memória temporária de remetente 12.
Assim que um bloco As = [as, ..., as+L] é acumulado na memória temporária de remetente 12, o processador de remetente 13 o carrega, etapa 40, calcula o valor de reedição hs usando a função de reedição H enviada com a primeira mensagem de controle, etapa 42, e envia uma mensagem de autenticação no canal seguro 8, etapa 44. Em particular, depois de enviar a primeira mensagem de controle, o processador de remetente 13 adquire o bloco [ak+p+i,ak+p+L], seguindo o padrão selecionado.
De acordo com uma primeira concretização, a mensagem de autenticação inclui o valor de reedição calculado hs. De acordo com uma concretização diferente, o processador de remetente 13 envia o valor de reedição hs junto com um símbolo de autenticação.
O processo de adquirir um bloco, enquanto calcular o valor de reedição disso e enviar a mensagem de autenticação no canal seguro 8 (etapas 40-44) pode ser repetido para o fluxo inteiro, assim gerando um fluxo de controle [hs, hs+L, hs+2L,..].
As etapas descritas são então repetidas até que a transmissão do fluxo de dados original termine (saída sim da etapa 46) ou até que o processador de remetente 13 receba um pedido de re-sincronização do processador de receptor 20 (saída sim da etapa 48). No caso anterior, o processador de remetente 13 recebe uma segunda mensagem de controle semelhante à primeira mensagem de controle e incluindo novos dados de sincronização 12, referidos a um novo padrão de sincronização P2, a função de reedição H, e o comprimento L. Então, o processador de remetente 13 executa re-sincronização, identificando, na memória temporária de remetente 12, o bloco Bz seguindo padrão P2, bloco 50 e retoma o procedimento de transmissão da etapa 42, calculando o valor de reedição do bloco Bz.
Figura 4b mostra o fluxograma das operações executadas pelo processador de receptor 20, assim que o módulo de controle de receptor 11 começa a receber uma transmissão. Em particular, o módulo de receptor 11 pode ser ativado assim que os primeiros bytes de um fluxo de dados [bi, b2, ..., bN] é recebido do canal de dados 7.
Quando o módulo de receptor é ativado, o fluxo de dados recebido é acumulado na memória temporária de dados de receptor 18. Na prática, de acordo com uma concretização, o fluxo de dados recebido de canal 7 e dirigido ao receptor 3 é duplicado e o fluxo de dados duplicado é armazenado na memória temporária de dados recebidos 18.
Assim que a mensagem de controle [II, H, L] é recebida pela memória temporária de controle de receptor 19 de canal 8, o processador de 5 receptor 20 a carrega, etapa 58; depois disso, o fluxo de controle [hs, hs+L, hs+2L, ..·], é acumulado na memória temporária de controle de receptor 19.
Depois de receber a primeira mensagem de controle, o processador de receptor 20 carrega as subseqüências Bi = [bi? ..., bi+L], com 1 < i < h-L e bh último byte recebido, etapa 60, e compara a subseqüência 10 carregada com o padrão PI, etapa 62. Na alternativa, se os dados de sincronização recebidos Il forem um número de seqüência, como provido para o protocolo usado, o processador de receptor 20 procura um bloco recebido tendo o mesmo número de seqüência.
As etapas descritas são repetidas até que o processador de 15 receptor 20 ache uma subseqüência Bq = [bq,..., bq+L] que é igual ao padrão Pl (ou cujo número de seqüência de protocolo é igual aos dados de sincronização II), saída "sim" da etapa 62. Agora, o módulo de receptor 11 está sincronizado com o módulo de remetente 10.
Depois disso, o processador de receptor 20 carrega o bloco Bs 20 = [bs,..., bs+L] seguindo o usado para sincronização da memória temporária de dados de receptor 18, etapa 64, calcula o valor de reedição fs disso pela função de reedição recebida H, etapa 66, carrega o valor de reedição recebido hs da memória temporária de controle de receptor 19, etapa 68, e compara fs com hs, etapa 70. Se as mensagens de controle contiverem um símbolo de autenticação, este símbolo é verificado por meio padrão, por exemplo usando assinatura digital simétrica baseada em segredos compartilhados pelo módulo de remetente 10 e pelo módulo de receptor 11 (por exemplo, de acordo com as indicações da Assinatura Digital de XML padrão).
Se o resultado da comparação for positivo, isto é se fs = hs, segue que [bs, ..., bs+L] = [as, as+L], e o bloco recebido Bs é autenticado. Portanto, o receptor está assegurado que o bloco recebido foi enviado pelo remetente assumido (autenticidade das partes) e não foi modificado durante a transmissão (integridade da mensagem).
Se as verificações na etapa 70 derem resultados positivos, o procedimento anterior (etapas 64-70) continua com os blocos seguintes Bs até o fim do fluxo de dados (saída sim da etapa 72), se não (saída não da etapa 70), um procedimento de erro é implementado (etapa 74).
A situação de erro pode ser administrada de modos diferentes, levando em conta o tipo de erro. De acordo com uma primeira solução, o receptor pode apenas enviar uma mensagem de sinalização de erro ambos ao servidor de registro/contabilidade 27 (na concretização da Figura 2) e ao módulo de remetente 10, sem interromper a transmissão. De acordo com uma segunda solução, o sistema pode aceitar vários erros antes de parar a transmissão. De acordo com uma terceira solução, o sistema pode interromper imediatamente a transmissão.
A primeira e segunda soluções podem ser vantajosas quando o canal de transmissão usado é conhecido estar defeituoso. Este é o caso por exemplo de redes com bandas de transmissão muito baixas ou de redes sem fios que são estruturalmente inseguras (por exemplo, rede de IPv4 através de HF). Neste exemplo, muitos protocolos de comunicação, por exemplo todos os protocolos baseados em TCP e SIP (Protocolo de Iniciação de Sessão), provêem retransmitir automaticamente as mensagens perdidas. Por outro lado, quando retransmissão não é provida (por exemplo, de acordo com Protocolo de Datagrama de Usuário - UDP), o sistema pode incluir uma tolerância a erro. Por exemplo, se a rede de comunicação for conhecida perder uma média de 5% dos pacotes de IP enviados, o sistema pode aceitar 5% de erros de autenticação, assumindo que tais erros são devido a erros de transmissão e não a problemas de segurança. Além disso se, durante a transmissão, o módulo de receptor 11 perder sua sincronização com o módulo de transmissor 10, um procedimento de re-sincronização pode ser começado.
Figura 4c descreve o fluxograma de um possível procedimento de administração de erro, com reinicio de sincronização.
Em particular, inicialmente, o processador de receptor 20 gera uma mensagem de erro para seu servidor de registro/contabilidade 27, para a concretização da Figura 2 e/ou para o módulo de remetente 10, etapa 80. Então, o tipo de erro é verificado, etapa 82, para descobrir se o erro era devido à perda de um ou mais pacotes ou a um dano nos dados recebidos. Em particular, se a transmissão prover um número de seqüência, o número de seqüência dos pacotes recebidos pode ser verificado; se a transmissão não prover números de seqüência, os valores de reedição dos blocos seguintes são verificados.
Se o erro for devido à perda de pacotes, saída "sim" da etapa 82, o processador de receptor 20 envia um pedido de re-sincronização, etapa 84. Em particular, o pedido de re-sincronização inclui dados de controle 12 para um novo padrão de sincronização P2, a função de reedição Heo comprimento L. Então, o processador de receptor 20 volta à etapa 64 da Figura 4b, para verificar um bloco Bs seguindo o usado para gerar os dados de controle 12.
Se o erro não for devido à perda de pacotes, por exemplo, devido a um ataque à integridade de dados, saída "não" da etapa 82, re-sincronização geralmente não é necessária, e o processador de receptor 20 pode prosseguir e verificar o bloco seguinte, etapa 86. Verificação é feita como acima descrito, calculando o valor de reedição e o comparando com o valor de reedição seguinte recebido no canal seguro 8. Se o resultado da verificação da etapa 86 for positivo, saída "sim" da etapa 88, então o fluxo padrão é retomado da etapa 64 da Figura 4b; se não, saída "não" da etapa 88, o processador de receptor 20 envia uma mensagem de erro para ambos seu servidor 27, para a concretização da Figura 2, e/ou para o módulo de remetente 10, etapa 90; então bloqueia os pacotes entrando no módulo de receptor 11. O verificação dos blocos seguintes pode ser repetida, por exemplo, algumas vezes, baseado na porcentagem de erros aceitos pelo sistema; além disso, uma mensagem de erro também pode ser enviada depois da primeira detecção de um erro (antes de verificar uma mensagem seguinte na etapa 86).
Figura 5 mostra o fluxo de dados trocados em uma comunicação baseada em um protocolo de RTP, em que cada mensagem 10 (pacote) tem um próprio número de seqüência. Assim, aqui o comprimento L enviado pelo módulo de remetente 10 para o módulo de receptor 11 se refere a pacotes. A transmissão pode considerar as imagens captadas por uma câmera de vídeo de vigilância, como enviadas através de uma rede de IP para um centro de controle.
Na Figura 5, a tempo tO, o remetente 2 envia um primeiro pacote (mensagem tendo número de seqüência 2), que ativa o módulo de remetente 10. O primeiro pacote assim não é autenticado. Este pacote (como também os pacotes transmitidos sucessivos) é recebido pelo módulo de receptor 11 com um atraso At.
Depois de ter recebido o primeiro pacote, o processador de remetente 13 ativa o procedimento de autenticação e envia uma primeira mensagem de controle C1=<I,L,H> no canal seguro 8. No exemplo, os dados de sincronização I são o número de seqüência da mensagem de RTP (aqui 2), L=4, e a função de reedição é H=SHA-256. Além disso, o módulo de remetente 10 começa a carregar sua memória temporária 12 com os pacotes na ordem que são enviados e, depois de carregar quatro pacotes (primeiro bloco), calcula o valor de reedição hl para o primeiro bloco. Então, o processador de remetente 13 envia o valor de reedição hl no canal seguro 8.
Enquanto isso, o módulo de receptor 11 recebeu a primeira mensagem de controle Cl e começa a receber e carregar sua memória temporária de dados 18 com os pacotes recebidos. Assim que o módulo de receptor 11 recebeu o número comunicado de pacotes formando um bloco (aqui, quatro), o processador de receptor 20 calcula a função de reedição disso, hl'. Então, o processador de receptor 20 compara hl e hl'. Se eles casarem, a integridade de pacotes 3-6 é verificada positivamente.
O processo é repetido para pacotes 7-10, 11-14, ..., até o fim do fluxo.
O sistema e método como descritos têm as vantagens seguintes.
O remetente e o receptor não requerem nenhuma adaptação, desde que o fluxo de dados original não é modificado, por esse meio permitindo autenticação de dados também em aplicativos de legado.
O método pode ser aplicado a todos os protocolos de comunicação do tipo de pacote, ambos para fluxos de dados discretos e contínuos.
Desde que os módulos de controle 10, 11 estão separados ambos do remetente e do receptor, eles podem ser implementados de um modo modular e flexível, como componentes adicionais, de acordo com a política de segurança particular.
A solução descrita não introduz nenhum atraso ao fluxo de dados transmitidos, como a transmissão dos dados de autenticação é efetuada em um canal paralelo, sem interferir com a elaboração do fluxo de dados original. Este aspecto é particularmente importante para transmissão em tempo real, que não pode ser autenticada por métodos requerendo a modificação do fluxo original.
Finalmente, está claro que numerosas modificações e variantes podem ser feitas ao presente método e sistema, tudo caindo dentro da extensão da invenção, como definida nas reivindicações anexas. Em particular, a mensagem de sincronização trocada entre o módulo de remetente IOeo módulo de receptor 11 pode não conter a função de reedição Heo comprimento L, se o sistema prover uma única função de reedição H e comprimento L (por exemplo, eles estão conectados por fios no sistema), e/ou podem conter informação adicional, tal como um identificador de módulo de remetente e o símbolo de autenticação, para provar sua identidade.
Além disso, os dados de sincronização I podem incluir dados diferentes, por exemplo porções não contíguas de um padrão, uma informação de identificação de remetente e similar.
O procedimento de erro também pode ser diferente do descrito, e inclui interrupção imediata da transmissão, pedidos de reenviar pacotes perdidos, assim por diante.
Se o fluxo de dados não contiver um número alto de dados, autenticação pode ser executada dado por dado, sem dividir o fluxo de dados em blocos.

Claims (22)

1. Método para autenticação fora de banda de fluxos de dados transmitidos através de uma rede de comunicação (4) incluindo um remetente (2); um receptor (3); um módulo de controle de remetente (10) e um módulo de controle de receptor (11), caracterizado pelo fato de incluir as etapas de: transmitir um primeiro fluxo de dados através de um primeiro canal (7) conectando o remetente (2) com o receptor (3); receber, por dito módulo de controle de remetente (10), dito primeiro fluxo de dados de dito remetente (2); gerar dados de autenticação de dito primeiro fluxo de dados por dito módulo de controle de remetente (10); transmitir ditos dados de autenticação do módulo de controle de remetente (10) para o módulo de controle de receptor (11) através de um segundo canal (8) conectando o módulo de controle de remetente (10) com o módulo de controle de receptor (11); e verificar autenticidade de um segundo fluxo de dados recebidos através de dito primeiro canal (7) por dito módulo de controle de receptor (11) usando ditos dados de autenticação, adicionalmente incluir a etapa de trocar uma mensagem de controle incluindo dados de sincronização entre o módulo de controle de remetente (10) e o módulo de controle de receptor (11) através de dito segundo canal (8).
2. Método de acordo com a reivindicação 1, caracterizado pelo fato de que a etapa de trocar uma mensagem de controle é executada antes de transmitir ditos dados de autenticação.
3. Método de acordo com a reivindicação 1 ou 2, caracterizado pelo fato de que a etapa de trocar uma mensagem de controle inclui uma etapa de extração, em que o módulo de remetente 10 extrai um padrão de dito primeiro fluxo de dados, ditos dados de sincronização identificando univocamente dito padrão extraído.
4. Método de acordo com a reivindicação 3, caracterizado pelo fato de que a etapa de verificar a autenticidade do segundo fluxo de dados inclui uma etapa de sincronização, em que o módulo de controle de receptor (11) procura dito padrão extraído em dito segundo fluxo de dados na base de ditos dados de sincronização.
5. Método de acordo com a reivindicação 3 ou 4, caracterizado pelo fato de que os ditos dados de sincronização incluem dito padrão extraído ou um número de seqüência de pacote.
6. Método de acordo com quaisquer das reivindicações 3-5, caracterizado pelo fato de que a etapa de gerar dados de autenticação inclui a etapa de calcular, por dito módulo de controle de remetente (10), primeiros valores de reedição de primeiras porções de dito primeiro fluxo de dados seguindo dito padrão extraído, e a etapa de transmitir dados de autenticação 15 inclui a etapa de transmitir ditos valores de reedição primeiro através de dito segundo canal (8), e em que a etapa de verificar autenticidade do segundo fluxo de dados inclui carregar no módulo de controle de receptor (11) o segundo fluxo de dados, calcular segundos valores de reedição para segundas porções do segundo fluxo de dados e comparar ditos segundos valores de reedição com os primeiros valores de reedição recebidos.
7. Método de acordo com a reivindicação 6, caracterizado pelo fato de que a dita mensagem de controle também inclui uma função de reedição, e em que dito primeiro e segundo valores de reedição são calculados por dito módulo de controle de remetente (13) e dito módulo de controle de receptor (11) usando dita função de reedição.
8. Método de acordo com quaisquer das reivindicações 3-7, caracterizado pelo fato de que a etapa de receber um primeiro fluxo de dados inclui dividir dito primeiro fluxo de dados em primeiros blocos de um comprimento fixo; a etapa de gerar dados de autenticação inclui calcular valores de reedição de ditos primeiros blocos; a etapa de verificar autenticidade do fluxo recebido de dados inclui dividir o segundo fluxo de dados em segundos blocos de um comprimento fixo, calcular valores de reedição de ditos segundos blocos, e comparar ditos dados de autenticação com ditos valores de reedição de ditos segundos blocos.
9. Método de acordo com a reivindicação 8, caracterizado pelo fato de que a etapa de receber um primeiro fluxo de dados adicionalmente inclui acumular ditos primeiros blocos em uma memória temporária de remetente (12); a etapa de gerar dados de autenticação inclui carregar um bloco de ditos primeiros blocos de dita memória temporária de remetente (12); a etapa de verificar autenticidade do fluxo recebido de dados inclui acumular ditos segundos blocos em uma memória temporária de dados de receptor (18), acumular ditos dados de autenticação em uma memória temporária de controle de receptor (19) e carregar um bloco de ditos segundos blocos de dita memória temporária de dados de receptor (18).
10. Método de acordo com quaisquer das reivindicações 1-9, caracterizado pelo fato de que a dita mensagem de controle adicionalmente inclui uma informação de comprimento de ditos padrões.
11. Método de acordo com quaisquer das reivindicações 1-10, caracterizado pelo fato de que se durante dita etapa de verificar autenticidade do segundo fluxo de dados, o módulo de controle de receptor (11) detectar um erro entre ditos dados de autenticação e o segundo fluxo de dados, o módulo de controle de receptor (11) envia um pedido de re-sincronização para dito módulo de controle de remetente (10).
12. Método de acordo com a reivindicação 11, caracterizado pelo fato de que o dito pedido de re-sincronização inclui segundos dados de sincronização identificando univocamente um segundo padrão extraído do segundo fluxo de dados.
13. Método de acordo com a reivindicação 12, caracterizado pelo fato de que os segundos dados de sincronização incluem um valor de reedição de dito segundo padrão extraído do segundo fluxo de dados.
14. Método de acordo com quaisquer das reivindicações 1-13, caracterizado pelo fato de que o dito segundo canal (8) é um canal seguro.
15. Sistema para autenticação fora de banda de fluxos de dados transmitidos através de uma rede de comunicação (4), caracterizado pelo fato de incluir: um módulo de controle de remetente (10) configurado para receber um primeiro fluxo de dados de um remetente (2) e gerar dados de autenticação; um módulo de controle de receptor (11) configurado para verificar ditos dados de autenticação; um primeiro canal (7) conectando dito remetente (2) a dito receptor (3) configurado para transmitir dito primeiro fluxo de dados de dito 20 remetente para dito receptor; um segundo canal (8) conectando dito módulo de remetente (10) e dito módulo de receptor (11) configurado para transmitir ditos dados de autenticação; em que dito módulo de controle de remetente (10) e dito módulo de controle de receptor (11) incluem unidades de sincronização respectivas (12, 13; 18-20) trocando mensagem de controle incluindo dados de sincronização.
16. Sistema de acordo com a reivindicação 15, caracterizado pelo fato de que a dita unidade de sincronização de dito módulo de controle de remetente (10) inclui uma memória temporária de remetente (12) configurada para carregar primeiras porções do primeiro fluxo de dados e um processador de remetente (13) configurado para extrair um padrão (Pl) de ditas primeiras porções e transmitir dita mensagem de controle para dito 5 módulo de controle de receptor (11) através de dito segundo canal (8), ditos dados de sincronização (Il) identificando univocamente dito padrão extraído (PI).
17. Sistema de acordo com a reivindicação 16, caracterizado pelo fato de que a dita unidade de sincronização de dito módulo de controle de receptor (11) inclui uma memória temporária de dados de receptor (18) configurada para carregar segundas porções de um segundo fluxo de dados recebidos através de dito primeiro canal (7) e um processador de receptor (20) configurado para receber dita mensagem de controle de dito segundo canal (8) e para receber ditas segundas porções de dita memória temporária de dados de receptor (18), em que dito processador de receptor (20) é configurado para procurar dito padrão extraído de ditas segundas porções na base de ditos dados de sincronização.
18. Sistema de acordo com a reivindicação 16 ou 17, caracterizado pelo fato de que dito dados de sincronização incluem dito padrão extraído ou um número de seqüência de pacote.
19. Sistema de acordo com a reivindicação 17 ou 18, caracterizado pelo fato de que dito processador de remetente (13) inclui um primeiro calculador (42) configurado para calcular primeiros valores de reedição de ditas primeiras porções seguindo dita porção extraída e um elemento de transmissor (44) configurado para transmitir ditos primeiros valores de reedição em dito canal seguro (8) e dito módulo de receptor (11) inclui uma memória temporária de controle de receptor (19) conectada a dito processador de receptor (20) e dito canal seguro (8) e configurada para carregar ditos primeiros valores de reedição, dito processador de receptor (20) incluindo um segundo calculador (66) configurado para calcular segundos valores de reedição para ditas segundas porções e um comparador (70) configurado para comparar os primeiros valores de reedição com os segundos valores de reedição.
20. Sistema de acordo com a reivindicação 19, caracterizado pelo fato de que a dita mensagem de controle também inclui uma função de reedição e em que dito processador de remetente (13) e dito processador de receptor (20) são configurados para calcular dito primeiro e segundo valores de reedição usando dita função de reedição.
21. Sistema de acordo com quaisquer das reivindicações 15-20, caracterizado pelo fato de que o dito módulo de controle de remetente (10) faz parte de uma primeira rede local (5) incluindo dito remetente (2) e dito módulo de controle de receptor (11) faz parte de uma segunda rede local (6) incluindo dito receptor (3).
22. Sistema de acordo com quaisquer das reivindicações 15-20, caracterizado pelo fato de que o dito módulo de controle de remetente (10) e dito módulo de controle de receptor (11) fazem parte de dita rede de comunicação (4).
BRPI0621674-9A 2006-05-15 2006-05-15 Método e sistema para autenticação fora de banda de fluxos de dados transmitidos através de uma rede de comunicação BRPI0621674B1 (pt)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2006/004555 WO2007131523A1 (en) 2006-05-15 2006-05-15 Out-of-band authentication method and system for communication over a data network

Publications (2)

Publication Number Publication Date
BRPI0621674A2 true BRPI0621674A2 (pt) 2012-07-10
BRPI0621674B1 BRPI0621674B1 (pt) 2019-05-28

Family

ID=37691759

Family Applications (1)

Application Number Title Priority Date Filing Date
BRPI0621674-9A BRPI0621674B1 (pt) 2006-05-15 2006-05-15 Método e sistema para autenticação fora de banda de fluxos de dados transmitidos através de uma rede de comunicação

Country Status (6)

Country Link
US (1) US8572382B2 (pt)
EP (1) EP2020136B1 (pt)
CN (1) CN101473622B (pt)
AT (1) ATE540516T1 (pt)
BR (1) BRPI0621674B1 (pt)
WO (1) WO2007131523A1 (pt)

Families Citing this family (42)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8131998B2 (en) * 2007-03-05 2012-03-06 George Mason Intellectual Properties, Inc. Transparent authentication of continuous data streams
US20110225240A1 (en) * 2009-10-20 2011-09-15 Truong Cong Thang Method and apparatus for managing transaction of iptv
US8447970B2 (en) * 2010-02-09 2013-05-21 Microsoft Corporation Securing out-of-band messages
WO2011162648A1 (en) * 2010-06-21 2011-12-29 Saab Ab A method and arrangement for recording a media stream
DE102010033229A1 (de) * 2010-08-03 2012-02-09 Siemens Aktiengesellschaft Verfahren und System zur manipulationssicheren Übertragung von Steuerdaten
DE102011056038B4 (de) * 2011-12-05 2015-06-03 Hochschule Darmstadt Authentifikation von Teilnehmern eines Telefoniedienstes
US9635004B2 (en) 2012-04-25 2017-04-25 Futurewei Technologies, Inc. Systems and methods for segment integrity and authenticity for adaptive streaming
US8316232B1 (en) * 2012-07-18 2012-11-20 Dj Inventions, Llc Cryptographic manager tool system
CN103888334B (zh) * 2012-12-20 2017-12-08 兴唐通信科技有限公司 IP分组网中VoIP多层加密方法及系统
US8972296B2 (en) * 2012-12-31 2015-03-03 Ebay Inc. Dongle facilitated wireless consumer payments
US9019992B2 (en) 2013-01-08 2015-04-28 Tangome, Inc. Joint retransmission and frame synchronization for error resilience control
CN103152260B (zh) * 2013-02-21 2019-02-15 中兴通讯股份有限公司 报文转发系统、方法及装置
US9251384B1 (en) * 2013-03-07 2016-02-02 Amazon Technologies, Inc. Trusted peripheral device for a host in a shared electronic environment
WO2014143025A1 (en) * 2013-03-15 2014-09-18 Hewlett-Packard Development Company, L.P. Secure path determination between devices
FR3004881B1 (fr) 2013-04-19 2015-04-17 Kolor Procede de generation d'un flux video de sortie a partir d'un flux video large champ
US10263783B2 (en) * 2013-08-23 2019-04-16 Nec Corporation Method and system for authenticating a data stream
CN103580956A (zh) * 2013-11-05 2014-02-12 北京锐安科技有限公司 一种检测数据完整性的方法及装置
US9288189B2 (en) * 2014-01-06 2016-03-15 International Business Machines Corporation Retrieving both sensitive and non-sensitive content in a secure manner
US9450757B2 (en) * 2014-05-07 2016-09-20 Oxcept Limited Method and device for communication security
CN104184593A (zh) * 2014-09-16 2014-12-03 北京唐密科技发展有限公司 一种事件型动态口令装置及实现方法
US9628445B2 (en) * 2014-10-31 2017-04-18 Ncr Corporation Trusted device control messages
US10033928B1 (en) 2015-10-29 2018-07-24 Gopro, Inc. Apparatus and methods for rolling shutter compensation for multi-camera systems
US9973696B1 (en) 2015-11-23 2018-05-15 Gopro, Inc. Apparatus and methods for image alignment
US9792709B1 (en) 2015-11-23 2017-10-17 Gopro, Inc. Apparatus and methods for image alignment
US9848132B2 (en) * 2015-11-24 2017-12-19 Gopro, Inc. Multi-camera time synchronization
US9973746B2 (en) 2016-02-17 2018-05-15 Gopro, Inc. System and method for presenting and viewing a spherical video segment
US9602795B1 (en) 2016-02-22 2017-03-21 Gopro, Inc. System and method for presenting and viewing a spherical video segment
DE102016207642A1 (de) * 2016-05-03 2017-11-09 Siemens Aktiengesellschaft Verfahren und Vorrichtungen zum Authentisieren eines Datenstroms
US10432855B1 (en) 2016-05-20 2019-10-01 Gopro, Inc. Systems and methods for determining key frame moments to construct spherical images
US9934758B1 (en) 2016-09-21 2018-04-03 Gopro, Inc. Systems and methods for simulating adaptation of eyes to changes in lighting conditions
US10268896B1 (en) 2016-10-05 2019-04-23 Gopro, Inc. Systems and methods for determining video highlight based on conveyance positions of video content capture
US10700865B1 (en) * 2016-10-21 2020-06-30 Sequitur Labs Inc. System and method for granting secure access to computing services hidden in trusted computing environments to an unsecure requestor
US10194101B1 (en) 2017-02-22 2019-01-29 Gopro, Inc. Systems and methods for rolling shutter compensation using iterative process
DE102017212809B3 (de) 2017-07-26 2018-09-27 Audi Ag Verfahren zur Überprüfung des Datentransports über eine zwischen zwei ersten Schnittstelleneinheiten realisierte erste Kommunikationsverbindung zwischen zwei Datenverarbeitungseinrichtungen und Kraftfahrzeug
US11592590B2 (en) * 2019-12-30 2023-02-28 Schlumberger Technology Corproation Well log channel matching
DE102020110708A1 (de) * 2020-04-20 2021-10-21 Bayerische Motoren Werke Aktiengesellschaft Vorrichtung und Verfahren zum Versenden einer Nachricht an zumindest zwei Empfänger für ein Kraftfahrzeug
EP3955149B1 (en) * 2020-08-14 2024-04-24 Nokia Technologies Oy Method and apparatus for securing real-time data transfer from a device
WO2022099683A1 (zh) * 2020-11-16 2022-05-19 华为云计算技术有限公司 一种数据传输方法、装置、设备、系统及存储介质
DE102021128434A1 (de) 2021-11-02 2023-05-04 Knorr-Bremse Systeme für Nutzfahrzeuge GmbH Verfahren und Vorrichtung zum Betreiben einer gesicherten Datenkommunikation zwischen Funktionseinheiten für ein Fahrzeug
US20230291568A1 (en) * 2022-03-14 2023-09-14 Silicon Laboratories Inc. Per Unit Time Message Authentication Code
US11895198B1 (en) * 2022-10-28 2024-02-06 Jonathon Anderson Universal session protocol
US20250175343A1 (en) * 2023-11-27 2025-05-29 Silicon Laboratories Inc. Achieving high ssl/tls throughput in embedded devices

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5345507A (en) * 1993-09-08 1994-09-06 International Business Machines Corporation Secure message authentication for binary additive stream cipher systems
US6009176A (en) * 1997-02-13 1999-12-28 International Business Machines Corporation How to sign digital streams
US6842860B1 (en) 1999-07-23 2005-01-11 Networks Associates Technology, Inc. System and method for selectively authenticating data
FI112418B (fi) * 2000-02-01 2003-11-28 Nokia Corp Menetelmä datan eheyden tarkastamiseksi, järjestelmä ja matkaviestin
US7242772B1 (en) * 2000-09-07 2007-07-10 Eastman Kodak Company Encryption apparatus and method for synchronizing multiple encryption keys with a data stream
FI20002608L (fi) * 2000-11-28 2002-05-29 Nokia Corp Päästä-päähän -tahdistksen ylläpitäminen tietoliikeneyhteydellä
US7684565B2 (en) * 2001-01-16 2010-03-23 General Instrument Corporation System for securely communicating information packets
US6948066B2 (en) * 2001-01-17 2005-09-20 International Business Machines Corporation Technique for establishing provable chain of evidence
US7627121B1 (en) * 2001-02-15 2009-12-01 At&T Mobility Ii Llc Apparatus, system and method for detecting a loss of key stream synchronization in a communication system
US7151831B2 (en) * 2001-06-06 2006-12-19 Sony Corporation Partial encryption and PID mapping
US20030156715A1 (en) * 2001-06-12 2003-08-21 Reeds James Alexander Apparatus, system and method for validating integrity of transmitted data
US20030149869A1 (en) * 2002-02-01 2003-08-07 Paul Gleichauf Method and system for securely storing and trasmitting data by applying a one-time pad
US7401221B2 (en) * 2002-09-04 2008-07-15 Microsoft Corporation Advanced stream format (ASF) data stream header object protection
US20040059939A1 (en) * 2002-09-13 2004-03-25 Sun Microsystems, Inc., A Delaware Corporation Controlled delivery of digital content in a system for digital content access control
US7434065B2 (en) * 2003-09-29 2008-10-07 Broadcom Corporation Secure verification using a set-top-box chip
US7565534B2 (en) 2004-04-01 2009-07-21 Microsoft Corporation Network side channel for a message board
CN100499516C (zh) * 2004-09-29 2009-06-10 重庆邮电学院 分组交换设备流量监测查询方法及线卡采集器
US20070237145A1 (en) * 2006-03-30 2007-10-11 Avaya Technology Llc Comparison based authentication in RTP

Also Published As

Publication number Publication date
EP2020136A1 (en) 2009-02-04
US20090210707A1 (en) 2009-08-20
CN101473622A (zh) 2009-07-01
ATE540516T1 (de) 2012-01-15
US8572382B2 (en) 2013-10-29
CN101473622B (zh) 2013-11-06
WO2007131523A1 (en) 2007-11-22
EP2020136B1 (en) 2012-01-04
BRPI0621674B1 (pt) 2019-05-28

Similar Documents

Publication Publication Date Title
BRPI0621674A2 (pt) método e sistema para autenticação fora de banda de fluxos de dados transmitidos através de uma rede de comunicação
KR100910818B1 (ko) 비-macsec 노드들을 통해 macsec 패킷들을터널링하기 위한 방법 및 시스템
US8918644B2 (en) Imparting real-time priority-based network communications in an encrypted communication session
EP1618702B1 (en) Transmission/reception system using message authentication code
JP2004295891A (ja) パケットペイロードを認証する方法
Rajagopal et al. Fibre channel over tcp/ip (fcip)
CN113904809B (zh) 一种通信方法、装置、电子设备及存储介质
CN114826748B (zh) 基于rtp、udp及ip协议的音视频流数据加密方法和装置
CN113904807B (zh) 一种源地址认证的方法、装置、电子设备及存储介质
Xiao et al. A Secure and Efficient Transport Protocol for Multi-Identifier Network
US9762412B2 (en) Redundant traffic encoding of encapsulated real time communications
US20170126849A1 (en) Header redundancy removal for tunneled media traffic
CN120017311B (zh) 一种基于增量式编码的可验证资源传递方法及装置
CN111614688A (zh) 区块链的通用协议
CN119135626B (zh) 数据低时延收发方法、装置、网络设备和存储介质
CN118678126B (zh) 自适应跨域码流密码安全保护方法、系统及设备
Venkadesh et al. A frame work model for secure key management and hidden digital signature method to enhance security in SCTP
CN116455669A (zh) 一种udp敲门业务的tcp代理方法及装置
CN117614711A (zh) 一种列车安全通信方法和装置
CN116389169A (zh) 一种避免国密IPSecVPN网关数据包乱序、分片的方法
CN121923808A (zh) 后量子密码迁移的模块化解耦演进系统及方法
CN121841767A (zh) 基于单向光闸的数据交换方法及系统
CN115766237A (zh) 一种报文认证方法及系统
CN121908270A (zh) 一种基于直连通信的数据传输方法
CN121792234A (zh) 基于链式消息认证码的大坝安全监测数据传输验证方法

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.

B08F Application dismissed because of non-payment of annual fees [chapter 8.6 patent gazette]

Free format text: REFERENTE A 3A ANUIDADE

B08H Application fees: decision cancelled [chapter 8.8 patent gazette]

Free format text: REFERENTE AO DESPACHO 8.6 NA RPI 2214 DE 11/06/2013.

B06T Formal requirements before examination [chapter 6.20 patent gazette]
B06F Objections, documents and/or translations needed after an examination request according [chapter 6.6 patent gazette]
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 28/05/2019, OBSERVADAS AS CONDICOES LEGAIS. (CO) 10 (DEZ) ANOS CONTADOS A PARTIR DE 28/05/2019, OBSERVADAS AS CONDICOES LEGAIS