PT2306668T - Sistema e método de transação em linha segura - Google Patents

Description

DESCRIÇÃO "Sistema e método de transação em linha segura" A presente invenção refere-se ao campo das transmissões seguras de dados através de, pelo menos, uma rede de comunicações, tal como a Internet, por exemplo. As transmissões permitem, por exemplo a realização de operações "em linha" (ou "online" de acordo com a terminologia anglo-saxónica), ao conectarem-se a, pelo menos, um servidor utilizando, pelo menos, um terminal adequado, através de, pelo menos, uma rede de comunicação. A presente invenção aproveita os cartões inteligentes seguros, como, por exemplo, os "cartões de crédito" ou "cartões de pagamento inteligentes", em particular, os conhecidos pelo nome de EMV (que significa "Europay Mastercard Visa"), permitindo proteger os pagamentos efetuados através da pastilha eletrónica (por exemplo, de tipo ISSO 7816) do cartão compreendendo, pelo menos, uma chave de encriptamento e, possivelmente, devido à utilização de um código de identificação associado (número de identificação pessoal, PIN para "Personal Identification Number", de acordo com a terminologia anglo-saxónica). Deve salientar-se que a presente invenção é particularmente adequada para realizar transações em linha, mas também pode ser utilizada para vários tipos de trocas seguras de informação. Assim, por exemplo, a presente invenção é adequada para utilização de outros cartões, tais como, por exemplo, os cartões de saúde, os cartões dos profissionais de saúde (CPS) ou qualquer outro tipo de cartão cuja pastilha eletrónica armazena, pelo menos, uma chave de encriptamento, a fim de proteger a troca de dados de qualquer tipo (tais trocas são, no presente documento, denominadas coletivamente por "transação"). Na verdade, a invenção pode, possivelmente, evoluir em função da evolução das normas dos cartões, em particular, dos cartões EMV, e, no presente pedido, designam-se, de um modo geral, por "cartão seguro" tais cartões inteligentes compreendendo, pelo menos, uma chave de encriptamento simétrica armazenada na pastilha eletrónica e dotados com valências criptográficas por chave simétrica, ao contrário dos cartões de tipo PKI ("Public key Infrastructure", de acordo com a terminologia anglo-saxónica, designando uma infraestrutura permitindo a gestão e utilização de certificados digitais associando chaves públicas à identidade de um utilizador) conhecidos do estado da técnica, que utilizam chaves assimétricas e têm os inconvenientes mencionados abaixo.

Um problema na área das transações seguras refere-se a possíveis ataques, por exemplo, por piratas informáticos, para atingir dados sensíveis de transações, tais como informações bancárias, etc. Muitos ataques informáticos são executados com base em engenharia social (isto é, a falta de conhecimentos técnicos do público, que não conhece os mecanismos de segurança e, por conseguinte, pode utilizar os mecanismos de uma forma que os pode tornar vulneráveis). Conhecem-se, em particular, vírus informáticos que são programas de computador escritos com o objetivo de se propagarem para outros computadores ao serem inseridos em programas legítimos denominados "hospedeiros". Também podem ter o efeito, pretendido ou não, de prejudicar o funcionamento do computador infetado ao perturbar mais ou menos gravemente o mesmo. Podem espalhar-se através de qualquer meio de troca de dados digitais como a Internet, mas também disquetes, CD-ROM, chaves USB, etc. Há, também, ataques conhecidos como mistificação da interface ("phishing", de acordo com a terminologia anglo-saxónica) utilizados por infratores para obter informações pessoais visando cometer roubo de identidade. A técnica consiste em fazer a vítima acreditar que se está a dirigir a um terceiro confiável (banco, administração, etc.), a fim de obter informações pessoais (senha, número de cartão de crédito, data de nascimento, etc.) A mistificação de interface pode ser efetuada por correio eletrónico, sítios da Web falsificados ou outros meios eletrónicos. Também se conhecem ataques denominados "pharming" em inglês, que exploram as vulnerabilidades do DNS ("Domain Name System", de acordo com a terminologia anglo-saxónica) para recolher dados de uma vítima. Este é um tipo de mistificação de interface que permite o roubo de informações depois de atrair a vítima para um sítio da Web mascarado, mesmo que o nome de domínio tenha sido digitado corretamente. Nesse caso, os piratas informáticos já tinham modificado a correspondência entre o nome de domínio e o endereço IP. Assim, por exemplo, www.meubanco.pt já não aponta para o endereço IP do servidor do "meu banco", mas para outro servidor fraudulento. São conhecidos outros tipos de ataques com o nome de registo de teclado ("keylogger", de acordo com a terminologia anglo-saxónica), através do qual um equipamento ou um suporte lógico ("software") espião regista as teclas que foram selecionadas no teclado de um computador em determinadas condições e transmite-as, em particular, para permitir uma utilização fraudulenta. Também se conhecem ataques com o nome de "ataque de replicação" (HDM) (ou "man in the middle attack", MITM, de acordo com a terminologia anglo-saxónica) que visa intercetar as comunicações entre duas partes, sem que nenhuma delas duvide que o canal de comunicação (CS) entre si foi comprometido. 0 atacante deve, em primeiro lugar, estar apto a observar e intercetar mensagens entre as vitimas. 0 ataque de replicação é particularmente aplicável no protocolo original de troca de chaves Diffie-Hellman, quando é utilizado sem autenticação. Também se conhecem ataques com o nome de "homem do navegador" (ou "man in the browser", segundo a terminologia anglo-saxónica), que é uma forma recente de ameaça associada ao ataque de replicação, e assenta num cavalo de Troia (suporte lógico malicioso aparentemente legitimo concebido para executar ações sem o conhecimento do utilizador, utilizando, em geral, direitos pertencentes ao seu ambiente para desviar, difundir ou destruir informações, ou, ainda, para abrir uma "backdoor" que permita a um atacante assumir o controlo remoto de um computador). Estes ataques infetam, por exemplo, um navegador da Internet e permitem modificar páginas, modificar o conteúdo ou transações, ou inserir transações adicionais, tudo isto de uma forma totalmente invisível ao utilizador e à aplicação hospedeira. Estes ataques são particularmente perigosos porque, de um modo geral, são bem-sucedidos, mesmo quando se utilizam mecanismos de segurança como SSL, PKI ("Public Key Infrastructure", de acordo com a terminologia anglo-saxónica, designando uma infraestrutura permitindo a gestão e utilização de certificados digitais associando chaves públicas à identidade de um utilizador) e/ou a utilização de autenticação de dois ou três fatores.

Na técnica anterior, conhecem-se várias soluções para realizar transações seguras na Internet. No entanto, a maior parte das soluções conhecidas permanecem vulneráveis a, pelo menos, um dos ataques conhecidos. Conhecem-se, por exemplo, soluções utilizando um "dongle" (suporte físico, tal como uma chave a ligar a um computador, por exemplo, USB, "Universal Serial Bus") ou objetos portáteis, ou cartões inteligentes e/ou leitores de cartões inteligentes configurados para proteger operações. No entanto, este tipo de solução tem a desvantagem de, em geral, utilizar certificados, tais como os dos protocolos SSL/TLS, por exemplo, que não permitem, em geral, a verificação da sua autenticidade pelo utilizador, e que, portanto, são vulneráveis a alguns dos ataques descritos. Além disso, estas soluções têm o inconveniente de exigir a utilização de uma infraestrutura de rede que suporte a utilização destes dispositivos para autenticação (gestão de certificados distribuídos, etc.). De facto, vários protocolos relativamente seguros, tais como SSL/TLS, são desviados devido a problemas de engenharia social mencionados acima, na medida em que os utilizadores aceitam qualquer certificado que lhes seja apresentado.

Também se conhecem soluções que consistem na criação de um canal seguro (ou "túnel" seguro), ou seja, um canal (CS) de comunicação encriptado entre as 2 entidades relacionadas durante uma transação (banco-utilizador, por exemplo). No entanto, este tipo de solução também tem a desvantagem de permanecer vulnerável a determinados ataques na medida em que o canal seguro é baseado na utilização de certificados, tais como os protocolos SSL/TLS.

Finalmente, também se conhecem, em particular, dos documentos WO 2005/001618, EP 1850297 e WO 01/82246, soluções conhecidas como sendo compatíveis com o Programa de Autenticação por Cartão (PAC ou CAP de "Pastilha eletrónica Authentication Program" de acordo com a terminologia anglo-saxónica) e utilizando um leitor de cartão bancário conectado ao terminal (computador, por exemplo) do utilizador e no qual este insere um cartão bancário para permitir a assinatura de transações pela pastilha eletrónica desse cartão. No entanto, este tipo de solução tem a desvantagem de ser vulnerável a determinados ataques, na medida em que as informações sensíveis transitam através do terminal que ordena ao leitor a assinatura da transação pelo cartão. Por exemplo, um problema com esta solução está associado à engenharia social, dado que se deve ao facto de o utilizador não verificar, de um modo geral, as informações exibidas pelo leitor e se contentar em validar a transação confiando no que é apresentado no seu terminal, ao passo que um ataque, por exemplo do tipo de homem do navegador, pode ter desviado as informações a validar no leitor ao exibir informações normais no terminal.

Neste contexto, existe uma necessidade de soluções simples, económicas e fáceis de aplicar, especialmente para o público em geral, permitindo proteger transações em linha, ao contrário das soluções conhecidas, muitas vezes dispendiosas, com uma utilização e implementação muito complexas, em particular para o público em geral, nomeadamente devido a problemas relacionados com a engenharia social.

Um objetivo da presente invenção é, assim, superar, pelo menos, alguns inconvenientes da técnica anterior ao proporcionar um sistema permitindo inicializar transações seguras em linha.

Este objetivo é conseguido por um sistema de inicialização de transação segura em linha, por meio de, pelo menos, uma rede de comunicação, compreendendo o sistema, pelo menos, um equipamento de um fornecedor de serviços compreendendo, pelo menos, um servidor configurado para gerir transações em linha, através da troca de dados representativas de transações, compreendendo o referido equipamento, pelo menos, um módulo de segurança configurado para proteger essas transações, caracterizado por: — o referido sistema compreender, pelo menos, um leitor de cartão inteligente acedendo ao equipamento de fornecedor através da referida rede de comunicação e compreendendo meios de processamento configurados para, por um lado, trocar dados com, pelo menos, um pastilha eletrónica de, pelo menos, um cartão seguro, a fim de obter da pastilha eletrónica e transmitir para o módulo de segurança dados, denominados públicos, representativos de, pelo menos, uma informação relacionada com o cartão e, por outro lado, para gerar, em cooperação com a referida pastilha eletrónica, pelo menos, uma chave de sessão, e transmitir para o módulo de segurança dados encriptados utilizando essa chave de sessão, — o módulo de segurança ser configurado para calcular a referida chave de sessão a partir dos referidos dados públicos recebidos e de, pelo menos, uma chave de encriptação, — se calcular a chave de sessão pelo leitor e pelo módulo de segurança, permitindo-se a inicialização da transação através do estabelecimento de um canal de comunicação seguro, no qual os dados representativos da transação podem transitar de forma encriptada pela referida chave de sessão.

De acordo com uma outra caracteristica, a pastilha eletrónica do cartão é configurado para gerar, a partir de, pelo menos, uma chave de encriptamento armazenada na pastilha eletrónica, pelo menos, um criptograma utilizado pelos meios de processamento do leitor configurados para gerar a chave de sessão utilizada para estabelecer o canal seguro.

De acordo com uma outra caracteristica: — o módulo de segurança utiliza, pelo menos, uma chave, denominada chave mãe utilizada para a geração de chaves de cartões seguros fornecidos pelo fornecedor de serviços, denominadas chaves filhas, sendo cada um dos cartões fornecidos identificáveis a partir de, pelo menos, uma informação contida nos dados públicos, — os meios de processamento do leitor transmitem os dados públicos para o módulo de segurança para lhe permitirem encontrar a chave de encriptação a utilizar para calcular a chave de sessão.

De acordo com uma outra caracteristica, o equipamento do fornecedor de serviços compreende, pelo menos, uma base de dados armazenando as chaves de encriptação dos cartões seguros fornecidos pelo fornecedor de serviços, acedendo o módulo de segurança a essa base de dados para encontrar, em função dos dados públicos recebidos do leitor de cartão inteligente, a chave de encriptação a utilizar para calcular a chave de sessão.

De acordo com uma outra caracteristica, o leitor e o equipamento de fornecedor são associados através de uma comunicação segura através de um protocolo de tipo SSL/TLS, na qual é estabelecido o canal seguro.

De acordo com uma outra caracteristica, os meios de processamento do leitor são configurados para receber do módulo de segurança e processar, pelo menos, um comando de inicialização do canal seguro compreendendo um número imprevisível e induzindo a interrogação da pastilha eletrónica pelo leitor, para obter, pelo menos, um criptograma e os dados representativos de informações relacionadas com o cartão, o que permite aos meios de processamento do leitor gerar a chave de sessão utilizada para estabelecer o canal de comunicação seguro e transmitir ao módulo de segurança, por um lado, os dados representativos de informações relacionadas com o cartão e, por outro lado, os referidos dados encriptados utilizando essa chave de sessão, que compreendem dados relativos ao número imprevisível.

De acordo com uma outra caracteristica, a inicialização da transação segue-se a uma transmissão para o servidor do equipamento de fornecedor de, pelo menos, uma parte dos dados representativos da transação, por um servidor terceiro gerando um sítio Internet ao qual o utilizador está ligado.

De acordo com uma outra caracteristica, o servidor de equipamento de fornecedor é configurado para gerar o estabelecimento e a utilização do canal seguro ao processar e conservar um número imprevisível, a chave de sessão, um número de sessão gerado no estabelecimento do canal seguro e que está associado ao número imprevisível e a um contador de transações do cartão, bem como um número de sequência incrementado a cada comando enviado para o leitor durante cada sessão.

De acordo com uma outra caracteristica, o módulo de segurança do equipamento de fornecedor é configurado para armazenar a chave de sessão em meios de armazenamento e/ou para encriptar a chave de sessão utilizando uma chave, denominada chave mestra, e transmiti-la para o servidor, para armazenamento em forma encriptada nos meios de armazenamento.

Outro objetivo da presente invenção é superar, pelo menos, alguns dos inconvenientes da técnica anterior ao proporcionar um sistema permitindo proteger as transações em linha.

Este objetivo é conseguido por um sistema de transação segura compreendendo um sistema de inicialização de acordo com a invenção, em que o leitor e o módulo de segurança são configurados para encriptar e desencriptar, pela referida chave de sessão, os dados representativos da transação que são trocados entre estes durante a transação, transitando esses dados, em seguida, pelo canal de comunicação seguro devido a essas encriptações/desencriptações.

De acordo com outra caracteristica, o servidor é configurado para exigir do módulo de segurança, em cada transmissão de dados com o leitor, uma encriptação/desencriptação pela referida chave de sessão dos dados transmitidos, sendo o leitor configurado para, também, encriptar/desencriptar os dados trocados durante a transação.

Outro objetivo da presente invenção é superar, pelo menos, alguns dos inconvenientes da técnica anterior ao proporcionar um método permitindo inicializar transações seguras em linha.

Este objetivo é conseguido por um método de inicialização de transação segura em linha, através de, pelo menos, uma rede de comunicação, implementado por um sistema de inicialização de transação segura de acordo com a invenção, caracterizado por compreender, pelo menos, um passo de estabelecimento de, pelo menos, um canal de comunicação seguro entre o módulo de segurança e o leitor, que é implementado através das seguintes etapas: — gerar, pelo menos, uma chave de sessão, pelos meios de processamento do leitor, em cooperação com o cartão e, depois, encriptar dados utilizando essa chave de sessão, — obter, pelo leitor, a partir da pastilha eletrónica do cartão, dados representativos de informações relacionadas com o cartão, — transmitir, do leitor para o módulo de segurança, dados representativos de informações relacionadas com o cartão e dados encriptados utilizando a chave de sessão, — gerar, pelo módulo de segurança, a chave de sessão a partir de, pelo menos, uma chave de encriptação do módulo de segurança e dos dados recebidos.

De acordo com uma outra caracteristica, o passo de gerar, pelo menos, uma chave de sessão pelos meios de processamento do leitor, é precedido por um passo de geração (51), pela pastilha eletrónica do cartão, de, pelo menos, um criptograma a partir da chave de encriptação armazenada na pastilha eletrónica e de transmissão desse ou desses criptogramas para o leitor gerando a chave de sessão a partir desse ou desses criptogramas.

De acordo com uma outra caracteristica, o método compreende, pelo menos, um passo de introdução, pelo utilizador do cartão, de, pelo menos, um código de identificação pessoal do utilizador, e de autenticação desse código pela pastilha eletrónica do cartão, permitindo esse passo de introdução/autenticação, pelo menos, um passo de assinatura de dados pela pastilha eletrónica.

De acordo com uma outra caracteristica, o método compreende, pelo menos, um passo de receção e processamento, pelos meios de processamento do leitor, de, pelo menos, um comando de inicialização do canal seguro enviado pelo módulo de segurança, compreendendo um número imprevisível e induzindo a interrogação da pastilha eletrónica pelo leitor, para a obtenção de, pelo menos, um criptograma e os dados representativos de informações relacionadas com o cartão, permitindo este passo gerar a chave de sessão utilizada para estabelecer o canal de comunicação seguro e transmitir para o módulo de segurança, por um lado, os dados representativos de informações relacionadas com o cartão e, por outro lado, os referidos dados encriptados utilizando essa chave de sessão, que compreendem dados relativos ao número imprevisível.

Outro objetivo da presente invenção é superar, pelo menos, alguns dos inconvenientes da técnica anterior ao proporcionar um método permitindo proteger as transações em linha.

Este objetivo é conseguido por um método de transação segura, caracterizado por compreender os passos do método de inicialização de acordo com a invenção e, pelo menos, um passo de transmissão de dados entre o módulo de segurança e o leitor, sob forma encriptada, utilizando a referida chave de sessão, implementado num sistema de transação segura de acordo com a invenção.

De acordo com uma outra caracteristica, o servidor é configurado para exigir do módulo de segurança, em cada passo de transmissão de dados com o leitor, uma encriptação/desencriptação pela referida chave de sessão dos dados transmitidos, sendo o leitor também configurado para encriptar/desencriptar os dados trocados durante a transação.

Outras caracteristicas e vantagens da presente invenção aparecerão mais claramente com a leitura da descrição que se segue, efetuada recorrendo aos desenhos anexos, nos quais: — a figura 1 mostra uma forma de realização do sistema de acordo com a invenção, — a figura 2 mostra uma forma de realização do método de acordo com a invenção — a figura 3 mostra uma forma de realização do método de acordo com a invenção, até ao estabelecimento do canal seguro, — a figura 4 mostra a sequência da forma de realização do método da figura 3, a partir do estabelecimento do canal seguro. A presente invenção refere-se, por um lado, a um sistema e a um método de inicialização de transação segura em linha, devido ao estabelecimento de um canal seguro, tal como descrito abaixo. A presente invenção refere-se, por outro lado, a um sistema e a um método de transação segura em linha, isto é, de transmissões de dados seguros, com base num tal canal seguro. A titulo de exemplos ilustrativos e não limitativos, os dados transmitidos podem dizer respeito a operações permitindo a consulta e a gestão de serviços bancários em linha ("e-banking") e/ou permitindo a subscrição de produtos financeiros em linha ("e-subscription") e/ou permitindo a validação de pedidos de débito destinados a um recetor autorizado, como, por exemplo, com os pagamentos por débito em conta, TIP ("e-billing") e/ou permitindo o pagamento de compras em linha ("e-commerce") utilizando, por exemplo, um protocolo de pagamento seguro na Internet, tal como o protocolo "3-DSecure". A invenção é particularmente vantajosa na medida em que se propõe proteger as transações ao proporcionar um mecanismo resistente à maior parte dos ataques conhecidos e permitindo resolver os problemas de engenharia social. 0 termo "transação" refere-se, no presente pedido, a qualquer tipo de transmissão de dados através de, pelo menos, uma rede de comunicação, sendo essas transmissões protegidas devido à presente invenção. Assim, o termo "transação" pode dizer respeito a uma transação, por exemplo, de tipo bancário (por exemplo, um pagamento em linha, etc.), mas pode, na verdade, referir-se a outros tipos de transmissões de dados (por exemplo, no caso de envio de informações pessoais, em particular, durante a utilização de um cartão de saúde ou outro cartão). Essas "transações" são consideradas, no presente documento, como sendo realizadas entre, pelo menos, um utilizador e, pelo menos, uma entidade designada pelo termo "fornecedor de serviços" (por exemplo, um banco, um organismo privado ou público, etc.), que possui um equipamento (um conjunto de dispositivos, por exemplo) especifico para a implementação da invenção, designado pelo termo "equipamento (4) de fornecedor" (ou "equipamento (4) do fornecedor de serviços"), como descrito de forma detalhada a seguir. 0 fornecedor de serviços terá fornecido aos utilizadores da presente invenção, um cartão (2) dito "seguro" (como explicado abaixo) e um leitor (1) de cartão especifico, para lhes permitir efetuar transações em linha. Diz-se que o cartão (2) e o leitor (1) são "fornecidos" pelo fornecedor de serviços, mas será óbvio a partir da leitura do presente pedido de patente que a invenção não está limitada à forma como os utilizadores os obtiveram, sendo esse termo utilizado para explicar que o fornecedor de serviços conhece os cartões dos utilizadores (por exemplo, através da utilização de, pelo menos, uma base de dados armazenando identificadores de utilizadores e do cartão), como explicado em detalhe abaixo, e possui um equipamento (4) de fornecedor configurado para cooperar com os leitores (1) de cartão durante as transações, como explicado abaixo.

Como mencionado acima, a presente invenção permite vários tipos de transações, tais como, a titulo de exemplos ilustrativos e não limitativos, os conhecidos pelos nomes de "e-banking", "e-subscription", "e-billing" ou "e-commerce". 0 e-commerce utiliza, por exemplo, o protocolo "3D-Secure", que permite autenticar um titular de um cartão de pagamento no caso de compras feitas em sitios da Web e consiste em associar o processo de autorização financeira a uma autenticação em linha com base num modelo compreendendo 3 áreas (área do comprador, ou seja, em geral, a área do comerciante e da empresa que afiliou à rede de pagamento; a área do emissor, isto é, em geral, a área do titular do cartão e da empresa (muitas vezes, o seu banco) que emitiu o seu cartão; a área da interoperabilidade, isto é, em geral, a do operador da rede de pagamentos assegurando a interoperabilidade entre as duas primeiras áreas e garantindo que os fluxos financeiros ligam os pontos que têm que ligar) . Este protocolo é baseado em mensagens enviadas através de comunicações seguras, por exemplo, utilizando protocolos de tipo SSL ("Secure Sockets Layer", de acordo com a terminologia anglo-saxónica) ou TLS ("Transport Layer Security", de acordo com a terminologia anglo-saxónica), que garantem a autenticação do servidor e do cliente por certificados digitais. Deve salientar-se que a presente invenção pode ser compativel com o Programa de Autenticação por Cartão (PAC ou CAP de "Pastilha eletrónica Authentication Program" de acordo com a terminologia anglo-saxónica) , que disponibiliza especificações técnicas para a utilização de cartões bancários inteligentes para a autenticação de utilizadores e de transações bancárias em linha e por telefone. Também foi adotado enquanto senha de autenticação dinâmica (DPA). Os clientes dos bancos que receberam um leitor CAP do seu banco podem inserir o seu cartão bancário no leitor CAP para participar num dos protocolos de autenticação suportados por estas especificações. 0 CAP é uma forma de autenticação utilizando dois fatores de uma vez, na medida em que o cartão inteligente e um PIN válido devem ser apresentados para uma operação ser bem-sucedida, de acordo com vários métodos suportados. No entanto, tal como referido no preâmbulo do presente pedido de patente, os métodos suportados pelas especificações CAP têm a desvantagem de permanecer vulneráveis a determinados ataques, enquanto a presente invenção cumpre os requisitos de segurança do CAP, mas permite fazer com que as transações sejam ainda mais seguras.

Além disso, como mencionado acima, a presente invenção aproveita os cartões inteligentes, aqui designados pelo termo "cartão inteligente seguro", que armazenam, pelo menos, uma chave simétrica de encriptação e compreendem um pastilha eletrónica dotado com capacidades criptográficas utilizando chaves simétricas. Podem ser, em particular, cartões bancários, isto é, cartões inteligentes de pagamento, tais como os conhecidos pelo nome de EMV (de "Europay Mastercard Visa"), permitindo proteger os pagamentos efetuados através da pastilha eletrónica (por exemplo, de tipo ISO 7816) do cartão compreendendo, pelo menos, uma chave de encriptação simétrica. No entanto, a invenção não está limitada a cartões bancários (ou cartão de saúde ou outro) citados no presente documento a titulo de exemplo ilustrativo e não limitativo, na medida em que a invenção requer, apenas, no que se refere ao cartão, que a pastilha eletrónica armazene uma chave simétrica de encriptação e dados relacionados com o cartão, e que possua, pelo menos, capacidades criptográficas simétricas (como por exemplo, devido a, pelo menos, uma aplicação especifica implementada na pastilha eletrónica do cartão), que são aplicadas em resposta a comandos recebidos de um leitor acedendo ao cartão. Deve salientar-se que, em alternativa, é possivel que o leitor e o cartão dialoguem através de uma comunicação sem contacto (não sendo, então, o cartão necessariamente inserido no leitor, mas sendo o acesso executado na mesma pelo leitor). 0 termo "cartão seguro" será utilizado na presente descrição para designar esses tipos de cartões. A presente invenção não requer, por conseguinte, a implantação de novas entidades de encriptação (tais como "dongles", chaves USB de encriptação ou outro dispositivo a conectar a um terminal e armazenando uma chave de encriptação) e prevê a utilização de cartões seguros que permitem uma autenticação mútua e forte entre o equipamento (4) de fornecedor e a pastilha eletrónica (20) do cartão, tal como detalhado abaixo. A invenção pode, por conseguinte, aproveitar cartões já existentes e que já têm os meios necessários para a sua implementação (no que se refere ao cartão: capacidades de criptografia simétrica, chave de encriptação e dados relacionados com o cartão), como, por exemplo, os cartões bancários de tipo EMV. Deve salientar-se que, no caso de cartões seguros obrigando à introdução de um código PIN (como os cartões EMV), se obtém, mesmo, uma autenticação forte e mútua entre o fornecedor e o próprio utilizador. Devido aos meios utilizados na presente invenção, o utilizador tem a garantia de efetuar uma transação com o seu fornecedor de serviços e este último também tem a garantia de efetuar uma transação com o seu cliente (o utilizador ou, pelo menos, um utilizador autorizado, desde que o utilizador não tenha deixado roubar o seu cartão e o código PIN associado). A presente invenção obriga à utilização de um leitor (1) de cartão seguro, compreendendo meios (12) de processamento de dados configurados para comunicar com a pastilha eletrónica (20) do cartão (2), particularmente para obter, da pastilha eletrónica (20), assinaturas de dados para estabelecer o canal seguro e para realizar transações seguras em linha. Além disso, estes meios (12) de processamento de dados são configurados para executar operações criptográficas sobre os dados fornecidos pela pastilha eletrónica e para transmitir para o equipamento (4) de fornecedor os dados encriptados através de um canal (CS) seguro. O leitor (1) é (ou os seus meios de processamento são) além disso, configurado(s) para o estabelecimento de um canal (CS) de comunicação seguro (ou "túnel seguro") com, pelo menos, um módulo (ou dispositivo) de segurança do equipamento (4) de fornecedor em modo conectado (isto é, durante uma comunicação com o equipamento de fornecedor por meio de, pelo menos, uma rede de comunicação), por exemplo, de acordo com um algoritmo 3DES, por exemplo, em modo CBC, e com uma chave de sessão (Kses) gerada anteriormente. Como mencionado anteriormente, a presente invenção utiliza uma das funcionalidades dos cartões seguros permitidas por, pelo menos, uma chave de encriptação armazenada na pastilha eletrónica e fornecida pelo (ou conhecida do) fornecedor de serviços. Deve salientar-se que o algoritmo de cifragem 3DES (também conhecido como "Triple DES"), que é um algoritmo de cifragem simétrica encadeando 3 aplicações sucessivas do algoritmo DES (de "Data Encryption

Standard", de acordo com a terminologia anglo-saxónica, que é um algoritmo de cifragem por bloco) no mesmo bloco de dados de 64 bits com 2 ou 3 chaves DES diferentes, é citado no presente documento apenas a titulo de exemplo ilustrativo e não limitativo. Da mesma forma, o modo CBC ("Cipher Block Chaining" de acordo com a terminologia anglo-saxónica ou "encadeamento de blocos"), que consiste em aplicar a cada bloco um 'OU exclusivo' com a cifragem do bloco anterior, antes de ser, ele próprio, cifrado, e que utiliza um vetor de inicialização para fazer com que cada mensagem seja única, é citado no presente documento apenas a titulo de exemplo ilustrativo e não limitativo. De facto, será compreendido, através da leitura do presente pedido, que os métodos de encriptação utilizados podem evoluir em função das normas e que algumas formas de realização da presente invenção aproveitam seguranças já implantadas nos cartões seguros.

Os sistemas de inicialização e de transação segura em linha implementam, de um modo bem conhecido, pelo menos, uma rede (RC) de comunicação. Por exemplo, essa rede pode ser de tipo Internet. Em várias alternativas, a invenção pode implementar várias redes. Além disso, as redes envolvidas podem ser de vários tipos, como, por exemplo, uma rede de telefonia móvel (como, por exemplo, as redes de terceira geração), permitindo uma comunicação de débito elevado com terminais, tais como, por exemplo, telefones móveis ou computadores dotados com meios de comunicação adequados, etc. Mais tipicamente, pode tratar-se de uma rede de tipo Internet, por exemplo, com fios.

Também de um modo bem conhecido, as transações em linha são, geralmente, efetuadas a partir de um terminal (3), tal como um computador, por exemplo, mas podem ser efetuadas a partir de outros tipos de terminais, tais como telefones móveis compreendendo meios de comunicação e, pelo menos, uma aplicação de navegação na rede, conhecida com o nome de navegador (ou "browser" de acordo com a terminologia anglo-saxónica. Deve salientar-se que, no presente documento, um tal terminal é designado pelo termo "terminal de utilizador", mas é óbvio que um tal terminal pode ser propriedade de qualquer entidade, que pode corresponder a diversos tipos de terminais e que essa designação não deve ser interpretada de modo limitativo. Em geral, é evidente que a navegação através de uma rede de tipo Internet pode ser realizada a partir de vários tipos de terminais e a invenção não deve ser limitada aos exemplos não limitativos dados no presente documento a titulo ilustrativo. Em contrapartida, a presente invenção, ao exigir a utilização de um leitor (1) de cartão seguro, implica que o terminal (3) possa incluir um tal leitor diretamente no terminal ou esteja ligado a esse leitor por intermédio de, pelo menos, uma interface de conexão adequada (por exemplo, mini-USB, como frequentemente encontrado, até mesmo em terminais móveis) e unidades de controlo ("drivers", de acordo com a terminologia anglo-saxónica) permitindo o controlo de um tal leitor, sendo os detalhes referentes ao diálogo entre o terminal e o leitor em função das transmissões de dados na rede (através do navegador) disponibilizados mais adiante na presente descrição. Nenhum detalhe será disponibilizado no presente documento sobre as modalidades fisicas de terminais e leitores (nem sobre as unidades de controlo e outros meios utilizados), na medida em que o perito na especialidade compreenderá, através da leitura da presente invenção, quais as modalidades possíveis sem se divergir do espirito da invenção. Além disso, a invenção também proporciona formas de realização permitindo dispensar um terminal (3) ao qual o leitor (1) deve ser conectado. Nestas formas de realização, o leitor (1) está dotado com meios de comunicação em, pelo menos, uma rede (RC) de comunicação. Este leitor (1), dito "comunicante", pode, em algumas alternativas, integrar, pelo menos, uma aplicação permitindo navegar na rede de comunicação, para permitir que o utilizador se conecte, pelo menos, ao equipamento (4) de fornecedor. Versões melhoradas permitirão a conexão a outros servidores (por exemplo, sitios comerciais, etc.). Em outras alternativas, o leitor (1) não será dotado com um navegador (na sua definição comum de suporte lógico de navegação), mas será configurado para se poder conectar diretamente ao equipamento (4) de fornecedor, por exemplo, através de meios de comunicação (por exemplo, meios de comunicação sem fios, como numa rede de telefonia móvel) e utilizando meios de armazenamento armazenando dados que lhe permitam conectar-se a esse equipamento. Tais dados podem, por exemplo, compreender, pelo menos, um URL ("Universal Resources Locator") indicando o endereço de, pelo menos, um servidor do equipamento (4) de fornecedor, possivelmente com um identificador e senha. Esses dados podem, por exemplo, ser armazenados nos meios de armazenamento do próprio leitor (1) ou na pastilha eletrónica (20) do cartão (2) seguro (e extraidos pelo leitor para a comunicação com o fornecedor). O perito na especialidade irá, portanto, compreender, através da leitura do presente pedido de patente, que a invenção pode, na verdade, utilizar um dispositivo, tal como um leitor de cartão seguro, que pode ser conectado a um terminal de comunicação ou formar, o próprio, um tal terminal de comunicação, e que, no caso em que o leitor forma, ele próprio, um terminal de comunicação, o navegador e o módulo de porta de acesso (descritos mais adiante no presente pedido de patente) podem ser omissos, uma vez que estes últimos são utilizados, respetivamente, para se conectarem ao equipamento (4) de fornecedor e controlar a transmissão dos dados do navegador do terminal para o leitor. No entanto, em algumas formas de realização, o navegador e o módulo de porta de acesso podem ser, ainda, implementados neste tipo de leitor de comunicação, para permitir mais funcionalidades (especialmente se o navegador for um verdadeiro suporte lógico de navegação que requer a integração de um módulo de porta de acesso, como descrito no presente pedido de patente).

Por outro lado, sabe-se, também, que as transações em linha implementam, pelo menos, um equipamento (4) de um fornecedor de serviços (por exemplo, um banco ou um organismo privado ou público) compreendendo, pelo menos, um servidor (40) configurado para gerir as comunicações e, em particular, as transações, com os navegadores (N) de terminais (3) . As transações em linha, por exemplo, tais como as indicadas a titulo de exemplo ilustrativo e não limitativo na apresentação do campo técnico ("e-banking", etc.), requerem, de um modo geral, a conexão do utilizador (através do navegador de um terminal ou de acordo com as alternativas acima descritas, através do leitor de comunicação) o servidor (40), para permitir uma autenticação do utilizador e uma autorização da transação pelo servidor (40). Além disso, o equipamento (4) de fornecedor compreende, em geral, na técnica anterior, também, pelo menos, um módulo (41) de segurança, que é configurado para desencriptar e verificar as assinaturas de transações fornecidas pelo cartão (podendo este módulo ser, por exemplo, implementado em, pelo menos, um servidor do equipamento (4) de fornecedor). Este módulo (41) de segurança pode, a titulo de exemplo ilustrativo e não limitativo, compreender, por exemplo, como conhecido no setor bancário, um "equipamento criptográfico inviolável", que poderia ser, por exemplo, um equipamento conhecido com o nome de HSM (de "Hardware Security Module", segundo a terminologia anglo-saxónica) , permitindo operações de desencriptação de assinaturas de transações e de verificação dessas assinaturas. Em geral, um servidor do equipamento (4) de fornecedor pode armazenar, possivelmente, os dados relativos às transações e/ou à sua encriptação. De um modo convencional, o equipamento (4) de fornecedor pode compreender um primeiro servidor, denominado frontal (como mostrado na figura 1), ao qual os utilizadores se conectam para realizar transações, e um segundo servidor, denominado servidor (40) de operações, gerindo as sessões de conexão de utilizadores e as trocas de dados necessárias de acordo com as transações pedidas (por parte do utilizador ou de um servidor de um sitio comercial, por exemplo), ao transmitir os dados sensíveis para o módulo (41) de segurança para cifragem/decifragem. O perito na especialidade irá, por conseguinte, compreender que o equipamento (4) de fornecedor pode compreender, pelo menos, um servidor (40) (por exemplo, um único servidor que execute as funções do servidor frontal e do servidor de operações) e, pelo menos, um módulo (41) de segurança (por exemplo, "equipamento criptográfico inviolável", por exemplo de tipo HSM), implementado no mesmo servidor ou (como mostrado na figura 1) em, pelo menos, um dispositivo diferente.

Em algumas formas de realização, o leitor (1) e o equipamento (4) de fornecedor são associados por meio de, respetivamente, meios de comunicação, implementados diretamente no leitor ou através de um terminal (3), por exemplo, utilizando um navegador (N) e meios de comunicação de, pelo menos, um servidor (40), através de uma comunicação segura de acordo com um protocolo de tipo SSL/TLS, na qual é aberto o canal (CS) seguro. Sabe-se, neste campo, que as conexões dos utilizadores aos servidores do ou dos seus fornecedores de serviços (por exemplo, um banco) passam por conexões seguras (por exemplo, de acordo com o protocolo https). A presente invenção permite a utilização de protocolos de segurança, por exemplo, de tipo SSL/TLS, para proteger a sessão de comunicação segura, mas também permite criar um canal (CS) seguro nesta sessão para proteger, ainda mais, as informações sensíveis trocadas, por exemplo, para permitir resistir, em particular, aos ataques de tipo "man in the middle" ou "man in the browser". Em outras formas de realização, a comunicação com o equipamento (4) de fornecedor pode fazer-se de acordo com outros tipos de protocolos, em particular, protocolos não seguros, dado que o estabelecimento do canal (CS) seguro é realizado desde o inicio da comunicação para que não haja dados sensíveis a transitar "em claro" na rede. Por exemplo, a partir do momento em que o leitor (1) é ativado (por exemplo, quando é conectado a um terminal de comunicação ou quando acede ao cartão), é associado (através dos seus meios de comunicação ou dos do terminal) com o equipamento (4) de fornecedor através da rede (RC) de comunicação (por exemplo, por meio de um URL armazenado em meios de armazenamento e extraido pelo leitor) para estabelecer o canal seguro.

Por conseguinte, compreende-se que os sistemas de inicialização e de transação segura em linha, através de, pelo menos, uma rede (RC) de comunicação, compreendem, pelo menos, um leitor (1) de cartão (2) seguro, que comunica (por exemplo, através de um terminal (3) compreendendo meios (30) de processamento de dados executando, pelo menos, um navegador (N) configurado para comunicar através da referida rede (RC) (ou diretamente utilizando meios de comunicação), com, pelo menos, um equipamento (4) de um fornecedor de serviços compreendendo, pelo menos, um servidor (40) configurado para gerir transações com leitores (1) ou navegadores (N) de terminais (3) de utilizadores, através da troca de dados representativos de transações e, pelo menos, um módulo (41) de segurança configurado para proteger essas transações (em cooperação com o leitor).

Mais particularmente, os sistemas de acordo com a invenção são configurados para estabelecer um canal (CS) seguro entre o leitor (1) de cartão (2) seguro e o módulo (41) de segurança utilizando, pelo menos, uma chave (CF) de encriptação e dados (D_chip) representativos de, pelo menos, uma informação relacionada com o cartão, armazenados na pastilha eletrónica do cartão seguro. Essa chave de encriptação corresponde a um "segredo partilhado" pelo cartão e pelo equipamento (4) de fornecedor e é utilizado para gerar, em ambos os lados, uma chave (Kses) de sessão permitindo encriptar dados de transação transmitidos através do canal seguro. Assim, o módulo (41) de segurança (ou servidor) e o leitor (1) utilizam a mesma chave de sessão para encriptar/desencriptar os dados que trocam entre si para a transação. Por conseguinte, compreende-se que devido a essas encriptações/desencriptações realizadas em ambos os lados, um canal (CS) seguro é estabelecido entre as duas entidades para permitir que não haja violação dos dados sensíveis. Estes dados (D_chip) representativos de informações relacionadas com o cartão correspondem a dados "públicos", porque não são sensíveis e podem, portanto, transitar sem encriptação através da rede. Estes dados (D_chip) públicos são enviados para o equipamento (4) de fornecedor para lhe permitir identificar o cartão (2) e executar as mesmas operações criptográficas que o cartão (2) e o leitor (1) . No presente documento, o termo "estabelecimento de um canal seguro" significa que o equipamento (4) de fornecedor (em particular, o módulo (41) de segurança) e o leitor (1) se associam para calcular uma mesma chave (Kses) de sessão que utilizam para encriptar/desencriptar os dados de transações trocados posteriormente, que transitam pelo canal (CS) seguro. A presente invenção refere-se, por conseguinte, a um método e a um sistema de inicialização de transações seguras com base no estabelecimento de um canal (CS) seguro para as transações. Depois de estabelecido esse canal (CS), a transação é inicializada e pode prosseguir através do canal seguro. A presente invenção também se refere, por conseguinte, a um método e a um sistema de transações seguras com base numa tal inicialização através do estabelecimento de um canal (CS) seguro. A presente invenção proporciona, assim, sistemas resistentes a diversos tipos de ataques conhecidos ao utilizar, de um modo vantajoso, os mecanismos de segurança já implantados nos cartões seguros, mas explorando-os remotamente em associação com o equipamento do fornecedor de serviços por intermédio de, pelo menos, um canal (CS) seguro permitindo assegurar a segurança das transações, ou mesmo a sua total confidencialidade em determinadas formas de realização abaixo descritas. Com efeito, em vez de propor uma simples assinatura das transações pelo cartão (2) (utilizando o leitor), realizada no final da transação para a validar, como na técnica anterior (particularmente em sistemas de tipo CAP) propõe-se inicializar a transação através do estabelecimento de um canal (CS) seguro com base nos mesmos mecanismos criptográficos, mas cuja utilização é modificada para a implementação da presente invenção. A utilização destes mecanismos criptográficos é modificada, em particular, porque o ou os criptogramas gerados pelo cartão são utilizados pelo leitor (1) para gerar uma chave (Kses) de sessão, por exemplo, concatenando 2 criptogramas fornecidos pelo cartão (2) . Por outro lado, o módulo de segurança também é, no presente documento, configurado para gerar a mesma chave (Kses) de sessão que será, posteriormente, utilizada pelo mesmo e pelo leitor para encriptar/desencriptar os dados que têm que trocar entre si para a transação propriamente dita. Em contrapartida, na técnica anterior, particularmente em sistemas CAP, o cartão envia simplesmente um criptograma no final da transação para o módulo (41) de segurança, que, simplesmente, verifica se o criptograma está correto. Além disso, a utilização desses mecanismos é modificada durante as transações, porque as operações de encriptação/desencriptação são realizadas em ambos os lados para os envios de dados através do canal (CS) seguro, tanto do servidor para o leitor como do leitor para o servidor. Na técnica anterior, em particular nos sistemas CAP, o servidor não encripta dados a enviar para o cartão ou para o leitor. É, assim, claro que a encriptação pelo módulo de segurança dos dados enviados para o leitor que os desencripta é uma utilização vantajosa e inovadora dos mecanismos em que se conhece apenas uma parte. Além disso, o estabelecimento do canal seguro assenta na troca de informações entre o cartão (utilizando o leitor) e o servidor. Quando todos os dados relativos à transação são introduzidos, processados e/ou exibidos apenas no leitor (e não no terminal ao qual o leitor pode ser conectado), a invenção permite uma total confidencialidade dos dados, além da segurança proporcionada pelo canal (CS) seguro, como explicado em detalhe abaixo. 0 sistema de inicialização de acordo com a invenção compreende, pelo menos, um leitor (1) de cartão inteligente acedendo ao equipamento (4) de fornecedor através da referida rede (RC) de comunicação e compreendendo meios (12) de processamento configurados para, por um lado, trocar dados com, pelo menos, um pastilha eletrónica (20) de, pelo menos, um cartão (2) seguro, a fim de obter da pastilha eletrónica (20) e transmitir para o módulo (41) de segurança dados (D_chip), denominados públicos, representativos de, pelo menos, uma informação relacionada com o cartão (2) e, por outro lado, gerar, em cooperação com a referida pastilha eletrónica (20), pelo menos, uma chave (Kses) de sessão, e transmitir para o módulo (41) de segurança dados encriptados utilizando essa chave (Kses) de sessão. O módulo (41) de segurança está configurado para calcular a referida chave (Kses) de sessão a partir dos referidos dados (D_chip) públicos recebidos e de, pelo menos, uma chave (CF) de encriptação. Este cálculo da chave (Kses) de sessão pelo leitor (1) e pelo módulo (41) de segurança permite a inicialização da transação através do estabelecimento de um canal (CS) de comunicação seguro, em que os dados representativos da transação podem transitar de forma encriptada pela referida chave (Kses) de sessão.

Para calcular a chave (Kses) de sessão a partir dos dados recebidos, o módulo (41) de segurança pode executar os mesmos cálculos que o leitor (1) e o cartão (2). Por exemplo, o leitor pode gerar a chave de sessão a partir de, pelo menos, um criptograma (ARQC, AAC) gerado pela pastilha eletrónica (20) do cartão (2), como descrito no presente pedido de patente, e o módulo (41) de segurança pode, também, gerar, pelo menos, um criptograma (ARQC, AAC) e, em seguida, calcular a chave (Kses) de sessão desse ou desses últimos. O sistema de acordo com algumas formas de realização será, agora, descrito recorrendo à figura 1. Deve salientar-se que as várias formas de realização descritas no presente pedido de patente podem ser combinadas entre si, salvo indicação expressa em contrário ou se forem incompatíveis entre si e/ou se a sua combinação não funcionar para o sistema ou método. O sistema de transação de acordo com a presente invenção compreende, por conseguinte, pelo menos, um leitor (1) de cartão inteligente conectado ao terminal (3) de utilizador e compreendendo meios (12) de processamento configurados, em particular, para trocar dados com um cartão (2) seguro de um utilizador ao qual o leitor acedeu (devido ao facto de o cartão ser inserido no leitor ou por meio de leitura remota no caso de cartões e leitores ditos "sem contacto") . O leitor (1) pode, também, compreender meios (10) de exibição e meios (11) de introdução de dados (tais como um ecrã e uma pluralidade de teclas, ou, ainda, um ecrã tátil) para permitir ao utilizador verificar as informações apresentadas e introduzir ou validar os dados, de acordo com várias formas de realização. Os meios (12) de processamento do leitor (1) também estão configurados para proporcionar um processamento local de dados, como, por exemplo, operações de cifragem (encriptação) ou decifragem (desencriptação) de dados representativos de uma transação, por exemplo, em função de mensagens trocadas com o cartão ou com o equipamento (4) de fornecedor. Deve salientar-se que o cartão (2) inteligente com pastilha eletrónica (20) é denominado "de um utilizador" e é conhecido no campo que pertencem exclusivamente a um utilizador. No entanto, também se conhecem cartões seguros, por exemplo, de tipo EMV, tendo mais titulares, e esta designação não deve ser interpretada de forma limitativa, mas de forma a permitir a identificação (completamente fiável em alguns casos) do utilizador que o utiliza como um utilizador autorizado (através da verificação do código PIN em particular) . Os cartões (2) seguros são conhecidos da técnica anterior e compreendem, pelo menos, um pastilha eletrónica (20) permitindo assinar transações, particularmente depois de o seu utilizador ter sido autenticado por validação de um código de identificação pessoal válido (código PIN, de "Personal Identification Number", de acordo com a terminologia anglo-saxónica). Nenhum detalhe será, assim, dado sobre o funcionamento destes cartões para além dos passos mais específicos na implementação da presente invenção.

Os meios (12) de processamento do leitor (1) de um cartão seguro estão, ainda, configurados para gerar, em cooperação com a pastilha eletrónica (20) do cartão (2), pelo menos, uma chave (Kses) de sessão. Para gerar uma chave (Kses) de sessão, o leitor (1) obtém do cartão (2) um determinado número de dados que são detalhados abaixo de acordo com várias formas de realização. Em particular, a chave (Kses) de sessão é gerada pelo leitor (1) em cooperação com a pastilha eletrónica (20), que armazena, pelo menos, uma chave (CF) de encriptação e dados (D_chip) públicos. Os meios (12) de processamento do leitor (1) podem, por exemplo, executar, pelo menos, uma aplicação específica para a implementação da invenção (em particular, para o estabelecimento do canal seguro utilizando as encriptações/desencriptações de dados). Em algumas formas de realização, os meios (12) de processamento do leitor (1) estão configurados para receber do módulo (41) de segurança e processar, pelo menos, um comando de estabelecimento (inicialização) do canal (CS) seguro, induzindo a interrogação da pastilha eletrónica (20) pelo leitor (1) para a obtenção de, pelo menos, um criptograma (AAC, ARQC) e os dados (D_chip) representativos de informações relacionadas com a cartão (2), o que permite aos meios (12 ) de processamento do leitor (1) gerar a chave (Kses) de sessão servindo para estabelecer o canal (CS) de comunicação seguro e transmitir para o módulo (41) de segurança, por um lado, os dados (D_chip) representativos de informações relacionadas com o cartão (2) e, por outro lado, os referidos dados encriptados utilizando essa chave (Kses) de sessão. Em algumas formas de realização, este comando de estabelecimento do canal pode compreender um número imprevisível (UN), aumentando a segurança, como detalhado abaixo. Neste caso, os dados encriptados pelo leitor (1) utilizando a chave (Kses) de sessão incluirão dados relativos a esse número imprevisível (UN) . Por exemplo, o leitor gera um número (Nses) de sessão que pode, por exemplo, corresponder a uma concatenação desse número imprevisível (UN) com um contador de transações (conhecido como ATC na área bancária) e pode encriptar esse número sessão (Nses) pela chave (Kses) de sessão para enviá-lo para o módulo (41) de segurança. Ao estabelecer o canal (CS) seguro, o leitor (1) pode solicitar a inserção do código PIN pelo utilizador, a fim de autenticá-lo para condicionar a geração de um ou de mais criptogramas. Em resposta ao comando de estabelecimento do canal, o leitor envia para o equipamento (4) de fornecedor, pelo menos, dados (D chip) representativos de informações relacionadas com o cartão (2) . Estes dados podem ser enviados sem encriptação prévia pelo leitor (1), como mencionado acima. O módulo (41) de segurança está configurado para calcular a chave (Kses) de sessão a partir de, pelo menos, uma chave (CF) de encriptação e de dados (D_chip) públicos, que lhe são transmitidos pelo leitor (1), que os obteve a partir da pastilha eletrónica (20) do cartão (2) . Essas trocas de dados permitem, assim, a inicialização da transação, uma vez que essa chave (Kses) de sessão permite o estabelecimento do canal (CS) seguro entre o módulo (41) de segurança e o leitor (1) devido às encriptações/desencriptações de dados trocados entre eles. Os dados trocados para permitir a transação (por exemplo, para definir vários parâmetros da transação, para validar a transação, etc.) são, então, encriptados desde o inicio (pelo leitor e pelo módulo de segurança), ao contrário de algumas soluções da técnica anterior (em particular, o CAP), em que apenas a validação da transação é baseada numa assinatura pelo próprio cartão (2) (e não há uma encriptação em ambos os lados pelo módulo de segurança e pelo leitor).

Em algumas formas de realização, a pastilha eletrónica (20) do cartão (2) é, de facto, configurado para gerar, a partir da chave (CF) de encriptação, pelo menos, um criptograma (AAC, ARQC) utilizado pelos meios (12) de processamento do leitor (1) para gerar a chave (Kses) de sessão servindo para o estabelecimento do canal (CS) seguro. O ou os criptogramas gerados pelo cartão podem ser, por exemplo, do tipo dos criptogramas conhecidos pelo nome de AAC (de "Application Authentication Cryptogram", de acordo com a terminologia anglo-saxónica) e/ou ARQC (de "Authorization ReQuest Cryptogram" de acordo com a terminologia anglo-saxónica) convencionalmente conhecidos na área. Em algumas formas de realização, a pastilha eletrónica pode gerar dois tipos de criptogramas e é a sua combinação que irá permitir que o leitor (1) gere a chave (Kses) de sessão (por exemplo, por uma concatenação dos dois criptogramas).

Em algumas formas de realização, o módulo (41) de segurança utiliza, pelo menos, uma chave, denominada chave mãe (CM) que serviu para a geração de chaves (CF) de cartões (2) seguros fornecidos pelo fornecedor de serviços, denominadas chaves filhas (CF), podendo cada um dos cartões (2) fornecidos ser identificado a partir de, pelo menos, uma informação contida nos dados (D_chip) públicos.

Nestas formas de realização, os meios (12) de processamento do leitor (1) transmitem para o módulo (41) de segurança os dados (D_chip) públicos para lhe permitir encontrar a chave (CF) de encriptação a utilizar para calcular a chave (Kses) de sessão e, assim, permitir a encriptação/desencriptação de dados representativos da transação transmitidos através do canal (CS) seguro. Num exemplo particular, o módulo (41) de segurança utiliza um algoritmo, por exemplo, de tipo 3DES, para gerar as chaves (CF) de encriptação a partir da chave mãe (CM) e de dados (D_chip) públicos. Um tal algoritmo permite, por conseguinte, que o módulo (41) de segurança, através dos dados (D_chip) públicos que recebe do leitor, encontre a chave filho a utilizar a partir da chave mãe (CM) . Para maior segurança, deve salientar-se que a chave mãe (CM) utilizada pelo módulo (41) de segurança pode ser armazenada de forma encriptada por, pelo menos, uma chave de encriptação, denominada chave (SK) de segredo. Também se deve salientar que a chave (CF) de encriptação só está presente furtivamente no módulo (41) de segurança durante o cálculo da chave (Kses) de sessão.

Em algumas formas de realização correspondentes a uma alternativa às formas de realização do parágrafo anterior, o equipamento (4) do fornecedor de serviço compreende, pelo menos, uma base de dados que armazena as chaves (CF) de encriptação dos cartões (2) seguros fornecidos pelo fornecedor de serviços, acedendo o módulo (41) de segurança a essa base de dados para encontrar, com base nos dados (D_chip) públicos recebidos do leitor (1) de cartões inteligentes, a chave (CF) a utilizar para calcular a chave (Kses) de sessão. Para aumentar a segurança, deve salientar-se, aqui, que as chaves (CF) de encriptação armazenadas no módulo (41) de segurança podem ser armazenadas de forma encriptada por, pelo menos, uma chave de encriptação, denominada chave (SK) de segredo.

Em algumas formas de realização, os dados (D_chip) representativos de informações relacionadas com o cartão (2) podem ser representativos de, pelo menos, uma informação que permita, pelo menos, a identificação do cartão utilizado para a transação. De acordo com várias formas de realização, esses dados também podem representar, pelo menos, uma informação relacionada com as posições (ou valores) de contadores. Esses dados podem ser, por exemplo, tais como os atualmente conhecidos na área dos cartões bancários, incluindo um número de conta principal (PAN, de "Primary Account Number"), que pode ser utilizado pelo módulo (41) de segurança para encontrar a chave filha (a partir da chave mãe ou entre as chaves filhas armazenadas, de acordo com os 2 exemplos descritos nos 2 parágrafos anteriores). Outros dados utilizáveis pelo módulo (41) de segurança na presente invenção, para encontrar o ou os criptogramas, são dados conhecidos com o identificador IAD (de "Issuer Authentication Data" de acordo com a terminologia anglo-saxónica), e podem incluir dados representativos de informações conhecidos pelas siglas de KDI ("Key Derivation Index", de acordo com a terminologia anglo-saxónica), CVN (de "Cryptogram Version Number" de acordo com a terminologia anglo-saxónica) e CVR (de "Card Verification Result", de acordo com a terminologia anglo-saxónica). Além disso, esses dados também podem incluir dados conhecidos com os nomes anglo-saxónicos de "Card Risk Management Data Object List 1" (CD0L1), "Card Risk Management Data Object List 2" (CD0L1), "Application Transaction Counter" (ATC) e "Primary Account Number Sequence" (PSN). Deve salientar-se que os exemplos de dados representativos de informações relacionadas com o cartão que são dados no presente documento não são limitativos e representam apenas exemplos selecionados, em particular, no setor bancário, para detalhar a forma como o módulo (41) de segurança pode calcular a chave de sessão permitindo a encriptação dos dados que passam através do canal (CS) seguro.

Todos ou parte destes dados (D_chip) do cartão (2) permitem que o módulo (41) de segurança calcule a chave (Kses) de sessão. Assim, de acordo com várias formas de realização, os dados (D chip) públicos representam, pelo menos, uma informação relacionada com o cartão e permitem, pelo menos, a identificação do cartão (2) . Por exemplo, o módulo (41) de segurança está configurado para: — encontrar a chave (CF) de encriptação a utilizar devido a, pelo menos, uma parte destes dados (D_chip), por exemplo, o PAN do cartão (2) que lhe é transmitido pelo leitor (1) — gerar, pelo menos, um criptograma (AAC, ARQC) a partir de, pelo menos, uma parte destes dados (D_chip) e da chave (CF) de encriptação, por exemplo, executando, pelo menos, uma aplicação como a utilizada pelo cartão para gerar o ou os criptogramas, — calcular a chave (Kses) de sessão da mesma forma que o leitor (1) a partir do ou dos criptogramas (AAC, ARQC), por exemplo, através de uma aplicação, pelo menos parcialmente, equivalente à do leitor.

Em algumas formas de realização, o estabelecimento do canal (CS) seguro é iniciado pelo equipamento (4) de fornecedor (quando o leitor (1) é posto em contacto com este ou quando um pedido de transação é recebido por este último). Por exemplo, quando os cartões (2) compreendem várias aplicações para gerar criptogramas (o que permite aumentar o nivel de segurança), o equipamento (4) de fornecedor (o servidor (40) de operações ou o módulo (41) de segurança) pode enviar um comando de inicialização do canal (CS) seguro para o leitor (1), especificando, pelo menos, uma aplicação a utilizar para gerar os criptogramas, utilizando, pelo menos, um identificador de aplicação (AID de "Application Identifier" de acordo com a terminologia anglo-saxónica). Sabe-se que os pastilha eletrónicas (20) dos cartões (2) seguros armazenam por vezes, pelo menos, uma lista dando uma ordem de prioridade às suas aplicações. O identificador de aplicação permite que a pastilha eletrónica só utilize as aplicações nessa ordem, mas de acordo com o que lhe é indicado pelo equipamento (4) de fornecedor. Numa alternativa, o equipamento (4) de fornecedor pode armazenar as mesmas listas e o identificador de aplicação transmitido pode, por conseguinte e simplesmente, indicar o número da aplicação na lista. Noutras alternativas mais simples, as listas do equipamento (4) de fornecedor permitem dispensar um tal identificador de aplicação. Em outras formas de realização, o canal (CS) seguro poderia ser iniciado pelo leitor (1), que transmite para o equipamento (4) de fornecedor um tal identificador de aplicação que lhe é fornecido pelo cartão (2) quando gera, pelo menos, um criptograma ou que tenha utilizado para indicar ao cartão que aplicação utilizar para gerar o ou os criptogramas. Deve salientar-se que os mesmos mecanismos para identificar a aplicação podem ser utilizados para informar o leitor sobre a aplicação que deve ser utilizada para gerar a chave de sessão (no caso em que possuísse várias aplicações para essa função) ou para informar o equipamento (4) de fornecedor sobre a aplicação que utilizou.

Algumas formas de realização incluem um mecanismo permitindo aumentar ainda mais a segurança de encriptação. Este mecanismo baseia-se num número imprevisível (UN) mencionado acima, que é gerado pelo equipamento (4) de fornecedor (pelo servidor (40) de operações ou pelo módulo (41) de segurança), durante o estabelecimento do canal (CS) seguro. Este número imprevisível (UN) é transmitido para o leitor (1) para formar um valor aleatório a partir do qual irá ser gerada a chave (Kses) de sessão. Numa alternativa, o número imprevisível (UN) pode ser gerado pelo cartão (2) ou leitor (1), ou ser mesmo introduzido pelo utilizador no leitor (1) e transmitido para o equipamento (4) de fornecedor, mas a segurança é melhorada quando é o servidor que o envia para o leitor. Em algumas formas de realização combinando as formas de realização ou alternativas supracitadas, de modo a aumentar ainda mais o nivel de segurança, tanto o número imprevisível (UN) como o identificador de aplicação vão ser transmitidos durante o estabelecimento (inicialização) do canal (CS) seguro (seja por iniciativa do leitor ou do fornecedor).

Por conseguinte, deve compreender-se que, em algumas formas de realização particularmente seguras, o leitor (1) pode pedir aa pastilha eletrónica (20) do cartão para gerar um primeiro criptograma (por exemplo, ARQC) especificando um número imprevisível (UN) . A pastilha eletrónica (20), em seguida, reenvia um primeiro criptograma, por exemplo, com um contador de transação (ATC, por exemplo) e com os dados de tipo IAD (por exemplo, DKI, CVN e CVR). O leitor pode, então, pedir aa pastilha eletrónica (20) do cartão para gerar um segundo criptograma (por exemplo, AAC) especificando, por exemplo, o número imprevisível (UN) novamente. A pastilha eletrónica (20), em seguida, reenvia um segundo criptograma, por exemplo, com um contador de transação (ATC, por exemplo) e com os dados de tipo IAD (por exemplo, DKI, CVN e CVR). O leitor (1) pode, então, gerar a chave (Kses) de sessão concatenando os primeiro e segundo criptogramas.

Por outro lado, em algumas formas de realização, o leitor (1) está configurado para gerar um número (Nses) de sessão. Este número (Nses) de sessão está relacionado com o número imprevisível (UN) e o contador de transações (por exemplo, ATC) associado com um identificador do utilizador do cartão (2) . Por conseguinte, o leitor (1) gera o número (Nses) de sessão pela combinação do número imprevisível (UN) com o contador de transações (por exemplo, através de uma concatenação).

Nestas formas de realização, depois de calculada a chave de sessão, o leitor pode transmitir número (Nses) de sessão para o equipamento (4) de fornecedor, numa forma encriptada pela chave (Kses) de sessão. Este número (Nses) de sessão, em seguida, permite que o equipamento (4) de fornecedor identifique o leitor (1) com o qual decorrem as transações. 0 servidor (40) de operações pode utilizar este número (Nses) de sessão para rastrear as operações realizadas. Por exemplo, o servidor (40) de operações pode solicitar encriptações/desencriptações ao módulo de segurança ao indicar-lhe o número de sessão. Além disso, o equipamento (4) de fornecedor pode ser configurado de modo a gerar um número (Nseq) de sequência associado a cada transação e incrementado a cada comando enviado para o leitor (1). Assim, é mantido um registo de cada ordem (Nseq) para cada operação (Nses) . Os dados que passam através do canal seguro podem ser sempre acompanhados por um número (Nses) de sessão, um número (Nseq) de sequência e serem encriptados pela chave (Kses) de sessão.

Depois de estabelecido o canal (CS) seguro, o leitor (1) pode dialogar com o equipamento (4) de fornecedor de forma segura e aceder ao cartão (2) para obter vários tipos de dados. Em algumas formas de realização, os meios (12) de processamento do leitor (1) estão configurados para receber, pelo menos, uma mensagem encriptada solicitando a interrogação da pastilha eletrónica (20) a partir do equipamento (4) de fornecedor e desencriptar essa mensagem utilizando a chave (Kses) de sessão, de modo a enviar para o cartão (2), pelo menos, um comando APDU de interrogação da pastilha eletrónica (20).

Em geral, o leitor está configurado para responder a ordens ou comandos (por exemplo, através dessas mensagens encriptadas) enviados pelo equipamento (4) de fornecedor (por exemplo, o servidor (40) de operações). Estes comandos podem dizer respeito, como exemplos ilustrativos e não limitativos, a: — um pedido de confirmação da conexão do leitor (1) ao terminal (3) e/ou um pedido de identificação do leitor (não necessitando de troca com o cartão) — uma ordem de inicialização do canal seguro, — um pedido de exibição de informações enviadas pelo equipamento (4) de fornecedor para confirmação (validação) pelo utilizador, — um pedido de exibição de um convite à introdução de dados pelo utilizador, — um pedido de assinatura de dados, — os pedidos de interrogação da pastilha eletrónica (comando APDU), recebidos, por exemplo, sob a forma de mensagem encriptada, desencriptados pelo leitor que interroga a pastilha eletrónica.

Em algumas formas de realização, o servidor (40) de operações do equipamento (4) de fornecedor está configurado para gerar o estabelecimento e a utilização do canal (CS) seguro ao guardar (armazenar) o número imprevisível (UN), o número (Nseq) de sequência associado com cada transação e incrementado a cada comando enviado para o leitor (1) , e o número (Nses) de sessão.

Em algumas formas de realização, o módulo (41) de segurança do equipamento (4) de fornecedor está configurado para armazenar a chave (Kses) de sessão em meios de armazenamento e/ou para encriptar a chave (Kses) de sessão utilizando uma chave, denominada chave mestre (KM), e transmiti-la para o servidor (40), para armazenamento sob uma forma encriptada ([Kses]™) em meios de armazenamento. Assim, por exemplo, o servidor (40) de operações, encarregado de gerir a comunicação com o utilizador (através do terminal e do leitor) mantém a chave de sessão (mas de forma encriptada pela chave do módulo de segurança para mais segurança, pois o servidor pode não ser tão seguro quanto o módulo de segurança) e reenvia-a para o módulo de segurança em cada pedido de encriptação/desencriptação. As trocas com o utilizador, assim, não têm que ser seguidas pelo módulo de segurança, que simplesmente executa as operações de encriptação/desencriptação em resposta a solicitações do servidor (40) de operação gerindo as outras operações, em particular, identificando a transação corrente utilizando o número (Nses) de sessão e a ordem atual devido ao número (Nseq) de sequência. 0 equipamento (4) de fornecedor, em particular, o servidor (40) de operações, está, assim, confiqurado para recolher esses dados (D chip) representativos de informações relacionadas com o cartão (2) e, em algumas formas de realização, para guardar os elementos seguinte associados com a operação (pelo menos, o tempo da operação): — o criptograma ([Rses]™) da chave (Kses) de sessão, devolvido pelo módulo (41) de segurança, — o N.° de sessão (Nses), que pode, por exemplo, ser constituído por 4 bytes do UN e 2 bytes do ATC associado com o identificador do titular, — o N.° de sequência (Nseq) durante uma sessão (operação), por exemplo, constituído por 2 bytes e incrementado a cada comando ou ordem enviados para o leitor (D .

Além disso, o servidor (40) de operações pode ser configurado para verificar a consistência das informações ao controlar que um número de sessão correto (em comparação com o N.° armazenado) se encontra presente no momento da decifragem dos dados recebidos do leitor (1) e para verificar que o número (Nseq) de sequência é estritamente crescente numa sessão. Finalmente, pode, também, ser configurado de modo a verificar nos dados (D_chip) que a autenticação do titular (PIN) foi bem efetuada.

Os dados sobre a transação também podem ser armazenados, em particular, para prever casos de contestação, embora a validação das transações pelo utilizador autenticado pelo seu código possa impedir essa contestação das transações.

Em algumas formas de realização em que a invenção utiliza um navegador (suporte lógico de navegação em execução nos meios de processamento do terminal (3) de utilizador ou do leitor (1) diretamente), a invenção proporciona um módulo (ME) de porta de acesso permitindo transmitir os dados recebidos do equipamento (4) de fornecedor para o leitor (1). Com efeito, os navegadores (N) conhecidos não permitem, atualmente, transmitir dados recebidos através de uma rede de comunicação para um leitor de cartões. No caso de um navegador executado nos meios (30) de processamento de um terminal (3) de utilizador, é necessário, pelo menos, um módulo (ME) de porta de acesso executado nesses meios (30) de processamento. No caso de um leitor em comunicação mencionado acima, este módulo pode, opcionalmente, ser omisso. Este módulo de porta de acesso é configurado para controlar as trocas de dados que transitam pelo canal (CS) seguro entre o módulo (41) de segurança e o leitor (1), transmitindo ao leitor (1) os dados recebidos do equipamento de fornecedor (em particular, o servidor (40) de operações) pelo navegador (N) . Em algumas formas de realização, este módulo (ME) de porta de acesso pode ser executado dentro do ambiente de suporte lógico fornecido pelo navegador. Por exemplo, este módulo de porta de acesso pode ser um módulo de expansão ("plug-in" de acordo com a terminologia anglo-saxónica) do navegador (N) . Pode ser implementado como uma miniaplicação, por exemplo, de tipo JAVA™. A invenção pode, assim, proporcionar vários tipos de aplicação, tais como extensões ou código passivel de ser descarregado, ou, no futuro, os navegadores poderão incluir uma tal função. Em alternativa, também é possivel que o leitor e/ou o cartão armazenem dados permitindo a instalação desse módulo no terminal. Assim, o terminal (3) do utilizador, durante a conexão do leitor ou/e durante o acesso ao cartão pelo leitor, poderá ser automaticamente dotado com o módulo de porta de acesso permitindo as transmissões de dados no canal seguro.

Por exemplo, um tal módulo (ME) de porta de acesso pode permitir que o navegador verifique a presença do leitor, ao confirmar ao navegador essa presença ou, no caso de ausência ou de resposta inadequada, provocando a exibição de uma mensagem solicitando ao utilizador para ligar o leitor. Em geral, o módulo de porta de acesso pode ser responsável por transmitir ao leitor os pedidos recebidos pelo navegador, tais como os pedidos detalhados anteriormente como exemplos ilustrativos e não limitativos (interrogação da pastilha eletrónica, validação de dados, assinaturas de dados, convite à inserção de dados, etc.) e será responsável de transmitir a ou as respostas do leitor (1) para o navegador.

Em algumas formas de realização, pelo menos, uma parte dos dados representativos da transação, enviados para o servidor (40) do equipamento (4) de fornecedor, são inseridos pelo utilizador nos meios de introdução de dados do terminal (3) , através de informações exibidas pelo navegador (N) em meios de exibição do terminal (3) . Estas formas de realização não garantem, necessariamente, a confidencialidade, na medida em que vários tipos de ataques permitirão quebrar a confidencialidade ou mesmo permitir corromper os dados inseridos. No entanto, mesmo que os dados inseridos no navegador sejam corrompidos, a segurança das transações pode, ainda, ser garantida pela presente invenção se o utilizador utilizar o leitor (1) para inserir, verificar os dados relativos à transação e para validar a transação, pois os dados transação foram encriptados para transitar pelo canal (CS) seguro sem poderem ser corrompidos. A invenção pode proporcionar a exibição, por meio do navegador, de uma mensagem informando o utilizador da necessidade de verificar e validar as informações no leitor. Em algumas formas de realização permitindo uma total confidencialidade das informações e uma segurança completa, todos os dados são inseridos pelo utilizador no leitor (1). Em algumas formas de realização, pelo menos, uma parte dos dados representativos da transação, transmitidos para o servidor (40) do equipamento (4) de fornecedor, são inseridos pelo utilizador nos meios (11) de introdução de dados do leitor (1) de cartões inteligentes. Por conseguinte, deve compreender-se que, em algumas alternativas da invenção, a segurança e a confidencialidade totais das transações são asseguradas pelo facto de todos os dados passarem através do canal seguro entre o leitor e o equipamento de fornecedor.

Em algumas formas de realização, a inicialização da transação segue-se a uma transmissão para o servidor (40) do equipamento (4) de fornecedor de, pelo menos, uma parte dos dados representativos da transação, por um servidor (5) terceiro gerindo um sitio da Internet ao qual o utilizador está conectado. Assim, a inicialização ocorre quando o utilizador tenta efetuar uma transação. A transação propriamente dita pode, em seguida, passar pelo canal (CS) seguro. Em algumas formas de realização, pelo menos, uma parte dos dados representativos da transação de dados são transmitidos para o servidor (40) do equipamento (4) de fornecedor por um servidor (5) terceiro gerindo um sitio da Internet ao qual o utilizador está conectado. Deve compreender-se da presente descrição que o utilizador pode conectar-se ao servidor (5) terceiro a partir do seu leitor/terminal no caso em que o leitor está incorporado num terminal em comunicação ou ser conectado ao servidor (5) terceiro a partir do seu terminal no caso em que o leitor está conectado a um tal terminal. A conexão do utilizador é efetuada através do navegador (N) do terminal (3) para realizar uma transação, selecionada através dos meios de introdução de dados do terminal (3) . Assim, a invenção também permite a compra de artigos em linha. O equipamento (4) de fornecedor recebendo dados relacionados com uma transação do servidor (5) terceiro ao qual está conectado o navegador (N) pode ser colocado em contacto com o leitor para estabelecer um canal seguro e nenhum dado sensivel fica, então, acessível na rede. A invenção também se refere a um método de inicialização de transação segura em linha e a um método de transação segura em linha, em que uma forma de realização é mostrada na figura 2. Estes métodos são implementados pelos sistemas de acordo com a invenção. O método de transação compreende, pelo menos, um passo (91) de transmissão de dados cifrados, pela referida chave (Kses) de sessão, entre o módulo (41) de segurança e o leitor (1), após um passo (90) de estabelecimento de, pelo menos, um canal (CS) de comunicação seguro entre o módulo (41) de segurança e o leitor (1) . Este passo (90) de estabelecimento do canal (CS) seguro é implementado por meio dos seguintes passos preliminares: — geração (52) de, pelo menos, uma chave (Kses) de sessão, pelos meios (12) de processamento do leitor (1), em cooperação com o cartão (2), e, em seguida, a encriptação de dados utilizando essa chave (Kses) de sessão, — obtenção (53), pelo leitor (1), a partir da pastilha eletrónica (20) do cartão (2), de dados (D_chip) representativos de informações relacionadas com o cartão (2) , — transmissão (54), do leitor (1) para o módulo (41) de segurança, de dados (D chip) representativos de informações relacionadas com o cartão (2) e de dados encriptados utilizando a chave (Kses) de sessão, — geração (55), pelo módulo (41) de segurança, da chave (Kses) de sessão a partir de, pelo menos, uma chave (CF) de encriptação do módulo (41) de segurança e de dados (D_chip) recebidos.

Após este passo (90) de estabelecimento do canal (CS) de comunicação seguro, a transação pode desenrolar-se segundo uma sequência especifica (dependendo do tipo de transação), de forma completamente segura, por meio de, pelo menos, um passo (91) de transmissão de dados cifrados entre o módulo (41) de segurança e o leitor (1). Por conseguinte, deve compreender-se que a presente invenção tem a vantagem de proteger os dados transmitidos desde o inicio da transação, em vez de proteger apenas a validação da transação por uma assinatura (criptográfica) como na técnica anterior. Em algumas formas de realização, o passo (52) de geração de, pelo menos, uma chave (Kses) de sessão pelos meios (12) de processamento do leitor (1) é precedido por um passo (51) de geração, pela pastilha eletrónica (20) do cartão (2), de, pelo menos, um criptograma (AAC, ARQC) a partir da chave (CF) de encriptação armazenada na pastilha eletrónica (20) e de transmissão desse ou desses criptogramas para o leitor (1) gerando a chave (Kses) de sessão a partir desse ou desses criptogramas (AAC, ARQC).

Em algumas formas de realização, o método compreende, pelo menos, um passo (50) de inserção, pelo utilizador do cartão (2) , de, pelo menos, um código de identificação pessoal (PIN) do utilizador e de autenticação desse código pela pastilha eletrónica (20) do cartão. Este passo (50) de inserção/autenticação pode ser implementado no momento do estabelecimento do canal seguro, para o utilizador ser autenticado desde o inicio e para que as trocas de dados necessárias para a transação sejam efetuadas através do canal estabelecido pela autenticação do utilizador do cartão. Por conseguinte, este passo permite, pelo menos, um passo (60) de assinatura de dados pela pastilha eletrónica (20) . Por exemplo, quando o leitor necessita de criptogramas da pastilha eletrónica para calcular a chave de sessão, a pastilha eletrónica executa assinaturas ao realizar, pelo menos, um criptograma e o leitor gera a chave de sessão, como mencionado acima. No caso de uma autenticação ao estabelecer o canal (CS) seguro, essa assinatura (60) para a inicialização da transação difere das assinaturas convencionalmente utilizadas na área, em particular, no CAP, uma vez que essas assinaturas clássicas são feitas no final de uma transação para a validar (através do envio de um criptograma), enquanto a assinatura de inicialização destas formas de realização é feita para o estabelecimento do canal, antes de qualquer troca de dados, o que protege, de um modo vantajoso, a transação. No entanto, a presente invenção também permite a implementação de um outro passo de assinatura no final da transação. Por exemplo, depois de o canal ser estabelecido e depois de a maior parte dos passos necessários para a transação ter sido realizada através do canal por troca de dados de forma encriptada, é possível exigir uma nova introdução do código PIN pelo utilizador no final da transação, por exemplo, através da exibição de um resumo das informações da transação e de um convite para a introdução do PIN para uma assinatura do tipo convencionalmente utilizado no CAP. Em geral, o método pode, também, compreender, pelo menos, um passo de validação pelo utilizador de informações exibidas e/ou inseridas no leitor e correspondendo a dados representativos da transação.

Em algumas formas de realização, o método compreende, pelo menos, um passo (58) de encapsulamento/desencapsulamento de dados representativos da transação transitando através do canal (CS) seguro.

Em algumas formas de realização, o passo (52) de geração de, pelo menos, uma chave (Kses) de sessão, por meios (12) de processamento do leitor (1) é precedido por um passo (51) de geração, pelo a pastilha eletrónica (20) do cartão (2), de, pelo menos, um criptograma (AAC, ARQC) a partir da chave (CF) de encriptação armazenada na pastilha eletrónica (20) e de transmissão desse ou desses criptogramas para o leitor (1) gerando a chave (Kses) de sessão a partir desse ou desses criptogramas (AAC, ARQC). Por exemplo, o leitor concatena dois criptogramas diferentes gerados.

Em algumas formas de realização, o método compreende, pelo menos, um passo de receção e processamento, pelos meios (12) de processamento do leitor (1), de, pelo menos, um comando de inicialização do canal (CS) seguro enviado pelo módulo (41) de segurança, compreendendo um número imprevisível (UN) e induzindo a interrogação da pastilha eletrónica (20) pelo leitor (1), para obter, pelo menos, um criptograma (AAC, ARQC) e os dados (D_chip) representativos de informações relacionadas com o cartão (2), permitindo este passo o passo (52) de geração da chave (Kses) de sessão para o estabelecimento do canal (CS) de comunicação seguro e transmissão (54) para o módulo (41) de segurança, por um lado, de dados (D_chip) representativos de informações relacionadas com o cartão (2) e, por outro lado, dos referidos dados encriptados utilizando essa chave (Kses) de sessão, que compreendem dados relativos ao número imprevisível (UN). 0 método de transação seguro de acordo com a invenção compreende os passos do método de inicialização e, pelo menos, um passo (91) de transmissão de dados entre o módulo (41) de segurança e o leitor (1) em forma encriptada pela referida chave (Kses) de sessão, implementado num sistema de transação segura de acordo com a invenção.

Em algumas formas de realização, o servidor (40) está configurado para solicitar do módulo (41) de segurança, em cada passo (91) de transmissão de dados com o leitor (1), uma encriptação/desencriptação pela referida chave (Kses) de sessão dos dados transmitidos, estando o leitor (1) configurado para, também, encriptar/desencriptar os dados trocados durante a transação.

Deve compreender-se, através da leitura do presente pedido de patente, que o passo (90) de inicialização do canal seguro, através da troca de dados necessários, pode, também, compreender os passos de transmissão de dados representativos do número imprevisível (UN), do identificador de aplicação (AID), do número (Nses) de sessão, do número (Nseq) de sequência, etc., anteriormente mencionados. Também se deve compreender que, depois de concluída a inicialização (90) do canal, o método pode prosseguir com, pelo menos, uma iteração do passo (91) de transmissão de dados encriptados utilizando a chave de sessão. Cada iteração desta transmissão (91) está associada a, pelo menos, um passo (910) de encriptação/desencriptação dos dados transmitidos. Assim, compreende-se que a invenção se refere, em primeiro lugar, a um método e a um sistema de inicialização de transação nos quais o estabelecimento (90), ou inicialização, do canal (CS) seguro é realizado/a pela implementação dos passos descritos acima, para permitir que as duas entidades utilizem a mesma chave de sessão, e a invenção também se refere a um método e a um sistema de transação segura nos quais as transmissões (91) de dados representativos da transação estão associadas a, pelo menos, um passo (910) de encriptação/desencriptação de dados transmitidos pela referida chave (Kses) de sessão. E pelo facto de os dados serem encriptados que se compreende que estes transitem por um canal seguro.

Em geral, deve compreender-se que a invenção permite a implementação de passos relativos a transações, tais como, por exemplo, transferências bancárias em linha, pagamentos em linha (por exemplo, de tipo 3D-secure), alterações de código PIN em linha (fazendo-se o envio do novo código inserido de forma encriptada pela chave de sessão através do canal seguro) . Deve salientar-se que a presente invenção permite, obviamente, a transmissão de outro tipo de dados para além dos que se referem a um código PIN, dado que o termo "transação", no presente documento, abrange qualquer tipo de transmissão de dados. No caso de uma mudança de código PIN de um cartão seguro, o novo código PIN transmitido de forma cifrada através do canal seguro é decifrado pelo módulo (41) de segurança e pode ser armazenado pelo equipamento (4) de fornecedor. No setor bancário, as alterações do código PIN requerem a utilização de um comando especifico para o cartão, conhecido como "secure messaging". A invenção pode incorporar essa funcionalidade através do envio, pelo equipamento (4) de fornecedor tendo recebido o novo código PIN escolhido pelo utilizador (inserido no leitor) , de um tal comando contendo o novo código PIN e permitindo alterar o código PIN pelo cartão.

Os vários tipos de transações possíveis através da implementação do método ocorrerão de acordo com várias sequências como é conhecido pelos peritos na especialidade. As figuras 3 e 4 mostram a sequência de uma operação de transferência bancária, no exemplo descrito acima de um equipamento 4) de fornecedor compreendendo um primeiro servidor, denominado frontal, ao qual acede o navegador (N) do terminal (3) que está conectado a um leitor (1) acedendo aa pastilha eletrónica (20) do cartão (2) e um servidor (40) de operações gerindo todas as operações e interrogando o módulo (41) de segurança para as encriptações/desencriptações. A figura 3 mostra a sequência até ao estabelecimento (90) do canal (CS) seguro num exemplo de realização adaptado para uma operação de transferência bancária. A figura 4 mostra a sequência da forma de realização do método da figura 3, a partir do estabelecimento (90) do canal (CS) seguro. A figura 3 mostra, por conseguinte, uma forma de realização do método de inicialização de transação e a figura 4 mostra uma forma de realização do método de transação. Nesse exemplo das figuras 3 e 4, considera-se que uma sessão "e-banking" já está em andamento: o utilizador já foi autenticado por um método estabelecido pelo banco e deseja fazer uma operação de tipo transferência bancária durante a sua sessão. O seu leitor está conectado e o seu cartão inserido. Neste exemplo, o método para implementar uma tal operação de transferência bancária pode ocorrer da seguinte forma: — Envio (61) pelo equipamento (4) de fornecedor (o servidor frontal da web, por exemplo) de um convite para a introdução dos campos da operação no terminal (3); — Introdução (62) de dados da operação pelo utilizador no terminal (3); — Envio (63) dos dados da operação e pedido de confirmação do terminal (3) para o servidor Frontal da Web.

Deve salientar-se que a introdução de dados pode, na verdade, ser efetuada no leitor (1) e não no terminal. Neste caso, os passos anteriores irão ser complementados por passos de transmissões, utilizando o módulo (ME) de porta de acesso, de dados entre o terminal e o leitor. Também se deve salientar que se omitiram, aqui, todos os passos realizados pelo módulo de porta de acesso e que só se menciona o terminal (3) para maior clareza e simplicidade. O método continua com: — Envio (64) dos dados da operação do frontal da Web para o servidor (40) de operação; — Ordem (65) de inicialização do canal seguro, pelo servidor de operação para o terminal (3); — Teste (66) da presença do leitor pelo terminal (3); — Teste (67) da presença do cartão pelo leitor (1); — Ordem (68) de inicialização (90) do canal seguro pelo terminal (3) para o leitor (1); — Troca(s) (69) entre o leitor e o cartão (pelos comandos acima descritos, em particular, aqui, para um pedido de introdução do código PIN); — Introdução (70) do código PIN pelo utilizador após convite exibido pelo leitor (1); — Troca(s) (71) entre o leitor e o cartão (pelos comandos acima descritos, em particular, aqui, para a verificação do código PIN pelo cartão); — Geração (52) da chave (Kses) de sessão pelo leitor (1) para o estabelecimento (90) do canal (CS) seguro, por exemplo, com Geração (51) de um ou de uns criptogramas pelo cartão (2), Geração de um número N(ses) de sessão e, depois, Encriptação (910) do número N(ses) de sessão; — Obtenção (53) de dados (D_chip) do cartão (2) pelo leitor (1); — Transmissão (54) de dados (D_chip) representativos de informações relacionadas com a cartão (2), do leitor (1) para o módulo (41) de segurança por meio de, aqui, em particular: - Envio (72) de dados (D_chip) do cartão e do número (Nses) de sessão, cifrado pela chave (Kses) de sessão, pelo leitor (1) para o terminal (3);

Envio (73) de dados (D_chip) do cartão e, opcionalmente, do número (Nses) de sessão, cifrado pela chave (Kses) de sessão, pelo terminal (3) para o servidor (40) de operações; — Ordem (74) para criar a chave (Kses) de sessão a partir dos dados (D_chip) do cartão, pelo servidor de operação para o módulo (41) de segurança; — Geração (55) pelo módulo (41) de segurança da chave (Kses) de sessão a partir de uma chave (CM) de encriptação do módulo (41) de segurança e dos dados (D_chip) recebidos, — Envio (75) da chave (Kses) de sessão cifrada pela chave mestra (KM) pelo módulo (41) de segurança para o servidor de operação (para armazenamento e reutilização nos passos seguintes da transação, possivelmente com o número de sessão e número de sequência) O Canal (CS) seguro é, então, ativado (estabelecimento (90) através das gerações (52 e 55) de cada lado. O método de iniciação fica, assim, concluído nesta forma de realização e o método de transação pode, então, prosseguir (figura 4) com: — Ordem (76) de cifragem (910) dos dados da operação para exibição no ecrã do leitor, pelo servidor de operação para o módulo (41) de segurança — Transmissão (91) dos dados da transação encriptados utilizando a chave (Kses) de sessão devido, aqui, em particular:

Ao envio (77) da cadeia de caracteres cifrada pela chave de sessão pelo módulo (41) de segurança para o servidor de operação; À ordem (78) de pedido de confirmação das informações cifradas pela chave de sessão pelo servidor de operação para o terminal (3); À ordem (79) de pedido de confirmação das informações cifradas pela chave de sessão, pelo terminal (3) para o leitor (1); — Exibição (80) no leitor (1) das informações cifradas e Validação/Cancelamento (81) pelo utilizador com base nas informações apresentadas.

Deve salientar-se que o método pode compreender várias iterações sucessivas dos vários passos, em particular, as das transmissões (91), que podem incluir vários comandos, tais como os descritos acima, em particular, referentes à ordem (79), exibição (80) e validação/cancelamento (81): por exemplo, uma iteração para solicitar a validação/cancelamento da conta a debitar, uma iteração para solicitar a validação/cancelamento da conta a creditar, etc. De acordo com várias alternativas, pode, de facto, existir uma única ordem (79) enviada para exigir múltiplas exibições (80) e validações (81) e passos, ou várias ordens para vários passos de validação/cancelamento). Também se deve salientar que o encapsulamento/desencapsulamento (58) não é mencionado aqui para simplificar a descrição da sequência de passos. O método de transação, em seguida, continua com uma transmissão (91) na outra direção, em particular, aqui, com: — Envio (82) das informações validadas, assinadas pelo cartão e, em seguida, cifradas pelo leitor (1) com a chave de sessão, para o terminal (3); — Envio (83) das informações validadas, assinadas pelo cartão e, em seguida, cifradas pelo leitor (1) com a chave de sessão, pelo terminal (3) para o servidor de operação; — Ordem (84) de decifragem das informações validadas, assinadas pelo cartão e, em seguida, cifradas com a chave de sessão pelo servidor de operação para o módulo (41) de segurança.

Para permitir manter um registo das operações, o método pode continuar com um passo de envio (85) das informações validadas e da assinatura legivel para arquivamento, do módulo (41) de segurança para o servidor (40) de operação; o servidor (40) de operação pode, em seguida, executar uma Operação de pagamento, por exemplo, com o envio (86), pelo menos, para o terminal (3), de uma confirmação de operação (confirmação da transação realizada).

Ao ler este exemplo ilustrativo acima e meios específicos descritos no presente pedido de patente, o perito na especialidade irá compreender os passos, em particular, entre os descritos acima, que podem ser implementados para várias operações, como, por exemplo, transações bancárias (pagamento em linha) ou envios seguros de dados (por exemplo, representativos de informações sobre a saúde do utilizador, etc.) 0 módulo (41) de segurança está configurado para, pelo menos, permitir uma inicialização de transação utilizando, pelo menos, uma função de inicialização do canal seguro, por exemplo, implementada após uma ordem de criação do canal (CS) seguro proveniente do servidor (40) de operações. Por exemplo, essa função pode ter, como parâmetros de entrada, os dados representativos de informações relacionadas com o cartão (D_chip) para a constituição da chave de sessão e, como valores devolvidos, a chave (Kses) de sessão cifrada pela chave mestra (KM) do módulo (41) de segurança: [Kses] km. Deve salientar-se que, de acordo com várias formas de realização, os valores devolvidos também irão incluir o número imprevisível (UN) e/ou o identificador de aplicação (AID) acima referido, ou que o servidor de operações pode gerir essa função de inicialização do canal seguro ao transmiti-la para o leitor depois de lhe adicionar o número imprevisível (UN) e/ou o identificador de aplicação (AID).

Em algumas formas de realização, o módulo (41) de segurança também está configurado para permitir uma transação segura utilizando, pelo menos, uma função de cifragem/decifragem (encriptação/desencriptação) implementada, por exemplo, após: — Uma ordem de encriptação (cifragem), por exemplo, enviada para o módulo de segurança pelo servidor (40) de operações. Por exemplo, essa função pode ter, em parâmetros [Kses] km, a chave de sessão cifrada pela chave mestre do módulo de segurança e os dados a cifrar, e, em valores devolvidos, esses dados cifrados pela chave (Kses) de sessão; — Uma ordem de desencriptação (decifragem), por exemplo, enviada para o módulo de segurança pelo servidor (40) de operações. Por exemplo, essa função pode ter, em parâmetros, a chave de sessão cifrada pela chave mestra do módulo de segurança ([Kses]™) e os dados a decifrar e, em valores devolvidos, os dados legíveis (decifrados).

Além disso, dependendo das aplicações e da arquitetura (do equipamento) do fornecedor de serviços, a invenção pode, também, incluir outros dados e funções conhecidas pelos peritos na especialidade (chave de transporte, passagem de dados cifrados para uma nova chave, ...) e que são específicos de cada fornecedor de serviços. A presente invenção refere-se a "meios de processamento de dados" em vários dispositivos (servidor, terminal, leitor, cartão, etc.). 0 perito da especialidade vai compreender, ao ler o presente pedido de patente, que tais meios de processamento de dados se referem, no cartão seguro, aa pastilha eletrónica que inclui, pelo menos, um microprocessador permitindo o processamento de dados. Além disso, a pastilha eletrónica pode armazenar vários tipos de dados, tais como os representativos de informações relacionadas com o cartão, mas também dados permitindo a execução de uma ou de umas aplicações específicas (para a assinatura de transações em particular). Além disso, o perito na especialidade compreenderá que, para os servidores, os terminais e o leitor, estes meios também podem incluir, pelo menos, um microprocessador, por exemplo, montado numa placa principal ("motherboard"). Em geral, os meios de processamento de dados podem compreender, pelo menos, um circuito eletrónico e/ou, pelo menos, um processador. Dependendo dos recursos informáticos necessários, são possíveis várias alternativas no âmbito dos peritos na especialidade. Do mesmo modo, as várias tarefas e funções aqui descritas podem, de facto, ser realizadas por vários dispositivos diferentes que cooperam de modo a formar a entidade descrita (servidor, terminais, etc.). Com efeito, é possível, por exemplo, que vários servidores cooperem para realizar as tarefas necessárias no sistema a que pertencem, como explicado, por exemplo, para os servidores do equipamento (4) de fornecedor, e a invenção não deve ser limitada pela presença de um único servidor, por exemplo. Da mesma forma, o termo servidor é particularmente evidente para as aplicações aqui descritas, mas deve compreender-se que a invenção também pode ser implementada ao substituir o equipamento de fornecedor (servidores) por, pelo menos, um terminal de um utilizador (que, então, compreenderá os meios especificos descritos para o equipamento de fornecedor, tendo, anteriormente, confiqurado o cartão e esse terminal para permitir a implementação da invenção). Além disso, a invenção utiliza, em várias formas de realização, aplicações de suporte lógico e deve compreender-se que a forma como essas aplicações são implementadas não está limitada à sua execução num único dispositivo, dado que os meios de processamento podem ser distribuidos por múltiplos dispositivos. Assim, as aplicações aqui descritas podem, também, ser provenientes de fontes diferentes (em particular, no caso de código descarregável) e isso é uma interpretação funcional que deve ser aplicada uma vez que é a execução das funções aqui descritas que é importante.

Em particular, a invenção utiliza meios especificos, em particular, no terminal de utilizador (módulo de porta de acesso para o navegador), no equipamento de fornecedor (pelo menos, o módulo de segurança e um servidor para as trocas) e no leitor (aplicação especifica). A invenção pode, por conseguinte, também envolver cada um desses elementos em separado, com os seus meios especificos descritos aqui.

Para os peritos na especialidade deve ser óbvio que a presente invenção permite formas de realização com inúmeras outras formas especificas sem se divergir do âmbito da aplicação da invenção, tal como reivindicado. Por conseguinte, as presentes formas de realização devem ser consideradas como ilustrativas, mas podem ser modificadas no campo definido pelo âmbito das reivindicações anexas e a invenção não deve ser limitada aos detalhes dados acima.

Lisboa, 2016-11-09

Claims (17)

1. REIVINDICAÇÕES

   1 - Leitor (1) de cartão inteligente com pastilha eletrónica para transações seguras em linha, por meio de, pelo menos, uma rede (RC) de comunicação, através da troca de dados representativos de transações com, pelo menos, um equipamento (4) de um fornecedor de serviços compreendendo, pelo menos, um servidor (40) configurado para gerir transações em linha e, pelo menos, um módulo (41) de segurança protegendo essas transações em cooperação com o leitor (1), caracterizado por compreender meios (12) de processamento que são adaptados para: trocar, antes de qualquer transação, dados com, pelo menos, um pastilha eletrónica (20) de, pelo menos, um cartão (2) seguro, de modo a obter da pastilha eletrónica (20) e transmitir ao módulo (41) de segurança dados (D_chip), denominados públicos, representativos de, pelo menos, uma informação relacionada com o cartão (2); gerar, antes de qualquer transação, em cooperação com a referida pastilha eletrónica (20), pelo menos, uma chave (Kses) de sessão e transmitir dados encriptados utilizando essa chave (Kses) de sessão para o módulo (41) de segurança, de modo a que o módulo (41) de segurança possa calcular a referida chave (Kses) de sessão com base nos referidos dados (D_chip) públicos recebidos e em, pelo menos, uma chave (CF) de encriptação; trocar os dados representativos da transação com o módulo (41) de segurança numa forma encriptada pela referida chave (Kses) de sessão, formando, assim, um canal (CS) de comunicação seguro para a transação.
2. 2 - Leitor (1) de cartão inteligente com pastilha eletrónica, de acordo com a reivindicação 1, caracterizado por os meios (12) de processamento do leitor (1) estarem adaptados para gerar a chave (Kses) de sessão em cooperação com a pastilha eletrónica (20) do cartão (2) ao exigir que a pastilha eletrónica (20) do cartão (2) gere, com base em, pelo menos, uma chave (CF) de encriptação armazenada na pastilha eletrónica, (20), pelo menos, um criptograma (AAC, ARQC) utilizado pelo leitor (1) para gerar a chave (Kses) de sessão utilizada para o estabelecimento do canal (CS) seguro.
3. 3 - Sistema de transação segura em linha, através de, pelo menos, uma rede (RC) de comunicação, compreendendo o sistema, pelo menos, um equipamento (4) de um fornecedor de serviços compreendendo, pelo menos, um servidor (40) configurado para gerir transações em linha através da troca de dados representativos de transações com, pelo menos, um leitor (1) de cartões (2) com pastilha eletrónica, compreendendo, ainda, o referido equipamento (4), pelo menos, um módulo (41) de segurança configurado para proteger essas transações, caracterizado por: — o referido sistema compreender, pelo menos, um leitor de cartão inteligente com pastilha eletrónica de acordo com uma das reivindicações 1 e 2; — o módulo (41) de segurança calcular a referida chave (Kses) de sessão com base nos referidos dados (D_chip) públicos recebidos e, pelo menos, numa chave (CF) de encriptação; — o leitor (1) e o módulo (41) de segurança encriptarem e desencriptarem, através da referida chave (Kses) de sessão, os dados representativos da transação que trocam entre si durante a transação, formando, assim, um canal (CS) de comunicação seguro para a transação.
4. 4 - Sistema, de acordo com a reivindicação 3, caracterizado por: — o módulo (41) de segurança utilizar, pelo menos, uma chave, denominada chave mãe (CM) tendo sido utilizada para gerar chaves (CF) de cartões (2) seguros fornecidos pelo fornecedor de serviços, denominadas chaves filhas (CF) , podendo cada um dos cartões (2) fornecidos ser identificado com base em, pelo menos, uma informação contida nos dados (D_chip) públicos; — os meios (12) de processamento do leitor (1) transmitirem os dados (D chip) públicos para o módulo (41) de segurança para lhe permitir encontrar a chave (CF) de encriptação a utilizar para calcular a chave (Kses) de sessão.
5. 5 - Sistema, de acordo com uma das reivindicações 3 e 4, caracterizado por o equipamento (4) do fornecedor de serviços compreender, pelo menos, uma base de dados armazenando as chaves (CF) de encriptação dos cartões (2) seguros fornecidos pelo fornecedor de serviços, acedendo o módulo (41) de segurança a essa base de dados para encontrar, com base nos dados (D_chip) públicos recebidos do leitor (1) de cartões com pastilha eletrónica, a chave (CF) de encriptação a utilizar para calcular a chave (Kses) de sessão.
6. 6 - Sistema, de acordo com uma das reivindicações 3 a 5, caracterizado por o leitor (1) e o equipamento (4) de fornecedor estarem ligados através de uma comunicação segura de acordo com um protocolo do tipo SSL/TLS, no qual o canal (CS) seguro está estabelecido.
7. 7 - Sistema, de acordo com uma das reivindicações 3 a 6, caracterizado por os meios (12) de processamento do leitor (1) estarem configurados para receber do módulo (41) de segurança e para processar, pelo menos, um comando de inicialização do canal (CS) seguro compreendendo um número imprevisível (UN) e induzindo a interrogação da pastilha eletrónica (20) pelo leitor (1), de modo a obter, pelo menos, um criptograma (AAC, ARQC) e os dados (D_chip) representativos de informações relacionadas com o cartão (2), o que permite que os meios (12) de processamento do leitor (1) gerem a chave (Kses) de sessão utilizada para estabelecer o canal (CS) de comunicação seguro e transmitam ao módulo (41) de segurança, por um lado, os dados (D chip) representativos de informações relacionadas com o cartão (2) e, por outro lado, os referidos dados encriptados utilizando essa chave (Kses) de sessão, que compreendem dados relativos ao número imprevisível (UN).
8. 8 - Sistema, de acordo com uma das reivindicações 3 a 6, caracterizado por a inicialização da transação ser efetuada após uma transmissão para o servidor (40) do equipamento (4) de fornecedor de, pelo menos, uma parte de dados representativos da transação, por um servidor (5) terceiro gerindo um sitio da Internet ao qual o utilizador está conectado.
9. 9 - Sistema, de acordo com uma das reivindicações 3 a 8, caracterizado por o servidor (40) do equipamento (4) de fornecedor estar configurado para gerir o estabelecimento e a utilização do canal (CS) seguro ao processar e manter um número imprevisível (UN), a chave (Kses) de sessão, um número (Nses) de sessão gerado quando o canal (CS) seguro é estabelecido e que está associado ao referido número imprevisível (UN) e a um contador de transações do cartão (2), bem como um número (Nseq) de sequência que é incrementado a cada comando enviado para o leitor (1) durante cada sessão.
10. 10 - Sistema, de acordo com uma das reivindicações 3 a 8, caracterizado por o módulo (41) de segurança do equipamento (4) de fornecedor estar configurado para armazenar a chave (Kses) de sessão em meios de armazenamento e/ou para encriptar a chave (Kses) de sessão utilizando uma chave, denominada chave mestra (KM), e enviá-la para o servidor (40) para ser armazenada nos meios de armazenamento de forma encriptada.
11. 11 - Sistema, de acordo com uma das reivindicações 3 a 10, caracterizado por o servidor (40) estar configurado para solicitar ao módulo (41) de segurança, em cada transmissão de dados com o leitor (1), uma encriptação/desencriptação pela referida chave (Kses) de sessão dos dados transmitidos, sendo o leitor (1) também configurado para encriptar/desencriptar os dados trocados durante a transação.
12. 12 - Método de inicialização de transação seguro em linha, por meio de, pelo menos, uma rede (RC) de comunicação, implementada utilizando, pelo menos, um leitor de acordo com uma das reivindicações 1 e 2, caracterizado por compreender, pelo menos, um passo (90) de estabelecimento de, pelo menos, um canal (CS) de comunicação seguro entre o módulo (41) de segurança e o leitor (1), que é implementado utilizando os seguintes passos: — geração (52) de, pelo menos, uma chave (Kses) de sessão, pelos meios (12) de processamento do leitor (1), em cooperação com o cartão (2) e, em seguida, encriptação de dados utilizando essa chave (Kses) de sessão; — obtenção (53), pelo leitor (1), a partir da pastilha eletrónica (20) do cartão (2), dados (D_chip) representativos de informações relacionadas com o cartão (2) ; — transmissão (54), do leitor (1) para o módulo (41) de segurança, de dados (D_chip) representativos de informações relacionadas com o cartão (2) e de dados encriptados utilizando a chave (Kses) de sessão; — geração (55), pelo módulo (41) de segurança, da chave (Kses) de sessão com base em, pelo menos, uma chave (CF) de encriptação do módulo (41) de segurança e nos dados (D_chip) recebidos.
13. 13 - Método, de acordo com a reivindicação 12, caracterizado por o passo (52) de geração de, pelo menos, uma chave (Kses) de sessão, pelos meios (12) de processamento do leitor (1), ser precedido por um passo (51) de geração, pela pastilha eletrónica (20) do cartão (2), de, pelo menos, um criptograma (AAC, ARQC) com base na chave (CF) de encriptação armazenada na pastilha eletrónica (20) e de transmissão desse ou desses criptogramas para o leitor (1) gerando a chave (Kses) de sessão com base nesse ou nesses criptogramas (AAC, ARQC).
14. 14 - Método, de acordo com uma das reivindicações 12 e 13, caracterizado por compreender, pelo menos, um passo (50) de introdução, pelo utilizador do cartão (2), de, pelo menos, um código de identificação pessoal (PIN) do utilizador e de autenticação desse código pela pastilha eletrónica (20) do cartão, permitindo esse passo (50) de introdução/autenticação, pelo menos, um passo (60) de assinatura de dados pela pastilha eletrónica (20).
15. 15 - Método, de acordo com uma das reivindicações 12 a 14, caracterizado por compreender, pelo menos, um passo de receção e processamento, pelos meios (12) de processamento do leitor (1), de, pelo menos, um comando de inicialização do canal (CS) seguro enviado pelo módulo (41) de segurança, compreendendo um número imprevisível (UN) e induzindo a interrogação da pastilha eletrónica (20) pelo leitor (1), de modo a obter, pelo menos, um criptograma (AAC, ARQC) e os dados (D_chip) representativos de informações relacionadas com o cartão (2), permitindo esse passo o passo (52) de geração da chave (Kses) de sessão utilizada para estabelecer o canal (CS) de comunicação seguro e a transmissão (54) para o módulo (41) de segurança de, por um lado, os dados (D_chip) representativos de informações relacionadas com o cartão (2) e, por outro lado, os referidos dados encriptados utilizando essa chave (Kses) de sessão, que compreendem dados os dados relativos ao número imprevisível (UN).
16. 16 - Método de transação segura em linha, caracterizado por compreender os passos do método de inicialização de acordo com uma das reivindicações 12 a 15 e, pelo menos, um passo (91) de transmissão de dados entre o módulo (41) de segurança e o leitor (1) de forma criptografada devido à referida chave (Kses) de sessão.
17. 17 - Método, de acordo com a reivindicação 16, caracterizado por o servidor (40) estar configurado para solicitar ao módulo (41) de segurança, em cada passo (91) de transmissão de dados com o leitor (1) , uma encriptação/desencriptação pela referida chave (Kses) de sessão dos dados transmitidos, estando o leitor (1) também configurado para encriptar/desencriptar os dados trocados durante a transação. Lisboa, 2016-11-09