BR102018015221B1 - método para compartilhamento seguro de informações e sistema relacionado - Google Patents

método para compartilhamento seguro de informações e sistema relacionado Download PDF

Info

Publication number
BR102018015221B1
BR102018015221B1 BR102018015221A BR102018015221A BR102018015221B1 BR 102018015221 B1 BR102018015221 B1 BR 102018015221B1 BR 102018015221 A BR102018015221 A BR 102018015221A BR 102018015221 A BR102018015221 A BR 102018015221A BR 102018015221 B1 BR102018015221 B1 BR 102018015221B1
Authority
BR
Brazil
Prior art keywords
secure
processor
data
key
confidential data
Prior art date
Application number
BR102018015221A
Other languages
English (en)
Other versions
BR102018015221B8 (pt
BR102018015221A2 (pt
Inventor
Jeremiah Murray Brian
Original Assignee
Clover Network Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Clover Network Inc filed Critical Clover Network Inc
Publication of BR102018015221A2 publication Critical patent/BR102018015221A2/pt
Publication of BR102018015221B1 publication Critical patent/BR102018015221B1/pt
Publication of BR102018015221B8 publication Critical patent/BR102018015221B8/pt

Links

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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/606—Protecting data by securing the transmission between two devices or processes
    • 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/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • 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/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • G06Q20/207—Tax processing
    • 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/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • 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/002—Countermeasures against attacks on cryptographic mechanisms
    • 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/0866—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving user or device identifiers, e.g. serial number, physical or biometrical information, DNA, hand-signature or measurable physical characteristics
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • 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/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • 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/3247—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 digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • 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
    • G06Q2220/00—Business processing using cryptography
    • 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/08—Randomization, e.g. dummy operations or using noise
    • 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/16—Obfuscation or hiding, e.g. involving white box
    • 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/56—Financial cryptography, e.g. electronic payment or e-cash

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Finance (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computing Systems (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Telephone Function (AREA)
  • Storage Device Security (AREA)

Abstract

são descritos sistemas e métodos associados que envolvem um dispositivo confiável e um dispositivo não confiável onde os dados sensíveis ou chaves são compartilhados entre esses dispositivos. um método revelado inclui armazenar uma chave em uma memória segura em um primeiro dispositivo, receber dados sensíveis através de uma interface de usuário em um segundo dispositivo, gerar um conjunto de instruções de encriptação de caixa branca com base na chave usando um gerador de encriptação de caixa branca no primeiro dispositivo, gerar uma representação de dados completa do conjunto de instruções de encriptação de caixa branca usando um processador seguro no primeiro dispositivo, transmitir a representação de dados completa a partir do primeiro dispositivo ao segundo dispositivo, e encriptar os dados sensíveis usando a representação de dados completa no segundo dispositivo. a representação de dados completa não é turing-completa e não é executável em relação ao segundo dispositivo.

Description

MÉTODO PARA COMPARTILHAMENTO SEGURO DE INFORMAÇÕES E SISTEMA RELACIONADO
FUNDAMENTOS [001] Em determinados ambientes técnicos, requer-se que um dispositivo confiável e um dispositivo não confiável compartilhem seguramente informações. Conforme o uso em questão, a confiança é definida em relação à perspectiva de um observador, tal como o fabricante de um dispositivo, e se refere a um nível de confiança mantido portal observador quanto a quão seguro um sistema é. Em geral, um fabricante será capaz de garantir que os dispositivos que eles produzem sejam confiáveis, mas não podem ter o mesmo nível de confiança em dispositivos produzidos por terceiras partes não relacionadas. Portanto, o fabricante deve considera a possibilidade que os dados armazenados na memória de um dispositivo não confiável possam ser monitorados e extraídos sem a permissão do operador de tal dispositivo não confiável.
[002] Um exemplo específico de um dos ambientes técnicos supramencionados é ilustrado na Figura 1. Um leitor de cartão seguro 100 pode ser pareado a um smartphone 101, ou outro dispositivo, para propósitos de processar um pagamento. Os leitores de cartão seguros que são configurados para uso com smartphones e tablets padrão estão apelando a partir de uma perspectiva de conveniência de usuário devido à flexibilidade que eles proporcionam e à divisão de trabalho entre um dispositivo de tarefa específica de baixo custo e um dispositivo de interface de usuário mais complexo que já esteja amplamente disponível. Os leitores de cartão seguro padrão que se encontram disponíveis atualmente obterão dados confidenciais a partir de um cartão de pagamento 102 e os encriptarão internamente. O leitor de cartão seguro pode, então, transmitir os dados encriptados a um processador de pagamento 103. Nessa situação, o dispositivo não confiável (isto é, smartphone
Petição 870190009787, de 30/01/2019, pág. 10/57
2/35
101) nunca está em contato com os dados confidenciais não encriptados, e ao invés disso, meramente proporciona um meio para interface ao usuário. O termo dispositivo de entrada de usuário é usado no presente documento para se referir ao smartphone, tablet, ou outro dispositivo discreto que esteja operando em tandem com o leitor de cartão seguro para se comunicar com um usuário e processar um pagamento.
[003] Em determinados fluxos de pagamento, dados confidenciais são proporcionados a partir de um usuário através do leitor de cartão e do dispositivo de entrada de usuário separado. Por exemplo, conforme mostrado na metade inferior da Figura 1, o leitor de cartão seguro 100 pode ser usado para obter um número de conta pessoal (PAN) a partir de uma tarja magnética ou chip em um cartão de débito, enquanto o smartphone 101 é usado para obter um número de identificação pessoal (PIN) a partir do detentor do cartão usando uma tela sensível ao toque. Nessa situação, o leitor de cartão seguro 100 e o smartphone 101 precisarão encriptar os dados que eles recebem para manter o nível necessário de segurança associado ao processamento de pagamentos.
[004] Leitores de cartão seguros se encontram amplamente disponíveis, mas a capacidade de receber um PIN on glass através da tela sensível ao toque de qualquer dado smartphone é uma funcionalidade que não está amplamente disponível devido a dificuldades da indústria com a extensão da segurança baseada em padrões a um smartphone arbitrário. Portanto, por causa da dificuldade de compartilhar dados seguros e chaves de encriptação com um dispositivo inseguro ou não confiável, os fluxos de pagamento que envolvem a entrada de um pin em um smartphone geralmente não são suportados pela combinação conveniente de um leitor de cartão seguro e smartphone.
[005] A comunicação segura entre os dispositivos é geralmente obtida através de uma troca de chaves, tais como aquelas usadas para encriptação
Petição 870190009787, de 30/01/2019, pág. 11/57
3/35 simétrica ou assimétrica. No sistema da Figura 1, uma solução que pode mitigar questões de segurança seria encriptar o PIN no smartphone 101 usando uma chave 105 previamente proporcionada a partir do leitor de cartão seguro 100 pela linha 104. No entanto, a natureza não confiável do smartphone 101 complica essa abordagem. Conforme supramencionado, uma chave compartilhada com um dispositivo não confiável poderia ser essencialmente exposta quando for armazenada ou usada por um dispositivo não confiável. Em um caso extremo, um invasor pode ter a capacidade de monitorar a execução de código no dispositivo não confiável e extrai a chave. Essa extração pode ser obtida furtando-se diretamente os dados de chave, monitorando-se os valores intermitentes gerados na memória durante um processo de encriptação e extrapolando-se os dados de chave, ou monitorando-se a entrada-saída do processo de encriptação por muitas amostras para extrapolar os dados de chave.
SUMÁRIO [006] Determinadas abordagens descritas no presente documento se referem a um sistema que envolve tanto um dispositivo confiável (também mencionado no presente documento como dispositivo seguro ou primeiro dispositivo) como um dispositivo não confiável (também mencionado no presente documento como dispositivo não seguro ou um segundo dispositivo) onde dados ou chaves confidenciais são compartilhados entre esses dispositivos. Os dispositivos confiáveis e não confiáveis podem ser dispositivos discretos. No espaço de pagamentos, um dispositivo confiável seguro poderia ser um leitor de cartão seguro e o dispositivo não confiável poderia ser um dispositivo de entrada de usuário, tal como um smartphone ou tablet com uma tela sensível ao toque ou um teclado numérico dedicado. Em abordagens específicas, os dados confidenciais são recebidos no dispositivo não confiável, e os dados são mantidos no dispositivo não confiável, mas o dispositivo não confiável não tem permissão
Petição 870190009787, de 30/01/2019, pág. 12/57
4/35 para acessar nenhuma chave de criptografia mantida pelo dispositivo confiável ou qualquer elemento confiável afiliado do sistema.
[007] Ao invés de entregar uma chave a um dispositivo não confiável, um dispositivo seguro pode, por outro lado, conduzir localmente um procedimento em uma chave para gerar instruções que permitam que o dispositivo não confiável realize uma encriptação ou uma decriptação de acordo com a chave, sem que seja capaz de reconstruir a chave a partir dessas instruções. As instruções podem, então, ser entregues ao dispositivo não confiável e executadas no mesmo para permitir efetivamente que o dispositivo não confiável criptografe dados de acordo com o protocolo de criptografia da chave sem nunca ter realmente acesso à própria chave ou expor os valores de chave na memória do dispositivo não confiável. As instruções podem estar sob a forma de um código executável. As instruções geradas pelo dispositivo seguro podem usar determinadas técnicas para frustrar qualquer tentativa de extrair a chave através de uma análise das instruções.
[008] O processo de gerar as instruções descritas anteriormente, e usá-las para propósitos seja de encriptação ou de decriptação em um dispositivo não confiável, é referido como criptografia de caixa branca. O termo caixa branca se refere ao fato de que um projetista de sistema não tem garantias que um invasor não terá capacidade de olhar dentro do dispositivo não confiável enquanto estiver criptografando dados e, desse modo, extraia a chave usada para tal encriptação. Um módulo capaz de gerar as instruções de encriptação ou decriptação a partir de uma chave criptográfica pode ser referido como um gerador de código de caixa branca. Conforme o uso em questão, o termo módulo se refere a instruções armazenadas em uma memória legível por computador não transitória que são executáveis por um processador para propósitos de instanciar um objeto de software, e o próprio objeto de software.
Petição 870190009787, de 30/01/2019, pág. 13/57
5/35 [009] A Figura 2 inclui um diagrama de blocos básico 200 e um fluxograma 210 para ilustrar abordagens onde o código de caixa branca é gerado em um dispositivo confiável para propósitos de conduzir uma encriptação de dados em um dispositivo não confiável. No diagrama de blocos 200, um dispositivo confiável (também mencionado como dispositivo seguro ou primeiro dispositivo) 201 inclui uma memória segura 202 e um processador seguro 203, enquanto um dispositivo não confiável (também mencionado como um dispositivo inseguro ou um segundo dispositivo) 204 inclui um processador padrão 205 e uma interface de usuário 206. A memória segura 202 e o processador seguro 203 podem ser integrados no mesmo chip ou podem ser elementos separados, e também podem estar situados sob uma malha de violação dentro do dispositivo confiável 201. O processador padrão 205 pode ser qualquer microcontrolador ou microprocessador padrão. A interface de usuário 206 pode ser qualquer meio para receber dados a partir de um usuário incluindo uma câmera, uma tela sensível ao toque, um teclado numérico, um microfone, ou qualquer outro sistema para receber dados a partir de um usuário. A interface de usuário 206 pode proporcionar dados de entrada a uma memória de trabalho temporária no dispositivo 204 e encriptada usando o processador padrão 205 de acordo com o procedimento do fluxograma 210.
[010] As etapas do fluxograma 210 incluem gerar um código de encriptação de caixa branca em um primeiro dispositivo e usar o código para encriptar dados em outro dispositivo. Determinados benefícios se acumulam para gerar as instruções de encriptação de caixa branca localmente no dispositivo seguro, ao invés de fornecê-las através de um servidor. As instruções de encriptação de caixa branca e suas representações completas de dados podem exceder 1 mebibyte de tamanho. Visto que a criptografia de caixa branca resulta em tamanhos de chave consideravelmente grandes, gerar as instruções em um
Petição 870190009787, de 30/01/2019, pág. 14/57
6/35 servidor e, então, transmitir as chaves a uma memória local pode ser insustentável a partir de uma perspectiva de uso de rede e retardo de transação individual.
[011] O fluxograma 210 inclui uma etapa 211 de armazenar, e uma memória segura em um primeiro dispositivo, tal como o dispositivo seguro 201, uma chave. A chave pode ser uma chave criptográfica forte usada para encriptação simétrica ou assimétrica de acordo com um protocolo de chave. A memória segura pode ser resistente à violação de modo que a chave fosse apagada assim que o dispositivo perdesse energia ou detectasse uma violação. A memória segura, ou pelo menos uma porção da memória segura dedicada para armazenar a chave, pode ser uma memória volátil.
[012] O fluxograma 210 também inclui uma etapa 212 de gerar, usando um gerador de encriptação de caixa branca em um primeiro dispositivo, tal como o dispositivo seguro 201, um conjunto de instruções de encriptação de caixa branca com base na chave. A etapa 212 pode ser configurada para gerar instruções de encriptação de caixa branca diferentes para a mesma chave com base em uma entrada aleatória ao processo de geração. A entrada aleatória pode ser um parâmetro de configuração aleatória do dispositivo seguro 201. As instruções de encriptação de caixa branca podem ser proporcionadas sob a forma de um código usando um código fonte que pode ser interpretado, compilado e executado em um segundo dispositivo, tal como o dispositivo 204. O fluxograma 210 também inclui uma etapa 213 de transmitir as instruções de encriptação de caixa branca a partir do primeiro dispositivo ao segundo dispositivo. As instruções podem ser transmitidas através de um canal de comunicação seguro entre o dispositivo seguro e o dispositivo não confiável. O primeiro dispositivo pode ser o dispositivo seguro 201 e o segundo dispositivo pode ser o dispositivo 204.
Petição 870190009787, de 30/01/2019, pág. 15/57
7/35 [013] 0 fluxograma 210 também inclui uma etapa 214 na qual dados confidenciais são recebidos em uma interface de usuário do segundo dispositivo. O segundo dispositivo pode ser o dispositivo 204 e a interface de usuário pode ser a interface de usuário 206. Na situação onde a interface de usuário 206 é uma tela sensível ao toque, os dados podem ser armazenados como coordenadas de toque representativas do conjunto de dados, ou como próprios dados confidenciais, em uma memória de trabalho do dispositivo 204. Os dados confidenciais podem, então, de acordo com a etapa 215, ser encriptados usando as instruções de encriptação de caixa branca no segundo dispositivo usando um processador padrão no segundo dispositivo. O segundo dispositivo pode ser o dispositivo 204 e o processador padrão pode ser o processador 205. Como resultado, os dados confidenciais recebidos a partir da interface de usuário 206 não ficarão expostos por qualquer duração considerável de tempo no dispositivo 204 antes de serem encriptados, e o processador 205 nunca estará em posse da chave criptográfica visto que a mesma permanece seguramente armazenada no dispositivo seguro 201. Os dados confidenciais também podem ser recebidos em uma porção segura do dispositivo 204 e seguramente encriptados antes de serem transferidos para fora da porção segura.
[014] Usando algumas das abordagens representadas pela Figura 2, transmite-se um código executável a partir de um dispositivo seguro a um dispositivo não confiável para execução no dispositivo não confiável. No entanto, o envio por push de um código executável a um dispositivo geralmente é submetido a restrições, e algumas vezes é expressamente proibido. Em alguns casos, distribuir um código ao dispositivo não confiável pode exigir o envolvimento de uma terceira parte. Por exemplo, enviar por push um código a um smartphone Android ou iOS geralmente requer que o código seja filtrado através de uma loja de aplicativos. O processo de terceira parte está fora do
Petição 870190009787, de 30/01/2019, pág. 16/57
8/35 controle do administrador do sistema responsável por assumir a comunicação entre o dispositivo seguro e o dispositivo não confiável. Como resultado, não há garantias que a comunicação entre dois dispositivos não seja mantida por um período inaceitável enquanto os códigos executáveis, tais como as instruções de encriptação de caixa branca transmitidas na etapa 213, são enviados ao dispositivo não confiável. Em determinadas abordagens, uma chave diferente pode ser necessária sempre que o dispositivo não confiável encriptar ou decriptar um novo conjunto de dados confidenciais. Como resultado, o tempo gasto pela terceira parte para revisar o código executável destinado para o dispositivo não confiável seria necessário para cada comunicação entre os dispositivos e resultar em um retardo inaceitavelmente longo. Adicionalmente, em algumas abordagens, uma chave diferente é necessária com base em qual usuário está operando o dispositivo seguro. Isso exigiría que cada pessoa que baixe o aplicativo para seu smartphone seja dotada de uma versão específica do aplicativo que seria, de modo similar, insustentável e difícil de administrar. Adicionalmente, em algumas abordagens, o método geral usado na etapa 212 pode ser atualizado independentemente do aplicativo no telefone. As atualizações reduzem o custo associado à atualização das técnicas de caixa branca para proteção contra um ataque recentemente descoberto.
[015] Para endereçar restrições em proporcionar um código executável ao dispositivo não confiável, as instruções que implementam a funcionalidade da chave podem ser traduzidas em dados em um formato específico que seja passível de uso por um módulo especializado no dispositivo não confiável. Como resultado, não há necessidade de transferir um código executável a partir do dispositivo seguro ao dispositivo não confiável e não há necessidade de enviar por push um código através de um sistema de terceira parte. Diversas variações do processo para gerar o código executável, traduzir o código de volta em dados,
Petição 870190009787, de 30/01/2019, pág. 17/57
9/35 e utilizar os dados para uma encriptação ou decriptação são descritas no presente documento. Independentemente da abordagem usada, os dados serão uma descrição completa do código executável, mas, ao mesmo tempo, não são Turing-completos, e não contêm instruções que podem ser executadas pelo dispositivo não confiável. Resumidamente, os dados permitirão que um módulo especializado no dispositivo não confiável execute a mesma encriptação de caixa branca que o código executável, enquanto não esteja sendo usável para computação de propósitos gerais.
[016] A Figura 3 inclui um diagrama de blocos básico 300 e um fluxograma
310 para ilustrar abordagens onde uma representação de dados completa de código caixa branca é gerada em um dispositivo confiável para propósitos de conduzir uma encriptação de dados em um dispositivo não confiável. O fluxograma 310 é distinguível do fluxograma 210 devido à adição de uma etapa
311 na qual um processador seguro no primeiro dispositivo é usado para gerar uma representação de dados completa do conjunto de instruções de encriptação de caixa branca geradas na etapa 212. O processador seguro pode ser o processador seguro 203 no dispositivo seguro 201. O processador seguro pode instanciar um gerador de representação de dados para propósitos de executar a etapa 311.
[017] A representação de dados completa pode ser transferida ao dispositivo não confiável e usada para encriptar os dados confidenciais no mesmo. A representação de dados completa contém todos os dados necessários para que um módulo especializado no dispositivo não confiável execute a encriptação de caixa branca. A representação de dados completa pode incluir um conjunto de funções primitivas a partir de uma biblioteca de funções primitivas e uma coleção de estruturas de dados referenciadas por essas funções primitivas. A representação de dados completa pode incluir uma coleção de tabelas de
Petição 870190009787, de 30/01/2019, pág. 18/57
10/35 pesquisa e um grafo direcionado. A representação de dados completa não será passível à computação para propósitos gerais e pode existir exclusivamente em memória de quaisquer instruções executáveis a partir da perspectiva do dispositivo não confiável. O fluxograma 310 também inclui uma etapa 312 de transmitir a representação de dados completa a partir do primeiro dispositivo a um segundo dispositivo. A representação pode ser transmitida através de um canal seguro de comunicação entre o primeiro dispositivo e o segundo dispositivo. O fluxograma 310 também inclui uma etapa 315 de encriptar os dados confidenciais usando um processador padrão no segundo dispositivo. O processador padrão pode ser o processador 205 no segundo dispositivo 204. A etapa 315 pode envolver um módulo especializado no segundo dispositivo analisando sintaticamente a representação de dados completa para determinar as etapas necessárias para encriptar os dados confidenciais de acordo com o protocolo de chave. O módulo especializado pode ser uma máquina virtual instanciada usando o processador padrão. A representação de dados completa pode, desse modo, ser analisada sintaticamente pelo módulo especializado, enquanto, ao mesmo tempo, não sendo Turing-completa em relação ao dispositivo não confiável e ao processador padrão.
[018] Um método descrito inclui armazenar uma chave em uma memória segura em um primeiro dispositivo, receber dados confidenciais através de uma interface de usuário em um segundo dispositivo, gerar um conjunto de instruções de encriptação de caixa branca com base na chave usando um gerador de encriptação de caixa branca no primeiro dispositivo, gerar uma representação de dados completa do conjunto de instruções de encriptação de caixa branca usando um processador seguro no primeiro dispositivo, transmitir a representação de dados completa a partir do primeiro dispositivo ao segundo dispositivo e encriptar os dados confidenciais usando a representação de dados
Petição 870190009787, de 30/01/2019, pág. 19/57
11/35 completa no segundo dispositivo. A representação de dados completa não é executável.
[019] Um sistema descrito inclui um dispositivo seguro com um processador seguro e uma memória segura, um dispositivo inseguro com um processador padrão, um canal seguro de comunicação entre o dispositivo seguro e o dispositivo inseguro, uma chave armazenada na memória segura, um gerador de instrução de encriptação de caixa branca: (i) instanciado pelo processador seguro; e (ii) programado para gerar um conjunto de instruções de encriptação de caixa branca usando a chave, um gerador de representação de dados: (i) instanciado pelo processador seguro; e (ii) programado para gerar uma representação de dados completa do conjunto de instruções de encriptação de caixa branca usando o conjunto de instruções de encriptação de caixa branca, e uma máquina virtual: (i) instanciada pelo processador padrão; e (ii) programada para encriptar dados confidenciais usando a representação de dados completa.
[020] Outro sistema descrito inclui um dispositivo não confiável com uma interface de usuário para receber dados confidenciais, um processador no dispositivo não confiável, um sistema operacional instanciado no dispositivo não confiável pelo processador, um dispositivo de leitor de cartão seguro, um canal de comunicação sem fio entre o dispositivo não confiável e o dispositivo de leitor de cartão seguro, e uma chave armazenada no dispositivo de leitor de cartão seguro. Uma memória no dispositivo de leitor de cartão seguro armazena instruções para: gerar um conjunto de instruções de encriptação de caixa branca usando a chave; gerar uma representação de dados completa das instruções de encriptação de caixa branca. O sistema também inclui um aplicativo instanciado no dispositivo não confiável e programado para encriptar os dados confidenciais usando a representação de dados completa. A representação de dados completa não inclui um código executável para o sistema operacional.
Petição 870190009787, de 30/01/2019, pág. 20/57
12/35
BREVE DESCRIÇÃO DOS DESENHOS [021] Figura 1 ilustra dois exemplos de como um leitor de cartão seguro pode ser pareado com um smartphone para processar pagamentos.
[022] Figura 2 ilustra um diagrama de blocos e um fluxograma para ilustrar abordagens onde o código de caixa branca é gerado em um dispositivo confiável para propósitos de conduzir uma encriptação de dados em um dispositivo não confiável de acordo com abordagens descritas no presente documento.
[023] Figura 3 ilustra um diagrama de blocos e um fluxograma para ilustrar abordagens onde uma representação de dados completa de um conjunto de instruções de código de caixa branca é gerada em um dispositivo confiável para propósitos de conduzir uma encriptação de dados em um dispositivo não confiável de acordo com abordagens descritas no presente documento.
[024] Figura 4 ilustra um diagrama de fluxo de dados de um leitor de cartão seguro que se comunica com um smartphone para propósitos de obter e transmitir seguramente tanto um número de conta pessoal (PAN) como um número de identificação pessoal (PIN) associados a um cartão de pagamento a um servidor de processador de pagamento de acordo com abordagens descritas no presente documento.
[025] Figura 5 ilustra um diagrama de fluxo de dados de uma versão simplificada de rodadas de chave envolvidos em uma cifra de bloco simétrica usada para descrever as abordagens descritas no presente documento.
[026] Figura 6 ilustra dois diagramas de fluxo de dados para a decomposição da cifra de bloco simétrica na Figura 5 em um conjunto de tabelas de pesquisa de acordo com abordagens descritas no presente documento.
[027] Figura 7 ilustra dois diagramas de fluxo de dados para descrever a tradução das rodadas de chave envolvidas em uma cifra de bloco simétrica em um conjunto de tabelas de pesquisa em grafo direcionado de acordo com as
Petição 870190009787, de 30/01/2019, pág. 21/57
13/35 abordagens descritas no presente documento.
[028] Figura 8 ilustra um diagrama conceituai de uma representação de dados completa, e um conjunto correspondente de funções primitivas na mesma, de um conjunto de instruções de encriptação de caixa branca de acordo com as abordagens descritas no presente documento.
DESCRIÇÃO DETALHADA [029] No presente documento, revelam-se sistemas e métodos que envolvem um dispositivo confiável seguro (também mencionado como dispositivo seguro ou primeiro dispositivo) e um dispositivo não confiável (também mencionado como um dispositivo inseguro ou segundo dispositivo) onde dados confidenciais ou chaves são compartilhados entre esses dispositivos. A instância específica do dispositivo confiável seguro sendo um leitor de cartão seguro e o dispositivo não confiável sendo um dispositivo de interface de usuário, tal como um smartphone, é usada por motivos de explicação. No entanto, os conceitos descritos no presente documento são mais abrangentemente aplicáveis. Um leitor de cartão seguro pode ser fabricado por um fabricante de dispositivos de pagamento para operar como um dispositivo de pagamentos confiável especializado. O leitor de cartão seguro pode incluir uma chave secreta para encriptar informações de pagamento para entrega a um processador de pagamentos com o qual o fabricante de dispositivo de pagamento tem um acordo para processamento de pagamento. O leitor de cartão seguro também pode incluir uma chave usada para gerar instruções de encriptação de caixa branca para o dispositivo não confiável. Um dispositivo não confiável pode ser um smartphone arbitrário, ou outro dispositivo de interface de usuário, com um aplicativo especializado instalado para conduzir alguns dos métodos descritos no presente documento. O aplicativo especializado pode ser projetado pelo fabricante de dispositivo de pagamento e distribuído a smartphones por um
Petição 870190009787, de 30/01/2019, pág. 22/57
14/35 sistema de distribuição de terceira partem tais como lojas de aplicativos Android ou iOS.
[030] Embora esta descrição use o ambiente específico de um leitor de cartão seguro e smartphone como um veículo por propósitos explicativos, as abordagens descritas no presente documento são mais amplamente aplicáveis à comunicação ou encriptação de dados confidenciais em um sistema que inclui dispositivos não confiáveis em geral, e eles não são limitados à tecnologia de pagamentos.
[031] A Figura 4 é um diagrama de fluxo de dados que ilustra um leitor de cartão seguro 400 que se comunica com um smartphone 410 para propósitos de obter e transmitir seguramente tanto dados seguros (por exemplo: um número de conta pessoal (PAN)) como dados confidenciais (por exemplo: um número de identificação pessoal (PIN)) associados a um cartão de pagamento 420 a um servidor de processador de pagamento 430. A transmissão do PIN e PAN ao servidor de processador de pagamento 430 pode ser conduzida usando uma chave secreta 401 armazenada em uma memória segura no leitor de cartão seguro 400. A chave secreta pode ser referida como uma chave de back-end de uma rede de processamento de pagamento. A chave secreta pode ser gerada por um conjunto de chave única discreta por transação (DUKPT) conforme proporcionado pelo processador de pagamentos que opera o servidor 430.0 PIN pode ser seguramente transferido a partir de um smartphone 410 ao leitor de cartão seguro 400, para transmissão adicional ao servidor de processador de pagamento 430 usando outra chave, tal como uma chave de encriptação local 402.
[032] A chave de encriptação local 402 pode ser uma chave de encriptação simétrica ou assimétrica. A chave de encriptação local 402 pode ser uma chave pública associada a um certificado de chave pública que é armazenada em uma
Petição 870190009787, de 30/01/2019, pág. 23/57
15/35 memória segura em um leitor de cartão seguro 400 que é inserido no leitor de cartão seguro em uma sala para injeção de chave em uma instalação de fabricação ou inserido no leitor de cartão seguro usando um procedimento de injeção de chave remota (RKI). A chave de encriptação local 402 pode ser usada como parte de um protocolo de encriptação de caixa branca para facilitar uma comunicação segura com o smartphone 410 sem entregar a própria chave de encriptação local 402 ao smartphone 410. A encriptação de caixa branca conduzida no smartphone 410 pode usar qualquer número de protocolos ou técnicas de encriptação. Em particular, o leitor de cartão seguro 400 pode gerar, e o smartphone 410 pode usar, instruções de caixa branca que implementam a cifra de bloco de AES para encriptar o PIN em um formato definido sob o formato ISO 9564-1 (Bloco de PIN). O formato ISO 9564-1 pode ser usado para encriptar tanto o PIN como o PAN para gerar o bloco de PIN. No entanto, em determinadas abordagens, é benéfico não transferir o PAN a partir do leitor de cartão seguro 400 exceto que seja encriptado com a chave secreta 401. Como tal, um número aleatório gerado no leitor de cartão seguro 400 pode ser usado no lugar do PAN ao gerar as instruções de caixa branca. O número aleatório seria armazenado pelo leitor de cartão seguro 400 em associação à chave de encriptação local 402, ou como parte da mesma, de modo que possa ser usado para decriptar o PIN. O número aleatório pode ser alterado sempre que um conjunto de instruções de caixa branca for gerado pelo leitor de cartão seguro 400.
[033] O leitor de cartão seguro 400 é fabricado por um fabricante de dispositivo de pagamento e inclui determinados aspectos de segurança, tal como um armazenamento seguro e um ambiente de execução com um processador seguro e memória, sensores de violação e malhas de violação para manter chaves de encriptação e dados de pagamento confidenciais seguros e isolados contra invasores. O leitor de cartão seguro 400 é um dispositivo confiável a partir
Petição 870190009787, de 30/01/2019, pág. 24/57
16/35 da perspectiva do fabricante do leitor de cartão seguro 400 e do operador do servidor de processador de pagamento 430 visto que um leitor de cartão seguro 400 satisfará determinados padrões necessários por tal operador. Por exemplo, o leitor de cartão seguro 400 pode ser um leitor compatível da indústria de cartão de pagamento (PCI).
[034] O leitor de cartão seguro 400 pode incluir meios para receber dados de pagamento a partir do cartão de pagamento 420 tal como um leitor de tarja magnética, leitor de chip ou uma antena para cartões sem contato. O smartphone 410 também pode incluir alguns dos aspectos de segurança supramencionados, mas não é necessário que inclua esses aspectos. O smartphone 410 pode incluir um processador geral e uma interface de usuário, tal como uma tela sensível ao toque 411, para receber informações de pagamento adicionais a partir de um usuário. Em uma abordagem específica, o leitor de cartão seguro 400 obterá um PAN a partir do cartão de pagamento 420 e o smartphone 410 obterá um PIN a partir de um detentor de cartão de pagamento 420 usando uma tela sensível ao toque 411 e um controlador de tela sensível ao toque 412. O smartphone pode incluir um modo seguro para evitar que dados de toque sejam usados para determinar o PIN. Usando a abordagem a seguir, o PIN pode, então, ser encriptado pela chave de encriptação local 402, seguramente transferido ao leitor de cartão seguro 400 a partir do smartphone 410, e, então, encriptado usando a chave secreta 401 para transmissão ao servidor de processador de pagamento 430.
[035] A comunicação entre o leitor de cartão seguro 400 e o smartphone 410 pode ser conduzida usando uma conexão com ou sem fio. Em algumas abordagens, o smartphone 410 fornecerá energia ao leitor de cartão seguro 400 usando uma conexão com fio, e se comunicará com o leitor de cartão seguro 400 usando uma conexão sem fio. Em determinadas abordagens, a conexão com fio
Petição 870190009787, de 30/01/2019, pág. 25/57
17/35 será proporcionada através de um micro-USB ou interface similar. Em determinadas abordagens, a conexão com fio será proporcionada através de um conector de 3,5 ou 2,5 mm que seja, de outro modo, usado para saída de som estéreo ou entrada de microfone. A conexão sem fio pode ser conduzida usando qualquer protocolo sem fio, tal como Bluetooth, Bluetooth de Baixa Energia (BLE), Z-Wave, ZigBee, IrDA, ou protocolos similares. Os dados enviados através da conexão entre o leitor de cartão seguro 400 e o smartphone 410 podem ser encriptados e podem ser protegidos com assinaturas criptológicas.
[036] A Figura 4 é ilustrativa de uma classe de sistemas onde um dispositivo seguro inclui chaves de encriptação que não podem ser usadas ou armazenadas fora de um ambiente confiável. O ambiente confiável pode ser aquele no qual a confiança é medida a partir da perspectiva do operador de um servidor de processamento de pagamentos 430 e é ajustado por um padrão industrial, tais como os padrões PCI. De modo correspondente, a chave secreta 401 e a chave de encriptação local 402 não podem ser armazenadas, mesmo temporariamente, fora do ambiente confiável. Portanto, a comunicação segura entre o leitor de cartão seguro 400 e o smartphone 410 é conduzida sem transferir a chave de encriptação local 402 ao smartphone 410. Adicionalmente, a comunicação por uma rede maior que aquela ajustada pelos dois dispositivos discretos mostrados na Figura 4 requer o uso da chave secreta 401, que é uma chave de encriptação mais forte e mais ávida por recursos do que a chave de encriptação local 402, e é destinada a ser segura o suficiente para transferir dados de pagamento por uma rede grande, tal como a Internet. Conforme mostrado no diagrama, o leitor de cartão seguro 400 pode alavancar as capacidades de comunicação de rede de área grande do smartphone 410 para se comunicar com o servidor de processamento de pagamentos 430, ou pode se comunicar diretamente com o servidor. A rota tomada pelas informações de
Petição 870190009787, de 30/01/2019, pág. 26/57
18/35 pagamento encriptadas pode depender das capacidades do dispositivo 400, da bateria disponível no dispositivo 400, ou da resistência relativa da conexão de rede entre os dois dispositivos. Por exemplo, o dispositivo 400 pode ser projetado para ter baixo custo de modo que tenha somente capacidades de comunicação local como um modem para comunicações Bluetooth, enquanto o dispositivo 410 era um smartphone totalmente equipado com a capacidade de se comunicar através da Internet.
[037] Embora a chave de encriptação local 402 nunca seja transferida a partir do leitor de cartão seguro 400 ao smartphone 410, comunicações a partir do smartphone 410 ao leitor de cartão seguro 400 podem ser conduzidas por um canal seguro conforme assegurado pelo protocolo de encriptação da chave de encriptação local 402 usando encriptação de caixa branca. Conforme ilustrado, o leitor de cartão seguro 400 pode usar uma chave de encriptação local 402 como a entrada ao gerador de encriptação de caixa branca 403 para gerar um conjunto de instruções executáveis que podem ser usadas para implementar o protocolo de encriptação da chave de encriptação local 402 sem ser capaz de revelar a própria chave. O gerador de encriptação de caixa branca 403 pode ser um módulo instanciado no leitor de cartão seguro 400 usando um processador seguro e uma memória.
[038] O gerador de encriptação de caixa branca 403 pode ofuscar as instruções geradas para evitar que um invasor reconstrua a chave usando as instruções. Por exemplo, as instruções podem incluir um conjunto de tabelas de pesquisa e os valores nas tabelas podem ser usados junto a técnicas de reconstrução algébricas, que usam os valores de chave como incógnitas, para solucionar os valores de chave com base nos valores de tabela. No entanto, as técnicas de ofuscação podem ser usadas para frustrar uma reconstrução algébrica. A ofuscação pode utilizar dados de configuração aleatórios 404
Petição 870190009787, de 30/01/2019, pág. 27/57
19/35 gerados ou previamente armazenados na área segura do leitor de cartão seguro 410 para garantir que a ofuscação não possa ser revertida por engenharia mesmo se a abordagem exata for conhecida. Os dados de configuração 404 podem ser armazenados de modo que não possam ser descobertos a partir de fora do dispositivo sem acionar um evento de violação e, desse modo, resultar nas chaves no dispositivo sendo apagadas, e adicionalmente registradas como comprometidas.
[039] A encriptação de caixa branca pode ser conduzida no smartphone 410 usando o código executável gerado pelo gerador de encriptação de caixa branca 403 diretamente. O código executável pode ser transmitido a partir do leitor de cartão seguro 400 ao smartphone 410 e executado por um processador no smartphone 410 usando os dados confidenciais. O processo pode ser conduzido e uma porção segura do smartphone 410 e pode ser conduzido enquanto o dispositivo se encontra em um modo seguro. No entanto, podem haver restrições ou proibições em enviar por push o código executável ao smartphone 410. Por exemplo, o código que precisa ser enviado por push ao smartphone 410 pode precisar ser transferido através de um canal de terceira parte pelo qual o fabricante do leitor de cartão seguro 400 não tem controle. Nessas abordagens, o código executável pode ser transferido em uma representação de dados usando um gerador de representação de dados, tal como o gerador de representação de dados 405, antes de ser transferido ao smartphone 410.
[040] O gerador de representação de dados 405 pode ser um módulo instanciado usando um processador seguro e uma memória segura no leitor de cartão seguro 400. O gerador de representação de dados 405 pode adotar nas instruções de encriptação de caixa branca como uma entrada e produzir uma representação de dados completa das instruções. A representação de dados
Petição 870190009787, de 30/01/2019, pág. 28/57
20/35 completa não será Turing-completa e não será executável pelo sistema operacional ou processador geral no smartphone 410. No entanto, a representação de dados completa pode ser analisada sintaticamente por um módulo no smartphone 410 e usado por esse módulo para encriptar o PIN recebido a partir do controlador de toque 412. A representação de dados completa pode incluir um conjunto de funções primitivas e estruturas de dados. A representação de dados completa pode incluir um conjunto de tabelas de pesquisa, e um grafo direcionado, conforme será descrito abaixo. O módulo no smartphone 410 que analisa sintaticamente a representação de dados completa pode ser uma máquina virtual como a máquina virtual 413. A máquina virtual 413 pode ser um computador de software instanciado por um processador e um sistema operacional no smartphone 410. A máquina virtual 413 pode analisar a representação de dados completa para encontrar uma ordem na qual valores específicos devem ser calculados, determinadas operações nesses valores que devem ser conduzidas e tabelas de pesquisa onde pesquisar valores com base na entrada à tabela. O uso de uma máquina virtual proporciona determinados benefícios onde o esquema de encriptação de caixa branca, conforme orquestrado pelo dispositivo seguro, se torna independente de plataforma, à medida que o sistema operacional subjacente ou kernel do dispositivo não confiável não precisam mais ser compatíveis ao protocolo de encriptação.
[041] O uso de instruções de encriptação de caixa branca geradas pelo gerador de encriptação de caixa branca 403 representa uma abordagem superior a uma comunicação de par de chaves pública e privada assimétrica. Usar essa abordagem permite que o sistema produza uma chave diferente para encriptar cada entrada de dados confidenciais enquanto, ao mesmo tempo, não proporciona diversas amostras de chave pública a um invasor potencial. Adicionalmente, determinados padrões da indústria como aqueles de acordo
Petição 870190009787, de 30/01/2019, pág. 29/57
21/35 com ISO 9564 permitirão somente uma criptografia para encriptar PINs, logo, uma criptografia assimétrica não é uma opção disponível. Além disso, a geração de chave privada pode ser intensiva a recursos. Por exemplo, chaves privadas de RSA exigem uma computação substancial para gerar. Um processador seguro embarcado com um ASIC de aceleração de RSA pode tomar de 1 a 3 minutos para gerar uma chave privada de RSA de 2048 bits. Usando algumas das abordagens do presente documento, uma chave de caixa branca nova pode ser gerada para cada transação que reduz o ganho dos invasores a partir de engenharia reversa do código para uma chave de caixa branca particular.
[042] As abordagens representadas pela Figura 4 permite que o PIN seja encriptado para transmissão ao leitor de cartão seguro 400 através de uma conexão segura em uma rede de área pequena, e, então, re-encriptado para transmissão ao servidor de processador de pagamentos 430 através de uma rede de área ampliada. Uma vez que o PIN for encriptado no smartphone 410 usando um protocolo de acordo com chave de encriptação local 402, o mesmo pode ser transmitido de volta ao leitor de cartão seguro 400 por uma conexão segura. O protocolo pode ser um dos métodos especificados em ISO 9564 parte 1. A conexão segura pode ser a mesma conexão usada para transmitir as instruções de encriptação de caixa branca, ou representação de dados completa das mesmas, a partir do leitor de cartão seguro 400 ao smartphone 410. O PIN pode, então, ser decriptado usando um módulo de decriptação 406 usando a chave de encriptação local 402. Conforme ilustrado, a chave pode ser uma chave simétrica com as instruções de encriptação de caixa branca usadas para executar a encriptação de dados pela chave simétrica, enquanto não é capaz de executar a decriptação, enquanto o módulo de decriptação 406 utiliza a chave simétrica para decriptar o PIN.
[043] Uma vez decriptado, o PIN do smartphone 410 pode ser re
Petição 870190009787, de 30/01/2019, pág. 30/57
22/35 encriptado por um módulo de re-encriptação 407 usando a chave secreta 401. De modo similar, o PAN pode ser encriptado pela chave secreta 401 usando um módulo de encriptação, que não é mostrado no diagrama, embora possa ser o mesmo módulo que aquele usado para re-encriptar o PIN. De modo subsequente, tanto o PAN como o PIN conforme encriptados pela chave secreta 401 podem ser transmitidos ao servidor de processador de pagamentos 430. Conforme ilustrado, os dados podem ser enviados diretamente ao servidor, ou podem ser transmitidos primeiramente ao smartphone 410, e, então, enviados ao servidor 430.
[044] Embora o exemplo da Figura 4 seja limitado a um smartphone e a um leitor de cartão seguro, deve-se avaliar que vários outros dispositivos podem ser usados em seu lugar enquanto ainda se aplicam os conceitos subjacentes para compartilhar dados confidenciais entre os dois dispositivos sem compartilhar uma chave de encriptação local. Por exemplo, o leitor de cartão seguro pode ser qualquer dispositivo confiável que seja usado para obter informações de pagamento a partir de um usuário, tal como um scanner biométrico, scanner de código QR, ou qualquer outro dispositivo capaz de receber informações a partir de um usuário usando um sensor. De modo similar, o smartphone 410 pode ser qualquer dispositivo não confiável capaz de receber dados confidenciais a partir de um usuário. O dispositivo não confiável pode ser qualquer dispositivo de entrada de usuário, tal como um tablet, teclado numérico dedicado, terminal de exibição sensível ao toque, ou qualquer outro dispositivo capaz de receber informações a partir de um usuário usando um sensor.
[045] As Figuras 5 a 8 proporcionam exemplos de geradores de encriptação de caixa branca e geradores de representação de dados que podem ser usados de acordo com as abordagens descritas no presente documento. A
Petição 870190009787, de 30/01/2019, pág. 31/57
23/35 abordagem ilustrada corresponde a uma versão simplificada de AES conforme descrito em FIPS 197. No entanto, conforme mencionado anteriormente, o conceito descrito pode ser usado com qualquer tipo de cifra simétrica como AES, RSA, SQUARE, CRYPTON, ARIA, Camellia, Padrão de Encriptação de Dados (DES), Padrão/Algoritmo de Encriptação de Dados Triplos (TDES/TDEA), Blowfish, Serpent, Twofish, Threefish, Rotina de Encriptação Rápida e Segura (SAFER), Algoritmo de Encriptação de Dados Internacional (IDEA), Algoritmo de Encriptação Diminuto (TEA), TEA estendido (XTEA) de 128-bit, 192-bit e 256-bit, e outros.
[046] A encriptação usando AES envolve a geração de uma programação de chave a partir de uma chave de base onde a programação de chave é uma sequência de chaves de rodada Ko, Ki,... Kn que são usadas para cada rodada de encriptação. O processo envolve três operações: RotWord, Subword e Rcon. RotWord envolve decompor a chave em palavras de 32 bits e deslocar cada palavra de 8 bits para a esquerda com os bits altos envoltos. Subword envolve substituir cada byte por um novo byte com base em uma caixa de substituição. Rcon envolve computar w'1 para cada palavra (w) e rodada (i) pelo campo de Galois F2b. Após a programação de chave ter sido gerada, chaves de rodada são aplicadas em uma série de rodadas de encriptação aos dados confidenciais. Em AES de 128-bit, existem 10 rodadas e 10 chaves de rodada de 16-byte associadas na programação de chave.
[047] A Figura 5 é um diagrama de fluxo de dados 500 para uma versão simplificada das rodadas de chave envolvidas com uma cifra de bloco simétrica de AES. O fluxograma 500 ilustra como dados confidenciais BLOCO PLAINTEXT são encriptados em uma cadeia de dados encriptados BLOCO CIPHERTEXT. BLOCO PLAINTEXT pode ser uma porção de uma mensagem que foi decomposta em pedaços com um tamanho que seja compatível à cifra. O processo envolve
Petição 870190009787, de 30/01/2019, pág. 32/57
24/35 decompor os dados confidenciais em um conjunto de partes como Mbi-Mb6. Os dados são, então, submetidos a uma série de rodadas de chave. O fluxograma ilustra uma primeira rodada de chave, e uma porção da segunda rodada de chave e rodada de chave finais. O fluxograma supõe que as chaves de rodada Ko, Ki,... Kn já tenham sido geradas. Cada rodada de AES tem quatro etapas: SubBytes, ShiftRows, MixColumns e AddRoundKey. A etapa de SubByes envolve substituir cada byte por um novo byte com base em uma caixa de substituição. A etapa é igual a SubWord na programação de geração de chave. A etapa é ilustrada usando a referência Sub na Figura 5. A etapa ShiftRows envolve selecionar bytes sendo deslocados entre as fileiras na matriz de estado. A etapa é ilustrada usando setas após a etapa de substituição. A etapa de MixColumns envolve cada coluna na matriz de estado sendo combinada usando uma transformada linear invertível. A transformada linear é uma multiplicação no campo de Galois. A etapa pode ser implementada através de tabelas de pesquisa ao invés de aritmética de Galois direta. A etapa é ilustrada pela referência Misturar Colunas na Figura 5. A etapa de AddRoundKey envolve conduzir uma operação ouexclusivo na matriz de estado usando a chave de rodada para tal rodada. A etapa é ilustrada pelos blocos ou-exclusivo e indicadores de chave de rodada na Figura 5. No exemplo ilustrado simplificado da Figura 5, a chave de rodada precisaria de seis elementos independentes. A saída dessas quatro etapas seria, então, proporcionada à próxima rodada de chave. A saída da rodada de chave final seria, então, um conjunto de partes Cbi-Cb6 que compreende os dados encriptados BLOCO CIPHERTEXT.
[048] A operação combinada de um gerador de instrução de caixa branca e gerador de representação de dados completa que podem ser utilizados em combinação com as abordagens descritas no presente documento pode ser descrita com referência à Figura 6.0 diagrama de fluxo de dados da Figura 5 pode
Petição 870190009787, de 30/01/2019, pág. 33/57
25/35 ser decomposto em um conjunto de tabelas de pesquisa complexas em que um dado conjunto de valores para Cbi-Cb6 é produzido para um dado conjunto de valores para Mbi-Mb6. 0 diagrama de fluxo de dados 600 na Figura 6 é uma ilustração de uma porção da rodada de chave 1 do diagrama de fluxo de dados 500 em que somente partes de dados Mbi, Mb4 e Mbs, e a saída de MISTURAR COLUNAS 1 são relevantes. Essas saídas consistem em uma porção da entrada à rodada de chave 2 e podem ser referidas como Rn, R12 e R13. De modo similar, o diagrama de fluxo de dados 610 na Figura 6 é uma ilustração de uma segunda porção da rodada de chave 1 do diagrama de fluxo de dados 500 em que somente partes de dados Mbz, Mb3 e Mb6, e a saída de MISTURAR COLUNAS 2 são relevantes. Essas saídas são uma porção da entrada à rodada de chave 2 e podem ser referidas como R14, Ris e Rie.
[049] As relações das entradas e saídas dos diagramas de fluxo de dados 600 e 610 são independentes e podem ser representadas por tabelas de pesquisa independentes ilustradas pela estrutura de dados 605 e 615, respectiva mente. As estruturas de dados 605 e 615 são tabelas de pesquisa tridimensionais em que as partes de dados de BLOCO PLAINTEXT são entradas e as saídas são as entradas à rodada de chave 2. Para qualquer entrada potencial ao diagrama de fluxo de dados 600, a estrutura de dados 605 incluirá uma saída correspondente. O mesmo é verdadeiro para o diagrama de fluxo de dados 610 e a estrutura de dados 615. De modo notável, nenhuma dessas estruturas de dados exige a inclusão da chave K°. Como tal, um gerador de instrução de caixa branca e um gerador de representação de dados completa podem ser usados para gerar um conjunto de estruturas de dados que podem ser usados para implementar um protocolo de encriptação usando uma dada chave sem expor a chave a invasores potenciais que têm acesso à memória de um dispositivo conduzindo a encriptação.
Petição 870190009787, de 30/01/2019, pág. 34/57
26/35 [050] A Figura 7 proporciona dois diagramas de fluxo de dados que podem ser executados por um processador a fim de executar uma encriptação. O diagrama de fluxo de dados 700 recebe os dados confidenciais a serem encriptados BLOCO PLAINTEXT, recebe uma chave de encriptação CHAVE, executa um conjunto de funções 701, e produz uma saída encriptada BLOCO CIPHERTEXT. Referindo-se nova mente à Figura 4, a ação do gerador de encriptação de caixa branca 403 pode ser ilustrada pela seta 720. O diagrama de fluxo de dados 710 conduz a mesma encriptação que o diagrama de fluxo de dados 700, mas não requer uma CHAVE como uma entrada e, ao invés disso, utiliza tabelas de pesquisa 711 configuradas de modo que as relações de entradasaída das tabelas de pesquisa absorvam a chave e a mantenha oculta de um invasor que seja capaz de monitorar os valores intermitentes gerados por um processador durante a execução do diagrama de fluxo de dados 710. Portanto, ao invés de codificar a chave diretamente, o código que implementa a encriptação de caixa branca pode ser um conjunto de funções que depende do valor da chave. Adicionalmente, alguns conjuntos de funções são compostos em uma função única.
[051] Um dispositivo também pode ter diversos módulos que implementam a etapa 720 de diferentes formas. Um parâmetro de entrada aleatória ao gerador de instrução de caixa branca pode ser usado para decidir qual implementação do método 720 deve ser usada. O gerador de instrução de caixa branca também pode executar a etapa 720 usando diferentes métodos de caixa branca para diferentes porções do processo de encriptação, e o parâmetro de entrada aleatória pode ser usado para selecionar qual método usar para qual parte do processo de encriptação. O parâmetro de entrada aleatória pode ser, ou pode ser derivado a partir de, um valor de configuração aleatório do dispositivo. Adicionalmente, diferentes técnicas de caixa branca podem ser
Petição 870190009787, de 30/01/2019, pág. 35/57
27/35 aplicadas a qualquer conjunto de transformadas no processo de encriptação. Diferentes técnicas de caixa branca podem se aplicar a diferentes transformadas no processo de encriptação. Em certas implementações, algumas, mas não todas, transformadas que são saídas de uma técnica de caixa branca podem ser adicionalmente obscurecidas aplicando-se técnicas de caixa branca adicionais.
[052] Um gerador de representação de dados, tal como o gerador de representação de dados 405, pode estender o processo ilustrado na Figura 7, traduzindo-se o diagrama de fluxo de dados 710 em uma representação de dados completa que não inclui qualquer código executável. O gerador de representação de dados completa pode gerar um conjunto de funções primitivas a partir de uma biblioteca de funções primitivas e um conjunto de tabelas de pesquisa. O gerador de representação de dados completa pode gerar tabelas de pesquisa 711 e também pode gerar um grafo direcionado para permitir que o módulo especializado determine como as tabelas de pesquisa devem ser utilizadas de modo que o conjunto de rodadas de chave completo seja executado. As estruturas de dados podem ser marcadas com dados de identificação correspondentes a entradas no grafo direcionado de modo que o módulo pode determinar que a saída de uma estrutura de dados deva ser usada como a entrada à próxima. Um módulo especializado em outro dispositivo pode, então, analisar sintaticamente a representação de dados completa para executar o diagrama de fluxo de dados 710 sem qualquer código executável sendo transferido a esse dispositivo.
[053] Retornando-se ao exemplo da Figura 4, a máquina virtual 413 pode analisar uma representação de dados gerados pelo gerador de representação de dados 405 para executar um protocolo de encriptação de caixa branca produzido pelo gerador de encriptação de caixa branca 403. Nesse exemplo, o gerador de encriptação de caixa branca 403 executará a seta 720 na Figura 7, enquanto o
Petição 870190009787, de 30/01/2019, pág. 36/57
28/35 módulo especializado 413 executará o diagrama de fluxo de dados após analisar a representação de dados completa. Todas essas etapas também podem ser realizadas sem o leitor de cartão seguro 400 enviar qualquer código executável ao smartphone 410. Usando essa abordagem, mesmo se um invasor for capaz de monitorar os valores gerados durante o processo de encriptação conduzido pela máquina virtual 413, os valores de chave não aparecerão na memória no smartphone 410.
[054] Algumas abordagens onde as instruções de encriptação de caixa branca são decompostas em uma representação de dados completa proporcionam determinados benefícios onde a implementação de caixa branca conduzida pelo sistema pode ser atualizada frequentemente sem exigir que um novo programa seja instalado no segundo dispositivo. Para assegurar uma segurança, o protocolo de caixa branca utilizado para manter comunicações pode precisar ser atualizado em uma base frequente tal como mensalmente. No entanto, se as instruções de encriptação de caixa branca forem decompostas em funções primitivas componentes, múltiplos protocolos de caixa branca podem ser executados pelo mesmo módulo especializado no segundo dispositivo gerando-se diferentes funções primitivas e o software no segundo dispositivo não precisará ser atualizado. Isso é benéfico dado que os problemas em enviar por push o código a segundo dispositivo mencionado anteriormente, e problemas gerais referentes à atualização do software em sistemas de multipartes que devem manter a compatibilidade. Em particular, o método de ofuscar as instruções ou representação de dados pode ser atualizado sem exigir uma atualização do software no dispositivo não confiável. Os métodos de ofuscação de caixa branca atuais podem ser superados por novas técnicas matemáticas que ainda não são conhecidas. O uso de uma representação de dados completa que é configurada para representar qualquer operação de
Petição 870190009787, de 30/01/2019, pág. 37/57
29/35 função primitiva que pode ser conduzida por um esquema de ofuscação de encriptação de caixa branca permite que novos métodos de ofuscação sejam implantados sem atualizar o software no dispositivo não confiável.
[055] As instruções e as estruturas de dados descritas anteriormente podem ser submetidas ao processamento adicional para garantir que a chave subjacente não possa ser recolhida através de uma análise das instruções ou dados em isolamento. Gerar estruturas de dados como 605 e 615 a serem usadas ao invés de um conjunto de funções que são diretamente dependentes de valores de chave para um processo de encriptação proporciona um nível de segurança às chaves subjacentes. No entanto, os valores de chave ainda são indiretamente representados pelas estruturas de dados em que eles controlam relação entre as entradas e saídas, e, portanto, podem ser potencialmente extraídos a partir de uma análise das estruturas de dados usando relações e análises algébricas. Para impedir esses tipos de ataques, as instruções de encriptação de caixa branca podem ser ofuscadas para evitar engenharia reversa. Em abordagens onde as instruções de caixa branca ou a representação de dados completa utilizam tabelas de pesquisa, a ofuscação pode ser conduzida através da introdução de codificações de mistura nas tabelas de pesquisa. Por exemplo, as codificações de mistura bijetivas podem ser aplicadas. As codificações podem ser escolhidas de modo que se desloquem quando compostas. Portanto, utilizar as tabelas de pesquisa na ordem apropriada induzirá que as codificações saiam do cálculo enquanto evita que a análise de tabelas de pesquisa específicas para render informações que podem levar a uma constatação das chaves de encriptação subjacentes.
[056] Com referência à Figura 7, o gerador de instrução de caixa branca pode ser projetado para garantir que cada transformada na cifra subjacente 700 tenha um número mínimo de técnicas de caixa branca aplicadas ao mesmo antes
Petição 870190009787, de 30/01/2019, pág. 38/57
30/35 de gerar o diagrama de fluxo de dados 710. Visto que o tamanho das tabelas da saída de uma técnica de caixa branca é geralmente maior que o tamanho das tabelas nas entradas, o método 720 também pode ser projetado para aplicar técnicas de caixa branca adicionais (após todas as transformadas de cifra de base terem sido submetidas a pelo menos um conjunto de número de técnicas de caixa branca) a transformadas aleatoriamente selecionadas até que o tamanho total da saída exceda um valor predefinido. Algumas técnicas de caixa branca usadas no processo 720 podem não se encadear bem juntas. Por exemplo, as técnicas podem aumentar o tamanho da saída sem proporcionar uma segurança adicional. O método 720 pode ser projetado para evitar técnicas de encadeamento nessas circunstâncias evitando-se que essas técnicas sejam encadeadas mesmo se forem aleatoriamente selecionadas.
[057] Em determinadas abordagens, a representação de dados completa ou instruções de encriptação de caixa branca também podem ser mantidas sendo geradas usando dados de configuração aleatórias no dispositivo seguro. Por exemplo, os dados de configuração aleatória 404 podem ser aplicados para ofuscar e adicionar uma segurança adicional à geração das instruções de encriptação de caixa branca ou da representação de dados completa. Os dados de configuração aleatória podem ser: um hash de informações como um ID de rede, número serial, valores de ajuste, e outros dados de configuração aleatória no dispositivo seguro; ou dentre um gerador de número aleatório de hardware (RNG) ou pseudo-RNG de software. Os dados de configuração aleatória podem ser usados para ofuscar as instruções de encriptação de caixa branca ou selecionar como as instruções de encriptação de caixa branca são ofuscadas ou, de outro modo, asseguradas contra extração. Essa camada adicional de segurança serviría para proteger as chaves contra extração mesmo se o método específico de ofuscação for conhecido a um invasor.
Petição 870190009787, de 30/01/2019, pág. 39/57
31/35 [058] A representação de dados completa gerada para implementar um fluxograma 710 após o gerador de encriptação de caixa branca ter gerado as instruções pode ser conduzida de várias formas. Em determinadas abordagens, a representação de dados pode ser gerada por código não executável em uma linguagem de programação padrão que seja deliberadamente projetada para não ser Turing-completa. Para gerar a representação de dados completa, o dispositivo seguro pode adotar uma chave de encriptação, expandir a programação de chave, e construir um grafo de processo do processo de encriptação. O grafo de processo pode, então, ser opcionalmente ofuscado através da introdução de codificações de mistura como codificações de mistura bijetivas. O dispositivo seguro pode, então, decompor o grafo de processo em uma representação de dados completa. O gerador de representação de dados completa pode ser configurado para produzir funções primitivas e estruturas de dados que podem ser analisados por um módulo especializado no dispositivo inseguro para implementar o gráfico de processo. O gerador pode ser projetado para utilizar uma biblioteca de funções primitivas que sejam comuns a qualquer protocolo de encriptação de caixa branca tal como uma biblioteca que consiste em uma função primitiva concatenada, uma função primitiva de tabela de pesquisa, e uma função primitiva de seleção de bits. A função primitiva de tabela de pesquisa pode consistir em uma própria tabela de dados onde a identidade da transformada como uma transformada de tabela de pesquisa é entendida pelo módulo especializado ao analisar sintaticamente a representação de dados completa.
[059] A Figura 8 ilustra um diagrama conceituai, e um conjunto de funções primitivas correspondente, de uma representação de dados completa de um conjunto de instruções de encriptação de caixa branca. A representação de dados completa pode incluir um grafo direcionado 800 que representa quais tarefas são
Petição 870190009787, de 30/01/2019, pág. 40/57
32/35 pré-requisitos para a conclusão de outra tarefa ao implementar as instruções de encriptação de caixa branca. Conforme ilustrado no grafo direcionado 800, H1 e H2 precisam ser concluídos antes de G1 ser computado. De modo similar, Hl, H2 e H3 dependem de X. O grafo direcionado pode ser enviado como uma estrutura de dados separada ou pode ser construído nas próprias funções primitivas através da inclusão de campos que identificam outras funções primitivas como pré-requisitos. A representação de dados completa também pode incluir um conjunto de estruturas de dados 820 como tabelas de pesquisa 801, 802 e 803. As estruturas de dados podem ter as características de tabelas de pesquisa 711 na Figura 7 em que elas podem ser acessadas em uma sequência específica para executar a encriptação de uma chave associada. A sequência específica pode ser especificada pelo grafo direcionado.
[060] A abordagem específica usada para decompor o grafo de processo de um conjunto de encriptação de caixa branca afetará as características de quaisquer funções primitivas que sejam geradas para a representação de dados completa. Um conjunto de funções primitivas exemplificador é apresentado na tabela 830. As funções primitivas na tabela 830 são selecionados a partir de uma biblioteca que compreende funções primitivas de tabela de pesquisa, funções primitivas de seleção de bits e funções primitivas de concatenação. As funções primitivas de tabela de pesquisa podem ser usadas por um módulo especializado para obter um valor a partir de uma tabela de pesquisa com base em um valor de entrada. As funções primitivas de seleção de bits podem ser usadas por um módulo especializado para selecionar um bit específico a partir de um valor de entrada. As funções primitivas de concatenação podem ser usadas por um módulo especializado para concatenar valores de entrada. As funções primitivas da tabela 830 incluem quatro campos: ID de função primitiva 811, ID de dados 812, ID de transformada 813 e flag de saída 814.
Petição 870190009787, de 30/01/2019, pág. 41/57
33/35 [061] ID de função primitiva 811 pode ser um identificador único, tal como um inteiro aleatório de 32 bits que é usado para identificar a função primitiva para propósitos de sequenciá-la em relação às outras funções primitivas. Conforme previamente mencionado, as funções primitivas podem ter vários campos adicionas tais como campos que identificam quais outras funções primitivas são pré-requisitos para sua execução e elas podem ser referidas por usarem campos de ID similares. O conjunto de funções primitivas na tabela 830 não inclui referências a outras funções primitivas e é projetado para que seja transferido junto a um grafo direcionado. Por exemplo, o grafo direcionado 810 indicaria que Hl e H2 foram pré-requisitos para G1 e o módulo responsável por analisar a representação de dados completa seria capaz de sequenciar essas funções primitivas para tal propósito usando os campos de ID.
[062] O campo de ID de dados 812 referenciam os dados associados à função primitiva. No caso de Hl, H2 e H3, as funções primitivas são funções primitivas de tabela de pesquisa e os IDs de dados associados referenciam as estruturas de dados 801, 802 e 803 respectiva mente para o módulo acessar a tabela de pesquisa apropriada ao analisar a representação de dados completa. Embora não ilustrado, se uma função primitiva for uma composição de outras funções primitivas, o ID de dados 812 também pode ser um identificador único dessas outras funções primitivas e uma ordem na qual as funções primitivas devem ser compostas.
[063] O campo de ID de transformada 813 referenciam o tipo de transformada associada à função primitiva. No caso ilustrado, G1 e G2 são funções primitivas de seleção de bits, F é uma função primitiva concatenada, e Hl, H2 e H3 são funções primitivas de tabela de pesquisa. Nessa situação, o valor NULL é um valor padrão que o módulo que analisa a representação de dados interpretará como indicando que a função primitiva é uma função primitiva de
Petição 870190009787, de 30/01/2019, pág. 42/57
34/35 tabela de pesquisa. 0 ID transformada também pode incluir dados adicionais para especificar adicionalmente a transformada. Por exemplo, o campo de ID de transformada 813 de função primitiva G1 declara que a função primitiva é uma função primitiva de seleção de bit, e também especifica quais bits devem ser selecionados a partir dos dois valores de entrada. Como outro exemplo, o campo de ID de transformada 813 de função primitiva F declara que a função primitiva é uma função primitiva concatenada, mas não inclui informações adicionais. Nessa abordagem, a transformada padrão podería ser conduzida e as duas entradas à função primitiva poderíam ser concatenadas em sua totalidade em uma ordem predeterminada com base nas informações a partir do grafo direcionado.
[064] O campo de flag de saída 814 referência se a saída da função primitiva é uma saída do grafo direcionado. Portanto, quando o módulo responsável por analisar a representação de dados completa analisar a instrução F será sabido que o resultado é pelo menos parte dos dados que devem ser retornados. Essas informações podem ser alternativamente absorvidas no grafo direcionado e não precisam ser um campo na própria função primitiva.
[065] A representação de dados completa não é diretamente executada no processador do dispositivo não confiável. De preferência, um módulo no dispositivo não confiável é usado para interpretar a representação de dados e executar a encriptação de caixa branca para encriptar dados confidenciais presentes no dispositivo não confiável. O dispositivo não confiável pode usar o módulo de encriptação de caixa branca com um modo de operação de cifra de bloco, tipo CBC, ECB, GCM ou outros, e, além disso, pode usar o módulo de encriptação de caixa branca para encriptar dados relacionados a pagamentos por um padrão industrial, tal como em um bloco de PIN ISO 9564-2. O módulo pode ser uma máquina virtual instanciada no dispositivo não confiável capaz de
Petição 870190009787, de 30/01/2019, pág. 43/57
35/35 analisar a representação, interpretando as funções primitivas e estruturas de dados da representação de dados em uma sequência, e compilando a sequência em um conjunto de instruções que pode ser executada usando o sistema operacional ou kernel do dispositivo não confiável.
[066] Muito embora o relatório descritivo tenha sido descrito em detalhes em relação às modalidades específicas da invenção, avaliar-se-á que os indivíduos versados na técnica, ao atingirem uma compreensão do supracitado, podem prontamente conceber alterações, variações e equivalentes a essas modalidades. Qualquer uma das etapas do método discutidas anteriormente pode ser conduzida por um processador operando com uma mídia não transitória legível por computador que armazena instruções para essas etapas de método. A mídia legível por computador pode ser uma memória dentro de um dispositivo de usuário pessoal, uma estação de trabalho ou uma memória acessível por rede. Embora os exemplos na descrição tenham sido geralmente direcionados à encriptação de informações de pagamento em um dispositivo não confiável em um sistema de Ponto de Vendas (POS), as abordagens podem ser direcionadas a qualquer computador ou sistema computadorizado no qual dados são encriptados em dispositivos não confiáveis ou inseguros. Essas e outras modificações e variações à presente invenção podem ser praticadas pelos indivíduos versados na técnica, sem divergir do escopo da presente invenção, que será mais particularmente apresentado nas reivindicações anexas.

Claims (19)

  1. REIVINDICAÇÕES
    1. Método para compartilhamento seguro de informações, caracterizado pelo fato de que compreende:
    armazenar, em uma memória segura em um primeiro dispositivo, uma chave;
    receber, através de uma interface de usuário em um segundo dispositivo, dados confidenciais;
    gerar, usando um gerador de encriptação de caixa branca no primeiro dispositivo, um conjunto de instruções de encriptação de caixa branca com base na chave;
    gerar, usando um processador seguro no primeiro dispositivo, uma representação de dados completa do conjunto de instruções de encriptação de caixa branca, a geração das instruções de encriptação de caixa branca e a representação completa de dados compreendendo adicionalmente:
    gerar um conjunto de tabelas de pesquisa usando a chave;
    ofuscar, usando o processador seguro no primeiro dispositivo, o conjunto de tabelas de pesquisa com codificações de mistura bijetivas para produzir um conjunto de tabelas de pesquisa ofuscadas, e gerar um grafo direcionado e um conjunto de funções primitivas, em que o conjunto de funções primitivas inclui dados que descrevem completamente o conjunto de tabelas de pesquisa ofuscadas;
    transmitir a representação de dados completa a partir do primeiro dispositivo ao segundo dispositivo; e encriptar, usando um processador padrão no segundo dispositivo, os dados confidenciais usando a representação de dados completa, a encriptação compreendendo adicionalmente:
    analisar, usando o processador padrão no segundo dispositivo, o conjunto
    Petição 870190009787, de 30/01/2019, pág. 45/57
  2. 2/10 de funções primitivas de acordo com o grafo direcionado, a análise incluindo encontrar uma ordem na qual os valores específicos são calculados, encontrando operações a serem realizadas nesses valores específicos e encontrando tabelas de pesquisa ofuscadas nas quais pesquisar valores;
    em que a representação de dados completa é não executável.
    2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que:
    o primeiro dispositivo é um dispositivo seguro que aloja a memória segura e o processador seguro;
    o segundo dispositivo é um dispositivo de exibição sensível ao toque;
    os dados confidenciais consistem em um número de identificação pessoal; e a etapa de encriptação dos dados confidenciais produz um número de identificação pessoal encriptado.
  3. 3. Método, de acordo com a reivindicação 2, caracterizado pelo fato de que compreende, ainda:
    formar uma conexão segura entre o primeiro dispositivo e o segundo dispositivo;
    em que a transmissão da representação de dados completa a partir do primeiro dispositivo ao segundo dispositivo é conduzida usando a conexão segura; e em que o primeiro dispositivo é um leitor de cartão seguro.
  4. 4. Método, de acordo com a reivindicação 3, caracterizado pelo fato de que compreende, ainda:
    derivar, usando o processador seguro no primeiro dispositivo, a chave usando um gerador de chave aleatória e dados de configuração aleatória no primeiro dispositivo;
    Petição 870190009787, de 30/01/2019, pág. 46/57
    3/10 transmitir, usando a conexão segura, os dados confidenciais encriptados a partir do segundo dispositivo ao primeiro dispositivo;
    decriptar, usando o processador seguro no primeiro dispositivo, os dados confidenciais encriptados para produzir dados confidenciais decriptados.
    re-encriptar, usando o processador seguro no primeiro dispositivo, os dados confidenciais decriptados usando uma chave secreta para produzir dados confidenciais re-encriptados; e transmitir os dados confidenciais re-encriptados a um processador;
    em que a interface de usuário é uma tela sensível ao toque do segundo dispositivo.
  5. 5. Método, de acordo com a reivindicação 4, caracterizado pelo fato de que compreende, ainda:
    receber, usando o primeiro dispositivo, dados seguros;
    encriptar, usando o processador seguro no primeiro dispositivo, os dados seguros encriptados usando a chave secreta para produzir dados seguros encriptados; e transmitir os dados seguros encriptados ao processador;
    em que a chave secreta é uma chave única derivada por transação (DUKPT).
  6. 6. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende, ainda:
    gerar, no primeiro dispositivo, a chave;
    receber, através da interface de usuário no segundo dispositivo, conjuntos adicionais de dados confidenciais;
    gerar, no primeiro dispositivo, um conjunto de chaves novas que correspondam unicamente aos conjuntos adicionais de dados confidenciais.
  7. 7. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que encriptar, usando o processador padrão no segundo dispositivo, os dados
    Petição 870190009787, de 30/01/2019, pág. 47/57
    4/10 confidenciais usando a representação de dados completa, compreende, ainda: aplicar os dados confidenciais ao conjunto de funções primitivas de acordo com o grafo direcionado.
  8. 8. Método, de acordo com a reivindicação 7, caracterizado pelo fato de que uma função primitiva no conjunto de funções primitivas inclui:
    um identificador único;
    um arranjo de dados binários que representam uma tabela de pesquisa; e um flag para indicar se a função primitiva gera um resultado final no grafo direcionado.
  9. 9. Método, de acordo com a reivindicação 7, caracterizado pelo fato de que compreende, ainda:
    instanciar, usando o processador padrão no segundo dispositivo, uma máquina virtual;
    em que a encriptação é conduzida pela máquina virtual; e em que a representação de dados completa é não executável em relação ao processador padrão.
  10. 10. Sistema para compartilhamento seguro de informações, caracterizado pelo fato de que compreende:
    um dispositivo seguro com um processador seguro e uma memória segura; um dispositivo inseguro com um processador padrão e uma memória;
    um canal seguro de comunicação entre o dispositivo seguro e o dispositivo inseguro;
    uma chave armazenada na memória segura;
    em que a memória segura compreende instruções executáveis por processador que, quando executadas pelo processador seguro, fazem o processador seguro:
    gerar um conjunto de instruções de encriptação de caixa branca usando a
    Petição 870190009787, de 30/01/2019, pág. 48/57
    5/10 chave; e gerar uma representação de dados completa do conjunto de instruções de encriptação de caixa branca usando o conjunto de instruções de encriptação de caixa branca;
    em que a memória segura compreende instruções executáveis por processador que, quando executadas pelo processador seguro para gerar o conjunto de instruções de encriptação de caixa branca e a representação de dados completa do conjunto de instruções de criptografia de caixa branca, fazem ainda o processador seguro:
    gerar um conjunto de tabelas de pesquisa usando a chave;
    ofuscar, usando um processador seguro no dispositivo seguro, o conjunto de tabelas de pesquisa com codificações de mistura bijetivas para produzir um conjunto de tabelas de pesquisa ofuscadas, e gerar um grafo direcionado e um conjunto de funções primitivas, em que o conjunto de funções primitivas inclui dados que descrevem completamente o conjunto de tabelas de pesquisa ofuscadas; e em que a memória do dispositivo inseguro compreende instruções executáveis por processador que, quando executadas pelo processador padrão, fazem o processador padrão:
    instanciar uma máquina virtual; e:
    encriptar, usando a máquina virtual instanciada, dados confidenciais usando a representação de dados completa em que a memória do dispositivo inseguro compreende instruções executáveis por processador que, quando executadas pelo processador padrão para encriptar dados confidenciais, fazem ainda o processador padrão:
    analisar, usando a máquina virtual instanciada, o conjunto de funções primitivas de acordo com o grafo direcionado, a análise incluindo encontrar uma
    Petição 870190009787, de 30/01/2019, pág. 49/57
    6/10 ordem na qual valores específicos são calculados, encontrando operações a serem realizadas nesses valores específicos e encontrando tabelas de pesquisa ofuscadas nas quais pesquisar valores;
  11. 11. Sistema, de acordo com a reivindicação 10, caracterizado pelo fato de que:
    o canal seguro de comunicação é um canal de comunicação sem fio;
    o dispositivo seguro é um dispositivo de leitor de cartão seguro;
    o dispositivo inseguro é um dispositivo de exibição sensível ao toque;
    o dispositivo de exibição sensível ao toque compreende uma tela sensível ao toque; e os dados confidenciais consistem em um número de identificação pessoal recebido através da tela sensível ao toque.
  12. 12. Sistema, de acordo com a reivindicação 10, caracterizado pelo fato de que compreende, ainda:
    uma chave secreta armazenada na memória segura;
    em que o dispositivo seguro é programado para: (i) decriptar os dados confidenciais encriptados a partir do dispositivo inseguro usando a chave para produzir dados confidenciais decriptados; e (ii) re-encriptar os dados confidenciais decriptados usando a chave secreta para produzir dados confidenciais re-encriptados; e um servidor seguro programado para decriptar os dados confidenciais reencriptados usando a chave secreta;
    em que a chave secreta é uma chave única derivada por transação (DUKPT).
  13. 13. Sistema, de acordo com a reivindicação 10, caracterizado pelo fato de que compreende, ainda:
    uma tela sensível ao toque no dispositivo inseguro que é programada para receber os dados confidenciais;
    Petição 870190009787, de 30/01/2019, pág. 50/57
    7/10 um leitor de cartão no dispositivo seguro que é programado para receber dados seguros;
    um servidor seguro;
    em que os dados confidenciais consistem em um número de identificação pessoal; e em que os dados seguros e os dados confidenciais são usados pelo servidor seguro para autorizar uma transação de dados.
  14. 14. Sistema, de acordo com a reivindicação 13, caracterizado pelo fato de que:
    a memória do dispositivo inseguro compreende instruções executáveis por processador que, quando executadas pelo processador padrão, fazem o processador padrão instanciar um sistema operacional;
    a representação de dados completa é não executável pelo sistema operacional.
  15. 15. Sistema, de acordo com a reivindicação 13, caracterizado pelo fato de que as instruções executáveis do processador que, quando executadas pelo processador padrão para encriptar dados confidenciais, fazem o processador padrão:
    aplicar, usando a máquina virtual instanciada, os dados confidenciais ao conjunto de funções primitivas de acordo com o grafo direcionado.
  16. 16. Sistema para compartilhamento seguro de informações, caracterizado pelo fato de que compreende:
    um dispositivo não confiável com uma interface de usuário para receber dados confidenciais;
    um processador e uma memória no dispositivo não confiável;
    um sistema operacional instanciado no dispositivo não confiável pelo processador;
    Petição 870190009787, de 30/01/2019, pág. 51/57
    8/10 um dispositivo de leitor de cartão seguro com um processador seguro e uma memória segura;
    um canal de comunicação seguro entre o dispositivo não confiável e o dispositivo de leitor de cartão seguro;
    uma chave armazenada no dispositivo de leitor de cartão seguro;
    em que a memória segura no dispositivo de leitor de cartão seguro compreende instruções executáveis por processador que, quando executadas pelo processador seguro, fazem o processador seguro:
    gerar um conjunto de instruções de encriptação de caixa branca usando a chave; e gerar uma representação de dados completa das instruções de encriptação de caixa branca;
    em que as instruções executáveis por processador que, quando executadas pelo processador seguro para gerar o conjunto de instruções de encriptação de caixa branca e a representação de dados completa do conjunto de instruções de criptografia de caixa branca, fazem ainda o processador seguro:
    gerar um conjunto de tabelas de pesquisa usando a chave;
    ofuscar, usando um processador seguro no dispositivo de leitor de cartão seguro, o conjunto de tabelas de pesquisa com codificações de mistura bijetivas para produzir um conjunto de tabelas de pesquisa ofuscadas, e gerar um grafo direcionado e um conjunto de funções primitivas, em que o conjunto de funções primitivas inclui dados que descrevem completamente o conjunto de tabelas de pesquisa ofuscadas; e em que a memória no dispositivo inseguro compreende instruções executáveis por processador que, quando executadas pelo processador, fazem o processador:
    instanciar uma aplicação; e
    Petição 870190009787, de 30/01/2019, pág. 52/57
    9/10 encriptar, usando a aplicação, dados confidenciais usando a representação de dados completa;
    em que as instruções executáveis por processador que, quando executadas pelo processador, fazem o processador encriptar dados confidenciais, fazendo ainda o processador:
    analisar, usando a aplicação, o conjunto de funções primitivas de acordo com o grafo direcionado, a análise incluindo encontrar uma ordem na qual valores específicos são calculados, encontrando operações a serem realizadas nesses valores específicos e encontrando tabelas de pesquisa ofuscadas nas quais pesquisar valores; e em que a representação de dados completa é não executável em relação ao sistema operacional.
  17. 17. Sistema, de acordo com a reivindicação 16, caracterizado pelo fato de que:
    o dispositivo não confiável é um dispositivo de exibição sensível ao toque;
    a interface de usuário é uma tela sensível ao toque do dispositivo de exibição sensível ao toque; e os dados confidenciais consistem em um número de identificação pessoal recebido através da tela sensível ao toque.
  18. 18. Sistema, de acordo com a reivindicação 16, caracterizado pelo fato de que compreende, ainda:
    uma chave secreta armazenada na memória segura;
    em que a memória segura compreende ainda instruções executáveis por processador que, quando executadas pelo processador seguro, fazem o processador seguro:
    decriptar dados confidenciais encriptados a partir do dispositivo não confiável usando a chave para produzir dados confidenciais decriptados; e
    Petição 870190009787, de 30/01/2019, pág. 53/57
    10/10 re-encriptar os dados confidenciais decriptados usando a chave secreta para produzir dados confidenciais re-encriptados; e um servidor seguro programado para decriptar os dados confidenciais reencriptados usando a chave secreta;
    em que a chave secreta é uma chave única derivada por transação (DUKPT).
  19. 19. Sistema, de acordo com a reivindicação 16, caracterizado pelo fato de que as instruções executáveis por processador que, quando executadas pelo processador, fazem o processador encriptar os dados confidenciais, fazendo ainda o processador:
    aplicar os dados confidenciais ao conjunto de funções primitivas de acordo com o grafo direcionado.
BR102018015221A 2017-12-15 2018-07-25 Método para compartilhamento seguro de informações e sistema relacionado BR102018015221B8 (pt)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US15/843,264 2017-12-15
US15/843,264 US10140612B1 (en) 2017-12-15 2017-12-15 POS system with white box encryption key sharing

Publications (3)

Publication Number Publication Date
BR102018015221A2 BR102018015221A2 (pt) 2019-02-12
BR102018015221B1 true BR102018015221B1 (pt) 2019-12-24
BR102018015221B8 BR102018015221B8 (pt) 2022-06-28

Family

ID=64315478

Family Applications (1)

Application Number Title Priority Date Filing Date
BR102018015221A BR102018015221B8 (pt) 2017-12-15 2018-07-25 Método para compartilhamento seguro de informações e sistema relacionado

Country Status (5)

Country Link
US (3) US10140612B1 (pt)
EP (1) EP3499444A1 (pt)
AU (2) AU2018200866A1 (pt)
BR (1) BR102018015221B8 (pt)
CA (1) CA2993748C (pt)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10546302B2 (en) 2016-06-30 2020-01-28 Square, Inc. Logical validation of devices against fraud and tampering
US10715536B2 (en) 2017-12-29 2020-07-14 Square, Inc. Logical validation of devices against fraud and tampering
US10693662B2 (en) * 2018-02-22 2020-06-23 Idlogiq Inc. Methods for secure serialization of supply chain product units
US10833849B2 (en) 2018-03-21 2020-11-10 Clover Network, Inc. Unified secure device provisioning
US11362824B2 (en) * 2018-05-25 2022-06-14 Intertrust Technologies Corporation Content management systems and methods using proxy reencryption
US11206130B2 (en) * 2018-07-31 2021-12-21 Nxp B.V. Customizing cryptographic keys between multiple hosts
US11507958B1 (en) 2018-09-26 2022-11-22 Block, Inc. Trust-based security for transaction payments
US11494762B1 (en) 2018-09-26 2022-11-08 Block, Inc. Device driver for contactless payments
US11429753B2 (en) * 2018-09-27 2022-08-30 Citrix Systems, Inc. Encryption of keyboard data to avoid being read by endpoint-hosted keylogger applications
CN109688584B (zh) * 2018-12-27 2022-04-08 绍兴心越科技有限公司 适用于资源受限网络节点的数据安全存储系统及方法
TR201905756A2 (tr) * 2019-04-18 2019-05-21 Kartek Kart Ve Bilisim Teknolojileri Ticaret Anonim Sirketi Yazılım tabanlı POSlara (SoftPOS) PIN girişi, saklanışı ve iletimi için yazılımsal güvenlik sistemi ve yöntemi.
US10726681B1 (en) * 2019-07-26 2020-07-28 Clover Network, Inc. Advanced hardware system for self service checkout kiosk
JP7383949B2 (ja) * 2019-09-20 2023-11-21 富士電機株式会社 情報処理装置及びプログラム
CN110933108B (zh) * 2019-09-26 2021-05-11 腾讯科技（深圳）有限公司 基于区块链网络的数据处理方法、装置、电子设备及存储介质
FR3144464A1 (fr) * 2022-12-22 2024-06-28 Banks And Acquirers International Holding Procédé de sécurisation de la transmission de données, et système correspondant.

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2825495B1 (fr) * 2001-05-31 2003-09-26 Schlumberger Systems & Service Terminal electronique de paiement, carte a puce adaptee a un tel terminal et procede de chargement d'une cle secrete dans un tel terminal
CA2354470A1 (en) 2001-07-30 2003-01-30 Cloakware Corporation Active content for secure digital media
US7900041B2 (en) 2003-07-22 2011-03-01 Irdeto Canada Corporation Software conditional access system
US7769165B2 (en) 2005-10-14 2010-08-03 Microsoft Corporation Semi-public white-box cipher
WO2007084896A2 (en) * 2006-01-13 2007-07-26 Magtek, Inc. Secure magnetic stripe reader
CA2699042C (en) 2007-09-13 2017-01-03 Irdeto B.V. Cryptographic processing of content
US20100189263A1 (en) 2008-11-05 2010-07-29 Mustang Microsystems, Inc. Method and apparatus for generating and updating security codes
EP2362573A1 (en) * 2010-02-19 2011-08-31 Irdeto B.V. Device and method for establishing secure trust key
RU2620712C2 (ru) 2012-01-09 2017-05-29 Конинклейке Филипс Н.В. Устройство виртуальной машины, имеющее управляемую ключом обфускацию, и способ
US20140324708A1 (en) * 2012-06-12 2014-10-30 Square, Inc. Raw sensor input encryption for passcode entry security
CN106031207B (zh) 2013-12-02 2019-12-13 万事达卡国际股份有限公司 用于向不带有安全元件的移动设备安全传送远程通知服务消息的方法及系统
KR20150090438A (ko) 2014-01-29 2015-08-06 한국전자통신연구원 화이트박스 암호 장치 및 그 방법
US9654279B2 (en) 2014-03-20 2017-05-16 Nxp B.V. Security module for secure function execution on untrusted platform
US9813245B2 (en) 2014-08-29 2017-11-07 Visa International Service Association Methods for secure cryptogram generation
SG10201405852QA (en) 2014-09-18 2016-04-28 Huawei Internat Pte Ltd Encryption function and decryption function generating method, encryption and decryption method and related apparatuses
US9774443B2 (en) 2015-03-04 2017-09-26 Apple Inc. Computing key-schedules of the AES for use in white boxes
US10171234B2 (en) 2015-12-16 2019-01-01 Nxp B.V. Wide encoding of intermediate values within a white-box implementation
US10223511B2 (en) * 2016-03-30 2019-03-05 Nxp B.V. Watermarking input and output of a white-box implementation
JP6877889B2 (ja) * 2016-04-08 2021-05-26 ソニーグループ株式会社 暗号化装置、暗号化方法、復号化装置、及び復号化方法
KR101933649B1 (ko) 2016-05-27 2018-12-28 삼성에스디에스 주식회사 화이트박스 암호 알고리즘을 이용한 공개키 암호화를 위한 장치 및 방법
US10546119B2 (en) * 2016-11-14 2020-01-28 Mastercard International Incorporated Methods for securely storing sensitive data on mobile device
US10615980B2 (en) * 2017-02-02 2020-04-07 Mastercard International Incorporated Methods and systems for securely storing sensitive data on smart cards
EP3665566A4 (en) * 2017-08-08 2021-04-21 Crypto4A Technologies Inc. SECURE MACHINE-EXECUTED CODE DEPLOYMENT AND EXECUTION PROCESS AND SYSTEM

Also Published As

Publication number Publication date
US20210056546A1 (en) 2021-02-25
US10140612B1 (en) 2018-11-27
BR102018015221B8 (pt) 2022-06-28
BR102018015221A2 (pt) 2019-02-12
EP3499444A1 (en) 2019-06-19
AU2019271965B2 (en) 2021-04-29
AU2018200866A1 (en) 2019-07-04
CA2993748A1 (en) 2019-06-15
CA2993748C (en) 2024-02-13
AU2019271965A1 (en) 2019-12-19
US10909532B2 (en) 2021-02-02
US20190188703A1 (en) 2019-06-20
US11615411B2 (en) 2023-03-28

Similar Documents

Publication Publication Date Title
US11615411B2 (en) POS system with white box encryption key sharing
KR101725847B1 (ko) 키 복원 공격들을 좌절시키기 위한 대책으로서 송신기-수신기 페어링을 위한 마스터 키 암호화 기능들
CN105915502B (zh) 利于网络加入的方法和系统
CN106797317A (zh) 安全共享密钥共享系统及方法
CN107453880B (zh) 一种云数据安全存储方法和系统
CN102196375A (zh) 保护带外消息
ES2619613T3 (es) Método criptográfico para intercambiar mensajes de forma segura y dispositivo y sistema para implementar este método
CN101682628A (zh) 安全通信
EP2629225A1 (en) System, devices and methods for collaborative execution of a software application comprising at least one encrypted instruction
CN102567688A (zh) 一种安卓操作系统上的文件保密系统及其保密方法
US9729319B2 (en) Key management for on-the-fly hardware decryption within integrated circuits
CN104200137A (zh) 一种保护java程序自身安全的方法
CN104866784A (zh) 一种基于bios加密的安全硬盘、数据加密及解密方法
CN105262586B (zh) 汽车防盗设备的密钥分配方法及装置
JP2023510002A (ja) エアギャッピングハードウェアプロトコルを使用したセキュアなデータ転送のためのシステムおよび方法
CN106341384A (zh) 用于促进安全通信的方法
US10404718B2 (en) Method and device for transmitting software
CN104081712A (zh) 使用隐藏的根密钥的可重复的应用特定的加密密钥获得
KR101834522B1 (ko) 데이터 확인 장치 및 이를 이용하여 데이터를 확인하는 방법
CN106161000A (zh) 对数据文件进行加密和解密的方法和系统
KR101428665B1 (ko) Ａｅｓ－ｏｔｐ기반의 보안 시스템 및 방법
KR101810165B1 (ko) 전자 화폐 단말 및 이를 이용하여 전자 화폐를 제공하는 방법
KR101834515B1 (ko) 입력부를 포함하는 암복호화 장치
KR20170132464A (ko) 암복호화 장치 및 이를 이용한 암복호화 방법
CN105262743A (zh) 数据存储方法及安全装置、网络存储系统

Legal Events

Date Code Title Description
B03B Publication of an application: publication anticipated [chapter 3.2 patent gazette]
B09A Decision: intention to grant [chapter 9.1 patent gazette]
B16A Patent or certificate of addition of invention granted [chapter 16.1 patent gazette]

Free format text: PRAZO DE VALIDADE: 20 (VINTE) ANOS CONTADOS A PARTIR DE 25/07/2018, OBSERVADAS AS CONDICOES LEGAIS.

B25D Requested change of name of applicant approved

Owner name: CLOVER NETWORK, LLC (US)