BR102019015369B1 - sistemas e método para provisionar uma conexão segura a uma conexão interdispositivo - Google Patents

sistemas e método para provisionar uma conexão segura a uma conexão interdispositivo Download PDF

Info

Publication number
BR102019015369B1
BR102019015369B1 BR102019015369-5A BR102019015369A BR102019015369B1 BR 102019015369 B1 BR102019015369 B1 BR 102019015369B1 BR 102019015369 A BR102019015369 A BR 102019015369A BR 102019015369 B1 BR102019015369 B1 BR 102019015369B1
Authority
BR
Brazil
Prior art keywords
key
connection
cloud architecture
secure
connection protocol
Prior art date
Application number
BR102019015369-5A
Other languages
English (en)
Other versions
BR102019015369B8 (pt
BR102019015369A2 (pt
Inventor
Brian Jeremiah Murray
Narayanan Gopalakrishnan
Original Assignee
Clover Network, Inc
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 Clover Network, Inc filed Critical Clover Network, Inc
Publication of BR102019015369A2 publication Critical patent/BR102019015369A2/pt
Publication of BR102019015369B1 publication Critical patent/BR102019015369B1/pt
Publication of BR102019015369B8 publication Critical patent/BR102019015369B8/pt

Links

Images

Classifications

    • 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/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3227—Aspects of commerce using mobile devices [M-devices] using secure elements embedded in M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • 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
    • H04L63/0442—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 wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/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/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0863—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving passwords or one-time passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0877—Generation of secret information including derivation or calculation of cryptographic keys or passwords using additional device, e.g. trusted platform module [TPM], smartcard, USB or hardware security module [HSM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • 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
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/50—Secure pairing of devices
    • 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
    • H04L2209/805—Lightweight hardware, e.g. radio-frequency identification [RFID] or sensor
    • 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
    • H04L63/067—Network architectures or network communication protocols for network security for supporting key management in a packet data network using one-time keys
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • 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
    • 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/088—Usage controlling of secret information, e.g. techniques for restricting cryptographic keys to pre-authorized uses, different access levels, validity of crypto-period, different key- or password length, or different strong and weak cryptographic algorithms
    • 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/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H04L9/0897—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage involving additional devices, e.g. trusted platform module [TPM], smartcard or USB
    • 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
    • H04L9/3228—One-time or temporary data, i.e. information which is sent for every authentication or authorization, e.g. one-time-password, one-time-token or one-time-key
    • 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/3271—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 challenge-response
    • H04L9/3273—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 challenge-response for mutual authentication
    • 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/3297—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 involving time stamps, e.g. generation of time stamps
    • 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]
    • 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/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H04W12/0431—Key distribution or pre-distribution; Key agreement
    • H04W12/0609—
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Métodos e sistemas relacionados ao fornecimento de uma conexão segura são descritos. Um método descrito inclui armazenar um segredo de dispositivo em um elemento seguro em um primeiro dispositivo, armazenando um mapeamento do segredo de dispositivo para um identificador de dispositivo do primeiro dispositivo em uma arquitetura de nuvem, gerar uma chave de pareamento usando um primeiro gerador de chave de protocolo de conexão no elemento seguro e no segredo de dispositivo, gerar a chave de pareamento usando um segundo gerador de chave de protocolo de conexão na arquitetura de nuvem e no segredo de dispositivo. O método também inclui transmitir a chave de pareamento da arquitetura de nuvem para um segundo dispositivo em resposta ao recebimento do identificador de dispositivo, autenticar mutuamente o primeiro e o segundo dispositivo usando a chave de pareamento e adicionar a conexão segura à conexão interdispositivo usando a chave de pareamento como armazenada no primeiro dispositivo e como armazenada no segundo dispositivo.

Description

ANTECEDENTES
[001] O estabelecimento de conexões seguras entre dispositivos de comunicação é essencial para preservar a privacidade e a integridade de dados da informação que passa entre eles. As conexões sem fio são particularmente vulneráveis a ataques a partir de entidades mal-intencionadas que poderiam usar outros dispositivos sem fio próximos para realizar esse tipo de ataque. Os métodos de segurança atuais são projetados para resistir aos tipos mais comuns de ataques, como ataques man-in-the-middle (homem no meio) (MITM), ataques de negação de serviço (DoS) ou ataques de envenenamento por protocolo de resolução de endereço (ARP). Enquanto muitas das nuances das vulnerabilidades de comunicação segura sejam conhecidas, a escolha de uma configuração de segurança específica para um determinado conjunto de dispositivos conectados sem fio não é trivial. Por exemplo, uma configuração de segurança pode ser altamente dependente das capacidades exclusivas das arquiteturas de software e hardware em um tipo de dispositivo, tal como os recursos significativos disponíveis para um sistema de um computador pessoal conectado a um roteador Wi-Fi. Alternativamente, dispositivos de comunicação sem fio podem contar com comunicação de curto alcance, tal como no caso de um smartphone usando comunicação de campo próximo, para prover um nível de segurança usando o alcance limitado da transmissão sem fio. Para atender a esse contexto em constante evolução, novas soluções de segurança de conexão estão em constante desenvolvimento.
[002] Dispositivos que se comunicam através de conexões interdispositivo sem fio geralmente colaboram em um sistema ou rede, como exemplificado no crescente paradigma da Internet das Coisas (IoT). Como muitos desses dispositivos são dependentes de informações privadas, o estabelecimento de conexões seguras entre dois ou mais dispositivos é uma necessidade comum em configurações pessoais, domésticas e corporativas. Um exemplo geral que abrange essas configurações inclui a conexão segura entre um dispositivo de usuário pessoal multifuncional, tal como um smartphone, e um dispositivo de aplicação, às vezes chamado de “dongle” ou dispositivo periférico. Dispositivos de usuário pessoal utilizam um conjunto de protocolos de comunicação para maximizar a segurança e a compatibilidade interdispositivo, enquanto dispositivos de aplicação são projetados com hardware e software limitados a fim de terem um fator de forma conveniente para uso pessoal e permanecerem competitivos no mercado. Impulsionado por essa assimetria na funcionalidade do dispositivo, o estabelecimento de uma conexão segura entre um dispositivo de usuário pessoal e um dispositivo de aplicação pode ser limitado pelo dispositivo de aplicação. Consideração cuidadosa deve ser dada ao projeto de um sistema para prover tal uma conexão que tenha usabilidade e segurança.
[003] O protocolo de Segurança de Camada de Transporte (TLS) é um protocolo de segurança personalizável e bem desenvolvido que pode ser usado para proteger uma conexão de comunicação sem fio entre um dispositivo de usuário pessoal e um dispositivo de aplicação. TLS pode ser configurado para fornecer uma conexão segura usando esquemas de encriptação de chave simétrica ou assimétrica. Autenticação com TLS pode ser estabelecida usando métodos definidos pelo framework de infraestrutura de chave pública (PKI), por exemplo, com o uso de certificados assinado por um terceiro confiável. Além disso, dois ou mais dispositivos podem estabelecer comunicação segura por meio de um processo no qual um servidor TLS é instanciado em um dispositivo, enquanto os outros dispositivos podem se comunicar com o servidor TLS como clientes. Posteriormente, o servidor e os clientes podem negociar os esquemas de autenticação e encriptação de chaves desejados por meio de um processo chamado “handshake”, no qual ambos concordam com métodos de séries de algoritmos executáveis predefinidos e transferências de informações de servidor- cliente. É de extrema importância que os métodos de autenticação e encriptação de chave dentro do handshake sejam implementados com os dispositivos exclusivos do sistema em mente para ativar o potencial máximo de segurança da conexão segura.
SUMÁRIO
[004] Métodos e sistemas relacionados ao fornecimento de uma conexão segura com uma conexão interdispositivo são descritos. Um sistema inclui um primeiro dispositivo, um segundo dispositivo e uma arquitetura de nuvem. O primeiro dispositivo tem um elemento seguro que armazena um segredo de dispositivo, instancia um primeiro módulo de protocolo de conexão, e instancia um primeiro gerador de chave de protocolo de conexão. A arquitetura de nuvem armazena um mapeamento a partir do segredo de dispositivo para uma identificação do primeiro dispositivo e instancia um segundo gerador de chave de protocolo de conexão. O primeiro o gerador de chave de protocolo de conexão e o segundo gerador de chave de protocolo de conexão são configurados para gerar uma chave de pareamento usando o segredo de dispositivo. O segundo dispositivo tem um processador que instancia um segundo módulo de protocolo de conexão, que é comunicativamente conectado ao primeiro dispositivo através da conexão interdispositivo, que é configurado para receber a identificação do primeiro dispositivo a partir do primeiro dispositivo, e que é configurado para trocar a identificação do primeiro dispositivo para chave de pareamento com a arquitetura de nuvem em uma conexão de rede. O primeiro módulo de protocolo de conexão e o segundo módulo de protocolo de conexão são configurados para autenticar mutuamente usando a chave de pareamento e adicionar a conexão segura à conexão interdispositivo usando a chave de pareamento.
[005] Um método descrito inclui armazenar um segredo de dispositivo em um elemento seguro no primeiro dispositivo, e armazenar um mapeamento a partir do segredo de dispositivo para um identificador de dispositivo do primeiro dispositivo em uma arquitetura de nuvem. O método inclui gerar uma chave de pareamento usando um primeiro gerador de chave de protocolo de conexão sobre o elemento seguro e o segredo de dispositivo, e gerar a chave de pareamento usando um segundo gerador de chave de protocolo de conexão sobre a arquitetura de nuvem e a chave do dispositivo. O método inclui transmissão da chave de pareamento a partir da arquitetura de nuvem para o segundo dispositivo em resposta ao recebimento do identificador de dispositivo. O método inclui autenticar mutuamente o primeiro e o segundo dispositivo usando a chave de pareamento como armazenada no primeiro dispositivo e como armazenada no segundo dispositivo. O método inclui adicionar a conexão segura à conexão interdispositivo usando a chave de pareamento como armazenada no primeiro dispositivo e armazenada no segundo dispositivo.
[006] Um sistema compreende um primeiro dispositivo, um segundo dispositivo, um elemento seguro, uma arquitetura de nuvem, um primeiro gerador de chave de protocolo de conexão, um segundo gerador de chave de protocolo de conexão, um primeiro módulo de protocolo de conexão, uma aplicação e um segundo módulo de protocolo de conexão. O primeiro dispositivo e o segundo dispositivo estão conectados com uma conexão interdispositivo. O primeiro dispositivo tem um elemento seguro que armazena um segredo de dispositivo. A arquitetura de nuvem armazena o segredo de dispositivo e um mapeamento a partir do segredo de dispositivo para um identificador de dispositivo do primeiro dispositivo. O primeiro gerador de chave de protocolo de geração está no elemento seguro configurado para gerar uma chave de pareamento usando o segredo de dispositivo. O segundo gerador de chave de protocolo de conexão está na arquitetura de nuvem configurada para gerar a chave de pareamento usando o segredo de dispositivo. O elemento seguro no primeiro dispositivo instancia o primeiro módulo de protocolo de conexão. O segundo módulo de protocolo de conexão está no segundo dispositivo. A aplicação está no segundo dispositivo, recebe a chave de pareamento a partir da arquitetura de nuvem e instancia o segundo módulo de protocolo de conexão. A arquitetura de nuvem é configurada para transmitir a chave de pareamento para o segundo dispositivo em resposta ao recebimento do identificador de dispositivo. O primeiro módulo de protocolo de conexão e o segundo módulo de protocolo de conexão são configurados para mutuamente autenticar usando a chave de pareamento e adicionar uma conexão segura à conexão interdispositivo usando a chave de pareamento.
BREVE DESCRIÇÃO DOS DESENHOS
[007] Fig. 1 ilustra um sistema para fornecer uma conexão segura a uma conexão interdispositivo entre um primeiro dispositivo e um segundo dispositivo, auxiliado por uma arquitetura de nuvem.
[008] Fig. 2 ilustra o sistema da Fig. 1, no qual o fornecimento da conexão segura usa um método de encriptação de chave OTP para gerar uma chave de pareamento.
[009] Fig. 3 ilustra um fluxograma e um diagrama de blocos que descrevem um exemplo do método de encriptação de chave OTP usado pelo sistema da Fig. 2.
[010]Fig. 4 ilustra o sistema da Fig. 2 com elementos e módulos adicionaisde segurança e comunicações para a arquitetura de nuvem.
[011] Fig. 5 ilustra o sistema da Fig. 4 com elementos e módulos adicionais que permitem que o sistema seja utilizado com dados de pagamento seguro.
DESCRIÇÃO DETALHADA
[012] Métodos específicos e sistemas para fornecer uma conexão segura entre dois dispositivos de acordo com o sumário acima são fornecidos nesta seção. Os métodos e sistemas descritos nesta seção são modalidades não limitativas da invenção e são fornecidos apenas para fins explicativos. A descrição detalhada destas modalidades específicas não deve ser aplicada para restringir o âmbito completo da invenção.
[013] Em modalidades específicas da invenção, um sistema é fornecido para adicionar uma conexão segura a uma conexão interdispositivo entre dispositivos de comunicação. Por exemplo, a conexão segura pode ser uma conexão de segurança de camada de transporte (TLS) que utiliza o protocolo TLS juntamente com um segredo compartilhado que é diretamente fornecido ou derivado dos dois dispositivos. Como outro exemplo, a conexão segura pode ser uma conexão de segurança de camada de transporte de datagrama (DTLS). Ao longo desta descrição, a TLS será usada como um tipo de conexão exemplar e protocolo. No entanto, a conexão segura pode envolver outros protocolos nos quais uma única chave é usada para fornecer confidencialidade e integridade para um fluxo bidirecional de dados.
[014] O estabelecimento de uma conexão segura começa com a autenticação. Autenticação é o processo no qual um usuário, dispositivo, aplicação, servidor, arquitetura de nuvem ou outra entidade de sistema definida fornece sua identidade para uma terceira parte de comunicação. A autenticação mútua entre duas entidades de sistema é um processo de autenticação bidirecional. No protocolo TLS, a identidade do servidor TLS é autenticada para proteger o cliente de ficar inadvertidamente comprometido através do compartilhamento de informações privadas com uma terceira parte mal- intencionada. Quando transferência de informação bidirecional deve ser protegida, por exemplo, em uma comunicação segura de um primeiro dispositivo e um segundo dispositivo descrito aqui, autenticação mútua é desejada. Em princípio, autenticação mútua pode ser realizada usando uma variedade de esquemas de encriptação. Por exemplo, o padrão de chave pública X.509 permite que um esquema de autenticação usando chaves públicas contidas em certificados assinados para autenticar um servidor para um cliente que possui uma chave privada correspondente. Mais genericamente, métodos de encriptação de chave pública/privada podem ser usados em um sistema estabelecido dentro de um ambiente de infraestrutura de chave pública (PKI). O paradigma de encriptação de chave pública/privada é robusto usando métodos de geração de chave suficientemente complexos e métodos de e autenticação implementados por terceiros confiáveis. Chaves simétricas também podem ser usadas para autenticação mútua. Uma “chave simétrica” pode se referir a uma única chave criptográfica mantida por duas partes de comunicação. O uso de chaves simétricas para autenticação mútua pode ser possibilitado, por exemplo, por ambas as partes tendo acesso a um conjunto mutuamente conhecido de dados secretos. Encriptação de chave simétrica e protocolos de autenticação têm requisitos computacionais e de memória relativamente baixos, em comparação com chaves públicas/privadas, e podem ser usados para agilizar os handshakes de segurança mesmo em dispositivos simples.
[015] Múltiplos esquemas de encriptação e autenticação estão disponíveis para fornecer uma conexão segura usando protocolo TLS. A escolha do esquema é negociada em um processo chamado handshake antes do início do fornecimento. O handshake envolve um conjunto de métodos predefinidos conhecidos por ambas as partes em comunicação. Um exemplo de handshake de TLS pode ser executado da seguinte maneira. Primeiro, um segredo compartilhado é gerado entre um servidor e um cliente em uma conexão não segura através da troca de informação de sessão local a partir do servidor e cliente em combinação com um número acordado ou conjunto de dados gerados por algoritmo chamado uma chave secreta pré-mestra (“pre-master”). Segundo, o servidor e o cliente procedem com uma transformação pré-programada e secretamente acordada para transformar a chave secreta pré-mestra em uma chave secreta mestra. A transformação deve ser computacionalmente difícil de reverter para seguramente gerar uma chave de encriptação com uma conexão não segura. Uma troca de chaves Diffie-Hellman é um exemplo de método que pode ser usado para realizar as primeiras e segundas etapas descritas. Terceiro, a chave secreta mestre é usada por ambas as partes para fazer uma chave secreta de código de autenticação de mensagem (MAC) a ser usada durante a sessão para geração adicional de uma chave de sessão simétrica que pode ser usada novamente por ambas as partes para encriptar e decriptar dados de comunicação.
[016] Em modalidades específicas da invenção, a geração da conexão segura pode ser baseada em um conjunto de dados secretos chamado de “semente” com o qual uma chave criptográfica pode ser gerada. A semente pode ser qualquer conjunto de dados secretos, por exemplo, um número verdadeiramente gerado aleatoriamente. Além disso, a semente pode ser associada ou "mapeada" para outro conjunto de dados, tal como um identificador de dispositivo de um dispositivo no sistema. Uma semente mapeada dessa maneira pode ser designada como "segredo de dispositivo" e pode ser combinada com o identificador de dispositivo para aumentar a geração de chaves durante uma etapa subsequente. Um dispositivo pode ser atribuído a um identificador de dispositivo a partir de múltiplas fontes, incluindo um número de série do dispositivo, um número de série de um componente interno do dispositivo ou qualquer identificador exclusivo e categorizável após isso. Sementes e, equivalentemente, segredos de dispositivo podem ser utilizados no sistema como um segredo compartilhado em suporte à geração de chaves criptográficas, tal como a geração de chaves simétricas. Quando múltiplas sementes são mapeadas para múltiplos dispositivos através de seus respectivos identificadores de dispositivos, as múltiplas conexões mapeadas podem ser chamadas de “mapeamento”.
[017] Em modalidades específicas da invenção, o sistema pode prover uma conexão segura a uma conexão interdispositivo entre um primeiro dispositivo e um segundo dispositivo, em que uma arquitetura de nuvem pode estar em comunicação com o segundo dispositivo. Nestas modalidades, o primeiro dispositivo pode ter uma identificação do primeiro dispositivo e pode armazenar uma semente. Além disso, a arquitetura de nuvem pode armazenar a semente como um segredo de dispositivo mapeado para a identificação do primeiro dispositivo, associando a semente ao primeiro dispositivo. A identificação do primeiro dispositivo pode ser um número de série do primeiro dispositivo. A partir da semente armazenada no primeiro dispositivo, uma chave de pareamento pode ser gerada. O primeiro dispositivo pode transferir a identificação do primeiro dispositivo na conexão interdispositivo para o segundo dispositivo. O segundo dispositivo pode transmitir a identificação do primeiro dispositivo para a arquitetura de nuvem. A arquitetura de nuvem, em resposta, pode gerar uma chave de pareamento a partir do segredo de dispositivo associada à identificação do primeiro dispositivo e enviar a chave de pareamento ao segundo dispositivo. Com suas respectivas chaves de pareamento idênticas, o primeiro dispositivo e o segundo dispositivo podem concluir um handshake para fornecer a conexão segura, realizando autenticação mútua e negociação de esquema criptográfico.
[018] O primeiro dispositivo pode transmitir a identificação, e qualquer outra informação que possa ser usada para o handshake com o segundo dispositivo, para o segundo dispositivo de várias maneiras. De acordo com o exemplo provido diretamente acima, a informação pode ser transmitida usando a mesma conexão interdispositivos, discutida em outro lugar neste documento, à qual a conexão segura será adicionada. No entanto, a informação também pode ser transmitida usando outros canais. A transmissão da informação do primeiro dispositivo pode depender do hardware do primeiro dispositivo. Por exemplo, se o primeiro dispositivo tivesse uma tela de exibição, a informação pode ser exibida para um usuário e inserida manualmente no segundo dispositivo. Como outro exemplo, o primeiro dispositivo poderia ter uma conexão alternativa com ou sem fio com o segundo dispositivo ao qual a informação pode ser entregue.
[019] O primeiro dispositivo, o segundo dispositivo e a arquitetura de nuvem podem instanciar módulos. Módulos podem implementar abordagens específicas para as etapas do método descritas aqui. Etapas do módulo podem ser implementadas usando instruções de armazenamento em mídia legível por computador, não transitórias que podem ser executadas por um processador. Módulos em dispositivos de comunicação podem ser configurados para gerar chaves, estabelecer e fornecer conexões com outros dispositivos, negociar protocolos de comunicação, e conduzir outros processos.
[020] O primeiro dispositivo, o segundo dispositivo e a arquitetura de nuvem pode incluir elementos de hardware. Elementos de hardware podem ser telas sensíveis ao toque, telas planas, painéis táteis, leitores de impressão digital, sensores de imagem, microfones, alto-falantes, baterias, processadores, clocks relativos, clocks absolutos, leitores de cartões, memórias voláteis, memórias não voláteis e outros componentes auxiliares. Elementos de hardware podem permitir comunicações com e sem fio, incluindo servidores web, modems, rádios configuráveis, transceptores sem fio, antenas, front-ends de radiofrequência compreendendo codificadores-decodificadores, multiplexadores, comutadores, amplificadores e filtros, além de outros componentes de comunicação. Elementos de hardware direcionados para comunicações com fio podem ser implementados em conjunto com qualquer tipo de cabo de dados, incluindo ethernet, token ring, coaxial, fibra ótica, cabo serial, Cat2, cabo telefônico, cabo de barramento serial universal (USB) ou outros tipos de cabo de dados usados para enviar informação digital. Alternativamente, os cabos de dados podem ser específicos para a comunicação de informação de vídeo, em cujo caso os tipos de cabos de dados podem incluir vídeo-s, vídeo componente, DVI, HDMI, porta de display, CoaXPress e MHL e outros tipos de cabo de vídeo. Elementos de hardware direcionados para comunicações sem fio podem suportar qualquer tipo padrão ou banda de frequência, incluindo padrões como a série Wi-Fi / IEEE 802.11, EDGE, as séries EV-Do, Flash-ODFM, GPRS, os padrões HSPA, Lorawan, LTE, RTT, as séries UMTS, WiMAX, 6LoWPAN, as séries Bluetooth, IEEE 802.15.42006, Thread, UWB, USB sem fio, ZigBee, ANT+ e outros padrões de comunicação.
[021] O primeiro dispositivo, o segundo dispositivo e a arquitetura de nuvem podem ter elementos seguros de habilitação que são resistentes à ataques de violação ou comprometimento. Um exemplo de um elemento seguro é um processador seguro que geralmente pode funcionar como um processador padrão com desempenho reduzido, sendo alterado para limitar as funções não necessárias para segurança melhorada. Um circuito integrado de aplicação específica (ASIC) ou um circuito integrado discreto pode ser projetado para executar somente funções específicas seguras e não outras funções de finalidade geral e, portanto, pode ser um elemento seguro. Um distinto processador de uso geral pode ser modificado para ser um elemento seguro, ou incluir um elemento seguro, através de certas modificações, como o particionamento físico do elemento seguro a partir dos elementos gerais de hardware no mesmo chipe. Um elemento seguro também pode ser colocado no mesmo pacote como um processador geral, mas ser localizado em um chipe físico diferente daquele pacote. Alternativamente, um elemento seguro pode ser seguro removendo percursos de comunicação vulneráveis para impedir a comunicação com elementos não seguros. Elementos seguros podem ter armazenamento seguro independente do armazenamento padrão. O armazenamento seguro pode ser isolado fisicamente e logicamente do sistema com o qual o elemento seguro está configurado para operar. Em outra abordagem, um elemento seguro pode receber memória limitada para evitar a manipulação de dados, módulos ou protocolos armazenados e excluir a possibilidade de códigos maliciosos serem instalados ou executados localmente. Em um exemplo, o armazenamento seguro pode estar na faixa de duzentos bytes a oito kilobytes. Elementos seguros podem ser instalados permanentemente na placa de circuito ou no pacote de chipe nos quais estão montados para evitar a violação física e a remoção. Elementos seguros podem ser ainda mais seguros por embalagens resistentes a violações, como uma cobertura opaca, uma malha resistente a rasgos, um sensor de violação, um elemento seguro que exclui o armazenamento seguro se uma violação for detectada ou um elemento que destrua o elemento seguro se houver uma remoção do sistema.
[022] Em modalidades específicas da invenção, o primeiro dispositivo pode ser um dispositivo de aplicação e o segundo dispositivo pode ser um dispositivo de usuário pessoal. Um dispositivo de aplicação pode ser direcionado para uma ou poucas aplicações, e pode ser otimizado com componentes mínimos para se aproximar do custo mínimo de fabricação. Um dispositivo de aplicação pode ser configurado para atender a um propósito específico em conjunto com um dispositivo de usuário pessoal e, portanto, pode ser um “periférico” do dispositivo de usuário pessoal. Em um exemplo, um dispositivo de aplicação pode ter um elemento seguro que pode armazenar dados privados e instanciar um módulo de protocolo de conexão e um gerador de chave de protocolo de conexão. Em outro exemplo, um dispositivo de aplicação pode ter um leitor de dados com um módulo de processamento de dados, o último dos quais é instanciado por um elemento seguro e comunicativamente conectado ao referido leitor de dados. Em um terceiro exemplo, um dispositivo de aplicação pode incluir um elemento seguro que é um circuito integrado discreto e inclui menos de vinte kilobytes de armazenamento seguro gravável. O segundo dispositivo pode ser um dispositivo de usuário pessoal, como um smartphone, tablet, laptop ou outro dispositivo de comunicação que pode habilitar protocolos criptográficos e de autenticação. Um dispositivo de usuário pessoal pode executar inúmeros tipos de aplicações. Por exemplo, um dispositivo de usuário pessoal pode ter um processador que instancia um módulo de protocolo de conexão e um sistema operacional. No mesmo exemplo, o dispositivo de usuário pessoal pode conectar-se comunicativamente com outro dispositivo, bem como participar na autenticação e estabelecer uma conexão segura com esse dispositivo. Ao longo desta invenção, os termos “primeiro” e “segundo” dispositivo serão usados para se referir a esses dispositivos, onde o uso desses termos deve incluir, mas não se limitar aos exemplos providos acima, onde o primeiro dispositivo é um dispositivo de aplicação e o segundo dispositivo é um dispositivo de usuário pessoal.
[023] Vantagens se acumulam para as modalidades da invenção onde o primeiro dispositivo é um periférico com memória segura limitada e uma chave de pareamento simétrica pode ser implementada para o handshake provisionar uma conexão segura com o segundo dispositivo. Usando uma chave de pareamento simétrica para o handshake de autenticação e encriptação, são necessários poucos bytes de dados armazenados no primeiro dispositivo por meio da omissão dos certificados que seriam necessários para a geração de chaves durante o handshake, como em um esquema de chave pública/privada onde as chaves privadas podem ser maiores que os certificados de autenticação. Ao mesmo tempo, as vantagens se acumulam nas abordagens nas quais uma semente é usada para emparelhar a geração de chaves. Nestas abordagens, a semente nunca é exposta fora do dispositivo seguro. Como tal, sistemas nos quais o elemento seguro no primeiro dispositivo possui recursos de processamento suficientes para executar um processo criptográfico usando uma semente pré-injetada, uma compensação desejável entre as partições de memória segura direcionada ao armazenamento em relação aos cálculos criptográficos é provida reduzindo o armazenamento seguro requerido para geração de chave simétrica. Além disso, o periférico pode ser um dispositivo de baixo custo provido por uma entidade responsável por assegurar a conexão, e o segundo dispositivo pode ser um dispositivo prontamente disponível que é provido por um usuário. Esses casos particulares são particularmente adaptáveis a certas abordagens descritas aqui, pois a abordagem de geração de chave de pareamento é exposta apenas nos periféricos seguros e na arquitetura de nuvem, o que proporciona um alto grau de controle ao provedor do periférico, permitindo que os usuários selecionem uma vasta gama de dispositivos para substituir o segundo dispositivo.
[024] Abordagens que utilizam chaves de pareamento simétricas fornecem vantagens específicas sobre abordagens que exigem o uso de certificados com relação a métodos de autenticação, além da geração de chaves. Assim, a conexão segura entre o primeiro dispositivo e o segundo dispositivo pode ser adicionada por meio de um handshake TLS que utiliza chaves simétricas em vez de certificados. Usar o padrão X.509 de chave pública/privada para instanciar uma conexão TLS segura pode exigir que ambos dispositivos forneçam certificados para autenticação mútua, em que cada certificado pode ter a ordem de oitocentos a mil e seiscentos bytes de tamanho. Na prática, usando métodos de assinatura digital assimétrica como Rivest-Shamir-Adleman (RSA), algoritmo de assinatura digital (DSA) ou encriptação de curva elíptica (ECC), o primeiro dispositivo e o segundo dispositivo teriam que se autenticar cada com uma cadeia de dois a quatro certificados, com a possibilidade de as chaves privadas correspondentes usadas para esses certificados serem ainda maiores que os próprios certificados, sobrecarregando ainda mais a memória segura do elemento seguro do primeiro dispositivo. Chaves simétricas podem aliviar essa carga de memória, compreendendo tamanhos de dados chave na ordem de 8 a 16 bytes através do uso de pacotes de handshake TLS iniciais menores na autenticação mútua e menos cálculos no processo de geração de chaves usando a semente. Tais abordagens evitam tempos de processamento de chave pública/privada, que podem ser da ordem de cem milissegundos. Os benefícios da menor carga de armazenamento seguro e do processamento criptográfico mais rápido podem proporcionar maior benefício sobre às suas vantagens já distintas, em sistemas seguros projetados para pagamentos seguros que também devem processar chaves de pagamento seguras e certificados de autenticação de pagamento com os elementos seguros já limitados.
[025] Em modalidades específicas da invenção, os benefícios se acumulam quando o sistema inclui uma arquitetura de nuvem que armazena a identidade de um conjunto de dispositivos, como um conjunto de dispositivos periféricos. Por exemplo, um fabricante poderia criar uma linha de periféricos que utilizam o sistema para se conectar com segurança a qualquer smartphone. Essas abordagens são benéficas porque a arquitetura de nuvem pode monitorar o conjunto de dispositivos e manter um registro de dispositivos comprometidos. Em um exemplo, um primeiro dispositivo pode ser um dispositivo periférico que se tornou suspeito ou sabidamente comprometido, como no caso em que foi roubado. Para evitar comunicações inseguras com o primeiro dispositivo comprometido, essas descobertas podem ser relatadas na arquitetura de nuvem. Assim, o primeiro dispositivo sob suspeita pode ser registrado como um dispositivo que foi comprometido. A transmissão da chave de pareamento da arquitetura de nuvem para o segundo dispositivo, conforme mencionado acima, pode ser pré-condicionada no primeiro dispositivo que não sendo registrado como comprometido na arquitetura de nuvem. Isso pode impedir o segundo dispositivo de ser ativado para autenticar e gerar uma conexão segura com um dispositivo que está comprometido.
[026] Modalidades específicas da invenção exibem certos benefícios onde o primeiro dispositivo não requer uma interface de usuário com alta funcionalidade ou não precisa de uma interface de usuário de forma alguma. Alguns esquemas de pareamento de dispositivos requerem a entrada do usuário de um segredo compartilhado para o dispositivo de aplicação para ativar o pareamento de dispositivos via uma interface de dispositivo. Por exemplo, um dispositivo poderia exibir um código, e o código seria, então, inserido manualmente em uma interface de usuário em um segundo dispositivo. A autenticação mútua e o fornecimento das conexões seguras, através do armazenamento seguro do segredo compartilhado no primeiro dispositivo, não exigem que um usuário forneça informação ao primeiro dispositivo para que o processo continue. Como tal, o primeiro dispositivo pode ser um dispositivo periférico como descrito acima, com requisitos de tamanho e segurança comparativamente rigorosos em relação a dispositivos de usuário, e pode frequentemente ser construído sem uma interface de usuário.
[027] Fig. 1 ilustra um sistema 100 para adicionar uma conexão segura 111 a uma conexão interdispositivo 110 entre dois dispositivos discretos, por exemplo, um primeiro dispositivo 120 e um segundo dispositivo 130, em conjunto com uma arquitetura de nuvem 140. O primeiro dispositivo 120 pode ser um periférico, um dispositivo de aplicação ou um tipo de dispositivo equivalente, do segundo dispositivo 130. O segundo dispositivo 130 pode ser um dispositivo de usuário pessoal ou um tipo de dispositivo equivalente. A conexão interdispositivo 110 pode ser gerada usando um protocolo Bluetooth e padrão usando um primeiro módulo de Bluetooth 121 no primeiro dispositivo 120 e um segundo módulo de Bluetooth 131 no segundo dispositivo 130. A conexão segura 111 pode ser instanciada como uma conexão TLS. A conexão interdispositivo 110 e a conexão segura 111 conectam de forma comunicativa o primeiro dispositivo 120 e o segundo dispositivo 130 de uma maneira bidirecional. Sementes e, equivalentemente, segredos de dispositivo podem ser usados no sistema 100 em apoio à geração de chaves de pareamento que podem ser subsequentemente usadas pelo primeiro dispositivo 120 e segundo dispositivo 130 durante o handshake para autenticação mútua e fornecimento da conexão segura 111.
[028] Em modalidades específicas da invenção, o sistema 100 pode ter um primeiro dispositivo 120 com um elemento seguro 122 que armazena um segredo de dispositivo, e a arquitetura de nuvem 140 pode armazenar um mapeamento a partir de uma identificação do primeiro dispositivo 120, como um identificador de hardware, para o segredo de dispositivo. O elemento seguro 122 pode ser um processador seguro discreto. O sistema 100 pode também instanciar um primeiro gerador de chave de protocolo de conexão 123 e um segundo gerador de chave de protocolo de conexão 141, no primeiro dispositivo 120 e a arquitetura de nuvem 140, respectivamente. O primeiro gerador de chave de protocolo de conexão 123 e o segundo gerador de chave de protocolo de conexão 141 podem ser configurados para gerar uma chave de pareamento usando a semente. Geradores de chave 123 e 141 podem ser implementados por elementos seguros que podem ser configurados para armazenar com segurança conjuntos de dados secretos e realizar operações criptográficas, incluindo a geração de uma PSK. Em uma configuração, um elemento seguro em conexão comunicativa com uma arquitetura de nuvem pode armazenar um elemento criptográfico, tal como uma chave de encriptação de chave (KEK), usada para encriptar sementes armazenadas na arquitetura de nuvem. Esquemas de encriptação de semente usando uma KEK podem incluir, por exemplo, algoritmos de chave simétrica de padrão de encriptação avançada (AES) ou padrão de encriptação de dados (DES). Por conseguinte, uma semente armazenada pode ser encriptada com uma KEK para gerar uma PSK, em que a PSK pode ser configurada para ser uma chave de pareamento. Além disso, o primeiro gerador de chave de protocolo de conexão 123 e o segundo gerador de chave de protocolo de conexão 141 podem ser ambos geradores de PSK compatíveis com protocolos TLS. Observa-se que a PSK ou chave de pareamento, após geração, pode ser usada subsequentemente em processos adicionais, por exemplo, um handshake TLS em que a PSK pode ser usada como entrada para permitir cálculos que finalmente derivam as chaves usadas diretamente para autenticação e encriptação.
[029] Vantagens se acumulam em modalidades específicas onde a semente é combinada com outra informação específica do dispositivo no processo criptográfico usado para gerar a chave de pareamento. Um desafio ao gerar uma chave de pareamento simétrica segura com recursos de memória e processamento limitados é o processo de criação de um número grande e verdadeiramente aleatório. Algoritmos típicos para esta tarefa podem ter recursos de cálculo significativos se executados internamente ao dispositivo. Alternativamente, uma chave pode ser carregada em uma instalação de injeção de chave certificada, ou um equivalente remoto disso, mas nesses ambientes, a quantidade de material de “chaveamento” disponível pode ser limitada quando o dispositivo é implantado. Combinação de dados específicos do dispositivo com a semente para gerar a chave de pareamento pode aliviar essa preocupação. Por exemplo, a geração da chave de pareamento usando a semente pode ser uma combinação da semente e dados adicionais específicos do dispositivo que estão prontamente disponíveis para o dispositivo, como identificadores de hardware, números de série e dados de dispositivo equivalentes no primeiro dispositivo.
[030] Processamento eficiente de informação segura e secreta no sistema 100 pode ser implementado organizando a informação em conjuntos. Quando um conjunto de sementes é mapeado para um conjunto de identificações de dispositivo, o conjunto de sementes pode ser chamado de um conjunto de segredos de dispositivo. Como tal, o mapeamento pode, portanto, incluir um conjunto de segredos de dispositivo e um conjunto de identificações. Além disso, o conjunto de identificações, pela correlação de cada identificação a um dispositivo único, pode identificar o conjunto de dispositivos 150. Em algumas modalidades, a arquitetura de nuvem 140 pode armazenar o conjunto de segredos de dispositivo e ser configurada para gerar um conjunto de chaves de pareamento usando o referido conjunto de segredos de dispositivo. A geração de chave pode ser realizada com o segundo gerador de chave de protocolo de conexão 141. A arquitetura de nuvem 140 pode ser comunicativamente conectada ao conjunto de dispositivos 150 via uma conexão de Internet comunicativa 113 para rastrear o status das chaves de pareamento geradas e armazenadas em tandem com o conjunto associado de dispositivos 150. Controle dos pares de chaves e do conjunto de dispositivos associados 150 no nível de arquitetura de nuvem 140 proporciona benefícios ao permitir a invalidade de chaves de pareamento e dispositivos quando estes ficam comprometidos.
[031] O processo de facilitar a transferência de informação necessária entre o primeiro dispositivo 120 e a arquitetura de nuvem 140 para gerar a conexão segura 111 entre o primeiro dispositivo 120 e o segundo dispositivo 130 pode ser mediado pelo segundo dispositivo 130 para melhorar segurança. Primeiro, o segundo dispositivo 130 pode ser necessário para autenticar sua identidade no servidor de arquitetura de nuvem 140, por exemplo, usando uma aplicação instalada para a entrega de uma combinação de senha e nome de usuário, um esquema de autenticação PKI ou outros métodos viáveis. Se a segunda autenticação do dispositivo 130 for bem-sucedida, o primeiro dispositivo 120 pode transmitir a identificação do primeiro dispositivo para o segundo dispositivo 130 utilizando a conexão interdispositivo 110, após o que o segundo dispositivo 130 pode trocar a identificação do primeiro dispositivo com a arquitetura de nuvem 140 em troca da chave de pareamento. A transferência da identificação do primeiro dispositivo para a arquitetura de nuvem 140 pelo segundo dispositivo 130 pode ser realizada, por exemplo, usando uma conexão de rede comunicativa 112. A chave de pareamento pode ser gerada pelo segundo gerador de chave de protocolo de conexão 141, em parte usando o segredo de dispositivo mapeado para a identificação do primeiro dispositivo, e transmitido a partir da arquitetura de nuvem 140 para o segundo dispositivo 130 em resposta ao recebimento do identificador de dispositivo a partir do segundo dispositivo 130. Alternativamente, o primeiro dispositivo pode enviar sua própria identidade e uma identidade do segundo dispositivo usando uma conexão direta entre o primeiro dispositivo e a arquitetura de nuvem, ponto no qual a arquitetura de nuvem entregará a chave de pareamento ao segundo dispositivo.
[032] O sistema pode estar em um estado em que o segundo dispositivo 130 pode estar em posse e armazenar com segurança a chave de pareamento, e o primeiro dispositivo pode estar em posse e armazenar com segurança a chave de pareamento gerada pelo primeiro gerador de chave de protocolo de conexão 123. Neste estado, um primeiro módulo de protocolo de conexão 124 instanciado pelo elemento seguro 122 do primeiro dispositivo 120, e um segundo módulo de protocolo de conexão 132 instanciado por um processador 133 no segundo dispositivo 130, podem ambos ser configurados para mutuamente autenticar e adicionar a conexão segura 111 à conexão interdispositivo 110, usando suas respectivas chaves de pareamento. O processador 133 pode instanciar um sistema operacional 134. O primeiro módulo de protocolo de conexão 124 e o segundo módulo de protocolo de conexão 132 podem ser módulos TLS.
[033] Em modalidades específicas da invenção, um leitor de dados 125 pode estar no primeiro dispositivo 120. O leitor de dados 125 pode ser configurado para a leitura segura de dados a partir de fontes de dados seguras. Por exemplo, o leitor de dados 125 pode ler dados seguros a partir de: um dispositivo de armazenamento de dados, tal como uma unidade USB; um dispositivo compreendendo uma tira magnética, tal como um cartão de crédito; um dispositivo que compreende um circuito integrado, tal como um cartão de circuito integrado (ICC); um usuário, como um usuário com um biométrico; comunicações por proximidade de campo (NFC) próximas providas por um dispositivo, tal como um smartphone; um código de barras, tal como identificar o código de barras em um item físico; ou uma imagem, tal como a imagem de um cheque pessoal. Em cada modalidade, o leitor de dados 125 pode tomar a forma de um dispositivo ou sistema para receber dados seguros, por exemplo, com referência às modalidades de exemplo acima, um leitor USB, um leitor de cartões, um leitor ICC, um dispositivo de comunicações NFC, um leitor biométrico, um scanner de código de barras ou um sensor de imagem. Estes exemplos mostram meramente configurações possíveis do leitor de dados 125 e não limitam as modalidades que estão abrangidas pelo âmbito completo da invenção. Um módulo de processamento de dados 126, instanciado no elemento seguro 122, pode subsequentemente receber os dados através de uma conexão comunicativa com o leitor de dados 125. O módulo de processamento de dados 126 pode interpretar sinais analógicos recebidos do leitor de dados 125 e convertê-los em informação digital. O módulo de processamento de dados 126 pode também encriptar a informação recebida e controlar a transferência de informação para fora do elemento seguro 122. O primeiro dispositivo 120 é configurado para transmitir a informação digital para o segundo dispositivo 130 utilizando a conexão segura 111.
[034] Em modalidades específicas da invenção, os métodos para adicionar uma conexão segura podem ser realizados utilizando um método de senha de uso único (OTP) que gera uma chave de encriptação com um período de validade finito. O período de validade de chave pode ser qualquer período de tempo, tal como a duração de uma transação, a duração de uma sessão de login, ou um período de tempo predeterminado e fixo. Benefícios seguem a partir da implementação de um método de geração de chave OTP como o período de validade de chave limitado minimiza a oportunidade de um invasor usar um ataque de reprodução ou repetição MITM, no qual um pacote de dados válido pode ser deliberadamente atrasado ou indevidamente repetido para induzir um defeito de segurança. Métodos OTP aqui descritos podem ser aplicados aos geradores de chave de protocolo de conexão no primeiro dispositivo 120 e na arquitetura de nuvem 140.
[035] Fig. 2 ilustra um sistema 200 para implementar um método de encriptação de chave OTP que pode exigir módulos e elementos específicos, adicionalmente, aos módulos e elementos herdados a partir do sistema 100. O primeiro dispositivo 120 pode ter um primeiro clock de tempo real 227 que pode ser instanciado no elemento seguro 122 e pode gerar uma primeiro marca de tempo. O primeiro dispositivo 120 também pode ter um primeiro gerador de chave de protocolo de conexão 223 que é configurado para gerar uma chave de pareamento a partir de um segredo de dispositivo usando a primeira marca de tempo do primeiro clock de tempo real 227. Em um exemplo, uma chave de pareamento incorporada em primeira marca de tempo pode ser uma chave OTP. A arquitetura de nuvem 140 pode instanciar um segundo clock de tempo real 242 que pode gerar uma segunda marca de tempo. O tempo real pode ser carregado no primeiro dispositivo 120 em um recurso seguro antes que o dispositivo seja implantado. Uma vez que o clock de tempo real 227 é em tempo real, ele pode ser utilizado em abordagens criptográficas sincronizadas com a arquitetura de nuvem 140 pelo resto da sua vida, desde que o clock de tempo real 227 não seja perturbado. A arquitetura de nuvem 140 também pode ter um segundo gerador de chave de protocolo de conexão 241 que é configurado para gerar uma chave de pareamento a partir de um segredo de dispositivo usando a segunda marca de tempo do segundo clock de tempo real 242. Em um exemplo, a chave de pareamento incorporada na segunda marca de tempo pode ser uma chave OTP. Ao usar o primeiro gerador de chave de protocolo de conexão 223 e o segundo gerador de chave de protocolo de conexão 241 usando um segredo de dispositivo e uma marca de tempo para gerar chaves de pareamento, PSKs, TLS PSKs ou chaves encriptadas equivalentes, essas chaves podem adquirir as qualidades de uma chave OTP e uma validade de tempo limitada.
[036] Em modalidades específicas da invenção, métodos de geração de chave OTP podem conter várias etapas que são identicamente seguidas pelo primeiro dispositivo 120 e a arquitetura de nuvem 140 para gerar um conjunto simétrico de chaves de pareamento. As seguintes etapas descritas abaixo são um exemplo do conjunto de múltiplas etapas idênticas descritas acima. Em uma primeira etapa, os conjuntos de dados de chaves a serem usados pelo gerador de chave, como uma semente ou segredo de dispositivo, podem ser provisionados. O provisionamento desta informação para o primeiro dispositivo 120 pode ser conduzido enquanto o dispositivo está em uma instalação de injeção de chave segura ou remotamente usando um protocolo de injeção de chave remota. Em uma segunda etapa, o algoritmo de geração de chave OTP e os parâmetros do algoritmo podem ser escolhidos. Em um exemplo, o algoritmo pode ser um algoritmo de geração de chave de código de autenticação de mensagem baseado em hash (HMAC). Em outro exemplo, os parâmetros do algoritmo podem incluir: um intervalo de geração de chave que define um tempo em que uma chave gerada pode se tornar inválida e uma nova deve ser gerada; um algoritmo hashing seguro, tal como a partir de séries de funções hash criptográficas SHA publicadas pelo Instituto Nacional de Padrões e Tecnologia dos Estados Unidos que operam matematicamente nos conjuntos de dados secretos do dispositivo para criar uma saída hash usada como dados fonte para a geração de chaves; um comprimento de truncamento que determina a quantidade de dados fonte a serem usados, que deve ser menor que o comprimento da saída hash; e outros parâmetros usados para geração de chaves. Em uma terceira etapa, o algoritmo de geração de chave OTP pode identificar os dados que serão usados como uma semente, que pode ser um segredo de dispositivo. Em uma quarta etapa, uma marca de tempo pode ser gerada por um clock de tempo real. Em um exemplo, o tempo real citado na marca de tempo pode ser definido como o tempo atual da época do Unix, que é o tempo decorrido em segundos a partir de o início de 1° de janeiro de 1970, hora universal coordenada. Em uma quinta etapa, a chave de pareamento pode ser calculada usando o algoritmo de geração de chave OTP usando os parâmetros selecionados. Em um exemplo, a chave de pareamento OTP gerada pode estar em formato binário.
[037] Fig. 3 ilustra um exemplo de método de geração de chave OTP 300 de acordo com a geração de uma chave de pareamento por um gerador de chave de protocolo de conexão. O método 300 pode começar com o provisionamento dos conjuntos de dados de chaveamento 301 usados pelo gerador de chave, tal como uma semente ou segredo de dispositivo com informação adicional de identificador de dispositivo. Em seguida, a instanciação do algoritmo de geração de chaves OTP 302 pode prosseguir. O algoritmo pode ser escolhido a partir de um conjunto de algoritmos durante a etapa 302 se múltiplos algoritmos estiverem disponíveis no conjunto. O algoritmo de geração de OTP pode ser qualquer algoritmo viável, como um método padrão de solicitação de comentários (RFC), conforme desenvolvido pela Internet Engineering Task Force. Em algumas modalidades do método 300, o algoritmo HMAC pode ser escolhido como o algoritmo de geração de chave OTP. Em um exemplo de implementação do algoritmo HMAC, os parâmetros incluem a função hash, h, o segredo de dispositivo, S, e a marca de tempo gerada em tempo real, T. O algoritmo pode importar os parâmetros 303 necessários para definir execução da geração de chaves. Finalmente, a chave de pareamento pode ser gerada 304 pelo cálculo do algoritmo OTP, onde a chave de pareamento pode ser configurada para ser utilizável como uma PSK para protocolos TLS. Quando aplicada aos módulos geradores de chaves usados no sistema 200, a implementação específica do método 300 pode variar. No entanto, certos mecanismos precisam ser implantados de forma idêntica para assegurar que o módulo gerador de chave na arquitetura de nuvem 140 e no primeiro dispositivo 120 concordem em relação a qual implementação aplicar a qualquer momento. Em algumas abordagens, a arquitetura de nuvem 140 e o primeiro dispositivo 120 recebem instruções antes da geração de uma chave de pareamento em relação a qual implementação aplicar para a próxima chave gerada.
[038] Em abordagens específicas para a invenção, a arquitetura de nuvem 140 pode incluir elementos e módulos que melhoram a funcionalidade e segurança dos métodos e sistemas aqui descritos. A arquitetura de nuvem 140 pode incluir um módulo de segurança de hardware (HSM). HSMs podem ser semelhantes aos elementos seguros, pois podem prover camadas de segurança indisponíveis para elementos genéricos. No entanto, HSMs são diferenciados dos elementos seguros em si, porque HSMs são projetados para armazenar, gerar, processar, categorizar e transferir chaves de encriptação. Assim, os HSMs podem incluir qualquer tipo de elemento seguro para realizar esses fins, como um processador seguro, armazenamento seguro de dados, módulos de encriptação, módulos de decriptação, geradores de chaves, clocks, elementos de entrada segura para receber comandos de controle remoto e outros elementos seguros. HSMs podem ser instalados localmente em um dispositivo como um elemento seguro. Como alternativa, os HSMs podem ser operados remotamente e transferir informações seguras, como uma chave de encriptação, para o sistema de interesse em uma conexão segura. Os HSMs com funcionalidade avançada podem ser utilizados em uma arquitetura de back-end do sistema, como uma arquitetura de nuvem 140, em que o design de back-end do sistema não é limitado, por exemplo, tamanho de componente de hardware, recursos de processamento ou armazenamento de energia da bateria. Os módulos, elementos e hardware utilizados em uma modalidade para implementar um HSM podem ser considerados equivalentes a outra modalidade de HSM, independentemente do local de instalação do HSM, tal como um dispositivo ou uma arquitetura de nuvem, a menos que definido de outra forma. É também notado que, enquanto um HSM é parte integrante da segurança dos seus elementos e módulos e, portanto, do sistema, o processo não requer absolutamente nenhum HSM para executar as etapas do método descrito. Essas etapas podem ser executadas por um processador genérico suportado pelos elementos e módulos necessários, se os requisitos de segurança do aplicação forem mantidos.
[039] Em abordagens específicas da invenção, a arquitetura de nuvem 140 pode incluir um banco de dados para armazenar com segurança as informações necessárias para registrar a coleta de chaves, dispositivos, identificadores de dispositivos, segredos de dispositivos e informações de rastreamento e provisionamento relacionadas. O banco de dados pode permanecer seguro enquanto residir fora do HSM por meio de uma implementação de encriptação de dados, por exemplo, usando uma técnica de chave de encriptação de chave descrita abaixo. A arquitetura de nuvem 140 pode incluir um servidor web para receber, armazenar, processar e prover informações da arquitetura de nuvem 140 com segurança para outro dispositivo no sistema, tal como o segundo dispositivo 130. O servidor web pode estabelecer uma conexão segura, por exemplo, formando uma conexão TLS segura com um protocolo de transferência de hipertexto seguro (HTTPS), com outro dispositivo após o dispositivo de conexão ter provido as credenciais necessárias, tal como um identificador de usuário. Após a conexão segura ser estabelecida, informações privadas, tais como chaves de pareamento, podem ser transmitidas através da conexão segura.
[040] Fig. 4 ilustra uma arquitetura de nuvem exemplar 140 no sistema 400 que pode incluir um HSM, um banco de dados e um servidor web para geração e transmissão de chave segura envolvendo a arquitetura de nuvem 140, além dos módulos e elementos herdados dos sistemas 100 e 200. Em um exemplo, um módulo de segurança de hardware 443 pode armazenar uma chave de encriptação de chave e instanciar o segundo gerador de chave de protocolo de conexão 241 para permitir a geração de uma chave de pareamento na arquitetura de nuvem 140. KEKs podem prover uma camada de segurança nos conjuntos de dados que são usados para gerar chaves de encriptação em etapas posteriores de encriptação, tal como chave de pareamento ou PSK. Uma KEK usada desta maneira pode complementar as etapas de encriptação implementadas, por exemplo, por um segundo gerador de chave de protocolo de conexão 241 que usa um algoritmo de encriptação OTP com uma segunda marca de tempo de um segundo clock de tempo real 242. A KEK pode ser usada para encriptar um segredo de dispositivo na arquitetura de nuvem 140 para criar um segredo de dispositivo encriptado. Como a chave de pareamento pode ser gerada com um segredo de dispositivo associado a um mapeamento para um identificador de um dispositivo, um banco de dados 444 na arquitetura de nuvem 140 pode conter as informações necessárias para provisionar o gerador de chave 241 no momento apropriado. Como tal, o banco de dados 444 pode conter o mapeamento enquanto armazena o segredo de dispositivo como um segredo de dispositivo encriptado e recupera o segredo de dispositivo encriptado utilizando o identificador de dispositivo. O segredo de dispositivo encriptado deve ser decriptado antes de ser usado para geração de chave e pode ser decriptado pelo módulo de decriptação 445 como instanciado no módulo de segurança de hardware 443. Após a decriptação, o segundo gerador de chave de protocolo de conexão 241 na arquitetura de nuvem 140 pode ser usado, com o segredo de dispositivo, para gerar a chave de pareamento. Em um exemplo, o segundo clock 242 em tempo real pode ser instanciado na arquitetura de nuvem 140 e desligado no módulo de segurança de hardware 443. Em outro exemplo válido, o segundo clock de tempo real 242 pode ser instanciado no módulo de segurança de hardware 443 e reter a mesma funcionalidade com segurança adicional.
[041] Em um exemplo, a arquitetura de nuvem 140 pode conter um servidor web 446 configurado para receber uma identificação de dispositivo de um segundo dispositivo 130 para autenticar o segundo dispositivo 130, pode acessar o mapeamento a partir do banco de dados 444 usando a identificação do dispositivo e pode transmitir a chave de pareamento para o segundo dispositivo 120 depois de acessar o mapeamento para encaminhar o handshake TLS, o processo de autenticação mútua e provisionamento de uma conexão segura 111 à conexão interdispositivo 110 entre o primeiro dispositivo 120 e o segundo dispositivo 130. Em outro exemplo, o segundo dispositivo 130 pode ter dois módulos de protocolos de conexão TLS separados 432 e 435. Módulo de protocolo de conexão TLS 432 pode ser instanciado no processador 133 para provisionar a conexão segura 111 de acordo com os métodos descritos para o segundo módulo de protocolo de conexão 132, onde a conexão segura 111 pode ser uma conexão TLS. O módulo de protocolo de conexão TLS 435, um terceiro módulo de protocolo de sistema 400, também pode ser instanciado no processador 133 enquanto permanece funcionalmente separado do protocolo de conexão TLS 432, ou poderia ser instanciado em outro lugar no segundo dispositivo 130. O módulo de protocolo de conexão TLS 435 pode formar uma conexão 412 com o servidor web 446 a partir do segundo dispositivo 130. A conexão 412 pode ser autenticada e encriptado usando protocolos HTTPS.
[042] Autenticação do segundo dispositivo 130 para o servidor web 446 na arquitetura de nuvem 140 pode permitir mecanismos de segurança exclusivos, tal como prevenir a arquitetura de nuvem de provisionar uma chave de pareamento para uma parte mal-intencionada. Em algumas modalidades da invenção, a autenticação do segundo dispositivo 130 para a arquitetura de nuvem 140 pode ser implementada usando uma aplicação instalada no segundo dispositivo 130. A aplicação pode ser configurada para ser gerenciada pelo sistema operacional 134 e instanciado pelo processador 13 usando o sistema operacional 134. A aplicação pode ser implementada usando um método para verificar a identidade do usuário do segundo dispositivo 130. A aplicação pode usar os elementos e módulos no segundo dispositivo 130 para auxiliar na tarefa de identificação do usuário. A aplicação pode, por exemplo, executar a segunda autenticação do dispositivo 130 solicitando ao usuário para inserir um nome de usuário e senha usando tecnologias de dispositivo de exibição e dispositivo de entrada, tal como um display de tela sensível ao toque, que pode ser retransmitido para o servidor web 446 para autenticação. O processo pelo qual o usuário provê informações privadas de usuário para autenticar é geralmente chamado de autenticação baseada em conhecimento. Métodos relacionados podem incluir questões de segurança diferentes ou adicionais, tais como números de identificação pessoal (PINs), perguntas de usuários pessoais respondidas com antecedência e acessíveis ao servidor web 446, ou até mesmo questões pictográficas. Em outros processos de autenticação, o aplicação pode solicitar uma biometria de usuário, tais como impressão digital, comando de voz, escaneamento de retina, ou imagem de reconhecimento facial, fornecida para o aplicação através dos elementos de sensor no segundo dispositivo 130. Em outro cenário, uma vez que o segundo dispositivo 130 é usualmente não sobrecarregado pelas mesmas restrições de elemento e módulo como o primeiro dispositivo 120, o segundo dispositivo 130 pode implementar protocolos de autenticação e encriptação padrão, tais como usar certificados e encriptação de chave privada/pública. Autenticação pela aplicação pode incorporar o segundo módulo de protocolo de conexão 132, ou equivalentemente módulo de protocolo de conexão TLS 432, para fazer parte da aplicação. Em outro exemplo, a autenticação pela aplicação pode incorporar o módulo de protocolo de conexão TLS 435. Como parte da aplicação, o módulo de protocolo pode ser usado para trocar a identificação do primeiro dispositivo 120 por uma chave de pareamento após a autenticação do segundo dispositivo 130 através do aplicação, por exemplo sobre conexão 412. Em outras palavras, a transmissão da chave de pareamento da arquitetura de nuvem 140 nesta troca pode ser pré- condicionada no processo de autenticação da aplicação do segundo dispositivo 130.
[043] Comunicações entre o segundo dispositivo 130 e a arquitetura de nuvem 140 pode ser conduzida pelo módulo de protocolo de conexão TLS 435 no segundo dispositivo 130 com o servidor web 446 na arquitetura de nuvem 140. Os módulos de protocolo de conexão TLS 435 podem provisionar conexão 412 com protocolos sem fio padrão conforme descrito acima, incluindo protocolos TLS. O protocolo TLS pode usar HTTPS para estabelecer uma conexão segura. Em algumas modalidades, o segundo dispositivo 130 pode ser um smartphone e o módulo de protocolo de conexão TLS 435 pode ser o módulo de protocolo de conexão TLS nativo configurado pelo fabricante do equipamento original (OEM) ou pela instalação do sistema operacional original. Se esses modelos de protocolo de conexão TLS 435 forem usados para comunicação com a arquitetura de nuvem 140, camadas adicionais de segurança criptográfica poderão ser implementadas na conexão TLS provisionada pelo módulo, quando exigido pela natureza sensível dos dados privados que estão sendo transportados pelo dispositivo 130. Em modalidades alternativas, o módulo de protocolo de conexão TLS 432 pode ser utilizado para se comunicar com o servidor web 446. Nestas modalidades, módulo de protocolo de conexão TLS 432 pode ser instanciado pelo aplicação e pode ser ativado para se conectar ao servidor web 446 por uma conexão diferente de um protocolo websocket.
[044] Fig. 5 ilustra o sistema 500 que pode realizar transações de pagamento seguras com módulos de pagamento seguro e armazenamento seguro, além dos módulos e elementos herdados dos sistemas 100, 200 e 400. Esses módulos de pagamento seguro e armazenamento seguro também podem suportar processos criptográficos e de autenticação, tal como o handshake TLS entre o primeiro dispositivo 120 e o segundo dispositivo 130. Para este fim, o primeiro dispositivo 120 pode ter um módulo de lógica de pagamento seguro 526 no elemento seguro 122. O módulo de lógica de pagamento seguro 526 pode incorporar as propriedades do módulo de processamento de dados 126 que permitem receber e processar dados do leitor de dados 125. Como o leitor de dados 125 pode receber informações de pagamento nos dados providos a ele, o módulo de lógica de pagamento seguro 526 pode receber e adicionalmente processar informações seguras de pagamento de acordo com padrões de pagamento seguro, tal como o padrão de segurança de dados do setor de cartões de pagamento. O segundo dispositivo 130 pode processar informação segura utilizando uma aplicação 536, que também pode funcionar como descrito acima em relação aos módulos do protocolo de conexão TLS. A aplicação 536 pode ser instanciado pelo processador 133 e instanciar o módulo de lógica de pagamento 537 que pode funcionar em conjunto com o módulo de lógica de pagamento seguro 526 através da conexão segura 111. Em algumas modalidades da invenção, o primeiro dispositivo 120 pode receber informação de pagamento relacionada com uma transação de pagamento no leitor de dados 125, e processar as informações de pagamento no módulo de lógica de pagamento seguro 526 para estar em condições de enviar ao módulo de lógica de pagamento 537 através da conexão segura 111. As informações de pagamento podem ser processadas pela aplicação 536 com o módulo de lógica de pagamento 537 e partes relevantes da informação de pagamento podem ser enviadas para outro local, por exemplo, através de uma conexão estabelecida por um dos módulos do protocolo de conexão TLS.
[045] Em configurações comerciais onde são utilizados pagamentos seguros e são esperadas interações com o cliente, a usabilidade aprimorada do sistema 500 é desejada. Para melhorar a velocidade de processamento na qual uma conexão segura pode ser provisionada, o primeiro dispositivo 120 pode auxiliar no tempo de processamento necessário para conduzir um handshake fornecendo uma sugestão de identidade de chave sempre que o protocolo seguro permitir. A sugestão pode ser gerada no primeiro dispositivo 120 como um conjunto de dados que inclui dados do primeiro dispositivo 120 juntamente com a identificação do primeiro dispositivo. Por exemplo, a sugestão pode ser uma combinação do identificador de dispositivo junto com um marca de tempo. A marca de tempo pode ser provida por um clock seguro operando no primeiro dispositivo, tal como o clock 227 nos exemplos acima.
[046] Em algumas modalidades da invenção, os módulos de segurança podem ser adicionados para permitir o armazenamento seguro e local de dados críticos e privados usados para o handshake TLS. Na arquitetura de nuvem 140, o módulo de segurança de hardware 443 pode incluir o módulo de armazenamento seguro 547 para armazenar uma KEK utilizada para a geração de uma TLS PSK ou uma chave de pareamento. No primeiro dispositivo 120, o elemento seguro 122 pode incluir o módulo de armazenamento seguro 528 para armazenar um segredo de dispositivo carregado. Em algumas abordagens em que um segredo de dispositivo é usado para gerar uma PSK para um handshake TLS, o armazenamento seguro pode ser menor que vinte kilobytes.
[047] O módulo de segurança de hardware 443 na arquitetura de nuvem 140 é um módulo configurável. Em um exemplo, o módulo de segurança de hardware 443 pode ser configurado para operar sem um módulo de controle, adequado para instâncias em que um pequeno conjunto de comandos criptográficos é necessário. Em um exemplo diferente, o módulo de segurança de hardware 443 pode receber comandos com um módulo de controle, como um computador de controle, para permitir a execução de programas armazenados. Neste exemplo, o computador de controle pode acomodar uma das muitas configurações, como um módulo isolado em conexão comunicativa com o módulo de armazenamento seguro 547 ou, alternativamente, totalmente incorporado ao servidor web 546.
[048] Em algumas modalidades da invenção, podem ser implementados métodos para verificar o estado de segurança no segundo dispositivo 130, a fim de interromper as operações, se ele tiver sido comprometido. A aplicação 536 no segundo dispositivo 130 pode transmitir telemetria de localização, por exemplo, coordenadas GPS, para a arquitetura de nuvem 140 pelo período de tempo da instalação da aplicação 536 para armazenar um conjunto de dados de localizações credíveis para uso do segundo dispositivo 130 com o primeiro dispositivo 120 em que algoritmos de aprendizado de máquina podem aprender. Se for determinado a partir da análise do algoritmo de aprendizagem que um segundo dispositivo 130 foi comprometido, a arquitetura de nuvem 140 pode ser instruída a interromper a transmissão de chave de pareamento para o segundo dispositivo 130.
[049] Embora a especificação tenha sido descrita em detalhe no que se refere a modalidades específicas da invenção, será apreciado que os especialistas na técnica, ao obterem uma compreensão do precedente, possam conceber prontamente alterações, variações e equivalentes a estas modalidades. Qualquer uma das etapas de método discutidas acima pode ser conduzida por um processador que opera com um meio não transitório legível por computador armazenando instruções para estas etapas de método. O meio legível por computador pode ser memória dentro de um dispositivo de usuário pessoal ou uma memória acessível de rede. O terminal pode ser um terminal de computador, um smartphone, um terminal de ponto de venda, um repetidor, um sinalizador, um sensor ou qualquer outro dispositivo que colete e transmita informações seguras. Embora os exemplos na descrição tenham sido geralmente direcionados para TLS, qualquer número de protocolos de comunicação com características semelhantes em termos de prover segurança e autenticação para um fluxo bidirecional de comunicação poderia ser usado em seu lugar. Estas e outras modificações e variações da presente invenção podem ser praticadas pelos especialistas na técnica, sem se afastar do âmbito da presente invenção, o que mais particularmente estabelecido nas reivindicações anexas.

Claims (28)

1.Sistema (100) para provisionar uma conexão segura (111) a uma conexão interdispositivo (110), caracterizado pelo fato de que compreende: um primeiro dispositivo (120) tendo um elemento seguro (122), em que o elemento seguro (122): (i) armazena um segredo de dispositivo; (ii) instancia um primeiro módulo de protocolo de conexão (124); e (iii) instancia um primeiro gerador de chave de protocolo de conexão (123); uma arquitetura em nuvem (140) que: (i) armazena um mapeamento a partir do segredo de dispositivo para uma identificação do primeiro dispositivo (120); e (ii) instancia um segundo gerador de chave de protocolo de conexão (141); em que o primeiro gerador de chave de protocolo de conexão (123) e o segundo gerador de chave de protocolo de conexão (141) são ambos configurados para gerar uma chave de pareamento usando o segredo de dispositivo; em que o primeiro gerador de chave de protocolo de conexão (123) gera a chave de pareamento usando uma primeira marca de tempo gerada no primeiro dispositivo (120); em que o segundo gerador de chave de protocolo de conexão (141) gera a chave de pareamento usando uma segunda marca de tempo gerada na arquitetura em nuvem (140); e um segundo dispositivo (130) que: (i) tem um processador (133) que instancia um segundo módulo de protocolo de conexão (132); (ii) é comunicativamente conectado ao primeiro dispositivo (120) por meio da conexão de interdispositivo (110); (iii) é configurado para receber a identificação do primeiro dispositivo a partir do primeiro dispositivo (120); e (iv) é configurado para trocar a identificação do primeiro dispositivo para a chave de pareamento com a arquitetura em nuvem (140) através de uma conexão de rede (112); em que a chave de pareamento é uma chave pré-compartilhada simétrica gerada usando etapas idênticas no primeiro dispositivo (120) e na arquitetura em nuvem (140); em que o primeiro módulo de protocolo de conexão (124) e o segundo módulo de protocolo de conexão (132) são configurados para: (i) autenticar mutuamente usando a chave de pareamento; e (ii) adicionar a conexão segura (111) para a conexão interdispositivo (110) usando a chave de pareamento.
2.Sistema (100), de acordo com a reivindicação 1, caracterizado pelo fato de que compreende ainda: um leitor de dados (125) no primeiro dispositivo (120); e um módulo de processamento de dados (126) instanciado pelo elemento seguro (122) e comunicativamente conectado ao leitor de dados (125) para receber dados; em que o primeiro dispositivo (120) é configurado para transmitir dados de leitor de dados para o segundo dispositivo (130) usando a conexão segura (111).
3.Sistema (100), de acordo com a reivindicação 2, caracterizado pelo fato de que: o segundo dispositivo (130) é um dispositivo de usuário pessoal; o processador (133) instancia um sistema operacional; o primeiro dispositivo (120) é um periférico do segundo dispositivo (130); o elemento seguro (122) é um processador seguro discreto; os primeiro (124) e segundo (132) módulos de protocolo de conexão são módulos de segurança de camada de transporte (TLS); os primeiro (123) e segundo (141) geradores de chave de protocolo de conexão são geradores de chave pré-compartilhada (PSK) de TLS; a chave de pareamento é uma PSK; e a conexão segura (111) é uma conexão de TLS.
4.Sistema (100), de acordo com a reivindicação 1, caracterizado pelo fato de que compreende ainda: um primeiro clock de tempo real (227) instanciado no elemento seguro (122); em que o primeiro gerador de chave de protocolo de conexão (123) é configurado para usar uma primeira marca de tempo a partir do primeiro clock de tempo real (227) para gerar a chave de pareamento a partir do segredo de dispositivo; um segundo clock de tempo real (242) instanciado na arquitetura em nuvem (140); e em que o segundo gerador de chave de protocolo de conexão (141) é configurado para usar uma segunda marca de tempo a partir do segundo clock de tempo real (242) para gerar a chave de pareamento a partir do segredo de dispositivo.
5.Sistema (100), de acordo com a reivindicação 1, caracterizado pelo fato de que a arquitetura em nuvem (140) compreende ainda: um módulo de segurança de hardware (443) armazenando uma chave de encriptação de chave e instanciando o segundo gerador de chave de protocolo de conexão (141); um banco de dados (444) contendo o mapeamento, em que o banco de dados (444) armazena o segredo de dispositivo como um segredo de dispositivo encriptado; e um módulo de decriptação instanciado no módulo de segurança de hardware (443) e configurado para decriptar o segredo de dispositivo encriptado usando a chave de encriptação de chave.
6.Sistema (100), de acordo com a reivindicação 1, caracterizado pelo fato de que a arquitetura em nuvem (140) compreende ainda: um servidor web (446) configurado para receber a identificação do primeiro dispositivo (120) a partir do segundo dispositivo (130), acessar o mapeamento usando a identificação do primeiro dispositivo (120), e transmitir a chave de pareamento ao segundo dispositivo (130) após acessar o mapeamento.
7.Sistema (100), de acordo com a reivindicação 6, caracterizado pelo fato de que compreende ainda: uma conexão HTTPS entre o servidor web (446) e o segundo dispositivo (130); e um terceiro módulo de protocolo de conexão instanciado no segundo dispositivo (130) e configurado para formar a conexão HTTPS com o servidor web (446); em que os segundo e terceiro módulos de protocolo de conexão são módulos de TLS separados.
8.Sistema (100), de acordo com a reivindicação 1, caracterizado pelo fato de que compreende ainda: um sistema operacional e uma aplicação do sistema operacional que são instanciados pelo processador (133) no segundo dispositivo (130); em que o segundo módulo de protocolo de conexão (132) é parte da aplicação; em que a aplicação é configurada para autenticar o segundo dispositivo (130) para a arquitetura em nuvem (140); e em que a arquitetura em nuvem (140) é configurada para pré-condicionar a troca da identificação do primeiro dispositivo (120) para a chave de pareamento com uma autenticação do segundo dispositivo (130) por meio da aplicação.
9.Sistema (100), de acordo com a reivindicação 1, caracterizado pelo fato de que o elemento seguro (122): é um circuito integrado discreto; e inclui menos do que 20 kilobytes de armazenamento seguro gravável.
10.Sistema (100), de acordo com a reivindicação 1, caracterizado pelo fato de que: o mapeamento inclui um conjunto de segredos de dispositivo e um conjunto de identificações; o conjunto de identificações identifica um conjunto de dispositivos (150); a arquitetura em nuvem (140) é comunicativamente conectada ao conjunto de dispositivos (150) por meio da internet; e o segundo gerador de chave de protocolo de conexão (141) é configurado para gerar um conjunto de chaves de pareamento usando o conjunto de segredos de dispositivo.
11.Método para provisionar uma conexão segura (111) a uma conexão interdispositivo (110) entre um primeiro dispositivo (120) e um segundo dispositivo (130), caracterizado pelo fato de que compreende: armazenar um segredo de dispositivo em um elemento seguro (122) no primeiro dispositivo (120); armazenar um mapeamento a partir do segredo de dispositivo para um identificador de dispositivo do primeiro dispositivo (120) em uma arquitetura em nuvem (140); gerar uma primeira marca de tempo no primeiro dispositivo (120); gerar uma segunda marca de tempo na arquitetura em nuvem (140); gerar uma chave de pareamento usando: (i) um primeiro gerador de chave de protocolo de conexão (123) no elemento seguro (122); (ii) a primeira marca de tempo; e (iii) o segredo de dispositivo; gerar a chave de pareamento usando: (i) um segundo gerador de chave de protocolo de conexão (141) na arquitetura em nuvem (140); (ii) a segunda marca de tempo; e (iii) o segredo de dispositivo; transmitir a chave de pareamento a partir da arquitetura em nuvem (140) para o segundo dispositivo (130) em resposta à recepção do identificador de dispositivo; autenticar mutuamente o primeiro (120) e segundo (130) dispositivos usando a chave de pareamento como armazenada no primeiro dispositivo (120) e como armazenada no segundo dispositivo (130); e adicionar a conexão segura (111) à conexão interdispositivo (110) usando a chave de pareamento como armazenada no primeiro dispositivo (120) e como armazenada no segundo dispositivo (130); em que a chave de pareamento é uma chave pré-compartilhada simétrica gerada usando etapas idênticas no primeiro dispositivo (120) e na arquitetura em nuvem (140).
12.Método, de acordo com a reivindicação 11, caracterizado pelo fato de que compreende ainda: receber dados usando um leitor de dados (125) no primeiro dispositivo (120); e transferir os dados a partir do primeiro dispositivo (120) para o segundo dispositivo (130) usando a conexão segura (111).
13.Método, de acordo com a reivindicação 12, caracterizado pelo fato de que: o segundo dispositivo (130) é um dispositivo de usuário pessoal com um sistema operacional; o primeiro dispositivo (120) é um periférico do segundo dispositivo (130); o elemento seguro (122) é um processador seguro discreto; os primeiro e segundo geradores de chave de protocolo de conexão são geradores de chave pré-compartilhada (PSK) de TLS; a chave de pareamento é uma PSK; e a conexão segura é uma conexão de TLS.
14.Método, de acordo com a reivindicação 11, caracterizado pelo fato de que compreende ainda: gerar uma primeira marca de tempo usando um primeiro clock de tempo real (227) no elemento seguro (122); gerar uma segunda marca de tempo usando um segundo clock de tempo real (242) na arquitetura em nuvem (140); em que a geração da chave de pareamento usando o primeiro gerador de chave de protocolo de conexão (123) usa a primeira marca de tempo; e em que a geração da chave de pareamento usando o segundo gerador de chave de protocolo de conexão (141) usa a segunda marca de tempo.
15.Método, de acordo com a reivindicação 11, caracterizado pelo fato de que compreende ainda: encriptar o segredo de dispositivo na arquitetura em nuvem (140) para criar um segredo de dispositivo encriptado; recuperar o segredo de dispositivo encriptado a partir de um banco de dados (444) da arquitetura em nuvem (140) usando o identificador de dispositivo; decriptar o segredo de dispositivo encriptado usando um módulo de segurança de hardware (443) da arquitetura em nuvem (140) antes de gerar a chave de pareamento usando o segundo gerador de chave do protocolo de conexão (141) na arquitetura em nuvem (140) e o segredo de dispositivo; e em que o segundo gerador de chave de protocolo de conexão (141) é instanciado pelo módulo de segurança de hardware (443).
16.Método, de acordo com a reivindicação 11, caracterizado pelo fato de que compreende ainda: receber o identificador de dispositivo a partir do segundo dispositivo (130) usando um servidor web (446) da arquitetura em nuvem (140); em que a transmissão da chave de pareamento a partir da arquitetura em nuvem (140) para o segundo dispositivo (130) usa o servidor web (446).
17.Método, de acordo com a reivindicação 16, caracterizado pelo fato de que compreende ainda: formar uma conexão HTTPS entre o servidor web (446) e o segundo dispositivo (130) usando um módulo de protocolo de conexão de TLS instanciado no segundo dispositivo (130); em que um módulo de protocolo TLS separado adiciona a conexão segura (111) à conexão interdispositivo (110).
18.Método, de acordo com a reivindicação 11, caracterizado pelo fato de que compreende ainda: instanciar uma aplicação usando um sistema operacional no segundo dispositivo (130); autenticar o segundo dispositivo (130) para a arquitetura em nuvem (140) usando a aplicação; e pré-condicionar uma transmissão da chave de pareamento a partir da arquitetura em nuvem (140) para o segundo dispositivo (130) com uma autenticação do segundo dispositivo (130) por meio da aplicação.
19.Método, de acordo com a reivindicação 11, caracterizado pelo fato de que o elemento seguro (122): é um circuito integrado discreto; e inclui menos de 20 kilobytes de armazenamento seguro gravável.
20.Método, de acordo com a reivindicação 11, caracterizado pelo fato de que compreende ainda: armazenar um conjunto de segredos de dispositivos na arquitetura em nuvem (140); e gerar um conjunto de chaves de pareamento usando o conjunto de segredos do dispositivo na arquitetura em nuvem (140); em que o mapeamento inclui um conjunto de identificações; e em que o conjunto de identificações identifica um conjunto de dispositivos (150).
21.Método, de acordo com a reivindicação 11, caracterizado pelo fato de que compreende ainda: gerar uma marca de tempo usando um clock de tempo real (242) na arquitetura em nuvem (140); gerar uma sugestão de identidade de chave no segundo dispositivo (130) usando a marca de tempo e o identificador de dispositivo; e transmitir a sugestão de identidade de chave a partir do segundo dispositivo (130) para o primeiro dispositivo (120) enquanto adiciona a conexão segura (111) à conexão interdispositivo (110).
22.Método, de acordo com a reivindicação 11, caracterizado pelo fato de que compreende ainda: registrar um terceiro dispositivo como comprometido na arquitetura em nuvem (140); e pré-condicionar uma transmissão da chave de pareamento a partir da arquitetura em nuvem (140) para o segundo dispositivo (130) no primeiro dispositivo (120) não sendo registrado como comprometido na arquitetura em nuvem (140).
23.Método, de acordo com a reivindicação 11, caracterizado pelo fato de que compreende ainda: gerar a conexão interdispositivo (110) usando um primeiro módulo Bluetooth (121) no primeiro dispositivo (120) e um segundo módulo Bluetooth (131) no segundo dispositivo (130); transmitir o identificador de dispositivo a partir do primeiro dispositivo (120) para o segundo dispositivo (130) usando a conexão interdispositivo (110); e transmitir o identificador de dispositivo a partir do segundo dispositivo (130) para a arquitetura em nuvem (140) usando uma conexão de rede (112).
24.Método, de acordo com a reivindicação 11, caracterizado pelo fato de que compreende ainda: gerar uma primeira marca de tempo usando um primeiro clock de tempo real (227) no elemento seguro (122); em que a geração da chave de pareamento usando o primeiro gerador de chave de protocolo de conexão (123) utiliza a primeira marca de tempo; e em que a chave de pareamento é uma chave de pareamento de uso único (OTP).
25.Sistema (100), compreendendo: um primeiro dispositivo (120); um segundo dispositivo (130) com uma conexão interdispositivo (110) para o primeiro dispositivo (120); caracterizado pelo fato de que o sistema (100) compreende ainda: um elemento seguro (122) no primeiro dispositivo (120) armazenando um segredo de dispositivo; uma arquitetura em nuvem (140) armazenando o segredo de dispositivo e um mapeamento a partir do segredo de dispositivo para um identificador de dispositivo do primeiro dispositivo (120); um primeiro gerador de chave de protocolo de conexão (123) no elemento seguro (122) configurado para gerar uma chave de pareamento usando o segredo de dispositivo; em que o primeiro gerador de chave de protocolo de conexão (123) gera a chave de pareamento usando uma primeira marca de tempo gerada no primeiro dispositivo (120); um segundo gerador de chave de protocolo de conexão (141) na arquitetura em nuvem (140) configurado para gerar a chave de pareamento usando o segredo de dispositivo; em que o segundo gerador de chave de protocolo de conexão (141) gera a chave de pareamento usando uma segunda marca de tempo gerada na arquitetura em nuvem (140); um primeiro módulo de protocolo de conexão (124) instanciado pelo elemento seguro (122); um segundo módulo de protocolo de conexão (132) no segundo dispositivo (130); uma aplicação no segundo dispositivo (130) que recebe a chave de pareamento a partir da arquitetura em nuvem (140) e instancia o segundo módulo de protocolo de conexão (132); em que a arquitetura em nuvem (140) é configurada para transmitir a chave de pareamento para o segundo dispositivo (130) em resposta ao recebimento do identificador de dispositivo; em que o primeiro módulo de protocolo de conexão (124) e o segundo módulo de protocolo de conexão (132) são configurados para: (i) autenticar mutualmente usando a chave de pareamento; e (ii) adicionar uma conexão segura (111) para a conexão interdispositivo (110) usando a chave de pareamento; e em que a chave de pareamento é uma chave pré-compartilhada simétrica gerada usando etapas idênticas no primeiro dispositivo (120) e na arquitetura em nuvem (140).
26.Sistema (100), de acordo com a reivindicação 25, caracterizado pelo fato de que compreende ainda: um leitor de dados (125) no primeiro dispositivo (120); e um módulo de processamento de dados (126) instanciado pelo elemento seguro (122) e comunicativamente conectado ao leitor de dados (125) para recepção de dados; em que o primeiro dispositivo (120) é configurado para transmitir dados de leitor de dados para o segundo dispositivo (130) usando a conexão segura (111).
27.Sistema (100), de acordo com a reivindicação 26, caracterizado pelo fato de que: o segundo dispositivo (130): (i) é um dispositivo de usuário pessoal; e (ii) tem um processador; o processador (133) instancia um sistema operacional; o primeiro dispositivo (120) é um periférico do segundo dispositivo (130); o elemento seguro (122) é um processador seguro discreto; os primeiro (124) e segundo (132) módulos de protocolo de conexão são módulos de segurança de camada de transporte (TLS); os primeiro (123) e segundo (141) geradores de chave de protocolo de conexão são geradores de chave pré-compartilhada (PSK) de TLS; a chave de pareamento é uma chave PSK; e a conexão segura (111) é uma conexão de TLS.
28.Sistema (100), de acordo com a reivindicação 26, caracterizado pelo fato de que compreende ainda: um primeiro clock de tempo real (227) instanciado no elemento seguro (122); em que o primeiro gerador de chave de protocolo de conexão (123) é configurado para usar uma primeira marca de tempo a partir do primeiro clock de tempo real (227) para gerar a chave de pareamento a partir do segredo de dispositivo; um segundo clock de tempo real (242) instanciado na arquitetura em nuvem (140); e em que o segundo gerador de chave de protocolo de conexão (141) é configurado para usar uma segunda marca de tempo a partir do segundo clock de tempo real (242) para gerar a chave de pareamento a partir do segredo de dispositivo; e em que a chave de pareamento é uma chave de pareamento de uso único.
BR102019015369A 2018-10-03 2019-07-25 Sistemas e método para provisionar uma conexão segura a uma conexão interdispositivo BR102019015369B8 (pt)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16/150,625 2018-10-03
US16/150,625 US10326797B1 (en) 2018-10-03 2018-10-03 Provisioning a secure connection using a pre-shared key

Publications (3)

Publication Number Publication Date
BR102019015369A2 BR102019015369A2 (pt) 2020-02-18
BR102019015369B1 true BR102019015369B1 (pt) 2021-03-16
BR102019015369B8 BR102019015369B8 (pt) 2022-06-28

Family

ID=66826035

Family Applications (1)

Application Number Title Priority Date Filing Date
BR102019015369A BR102019015369B8 (pt) 2018-10-03 2019-07-25 Sistemas e método para provisionar uma conexão segura a uma conexão interdispositivo

Country Status (6)

Country Link
US (1) US10326797B1 (pt)
EP (1) EP3633913B1 (pt)
CN (1) CN110995642B (pt)
AU (1) AU2019202163B1 (pt)
BR (1) BR102019015369B8 (pt)
CA (1) CA3061233C (pt)

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104765999B (zh) * 2014-01-07 2020-06-30 腾讯科技（深圳）有限公司 一种对用户资源信息进行处理的方法、终端及服务器
CN107210918B (zh) * 2015-02-17 2021-07-27 维萨国际服务协会 用于使用基于交易特定信息的令牌和密码的交易处理的装置和方法
US10833849B2 (en) * 2018-03-21 2020-11-10 Clover Network, Inc. Unified secure device provisioning
US10693633B2 (en) 2018-11-19 2020-06-23 Cypress Semiconductor Corporation Timestamp based onboarding process for wireless devices
US11310271B2 (en) * 2019-02-20 2022-04-19 Arris Enterprises Llc Using secure web sockets to extend reach of conditional access systems
US11218330B2 (en) * 2019-03-25 2022-01-04 Micron Technology, Inc. Generating an identity for a computing device using a physical unclonable function
US10726681B1 (en) * 2019-07-26 2020-07-28 Clover Network, Inc. Advanced hardware system for self service checkout kiosk
TWI758636B (zh) * 2019-09-09 2022-03-21 阿證科技股份有限公司 具有高安全性的資料傳輸系統及方法
EP4102770A4 (en) * 2020-02-10 2023-11-01 Samsung Electronics Co., Ltd. ELECTRONIC DEVICE AND METHOD FOR PEER-TO-PEER SERVICE IN AN ELECTRONIC DEVICE
US20210279703A1 (en) * 2020-03-06 2021-09-09 Fiserv, Inc. Point of sale device with secure connection between security meshes
CN113891311A (zh) * 2020-06-17 2022-01-04 深圳市利维坦技术有限公司 用于加密IOT的Wi-Fi广播的系统和方法
WO2022006493A1 (en) 2020-07-02 2022-01-06 Cal-Chip Electronics Specialty Products, Inc. Connected secure key redistribution system and method
WO2022012960A1 (en) * 2020-07-16 2022-01-20 Signify Holding B.V. Location-based encryption and decryption
JP2023535613A (ja) * 2020-07-28 2023-08-18 華為技術有限公司 Ｂｌｕｅｔｏｏｔｈノードペアリング方法及び関連する装置
CN112751668B (zh) * 2020-12-29 2022-10-21 杭州永谐科技有限公司 一种低成本物联网数据加密通信系统
CN114697945B (zh) * 2022-04-02 2023-10-24 中国电信股份有限公司 发现响应消息的生成方法及装置、发现消息的处理方法
US11758598B1 (en) * 2022-04-15 2023-09-12 Dell Products, L.P. Automated multi-client and multi-mode wireless device pairing and connection methods and systems
US11968302B1 (en) 2023-03-24 2024-04-23 Srinivas Kumar Method and system for pre-shared key (PSK) based secure communications with domain name system (DNS) authenticator
US12015721B1 (en) 2023-03-24 2024-06-18 Srinivas Kumar System and method for dynamic retrieval of certificates with remote lifecycle management

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101166259B (zh) * 2006-10-16 2010-11-10 华为技术有限公司 手机电视业务保护方法、系统、手机电视服务器及终端
CN101393628B (zh) * 2008-11-12 2012-08-08 飞天诚信科技股份有限公司 一种新型的网上安全交易系统和方法
CN101583124B (zh) * 2009-06-10 2011-06-15 大唐微电子技术有限公司 一种用户识别模块与终端进行认证的方法和系统
CN102111759A (zh) * 2009-12-28 2011-06-29 中国移动通信集团公司 一种认证方法、系统和装置
JP5861081B2 (ja) * 2010-06-03 2016-02-16 パナソニックＩｐマネジメント株式会社 半導体装置およびこれを用いた半導体リレー
MX2013000279A (es) 2010-07-09 2013-08-21 Izettle Merchant Services Ab Sistema para pago seguro sobre una red de comunicacion inalambrica.
WO2013177325A2 (en) * 2012-05-22 2013-11-28 Level 3 Communications, Llc Methods and systems for allocating and provisioning computing resources
US10025920B2 (en) * 2012-06-07 2018-07-17 Early Warning Services, Llc Enterprise triggered 2CHK association
EP2725758A1 (fr) * 2012-10-29 2014-04-30 Gemalto SA Procédé d'authentification mutuelle entre un terminal et un serveur distant par l'intermédiaire d'un portail d'un tiers
DE102013203257A1 (de) * 2013-02-27 2014-08-28 Bundesdruckerei Gmbh Lesen eines Attributs aus einem ID-Token
US10880741B2 (en) * 2013-07-23 2020-12-29 Capital One Services, Llc Automated bluetooth pairing
US9704160B2 (en) 2014-09-22 2017-07-11 Mastercard International Incorporated Trusted execution environment for transport layer security key pair associated with electronic commerce and card not present transactions
US9436819B2 (en) * 2014-09-23 2016-09-06 Intel Corporation Securely pairing computing devices
KR102294118B1 (ko) * 2014-10-21 2021-08-26 삼성전자주식회사 보안 연결 장치 및 방법
JP6508688B2 (ja) * 2014-10-31 2019-05-08 コンヴィーダ ワイヤレス， エルエルシー エンドツーエンドサービス層認証
US20160179855A1 (en) * 2014-12-23 2016-06-23 Yahoo! Inc. Ubiquitous content access and management
TW201700213A (zh) * 2015-06-30 2017-01-01 國立中興大學 可改善熱誤差之工具機
US10229448B2 (en) * 2015-12-16 2019-03-12 Paypal, Inc. Network of personalized devices determining data for shopping predictions
US10172000B2 (en) * 2016-03-17 2019-01-01 M2MD Technologies, Inc. Method and system for managing security keys for user and M2M devices in a wireless communication network environment
US10334437B2 (en) * 2016-06-09 2019-06-25 Canary Connect, Inc. Secure pairing of devices and secure keep-alive

Also Published As

Publication number Publication date
US10326797B1 (en) 2019-06-18
BR102019015369B8 (pt) 2022-06-28
EP3633913B1 (en) 2021-03-03
EP3633913A1 (en) 2020-04-08
CA3061233C (en) 2021-09-21
CN110995642B (zh) 2022-04-12
CA3061233A1 (en) 2020-04-03
AU2019202163B1 (en) 2019-10-31
CN110995642A (zh) 2020-04-10
BR102019015369A2 (pt) 2020-02-18

Similar Documents

Publication Publication Date Title
BR102019015369B1 (pt) sistemas e método para provisionar uma conexão segura a uma conexão interdispositivo
US11722296B2 (en) Device securing communications using two post-quantum cryptography key encapsulation mechanisms
KR102138283B1 (ko) 하나의 장치를 이용하여 다른 장치를 언로크하는 방법
US10554636B2 (en) Lightweight encrypted communication protocol
US10979412B2 (en) Methods and apparatus for secure device authentication
US9467430B2 (en) Device, method, and system for secure trust anchor provisioning and protection using tamper-resistant hardware
EP3518458B1 (en) Method and device for secure communications over a network using a hardware security engine
US10958664B2 (en) Method of performing integrity verification between client and server and encryption security protocol-based communication method of supporting integrity verification between client and server
US20170214664A1 (en) Secure connections for low power devices
US11050570B1 (en) Interface authenticator
EP3175380A1 (en) System and method for implementing a one-time-password using asymmetric cryptography
US12003629B2 (en) Secure server digital signature generation for post-quantum cryptography key encapsulations
CN104160656A (zh) 用于将客户端设备与网络相连的系统和方法
EP3047601A1 (en) Technologies for synchronizing and restoring reference templates
US20230361994A1 (en) System and Methods for Secure Communication Using Post-Quantum Cryptography
CN110912685A (zh) 建立受保护通信信道
KR20170012161A (ko) IoT 디바이스의 통신 클라이언트의 동작 방법 및 상기 통신 클라이언트를 포함하는 IoT 디바이스
WO2014177055A1 (zh) 移动设备与安全载体之间通信连接的建立
CN112425116A (zh) 一种智能门锁无线通信方法、智能门锁、网关及通信设备
US20230308424A1 (en) Secure Session Resumption using Post-Quantum Cryptography
US11520937B2 (en) NVMe over fabrics authentication system
TW201929476A (zh) 加密驗證方法

Legal Events

Date Code Title Description
B03B Publication of an application: publication anticipated [chapter 3.2 patent gazette]
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: 20 (VINTE) ANOS CONTADOS A PARTIR DE 25/07/2019, OBSERVADAS AS CONDICOES LEGAIS.

B25D Requested change of name of applicant approved

Owner name: CLOVER NETWORK, LLC (US)