BRPI0509538B1 - método, sinal digital, portadora, e primeiro sistema para estabelecer um percurso de comunicação bidirecional - Google Patents

método, sinal digital, portadora, e primeiro sistema para estabelecer um percurso de comunicação bidirecional Download PDF

Info

Publication number
BRPI0509538B1
BRPI0509538B1 BRPI0509538A BRPI0509538A BRPI0509538B1 BR PI0509538 B1 BRPI0509538 B1 BR PI0509538B1 BR PI0509538 A BRPI0509538 A BR PI0509538A BR PI0509538 A BRPI0509538 A BR PI0509538A BR PI0509538 B1 BRPI0509538 B1 BR PI0509538B1
Authority
BR
Brazil
Prior art keywords
key
user
public key
service
shared secret
Prior art date
Application number
BRPI0509538A
Other languages
English (en)
Inventor
Anthony Little Herbert
Kenneth Brown Michael
Original Assignee
Blackberry Ltd
Research In Motion Ltd
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 Blackberry Ltd, Research In Motion Ltd filed Critical Blackberry Ltd
Publication of BRPI0509538A publication Critical patent/BRPI0509538A/pt
Publication of BRPI0509538B1 publication Critical patent/BRPI0509538B1/pt

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3215—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a plurality of channels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/041—Key generation or derivation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless

Abstract

emprego e fornecimento de dispositivos portáteis sem fio um método realizado por um primeiro sistema para o estabelecimento de um percurso de comunicação bidirecional seguro entre o primeiro sistema e um segundo sistema para uma troca de uma ou mais mensagens é descrito.um primeiro par de chaves tendo uma primeira chave pública e uma primeira chave privada é gerado, e um segundo par de chaves tendo uma segunda chave de usuário e uma segunda chave privada é gerada. a segunda chave de usuário é gerada com base em um segredo compartilhado conhecido pelo primeiro sistema e pelo segundo sistema. a segunda chave de usuário e a primeira chave pública são enviadas para o segundo sistema. uma terceira chave pública e uma quarta chave pública geradas pelo segundo sistema são recebidas, onde a quarta chave pública é gerada com base no segredo compartilhado.uma chave mestra é calculada com base na primeira chave privada, na segunda chave privada, na terceira chave pública e na quarta chave pública, onde a chave mestra é configurada para ser usada na encriptação de uma ou mais mensagens.

Description

MÉTODO, SINAL DIGITAL, PORTADORA, E PRIMEIRO SISTEMA PARA
ESTABELECER UM PERCURSO DE COMUNICAÇÃO BIDIRECIONAL ANTECEDENTES
CAMPO TÉCNICO
Este pedido se refere a um aparelho e a um método de estabelecimento de uma relação autêntica e segura entre dois sistemas de envio de mensagem para a troca de dados. Mais especificamente, este pedido descreve um aparelho e um método para o estabelecimento de uma relação autêntica entre um dispositivo portátil sem fio (dispositivo móvel) e um centro de mensagem ou sistema de hospedagem usando métodos de autenticação baseados em senha. O aparelho e o método descritos aqui são aplicáveis a ambientes de linha em terra bem como a ambientes sem fio.
ANTECEDENTES DA TÉCNICA
Há vários mecanismos de encriptação baseados em senha fortes atualmente conhecidos na indústria de computadores. Algumas destas implementações incluem Troca de Chave Encriptada (EKE), Módulos Derivados de Senha (PDM), e Troca de Chave Exponencial Autenticada por Senha Simples (SPEKE). Estes mecanismos são limitados nas suas implementações e não se dirigiram à necessidade de dispositivos móveis. Adicionalmente, estes mecanismos não se dirigem à necessidade de implementação de um sigilo futuro perfeito, de modo que se uma brecha de segurança não ocorrer todas as mensagens prévias trocadas permanecem seguras. Um protocolo provê um sigilo futuro perfeito se as chaves de sessão passada não forem comprometidas mesmo se as chaves de longa duração forem comprometidas. (Veja, por exemplo, Menezes et al. , Handbook of Applied Cryptography, 1996, p. 496) . O
Petição 870180138959, de 08/10/2018, pág. 14/15
2/39 ί
/1 sigilo futuro perfeito, também conhecido como proteção de ruptura passada, significa que todas as mensagens trocadas seguramente prévias devem permanecer seguras apesar de qualquer coisa que aconteça no futuro.
SUMÁRIO
Um sistema de comunicação de encriptação baseado em senha, em ambientes sem fio ou com fio, tendo um sigilo futuro perfeito é descrito. Ele inclui o uso de um par de chaves geradas de longa duração em combinação com um par de 10 chaves de autenticação de curta duração, geradas usando-se um segredo compartilhado, para se permitir a implementação de um sigilo futuro perfeito. A chave pública de longa duração é complementada com a chave pública de autenticação, para se permitir uma troca autêntica de 15 chaves de longa duração. Isto permite que a parte correspondente que está de posse do segredo compartilhado receba e seja capaz de usar a chave pública de longa duração.
De acordo com um aspecto, um método realizado por um 20 primeiro sistema para o estabelecimento de um percurso de comunicação bidirecional seguro entre o primeiro sistema e um segundo sistema para uma troca de uma ou mais mensagens é descrito. 0 método compreende a geração de um primeiro par de chaves que tem uma primeira chave pública e uma 25 primeira chave privada, e a geração de um segundo par de chaves tendo uma segunda chave pública e uma segunda chave privada. A segunda chave pública é gerada com base em um segredo compartilhado conhecido pelo primeiro sistema e pelo segundo sistema. O método também compreende o envio da 30 segunda chave pública e da primeira chave pública para o
Figure BRPI0509538B1_D0001
3/39 segundo sistema, e o recebimento de uma terceira chave pública e de uma quarta chave pública geradas pelo segundo sistema, onde a quarta chave pública é gerada com base no segredo compartilhado. O método também compreende o cálculo 5 de uma chave mestra baseada na primeira chave privada, na segunda chave privada, na terceira chave pública e na quarta chave pública, onde a chave mestra é configurada para ser usada na encriptação de uma ou mais mensagens.
De acordo com um outro aspecto, um sistema compreende uma memória e uma unidade de processamento acoplada à memória, onde a unidade de processamento é configurada para executar as etapas citadas acima.
De acordo com um outro aspecto, um portador legível em computador contém instruções de processamento adaptadas 15 para fazerem com que uma unidade de processamento execute as etapas citadas acima.
BREVE DESCRIÇÃO DOS DESENHOS
A Figura 1 mostra um diagrama de blocos de um primeiro sistema de comunicação de exemplo, entre um sistema fixo e 20 um sem fio.
A Figura 2 mostra um diagrama de blocos de um segundo sistema de comunicação de exemplo, entre dois sistemas sem fio.
A Figura 3 mostra um diagrama de blocos de um terceiro sistema de comunicação de exemplo, entre dois sistemas fixos.
A Figura 4 mostra um diagrama de troca de mensagem de um conjunto de exemplo de trocas de dados para a implementação do sistema de comunicação da Figura 1, onde 30 um usuário é o iniciador da troca de dados.
Figure BRPI0509538B1_D0002
4/39
Figure BRPI0509538B1_D0003
A Figura 5 mostra um diagrama de troca de mensagem de um conjunto de exemplo de trocas de dados para a implementação do sistema de comunicação da Figura 1, onde um provedor de serviços é o iniciador da troca de dados.
A Figura 6 mostra um fluxograma de dados das etapas no software de usuário para a realização das etapas na Figura 4, onde o usuário é o iniciador da troca de chave.
A Figura 7 mostra um fluxograma de dados das etapas no software de serviço para a realização das etapas na Figura 10 4, onde o usuário é o iniciador da troca de chave.
A Figura 8 mostra um fluxograma de dados das etapas no usuário de serviço para uma seqüência de rechaveamento quando da nova geração de uma outra chave no ambiente ilustrado nas Figuras 1, 2 e 3.
A Figura 9 mostra um fluxograma das etapas necessárias no provedor de serviços para uma seqüência de rechaveamento quando da nova geração de uma outra chave no ambiente ilustrado nas Figuras 1, 2 e 3.
DESCRIÇÃO DETALHADA
Com referência à Figura 1, é mostrado um diagrama de blocos de um primeiro sistema de comunicação de exemplo entre um sistema fixo e um sem fio. Este diagrama de visão geral mostra um ambiente de rede em que a invenção é usada.
O diagrama mostra uma modalidade de exemplo da invenção e se concentra em uma topologia de rede, que inclui um dispositivo móvel que é sem fio. Nesta figura, há sistemas oferecendo serviços 20 e 22 e sistemas usando os serviços 30 e 32. Entre a oferta de serviço (também referida aqui como provedor de serviços) e o usuário de serviço estão uma
0 ou mais redes e uma ou mais conexões, para se permitir o
5/39 ’ ί t
J fluxo de dados entre os dois sistemas.
Voltando-nos, agora, para a Figura 1, a oferta de serviço 20 ou 22 pode ser muitos possíveis computadores *
oferecendo serviços para os usuários. Para alguém versado na técnica, alguns provedores de serviços bem conhecidos poderíam ser computadores na Internet em um Provedor de Serviços de Internet (ISP) ou um escritório de Provedor de Serviços de Aplicativo (ASP). As ofertas de serviço 20 e 22 também podem ser um ou mais computadores rodando em uma companhia privada ou pública, como um banco, uma corretora de ações, uma corretora de seguros ou alguma outra companhia orientada para serviços. A oferta de serviço 20 ou 22 também pode ser rodada como parte de um agrupamento de computadores operando ao redor do mundo, constituindo um
Agrupamento de Descrição, Descoberta e Integração Universal (agrupamento de UDDI). O elemento comum em todas estas ofertas de serviço 20 e 22 é que estas ofertas de serviço e 22 precisam estabelecer um canal de dados seguro com um usuário. No caso de UDDI, a relação segura poderia ser 20 necessária para a troca de listagens de serviço privado, ou mesmo para se permitir que uma UDDI represente uma oferta de serviço.
Os dispositivos móveis e as hospedagens de serviço podem ser diferentes.
endereçados endereçados
Em algumas com endereços de uma variedade modalidades, eles de formas podem ser outras modalidades, o sistema de hospedagem pode ser endereçado por um endereço de e-mail. Ainda em uma outra modalidade, o endereço de destino pode ser um endereço de e-mail de um usuário do dispositivo móvel no sistema de
6/39 £
J hospedagem.
Uma pessoa versada na técnica apreciará que o usuário do serviço 3 0 ou 32 poderia ser um navegador de protocolo de transferência de hipertexto (HTTP) de móvel, um navegador de protocolo de aplicativo sem fio (WAP) de móvel, um aplicativo baseado em protocolo de controle de transmissão / protocolo de internet (TCP/IP) proprietário ou alguma outra solução corporativa proprietária. Neste campo, há novos métodos sendo desenvolvidos rapidamente, incluindo, por exemplo, a nova solução Java 2 Micro Edition (J2ME) para pequenos dispositivos móveis sem fio, como telefones celulares e assistentes digitais pessoais (PDAs). Para dispositivos que usam J2ME, a opção de anexação e transferência de um software através de uma oferta de serviço está se tornando lugar comum. De modo similar, as ofertas de serviço 2 0 e 22 podem ser baseadas em uma solução de servidor da web de HTTP, uma solução de Java t Enterprise, uma oferta de serviço baseada em linguagem de marcação sem fio (WML) ou alguma solução de serviço proprietária criada para uma finalidade específica.
Será apreciado que sistemas móveis e sistemas de hospedagem referidos aqui podem compreender, cada um, uma ou mais respectivas memórias (por exemplo, contendo instruções de processador) e uma ou mais respectivas 25 unidades de processamento, tais como aquelas convencionalmente conhecidas, por exemplo, unidades de processamento de finalidade geral e/ou unidades de processamento de finalidade especial, tais como circuitos integrados específicos de aplicação (ASICs) e arranjos de porta programáveis de campo (FPGAs), onde as unidades de
7/39 processamento podem ser configuradas (por exemplo, programadas com instruções de software e/ou firmware adequadas, e/ou produzidas com circuitos de hardware das abordagens descritas aqui. Cada um desses sistemas também pode incluir qualquer (quaisquer) interface(s) adequada(s), tais como aquelas em conjunto com uma respectiva(s) unidade(s) de processador para facilitação da comunicação com outros sistemas.
Os pontos de extremidade no percurso de comunicação são acoplados através de uma ou mais redes de dados que permitem a troca de dados, voz, vídeo, música, fotografias ou qualquer outra mídia digital que pode ser trocada através de um canal de comunicações de dados. As duas redes principais incluídas nesta ilustração são a Rede de Área Ampla (WAN) 26, a mais comum sendo a Internet, e uma rede sem fio 28. A rede sem fio 2 8 poderia ser uma rede GSM/GPRS, uma rede CDMA/1XRTT, uma rede CDMA2000, uma rede de 3- Geração como EDGE ou UMTS ou muitas outras redes sem fio públicas logo disponíveis. Em um sistema de exemplo, estas redes são acopladas usando-se ligações 24 como ISDN, Tl, Ethernet (linha em terra e 802.11), Envio de Quadro,
ATM, ADSL ou alguma outra conexão de Internet de alta velocidade para o serviço de hospedagem 22. Conforme quantidades maiores de dados estão sendo trocadas, é claro que a segurança precisa ser melhorada e tornada mais inviolável para hackers e pessoas acompanhando em segredo. A invenção trabalha com estes percursos de comunicação de dados existentes para a provisão de uma autenticação baseada em senha avançada. Este nível de segurança provê
4^
8/39 f
í maior confiança de que o destinatário de quaisquer dados comunicados seja exatamente a entidade que se espera. Uma modalidade para um percurso de comunicação de dados 36 é ilustrada entre uma oferta de serviço de Sistema de 5 Hospedagem 22 e um usuário do serviço em um dispositivo móvel 32. Uma outra modalidade para um percurso de comunicação de dados 40 ê ilustrada entre uma oferta de serviço de UDDI 20 e um usuário do serviço em um dispositivo móvel 30.
Em uma modalidade, a oferta de serviço de sistema de hospedagem 22 tem uma comunicação fora de banda 34 (isto é, uma comunicação por qualquer canal seguro adequado) com um usuário de um dispositivo móvel 32. O percurso de comunicação fora de banda 34 é usado para a troca de um segredo compartilhado, evitando-se um percurso inseguro que é para ser tornado seguro. Uma vez que a nuvem de serviço de UDDI provê algum nível de segurança, uma nuvem de serviço de UDDI poderia ser usada para a localização do serviço e a recepção do segredo compartilhado fora de banda
0 com o serviço de destino final. O que vem a seguir são uns poucos exemplos de percursos de comunicação 34 e 38:
(a) 0 usuário de dispositivo móvel 3 0 ou 32 e um operador no sistema de hospedagem 20 ou 22 estabelecem uma chamada telefônica um com o outro para a troca do segredo compartilhado. O segredo então ê introduzido em cada sistema e usado no processo de criação de uma chave de encriptação.
(b) 0 usuário de dispositivo móvel 3 0 ou 3 2 se conecta a um website seguro 20 ou 22, de forma sem fio ou por uma rede com fio, e requisita uma chave. A chave é
9/39 i
. <
recebida e manualmente introduzida no dispositivo *’ móvel 30 ou 32. O sistema de hospedagem 20 ou 22 poderia receber a chave automaticamente a partir do ♦
servidor da web, ou também poderia ser introduzida manualmente. Em algumas modalidades, um registro é automaticamente gerado após um segredo compartilhado ser requisitada.
(c) O usuário do dispositivo móvel 30 ou 32 faz a requisição pelo serviço e o segredo compartilhado é enviado por e-mail para o sistema de hospedagem 20 ou para sua caixa de correio corporativa que é conhecida por estar em uma área segura. 0 usuário recupera o segredo compartilhado a partir de sua caixa de correio eletrônica e manualmente a introduz no dispositivo móvel 30 ou 32.
(d) O usuário do dispositivo móvel 3 0 ou 32 faz a requisição pelo serviço e a operadora no serviço 20 ou 4 22 gera um segredo compartilhado e este é dado a uma pessoa especificada que é conhecida por ser confiável e segura. Esta pessoa poderia ser um secretário ou um administrador de um dado grupo; de modo ideal, ele é alguém que pode confirmar a identidade do usuário fazendo a requisição. Esta pessoa de confiança então dá o segredo compartilhado ao usuário final do dispositivo móvel 30 ou 32 e ele é manualmente introduzido no dispositivo móvel 30 ou 32.
Esta lista curta mostra que há muitas formas de se ar de forma autentica um segredo compartilhado a um usuário de dispositivo móvel. A propriedade comum destas comunicações
0 fora de banda de exemplo 34 e 3 8 é que algum nível de
10/39 ι
autenticação é construído ou assumido na escolha feita.
v Este percurso de comunicação autenticado é diferente do percurso de comunicação de dados não autenticado.
Uma vez que o segredo compartilhado seja compartilhado, a próxima etapa na criação de um percurso de comunicação seguro pode ocorrer em 3 6 e 40. Um dos métodos - mais bem conhecidos para a criação de uma ligação segura e autenticada é usar um método de encriptação baseado em senha forte como SPEKE. SPEKE é um método criptográfico para uma autenticação baseada em conhecimento que alavanca e protege senhas fáceis de lembrar - isto é, segredos compartilhados. SPEKE é o mais simples dos métodos de senha forte conhecidos. É uma troca de Diffie-Hellman autenticada por senha, onde a senha forma a base ou um gerador da troca. (Em Diffie-Hellman padronizado, a base usualmente é um número público fixo.) Uma vez que o percurso de comunicação através da WAN 26 e da rede sem fio 28 tenha sido tornado seguro, a seqüência de rechaveamento pode ser iniciada. A seqüência de rechaveamento permite a geração de um novo conjunto de chaves após um número predeterminado de semanas ou meses. Durante esta seqüência de rechaveamento, o uso avançado de chaves de encriptação de longa duração permite a implementação de um sigilo futuro perfeito. Uma vez que o segredo de autenticação (segredo compartilhado) seja usado para a criação de um percurso seguro, ele pode ser reusado para a criação de novas chaves em datas posteriores. Pelo uso desta invenção, a operação de rechaveamento não compromete as chaves prévias e todas as conversações prévias permanecem secretas no futuro.
Voltando-nos para a Figura 2, é mostrado um diagrama
4ζ
11/39
Μ (
de blocos de um sistema de comunicação de exemplo entre dois sistemas sem fio, de acordo com uma modalidade da presente invenção. Nesta modalidade, um percurso seguro 52 pode ser criado entre dois dispositivos móveis. Nesta 5 modalidade, o dispositivo móvel 1 46 e o dispositivo móvel
48 trocam um segredo e são capazes de estabelecerem uma * chave comum usando aquele segredo compartilhado. A conversação fora de banda 50 poderia ocorrer através de uma chamada telefônica entre as duas partes, um encontro face a face ou usando-se um dos outros métodos já destacados ou qualquer outro método adequado. Uma vez que o segredo seja compartilhado, ele pode ser manualmente digitado nos dispositivos móveis 46 e 48, e uma estação poderia iniciar a troca de mensagens para a criação de uma chave de segurança mestra comum. Este tipo de modalidade poderia ser comumente usado para conversações por e-mail de ponto a ponto privadas. Também poderia ser usada para trocas de dados de envio de mensagem instantânea segura de ponto a ponto. Em um uso avançado, o dispositivo móvel 1 46, o qual está provendo o serviço, poderia estar rodando um servidor da web no dispositivo móvel 46 e oferecendo alguma forma de oferta de serviço seguro que também seja móvel.
Voltando-nos para a Figura 3, é mostrado um diagrama de blocos de um sistema de comunicação de exemplo, entre dois sistemas fixos, de acordo com uma modalidade da presente invenção. Nesta modalidade, a comunicação ocorre entre dois sistemas de hospedagem 60 e 62. Nesta ilustração, a oferta de serviço 60 e o consumidor de serviço 62 têm uma conversação fora de banda 66 e trocam
0 uma chave secreta. Conforme j á descrito, esta comunicação
12/39 fora de banda podería ser uma chamada telefônica, uma comunicação através de um navegador com uma conexão de SSL segura para a geração e a recuperação da chave, ou alguma outra comunicação adequada, tal como provido anteriormente.
Uma vez que o segredo seja trocado, uma chave de encriptação pode ser gerada usando-se métodos de geração de chave baseados em senha forte, como SPEKE. O percurso de comunicação para a troca da chave nesta ilustração poderia ser por uma rede WAN, tal como a Internet 26, ou através de 10 uma Intranet interna 64, ou qualquer outro percurso de comunicação adequado tal como ou similar a uma ligação 802.11 ou de Bluetooth. Nestes últimos exemplos, o consumidor de serviço 62 poderia estar rodando um laptop ou um palmtop e já ter um acesso limitado à Intranet, mas 15 maior segurança seria requerida. Ê bem conhecido na técnica que 802.11b carece das exigências de segurança robusta requisitadas pela maioria dos departamentos computacionais grandes dentro de companhias. Esta modalidade ilustra que a invenção pode ser usada para a provisão da opção de sigilo 20 futuro perfeito quando se usa um mecanismo de autenticação baseado em senha. Uma vez que mensagens adequadas sej am trocadas para a criação da chave mestra, o percurso de comunicação de dados 68 pode ser usado para a troca de todas as formas de dados secretamente com alta segurança.
Voltando-nos para a Figura 4, é mostrado um diagrama de troca de mensagem que mostra um conjunto de exemplo de trocas de dados para a geração e a verificação de uma chave mestra, onde o usuário é o iniciador da troca de dados. Esta ilustração mostra etapas de exemplo e trocas de 30 mensagem entre um consumidor de serviço 100 (usuário) e um
4S
13/39 • ί provedor de serviços 102. Nesta ilustração, uma extremidade da conexão é considerada um consumidor ou usuário de serviço 100, e a ela foi dado o rótulo sistema A. A outra extremidade da conexão é considerada o provedor de serviços (também referido como uma oferta de serviço) ou sistema de hospedagem
102, e recebeu o rótulo sistema B.
Neste exemplo, usuário 100 inicia a troca de dados para a criação de uma conexão segura.
Entre o Sistema
Sistema
B está uma troca de mensagem por uma ou mais redes de comunicação, tal como ilustrado na Figura 1. De modo similar, conforme mostrado nas Figuras 1, 2 e 3, o usuário poderia ser um dispositivo móvel 30, 3 2 ou 48, ou um Sistema de Hospedagem 62. Da mesma forma, o provedor de serviços poderia ser um dispositivo móvel 46 ou um Sistema 15 de Hospedagem 20, 22 ou 60.
Conforme mostrado na etapa 104, o usuário 100 contata um provedor de serviços conhecido 102 através de um dos métodos já descrito para comunicação fora de banda ou através de um outro método adequado para a troca de um 20 segredo compartilhado. Este provedor de serviços 102 quer facilitar esta troca e emite uma senha secreta ou cadeias de senha simples, fáceis de lembrar (etapa 106) . Através deste mecanismo, um segredo compartilhado é gerado e trocado entre as duas partes. O usuário 100 recebe e salva 25 o segredo para ajudar na geração da chave de encriptação.
Alternativamente, o provedor de serviços 102 pode receber uma senha secreta (segredo compartilhado) a partir do usuário 100. Em qualquer caso, o provedor de serviços salva o segredo compartilhado em relação a este usuário.
Após a troca do segredo compartilhado, o usuário 100
14/39 então inicia (neste exemplo) etapas de geração de pares de chaves (etapa 108) e de transferência de informação de chave para o provedor de serviços (etapa 110) .Em particular, o usuário 100 gera um par de chavesde encriptação de longa duração na etapa 10 8, isto é,as partes pública e privada de uma chave de encriptação.Um par de chaves de autenticação de curta duração também é gerado na etapa 108 pelo usuário 100. Este par de chaves de curta duração é referido como um par de chaves de autenticação neste exemplo, porque é gerado usando-se o segredo compartilhado, conforme discutido adicionalmente abaixo.
Uma vez que os pares de chave de curta duração e de longa duração de usuário sejam gerados, as chaves de usuário dos mesmos são transmitidas na etapa 110 para o provedor de serviços 102 para ainda gerar a chave mestra final (por exemplo, referida como um segredo mestre). Esta transferência pode ocorrer por uma linha insegura, já que apenas o sistema de hospedagem 102 que emitiu o segredo compartilhado pode compreender e usar a chave de autenticação de curta duração para a geração da chave mestra. Uma vez que as chaves de usuário de usuário sejam recebida pelo provedor de serviços (etapa 112), o usuário é verificado e o segredo compartilhado para aquele usuário é lembrado em 112. Uma vez que o usuário seja verificado e o segredo compartilhado para o usuário seja lembrado, o provedor de serviços 102 prossegue para gerar seu próprio par de chaves de autenticação de curta duração usando o segredo compartilhado (etapa 114) . O provedor de serviços 102 também gera seu próprio par de chaves de autenticação
15/39 de longa duração (etapa 114) . Usando as chaves de usuário geradas pelo usuário 100 e usando o segredo compartilhado, o provedor de serviços 102 gera uma chave de encriptação mestra (ou segredo mestre), conforme mostrado na etapa 116.
O segredo compartilhado provê a autenticação necessária para se confinar na informação trocada. A chave de * autenticação pública de curta duração do provedor de serviços, a chave de encriptação pública de longa duração do provedor de serviços e um valor de confirmação de chave 10 que foi calculado pelo provedor de serviços usando-se a chave de encriptação mestra recém gerada e alguma cadeia conhecida, são enviados para o usuário (etapa 116).
O usuário recebe a informação (etapa 118) enviada a partir do provedor de serviços 102, incluindo as chaves de usuário de curta duração e de longa duração do provedor de serviços e gera a própria chave mestra do usuário (etapa 120). Com esta chave mestra, o usuário verifica o valor de confirmação de chave (etapa 120). Neste exemplo, o valor de confirmação de chave poderia ser o valor de comprovação da chave mestra e o nome do serviço ou alguma outra cadeia conhecida, acordada pelo usuário e pelo provedor de serviços. Se o valor de confirmação de chave não for verificado, a chave mestra criada pelo usuário 100 não é confiável, e é assumido que alguém está tentando comprometer a conexão. Se a chave de encriptação mestra gerada pelo usuário 100 parecer válida, o usuário então envia um valor de confirmação de chave final de volta para o provedor de serviços (etapa 122) . 0 provedor de serviços recebe a mensagem, verifica o valor de confirmação de chave, e marca o usuário como pronto para ir (etapa 124).
16/39
Isto permite que uma troca de dados plena ocorra do ponto de vista do provedor de serviços (etapa 128) . No lado de usuário, uma vez que a mensagem de verificação seja enviada, haveria uma ligeira pausa na transmissão, mas, 5 então, uma troca de dados plena pode começar (etapa 126).
As transmissões podem compreender mensagens de e-mail, tráfego baseado em HTTP (protocolo de transferência de hipertexto), tais como XML (linguagem de marcação extensível), WML (linguagem de marcação sem fio), etc., ou 10 outros tipos de tráfego.
Em algumas modalidades, o sistema de hospedagem é
capaz de enviar uma carga útil de dados em uma mensagem
enviada para o dispositivo móvel, antes do valor de
confirmação final ser enviado para ele a partir do
dispositivo móvel. A carga útil nesta mensagem pode ser uma entrada de livro de serviço, que define o serviço de hospedagem no sistema de hospedagem. Em algumas modalidades, a entrada de livro de serviço pode ser uma entrada de serviço de UDDI, que define atributos de um 20 serviço de hospedagem no sistema de hospedagem sendo acessado.
Será apreciado que o par de chaves de encriptação de longa duração gerado por uma primeira parte (por exemplo, um usuário), conforme descrito aqui, é um exemplo de, mais 25 geralmente, um primeiro par de chaves, onde a porção de chave pública e a porção de chave privada do mesmo podem ser referidas como uma primeira chave pública e uma primeira chave privada. De modo similar, o par de chaves de autenticação de curta duração (também referido como par de 30 chaves de encriptação de curta duração) gerado pela
J
17/39 +7 primeira parte (por exemplo, o usuário), conforme descrito aqui, é um exemplo, mais geralmente, de um segundo par de chaves, onde a porção de chave pública e a porção de chave privada do mesmo podem ser referidas como uma segunda chave 5 pública e uma segunda chave privada. Também, o par de chaves de encriptação de longa duração gerado por uma segunda parte (por exemplo, um provedor de serviços), conforme descrito aqui, é um exemplo, mais geralmente, de um terceiro par de chaves, onde a porção de chave pública e 10 a porção de chave privada do mesmo podem ser referidas como uma terceira chave pública e uma terceira chave privada. De modo similar, o par de chaves de autenticação (ou de encriptação) de curta duração gerado pela segunda parte (por exemplo, o provedor de serviços), conforme descrito 15 aqui, é um exemplo, mais geralmente, de um quarto par de chaves, onde a porção de chave pública e a porção de chave privada do mesmo podem ser referidas como uma quarta chave pública e uma quarta chave privada. A primeira parte que gera os primeiro e segundo pares de chaves poderia ser um 20 usuário, tal como descrito no exemplo acima, ou um provedor de serviços, tal como descrito no exemplo abaixo.
Voltando-nos para a Figura 5, é mostrado um diagrama de troca de mensagem que mostra um conjunto de exemplo de trocas de dados para a geração e a verificação de uma chave 25 mestra, onde o provedor de serviços é o iniciador da troca de dados. As etapas na Figura 5 substancialmente correspondem às etapas na Figura 4, exceto pelo fato de o provedor de serviços efetuar a primeira etapa. Este exemplo destaca que o usuário ou o provedor de serviços pode ser o 30 iniciador da troca de dados. Nesta ilustração, uma
Figure BRPI0509538B1_D0004
18/39 ' j
- <
extremidade da conexão é considerada o usuário 100, e é ** rotulada sistema A - consumidor de serviço. A outra extremidade da conexão é considerada o serviço 102, e é rotulada sistema B - Provedor de Serviços. Entre o Sistema 5 A 100 e o Sistema B 102 está uma troca de mensagem por uma ou mais redes de comunicação de dados 26, 28 e 64, tal como * ilustrado nas Figuras 1, 2 e 3. De modo similar, conforme mostrado nas Figuras 1, 2 e 3, o usuário podería ser um dispositivo móvel 30, 32 ou 48 ou um Sistema de Hospedagem 10 20, 22, 46 ou 60.
Conforme mostrado nas etapas 200/202, o provedor de serviços 102 contata o usuário 100 (neste exemplo) para a troca de um segredo compartilhado. Alternativamente, o usuário poderia iniciar esta comunicação. Ê contemplado que 15 um administrador em uma companhia de hospedagem 102 poderia contatar o usuário 100 e informar ao usuário que o usuário tem de realizar alguma ação com o segredo compartilhado sendo provido. Usando qualquer método adequado selecionado a partir da lista extensiva de comunicações fora de banda 20 já provida, ou algum outro método adequado, o segredo compartilhado é gerado e trocado (etapas 200 e 202). O componente de Usuário recebe e salva o segredo compartilhado para ajudar na geração da chave de encriptação. Alternativamente, o provedor de serviços 102 25 pode receber uma senha secreta (segredo compartilhado) a partir do usuário 100. Em qualquer caso, o provedor de serviços salva o segredo compartilhado em relação a este usuário.
Após a troca do segredo compartilhado, o provedor de 30 serviços 102 pode iniciar (neste exemplo) as etapas de
19/3
Figure BRPI0509538B1_D0005
Figure BRPI0509538B1_D0006
geração de pares de chaves (etapa 204) e de transferência da informação de chave para o usuário 100 (etapa 2 06) . Em particular, o provedor de serviços 102 gera um par de chaves de autenticação de curta duração e um par de chaves de encriptação de longa duração (etapa 204) . Isto corresponde à etapa 108 na Figura 4.
Uma vez que os pares de chaves de curta duração e de longa duração do provedor de serviços sejam gerados, as chaves de usuário do mesmo são transmitidas para o usuário (etapa 206) para se gerar ainda a chave mestra final (também referida como um segredo mestre). Esta transferência pode ocorrer por uma linha insegura, já que apenas o proprietário do segredo compartilhado seria capaz de compreender e usar a chave de autenticação de curta duração para a geração da chave mestra. As chaves de usuário de provedor de serviços são recebidas pelo usuário, e ele checa a memória para verificar a criação de serviço que é esperada e que ele tem um segredo compartilhado salvo na memória (etapa 208). O usuário lembra o segredo compartilhado para aquele provedor de serviços 102 e gera um par de chaves de autenticação de curta duração usando o segredo compartilhado (etapa 210) . O usuário também gera um par de chaves de encriptação de longa duração (etapa 210) . Usando as chaves de usuário geradas e enviadas pelo provedor de serviços 102 e usando o segredo compartilhado, o usuário 100 gera uma chave de encriptação mestra (ou segredo mestre), conforme mostrado na etapa 212. Após a geração da chave mestra, o usuário 100 também gera um valor de confirmação de chave pela combinação de uma cadeia conhecida (isto é, conhecido para si mesmo ou a oferta de
20/39 jz
serviço) coir i a chave mestra (etapa 212) . A chave de
4* autenticação pública de curta duração, a chave de
encriptação pública de longa duração e o valor de
confirmação de chave são enviados para o provedor de
serviços (etapa 212).
O provedor de serviços recebe as chaves de usuário de usuário e o valor de confirmação de chave e verifica o remetente da informação (etapa 214) e também lembra o segredo compartilhado para este usuário. Com os valores de chave pública recebidos do usuário, o provedor de serviços lembra seus próprios valores de chave privada salvos para este usuário (etapa 214) . Usando as chaves de usuário recebidas do usuário e as chaves privadas salvas do provedor de serviços, o provedor de serviços agora pode 15 gerar uma chave mestra (etapa 216). Após a geração da chave mestra, o provedor de serviços 102 verifica o valor de confirmação de chave pelo cálculo de seu próprio valor de confirmação de chave, usando a cadeia conhecida e a chave mestra recém criada, e comparando-o em relação ao valor de 20 confirmação de chave recebido (etapa 216) . Se o valor de confirmação de chave não verificar, a chave mestra criada não é confiável e, assim, é assumido que alguém está tentando comprometer a conexão. Se o valor de confirmação de chave realmente verificar, a chave de encriptação mestra 25 é considerada válida e o provedor de serviços 102 envia um valor de confirmação de chave final de volta para o usuário (etapa 218). 0 usuário recebe a mensagem (etapa 220), verifica o valor de confirmação de chave e marca o provedor de serviços como pronto para ir (etapa 220) . Isto permite 3 0 que uma plena troca de dados ocorra do ponto de vista do
Figure BRPI0509538B1_D0007
21/39 usuário (etapa 222). No lado de oferta de serviço, uma vez ** que a mensagem de verificação seja enviada haveria uma pausa na transmissão, mas, então, uma troca de dados plena pode começar (etapa 224). Na maioria dos casos, será o usuário que iniciará a primeira troca de dados; então, ter a confirmação enviada para o usuário realmente tem algumas vantagens.
As transmissões podem compreender mensagens de e-mail, tráfego baseado em HTTP (protocolo de transferência de 10 hipertexto) , tais como XML (linguagem de marcação extensível), WML (linguagem de marcação sem fio), etc., ou outros tipos de tráfego.
A Figura 6 é um fluxograma de dados de etapas de exemplo realizadas pelo usuário (por exemplo, no software 15 de usuário) para a realização da abordagem de exemplo mostrada na Figura 4, quando o usuário é o iniciador da troca de chave. A primeira etapa ocorre quando o usuário descobre um novo serviço e desej a acessá-lo (etapa 300) . Isto poderia ocorrer através de um serviço tipo de UDDI, 20 através de um serviço de Intranet corporativa, através de navegação pela rede mundial, através de uma conversação com um amigo ou através de uma chamada telefônica. Uma vez que o serviço e o usuário tenham sido conectados, eles trocam um segredo compartilhado 's' que apenas os dois sabem 25 (etapa 3 02) . Os métodos de exemplo desta troca já foram descritos em detalhes. Este segredo compartilhado 's' será usado mais tarde como um PIN (Número de Identificação
Pessoal) para autenticação do usuário e do serviço um com o outro. Quando o usuário está pronto para acessar o serviço, 30 o usuário (por exemplo, em software) gera um par de chaves
22/39 új de longa duração para o serviço requisitado (etapa 3 04) .
Este par de chaves de longa duração é um dos valores de chave usados durante todas as operações de rechaveamento futuras. Para todos os cálculos matemáticos no restante deste pedido, nós assumimos que todas as partes envolvidas nas transações acordaram de antemão em um grupo G, de tamanho de ordem (G) e um elemento g de G, de modo que q = ordem (g) seja um número primo grande. G e g podem ser publicamente conhecidos, isto é, eles não precisam ser mantidos secretos. Os cálculos matemáticos de exemplo para a criação de valores de chave são como se segue (usando-se um método SPEKE), e embora os cálculos de exemplo mostrados abaixo utilizem um grupo multiplicativo, será evidente que cálculos adequados poderiam ser realizados usando-se um grupo aditivo:
Capturar um Par de Chaves de Longa Duração (por exemplo, por um Usuário)
Capturar a randômico, 1 < a < q-1;
Calcular A = ga;
Se A = 1, continuar escolhendo a's diferentes até A <>
1.
O valor Ά' é a chave pública de longa duração de usuário (ou, mais geralmente, uma primeira chave pública), e o valor 'a' é a chave privada de longa duração de usuário (ou, mais geralmente, a primeira chave privada).
O número selecionado 'a' é maior do que 1 e menor do que o número primo q-1. Uma vez que a chave privada seja selecionada (isto é, 'a') e a chave pública seja gerada (isto é, Ά') , a chave privada 'a' é armazenada de forma segura, e a chave pública Ά' é eventualmente transmitida
23/39 para o provedor de serviços.
Um par de chaves de autenticação de curta duração também é gerado pelo usuário, com base no segredo compartilhado 's' (etapa 306). Usando-se um cálculo similar seguindo-se um método de geração de chave SPEKE de exemplo, os cálculos matemáticos de exemplo para esta etapa são (usando, por exemplo, as mesmas hipóteses para q e 'a' (como agora aplicado a x) como antes):
Capturar um Par de Chaves de Autenticação de Curta Duração (por exemplo, por um Usuário)
Capturar x randômico, 1 < x < q-1;
Calcular X = sx;
Se X = 1, continuar escolhendo novos x's até X <> 1.
O valor 'X' é a chave pública de curta duração de usuário (ou, mais geralmente, uma segunda chave pública), e o valor 'x' é a chave privada de curta duração de usuário (ou, mais geralmente, a segunda chave privada). O valor 's' é o segredo compartilhado.
A seleção de 'x' é entre 1 e o número primo q-1. O software de usuário então envia os valores de chave pública
Ά' e 'X' para a oferta de serviço (provedor de serviços), conforme mostrado na etapa 308. Esta etapa prossegue para (A) , onde a oferta de serviço recebe os valores e realiza cálculos adicionais, mostrados na Figura 7. Uma vez que a oferta de serviço tenha completado aqueles cálculos, ela retorna um par similar de seus próprios valores de chave pública Έ' e Ύ' com um valor de confirmação de chave para o usuário para verificação (etapa 312), conforme discutido abaixo em relação à Figura 7. Isto é mostrado como uma entrada (B) na Figura 6 vindo da Figura 7. Neste ponto, o r
Figure BRPI0509538B1_D0008
Figure BRPI0509538B1_D0009
usuário é capaz de usar ' B' e Ύ' para a criação de uma chave mestra usando, por exemplo, cálculos de SPEKE avançados. Pelo uso de 'B' e Ύ' em conjunto para a geração da chave mestra, o método de encriptação permite a implementação de um sigilo futuro perfeito. Isto é visto mais claramente na seqüência de rechaveamento mostrada mais tarde. Um cálculo de chave mestra de exemplo é como se segue:
Calcular Chave Mestra (por exemplo, por Usuário):
kl = Yx;
k2 = Ba;
verificar que kl, k2 i=0, 1 ou ordem (G) - 1;
k = hash (kl | | k2) , onde | | é uma função de concatenação.
Aqui, ’x' é a chave de autenticação privada de curta duração de usuário (ou, mais geralmente, a segunda chave privada) , e Ύ' é a chave de autenticação pública de curta duração recebida da oferta de serviço (ou, mais geralmente, a quarta chave pública). Também, 'a' é a chave de encriptação privada de longa duração de usuário (ou, mais geralmente, a primeira chave privada), e Έ' é a chave de encriptação pública de longa duração recebida da oferta de serviço (ou, mais geralmente, a terceira chave pública).
valor vk' representa a chave mestra que pode ser usada para a encriptação de dados entre o usuário e o serviço. O valor ' k' é a combinação das chaves intermediárias 'kl' (com base nas chaves de autenticação de curta duração) e 'k2' (com base nas chaves de encriptação de longa duração). Uma verificação importante é feita nos valores de chave intermediários de kl e k2 na etapa 314,
25/39 para verificar se estes dois valores não são 0, 1 ou ordem (G) - 1; caso contrário, isto poderia significar que há um ataque de segurança sendo tentado em 314. Este ataque poderia resultar se a chave estivesse sendo forçada em um pequeno subconjunto de possíveis chaves totais. Se o atacante enviasse um X = 0 ou Y = 0, as partes se comunicando poderíam obter um valor de chave resultante de 0. Esta verificação rápida assegura que um ataque não está sendo posto em prática. Se, contudo, o valor de kl ou k2 10 cair realmente em um destes pequenos grupos de subconjunto, a negociação para uma chave pode ser abortada em 316.
Se um ataque de subconjunto não for detectado, a chave mestra 'k' pode ser usada pelo usuário para testar o valor de confirmação de chave enviado pela oferta de serviço 15 (etapa 318) . Um método para a geração de um valor de confirmação de chave é aplicar um hash à chave com uma cadeia conhecida, tais como os bytes na chave pública A. Um cálculo de exemplo para se testar o valor de confirmação de chave seria:
20 Testar Valor de Confirmação de Chave hA recebido = hA = hash (k | | bytes de chave pública A), onde hA recebido veio da oferta de serviço e 'k' é a chave mestra local.
Se o valor de confirmação de chave gerado por software
5 para Ά' não combinar (etapa 3 2 0) com o valor de confirmação de chave recebido, então, ele está incorreto (etapa 322) . Um valor de confirmação de chave incorreto poderia significar que um ataque man-in-the-middle (homem no meio) ou algum outro ataque está sendo tentado. A 30 operação será abortada neste caso (etapa 322) . Se os dois
26/39 valores de confirmação combinarem, então, é assumido que uma ligação plenamente segura foi estabelecida (etapa 324}. A ligação é marcada como válida e, após um curto atraso será usada para comunicações (etapa 324). Usando a chave de 5 verificação recém gerada, o usuário envia este valor de volta para o serviço (etapa 326). Este segue de volta para a Figura 6 seguindo o rótulo (C) . Após uma pausa de poucos momentos, isto é, para se garantir que a confirmação seja recebida pela oferta de serviço, o usuário pode começar a 10 trocar dados (etapa 328).
Quaisquer métodos de encriptação e de desencriptação adequados podem ser usados para a encriptação e a desencriptação de mensagens usando-se a chave mestra, tais como métodos de encriptação / desencriptação de chave simétrica, como o Padrão de Encriptação Avançado (AES) (Federal Information Processing Standards Publication 197, 26 de novembro de 2001, National Institute of Standards and Technology).
A Figura 7 é um fluxograma de dados de etapas de exemplo realizadas pela oferta de serviço (por exemplo, no software de provedor de serviços) para a realização da abordagem de exemplo mostrada na Figura 4, quando o usuário é o iniciador da troca de chave, conforme mostrado na Figura 4. 0 processo começa quando um usuário contata um provedor de serviços 'fora de banda7 para trocar um segredo compartilhado (etapa 398). Isto corresponde à etapa 302 na Figura 6 no dispositivo de usuário. Esta troca fora de banda foi discutida várias vezes e também provê um nível de autenticação que o usuário e o serviço são quem eles dizem 30 ser. Uma vez que esta troca esteja completa, o usuário está
27/39
-..
livre em qualquer ponto no tempo para contatar o serviço ** para começar o processo. Uma vez que o usuário realmente contate o serviço de hospedagem, mostrado com a mensagem (A) chegando a partir do fluxograma de usuário na Figura 6, o novo usuário é verificado (etapa 4 00) . Uma vez que um provedor de serviços poderia ter dezenas ou centenas de usuários desejando começar a usar seu serviço em qualquer tempo, o provedor de serviços é passivo até o usuário decidir que ele quer começar o serviço. Embora um segredo compartilhado tenha sido trocado, isto pode significar muito pouco, e segredos compartilhados velhos poderiam mesmo ser purgados após algum número de dias, se o usuário falhar em se conectar por aquele período de tempo. A chegada da mensagem permite que o provedor de serviços encontre o novo usuário e verifique que um segredo compartilhado existe (etapa 400) . Na mensagem está a chave de autenticação de curta duração pública do usuário, a qual é baseada no segredo compartilhado (etapa 400). A mensagem também contém a chave de encriptação de longa duração pública do usuário (etapa 400) , a qual pode ser usada na implementação para a criação do sigilo futuro perfeito, quando operações de rechaveamento ocorrerem, Figuras 7 e 8.
A oferta de serviço gera um par de chaves de encriptação de longa duração para este usuário, de uma maneira similar ao par de chaves de encriptação de longa duração criado pelo usuário (etapa 402). Os cálculos matemáticos para a criação do par de chaves de encriptação de longa duração de oferta de serviço são como se segue (por exemplo, usando-se um método SPEKE):
0 Capturar um Par de Chaves de Longa Duração (por exemplo,
28/39 por um Provedor de Serviços)
Capturar b randômico, 1 < b < q-1;
Calcular B = gb;
Se B = 1, continuar escolhendo b's diferentes até B <> 1.
valor Έ' é a chave pública de longa duração de oferta de serviço (ou, mais geralmente, uma terceira chave pública) , e o valor 'b' é a chave privada de longa duração de oferta de serviço (ou, mais geralmente, a terceira chave privada).
número selecionado 'b' é maior do que 1 e menor do que o número primo q-1. Uma vez que a chave privada 'b' seja selecionada e a chave pública Έ' seja gerada, a chave privada 'b' é armazenada de forma segura, e a chave pública VB' é eventualmente transmitida de volta para o usuário, de modo que ele possa usá-la em seus cálculos.
A oferta de serviço também gera um par de chaves de autenticação de curta duração, com base no segredo compartilhado (etapa 404) . Usando-se um cálculo similar seguindo-se um método de geração de chave SPEKE de exemplo, os cálculos matemáticos de exemplo para esta etapa são (usando, por exemplo, as mesmas hipóteses para q e 'x' (como agora aplicado a y) como antes):
Capturar um Par de Chaves de Autenticação de Curta Duração (por exemplo, por um Provedor de Serviços)
Capturar y randômico, 1 < y < q-1;
Calcular Y = sy;
Se Y = 1, continuar escolhendo novos y's até Y <> 1.
valor Ύ' é a chave de autenticação de curta duração pública de oferta de serviço (de provedor de serviços) (ou,
29/39 mais geralmente, uma quarta chave pública), e o valor 'y' é a chave de autenticação de curta duração privada de oferta de serviço (ou, mais geralmente, a quarta chave privada).
A seleção de 'y' é entre 1 e o número primo q - 1. Os valores de chave pública 'B' e Ύ' serão eventualmente enviados para o usuário para a geração da própria chave mestra de usuário.
A oferta de serviço então usa as chaves de usuário Ά' e 'X' recebidas do usuário e as chaves privadas recém calculadas para a geração de uma chave mestra (etapa 406). Pelo uso de Ά' e 'X' em conjunto para a geração da chave mestra, o método de encriptação provê um sigilo futuro perfeito. Para a provisão do sigilo futuro perfeito, a implementação também usa as chaves privadas na nova geração das chaves subsequentes, durante qualquer seqüência de rechaveamento. Um cálculo de chave mestra de exemplo é como se segue:
Calcular Chave Mestra (por exemplo, por Provedor de serviços) kl = Xy;
k2 = Ab;
verificar que kl, k2 1=0, 1 ou ordem (G) - 1;
k = hash (kl || k2).
Aqui, 'y' é a chave de encriptação privada de curta duração de oferta de serviço (ou, mais geralmente, a quarta chave privada) , e 'X' é a chave de encriptação pública de curta duração recebida do usuário (ou, mais geralmente, a segunda chave pública). Também, 'b' é a chave privada de longa duração de oferta de serviço (ou, mais geralmente, a terceira chave privada) , e Ά' é a chave de encriptação
30/39 pública de longa duração recebida do usuário (ou, mais geralmente, a primeira chave pública).
O valor 'k' representa a chave mestra gerada pela oferta de serviço, e é a mesma que a chave mestra gerada 5 pelo usuário. Esta chave mestra pode ser usada para a encriptação de dados entre o serviço e o usuário. O valor vk' é a combinação das chaves intermediárias 'kl' (com base nas chaves de autenticação de curta duração) e 'k2' (com base nas chaves de encriptação de longa duração) . Uma 10 verificação importante pode ser feita nos valores de chave intermediários de kl e k2 na etapa 408, para verificar se estes dois valores não são 0, 1 ou ordem (G) - 1; caso contrário, isto poderia significar que há um ataque de segurança sendo tentado. Este ataque resultaria se a chave 15 estivesse sendo forçada em um pequeno subconjunto de possíveis chaves totais. Se o atacante enviasse um X - 0 ou Y = 0, as partes se comunicando poderiam obter um valor de chave resultante de 0. Esta verificação rápida assegura que um ataque não está sendo posto em prática. Se, contudo, o 2 0 valor de kl ou k2 cair realmente em um destes pequenos grupos de subconjunto, a negociação para uma chave pode ser abortada (etapa 410).
Se um ataque de subconjunto não for detectado, a chave mestra 'k' poderá ser usada pelo usuário para testar o 25 valor de confirmação de chave enviado pela oferta de serviço (etapa 416) . Um método para a geração de um valor de confirmação de chave é aplicar um hash à chave com uma cadeia conhecida, tais como os bytes na chave pública B. A criação de uma cadeia de teste de amostra ocorre na etapa 30 412. Um cálculo de exemplo para se testar a cadeia (valor
31/39
Λ3 de confirmação de chave) seria:
Testar Valor de Confirmação de Chave hB = hash (k || bytes de chave pública B).
A oferta de serviço então transmitiría a cadeia de teste para o usuário, de modo que ele possa verificar que a chave mestra gerada pelo usuário combina com a chave mestra criada pela oferta de serviço. A oferta de serviço então envia a chave de encriptação pública de longa duração 'B', a chave de autenticação pública de curta duração Ύ' (ou a quarta chave pública) e a cadeia de verificação hB para o usuário (etapa 414).
Uma vez que o usuário tenha gerado sua própria chave mestra 'k' , ele envia de volta um valor de confirmação de chave final para garantir que a oferta de serviço sabe que tudo funcionou corretamente (C) . Esta etapa final (C) é mostrada na Figura 7 como uma entrada para a oferta de serviço na etapa 416. Se o valor de confirmação de chave foi calculado com base em Ά' e enviado para a oferta de serviço (etapa 416) , então, isto é o que o teste procura (etapa 418) . Se o valor de confirmação de chave não combinar com o valor esperado, a operação ê abortada (etapa 420) . Se o valor de confirmação de chave for combinado, então, será assumido que existe um percurso de comunicação de dados plenamente encriptado de duas vias e seguro (etapa
422) .
A Seqüência de Fluxo de Dados de Rechaveamento
A Figura 8 é um fluxograma de dados que mostra etapas de exemplo no usuário (por exemplo, no software) para uma seqüência de rechaveamento quando da nova geração de uma outra chave no ambiente ilustrado nas Figuras 1, 2 e 3.
Figure BRPI0509538B1_D0010
32/39
Este procedimento ilustra a utilidade de uso de uma chave de encriptação de longa duração para se permitir a implementação de um sigilo futuro perfeito. O processo começa com quando o usuário ou a oferta de serviço decide que uma nova chave é requerida. Para este exemplo, nós assumimos que a hospedagem (provedor de serviços) está rodando um temporizador de expiração de chave de encriptação. Contudo, há muitas outras formas pelas quais a chave de encriptação poderia ser gerada de novo. O usuário poderia decidir que é o momento de uma nova chave, o usuário ou o serviço poderia temer que alguém estivesse tentando atacar e determinar o valor de chave atual. Qualquer que seja o caso, uma nova chave é desejada, e um método único, não baseado no segredo compartilhado original, pode ser usado para a geração da nova chave.
Como mostrado no exemplo da Figura 8, uma requisição de rechaveamento é recebida pelo usuário, ou o usuário decide partir para uma nova chave (etapa 430) . Obviamente, a etapa 430 poderia ser executada pelo provedor de serviços ao invés de pelo usuário. O software de usuário gera uma nova chave de encriptação de curta duração (etapa 432). Um cálculo matemático de exemplo é baseado em SPEKE e usa a mesma seqüência como mostrado antes:
Capturar um Novo Par de Chaves de Longa Duração (por exemplo, por um Usuário)
Capturar x randômico, 1 < x < q-1;
Calcular X = gx;
Se X = 1, continuar escolhendo x's diferentes até X <> 1.
Aqui, 'x' é um valor novo gerado para a chave de
33/39 encriptação privada de curta duração de usuário. O valor 'x' pode ser referido como uma chave de encriptação ou como uma chave de autenticação (como foi feito previamente), porque o valor 'x' contribui para ambos os 5 aspectos. A seleção de 'x' deve ser entre 1 e o número primo q - 1. O software de usuário então envia o valor de chave pública recém gerado 'X' para o provedor de serviços
434. Esta etapa prossegue para (D) , onde o provedor de
serviços recebe o valor e realiza cálculos adicionais. A
10 etapa (D) então é feita na Figura 9 como uma entrada no
lado de provedor de serviços da conexão.
Uma vez que o provedor de serviços tenha completado aqueles cálculos com (D) mostrado na Figura 9, ele retorna uma chave de encriptação pública nova similar
Ύ' (discutida adicionalmente abaixo) com i, valor de confirmação de chave para verificação pelo usuário
Isto é mostrado como a entrada (E) na Figura 8. Neste ponto, o usuário é capaz de usar a nova chave ' Y' do provedor de serviços com a chave ' B' pública de longa 20 duração mais antiga do provedor de serviços para a criação de uma chave mestra na etapa 440 seguindo-se cálculos avançados de SPEKE, por exemplo. Pelo uso da Έ' existente e da nova Ύ' em conjunto para a geração da chave, o método de encriptação pode prover uma implementação de sigilo 25 futuro perfeito. O sigilo futuro perfeito pode ser obtido porque nem a Έ' existente nem a nova Ύ' são baseadas no segredo compartilhado original, e a ' B' existente é combinada com a nova Ύ' para a criação de uma nova chave não diretamente baseada na chave prévia. Adicionalmente, a chave 'B' existente realiza parte da autenticação gerada
34/39 £>b com o segredo compartilhado original. Apenas um usuário de serviço autenticado que originalmente possuía o segredo compartilhado teria sido capaz de ter a chave privada 'b' salva em disco. Isto é visto mais claramente no cálculo matemático de rechaveamento de exemplo para a criação de uma nova chave mestra 'k':
Calcular Chave Mestra (por exemplo, por Usuário) kl = Yx;
k2 = Ba;
verificar que kl, k2 1=0, 1 ou ordem (G) - 1;
k = hash (kl || k2).
Aqui, 'x' é a chave de encriptação privada de curta duração de usuário e Ύ' é a nova chave de encriptação pública de curta duração recebida gerada pelo provedor de 15 serviços. O valor 'a' é a chave de encriptação privada de longa duração de usuário e 'B' é a chave de encriptação pública de longa duração existente do provedor de serviços.
O valor 'k' representa a nova chave mestra que pode ser usada para a encriptação de dados entre o usuário e o 20 provedor de serviços. O valor 'k' é a combinação das chaves intermediárias 'kl' (com base na chave de encriptação de curta duração) e 'k2' (com base nas chaves de encriptação de longa duração). Uma verificação importante é feita nos valores de chave intermediários de kl e k2 (etapa 442) , 25 para verificar se estes dois valores não são 0, 1 ou ordem (G) - 1; caso contrário, isto poderia significar que há um ataque de segurança sendo tentado (etapa 442). Se, contudo, o valor de kl ou k2 cair realmente em um destes pequenos grupos de subconjunto, a negociação para uma chave pode ser 30 abortada (etapa 444).
35/39
Se um ataque de subconjunto não for detectado, a nova chave mestra 'k' pode ser usada para se testar o valor de confirmação de chave enviado pela oferta de serviço (provedor de serviços), conforme mostrado na etapa 446. Um 5 método para a geração de um valor de confirmação de chave é aplicar um hash à chave com uma cadeia conhecida como os bytes na chave pública de A . A abordagem para o cálculo
de um valor de confirmação de chave pode ser a mesma
conforme descrito pref. Se o valor de confirmação de chave
10 não combinar com o que foi recebido (etapa 448), a chave
será assumida como estando em erro (etapa 4 50) . Um valor de confirmação de chave incorreto significaria que um ataque ma.n~in~ the-middle (homem no meio) ou algum outro ataque está sendo tentado. Caso contrário, o usuário gera um valor 15 de confirmação de chave final usando a chave mestra 'k' (etapa 452). O valor de confirmação de chave é enviado para o provedor de serviços (etapa 454) como uma confirmação final; conforme mostrado no ponto (F) na Figura 8. Então, após uma pausa curta, a nova chave de encriptação é usada 20 no software de usuário (etapa 456). Durante um período de tempo curto, também haverá uma janela em que as mensagens que foram previamente transmitidas poderíam chegar. Durante este período de vários minutos, a chave antiga é mantida e tentada, se um erro de desencriptação ocorrer (etapa 456).
Voltando-nos, agora, para a Figura 9, esta representa um fluxograma de dados de etapas de exemplo no provedor de serviços para uma sequência de rechaveamento quando da nova geração de uma outra chave no ambiente ilustrado nas Figuras 1, 2 e 3. Este procedimento mostra a utilidade de usar a chave de encriptação de longa duração para a
36/39 <6$ implementação do sigilo futuro perfeito. Nesta modalidade, nós assumimos que o usuário começou e processo e já criou um novo par de chaves de encriptação (ou de autenticação) de curta duração, conforme mostrado na Figura 8. A chegada da chave de encriptação pública de curta duração 'X' é mostrada como a entrada (D) . A chave pública é recebida e a informação de confirmação de usuário é lembrada e checada (etapa 460). A oferta de serviço então gera um novo par de chaves de encriptação de curta duração pelo próximo segmento de tempo (etapa 462) . O cálculo matemático de exemplo para a criação de uma nova chave de encriptação de curta duração é similar àquele que foi mostrado antes, exceto pelo fato de o segredo compartilhado 's' não ser usado.
Capturar um Novo Par de Chaves de Longa Duração (por exemplo, por um Provedor de Serviços)
Capturar y randômico, 1 < y < q-1;
Calcular Y = gy;
Se Y = 1, continuar escolhendo y's diferentes até Y <>
1.
A seleção de 'y' está entre 1 e o número primo q-1.
O valor Ύ' eventualmente será enviado para o usuário para a geração de uma chave mestra (etapa 472).
Após capturar um novo par de chaves de encriptação de curta duração, uma chave mestra é gerada pelo provedor de serviços usando o valor 'X' que foi recém recebido do usuário e o valor recém gerado 'y' . Pelo uso de Ά' e 'X' em conjunto para a geração da chave, o método de encriptação provê um sigilo futuro perfeito. Um cálculo de exemplo de chave mestra é como se segue:
37/39
Calcular Chave Mestra (por exemplo, por Provedor de serviços) kl = Xy; k2 = Ab;
verificar que kl, k2 !-0, 1 ou ordem (G) - 1;
k = hash (kl || k2).
Aqui, 'y' é a nova chave de encriptação privada de curta duração de provedor de serviço e ' X' é a nova chave de encriptação pública de curta duração recebida gerada 10 pelo usuário. O valor 'b' é a chave privada de longa duração existente de provedor de serviços e Ά' é a chave de encriptação pública de longa duração existente.
O valor 'k' representa a chave mestra para a oferta de serviço (etapa 464). Isto será usado para a encriptação de 15 todos os dados entre a oferta de serviço e o usuário. O valor ' k' é a combinação das chaves intermediárias 1 kl' (com base nas novas chaves de autenticação de curta duração) e 'k2' (com base nas chaves de encriptação de longa duração) . 0 cálculo de 'k' não é diretamente dependente do segredo compartilhado original 's' , mas os valores Ά' e 'b' portam parte da autenticação originalmente provida por 's'. Uma verificação pode ser feita sobre os valores intermediários de kl e k2 (etapa 466), para verificar se estes dois valores não são 0, 1 ou ordem (G) - 1; caso contrário, isto podería significar que há um ataque de segurança sendo tentado. Se, contudo, kl ou k2 cair realmente em um destes pequenos grupos de subconjunto, a negociação para uma chave pode ser abortada (etapa 468).
Se um ataque de subconjunto não for detectado, a chave
38/39 mestra 'k' poderá ser usada para se testar o valor de confirmação de chave enviado pela oferta de serviço (etapa 470) . Um método para a geração de um valor de confirmação de chave é aplicar um hash à chave com uma cadeia 5 conhecida, tais como os bytes na chave pública B (etapa 470). Este cálculo pode ser similar àqueles já descritos. A oferta de serviço então transmitiría uma nova chave de encriptação pública de curta duração Ύ' , e o valor de confirmação de chave hB para o usuário (etapa 472) . Esta 10 transferência dos valores de chave e do valor de confirmação de chave é mostrada na caixa de transferência (E) na Figura 9.
Uma vez que o usuário tenha gerado sua própria chave mestra 'k', ele envia um valor de confirmação de chave 15 final para garantir que a oferta de serviço saiba que tudo funcionou corretamente (etapa 454 da Figura 8) , conforme mostrado em (F) . Esta etapa final em (F) é mostrada na Figura 9 como uma entrada para a oferta de serviço (etapa 474). Se o valor de confirmação de chave foi calculado para 20 Ά' e enviado para a oferta de serviço (etapa 474), então, isto é o que o teste procura (etapa 476) . Se o valor de confirmação de chave não combinar com o valor esperado, a operação será abortada (etapa 478) . Se o valor de confirmação de chave for verificado, então, é assumido que 25 existe um percurso de comunicação de dados pleno de duas vias encriptado e seguro (etapa 480) . O servidor mantém a chave prévia por vários minutos, somente como garantia no caso de pacotes estarem a caminho durante este estágio de geração de nova chave (etapa 480).
De acordo com um outro aspecto, qualquer forma de
39/39 portador legível em computador pode conter as instruções de processamento adaptadas para fazerem com que uma unidade de processamento execute os métodos descritos aqui. O portador legível em computador pode ser qualquer tipo adequado de portador, tal como uma memória de estado sólido (por exemplo, uma memória apenas de leitura (ROM), uma memória de acesso randômico (RAM), etc.), uma memória magnética, uma memória ótica, um outro tipo de memória, ou ondas / sinais modulados (tais como ondas / sinais modulados com freqüência de rádio, freqüência de áudio ou freqüência ótica) contendo um conjunto apropriado de instruções de computador que fariam com que uma unidade de processamento realizasse as técnicas descritas aqui.
Tendo descrito em detalhes as modalidades de exemplo da presente invenção, incluindo os métodos de operação de exemplo, é para ser compreendido que as operações descritas aqui são apresentadas apenas a título de exemplo e não têm por significado limitarem o escopo da presente invenção, o qual é definido pelas reivindicações a seguir.

Claims (4)

1. Método realizado por um primeiro sistema (32) para estabelecer um percurso de comunicação bidirecional (24, 36) entre o primeiro sistema (32) e um segundo sistema (22) para um troca de uma ou mais mensagens, o método caracterizado por compreender:
a geração de um primeiro par de chaves tendo uma primeira chave pública e uma primeira chave privada;
a geração de um segundo par de chaves tendo uma segunda chave pública e uma segunda chave privada, a segunda chave pública sendo gerada com base em um segredo conhecido compartilhado conhecido pelo primeiro sistema (32) e pelo segundo sistema (22);
em que o segredo compatilhardo é comunicado através de um canal seguro fora de banda (34);
o envio da segunda chave pública e da primeira chave pública para o segundo sistema (22);
a recepção de uma terceira chave pública e de uma quarta chave pública geradas pelo segundo sistema (22), a quarta chave pública sendo gerada com base no segredo compartilhado; e o cálculo de uma chave mestra com base na primeira chave privada, na segunda chave privada, na terceira chave pública e na quarta chave pública, em que a chave mestra é configurada para ser usada na criptografia de uma ou mais mensagens.
2/4 (22) receber uma segunda cadeia de teste gerada pelo segundo sistema (22); e autenticar o segundo sistema (22) com a segunda cadeia de teste e a chave mestra.
2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de ainda compreender:
gerar uma cadeia de teste;
enviar uma primeira cadeia de teste ao segundo sistema
Petição 870180138959, de 08/10/2018, pág. 10/15
3/4
9. Método, de acordo com a reivindicação 5, caracterizado pelo fato de que c > dispositivo móvel sem fio (32) e < d sistema hospedeiro (22) são endereçados com endereços de e-mail ou endereços IP. 10. Método, de acordo com a reivindicação 5, caracterizado pelo fato de que o método SPEKE (Simple Password Exponential Key Exchange) modificado é utilizado no cálculo da chave mestra. 11. Método, de acordo com a reivindicação 1,
caracterizado pelo fato de que o primeiro sistema compreende um sistema hospedeiro oferecendo serviços (46), e em que o segundo sistema compreende um dispositivo sem fio móvel (48).
12. Método, de acordo com a reivindicação 1, caracterizado pelo fato de ainda compreender a criptografia de uma ou mais mensagens usando a chave mestra.
13. Sinal digital caracterizado pelo fato de conter uma ou mais mensagens que são criptografadas de acordo com o método conforme definido na reivindicação 12.
14. Portadora que pode ser lida em computador, caracterizada pelo fato de conter instruções de processamento adaptadas para fazerem com que uma unidade de processamento execute o método conforme definido na reivindicação 1.
15. Primeiro sistema (32) para estabelecer um percurso de comunicação bidirecional (24, 36) para um segundo sistema (22) para um troca de uma ou mais mensagens, o sistema caracterizado por compreender:
um meio para a geração de um primeiro par de chaves que tem uma primeira chave pública e uma primeira chave
Petição 870180138959, de 08/10/2018, pág. 12/15
3. Método, de acordo com a reivindicação 2, caracterizado pelo fato de ainda compreender uma etapa de receber uma carga útil de dados tendo uma entrada de serviço de Descrição, Descoberta e Integração Universais (UDDI), antes da etapa de receber uma segunda cadeia de teste gerada pelo segundo sistema (22).
4. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o primeiro sistema compreende uma dispositivo móvel sem fio (32).
5. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o segundo sistema compreende um sistema hospedeiro (22) oferecendo serviços.
6. Método, de acordo com a reivindicação 5, caracterizado pelo fato de que o segredo compartilhado compreende um número de identificação pessoal (PIN) gerado automaticamente pelo sistema hospedeiro (22).
7. Método, de acordo com a reivindicação 4, caracterizado pelo fato de que o segredo compartilhado é recebido do segundo sistema (22) através de uma interface web seguindo uma solicitação pelo primeiro sistema (32).
8. Método, de acordo com a reivindicação 5, caracterizado pelo fato de que a troca de uma ou mais mensagens compreende uma troca de mensagens de e-mail, mensagens XML baseadas em http ou mensagens WML baseadas em http.
Petição 870180138959, de 08/10/2018, pág. 11/15
4/4 privada;
um meio para a geração de um segundo par de chaves tendo uma segunda chave pública e uma segunda chave privada, a segunda chave pública sendo gerada com base em um segredo compartilhado conhecido pelo primeiro sistema (32) e pelo segundo sistema (22);
em que o segredo compartilhado é comunicado através de um canal seguro fora de banda (34);
um meio para o envio da segunda chave pública e da primeira chave pública para o segundo sistema (22);
um meio para a recepção de uma terceira chave pública e de uma quarta chave pública geradas pelo segundo sistema (22), a quarta chave pública sendo gerada com base no segredo compartilhado; e um meio para o cálculo de uma chave mestra com base na primeira chave privada, na segunda chave privada, na terceira chave pública e na quarta chave pública, em que a chave mestra é configurada para ser usada na criptografia de uma ou mais mensagens.
BRPI0509538A 2004-04-02 2005-03-30 método, sinal digital, portadora, e primeiro sistema para estabelecer um percurso de comunicação bidirecional BRPI0509538B1 (pt)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US55909204P 2004-04-02 2004-04-02
US55964604P 2004-04-05 2004-04-05
PCT/CA2005/000466 WO2005096542A1 (en) 2004-04-02 2005-03-30 Deploying and provisioning wireless handheld devices

Publications (2)

Publication Number Publication Date
BRPI0509538A BRPI0509538A (pt) 2007-09-18
BRPI0509538B1 true BRPI0509538B1 (pt) 2019-01-15

Family

ID=35064141

Family Applications (1)

Application Number Title Priority Date Filing Date
BRPI0509538A BRPI0509538B1 (pt) 2004-04-02 2005-03-30 método, sinal digital, portadora, e primeiro sistema para estabelecer um percurso de comunicação bidirecional

Country Status (12)

Country Link
US (4) US7885411B2 (pt)
EP (1) EP1735945B1 (pt)
JP (1) JP4701238B2 (pt)
KR (1) KR20060132026A (pt)
CN (1) CN101023622B (pt)
AT (1) ATE438973T1 (pt)
AU (2) AU2005228061A1 (pt)
BR (1) BRPI0509538B1 (pt)
CA (1) CA2561796C (pt)
DE (1) DE602005015831D1 (pt)
HK (1) HK1095950A1 (pt)
WO (1) WO2005096542A1 (pt)

Families Citing this family (67)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1408669A1 (en) * 1998-07-03 2004-04-14 Nokia Corporation Secure session set up based on the wireless application protocol
CA2277633C (en) 1999-07-19 2009-10-20 Certicom Corp. Split-key key-agreement protocol
US7370350B1 (en) * 2002-06-27 2008-05-06 Cisco Technology, Inc. Method and apparatus for re-authenticating computing devices
US7861078B2 (en) * 2005-10-14 2010-12-28 Juniper Networks, Inc. Password-authenticated asymmetric key exchange
KR100772180B1 (ko) 2005-12-08 2007-11-01 한국전자통신연구원 이더넷 기반의 수동형 광네트워크에서 광종단장치와광가입자장치들 간에 보안 채널 설정 방법 및 이를 위한프레임 전송 제어용 다중점 제어 프로토콜 메시지 구조
US8086872B2 (en) 2005-12-08 2011-12-27 Electronics And Telecommunications Research Institute Method for setting security channel based on MPCP between OLT and ONUs in EPON, and MPCP message structure for controlling frame transmission
CN101554011A (zh) * 2006-09-21 2009-10-07 交互数字技术公司 群组式密钥的生成
US7870255B2 (en) * 2006-10-03 2011-01-11 Research In Motion Limited Access control system and method for wireless application provisioning
US8050403B2 (en) * 2007-03-06 2011-11-01 Research In Motion Limited Method and apparatus for generating a public key in a manner that counters power analysis attacks
US8131994B2 (en) 2007-06-01 2012-03-06 Cisco Technology, Inc. Dual cryptographic keying
US8838953B2 (en) * 2007-06-05 2014-09-16 Stmicroelectronics, Inc. System and method for using an out-of-band device to program security keys
US8228902B2 (en) * 2007-07-20 2012-07-24 Cisco Technology, Inc. Separation of validation services in VoIP address discovery system
US8228903B2 (en) * 2007-07-20 2012-07-24 Cisco Technology, Inc. Integration of VoIP address discovery with PBXs
US8121114B2 (en) 2009-02-12 2012-02-21 Cisco Technology, Inc. Prevention of voice over IP spam
US8204047B2 (en) * 2007-07-20 2012-06-19 Cisco Technology, Inc. Using PSTN reachability to verify caller ID information in received VoIP calls
US8223755B2 (en) * 2007-07-20 2012-07-17 Cisco Technology, Inc. Node reputation based on knowledge of PSTN calls
US8274968B2 (en) * 2007-07-20 2012-09-25 Cisco Technology, Inc. Restriction of communication in VoIP address discovery system
US8199746B2 (en) 2007-07-20 2012-06-12 Cisco Technology, Inc. Using PSTN reachability to verify VoIP call routing information
US8072967B2 (en) * 2007-07-20 2011-12-06 Cisco Technology, Inc. VoIP call routing information registry including hash access mechanism
US8228904B2 (en) * 2007-07-20 2012-07-24 Cisco Technology, Inc. Using PSTN reachability in anonymous verification of VoIP call routing information
US8208635B2 (en) 2007-11-13 2012-06-26 Rosemount Inc. Wireless mesh network with secure automatic key loads to wireless devices
US7522723B1 (en) * 2008-05-29 2009-04-21 Cheman Shaik Password self encryption method and system and encryption by keys generated from personal secret information
DE102009032465B4 (de) * 2008-07-16 2016-10-13 Infineon Technologies Ag Sicherheit in Netzwerken
US20100042841A1 (en) * 2008-08-15 2010-02-18 Neal King Updating and Distributing Encryption Keys
US8223754B2 (en) * 2009-02-09 2012-07-17 Cisco Technology, Inc. Auto-configured voice over internet protocol
US8296567B2 (en) * 2009-07-15 2012-10-23 Research In Motion Limited System and method for exchanging key generation parameters for secure communications
US8645695B2 (en) * 2009-10-07 2014-02-04 Blackberry Limited System and method for managing security key architecture in multiple security contexts of a network environment
US8886935B2 (en) * 2010-04-30 2014-11-11 Kabushiki Kaisha Toshiba Key management device, system and method having a rekey mechanism
EP2509276B1 (de) * 2011-04-05 2013-11-20 F. Hoffmann-La Roche AG Verfahren zum sicheren Übertragen von elektronischen Daten über eine Datenkommunikationsverbindung zwischen einem Gerät und einem weiteren Gerät
US9093395B2 (en) * 2011-09-02 2015-07-28 Avogy, Inc. Method and system for local control of defect density in gallium nitride based electronics
JP5367039B2 (ja) * 2011-09-30 2013-12-11 株式会社東芝 サーバ装置及びプログラム
JP5643741B2 (ja) * 2011-12-02 2014-12-17 株式会社東芝 認証装置、認証方法および認証プログラム
US10148438B2 (en) * 2012-04-03 2018-12-04 Rally Health, Inc. Methods and apparatus for protecting sensitive data in distributed applications
KR101301609B1 (ko) * 2012-05-31 2013-08-29 서울대학교산학협력단 비밀키 생성 장치 및 방법, 그리고 그 방법을 컴퓨터에서 실행시키기 위한 프로그램을 기록한 기록매체
US9716589B2 (en) * 2013-04-22 2017-07-25 Unisys Corporation Secured communications arrangement applying internet protocol security
SI3033102T2 (sl) 2013-08-13 2024-03-29 Northwestern University Peptid konjugirani delci
EP3089091B1 (en) * 2014-05-02 2020-03-11 Barclays Execution Services Limited Transaction authentication
WO2015188151A1 (en) * 2014-06-06 2015-12-10 Bittorrent, Inc. Securely sharing information via a public key- value data store
US20160065374A1 (en) * 2014-09-02 2016-03-03 Apple Inc. Method of using one device to unlock another device
US20170091887A1 (en) * 2015-09-24 2017-03-30 Yahoo! Inc. Method for accessing an online account after the owner's death
EP3363175A1 (en) * 2015-10-15 2018-08-22 Otis Elevator Company Software updating device
SG10202109555WA (en) 2016-02-23 2021-09-29 Nchain Holdings Ltd Agent-based turing complete transactions integrating feedback within a blockchain system
AU2017223138B2 (en) 2016-02-23 2022-02-10 nChain Holdings Limited Method and system for efficient transfer of cryptocurrency associated with a payroll on a blockchain that leads to an automated payroll method and system based on smart contracts
EP3420669B1 (en) 2016-02-23 2021-03-24 Nchain Holdings Limited Cryptographic method and system for secure extraction of data from a blockchain
HUE040631T2 (hu) 2016-02-23 2019-03-28 Nchain Holdings Ltd Közös titok meghatározása biztonsági információcseréhez, és hierarchikus, determinisztikus rejtjel kulcsok
WO2017145003A1 (en) 2016-02-23 2017-08-31 nChain Holdings Limited Blockchain-based exchange with tokenisation
GB2561729A (en) 2016-02-23 2018-10-24 Nchain Holdings Ltd Secure multiparty loss resistant storage and transfer of cryptographic keys for blockchain based systems in conjunction with a wallet management system
GB2562621A (en) 2016-02-23 2018-11-21 Nchain Holdings Ltd System and method for controlling asset-related actions via a blockchain
SG10202007904SA (en) 2016-02-23 2020-10-29 Nchain Holdings Ltd A method and system for securing computer software using a distributed hash table and a blockchain
EP3420517B1 (en) 2016-02-23 2022-07-06 nChain Holdings Limited A method and system for the secure transfer of entities on a blockchain
EP3257006B1 (en) 2016-02-23 2018-10-03 Nchain Holdings Limited Personal device security using elliptic curve cryptography for secret sharing
EP3257191B1 (en) 2016-02-23 2018-04-11 Nchain Holdings Limited Registry and automated management method for blockchain-enforced smart contracts
EP3420674B1 (en) 2016-02-23 2021-03-24 Nchain Holdings Limited Blockchain-implemented method for control and distribution of digital content
MX2018010048A (es) 2016-02-23 2019-01-21 Nchain Holdings Ltd Sistema universal de tokenizacion para criptomonedas basadas en cadena de bloques.
AU2017222470B2 (en) 2016-02-23 2023-01-12 nChain Holdings Limited Tokenisation method and system for implementing exchanges on a blockchain
US11212276B2 (en) * 2016-07-01 2021-12-28 Intel Corporation Single pairing for multiple technologies
EP3364596A1 (en) * 2017-02-15 2018-08-22 Koninklijke Philips N.V. Key exchange devices and method
EP3402118A1 (en) * 2017-05-10 2018-11-14 Koninklijke Philips N.V. Key agreement devices and method
US10530581B2 (en) * 2017-09-08 2020-01-07 Fujitsu Limited Authenticated broadcast encryption
US10819689B2 (en) 2018-05-03 2020-10-27 Honeywell International Inc. Systems and methods for encrypted vehicle data service exchanges
US10715511B2 (en) * 2018-05-03 2020-07-14 Honeywell International Inc. Systems and methods for a secure subscription based vehicle data service
GB201815396D0 (en) * 2018-09-21 2018-11-07 Nchain Holdings Ltd Computer implemented system and method
US11063921B2 (en) 2018-11-06 2021-07-13 International Business Machines Corporation Extracting data from passively captured web traffic that is encrypted in accordance with an anonymous key agreement protocol
CN112118568B (zh) * 2019-06-21 2022-02-25 华为技术有限公司 一种设备身份鉴权的方法及设备
TWI730355B (zh) * 2019-07-23 2021-06-11 新加坡商優納比控股私人有限公司 無線通信的動態金鑰產生方法
JP7037705B2 (ja) 2020-03-13 2022-03-16 株式会社ソリトンシステムズ 機密データ管理装置、プログラム及び記録媒体
US11882215B2 (en) * 2021-05-21 2024-01-23 Zoom Video Communications, Inc. Handling joining and leaving of participants in videoconferencing with end-to-end encryption

Family Cites Families (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5491749A (en) 1993-12-30 1996-02-13 International Business Machines Corporation Method and apparatus for entity authentication and key distribution secure against off-line adversarial attacks
US5491750A (en) * 1993-12-30 1996-02-13 International Business Machines Corporation Method and apparatus for three-party entity authentication and key distribution using message authentication codes
US6091820A (en) * 1994-06-10 2000-07-18 Sun Microsystems, Inc. Method and apparatus for achieving perfect forward secrecy in closed user groups
US5761305A (en) * 1995-04-21 1998-06-02 Certicom Corporation Key agreement and transport protocol with implicit signatures
US6487661B2 (en) 1995-04-21 2002-11-26 Certicom Corp. Key agreement and transport protocol
JPH1115373A (ja) * 1997-06-20 1999-01-22 Fuji Xerox Co Ltd 公開鍵暗号方式
US6219421B1 (en) * 1997-10-24 2001-04-17 Shaul O. Backal Virtual matrix encryption (VME) and virtual key cryptographic method and apparatus
US6279110B1 (en) * 1997-11-10 2001-08-21 Certicom Corporation Masked digital signatures
US6336188B2 (en) * 1998-05-01 2002-01-01 Certicom Corp. Authenticated key agreement protocol
CA2241705C (en) 1998-06-26 2006-06-20 Certicom Corp. A method for preventing key-share attacks
EP1408669A1 (en) * 1998-07-03 2004-04-14 Nokia Corporation Secure session set up based on the wireless application protocol
CA2255285C (en) 1998-12-04 2009-10-13 Certicom Corp. Enhanced subscriber authentication protocol
JP4556277B2 (ja) 1999-03-30 2010-10-06 ソニー株式会社 情報処理装置および方法、情報処理システム、並びにプログラム格納媒体
CA2277633C (en) * 1999-07-19 2009-10-20 Certicom Corp. Split-key key-agreement protocol
US7181014B1 (en) * 1999-09-10 2007-02-20 Cisco Technology, Inc. Processing method for key exchange among broadcast or multicast groups that provides a more efficient substitute for Diffie-Hellman key exchange
US6718467B1 (en) * 1999-10-28 2004-04-06 Cisco Technology, Inc. Password based protocol for secure communications
US7711122B2 (en) * 2001-03-09 2010-05-04 Arcot Systems, Inc. Method and apparatus for cryptographic key storage wherein key servers are authenticated by possession and secure distribution of stored keys
DE60236381D1 (de) * 2001-04-12 2010-06-24 Research In Motion Ltd System und Verfahren zum dynamischen Schieben von Informationen auf drahtlose Datenübertragungsvorrichtungen
EP1384126A2 (en) * 2001-04-24 2004-01-28 Hewlett-Packard Company An information security system
JP4255046B2 (ja) * 2001-04-27 2009-04-15 日本電信電話株式会社 暗号通信路の確立方法、プログラム及びプログラム媒体、並びに、暗号通信システム
US7181015B2 (en) * 2001-07-31 2007-02-20 Mcafee, Inc. Method and apparatus for cryptographic key establishment using an identity based symmetric keying technique
US7127063B2 (en) * 2001-12-31 2006-10-24 Certicom Corp. Method and apparatus for computing a shared secret key
US7353382B2 (en) * 2002-08-08 2008-04-01 Fujitsu Limited Security framework and protocol for universal pervasive transactions
US7784684B2 (en) * 2002-08-08 2010-08-31 Fujitsu Limited Wireless computer wallet for physical point of sale (POS) transactions
US20040073795A1 (en) * 2002-10-10 2004-04-15 Jablon David P. Systems and methods for password-based connection
US7328282B2 (en) * 2003-10-23 2008-02-05 International Business Machines Corporation Aspect oriented web service invocation

Also Published As

Publication number Publication date
US20120063599A1 (en) 2012-03-15
US8090107B2 (en) 2012-01-03
BRPI0509538A (pt) 2007-09-18
CA2561796A1 (en) 2005-10-13
WO2005096542A1 (en) 2005-10-13
US8615086B2 (en) 2013-12-24
AU2005228061A1 (en) 2005-10-13
CA2561796C (en) 2012-04-17
ATE438973T1 (de) 2009-08-15
AU2009248475A1 (en) 2010-01-07
EP1735945A1 (en) 2006-12-27
EP1735945B1 (en) 2009-08-05
US20120294440A1 (en) 2012-11-22
JP2007531422A (ja) 2007-11-01
AU2009248475B2 (en) 2012-06-14
US8238558B2 (en) 2012-08-07
CN101023622B (zh) 2010-12-08
JP4701238B2 (ja) 2011-06-15
KR20060132026A (ko) 2006-12-20
DE602005015831D1 (de) 2009-09-17
US7885411B2 (en) 2011-02-08
EP1735945A4 (en) 2007-06-20
HK1095950A1 (en) 2007-05-18
CN101023622A (zh) 2007-08-22
US20050232428A1 (en) 2005-10-20
US20110103588A1 (en) 2011-05-05

Similar Documents

Publication Publication Date Title
BRPI0509538B1 (pt) método, sinal digital, portadora, e primeiro sistema para estabelecer um percurso de comunicação bidirecional
US8218773B2 (en) Systems and methods to securely generate shared keys
CA2564909C (en) Systems and methods to securely generate shared keys
US7899185B2 (en) Real privacy management authentication system
Hallsteinsen et al. Using the mobile phone as a security token for unified authentication
US8144875B2 (en) Method and system for establishing real-time authenticated and secured communications channels in a public network
Dorey et al. Indiscreet Logs: Diffie-Hellman Backdoors in TLS.
Paul et al. Comparative analysis of various PPP authentication Protocols
Lakshmi et al. JPermit: usable and secure registration of guest-phones into enterprise VoIP network
AU2012202300B2 (en) Re-keying over a bidirectional communication path
Singh et al. Mechanisms for Security and Authentication of Wi-Fi devices

Legal Events

Date Code Title Description
B25D Requested change of name of applicant approved

Owner name: BLACKBERRY LIMITED (CA)

B25G Requested change of headquarter approved

Owner name: BLACKBERRY LIMITED (CA)

B07A Application suspended after technical examination (opinion) [chapter 7.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 15/01/2019, OBSERVADAS AS CONDICOES LEGAIS.