BR112015028071B1 - Sistemas e métodos para comunicação segura - Google Patents

Sistemas e métodos para comunicação segura Download PDF

Info

Publication number
BR112015028071B1
BR112015028071B1 BR112015028071-4A BR112015028071A BR112015028071B1 BR 112015028071 B1 BR112015028071 B1 BR 112015028071B1 BR 112015028071 A BR112015028071 A BR 112015028071A BR 112015028071 B1 BR112015028071 B1 BR 112015028071B1
Authority
BR
Brazil
Prior art keywords
public key
terminal
mobile device
key
certificate
Prior art date
Application number
BR112015028071-4A
Other languages
English (en)
Other versions
BR112015028071A2 (pt
Inventor
Weiming Tang
James Matthew Brewer
Original Assignee
Wayne Fueling Systems Llc
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 Wayne Fueling Systems Llc filed Critical Wayne Fueling Systems Llc
Publication of BR112015028071A2 publication Critical patent/BR112015028071A2/pt
Publication of BR112015028071B1 publication Critical patent/BR112015028071B1/pt

Links

Images

Classifications

    • 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
    • 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/3263—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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3265—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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate chains, trees or paths; Hierarchical trust model
    • 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/327—Short range or proximity payments by means of M-devices
    • G06Q20/3278—RFID or NFC payments by means of M-devices
    • 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/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • 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
    • 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
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/102—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying security measure for e-commerce
    • 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/045—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 hybrid encryption, i.e. combination of symmetric and asymmetric encryption
    • 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/0869—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving random numbers or seeds

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • Finance (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

SISTEMAS E MÉTODOS PARA COMUNICAÇÃO SEGURA. Em algumas modalidades, uma comunicação rápida e segura pode ser alcançada (por exemplo, em um sistema de pagamento de ambiente de abastecimento) com sistemas e métodos que validam uma solicitação de autenticação com base em uma ou mais chaves criptográficas pré-validadas.

Description

CAMPO
[001] A matéria revelada no presente documento geralmente refere-se a sistemas e métodos para comunicação sem fio segura e, mais particularmente, a pagamento sem fio seguro em um ambiente de dispensação de combustível.
ANTECEDENTES
[002] Diversos sistemas de pagamento móveis foram desenvolvidos nos quais um dispositivo móvel pode ser usado para pagar por bens ou serviços em um terminal de pagamento. Em alguns sistemas, o dispositivo móvel não se comunica diretamente com o terminal de pagamento. Em vez disso, a transação é conduzida entre uma infraestrutura de pagamento de dispositivo móvel e uma infraestrutura de pagamento de comerciante. Integrar essas infraestruturas amplamente divergentes e complexas, no entanto, pode, em geral, ter custo elevado.
[003] Outros sistemas envolvem comunicação direta entre o dispositivo móvel e o terminal de pagamento. Em tais sistemas, dados de usuário confiáveis como pagamento e informações de fidelidade são transmitidos como texto não criptografado, levantando diversas questões de segurança. Por exemplo, os dados de usuário confiáveis podem ser interceptados por terceiros inescrupulosos. Isso pode ser de interesse particular em ambientes de abastecimento, em que o terminal de pagamento é, em geral, disposto em uma configuração ao aR1ivre automatizada em que há um risco elevado de espionagem ou adulteração. Os usuários podem ser desencorajados a usar tais sistemas por medo de que o terminal de pagamento possa estar comprometido.
[004] Embora alguns esquemas de comunicação segura tenham sido desenvolvidos, os mesmos não foram aplicados em sistemas de pagamento móveis. Além disso, os mesmos tipicamente envolvem va- lidação de tempo de execução de certificados digitais e um procedimento de controle de fluxo complexo no qual diversas ocorrências de troca de dados de carga útil grande ocorrem. Tais esquemas, desse modo, introduzem atrasos significativos e são complicados e desgastantes para o usuário.
[005] Em conformidade, existe uma necessidade por sistemas de pagamento móveis aprimorados.
BREVE DESCRIÇÃO
[006] A comunicação móvel rápida e segura pode ser alcançada em algumas modalidades com sistemas e métodos que validam um pedido de autenticação com base em uma ou mais chaves criptografadas pré-validadas.
[007] Os sistemas e métodos para fornecer comunicação segura entre um terminal de pagamento e um dispositivo móvel, por exemplo, em um ambiente de abastecimento, são revelados no presente documento. Em algumas modalidades, o terminal de pagamento e o dispositivo móvel conduzem um processo de autenticação mútuo que, se bem-sucedido, produz uma chave de sessão que pode ser usada para criptografar dados sensíveis a serem trocados entre o terminal de pagamento e o dispositivo móvel. O processo de autenticação mútuo pode ser expedido, por exemplo, transferindo-se uma chave pública no lugar de um certificado completo e/ou mantendo-se em cada dispositivo um banco de dados de certificados pré-autenticados indexados por uma tabela de consulta. Os certificados pré-autenticados podem ser superiores em uma hierarquia de confiança para certificados de nível de unidade associados a um dispositivo móvel ou terminal de pagamento particular, de modo que a quantidade de validação que deve ser realizada no tempo de execução seja reduzida.
BREVE DESCRIÇÃO DOS DESENHOS
[008] Esses e outros recursos serão mais prontamente compre- endidos a partir da descrição detalhada a seguir tomada em conjunto com os desenhos anexos, nos quais:
[009] A Figura 1 é um diagrama esquemático de uma modalidade exemplificativa de um ambiente de abastecimento;
[0010] A Figura 2 é um diagrama esquemático de uma modalidade exemplificativa de um sistema de computador;
[0011] A Figura 3 é um diagrama esquemático de uma modalidade exemplificativa de um terminal de pagamento;
[0012] A Figura 4 é um diagrama esquemático de uma modalidade exemplificativa de uma hierarquia de certificados;
[0013] A Figura 5 é um diagrama de sequência de um método exemplificativo de gerenciamento de digitais de certificado durante a produção de um terminal de pagamento;
[0014] A Figura 6 é um diagrama esquemático de uma modalidade exemplificativa de um dispositivo móvel;
[0015] A Figura 7 é um diagrama de sequência de uma modalidade exemplificativa de um método de autenticação mútua conduzido por um terminal de pagamento e um dispositivo móvel;
[0016] A Figura 8 é um fluxograma que retrata o método da Figura 7 a partir da perspectiva do terminal de pagamento; e
[0017] A Figura 9 é um fluxograma que retrata o método da Figura 7 a partir da perspectiva do dispositivo móvel.
[0018] É verificado que os desenhos não estão necessariamente em escala. Os desenhos se destinam a retratar apenas aspectos típicos da matéria revelada no presente documento e, portanto, não devem ser considerados limitantes ao escopo da revelação, nos desenhos, numeração similar representa elementos similares entre os desenhos.
DESCRIÇÃO DETALHADA
[0019] Certas modalidades exemplificativas serão descritas agora para fornecer um entendimento geral dos princípios da estrutura, fun-ção, fabricação e uso dos dispositivos, sistemas e métodos revelados no presente documento.
[0020] Os sistemas e métodos para fornecer comunicação segura entre um terminal de pagamento e um dispositivo móvel, por exemplo, em um ambiente de abastecimento, são revelados no presente documento. Em algumas modalidades, o terminal de pagamento e o dispositivo móvel conduzem um processo de autenticação mútuo que, se bem-sucedido, produz uma chave de sessão que pode ser usada para criptografar dados sensíveis a serem trocados entre o terminal de pagamento e o dispositivo móvel. O processo de autenticação mútuo pode ser expedido, por exemplo, transferindo-se uma chave pública no lugar de um certificado completo e/ou mantendo-se em cada dispositivo um banco de dados de certificados pré-autenticados indexados por uma tabela de consulta. Os certificados pré-autenticados podem ser superiores em uma hierarquia de confiança para certificados de nível de unidade associados a um dispositivo móvel ou terminal de pagamento particular, de modo que a quantidade de validação que deve ser realizada no tempo de execução seja reduzida.
AMBIENTE DE ABASTECIMENTO
[0021] A Figura 1 ilustra uma modalidade exemplificativa de um ambiente de abastecimento 100 no qual um ou mais dos sistemas e métodos revelados no presente documento podem ser implantados. O ambiente de abastecimento 100 geralmente inclui um terminal de pagamento 102 e um dispositivo móvel 04 associados a um usuário (por exemplo, um consumidor que procura comprar combustível ou pessoal de serviço que procura acesso de serviço para o terminal de pagamento).
[0022] O terminal de pagamento 102 pode ser integrado com um dispensador de combustível 106, que pode incluir diversos recursos bem entendidos por aqueles versados na técnica como um bocal, uma bomba, botões para selecionar grau de combustível, uma tela de exi- bição e assim por diante. O terminal de pagamento 102 pode incluir um sistema de computador, conforme descrito abaixo. O terminal de pagamento 102 pode ser acoplado a um servidor back-end 108, que pode ser configurado para se comunicar com diversas redes, como uma rede de fidelidade de abastecimento 110 para manter, verificar e atualizar informações de fidelidade de consumidor e uma rede de pagamento de abastecimento 112 para processar compra de combustível e outras transações. Juntos, o servidor back-end 108, a rede de fidelidade de abastecimento 110 e a rede de pagamento de abastecimento 112 forma uma infraestrutura de pagamento de abastecimento.
[0023] O dispositivo móvel 104 também pode incluir um sistema de computador, conforme descrito abaixo. O dispositivo móvel 104 pode ser configurado para se comunicar com diversas redes, como uma nuvem de fidelidade móvel 114 para manter, verificar e atualizar informações de fidelidade de consumidor e uma nuvem de pagamento móvel 116 para processar compras e outras transações executadas usando o dispositivo móvel 104. A nuvem de fidelidade móvel 114 e a nuvem de pagamento móvel 116, juntas, formam uma infraestrutura de pagamento móvel. O dispositivo móvel 104 pode ser ou pode incluir qualquer dispositivo que é configurado para trocar dados através de uma rede de comunicação, como um telefone móvel, computador do tipo tablet, computador do tipo laptop, carteira digital e assim por diante. O dispositivo móvel pode ser transportado por um usuário ou integrado a um objeto móvel.
[0024] O terminal de pagamento 102 e o dispositivo móvel 104 podem autenticar mutuamente um ao outro para facilitar comunicação segura de pagamento ou outras informações diretamente entre o terminal de pagamento 102 e o dispositivo móvel 104. Um canal de comunicação segura entre o terminal de pagamento 102 e o dispositivo móvel 104 pode permitir pagamento móvel seguro sem exigir a infraes-trutura de pagamento de abastecimento e a infraestrutura de pagamento móvel seja alterada ou integrada.
[0025] Embora um ambiente de abastecimento seja mostrado na Figura 1, será verificado que os sistemas e métodos revelados no presente documento podem estar prontamente aplicados em outras configurações, por exemplo, qualquer configuração na qual um dispositivo móvel é usado para conduzir uma transação com um terminal. As transações podem incluir transação de pagamentos, transações de reembolso, transações de serviço, transações de controle ou qualquer outra transação que exija terminais de comunicação podem incluir terminais de pagamento, quiosques e assim por diante e/ou podem ser parte de um dispensador (por exemplo, um dispensador de combustível, um dispensador de lanche e bebida, um dispensador de dinheiro, etc.).
SISTEMA DE COMPUTADOR
[0026] A Figura 2 ilustra uma arquitetura exemplificativa de um sistema de computador 200 que pode ser usado para implantar o terminal de pagamento 102 ou dispositivo móvel 304 da Figura 1. Embora um sistema de computador exemplificativo 200 seja retratado e descrito no presente documento, será verificado que isso é por uma questão de generalidade e conveniência, em outras modalidades, o sistema de computador pode diferir em arquitetura e operação daquelas mostradas e descritas no presente documento.
[0027] O sistema de computador 200 pode incluir um processador 202 que controla a operação do sistema de computador 200, por exemplo, executando-se um sistema operacional (OS), controladores de dispositivo, programas de aplicativo e assim por diante. O processador 202 pode incluir qualquer tipo de microprocessador ou unidade de processamento central (CPU), que inclui microprocessadores de propósito geral ou propósito especial programáveis e/ou qualquer um dentre uma variedade de sistemas de múltiplos processadores ou de processador único comercialmente disponíveis ou registrados.
[0028] O sistema de computador 200 também pode incluir uma memória 204, que fornece armazenamento temporário ou permanente para que o código seja executado pelo processador 202 ou para que os dados sejam processados pelo processador 202. A memória 204 pode incluir memória somente de leitura (ROM), memória flash, uma ou mais variedades de memória de acesso aleatório (RAM) e/ou uma combinação de tecnologias de memória.
[0029] Os diversos elementos do sistema de computador 200 podem ser acoplados entre si. Por exemplo, o processador 202 pode ser acoplado à memória 204. Os diversos elementos do sistema de computador 200 podem ser diretamente acoplados entre si ou podem ser acoplados entre si por meio de um ou mais componentes intermediários. Na modalidade ilustrada, os diversos elementos do sistema de computador 200 são acoplados a um sistema de barramento 206. O sistema de barramento ilustrado 206 é uma abstração que representa qualquer um ou mais barramentos físicos separados, linhas/interfaces de comunicação e/ou conexões ponto a ponto ou de múltiplos depósitos, conectados por pontes apropriadas, adaptadores e/ou controladores.
[0030] O sistema de computador 200 também pode incluir uma interface de rede 208 que habilita o sistema de computador 200 a se comunicar com dispositivos remotos (por exemplo, outros sistemas de computador) através de uma rede, no caso do terminal de pagamento 102, a interface de rede pode facilitar comunicação com o servidor back-end 108, a rede de fidelidade de abastecimento 110 e a rede de pagamento de abastecimento 132 no caso do dispositivo móvel 104, a interface de rede pode facilitar comunicação com a nuvem de fidelidade móvel 114 e a nuvem de pagamento móvel 116, por exemplo, por meio de Wi-Fi ou uma rede de dados de celular.
[0031] O sistema de computador 200 também pode incluir uma interface de entrada/saída (I/O) 210 que facilita comunicação entre um ou mais dispositivos de entrada, um ou mais dispositivos de saída e os diversos outros componentes do sistema de computador 200. Os dispositivos de entrada e saída exemplificativos incluem teclados, telas sensíveis ao toque, botões, leitores de cartão de tira magnética, vistas, alto-falantes e assim por diante.
[0032] O sistema de computador 200 também pode incluir um dispositivo de armazenamento 212, que pode incluir qualquer meio convencional para armazenar dados de uma maneira não volátil e/ou não transitória. O dispositivo de armazenamento 212 pode, desse modo, manter dados e/ou instruções em um estado persistente (isto é, o valor é retido independentemente da interrupção de potência ao sistema de computador 200). O dispositivo de armazenamento 212 pode incluir uma ou mais unidades de disco rígido, unidades flash, unidades de USB, unidades ópticas, diversos discos ou cartões de mídia e/ou qualquer combinação dos mesmos e pode ser diretamente conectado aos outros componentes do sistema de computador 200 ou remotamente conectado ao mesmo, como através de uma rede.
[0033] O sistema de computador 200 também pode incluir um controlador de visor 214 que pode incluir um processador de vídeo e uma memória de vídeo e pode gerar imagens a serem exibidas em um ou mais visores de acordo com instruções recebidas do processador 202.
[0034] O sistema de computador 200 também pode incluir um elemento seguro 216. O elemento seguro 216 pode ser uma plataforma resistente à adulteração (por exemplo, um microcontrolador seguro de um chip) com capacidade de hospedar de modo seguro aplicativos e seus dados confidenciais e criptográficos (por exemplo, gerenciamento de chave) de acordo com as regras e exigências de segurança apresentadas por um conjunto de autoridades confiáveis bem identificadas. O elemento seguro 216 pode ter capacidade para fornecer geração de número aleatório, gerar pares de chave pública/privada específicas de dispositivo e executar um algoritmo de segurança. Exemplos conhecidos de algoritmos de segurança incluem, porém sem limitação: Hash, TDES, AES, RSA, etc. Os elementos seguros exemplifi- cativos 26 incluem Cartões de Circuito Integrado Universal fUICC), elementos seguros inseridos e cartões digitais de micro segurança (micro SD).
[0035] O sistema de computador 200 também pode incluir uma interface de comunicação segura 218 através da qual o sistema de computador 200 pode conduzir procedimentos de autenticação mútuos e se comunicar com outros sistemas de computador. A interface de comunicação segura 21 8 pode ser sem fio (por exemplo, comunicação de campo próximo (NFC), Wi-Fi, Bluetooth e similares) ou com fio (por exemplo, USB ou Etheraet). No caso de NFC, por exemplo, o sistema de computador 200 pode incluir um transceptor de rádio configurado para se comunicar com um transceptor de rádio de outro disposi-tivo com o uso de um ou mais padrões como ISO/IEC 14443, FeliCa, ISO/TEC 18092 e aqueles definidos pelo Fórum NFC.
MÓDULOS ABRANGENTES
[0036] As diversas funções realizadas pelo terminal de pagamento 102 e pelo dispositivo móvel 104 podem seR1ogicamente descritas como sendo realizadas por um ou mais módulos, será verificado que tais módulos podem ser implantados em hardware, software ou uma combinação dos mesmos. Será adicionalmente verificado que, quando implantados em software, os módulos podem ser parte de um único programa ou um ou mais programas separados e podem ser implantados em uma variedade de contextos (por exemplo, como parte de um sistema operacional, uma unidade de dispositivo, um aplicativo autô- nomo e/ou combinações dos mesmos). Além disso, software que incorpora um ou mais módulos pode ser armazenado como um programa executável em um ou mais meios de armazenamento legíveis por computador não transitórios. As funções reveladas no presente documento como sendo realizadas por um módulo particular também podem ser realizadas por qualquer outro módulo ou combinação de módulos e o terminal de pagamento 102 e o dispositivo móvel 104 podem incluir poucos ou mais módulos além dos que são mostrados e descritos no presente documento.
MÓDULOS DE TERMINAL DE PAGAMENTO
[0037] A Figura 3 é um diagrama esquemático dos módulos de uma modalidade exemplificativa do terminal de pagamento 102, conforme mostrado, o terminal de pagamento 102 pode incluir um módulo de certificado 302, um módulo de recebimento de pedido de autenticação 304, um módulo de autenticação 306, um módulo de geração de chave de sessão 308, um módulo de transmissão de resposta de autenticação 310 e um módulo de recebimento de informações seguras 312.
[0038] O módulo de certificado 302 pode manter um repositório 316 de uma ou mais digitais de certificado e uma tabela de consulta associada 314. A Figura 4 ilustra uma hierarquia de certificados exem- plificativa 400 que pode ser mantida pelo módulo de certificado 302.
[0039] Conforme mostrado, a hierarquia pode incluir um certificado de raiz 402 que identifica uma Autoridade de Certificado de Raiz de padrão industrial (CA de Raiz). CAs de Raiz exemplificativas incluem VeriSign, GlobalSign, DigiCert e similares. O certificado de raiz 402 forma a raiz de segurança para a hierarquia de certificados 400 e pode ser um certificado de chave pública não assinado ou um certificado auto assinado. A credibilidade do certificado de raiz 402 pode ser estabelecida por distribuição física de segurança, por exemplo, durante a produção do terminal de pagamento 102 conforme discutido em maiores detalhes abaixo. Para conveniência de descrição, o certificado de raiz 402 é chamado no presente documento de um nível 1 ou certificado "L1". Será verificado que a hierarquia 400 pode incluir uma pluralidade de certificados L1, por exemplo, emitidos a partir de uma pluralidade de CAs de Raiz diferentes. Cada certificado de L1 ou a chave pública contida no mesmo, pode ser associado a um identificador único (um "Level1ID"). O Level1ID pode ser uma atribuição de número único industrial similar a um endereço MAC, um hash do certificado de L1 completo ou algum outro código único, cadeia, número, etc. Cada certificado de L1 ou sua chave pública e o identificador único corres-pondente pode ser associado a um outro na tabela de consulta 314 de modo que, quando um identificador único for fornecido, o(s) certifica- do(s) ou chave(s) pública(s) associado(s) possa(m) ser rapidamente recuperado(s) a partir do repositório de certificado 316.
[0040] A hierarquia de certificados também pode incluir um ou mais níveis de certificados subordinados que são assinados por uma autoridade de certificado superior e, desse modo, herdar a credibilidade da autoridade de certificado superior.
[0041] Na modalidade ilustrada, por exemplo, a hierarquia 400 inclui um ou mais certificados de rede de terminal de pagamento 404 emitidos a partir de redes de pagamento, como bancos emissores de cartão, compradores ou outros processadores de casamento. A hierarquia ilustrada 400 também inclui um ou mais certificados de portador móvel 406 emitidos a partir de consultor móvel. Para conveniência de descrição, os certificados de rede de terminal de pagamento 404 e os certificados de portador móvel 406 são chamados no presente documento de certificados de nível 2 ou "L2". Cada certificado L2 pode ser armazenado no repositório de certificado 316 e o certificado ou sua chave pública pode ser associada na tabela de consulta 314 com um identificador único (um "Level2ID"), conforme descrito acima. Os certificados L2 são imediatamente subordinados aos certificados L1 e podem, portanto, ser assinados pelo CA de Raiz para herdar a credibilidade da CA de Raiz. Cada chave pública L2 pode, desse modo, ser indexada na tabela de consulta 314 por um identificador único que especifica a chave pública L2 e sua chave pública L1 superior (por exemplo, Level2ID + Level1ID).
[0042] A hierarquia também pode incluir certificados que são subordinados aos certificados L2, na modalidade ilustrada, por exemplo, a hierarquia 400 inclui um ou mais certificados de fornecedor de terminal de pagamento 408 emitidos a partir de fabricantes ou distribuidores de terminais de pagamento. A hierarquia 400 também pode incluir um ou mais certificados de fornecedor de dispositivo móvel 410 emitidos a partir de fabricantes ou distribuidores de dispositivo móveis. Para conveniência de descrição, os certificados de fornecedor de terminal de pagamento 408 e o dispositivo móvel, certificados de fornecedor 410 são chamados no presente documento de certificados de nível 3 ou "L3". Cada certificado L3 pode ser armazenado no repositório de certi-ficado 316 e o certificado ou sua chave pública pode ser associada na tabela de consulta 314 com um identificador único (um "Level3ID"), conforme descrito acima. Os certificados L3 são imediatamente subordinados aos certificados L2 e podem, portanto, ser assinados por uma autoridade de certificado L2 para herdar a credibilidade da autoridade de certificado L2. Cada chave pública L3 pode, desse modo, ser indexada na tabela de consulta 314 por um identificador único que especifica a chave pública L3 e suas chaves públicas superiores L2 e L1 (por exemplo, Level3ID + Level2ID + Level1ID).
[0043] A hierarquia 400 também pode incluir um certificado específico de dispositivo 432 único ao terminal de pagamento individual 102. Para conveniência de descrição, o certificado específico de dispositivo 412 é chamado no presente documento com um certificado de nível 4 ou "L4". O certificado L4 pode ser assinado por uma autoridade de certificado L3 para herdar a credibilidade da autoridade de certificado L3,
[0044] Os certificados de raiz 402, os certificados de rede de terminal de pagamento 404, os certificados de fornecedor de terminal de pagamento 408 e o certificado de terminal de pagamento 412 podem ser chamados de certificados de "lado de terminal". Os certificados de raiz 402, os certificados de portador móvel 406, os certificados de fornecedor de dispositivo móvel 40 e um certificado de dispositivo móvel 414 (discutidos adicionalmente abaixo) podem ser chamados de certificados de "lado móvel". Os certificados podem ser chamados de "certificados superiores", "certificados mais superiores", "certificados inferiores", "certificados mais inferiores" e assim por diante com base em sua posição dentro da hierarquia 400 e o certificado cuja perspectiva está sendo descrita. Por exemplo, a partir da perspectiva de um certificado L4, um certificado L3 pode ser chamado de um certificado superior e um certificado L2 pode ser chamado de um certificado mais superior. Do mesmo modo, a partir da perspectiva de um certificado L4, um certificado L2 pode ser chamado de um certificado superior e um certificado L1 pode ser chamado de um certificado mais superior.
[0045] Embora uma hierarquia de certificados de quarto nível 400 seja mostrada e descrita no presente documento, será verificado que a hierarquia pode incluir qualquer número de níveis. Por exemplo, uma hierarquia de dois níveis pode ser usada uma vez que certificados específicos de dispositivo são assinados diretamente por um CA de Raiz. Uma hierarquia de terceiro nível também pode ser usada uma vez que certificados específicos de dispositivo são assinados por um subCA cujo certificado é, por sua vez, assinado por um CA de Raiz. As hierarquias nas quais três ou mais autoridades de certificado imediato existem na cadeia de confiança entre o certificado específico de dispo- sitivo e um CA de Raiz também pode ser usado. Além disso, o nível na hierarquia no qual uma entidade ou classe particular de certificados resides pode variar do que é mostrado e descrito no presente documento. Por exemplo, certificados de portador móvel podem ser subordinados a certificados de fornecedor de dispositivo móvel. Em algumas modalidades, o repositório 316 pode ser configurado, para um ou mais certificados na hierarquia 400, para armazenar apenas a porção de chave pública criptografada do(s) dito(s) certificado(s) (por exemplo, os certificados L3 e L4).
[0046] Em algumas modalidades, a hierarquia de certificados 400 pode ser parte de uma infraestrutura de chave pública (PKI), por exemplo, de acordo com o padrão industrial X 509. Uma PKI usa pares de chave pública/chave privada para criptografar e descriptografar de modo seguro informações. Uma chave pública pode seR1ivremente distribuída e pode ser usada para criptografar as informações. Para descriptografar as informações, no entanto, uma pessoa deve possuir uma chave privada associada à chave pública. Um algoritmo de criptografia de chave pública/chave privada exemplificativo é o sistema de criptografia de RSA. Um certificado digital pode incluir uma chave pública e uma assinatura digital. A assinatura digital é criada usando-se uma chave privada da pessoa, de modo que qualquer pessoa com acesso à chave pública da pessoa possa provar que o assinante acessou a chave privada da pessoa e, portanto, que a assinatura é autêntica.
[0047] Desse modo, no exemplo acima, o CA de Raiz armazena uma chave privada em uma localização altamente segura. O certificado de raiz 402 armazenado no repositório de certificado 316 inclui a chave pública que corresponde à chave privada e uma assinatura digital assinada do CA de Raiz com o uso da chave privada. Um certificado de raiz bem conhecido 402 pode ser instalado em um ambiente controlado (por exemplo, durante a fabricação) de modo que o certificado possa ser confiável. Outros certificados no repositório 316 podem ser confiáveis ou autenticados com base em um sistema hierárquico de chaves de criptografia e assinaturas digitais que retrocede para o certificado de raiz, conforme será verificado por aqueles versados na técnica.
[0048] A Figura 5 ilustra um diagrama de sequência exemplificati- vo para pré-carregar o repositório de certificado 316 durante a fabricação ou produção do terminal de pagamento 102. Agora, em referência às Figuras 3, 4, e 5, primeiro, o terminal de pagamento 102 autogera um par de chave L4 de dispositivo específico. A chave privada é armazenada em uma localização segura dentro do terminal de pagamento 02, por exemplo, o elemento seguro 216. A chave pública é entregue a um sistema de gerenciamento de segurança de produção 500 com um pedido para criptografia. O sistema de gerenciamento de segurança de produção 500 criptografa a chave pública L4 de dispositivo específico com o uso de sua própria chave privada (por exemplo, uma chave privada de fornecedor de terminal de pagamento L3). O certificado de chave pública resultante (assinado pelo subCA L3) é, então, devolvido para o terminal de pagamento 102. Os outros certificados de chave pública na cadeia de confiança para esse terminal de pagamento particular (por exemplo, o certificado de raiz L1 402, o certificado de rede de terminal de pagamento L2 404 e o certificado de fornecedor de terminal de pagamento L3 408) também são enviados para o terminal de pagamento 102 junto com seus identificadores únicos correspondentes (Level1ID, Level2ID e Level3ID). Devido ao fato de que o sistema de gerenciamento de segurança de produção 500 é um ambiente controlado, certificados bem conhecidos podem ser pré-carregados no repositório de certificado 316 do terminal de pagamento 102,
[0049] O sistema de gerenciamento de segurança de produção 500 também pode pré-carregar no repositório de certificado 16 uma pluralidade de certificados de lado móveis e seus identificadores únicos correspondentes. De modo alternativo ou além disso, um ou mais dos certificados de lado móveis podem ser carregados no repositório de certificado 316 no campo, por exemplo, por meio de uma rede como a rede de pagamento de abastecimento 1 12. Desse modo, quando o mesmo se torna necessário para o terminal de pagamento 102 para autenticar um dispositivo móvel 104, o terminal de pagamento pode ter pré-instalado um ou mais certificados na cadeia de confiança de dispositivo móvel.
[0050] Uma vez que os certificados de lado móveis são carregados no repositório de certificado 316, os mesmos podem ser pré- autenticados. Por exemplo, um certificado de lado móvel 1,3 (por exemplo, um certificado de fornecedor de dispositivo móvel 410) pode ser pré-autenticado pelo módulo de certificado 302 em relação a seus certificados L2 e L1 correspondentes de modo que a dada chave pública L3 possa ser usada diretamente em tempo de execução sem exigir a processo de autenticação L3 de certificado demorado a ser executado no tempo de execução. Se a pré-autenticação for bem- sucedida, as chaves públicas L1, L2 e L3 agora confiáveis podem ser armazenadas no repositório de certificado 316 com um identificador único correspondente que é adicionado à tabela de consulta 314. Em algumas modalidades, o identificador único pode ser uma concatena- ção do Level1ID, do Level2ID e do LeveDID. O pseudocódigo a seguir demonstra o processo de pré-autenticação de um certificado 1,3 e indexação de sua chave pública na tabela de consulta 314 de acordo com sua cadeia de confiança: Level1 PubKey = RetrievePubHcKeyFromCertificate {Lev- el1); AddIntolevel1 PublicKeylookup {Level1 PubKey, Level11D); Level2Pubkey = DecryptPubKeyFromCertificate (Level2, Level 1 PubKey); Addlntolevel2PublicKeylookup (Level2PubKey, Level11D, Level21D); Level3PubKey = DecryptPubKeyFromCertificaie (Level 3, Level2PubKey); Addintolevel3PubiicKeylookup (Level3PubKey, Levell11D, Level21D, Level31D);
[0051] O módulo de certificado 302 pode, desse modo, ser configurado para pré-autenticar um ou mais certificados de lado móveis para expedir autenticação de tempo de execução de um dispositivo móvel 104.
[0052] O módulo de recebimento de pedido de autenticação 304 pode ser configurado para receber um pedido de autenticação de uma autenticação de busca de dispositivo (por exemplo, um dispositivo móvel 04), o pedido de autenticação pode incluir uma variedade de informações. Em algumas modalidades, o pedido de autenticação pode incluir uma chave pública específica de dispositivo (por exemplo, uma chave pública L4) do dispositivo móvel 104. O pedido também pode incluir uma ou mais chaves públicas superiores na hierarquia de certificados de lado móvel. Enquanto o pedido pode incluir o(s) certifica- do(s) completo(s), em algumas modalidades, apenas a porção de chave pública do certificado é incluído reduzindo, desse modo, a carga útil de dados e tempo de transação de velocidade. O pedido também pode incluir informações de identificação para especificar a cadeia de confiança pela qual o dispositivo móvel 104 retrocede para um certificado de raiz confiável mútuo 402. Por exemplo, o pedido pode incluir uma concatenação de identificador único associado a cada certificado (ou chave pública do mesmo) na cadeia de confiança. O pedido também pode incluir informações usadas como um precursor para uma chave de sessão que por fim pode ser usada para criptografar dados sensíveis uma vez que a autenticação mútua está completa. Por exemplo, o precursor pode ser ou pode incluir um número aleatório gerado pelo dispositivo móvel 104.
[0053] O módulo de autenticação 306 pode ser configurado para validar chaves públicas recebidas no pedido de autenticação. Em particular, o módulo de autenticação 306 pode usar as informações de identificação no pedido para determinar a partir da tabela de consulta 314 o conjunto de chaves públicas pré-autenticadas exigidas para descriptografar a chave pública específica de dispositivo incluída no pedido. O módulo de autenticação 306 também pode ser configurado para pedir quaisquer certificados nas cadeias que podem estar faltando do repositório de certificado 316, por exemplo, do dispositivo móvel 104 ou da rede de pagamento de abastecimento 112.
[0054] O módulo de geração de chave de sessão 308 pode ser configurado para gerar uma chave de sessão quando o pedido de autenticação é validado com sucesso. Por exemplo, o módulo de geração de chave de sessão 308 pode combinar um precursor de chave de sessão gerado pelo terminal de pagamento 102 (por exemplo, um número aleatório) com o precursor de chave de sessão incluído no pedido para produzir uma chave de sessão final. A chave de sessão pode ser usada por dois dispositivos mutuamente autenticados para cripto- grafar e descriptografar informações comunicadas entre os dispositivos. O módulo de geração de chave de sessão 308 também pode ser configurado para gerar uma soma de verificação para uso por uma pessoa mutualmente autenticada para validar a chave de sessão.
[0055] O módulo de transmissão de resposta de autenticação 310 pode ser configurado para transmitir uma resposta de autenticação para o dispositivo móvel 104. A resposta de autenticação pode incluir uma variedade de informações, em algumas modalidades, a resposta de autenticação pode incluir uma chave pública específica de dispositivo (por exemplo, uma chave pública 14) do terminal de pagamento 102. A resposta também pode incluir uma ou mais chaves públicas superiores na hierarquia de certificados de lado terminal. Enquanto a resposta pode incluir o(s) certificado(s) completo(s), em algumas modalidades, apenas a porção de chave pública do certificado é incluída, reduzindo, desse modo, a carga útil e tempo de transação de velocidade. A resposta também pode incluir informações de identificação para especificar a cadeia de confiança pela qual o terminal de pagamento 302 retrocede para um certificado de raiz mútuo 402. Por exemplo, a resposta pode incluir uma concatenação de identificador único associado a cada certificado (ou chave pública do mesmo) na cadeia de confiança. A resposta também pode incluir a chave de sessão criptografada e soma de verificação.
[0056] O módulo de recebimento de informações seguras 312 pode ser configurado para receber informações seguras de um dispositivo autenticado e para descriptografar as informações com o uso da chave de sessão. Em particular, pagamento ou informações de fidelidade do usuário podem ser criptografados pelo dispositivo móvel 104 com o uso da chave de sessão e recebidos pelo módulo de recebimento de informações seguras 32. O módulo de recebimento de informações seguras 312 pode, então, descriptografar as informações com o uso da chave de sessão de modo que o terminal de pagamento 102 possa completar a transação.
MÓDULOS DE DISPOSITIVO MÓVEL
[0057] A Figura 6 é um diagrama esquemático dos módulos de uma modalidade exemplificativa do dispositivo móvel 104. Conforme mostrado, o dispositivo móvel 104 pode incluir um módulo de certificado 602, um módulo de transmissão de pedido de autenticação 604, um módulo de recebimento de resposta de autenticação 606, um módulo de autenticação 60S, um módulo de validação de chave de sessão 610 e um módulo de transmissão de informações seguras 62. O dispositivo móvel 104 também pode incluir uma tabela de consulta 614 e um repositório de certificado 616.
[0058] O módulo de certificado 602, a tabela de consulta 614 e o repositório de certificado 616 do dispositivo móvel 104 são substancialmente idênticos àqueles do terminal de pagamento 02, com umas poucas exceções conforme discutido abaixo. Uma diferença é que o certificado L4 414 no módulo de certificado 602 corresponde ao dispositivo móvel 104 em vez do terminal de pagamento 102. O dispositivo móvel 104 é pré-carregado com certificados instalados durante a fabricação e a produção do dispositivo móvel 104 ou os certificados podem ser transferidos por download por meio da nuvem de pagamento móvel 116 ou da nuvem de fidelidade móvel 114. A hierarquia de certificados do dispositivo móvel 104 é a mesma que a descrita acima, com o dispositivo móvel 104 que inclui os certificados em sua própria cadeia de confiança bem como um ou mais certificados de lado de terminal pré-autenticados.
[0059] O módulo de transmissão de pedido de autenticação 604 é configurado para montar o pedido de autenticação descrito acima e para enviar o pedido para o terminal de pagamento 102 quando acionado por um usuário (por exemplo, quando o usuário coloca o dispositivo móvel 104 na proximidade para o terminal de pagamento, quando o usuário inicializa um aplicativo no dispositivo móvel ou quando o usuário atua um elemento de interface de usuário no dispositivo móvel).
[0060] O módulo de recebimento de resposta de autenticação 606 é configurado para receber a resposta de autenticação descrita acima do terminal de pagamento 102.
[0061] O módulo de autenticação 608 é configurado para autenti- car a chave pública L4 recebida do terminal de pagamento 102 com o uso do sistema de autenticação conforme descrito acima em relação ao módulo de autenticação 306 do terminal de pagamento 102.
[0062] O módulo de validação de chave de sessão 610 é configurado para descriptografar a chave de sessão recebida do terminal de pagamento 102 com o uso da terminal chave pública L4 do terminal de pagamento e para validar a chave de sessão com o uso da soma de verificação recebida do terminal de pagamento.
[0063] O módulo de transmissão de informações seguras 612 é configurado para criptografar informações seguras com o uso da chave de sessão e para transmitir as informações seguras criptografadas para o terminal de pagamento 102 para completar uma transação.
OPERAÇÃO
[0064] Um método exemplificativo de conduzir uma transação mutuamente autenticada é ilustrado esquematicamente nas Figuras 7, 8 e 9. Embora diversos métodos revelados no presente documento possam ser mostrados em relação aos fluxogramas ou diagramas de sequência, deve ser verificado que qualquer ordenação de etapas de método implícitas por tais fluxogramas, diagramas de sequência ou a descrição das mesmas não devem ser interpretados como limitantes ao método para realizar as etapas naquela ordem. Em vez disso, as diversas etapas de cada um dos métodos revelados no presente documento podem ser realizadas em qualquer uma dentre uma variedade de sequências. Além disso, visto que os fluxogramas e diagramas de sequência ilustrados são meramente modalidades exemplificativas, diversos outros métodos que incluem etapas adicionais ou incluem menos etapas que as ilustradas também se encontram dentro do escopo da presente revelação.
[0065] A Figura 7 é um diagrama de sequência da transação mutuamente autenticada. O processo de autenticação mútuo pode, em algumas modalidades, envolver apenas uma troca única entre o terminal de pagamento 102 e o dispositivo móvel 104 (por exemplo, um pedido de autenticação transmitido do dispositivo móvel 104 para o terminal de pagamento 102 e uma resposta de autenticação transmitida do terminal de pagamento 102 para o dispositivo móvel 104). Completar o processo de autenticação em uma troca única pode diminuir vantajosamente a quantidade de tempo exigido para completar uma transação, aumentando a conveniência de usuário, inicialmente, o terminal de pagamento 102 está em um estado pronto aguardando por um dispositivo móvel 104 para iniciar uma transação. O terminal de pagamento 102 pode exibir um pedido de mensagem que o usuário inicia uma transação com o uso de seu dispositivo móvel 104.
[0066] Para começar a transação, o dispositivo móvel 104 envia um pedido de autenticação para o terminal de pagamento 102. Por exemplo, o módulo de transmissão de pedido de autenticação 604 do dispositivo móvel 104 pode transmitir um pedido de autenticação para o módulo de recebimento de pedido de autenticação 304 do terminal de pagamento 102. O pedido de autenticação pode incluir:
[0067] (1) a chave pública específica de dispositivo (por exemplo,L4) do dispositivo móvel 104, que é criptografada por uma chave privada L3 de lado móvel,
[0068] (2) a chave pública L3 de lado móvel, criptografada por uma chave privada L2 de lado móvel,
[0069] (3) um identificador único que especifica a cadeia de chaves públicas exigida para descriptografar a chave pública L4 do dispositivo móvel 104 (por exemplo, Level1ID+ Level2ID + Level3ID), e
[0070] (4) um número aleatório R1 gerado pelo dispositivo móvel 104 e criptografado pela chave privada L4 do dispositivo móvel.
[0071] Mediante o recebimento do pedido de autenticação, o terminal de pagamento 102 pode tentar autenticar a chave pública L4 re- cebida com o uso da tabela de consulta 314 e o repositório de certificado 316, em particular, o módulo de autenticação 306 do terminal de pagamento 102 pode usar o identificador único recebido (Level 1 ID + Level21D + Level31D) para localizar a chave pública L3 pré- autenticada que pode descriptografar a chave pública L4 do dispositivo móvel 104. Se a chave pública L3 estiver presente no terminal de pagamento 102, a chave pública L4 recebida pode ser descriptografada e, então, usada para descriptografar o número aleatório R1.
[0072] Em alguns casos, a chave pública L3 que pode descripto- grafar a chave pública L4 do dispositivo móvel 104 pode não ser pré- carregada no terminal de pagamento 102. Por exemplo, o certificado L3 de lado móvel pode ainda não estar disponível para transferência por download através da rede de pagamento de abastecimento 1 12, por exemplo, se o dispositivo móvel 104 for de uma marca, modelo ou consultor particular que é novo. Em tais casos, o módulo de autenticação 306 pode usar o identificador único recebido sem o Level3ID (isto é, Level1ID + Level2ID) para localizar a chave pública pré-autenticada L2 que pode descriptografar a chave pública L3 do dispositivo móvel 104. Se a chave pública L2 estiver presente no terminal de pagamento 102, a chave pública L3 recebida pode ser descriptografada e, então, usada, conforme descrito acima, para descriptografar a chave pública L4 que, por sua vez, descriptografa o número aleatório R1 A chave pública L3 recém descriptografada pode, então, ser armazenada no repositório de certificado 316 para uso futuro e seu identificador único correspondente (Level1ID + Level2ID + Level3ID) pode ser adicionado à tabela de consulta 314.
[0073] Se a chave pública L2 não estiver presente no terminal de pagamento 102, o terminal de pagamento pode tentaR1ocalizar a chave pública 1,2 através de uma rede, pedido a chave pública do dispositivo móvel 104 ou negando a transação.
[0074] Após o número aleatório R1 ser descriptografado, o módulo de geração de chave de sessão 308 do terminal de pagamento 102 pode gerar uma chave de sessão S1 para ser usada na realização da transação. Em algumas modalidades, o módulo de geração de chave de sessão 308 pode gerar seu próprio número aleatório R2 e criar a chave de sessão S1 com base em uma combinação do número aleatório R1 do dispositivo móvel e o número aleatório R2 do terminal de pagamento. Por exemplo, a chave de sessão S1 pode ser definida pelo exclusivo ou de R1 e R2:81 = XOR {R1, R2)
[0075] O módulo de geração de chave de sessão 30 S também pode gerar uma soma de verificação CHKSl da chave de sessão S1, por exemplo, calculando-se um hash da chave de sessão:CHK81 = Hash (81)
[0076] O módulo de geração de chave de sessão 308 pode, então, criptografar a chave de sessão S I com o uso da chave pública L4 do dispositivo móvel, de modo que apenas a chave privada armazenada no elemento seguro do dispositivo móvel 216 possa ser usada para descriptografar e obter a chave de sessão S1. A soma de verificação CHKSl pode ser criptografada com o uso da própria chave privada L4 do terminal de pagamento.
[0077] O pseudocódigo a seguir demonstra o processo de autenticar o dispositivo móvel 104 e gerar a chave de sessão S1 e soma de verificação de chave de sessão CHK.S 1; PubKey = Lookup(MobileDevicelevel11D + MobileDevice- level21 D + MobiieDevicelevel31D) If (PubKey == null) { Level2PubKey=Lookup (MobileDevicelevel11D + Mo- bileDevicelevel21D); se (Levsi2PubKey != null) { PubKey = DecryptPubKey (Encrypted Level3 PubKey, Lev- el2PubKey); NewCertificateAvailable =true; } } If (PubKey null) { Level4PubKey = Decrypt (Given Encrypted Level4 Pub Key, PubKey); R1 -Decrypt (Given Encrypted R1 , Level4PubKey); R2:= RandomGeneration(); 81 = R1 XOR R2; Encrypted81 = Encrypt (81 , Level4PubKey}; EncryptedCHK81 = Encrypt (Hash(81 ),MyPrivateKey);
[0078] Conforme verificado acima, se a chave pública L2 de lado móvel não estiver disponível no terminal de pagamento 102, a mesma pode ser obtida em alguns casos a partir da rede de pagamento de abastecimento 112, da rede de fidelidade de abastecimento 110, do dispositivo móvel 104 ou alguma outra fonte. Um processo exemplifi- cativo para obter e descriptografar a chave pública L2 de lado móvel é demonstrado pelo pseudocódigo a seguir: If (Level2Pubkey == null) { Obtainlevel2Cerif'ficate (*Given Level2); Level1 PubKey=Lookup (Given mobileDevicelevel11D); If (Level1 PubKey==null) Throw Exception of "No Pre-Stored Trusted Level1 Root CA" Level2PubKey=DecryptPubKeyFromCertificate (Level2, Level1 PubKey}; PubKey=DecryptPubKey (Encrypted Level3 PubKey, Lev- el2PubKey); NewCertificaieAvaiiabte =true;
[0079] Conforme também verificado acima, o terminal de pagamento 102 pode ser configurado para armazenar novos certificados obtidos no tempo de execução (por exemplo, do dispositivo móvel 104) e para adicionar os mesmos à tabela de consulta 314 para facilitar processamento mais rápido no futuro. Um processo exemplificativo para armazenar um novo certificado e adicionar o mesmo à tabela de consulta 314 é demonstrado pelo pseudocódigo a seguir: If (NewCertificateAvailable—true) { If {CanStoreAdditionalPubKeylntoIookupTable()==true} { AddIntolevel3LookupTable (PubKey,mobileDevicelevel11D, MobileDevicelevel21D, MobileDevicelevei31D); AddIntolevel2LookupTable(Level2PubKey, MobileDevice- Level 11D, MobileDevicelevel21D); ReportToMyNetwork(); } }
[0080] Após gerar a chave de sessão S1 e a soma de verificação de chave de sessão CHKS1, o terminal de pagamento 102 pode transmitir uma resposta de autenticação para o dispositivo móvel 104. Em particular, o módulo de transmissão de resposta de autenticação 310 do terminal de pagamento 302 pode transmitir a resposta de autenticação para o módulo de recebimento de resposta de autenticação 606 do dispositivo móvel 104.
[0081] A resposta de autenticação pode incluir:
[0082] (1) a chave pública específica de dispositivo (por exemplo, L4) do terminal de pagamento 102, que é criptografada por uma chave privada L3 de lado de terminal,
[0083] (2) a chave pública L3 de lado de terminal, criptografada por uma chave privada L2 de lado de terminal,
[0084] (3) um identificador único que especifica a cadeia de chaves públicas exigida para descriptografar a chave pública L4 do terminal de pagamento 102 (por exemplo, Level1ID + Level2ID + Level3ID),
[0085] (4) a chave de sessão S1, criptografada pela chave pública L4 do dispositivo móvel; e
[0086] (5) a soma de verificação de chave de sessão CHKS 1,criptografada pela chave privada L4 do terminal de pagamento.
[0087] Mediante o recebimento da resposta de autenticação, o dispositivo móvel 104 pode tentar autenticar a chave pública L4 recebida com o uso da tabela de consulta 614 e o repositório de certificado 616. Em particular, o módulo de autenticação 608 do dispositivo móvel 104 pode usar o identificador único recebido (Level1ID + Level2ID + Level3ID) para localizar a chave pública pré-autenticada L3 que pode descriptografar a chave pública L4 do terminal de pagamento 102. Se a chave pública L3 estiver presente no dispositivo móvel 104, a chave pública L4 recebida pode ser descriptografada.
[0088] Em alguns exemplos, a chave pública L3 que pode descrip- tografar a chave pública L4 do terminal de pagamento 102 pode não ser pré-carregada no dispositivo móvel 104. Por exemplo, o certificado L3 de lado de terminal pode ainda não estar disponível para transferir por download através da nuvem de pagamento móvel 114 ou da nuvem de pagamento móvel 116, por exemplo, se o terminal de pagamento 102 for de uma marca, modelo ou rede de pagamento particular que é nova. Em tais casos, o módulo de autenticação 608 pode usar o identificador único recebido sem o Level3ID (isto é, Level1ID+ Le- vel2ID) para localizar a chave pública pré-autenticada L2 que pode descriptografar a chave pública L3 do terminal de pagamento 102. Se a chave pública L2 estiver presente no dispositivo móvel 104, a chave pública L3 recebida pode ser descriptografa e, então, usada, conforme descrito acima, para descriptografar a chave pública L4. A chave pública L3 recém-descriptografada pode, então, ser armazenada no repositório de certificado 616 para uso futuro e seu identificador único correspondente (Level1ID + Level2ID + Level3ID) pode ser adicionado à tabela de consulta 614.
[0089] Se a chave pública L2 não estiver presente no dispositivo móvel 104, o dispositivo móvel pode tentaR1ocalizar a chave pública L2 através de uma rede, pedir a chave pública do terminal de pagamento 102 ou negar a transação.
[0090] Se a autenticação for bem-sucedida, o módulo de validação de chave de sessão 610 pode usar a própria chave privada L4 do dispositivo móvel para descriptografar a chave de sessão S1 e usar a chave pública L4 descriptografada do terminal de pagamento 102 para descriptografar a soma de verificação de chave de sessão CHKS1. O módulo de validação de chave de sessão 610 pode, então, verificar se a soma de verificação CHKS1 corresponde à chave de sessão S1. Se uma correspondência for revelada, tanto o dispositivo móvel 104 quanto o terminal de pagamento 102 estarão em posse do combinado mediante a chave de sessão S1 e o processo de autenticação mútuo é completado.
[0091] A chave de sessão S1 pode, então, ser usada para cripto- grafar e descriptografar dados de usuário transmitidos entre o dispositivo móvel 104 e o terminal de pagamento 102. Por exemplo, o módulo de transmissão de informações seguras 612 do dispositivo móvel 104 pode criptografar o número de conto primário do usuário (PAN), dados de expiração de cartão de crédito e código de segurança de cartão de crédito (CVV) com o uso da chave de sessão S1 e pode transmitir os dados criptografados para o terminal de pagamento 102. O módulo de recebimento de informações seguras 312 do terminal de pagamento 02 pode receber as informações de pagamento criptografadas e des- criptografar as mesmas com o uso da chave de sessão S1. As informações de fidelidade de usuário podem ser comunicadas de uma maneira similar.
[0092] O pseudocódigo a seguir demonstra o processo de autenticar o terminal de pagamento 102 e criptografar as informações de pagamento com o uso da chave de sessão S1, bem como obter certificados adicionais e atualizar a tabela de consulta 614, se necessário: Pubkey = Lookup(PaymentTerminallevel11D + Pay- mentTerminallevel21 D + PaymentTerminallevel31D) If (PubKey == null) { Level2PubKey = Lookup(PaymentTerrninallevel11D + PaymentTerminallevel21 D}; If (Level2PubKey !=null) { PubKey=DecryptPubKey (Encrypted Level3 PubKey, Lev- el2PubKey); NewCertificateAvailable = true; } If (Level2PubKey == null) Obtainlevel2Certificate (*Given Level2); Level1 PubKey = Lookup (Given PaymentTermi- nallevel11D); If (Level1PubKey == null) Throw Exception of "No Pre-strored Trusted Level1 root CA" Level2PubKey=DecryptPubKeyFromCertificate (Level2, Level1 PubKey); PubKey = DecryptPubKey (Encrypted Level3 PubKey, Lev- el2Pubkey); NewCertificateAvailable=true; } } If (PubKey !== null) Level4PubKey = Decrypt (Given Encrypted Level4 Pub Key, PubKey); 81 = Decrypt (Given Encrypted 81, MyPrivateKey); CHK81 = Decrypt(Given Encrypted CH 81, Level4PubKey); if (Hash(81) == CHK81) { EncryptedCardData=EncryptCardData (PAN, Expiration, CVV, 81}: } } If (NewCertificateAvailable ==true) { If (Can8toreAdditionalPubKeyintolookupTable() ==true) { AddIntolevel3LookupTable (PubKey, PaymentTermi- nallevel11D, PaymentTerminallevel21D, Paymentterminallevel31D); AddIntolevel2LookupTable (Level2PubKey, PaymentTermi- nallevel11D, PaymentTerminallevel21D); ReportToMyNetwork(); } }
[0093] Uma vez recebido pelo terminal de pagamento 102, o pagamento e/ou as informações de fidelidade podem ser processados através da rede de pagamento de combustível 112 e rede de fidelida- de de combustível 110 da mesma maneira como se o usuário estivesse apresentado um cartão de plástico de tira magnética tradicional.
[0094] A Figura 8 fornece uma vista geral do método descrito acima a partir da perspectiva do terminal de pagamento 102. Inicialmente, na etapa S800, o terminal de pagamento 102 é a ilha, na etapa S802, um pedido de autenticação recebido é recebido de um dispositivo móvel 104. No bloco de decisão D804, o terminal de pagamento 102 determina se uma chave pública L3 com capacidade de descriptografar a chave pública L4 recebida do dispositivo móvel 104 está disponível, se não, o terminal de pagamento 102 determina no bloco de decisão D806 se uma chave pública L2 com capacidade de descriptografar a chave pública L3 recebida está disponível. Se não, o certificado L2 é pedido do dispositivo móvel 104 na etapa S808, recebido na etapa S810 e acessado para credibilidade no bloco de decisão D81.2. Se o certificado L2 não for confiável, a autenticação mútua falha na etapa S814. Se o certificado L2 for confiável ou se a chave pública L2 estiver disponível no terminal de pagamento 102, a chave pública L3 é des- criptografada na etapa S816. Se a chave pública L3 foi descriptografa- da na etapa S816 ou estivesse no bloco de decisão D804, a chave pública L4 recebida e, por sua vez, o número aleatório recebido R1 seriam descriptografados na etapa S818. Na etapa S820, a resposta de autenticação é entregue ao dispositivo móvel 104 para autenticação e o terminal de pagamento 102 espera por uma resposta do dispositivo móvel na etapa S822. Se o dispositivo móvel 104 pedir o certificado L2 de lado de terminal (sim no bloco de decisão D824), o mesmo é transmitido para o dispositivo móvel na etapa S826 e a execução retorna para a etapa S822. Se o dispositivo móvel 104 tiver capacidade de autenticar o terminal de pagamento 102, pagamento e/ou informações de fidelidade criptografados são recebidos do dispositivo móvel na etapa S828 e o pagamento é processado na etapa S830.
[0095] A Figura, 9 fornece uma vista geral do método descrito acima a partir da perspectiva do dispositivo móvel 104. Inicialmente, na etapa S900, o dispositivo móvel 104 recebe uma instrução para iniciar uma transação, por exemplo, quando um usuário inicializa um aplicativo de pagamento móvel ou atua um botão ou outro elemento de interface de usuário, na etapa S902, o dispositivo móvel 104 envia um pedido de autenticação para o terminal de pagamento 102 e espera na etapa S904 por uma resposta do terminal de pagamento. Se o dispositivo móvel 104 receber um pedido do terminal de pagamento 102 para o certificado L2 de lado móvel, (sim no bloco de decisão D906), o dispositivo móvel envia o certificado na etapa S908 e a execução retorna para a etapa S904. De outro modo, o dispositivo móvel 104 processa a resposta de autenticação recebida do terminal de pagamento 102 e determina no bloco de decisão D910 se uma chave pública L3 com capacidade de descriptografar a chave pública L4 do terminal de pagamento estiver presente no dispositivo móvel. Se não, o dispositivo móvel 104 determina no bloco de decisão D912 se uma chave pública L2 com capacidade de descriptografar a chave pública L3 recebida está disponível. Se não, o certificado L2 é pedido do terminal de pagamento na etapa S914, recebido na etapa S916 e acessado para credibilidade no bloco de decisão D918. Se o certificado L2 não for confiável, a autenticação mútua falha na etapa S920. Se o certificado L2 for confiável ou se a chave pública L2 estiver disponível no dispositivo móvel 104, a chave pública L3 é descriptografada na etapa S922. Se a chave pública L3 estiver descriptografada na etapa 8922 ou estiver disponível no bloco de decisão D910, a chave pública L4 recebida e, por sua vez, a chave de sessão recebida S1 são descriptografadas na etapa S924. Finalmente, na etapa S926, o dispositivo móvel 104 envia dados sensíveis criptografados pela chave de sessão S1 para o terminal de pagamento 102.
[0096] Nos exemplos acima, o pedido de autenticação e a resposta de autenticação, cada um, incluem uma chave pública L4 criptografada e uma chave pública L3 criptografada. Deve-se observar, no entanto, que mais ou poucas chaves públicas podem ser incluídas no pedido de autenticação e/ou a resposta de autenticação. Por exemplo, o pedido e/ou a resposta podem incluir apenas uma única chave (por exemplo, a chave pública L4 criptografada). A título de exemplificação adicional, o pedido e/ou a resposta podem incluir a chave pública L4 criptografada, a chave pública L3 criptografada e uma ou mais chaves adicionais, como uma chave pública L2 criptografada.
[0097] O método das Figuras 7, 8 e 9 pode, desse modo, permitir que o terminal de pagamento 102 e o dispositivo móvel 104 da Figura 1 comecem uma comunicação segura com o uso de um processo de autenticação mútuo rápido, em particular, o terminal de pagamento 102 pode receber um pedido de autenticação do dispositivo móvel 104 e, se o dispositivo móvel for autenticado, responder com uma resposta de autenticação. Após essa troca única, assumindo-se que a autenticação seja bem-sucedida, ambas as partes possuem uma chave de sessão segura que pode ser usada para criptografar informações sensíveis por transmissão sem fio. Por exemplo, o dispositivo móvel 104 pode usar a chave de sessão para criptografar pagamento ou informações de fidelidade de consumidor e transmitir as informações cripto-grafadas para o terminal de pagamento 102, que pode descriptografar as informações com o uso da chave de sessão e, então, processar as informações através de canais normais.
ACESSO DE SERVIÇO
[0098] Em algumas modalidades, o dispositivo móvel pode ser um dispositivo móvel de serviço adquirido por um usuário que busca acessar o terminal de pagamento ou um dispensador de combustível ou outro sistema do qual é uma parte, para propósitos de serviço. Em tais casos, em vez de transmitir pagamento ou informações de fidelidade mediante a finalização do processo de autenticação mútuo, o dispositivo móvel de serviço pode ser configurado para transmitir uma instrução para abrir ou destravar uma porta de serviço, realizar um teste de diagnóstico ou realizar outras funções relacionadas ao serviço, se o dispositivo móvel de serviço for autenticado pelo terminal de pagamento, o terminal de pagamento pode responder ao pedido de serviço controlando-se um atuador para abrir ou destravar a porta de serviço, etc. Em conformidade, o pessoal de serviço pode ser autenticado para impedir acesso não autorizado ou serviço de campo não autorizado ou operações de resolução de problema, fornecendo, desse modo, segurança aprimorada quando comparado com um modelo de chave mecânica tradicional.
VANTAGENS/ EFEITOS TÉCNICOS
[0099] Os sistemas e métodos revelados no presente documento podem produzir um número de vantagens e/ou efeitos técnicos.
[00100] Por exemplo, em algumas modalidades, as digitais de certificado são pré-armazenadas e pré-autenticadas no terminal de pagamento e no dispositivo móvel, de modo que uma chave pública de tamanho reduzido/par de identificadores possa ser trocada em vez de uma pluralidade de certificados maiores habilitando, desse modo, autenticação e execução de transação rápidas. Em algumas modalidades, todo o processo de autenticação mútuo pode ser completado em menos de 500 ms, menos de 250 ms ou menos de 100 ms. Em algumas modalidades, o módulo de transmissão de resposta de autenticação pode ser configurado para transmitir a resposta de autenticação em menos de 500 ms, menos de 250 ms ou menos de 100 ms após um pedido de autenticação ser recebido pelo módulo de recebimento de pedido de autenticação.
[00101] A título de exemplificação adicional, em algumas modalida- des, autenticação mútua segura entre dois dispositivos pode ser completada com apenas uma transferência do primeiro dispositivo (por exemplo, um terminal de pagamento) para o segundo dispositivo (por exemplo, um dispositivo móvel) e uma transferência do segundo dispositivo para o primeiro dispositivo habilitando, desse modo, autenticação e execução de transação rápidas.
[00102] Vantagens exemplificativas adicionais e/ou efeitos técnicos que podem ser produzidos por um ou mais dos sistemas e métodos revelados no presente documento incluem: (1) comunicação mutuamente autenticada segura entre um dispositivo móvel e um terminal de pagamento sem exigir alterações extensivas ou integração de infraes- trutura de pagamento de combustível existente e infraestrutura de pagamento móvel, (2) uma interface de NFC segura para permitir que um terminal de pagamento possa autenticar mutuamente com um aplicativo de pagamento móvel para habilitar comunicação rápida e segura entre os dois, (3) nenhuma exigência para alteração em comunicação entre uma nuvem de pagamento móvel e uma nuvem de terminal de pagamento e (4) segurança aprimorada para acesso de serviço.
[00103] Esta descrição escrita usa exemplos para revelar a invenção, que inclui o melhor modo e também para habilitar qualquer pessoa versada na técnica a praticar a invenção, que inclui realizar e usar quaisquer dispositivos ou sistemas e realizar quaisquer métodos incorporados. O escopo patenteável da invenção é definido pelas reivindicações e pode incluir outros exemplos que ocorrer àqueles versados na técnica. Tais outros exemplos se destinam a estar dentro do escopo das reivindicações se os mesmos tiverem elementos estruturais que não se diferem da linguagem literal das reivindicações ou se os mesmos incluírem elementos estruturais equivalentes com diferenças insubstanciais das linguagens literais das reivindicações.

Claims (28)

1. Terminal caracterizado pelo fato de que compreende: um transceptor sem fio configurado para se comunicar sem fio com um dispositivo móvel; um elemento seguro configurado para armazenar uma ou mais chaves criptográficas pré-validadas; e um processador acoplado ao elemento seguro e ao trans- ceptor sem fio, em que o processador é programado para: receber, por meio do transceptor sem fio, uma solicitação de autenticação do dispositivo móvel, autenticar o dispositivo móvel validando-se a solicitação de autenticação com base nas uma ou mais chaves criptográficas pré- validadas armazenadas no elemento seguro, gerar uma chave de sessão com base em um número aleatório recebido na solicitação de autenticação, transmitir, por meio do transceptor sem fio, quando o dispositivo móvel é autenticado com sucesso, uma resposta de autenticação que inclui a chave de sessão para o dispositivo móvel, e receber informações seguras do dispositivo móvel, em que as informações seguras são criptografadas pela chave de sessão.
2. Terminal, de acordo com a reivindicação 1, caracterizado pelo fato de que o terminal compreende pelo menos um dentre um terminal de pagamento, um quiosque e um dispensador de combustível.
3. Terminal, de acordo com a reivindicação 1, caracterizado pelo fato de que o transceptor compreende um transceptor de comunicação de campo próximo (NFC).
4. Terminal, de acordo com a reivindicação 1, caracterizado pelo fato de que a solicitação de autenticação compreende: uma primeira chave pública específica ao dispositivo móvel, em que a primeira chave pública é criptografada por uma chave priva- da que é superior à primeira chave pública em uma hierarquia de certificados; um identificador único que especifica a cadeia de chaves públicas na hierarquia de certificados que descriptografa fundamentalmente a primeira chave pública; e um número aleatório R1 criptografado por uma chave privada que corresponde à primeira chave pública.
5. Terminal, de acordo com a reivindicação 4, caracterizado pelo fato de que a solicitação de autenticação não inclui um certificado digital que corresponde à primeira chave pública.
6. Terminal, de acordo com a reivindicação 4, caracterizado pelo fato de que o processador é configurado para validar a solicitação de autenticação ao: usar uma tabela de consulta para determinar se uma chave pública superior especificada no identificador único está armazenada no terminal e pré-validada; e se a chave pública superior estiver armazenada no terminal e pré-validada, recuperar a chave pública superior e descriptografar a primeira chave pública com o uso da chave pública superior.
7. Terminal, de acordo com a reivindicação 6, caracterizado pelo fato de que a solicitação de autenticação inclui a chave pública superior e em que o processador é configurado para validar a solicitação de autenticação ao: se a chave pública superior não estiver armazenada no terminal ou não estiver pré-validada, usar a tabela de consulta para determinar se uma chave pública mais superior especificada no identificador único está armazenada e pré-validada no terminal, e se a chave pública mais superior estiver armazenada e pré- validada no terminal, recuperar a chave pública mais superior e des- criptografar a chave pública superior com o uso da chave pública mais superior; e se a chave pública mais superior não estiver armazenada no terminal ou não estiver pré-validada, pelo menos um dentre solicitar a chave pública mais superior do dispositivo móvel, obter a chave pública mais superior de uma rede, e rejeitar a solicitação de autenticação como proveniente de um dispositivo móvel não autenticável.
8. Terminal, de acordo com a reivindicação 4, caracterizado pelo fato de que a chave de sessão compreende uma combinação do número aleatório R1 e um número aleatório R2 gerado pelo terminal.
9. Terminal, de acordo com a reivindicação 4, caracterizado pelo fato de que a resposta de autenticação compreende: uma segunda chave pública específica ao terminal, em que a segunda chave pública é criptografada por uma chave privada de lado de terminal que é superior à segunda chave pública na hierarquia de certificados; um identificador único de lado de terminal que especifica a cadeia de chaves públicas na hierarquia de certificados que descripto- grafa fundamentalmente a segunda chave pública; a chave de sessão, em que a dita chave de sessão é criptografada pela primeira chave pública do dispositivo móvel; e uma soma de verificação de chave de sessão gerada pelo processador, em que a dita soma de verificação de chave de sessão é criptografada por uma chave privada que corresponde à segunda chave pública do terminal.
10. Terminal, de acordo com a reivindicação 9, caracterizado pelo fato de que a resposta de autenticação não inclui um certificado digital que corresponde à segunda chave pública.
11. Terminal, de acordo com a reivindicação 9, caracterizado pelo fato de que a resposta de autenticação compreende uma chave pública superior de lado de terminal que corresponde à chave pri- vada superior de lado de terminal.
12. Terminal, de acordo com a reivindicação 1,, caracterizado pelo fato de que o terminal é configurado para completar um processo de autenticação com o dispositivo móvel em menos de 500 ms.
13. Terminal, de acordo com a reivindicação 1,, caracterizado pelo fato de que o terminal é configurado para completar um processo de autenticação com o dispositivo móvel em uma troca única.
14. Terminal, de acordo com a reivindicação 1, caracterizado pelo fato de que as informações seguras compreendem informações de pagamento e em que o terminal é configurado para completar uma transação de pagamento sem comunicação entre uma infraestru- tura de pagamento móvel à qual o dispositivo móvel é acoplado e uma infraestrutura de pagamento à qual o terminal é acoplado.
15. Terminal, de acordo com a reivindicação 1, caracterizado pelo fato de que as informações seguras compreendem uma instrução de serviço para abrir uma porta do terminal, e em que o terminal é configurado para abrir a porta em resposta à instrução de serviço.
16. Método de comunicação seguro para execução por um terminal que inclui um transceptor sem fio configurado para se comunicar sem fio com um dispositivo móvel, um elemento seguro configurado para armazenar uma ou mais chaves criptográficas pré-validadas, e um processador acoplado ao elemento seguro e ao transceptor sem fio, em que o método é caracterizado pelo fato de que compreende: receber, por meio do transceptor sem fio, uma solicitação de autenticação do dispositivo móvel; autenticar o dispositivo móvel com o uso do processador para validar a solicitação de autenticação com base nas uma ou mais chaves criptográficas pré-validadas armazenadas no elemento seguro; usar o processador para gerar uma chave de sessão com base em um número aleatório recebido na solicitação de autenticação; transmitir, por meio do transceptor sem fio, quando o dispositivo móvel é autenticado com sucesso, uma resposta de autenticação que inclui a chave de sessão para o dispositivo móvel; e receber, por meio do transceptor sem fio, informações seguras do dispositivo móvel, em que as informações seguras são criptografadas pela chave de sessão.
17. Método, de acordo com a reivindicação 16, caracterizado pelo fato de que compreende adicionalmente executar uma transação de pagamento com o uso das informações seguras e dispensar combustível de um dispensador de combustível acoplado de modo operacional ao terminal.
18. Método, de acordo com a reivindicação 16, caracterizado pelo fato de que a solicitação de autenticação compreende: uma primeira chave pública específica ao dispositivo móvel, em que a primeira chave pública é criptografada por uma chave privada que é superior à primeira chave pública em uma hierarquia de certificados; um identificador único que especifica a cadeia de chaves públicas na hierarquia de certificados que descriptografa fundamentalmente a primeira chave pública; e um número aleatório R1 criptografado por uma chave privada que corresponde à primeira chave pública.
19. Método, de acordo com a reivindicação 18, caracterizado pelo fato de que a solicitação de autenticação não inclui um certificado digital que corresponde à primeira chave pública.
20. Método, de acordo com a reivindicação 18, caracterizado pelo fato de que validar a solicitação de autenticação com o uso do processador compreende: usar uma tabela de consulta para determinar se uma chave pública superior especificada no identificador único está armazenada no terminal e pré-validada; e se a chave pública superior estiver armazenada no terminal e pré-validada, recuperar a chave pública superior e descriptografar a primeira chave pública com o uso da chave pública superior.
21. Método, de acordo com a reivindicação 20, caracterizado pelo fato de que a solicitação de autenticação inclui a chave pública superior e em que validar a solicitação de autenticação com o uso do processador compreende: se a chave pública superior não estiver armazenada no terminal ou não estiver pré-validada, usar a tabela de consulta para determinar se uma chave pública mais superior especificada no identificador único está armazenada e pré-validada no terminal, e se a chave pública mais superior estiver armazenada e pré- validada no terminal, recuperar a chave pública mais superior e des- criptografar a chave pública superior com o uso da chave pública mais superior; e se a chave pública mais superior não estiver armazenada no terminal ou não estiver pré-validada, pelo menos um dentre solicitar a chave pública mais superior do dispositivo móvel, obter a chave pública mais superior de uma rede, e rejeitar a solicitação de autenticação como proveniente de um dispositivo móvel não autenticável.
22. Método, de acordo com a reivindicação 18, caracterizado pelo fato de que a chave de sessão compreende uma combinação do número aleatório R1 e um número aleatório R2 gerado pelo terminal.
23. Método, de acordo com a reivindicação 18, caracterizado pelo fato de que a resposta de autenticação compreende: uma segunda chave pública específica ao terminal, em que a segunda chave pública é criptografada por uma chave privada de lado de terminal que é superior à segunda chave pública na hierarquia de certificados; um identificador único de lado de terminal que especifica a cadeia de chaves públicas na hierarquia de certificados que descripto- grafa fundamentalmente a segunda chave pública; a chave de sessão, em que a dita chave de sessão é criptografada pela primeira chave pública do dispositivo móvel; e uma soma de verificação de chave de sessão gerada pelo processador, em que a dita soma de verificação de chave de sessão é criptografada por uma chave privada que corresponde à segunda chave pública do terminal.
24. Método, de acordo com a reivindicação 23, caracterizado pelo fato de que a resposta de autenticação não inclui um certificado digital que corresponde à segunda chave pública.
25. Método, de acordo com a reivindicação 23, caracterizado que a resposta de autenticação compreende uma chave pública superior de lado de terminal que corresponde à chave privada superior de lado de terminal.
26. Método, de acordo com a reivindicação 16, caracterizado pelo fato de que as informações seguras compreendem uma instrução de serviço para abrir uma porta do terminal, e em que o método inclui controlar um atuador eletrônico para abrir a porta em resposta à instrução de serviço.
27. Método, de acordo com a reivindicação 16, caracterizado pelo fato de que o terminal completa um processo de autenticação com o dispositivo móvel em uma troca única.
28. Método, de acordo com a reivindicação 16, caracterizado pelo fato de que as informações seguras compreendem informações de pagamento e em que o método inclui completar uma transação de pagamento sem comunicação entre uma infraestrutura de pagamento móvel à qual o dispositivo móvel é acoplado e uma infraestru- tura de pagamento à qual o terminal é acoplado.
BR112015028071-4A 2013-05-09 2014-05-02 Sistemas e métodos para comunicação segura BR112015028071B1 (pt)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US13/890,734 US11127001B2 (en) 2013-05-09 2013-05-09 Systems and methods for secure communication
US13/890,734 2013-05-09
PCT/US2014/036526 WO2014182557A1 (en) 2013-05-09 2014-05-02 Systems and methods for secure communication

Publications (2)

Publication Number Publication Date
BR112015028071A2 BR112015028071A2 (pt) 2017-07-25
BR112015028071B1 true BR112015028071B1 (pt) 2023-04-11

Family

ID=50896554

Family Applications (1)

Application Number Title Priority Date Filing Date
BR112015028071-4A BR112015028071B1 (pt) 2013-05-09 2014-05-02 Sistemas e métodos para comunicação segura

Country Status (10)

Country Link
US (2) US11127001B2 (pt)
EP (1) EP2995039B1 (pt)
CN (1) CN105556892B (pt)
BR (1) BR112015028071B1 (pt)
CA (1) CA2911637C (pt)
DK (1) DK2995039T3 (pt)
ES (1) ES2712150T3 (pt)
PT (1) PT2995039T (pt)
TR (1) TR201902104T4 (pt)
WO (1) WO2014182557A1 (pt)

Families Citing this family (52)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9860274B2 (en) 2006-09-13 2018-01-02 Sophos Limited Policy management
EP2396271B1 (en) 2009-02-11 2023-09-13 PepsiCo, Inc. Beverage dispense valve controlled by wireless technology
US8898769B2 (en) 2012-11-16 2014-11-25 At&T Intellectual Property I, Lp Methods for provisioning universal integrated circuit cards
US8959331B2 (en) 2012-11-19 2015-02-17 At&T Intellectual Property I, Lp Systems for provisioning universal integrated circuit cards
US9948614B1 (en) * 2013-05-23 2018-04-17 Rockwell Collins, Inc. Remote device initialization using asymmetric cryptography
EP3036680B1 (en) * 2013-08-21 2018-07-18 Intel Corporation Processing data privately in the cloud
US9036820B2 (en) 2013-09-11 2015-05-19 At&T Intellectual Property I, Lp System and methods for UICC-based secure communication
US9124573B2 (en) 2013-10-04 2015-09-01 At&T Intellectual Property I, Lp Apparatus and method for managing use of secure tokens
US9208300B2 (en) 2013-10-23 2015-12-08 At&T Intellectual Property I, Lp Apparatus and method for secure authentication of a communication device
US9240994B2 (en) 2013-10-28 2016-01-19 At&T Intellectual Property I, Lp Apparatus and method for securely managing the accessibility to content and applications
AU2014342209B2 (en) * 2013-10-30 2020-09-24 Gilbarco Inc. Cryptographic watermarking of content in fuel dispensing environments
US9313660B2 (en) 2013-11-01 2016-04-12 At&T Intellectual Property I, Lp Apparatus and method for secure provisioning of a communication device
US9240989B2 (en) 2013-11-01 2016-01-19 At&T Intellectual Property I, Lp Apparatus and method for secure over the air programming of a communication device
US9133012B2 (en) 2013-11-18 2015-09-15 Wayne Fueling Systems Sweden Ab Systems and methods for fuel dispenser security
US9276910B2 (en) * 2013-11-19 2016-03-01 Wayne Fueling Systems Llc Systems and methods for convenient and secure mobile transactions
US9413759B2 (en) 2013-11-27 2016-08-09 At&T Intellectual Property I, Lp Apparatus and method for secure delivery of data from a communication device
US10861090B2 (en) * 2013-11-27 2020-12-08 Apple Inc. Provisioning of credentials on an electronic device using passwords communicated over verified channels
US9713006B2 (en) 2014-05-01 2017-07-18 At&T Intellectual Property I, Lp Apparatus and method for managing security domains for a universal integrated circuit card
CA2960378C (en) 2014-05-30 2021-01-12 Wayne Fueling Systems Llc Methods and systems for communication between a fuel dispenser and a mobile device
US20150372865A1 (en) * 2014-06-23 2015-12-24 Rockwell Automation Technologies, Inc. System and method for autonomous dynamic provisioning
US20160065374A1 (en) * 2014-09-02 2016-03-03 Apple Inc. Method of using one device to unlock another device
US9716716B2 (en) * 2014-09-17 2017-07-25 Microsoft Technology Licensing, Llc Establishing trust between two devices
US10210500B2 (en) * 2014-09-23 2019-02-19 Mastercard International Incorporated Ultrasonic triangulation for payments method and apparatus
US10419271B2 (en) * 2014-12-30 2019-09-17 Lg Cns Co., Ltd. Public transportation fee payment system and operating method thereof
US10009324B2 (en) * 2015-06-29 2018-06-26 American Express Travel Related Services Company, Inc. Host card emulation systems and methods
US10943014B2 (en) 2015-10-01 2021-03-09 Twistlock, Ltd Profiling of spawned processes in container images and enforcing security policies respective thereof
US10223534B2 (en) 2015-10-15 2019-03-05 Twistlock, Ltd. Static detection of vulnerabilities in base images of software containers
US10664590B2 (en) 2015-10-01 2020-05-26 Twistlock, Ltd. Filesystem action profiling of containers and security enforcement
US10922418B2 (en) 2015-10-01 2021-02-16 Twistlock, Ltd. Runtime detection and mitigation of vulnerabilities in application software containers
US10586042B2 (en) 2015-10-01 2020-03-10 Twistlock, Ltd. Profiling of container images and enforcing security policies respective thereof
US10706145B2 (en) 2015-10-01 2020-07-07 Twistlock, Ltd. Runtime detection of vulnerabilities in software containers
US10599833B2 (en) 2015-10-01 2020-03-24 Twistlock, Ltd. Networking-based profiling of containers and security enforcement
US10567411B2 (en) 2015-10-01 2020-02-18 Twistlock, Ltd. Dynamically adapted traffic inspection and filtering in containerized environments
US20170099981A1 (en) * 2015-10-08 2017-04-13 Michel Abou Haidar Callisto integrated tablet computer in hot and cold dispensing machine
US20170099980A1 (en) * 2015-10-08 2017-04-13 Michel Abou Haidar Integrated tablet computer in hot and cold dispensing machine
US10778446B2 (en) * 2015-10-15 2020-09-15 Twistlock, Ltd. Detection of vulnerable root certificates in software containers
US9794072B2 (en) * 2015-11-05 2017-10-17 Redline Communications Inc. Certificate exchange mechanism for wireless networking
WO2017214617A1 (en) * 2016-06-10 2017-12-14 Gilbarco Inc. Fuel dispenser utilizing tokenized user guidance and prompting for secure payment
US10897360B2 (en) * 2017-01-26 2021-01-19 Microsoft Technology Licensing, Llc Addressing a trusted execution environment using clean room provisioning
US10885211B2 (en) 2017-09-12 2021-01-05 Sophos Limited Securing interprocess communications
US11620638B2 (en) 2017-10-31 2023-04-04 Wayne Fueling Systems Llc Methods, systems, and devices for loading currency into an electronic wallet
GB201720946D0 (en) * 2017-12-15 2018-01-31 Nchain Holdings Ltd Computer-implemented system and method
KR20200096248A (ko) 2017-12-13 2020-08-11 엔체인 홀딩스 리미티드 암호 자료를 안전하게 공유하기 위한 시스템 및 방법
US10902422B2 (en) * 2018-02-05 2021-01-26 Wayne Fueling Systems Llc Methods and devices for mobile payment transactions with a product dispenser
WO2019199836A1 (en) * 2018-04-09 2019-10-17 Averon Us, Inc. Secure communication using device-identity information linked to cloud-based certificates
SG11202104170PA (en) 2018-10-29 2021-05-28 Visa Int Service Ass Efficient authentic communication system and method
US11443582B2 (en) * 2018-12-03 2022-09-13 AvaLAN Wireless Systems, Inc. Virtual payment system and method for dispensing fuel
EP3672308B1 (de) * 2018-12-14 2021-08-25 Deutsche Telekom AG Authorization method and terminal for releasing or blocking resources
KR20220066357A (ko) * 2019-09-25 2022-05-24 지오 플랫폼즈 리미티드 다중 폐쇄 루프 보안 거래의 시스템 및 방법
US11496892B2 (en) * 2021-01-22 2022-11-08 Dell Products L.P. Secure infrastructure onboarding system
CN113591109B (zh) * 2021-07-23 2023-05-02 上海瓶钵信息科技有限公司 可信执行环境与云端通信的方法及系统
CN114024791A (zh) * 2021-10-28 2022-02-08 浪潮软件科技有限公司 一种智慧家庭安全通信方法和系统

Family Cites Families (46)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7366900B2 (en) * 1997-02-12 2008-04-29 Verizon Laboratories, Inc. Platform-neutral system and method for providing secure remote operations over an insecure computer network
US6005945A (en) * 1997-03-20 1999-12-21 Psi Systems, Inc. System and method for dispensing postage based on telephonic or web milli-transactions
US6229894B1 (en) * 1997-07-14 2001-05-08 Entrust Technologies, Ltd. Method and apparatus for access to user-specific encryption information
US6029043A (en) * 1998-01-29 2000-02-22 Ho; Chi Fai Computer-aided group-learning methods and systems
JP2001352321A (ja) 2000-04-06 2001-12-21 Sony Corp 情報処理システム、情報処理方法、および情報記録媒体、並びにプログラム提供媒体
JP2002014929A (ja) * 2000-04-26 2002-01-18 Sony Corp アクセス制御システム、アクセス制御方法、およびデバイス、アクセス制御サーバ、アクセス制御サーバ登録サーバ、データ処理装置、並びにプログラム記憶媒体
DE10025626A1 (de) * 2000-05-24 2001-11-29 Deutsche Telekom Ag Verschlüsseln von abzuspeichernden Daten in einem IV-System
US20010037302A1 (en) * 2000-05-31 2001-11-01 Javien, Inc. Data web object host discovery system
JP2002056325A (ja) * 2000-08-08 2002-02-20 Nec Corp 電子決済方法およびシステムとその決済センタ装置、個人情報入力端末およびプログラムを記録した記録媒体
US20020147905A1 (en) * 2001-04-05 2002-10-10 Sun Microsystems, Inc. System and method for shortening certificate chains
US7636840B2 (en) * 2002-07-10 2009-12-22 Dresser, Inc. Secure communications and control in a fueling environment
US7822688B2 (en) 2002-08-08 2010-10-26 Fujitsu Limited Wireless wallet
JP4617763B2 (ja) * 2003-09-03 2011-01-26 ソニー株式会社 機器認証システム、機器認証サーバ、端末機器、機器認証方法、および機器認証プログラム
CN1658547B (zh) 2004-02-16 2010-08-18 华为技术有限公司 密钥分发方法
CN100544247C (zh) 2004-02-16 2009-09-23 华为技术有限公司 安全能力协商方法
CN100359845C (zh) 2004-03-26 2008-01-02 中兴通讯股份有限公司 无线局域网自组网模式共享密钥认证和会话密钥协商方法
US20050256742A1 (en) * 2004-05-05 2005-11-17 Kohan Mark E Data encryption applications for multi-source longitudinal patient-level data integration
US20060012479A1 (en) * 2004-06-18 2006-01-19 Meir Ezra Fuel dispensing system
JP4671783B2 (ja) * 2004-07-20 2011-04-20 株式会社リコー 通信システム
DE102004037801B4 (de) * 2004-08-03 2007-07-26 Siemens Ag Verfahren zur sicheren Datenübertragung
CN100544249C (zh) 2004-10-29 2009-09-23 大唐移动通信设备有限公司 移动通信用户认证与密钥协商方法
EP1653655B1 (en) 2004-10-29 2006-11-29 Research In Motion Limited System and method for verifying digital signatures on certificates
JP4502393B2 (ja) * 2005-06-13 2010-07-14 キヤノン株式会社 通信パラメータの共有方法及び通信装置
US7835528B2 (en) * 2005-09-26 2010-11-16 Nokia Corporation Method and apparatus for refreshing keys within a bootstrapping architecture
JP4435076B2 (ja) * 2005-11-18 2010-03-17 フェリカネットワークス株式会社 携帯端末，データ通信方法，およびコンピュータプログラム
US7814538B2 (en) 2005-12-13 2010-10-12 Microsoft Corporation Two-way authentication using a combined code
KR101346734B1 (ko) * 2006-05-12 2014-01-03 삼성전자주식회사 디지털 저작권 관리를 위한 다중 인증서 철회 목록 지원방법 및 장치
CN101111056B (zh) 2006-07-17 2010-05-12 西安电子科技大学 在无线局域网中的快速切换方法
DK2057819T3 (da) * 2006-08-31 2011-12-19 Encap As Fremgangsmåde til synkronisering imellem en server og et mobilt apparat
US9830637B2 (en) * 2007-02-23 2017-11-28 Epona Llc System and method for processing vehicle transactions
US8345871B2 (en) 2007-03-15 2013-01-01 Palo Alto Research Center Incorporated Fast authentication over slow channels
US8539233B2 (en) 2007-05-24 2013-09-17 Microsoft Corporation Binding content licenses to portable storage devices
US7739169B2 (en) 2007-06-25 2010-06-15 Visa U.S.A. Inc. Restricting access to compromised account information
US10558961B2 (en) * 2007-10-18 2020-02-11 Wayne Fueling Systems Llc System and method for secure communication in a retail environment
CN101420413B (zh) 2007-10-25 2012-11-07 华为技术有限公司 会话密钥协商方法、认证服务器及网络设备
US20090144194A1 (en) * 2007-11-30 2009-06-04 Mark Dickelman Computer automated systems, devices and methods for data processing of accounting records
KR100997238B1 (ko) 2008-03-03 2010-11-29 삼성전자주식회사 Crum 유닛, 교체가능유닛 및 이를 이용하는 화상형성장치와, 그 인증 및 암호화 데이터 통신 방법
US8112066B2 (en) 2009-06-22 2012-02-07 Mourad Ben Ayed System for NFC authentication based on BLUETOOTH proximity
EP2290601A1 (en) 2009-08-24 2011-03-02 Afone Method and system for secure mobile payment
US8850203B2 (en) * 2009-08-28 2014-09-30 Alcatel Lucent Secure key management in multimedia communication system
CN102081769A (zh) 2009-11-27 2011-06-01 阿里巴巴集团控股有限公司 支付数据处理方法、系统、支付终端及支付服务器
US8601266B2 (en) * 2010-03-31 2013-12-03 Visa International Service Association Mutual mobile authentication using a key management center
US8550903B2 (en) 2010-11-15 2013-10-08 Bally Gaming, Inc. System and method for bonus gaming using a mobile device
US10380570B2 (en) * 2011-05-02 2019-08-13 Ondot System, Inc. System and method for secure communication for cashless transactions
EP2954709A4 (en) * 2013-02-08 2016-08-31 Schlage Lock Co Llc CONTROL SYSTEM AND METHOD
US9276910B2 (en) * 2013-11-19 2016-03-01 Wayne Fueling Systems Llc Systems and methods for convenient and secure mobile transactions

Also Published As

Publication number Publication date
CN105556892B (zh) 2021-07-06
CA2911637C (en) 2020-03-24
PT2995039T (pt) 2019-02-26
EP2995039B1 (en) 2018-11-28
US11127001B2 (en) 2021-09-21
WO2014182557A1 (en) 2014-11-13
US20140337234A1 (en) 2014-11-13
US20210406882A1 (en) 2021-12-30
BR112015028071A2 (pt) 2017-07-25
CN105556892A (zh) 2016-05-04
CA2911637A1 (en) 2014-11-13
ES2712150T3 (es) 2019-05-09
DK2995039T3 (en) 2019-03-18
EP2995039A1 (en) 2016-03-16
TR201902104T4 (tr) 2019-03-21

Similar Documents

Publication Publication Date Title
BR112015028071B1 (pt) Sistemas e métodos para comunicação segura
ES2970201T3 (es) Sistema de identificación personal con tarjeta sin contacto
US11276051B2 (en) Systems and methods for convenient and secure mobile transactions
US12008560B2 (en) On-boarding server for authorizing an entity to effect electronic payments
ES2599985T3 (es) Validación en cualquier momento para los tokens de verificación
ES2802265T3 (es) Método de autorización de una operación que va a realizarse en un dispositivo informático objetivo
TW202105282A (zh) 數位交易處理單元之應用鎖定及解鎖
CN108683674A (zh) 门锁通信的验证方法、装置、终端及计算机可读存储介质
KR20240045160A (ko) 신뢰 루트(Root-of-Trust) 기반의 보안을 갖는 암호화되고 인증된 펌웨어 제공 방법 및 시스템
US9398005B1 (en) Managing seed provisioning
JP2009105856A (ja) 情報処理装置および方法、記録媒体、プログラム、並びに情報処理システム

Legal Events

Date Code Title Description
B06F Objections, documents and/or translations needed after an examination request according [chapter 6.6 patent gazette]
B06U Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette]
B350 Update of information on the portal [chapter 15.35 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 02/05/2014, OBSERVADAS AS CONDICOES LEGAIS