BRPI0608941B1

BRPI0608941B1 - Método e sistema para prover segurança de dados para um protocolo de transporte confiável que suporta fornecimento ordenado de dados bem como fornecimento não ordenado de dados, receptor, transmissor, e, alocador de protocolo de segurança

Info

Publication number: BRPI0608941B1
Application number: BRPI0608941-0A
Authority: BR
Inventors: Ta-Wei Chen; Karl Norrman
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2005-03-31
Filing date: 2006-03-09
Publication date: 2019-08-20
Also published as: US8352727B2; CA2597419C; EP1867129A1; CN101151867B; BRPI0608941A2; CN101151867A; JP2008535080A; WO2006104438A1; EP1867129B1; JP4903780B2; US20080307528A1; CA2597419A1

Abstract

metodo e sistema para prover segurança de dados para um protocolo de transporte confiável que suporta fornecimento ordenado de dados bem como fornecimento não ordenado de dados, receptor, transmissor, e, alocador de protocolo de segurança. uma idéia básica da invenção é separar o fornecimento ordenado de dados e o fornecimento não ordenado de dados em um protocolo de segurança executado no topo de um protocolo de transporte confiável, e executar um primeiro tipo de processamento de segurança para fornecimento ordenado de dados e um segundo tipo diferente de processamento de segurança para fornecimento não ordenado de dados no protocolo de segurança. preferivelmente, mensagens de dados usando fornecimento ordenado e mensagens de dados usando fornecimento não ordenado, dentro de um fluxo de dados seguro, são separadas em dois espaços de seqúéncia de mensagem na camada de protocolo de segurança, e processamento de segurança de dados é então efetuado diferentemente nestes dois espaços. a invenção é particularmente adequada para um protocolo de transporte confiável tal como sctp (protocolo de transmissão de controle de fluxo). o protocolo de segurança executado no topo do protocolo de transporte é preferivelmente baseado no protocolo tls (segurança de camada de transporte) ou um protocolo tipo tls com uma extensão de processamento de segurança para fornecimento não ordenado.

Description

“MÉTODO E SISTEMA PARA PROVER SEGURANÇA DE DADOS PARA UM PROTOCOLO DE TRANSPORTE CONFIÁVEL QUE SUPORTA FORNECIMENTO ORDENADO DE DADOS BEM COMO FORNECIMENTO NÃO ORDENADO DE DADOS, RECEPTOR, TRANSMISSOR, E, ALOCADOR DE PROTOCOLO DE SEGURANÇA”

CAMPO TÉCNICO DA INVENÇÃO [001] A presente invenção relaciona-se em geral a aspectos de segurança de protocolos de transporte confiáveis e, especialmente, à proteção de dados fornecidos fora-de-ordem.

FUNDAMENTOS DA INVENÇÃO [002] Em geral, a invenção é concernente a protocolos de transporte confiáveis suportando o fornecimento ordenado de dados bem como um fornecimento fora-de-ordem de dados. O protocolo de transmissão de controle de fluxo (SCTP) [1] é um exemplo de tal protocolo de transporte, desenvolvido no grupo de trabalho SIGTRAN do IETF. Este foi originalmente projetado para transportar mensagens de sinalização de telefonia PSTN. Entretanto, uma vez que este possui diversas características úteis que não estão disponíveis no TCP, é visto agora como um protocolo de transporte de finalidade geral e uma alternativa ao TCP.

[003] Normalmente, dentro de um fluxo SCTP mensagens de dados são fornecidas em ordem, de acordo com seu número de sequência de fluxo. Se uma mensagem de dados chega fora-de-ordem no ponto de extremidade de recepção (isto é, mais cedo), precisa ser mantido sem fornecimento para a camada superior, até que todas as mensagens diante dela sejam recebidas e fornecidas à camada superior. Um ponto de extremidade SCTP pode indicar que nenhum fornecimento ordenado é requerido para uma particular quantidade apreciável de dados (DATA chunk) transmitida com o fluxo. Quando um ponto de extremidade recebe uma quantidade apreciável de dados indicada para fornecimento não ordenado, este pode contornar o mecanismo

Petição 870190052171, de 03/06/2019, pág. 11/35 / 18 de ordenação e imediatamente fornecer os dados à camada superior, conforme ilustrado na Figura 1 mostrando fornecimento SCTP não ordenado.

[004] O fornecimento não ordenado ajuda a evitar bloqueio de cabeça de linha (HOL) quando aplicações estão convivendo com grandes quantidades de transações independentes. Bloqueio HOL ocorre quando transações múltiplas independentes são realizadas por um único fluxo de dados em ordem (por exemplo uma conexão TCP) e alguns dados em uma das transações está atrasado; todas as outras transações após este são bloqueadas de fornecimento à camada superior e tem que aguardar até que os dados atrasados cheguem, mesmo se estes não estão correlacionados à transação com a chegada dos dados atrasados.

[005] Um exemplo desta espécie de aplicação é o transporte de mensagens de sinalização SIP entre dois proxies 10-A, 10-B (por exemplo mensagens de configuração/interrupção de chamada, informação de cobrança, e mensagens de questionamento de rota) para agentes SIP múltiplos 20-A, 20B, conforme ilustrado na Figura 2 mostrando proxies SIP trocando mensagens de sinalização usando SCTP como o protocolo de transporte. Estas mensagens de sinalização SIP são independentes uma da outra; a ordem de chegada destas mensagens de sinalização não importa. Entretanto, é importante que estas cheguem a tempo. Usar o fornecimento não ordenado de SCTP para realizar mensagens de sinalização SIP entre proxies SIP evita o bloqueio HOL presente no TCP; com o fornecimento SCTP não ordenado, a perda de uma mensagem SIP de uma transação SIP não afeta negativamente o fornecimento a tempo de mensagens SIP de outras transações. O bloqueio HOL pode também ser evitado usando a característica multi-fluxo do SCTP (isto é, designa a cada transação SIP seu próprio fluxo SCTP). Entretanto, isto requer mais recursos de fluxo e pode não ser exequível. Em [2] foi explicitamente especificado que uma entidade SIP DEVERIA enviar toda mensagem SIP através de fluxo zero com o fornecimento não ordenado, quando SCTP é

Petição 870190052171, de 03/06/2019, pág. 12/35 / 18 usado para transportar mensagens de sinalização SIP.

[006] Um outro exemplo, é o transporte de mensagens AAA (Autenticação, Autorização e Extrato de Contas). Quando um usuário autentica em um ponto de conexão de segurança ou outra entidade em uma rede, a entidade tipicamente não contém a informação vital necessária para autenticar o usuário. Ao invés disso, o protocolo DIAMETER é usado para recuperar informação de autenticação de sessão de um servidor AAA, conforme ilustrado na Figura 3 mostrando um caso de uso de autenticação típica com um servidor DIAMETER. Para evitar bloqueio HOL, a interface entre o servidor AAA 30 e o ponto de conexão de acesso 40 pode usar o método de fornecimento não ordenado do SCTP, ou estabelecer um fluxo confiável separado para cada usuário 50. A interface é usualmente protegida, e o protocolo TLS (Segurança de Camada de Transporte) é uma escolha comum aqui. Uma vez que TLS não pode ser usado com fornecimento não ordenado (como será mostrado abaixo) é frequentemente usado multifluxo que, conforme mencionado, requer mais recursos de fluxo. Um exemplo onde esta configuração de sistema é usada é a Arquitetura Bootstrapping Genérica definida em [3].

[007] Foi declarado em [1] que a segurança de dados de associações

SCTP pode ser obtida usando o cabeçalho de autenticação IP (AH) [4] ou o cabeçalho de encapsulamento IP (ESP) [5] na camada de rede. Entretanto, AH e ESP não são compatíveis com dispositivos tais como caixas intermediárias. A segurança de dados de associações SCTP pode também ser obtida usando o protocolo de segurança de camada de transporte (TLS) [6] no topo da camada de transporte, mas somente para fornecimento ordenado. O uso de TLS sobre SCTP para fornecimento ordenado foi descrito em [7]. A referência [8] descreve o protocolo DTLS (Segurança de Camada de Transporte de Datagrama), que é uma modificação do TLS compatível com o datagrama, usando processamento baseado em sequência de número para todas as

Petição 870190052171, de 03/06/2019, pág. 13/35 / 18 gravações DTLS.

SUMÁRIO DA INVENÇÃO [008] A presente invenção supera estas e outras deficiências dos arranjos da técnica anterior.

[009] É um objetivo geral da presente invenção melhorar a segurança para um protocolo de transporte confiável que suporta o fornecimento ordenado de dados, bem como fornecimento não ordenado de dados.

[0010] Em particular é desejável prover uma solução de segurança no topo da camada de transporte para dados que usam a característica de fornecimento não ordenada, como será explicado mais tarde.

[0011] É também desejável prover a segurança requerida, sem despender recursos de fluxo valiosos.

[0012] É um objetivo específico prover um método e sistema para prover segurança de dados para um protocolo de dados de transporte confiável que suporta o fornecimento ordenado de dados, bem como o fornecimento não ordenado de dados.

[0013] É um outro objetivo específico da invenção prover um receptor e um transmissor configurados para operar com base em um protocolo de transporte confiável que suporta o fornecimento ordenado de dados bem como o fornecimento não ordenado de dados.

[0014] Ainda um outro objetivo é prover alocador (conjunto de rotinas responsável pela alocação de tempo da CPU às várias aplicações) configurado para operar em conjunto com tal protocolo de transporte.

[0015] Este e outros objetivos são satisfeitos pela invenção conforme definido pelas reivindicações de patente que acompanham.

[0016] Uma idéia básica da invenção é separar o fornecimento ordenado de dados e o fornecimento não ordenado de dados em um protocolo de segurança executado no topo de um protocolo de transporte confiável, e

Petição 870190052171, de 03/06/2019, pág. 14/35 / 18 executar um primeiro tipo de processamento de segurança para fornecimento ordenado de dados e um segundo tipo diferente de processamento de segurança para fornecimento não ordenado de dados no protocolo de segurança. Preferivelmente, mensagens de dados usando fornecimento ordenado e mensagens de dados usando fornecimento não ordenado, dentro de um fluxo de dados seguro, são separadas em dois espaços de sequência de mensagem na camada de protocolo de segurança, e processamento de segurança de dados é então efetuado diferentemente nestes dois espaços.

[0017] A invenção é particularmente adequada para um protocolo de transporte confiável tal como SCTP (Protocolo de Transmissão de Controle de Fluxo). O protocolo de segurança executado no topo do protocolo de transporte é preferivelmente baseado no protocolo TLS (Segurança de Camada de Transporte) ou um protocolo tipo TLS com uma extensão de processamento de segurança para fornecimento não ordenado. Deveria entretanto, ser entendido que outras combinações de protocolos de segurança e transporte podem ser feitas.

[0018] É vantajoso introduzir um tipo de mensagem especial dedicado a mensagens não ordenadas para habilitar a identificação de tais mensagens. No lado da transmissão, tal mensagem do novo tipo de mensagem é preferivelmente designada a um número de sequência explícito a partir de um espaço de número de sequência especial dedicado a mensagens não ordenadas. No lado de recepção, o processamento de segurança para mensagens fornecidas de modo desordenado é então normalmente baseado no processamento de números de sequência explícitos executado pelas mensagens fornecidas de modo desordenado.

[0019] No sentido de efetuar proteção de reprodução para mensagens fornecidas de modo desordenado, de uma maneira eficiente, é benéfico manter uma lista daquelas mensagens que tenham sido recebidas, ou alternativamente daquelas mensagens que não tenham sido recebidas.

Petição 870190052171, de 03/06/2019, pág. 15/35 / 18 [0020] Para proteção de queda de dados, uma mensagem de terminação para terminação de uma conexão de protocolo de segurança, geralmente inclui um número de sequência final das mensagens de dados não ordenadas enviadas, e recepção confiável de todas as gravações enviadas no espaço de gravação não ordenado podem então ser detectadas com base no número de sequência final na mensagem de terminação.

[0021] A invenção é altamente compatível e plenamente operável com protocolos existentes, tais como UDP, DCCP e PR-SCTP.

[0022] A invenção oferece as seguintes vantagens:

> Segurança de dados melhorada;

> Uma solução de segurança robusta e eficiente no topo da camada de transporte para dados, que usa a característica de fornecimento não ordenado;

> Segurança de dados com utilização eficiente de recursos de fluxo valiosos; e > Altamente compatível com protocolos de transporte fundamentais existentes.

[0023] Outras vantagens oferecidas pela invenção serão verificadas ao ler a descrição abaixo das realizações da invenção.

BREVE DESCRIÇÃO DOS DESENHOS [0024] A invenção, juntamente com objetivos e vantagens adicionais desta, será melhor entendida pela referência à descrição seguinte, considerada juntamente com os desenhos que a acompanham, nos quais:

[0025] Figura 1 é um diagrama esquemático ilustrando fornecimento não ordenado SCTP.

[0026] Figura 2 mostra proxies SIP trocando mensagens de sinalização usando SCTP como o protocolo de transporte.

[0027] Figura 3 mostra um caso de uso de autenticação típico com um servidor DIAMETER.

Petição 870190052171, de 03/06/2019, pág. 16/35 / 18 [0028] Figura 4 ilustra o formato de uma gravação de dados TLS convencional.

[0029] Figura 5 mostra o suporte TLS corrente de serviços SCTP da técnica anterior.

[0030] Figura 6 é um fluxograma esquemático de um método para segurança de dados melhorada para um protocolo de transporte confiável de acordo com uma realização preferida típica da invenção.

[0031] Figura 7 ilustra um exemplo de um espaço de sequência separado para gravações fornecidas não ordenadas, de acordo com uma realização típica da invenção.

[0032] Figura 8 mostra um exemplo de um novo cabeçalho de gravação para fornecimento não ordenado (SCTP) de acordo com uma realização típica da invenção.

[0033] Figura 9 ilustra um possível fluxo de dados típico de acordo com a invenção, com referência particular a TLS e SCTP.

[0034] Figura 10 mostra como o receptor mantém uma lista de intervalos de gravações que recebeu, de acordo com uma realização típica da invenção.

[0035] Figura 11 ilustra um exemplo de uma lista de repetição onde o receptor anota quais gravações ainda não viu de acordo com uma realização típica da invenção.

[0036] Figura 12 mostra um exemplo de envio de mensagens de alerta de fechamento no espaço ordenado contendo o número de sequência mais alto do espaço não ordenado.

[0037] Figura 13 é um diagrama em blocos esquemático ilustrando partes relevantes de um receptor de acordo com uma realização típica da invenção.

[0038] Figura 14 ilustra esquematicamente uma separação de fornecimento não ordenado e não ordenado em ambos protocolos de

Petição 870190052171, de 03/06/2019, pág. 17/35 / 18 segurança e protocolo de transporte para a combinação típica de um protocolo de segurança TLS e um protocolo de transporte SCTP.

DESCRIÇÃO DETALHADA DAS REALIZAÇÕES DA INVENÇÃO [0039] Através dos desenhos, os mesmos caracteres de referência serão usados para elementos correspondentes ou similares.

[0040] Será útil começar com uma análise de problema em um contexto típico específico. Associações SCTP que usam características de fornecimento não ordenadas podem ser protegidas por AH e ESP. Entretanto, AH e ESP não são compatíveis com dispositivos tais como caixas intermediárias (por exemplo, caixas intermediárias fazendo otimização de desempenho TCP, compressão de cabeçalho, geração de ponto de conexão de aplicação, geração de barreira de proteção, geração de NAT, etc.) porque estas caixas intermediárias podem necessitar acessar ou mesmo manipular cabeçalhos de transporte. Portanto, os inventores reconheceram a necessidade de uma solução de segurança no topo da camada de transporte para dados que usam a característica de fornecimento não ordenado de protocolos tais como SCTP.

[0041] O TLS é um protocolo de segurança típico executado no topo da camada de transporte. O TLS foi originalmente projetado para proteger conexões de dados sobre TCP. O TLS divide um fluxo de dados em segmentos, executa processamento de segurança, incluindo criptografia e autenticação sobre cada segmento e encapsula os segmentos processados em gravações de dados. No TLS, quantidade apreciável de dados ou mensagens de dados são normalmente referidos como gravações. O formato de uma gravação de dados TLS convencional é ilustrado na Figura 4, e inclui um cabeçalho de gravação, dados criptografados, e um MAC (Código de Autenticação de Mensagem). O cabeçalho de gravação normalmente inclui um campo de tipo de gravação, um número de versão e informação sobre a extensão de gravação.

Petição 870190052171, de 03/06/2019, pág. 18/35 / 18 [0042] O TLS supõe que todas as gravações de dados cheguem em ordem e efetua processamento de segurança com base nesta suposição. Portanto, embora o TLS suporte SCTP quando os dados são fornecidos em ordem, o TLS não pode processar dados que usam fornecimento não ordenado. Na referência [7], foi explicitamente especificado que a característica de fornecimento não ordenado do SCTP precisa não ser usada juntamente com TLS, conforme ilustrado na Figura 5, mostrando o suporte corrente TLS de serviços SCTP. Na pilha de protocolo da Figura 5, pode ser visto que o TLS não é para ser usado para fornecimento SCTP não ordenado, mas somente para fornecimento SCTP ordenado.

[0043] Em geral, uma idéia básica da invenção é separar (S1) mensagens de dados para fornecimento ordenado e mensagens de dados para fornecimento não ordenado em dois espaços de sequência de mensagem na camada do protocolo de segurança, e efetuar (S2) processamento de segurança de dados diferentemente nestes dois espaços, conforme ilustrado esquematicamente no fluxograma da Figura 6. Os protocolos de segurança do estado da técnica de hoje, tal como TLS, não podem fazer tal distinção. A idéia da invenção é projetar/estender um protocolo de segurança, no topo da camada de transporte, para permitir uma separação de dados de fornecimento ordenado e não ordenado na camada do protocolo de segurança e executar diferentes tipos de processamento de segurança, dependendo do tipo de fornecimento.

[0044] A referência [8] descreve o protocolo DTLS, que realmente provê fornecimento não ordenado. Entretanto, no DTLS, todas as gravações contém um número de sequência explícito e todos os pacotes são processados em segurança do mesmo modo baseado nos números de sequência.

[0045] A presente invenção distingue entre DTLS em que, de acordo com a invenção, gravações de fornecimento ordenado e gravações de fornecimento não ordenado são separadas em dois espaços de sequência de

Petição 870190052171, de 03/06/2019, pág. 19/35 / 18 gravação diferentes, e processamento de segurança de dados é executado diferentemente para fornecimento ordenado e fornecimento não ordenado. Em particular, com a invenção, um número de sequência é somente inserido para pacotes que estão fora-de-ordem ao passo que o DTLS insere tal número para cada gravação. Deste modo, a solução inventiva economiza largura de faixa e pode ser tornada compatível com TLS legado.

[0046] Uma diferença adicional é que o DTLS provê um tamanho fixo da janela de reprodução, ao passo que, de acordo com a invenção, um outro método é usado para não perder de vista gravações que estão fora-deordem, o método sendo responsável por qualquer tamanho do intervalo de números de sequência perdidos.

[0047] A invenção é geralmente aplicável a protocolos de transporte confiáveis e protocolos de segurança projetados para execução no topo da camada de transporte. Entretanto, a invenção é particularmente adequada para SCTP (Protocolo de Transmissão de Controle de Fluxo) em combinação com um protocolo de segurança baseado no TLS (Segurança de Camada de Transporte) com processamento de segurança básico para fornecimento ordenado SCTP e uma extensão de processamento de segurança para fornecimento não ordenado SCTP. Em tal cenário, o uso da extensão de processamento de segurança é tipicamente negociado durante o estabelecimento da sessão, por exemplo, por meio de um procedimento na faixa, tal como um procedimento de saudação ou por meio de sinalização fora de faixa.

[0048] No lado da transmissão, o processamento de segurança para fornecimento não ordenado, é preferivelmente configurado para designar, a cada mensagem de dados não ordenada, um número de sequência explícito a partir de um espaço de número de sequência dedicado a mensagens não ordenadas. No lado da recepção, o processamento de segurança para mensagens fornecidas de modo desordenado é então baseado normalmente no

Petição 870190052171, de 03/06/2019, pág. 20/35 / 18 processamento dos números de sequência explícitos transportados pelas mensagens fornecidas de modo desordenado.

[0049] A seguir, a invenção será descrita principalmente com referência aos protocolos típicos particulares SCTP e TLS. Conforme mencionado, a invenção geralmente não está limitada a estes, e deveria ser entendido que outras combinações e protocolos de segurança e transporte podem ser feitas.

[0050] De acordo com uma realização típica preferida da invenção, separar as gravações fornecidas de modo ordenado e as gravações fornecidas de modo desordenado dentro de um fluxo seguro em dois espaços de sequência de gravação, conforme ilustrado na Figura 7 e efetuar segurança de dados separadamente nestes dois espaços diferentes. Figura 7 ilustra um exemplo de um espaço de sequência separado para gravações de fornecimento não ordenado de acordo com uma realização típica da invenção. São somente os números de sequência na sequência de fornecimento não ordenado que são explicitamente incluídos nos pacotes correspondentes. O espaço sequência de fornecimento não ordenado é meramente processado internamente pelo protocolo de segurança e não há tipicamente números de sequências explícitos presentes nos pacotes ordenados. A separação dos espaços de sequência é preferivelmente obtida introduzindo um tipo de gravação opcional para gravações fornecidas de modo desordenado. O TLS, por exemplo, possui um campo de “tipo” no cabeçalho de gravação (ver Figura 4), que é usado para identificar diferentes tipos de gravação (por exemplo, mensagens de saudação, mensagens de alerta e dados de aplicação). De acordo com a invenção, este campo pode também ser usado para especificar que uma gravação é uma gravação não ordenada (poderia haver versões não ordenadas de todos os tipos existentes, ou completamente diferentes poderiam ser definidas). O processamento de gravações não ordenadas pode, por exemplo, ser implementado como uma extensão de um protocolo de segurança tal como

Petição 870190052171, de 03/06/2019, pág. 21/35 / 18

TLS e o uso desta extensão pode ser negociado na faixa durante a saudação (TLS) (que é feita no espaço de sequência de fornecimento ordenado) para torná-lo de compatibilidade reversa com a implementação legada (TLS). Se uma implementação legada (TLS) é faceada com tipos de gravação não conhecidos, a conexão será terminada. Isto implica em que uma implementação legada (TLS) não falhará infelizmente se obtiver gravações dos novos tipos. Alternativamente, o uso de extensão de processamento de segurança para gravações de fornecimento não ordenado pode ser negociado por meio de sinalização fora de faixa (por exemplo, sinalização SIP).

[0051 ] O novo cabeçalho de gravação usado para gravações de dados de fornecimento não ordenado é preferivelmente definido para incluir um número de sequência explícito conforme ilustrado na Figura 8, mostrando um exemplo de um novo cabeçalho de gravação para fornecimento não ordenado (SCTP) de acordo com uma realização típica da invenção. Para cada gravação não ordenada, um número de sequência é normalmente extraído de um espaço de número de sequência que é dedicado a gravações não ordenadas. Outros campos que são necessários para processamento de segurança poderiam também ser incluídos neste novo cabeçalho de gravação (ou campos a partir do cabeçalho legado poderiam ser excluídos, por exemplo, a extensão de gravação poderia ser excluída se a extensão da gravação pudesse ser deduzida a partir do protocolo de transporte fundamental) sem afetar a interoperabilidade com o formato de gravação TLS legado.

[0052] Um fluxo de dados típico possível de tal solução é ilustrado na

Figura 9 com referência particular ao TLS e SCTP. No lado de transmissão

100, quando a aplicação (S11) envia uma quantidade apreciável de dados ao

TLS (S12), tem que especificar o tipo de fornecimento (isto é, fornecimento ordenado ou fornecimento não ordenado). Por exemplo, uma marcação especial (0/1) pode ser estabelecida pela aplicação, por exemplo, “0” para fornecimento ordenado e “1” para fornecimento não ordenado. Na

Petição 870190052171, de 03/06/2019, pág. 22/35 / 18 implementação TLS, o alocador é preferivelmente estendido. O alocador identifica o tipo de fornecimento (S13) e aloca tempo aos dados para a pilha de protocolo TLS legada (S14) ou a extensão TLS para fornecimento não ordenado SCTP (S15) de acordo com o tipo de fornecimento especificado pela aplicação. Para fornecimento não ordenado (S15), cada gravação é preferivelmente designada a um número de sequência explícito por um designador de número de sequência (SQN). Cada gravação é subsequentemente enviada ao receptor (S16).

[0053] No lado da recepção 200, quando o TLS recebe (S17) uma mensagem SCTP a partir da função de recepção do SCTP, o alocador de gravação aloca tempo (S18) à gravação de dados para a pilha de protocolo TLS legada (S19) ou a extensão TLS para fornecimento não ordenado SCTP (S20) de acordo com o campo de tipo do cabeçalho de gravação. Para gravações fornecidas de modo desordenado (S20), o número de sequência é extraído por um extrator SQN, e o processamento de segurança é efetuado por um módulo de processamento de segurança SQN, preferivelmente incluindo funções de segurança tais como proteção de reprodução, proteção de integridade e/ou proteção de perda de dados. Subsequentemente, a gravação é dada à aplicação (S21).

[0054] No espaço de sequência de fornecimento ordenado, gravações de dados chegam na mesma ordem em que são enviadas e podem ser processadas adequadamente por uma conexão TLS normal, usando o esquema de número de sequência implícito.

[0055] Com referência à extensão TLS para fornecimento não ordenado SCTP, a chegada de gravação é normalmente confiável. Entretanto, não é necessário que as gravações não ordenadas cheguem na mesma ordem em que são enviadas. Para executar proteção de integridade através de gravações fornecidas não ordenadas, o formato de gravações TLS deveria ser trocado de tal modo a incluir um número de sequência explícito (esta em

Petição 870190052171, de 03/06/2019, pág. 23/35 / 18 comparação com a sequência de fornecimento ordenado, onde os números de sequência são monotonicamente crescentes de um por gravação, e o número de sequência, daí, pode ser mantido como uma variável de estado nos pontos finais de comunicação). Uma diferença que é requerida entre os cabeçalhos das gravações dos dois tipos é que as gravações não ordenadas levam explicitamente o número de sequência.

[0056] A proteção de reprodução é preferivelmente executada com base na informação de número de sequência usando qualquer procedimento aceito para efetuar uma verificação de proteção de reprodução. Para evitar ataques simples de negação de serviço, proteção de integridade da informação de proteção de reprodução deveria ser preferivelmente também incluída. Se o MAC (ver Figura 8) é calculado através do número de sequência, haverá proteção de integridade para esta informação, usando verificação MAC codificada ordinariamente. Se um atacante modifica o número de sequência (informação de proteção de reprodução), o MAC não pode ser verificado e o protocolo então tomará as ações apropriadas.

[0057] Uma vez que o espaço entre o número de sequência na sequência não ordenada pode ser arbitrariamente grande, pode não ser factível manter uma janela de reprodução de tamanho fixo (ESP executado adiante). Ao invés de uma lista conceitual, por exemplo, na forma de uma lista conectada, contendo os espaços nas gravações recebidas, poderia ser mantida para utilização de memória mais eficiente. Esta lista conceitual é então usada para executar proteção de reprodução confiável. A decisão, na qual a implementação de proteção de reprodução que deve ser usada, pode ser feita por exemplo dependendo da distribuição de gravações não ordenadas e ordenadas no fluxo. A decisão é preferivelmente baseada em um conhecimento prévio desta distribuição, o que pode ser deduzido a partir do conhecimento do comportamento da aplicação.

[0058] Figura 10 mostra como o receptor mantém uma lista de

Petição 870190052171, de 03/06/2019, pág. 24/35 / 18 intervalos de gravações que recebeu (o primeiro número no par indica o limite inferior do intervalo, e o segundo o limite superior) de acordo com uma realização típica da invenção. Este também mostra como os intervalos podem ser mesclados quando são completados (ver o que acontece quando a gravação 3 e a gravação número 2 chegam). Em outras palavras, a Figura 10 ilustra um exemplo de uma lista de reprodução para fornecimento não ordenado, onde o receptor não perde de vista quais gravações viu.

[0059] Uma alternativa é manter uma lista de gravações que o receptor não recebeu. Isto é mostrado na Figura 11, ilustrando um exemplo de uma lista de reprodução onde o receptor anota quais gravações ainda não viu. Na Figura 11, INF significa o infinito conceitual, ou o número de sequência mais alto permitido. O número de sequência mais alto poderia ser interpretado de um modo modular, por exemplo, se o número de sequência começa em 0xfffe e o campo do número de sequência é de 16 bits de largura, o número de sequência “mais alto” poderia ser, por exemplo, 0xfffd, isto é, os números em torno do módulo 2^Λ16.

[0060] Para proteção de queda de dados, uma mensagem de terminação para terminação de uma conexão de protocolo de segurança, geralmente inclui um número de sequência final das mensagens de dados não ordenadas enviadas, e recepção confiável de todas as gravações enviadas no espaço de gravação não ordenado podem então ser detectadas com base no número de sequência final na mensagem de terminação. Deveria ser entendido que o conjunto de números de sequência é geralmente um conjunto ordenado, e o número de sequência final é o elemento “máximo” com respeito àquela ordem.

[0061] No TLS, a mensagem de terminação é tipicamente referida como uma mensagem de alerta de fechamento. Para efetuar detecção de queda de dados no contexto “TLS”, a mensagem de alerta de fechamento enviada por cada ponto de terminação de comunicação logo antes de uma conexão

Petição 870190052171, de 03/06/2019, pág. 25/35 / 18 “TLS” ser fechada, deveria conter preferivelmente o número de sequência “mais alto” de mensagens fornecidas não ordenadas enviadas, conforme ilustrado na Figura 12, mostrando um exemplo de envio de mensagens de alerta de fechamento no espaço ordenado contendo o número de sequência mais alto do espaço não ordenado. Isto é requerido para os pontos terminais assegurarem que não há pacotes não ordenados que não tenham alcançado um ponto de terminação. Por exemplo, se o ponto de terminação A recebe o Alerta de Fechamento contendo o número de sequência não ordenado mais alto enviado pelo ponto de terminação T (5 na figura), este sabe que não deveria interromper a conexão até que tivesse recebido todas as gravações de 1 a 5 na sequência não ordenada.

[0062] Figura 13 é um diagrama em blocos esquemático ilustrando partes relevantes de um receptor de acordo com uma realização típica da invenção. Neste exemplo particular, o receptor 200 compreende basicamente um receptor de mensagem 210, um alocador 220, um módulo para proteção de fornecimento ordenado 230, um módulo para proteção de fornecimento não ordenado 240 e um módulo de aplicação 250. O receptor de mensagem 210 inclui a função de recepção de mensagem do protocolo de transporte tal como SCTP, e permite possível armazenagem temporária de mensagens ou gravações de dados. O receptor de mensagem envia as mensagens de dados ao alocador 220 que verifica o tipo de mensagem. O alocador aloca tempo à mensagem de dados para o módulo 230 para (de)proteção de fornecimento ordenado ou módulo 240 para (de)proteção de fornecimento não ordenado, preferivelmente de acordo com o campo tipo do cabeçalho da mensagem de dados. Por exemplo, o módulo para proteção de fornecimento ordenado 230 pode implementar a pilha de protocolo TLS legada e o módulo para proteção de fornecimento não ordenado 240 pode implementar uma extensão TLS para fornecimento não ordenado. Preferivelmente, o módulo 240 para (de)proteção de fornecimento não ordenado inclui um extrator de número de sequência

Petição 870190052171, de 03/06/2019, pág. 26/35 / 18

242, um verificador de integridade 244 (por exemplo, verificação MAC), um verificador de reprodução 246 e uma armazenagem de lista de reprodução associada 248. Uma vez que as mensagens de dados tenham sido processadas, são enviadas à aplicação 250.

[0063] Em suma, os estados do protocolo de transporte são separados em fornecimento não ordenado e ordenado. Protocolos de segurança correntes atuais, contudo, não podem fazer esta distinção. Uma idéia básica da invenção é, portanto, estender o protocolo de segurança para possibilitar esta separação também em uma camada mais alta, como exemplificado na Figura 14. Figura 14 ilustra, esquematicamente, uma separação de fornecimento ordenado e não ordenado em ambos o protocolo de segurança e o protocolo de transporte para a combinação típica de um protocolo de segurança TLS e de um protocolo de transporte SCTP. Um ponto chave é processar mensagens de dados utilizando fornecimento ordenado e mensagens utilizando um fornecimento não ordenado separadamente, não importa se um ou dois pontos de entrada é(são) usado(s) para acessar a camada de protocolo de segurança, implicando em que os dois tipos de mensagens diferentes deveriam ser separados ou mantidos separados na camada de protocolo de segurança, pelo menos durante o processamento de segurança. É também facilmente entendido que outras combinações de tais protocolos de segurança e transporte confiável podem ser feitas.

[0064] Uma diferença entre uma extensão de protocolo de segurança, tal como extensão TLS, para o fornecimento não ordenado e o correspondente protocolo de segurança legado, tal como um TLS legado, é que a extensão de protocolo de segurança para o fornecimento não ordenado (ver, por exemplo, Figuras 9 e 14) executa o processamento de segurança requerido para cooperar com fornecimento não ordenado. Como um exemplo, a extensão de protocolo de segurança é preferivelmente configurada para:

• Processar o número de sequência explícito levado naquelas gravações; e

Petição 870190052171, de 03/06/2019, pág. 27/35 / 18 • Executar proteção de reprodução com base neste número de sequência (usando potencialmente um esquema diferente do esquema, por exemplo, no TLS legado, cujo esquema pode ser decidido durante a saudação. [0065] As realizações descritas acima são oferecidas meramente como exemplos, e deveria ser entendido que a presente invenção não está limitada a elas. Modificações, mudanças, e melhoramentos adicionais retendo princípios fundamentais básicos descritos e aqui reivindicados estão dentro do escopo da invenção.

REFERÊNCIAS [1] R. Stewart et al., “Stream Control Transmission Protocol”, RFC2960, IETF, October 2000.

[2] J.Rosenberg, et al., “The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP)”, Internet draft, IETF, January, 2005.

[3] 3GPP TS.33.220: “Generic Authentication Architecture (GAA); Generic bootstrapping architecture (Release 6)”, September, 2004.

[4] S. Kent and R. Atkinson, “IP Authentication Header”, RFC 2402, IETF, November 1998.

[5] S. Kent and R. Atkinson, “IP Encapsulating Security Payload (ESP)”, RFC 2406, IETF, November 1998.

[6] T. Dierks and C. Allen, “The TLS Protocol - Version 1.0”, RFC 2246, IETF, January 1999.

[7] A. Jungmaier, et al., “Transport Layer Security over Stream Control Transmission Protocol”, RFC 3436, IETF, December 2002.

[8] E. Rescorla, N. Modadugu, “Datagram Transport Layer Security”, Internet Draft, June 2004.

Claims

REIVINDICAÇÕES

1. Método para prover segurança de dados para um protocolo de transporte confiável que suporta fornecimento ordenado de dados bem como fornecimento não ordenado de dados, método este sendo caracterizado pelo fato de compreender:

separar dados de fornecimento ordenado e dados de fornecimento não ordenado em um protocolo de segurança executando no topo do protocolo de transporte confiável;

inserir um número de sequência em um cabeçalho dos dados de fornecimento não ordenado, tal número de sequência utilizado para assegurar a chegada e o processamento de todos os dados de fornecimento não ordenado; e executar, naquele protocolo de segurança, um primeiro tipo de processamento de segurança para dados de fornecimento ordenado e um segundo tipo diferente de processamento de segurança para dados de fornecimento não ordenado.
2. Método de acordo com a reivindicação 1, caracterizado pelo fato de que o referido protocolo de transporte confiável é SCTP (Protocolo de Transmissão de Controle de Fluxo).
3. Método de acordo com a reivindicação 1 ou reivindicação 2, caracterizado pelo fato de que o dito protocolo de segurança é baseado em TLS (Segurança de Camada de Transporte) com uma extensão de processamento de segurança para fornecimento não ordenado.
4. Método de acordo com a reivindicação 1, caracterizado pelo fato de que o referido protocolo de transporte confiável é SCTP (Protocolo de Transmissão de Controle de Fluxo), e o dito protocolo de segurança é baseado em TLS (Segurança de Camada de Transporte) com processamento de segurança legado para fornecimento ordenado SCTP e uma extensão de processamento de segurança para fornecimento não ordenado SCTP.
5. Método de acordo com a reivindicação 4, caracterizado pelo

Petição 870190052171, de 03/06/2019, pág. 29/35

2 / 6 fato de que o uso daquela extensão de processamento de segurança é negociado durante configuração de sessão.
6. Método de acordo com a reivindicação 1, caracterizado pelo fato de que mensagens de dados usando fornecimento ordenado e mensagens de dados usando fornecimento não ordenado, dentro de um fluxo de dados seguro, estão separadas em dois espaços de sequências de mensagens no protocolo de segurança, e processamento de segurança de dados é executado diferentemente nestes dois espaços.
7. Método de acordo com a reivindicação 6, caracterizado pelo fato de que o processamento de segurança para mensagens fornecidas de modo desordenado é baseado em processamento de números de sequências explícitos levados por mensagens fornecidas de modo desordenado.
8. Método de acordo com a reivindicação 6, caracterizado pelo fato de que mensagens fornecidas de modo desordenado são identificadas pela introdução de um tipo de mensagem especial que é dedicado a mensagens não ordenadas, cada uma daquelas mensagens não ordenadas compreendendo um número de sequência explícito designado a partir de um espaço de número de sequência especial que é dedicado a mensagens não ordenadas.
9. Método de acordo com a reivindicação 7 ou reivindicação 8, caracterizado pelo fato de que uma lista conceitual daquelas mensagens que tenham sido recebidas, ou alternativamente daquelas mensagens que não tenham sido recebidas, é mantida para efetuar proteção de reprodução para mensagens fornecidas de modo desordenado.
10. Método de acordo com a reivindicação 7 ou reivindicação 8, caracterizado pelo fato de que uma mensagem de terminação para terminação de uma conexão de protocolo de segurança inclui um número de sequência final das mensagens de dados não ordenadas enviadas, e recepção confiável de todas gravações enviadas no espaço de gravação não ordenado é detectada com base no número de sequência final na mensagem de terminação.

Petição 870190052171, de 03/06/2019, pág. 30/35

3 / 6
11. Sistema para prover segurança de dados para um protocolo de transporte confiável que suporta fornecimento ordenado de dados bem como fornecimento não ordenado de dados, sistema este sendo caracterizado pelo fato de compreender:

uma memória; e um ou mais processadores, o um ou mais processador(es) sendo configurado(s) para:

separar dados de fornecimento ordenado e dados de fornecimento não ordenado em um protocolo de segurança no topo do protocolo de transporte confiável;

inserir um número de sequência em um cabeçalho dos dados de fornecimento não ordenado, tal número de sequência utilizado para assegurar a chegada e o processamento de todos os dados de fornecimento não ordenado; e executar, naquele protocolo de segurança, um primeiro tipo de processamento de segurança para dados de fornecimento ordenado e um segundo tipo diferente de processamento de segurança para dados de fornecimento não ordenado.
12. Sistema de acordo com a reivindicação 11, caracterizado pelo fato de que o referido protocolo de transporte confiável é SCTP (Protocolo de Transmissão de Controle de Fluxo), e o dito protocolo de segurança é baseado em TLS (Segurança de Camada de Transporte) com processamento de segurança legado para fornecimento ordenado SCTP e uma extensão de processamento de segurança para fornecimento não ordenado SCTP.
13. Receptor configurado para operar com base num protocolo de transporte confiável que suporta fornecimento ordenado de dados bem como fornecimento não ordenado de dados, receptor este sendo caracterizado pelo fato de compreender:

uma memória; e um ou mais processadores, o um ou mais processador(es) sendo

Petição 870190052171, de 03/06/2019, pág. 31/35

4 / 6 configurado(s) para:

separar dados fornecidos de modo ordenado e dados fornecidos de modo desordenado em um protocolo de segurança no topo do protocolo de transporte confiável;

extrair um número de sequência de um cabeçalho daqueles dados fornecidos de modo desordenado, o número de sequência usado para assegurar a chegada e o processamento de todos os dados fornecidos de modo desordenado;

executar um primeiro tipo de processamento de segurança em tal protocolo de segurança para dados fornecidos de modo ordenado; e executar um segundo tipo diferente de processamento de segurança em tal protocolo de segurança para dados fornecidos de modo desordenado.
14. Receptor de acordo com a reivindicação 13, caracterizado pelo fato de que tal receptor é configurado para operar com base em SCTP (Protocolo de Transmissão de Controle de Fluxo), e o dito receptor sendo configurado para executar processamento de segurança TLS (Segurança de Camada de Transporte) legado para fornecimento ordenado SCTP e uma extensão de processamento de segurança TLS para fornecimento não ordenado SCTP.
15. Receptor de acordo com a reivindicação 13, caracterizado pelo fato de que tal receptor é configurado para separar mensagens de dados usando fornecimento ordenado e mensagens de dados usando fornecimento não ordenado dentro de um fluxo de dados seguro em dois espaços de sequências de mensagens no protocolo de segurança.
16. Receptor de acordo com a reivindicação 15, caracterizado pelo fato de que tal receptor é configurado para identificar mensagens fornecidas de modo desordenado com base na detecção de um tipo de mensagem especial que é dedicado a mensagens não ordenadas, cada uma das referidas mensagens não ordenadas compreendendo um número de sequência explícito designado a partir de um espaço de número de sequência especial que é dedicado a mensagens não ordenadas.

Petição 870190052171, de 03/06/2019, pág. 32/35

5 / 6
17. Receptor de acordo com a reivindicação 15 ou reivindicação

16, caracterizado pelo fato de que o processamento de segurança para mensagens fornecidas de modo desordenado é baseado em processamento de números de sequências explícitos levados por mensagens fornecidas de modo desordenado.
18. Receptor de acordo com a reivindicação 17, caracterizado pelo fato de que ele é adicionalmente configurado para manter uma lista conceitual daquelas mensagens que tenham sido recebidas, ou alternativamente daquelas mensagens que não tenham sido recebidas, para efetuar proteção de reprodução para mensagens fornecidas de modo desordenado.
19. Transmissor configurado para operar com base num protocolo de transporte confiável que suporta fornecimento ordenado de dados bem como fornecimento não ordenado de dados, transmissor este sendo caracterizado pelo fato de compreender:

uma memória; e um ou mais processadores, o um ou mais processador(es) sendo configurado(s) para:

separar dados destinados a fornecimento ordenado e dados destinados a fornecimento não ordenado em um protocolo de segurança no topo do protocolo de transporte confiável;

inserir um número de sequência em um cabeçalho dos dados de fornecimento não ordenado, tal número de sequência utilizado para assegurar a chegada e o processamento de todos os dados de fornecimento não ordenado;

executar um primeiro tipo de processamento de segurança em tal protocolo de segurança para fornecimento ordenado de dados; e executar um segundo tipo diferente de processamento de segurança em tal protocolo de segurança para fornecimento não ordenado de dados.
20. Transmissor de acordo com a reivindicação 19, caracterizado pelo fato de que o transmissor é configurado para operar com base em SCTP (Protocolo de Transmissão de Controle de Fluxo), e o referido transmissor sendo

Petição 870190052171, de 03/06/2019, pág. 33/35

6 / 6 configurado para executar processamento de segurança TLS (Segurança de Camada de Transporte) legado para fornecimento ordenado SCTP e uma extensão de processamento de segurança TLS para fornecimento não ordenado SCTP.
21. Transmissor de acordo com a reivindicação 19 ou reivindicação 20, caracterizado pelo fato de que o dito transmissor é configurado para designar números de sequências explícitos somente a mensagens de dados não ordenadas.
22. Alocador de protocolo de segurança configurado para operar em conjunto com um protocolo de transporte confiável que suporta fornecimento ordenado de dados bem como fornecimento não ordenado de dados, alocador de protocolo de segurança este sendo caracterizado pelo fato de compreender:

uma memória; e um ou mais processadores, o um ou mais processador(es) sendo configurado(s) para:

inserir um número de sequência em um cabeçalho de dados de fornecimento não ordenado, tal número de sequência utilizado para assegurar a chegada e o processamento de todos os dados de fornecimento não ordenado; e alocar tempo a dados para um primeiro tipo de processamento de protocolo de segurança para fornecimento ordenado ou para um segundo tipo diferente de processamento de protocolo de segurança para o fornecimento não ordenado de acordo com o tipo indicado de fornecimento.
23. Alocador de protocolo de segurança de acordo com a reivindicação 22, caracterizado pelo fato de que aquele alocador de protocolo de segurança é configurado para alocar tempo a dados para fornecimento ordenado a processamento de segurança TLS (Segurança de Camada de Transporte) legado e dados para fornecimento não ordenado a uma extensão de processamento de segurança TLS.