Patent Description:
The present technology relates to systems and methods for authenticating a component of an electronic device. The system and method may be used, for example, in the context of private information entry on the electronic device to ensure that only authenticated components are able to process sensitive information.

This discussion is believed to be helpful in providing the reader with background information to facilitate a better understanding of the various aspects of the present technology.

The expansion of the internet coupled with the multiplication of connected mobile electronic devices allows billions of people to use their mobile devices daily for learning, communicating, exchanging information and conducting financial transactions. While performing such activities, identity, personal information and sensitive data are often input into the device, stored on the device, and also sent through communication links and networks to service providers. However, as the value and volume of sensitive information processed by mobile devices and online service providers has increased, so too have the efforts of malevolent parties to obtain sensitive information and exploit it for financial gain or other illicit purposes. Given that servers and mobile devices are accessible through the internet, often malevolent parties operate remotely from the systems they aim to compromise, thus reducing risks to themselves. For example, they may perform cyber attacks on online systems and networking infrastructure, steal or otherwise compromise cryptographic keys, steal or guess passwords to individual's online and financial accounts, use email phishing and hijack their personal or financial accounts, perform unauthorized financial transactions, install malware on mobile devices or remote servers and networking equipment, etc. To mitigate these threats, mobile device makers and service providers typically implement various cyber-security measures to protect their online systems, coupled with basic authentication measures, such as using a personal identification code (PIC) or biometric ID to unlock a device and perform sensitive operations, as well as implementing anti-malware measures (both hardware and software) on the mobile device.

Cryptography plays a central and ubiquitous role to protect unwarranted or malevolent parties from accessing such sensitive information both on the mobile device and in online systems. Indeed many cryptographic methods have been developed to encrypt information, with the goal of making such private information inscrutable to unapproved parties and only accessible to authorized parties, who usually have in their possession a method or key only known to them to decrypt the encrypted information. In general, when cryptographic methods are properly implemented and operated according to approved standards, they are often effective in preventing attackers from using cryptanalysis, malware, or other methods to decipher encrypted information that they intercept through compromising a mobile device, networking equipment, online systems or other means, provided that the cryptographic keys remain secure.

While many malevolent parties operate remotely from the systems and devices that they aim to compromise, in some cases they may also have physical proximity, or even direct access and control of a device or server, which allows them to use physical methods of compromising a system that are not possible remotely.

Thus, some devices that perform encipherment of sensitive information do so in a hostile environment where the attacker may, to varying degrees, have access to the device interfaces or even be able to monitor or tamper with the internal components of the device, aiming to recover sensitive information prior to its encryption, or else to compromise cryptographic keys such that encipherment no longer protects sensitive information. This problem is particularly acute for terminals used in financial transactions, such as point-of-sale terminals or ATMs. For example, malicious entities as well as legitimate security researchers have devised or used sophisticated attacks to access private information processed by financial terminals, attacks that may involve using skimmers attached to electronic devices, replacing original and secure device components with counterfeit and insecure components, inserting information-disclosing bugs in the said devices, installing fake personal identification number (PIN) pads, and other methods to access the information in its unencrypted form. For this reason, standards applicable to the security of terminals, such as, but not limited to PCI-DSS and PCI-PTS, specify that terminals must put in place measures to detect and respond to physical tampering of the device, and so many such methods have been devised and implemented in commercial terminals.

It is also possible for malicious persons in possession of or even merely in proximity to an electronic device to non-invasively obtain sensitive information from the devices. Indeed, in a class of methods commonly referred to as side-channel attacks, a malevolent party tries to gain and exploit information arising from the physical implementation of the cryptographic system, such as by monitoring the power consumption, electromagnetic leaks or acoustic leaks of the electronic device. One form of side-channel attack, known as power analysis, refers to a method where the attacker studies the power consumption of a hardware device performing a cryptographic operation with the goal of non-invasively extracting cryptographic keys and other secret information from the device. As an example, simple power analysis (SPA) involves visual examination of a graph of the current drawn by a device over time for only a single cryptographic operation. Another, powerful, technique is differential power analysis (DPA), which uses statistical methods to extract secret keys from the observation of the power consumption for multiple cryptographic operations.

Considering the volume of financial information processed and exchanged daily via communication networks on mobile or other electronic devices and the potential for immediate financial gain for malevolent parties, tampering and hacking methods in the context of financial transactions effected on electronic devices that are deployed in a physically hostile environment, pose a threat to security. For the foregoing reasons, there is a need for methods and systems for authenticating a component of an electronic device.

<CIT> is directed to methods and apparatus for encrypting and authenticating data, wherein some data is encrypted, and some data is not encrypted, but all of the data is authenticated.

<CIT> is directed to methods and apparatus for encrypting and authenticating data, such that some of the data can be transmitted but still authenticated by the sender.

Embodiments of the present technology have been developed based on inventors' appreciation that known approaches for authenticating a component of an electronic device may, in some instances, not be relied upon to conduct secured PIC entries, specifically in the context of secured financial transactions. Improvements are therefore desirable, in particular improvements aimed at assuring that a component of the electronic device is an originally manufactured component and that the device, being deployed in a physically hostile environment, has not been tampered with by malevolent parties aiming to replace the original component with a malicious component and thereby compromise the security of the device.

The present technology arises from an observation made by the inventor(s) that while the usage of mobiles devices has been democratized, malevolent parties have devised sophisticated techniques to gain information from the physical implementation of a cryptosystem and that techniques that help ensure the physical integrity of the device when the device may be deployed in a hostile environment are an important aspect of securing information exchange and financial transactions.

Therefore, inventor(s) have devised method and systems for generating an unpredictable sequence of dynamic keys to be used for authentication of one component to another. The unpredictably is based on the use of a dynamic secret that is shared between the two components and updated in an unpredictable way, such as through the use of noise, at each transaction.

In accordance with a first broad aspect of the present technology, there is provided method for generating an encrypted and authenticated message by a first component of an electronic device, the message authenticating the first component as the originator of the message, the method comprising: encrypting a block of information based on a first encryption key acquired from a first memory of the first component associated with a second decryption key in a second component of the device so as to generate an encrypted block of information, accessing, from a first memory of the first component, a first previous version of a first dynamic unique key, the first previous version of the first dynamic unique key being at least partially based on a first original unique key,
generating a first current version of the dynamic unique key based on the first previous version of the first dynamic unique key, generating a message authentication code (MAC) based on the encrypted block of information and the first current version of the first dynamic unique key, and transmitting, to the second component the encrypted block of information and the MAC.

In some implementations of the method, the method further comprises receiving, at the second component, the message comprising the encrypted block of information and the message authentication code, accessing, from a second memory of the second component, a second previous version of a second dynamic unique key, the second previous version of the second dynamic unique key being at least partially based on a second original unique key, generating a second current version of the second dynamic unique key based on the second previous version of the dynamic unique key, generating, at the second component, a control MAC based on the received encrypted block of information and the second current version of the dynamic unique key, and upon determining that the control MAC matches the MAC, determining that the message is authentic and that therefore the first component originated the message.

In some implementations of the method, the method further comprises decrypting, by the second component, with a second decryption key acquired from a second memory of the second component, the second decryption key associated with the first encryption key, the encrypted block of information.

In some implementations of the method (<NUM>) the first previous version of the first dynamic unique key and the second previous version of the second dynamic unique key are identical, and (<NUM>) the first current version of the first dynamic unique key and the second current version of the second dynamic unique key are identical.

In some implementations of the method the first original key has been stored within the first memory of the first component at the time of manufacturing the first component, and wherein the second original key has been stored within the second memory of the second component at the time of manufacturing the second component.

In some implementations of the method, generating a first current version of the first dynamic unique key based on the first previous version of the dynamic unique key is further based on a first current version of the key serial number (KSN) and wherein generating the second current version of the second dynamic unique key based on the second previous version of the second dynamic unique key is further based on a second current version of the KSN.

In some implementations of the method, the transmitting, to the second component the encrypted block of information and the MAC further comprises transmitting the first current version of the KSN, the receiving further comprises receiving the second current version of the KSN, and wherein the second version of the KSN is the first current version of the KSN.

In some implementations of the method, the first encryption key is a public key, the second decryption key is a private key and wherein the block of information is encrypted and decrypted based on an asymmetric algorithm using the public key and the private key.

In some implementations of the method, the first encryption key is a secret key, the second decryption key is the secret key and wherein the block of information is encrypted and decrypted based on a symmetric algorithm using the secret key. In some implementations of the method, the method further comprises
In some implementations of the method, the block of information is encrypted based on at least one of the ElGamal, elliptic curve techniques, paillier cryptosystem, Rivest Sbadir Adleman (RSA), and Cramer-Shoup cryptosystem.

In some implementations of the method, the first key is a secret key, the second key is the secret key and the block of information is encrypted and decrypted based on at least one of Twofish, Serpent, Advanced Encryption Standard (AES), Data Encryption Standard (DES), Blowfish, CAST5, Grasshopper, Rivest Cipher <NUM> (RC4), Triple Data Encryption Algorithm (3DES), Skipjack, Safer +/++ and International Data Encryption Algorithm (IDEA) algorithm using the secret key.

In some implementations of the method, the MAC and the control MAC are generated according to a cipher block chaining message authentication code (CBC- MAC).

In some implementations of the method, the MAC and the control MAC are generated according to at least one of a keyed-hash message authentication code (HMAC), cipher-based message authentication code (CMAC), a one-key CBC-MAC (CMAC) and a parallelizable message authentication code (PMAC).

In some implementations of the method, the cipher block chaining message authentication code uses at least one of a DES algorithm, an AES algorithm, a RC6 algorithm, an IDEA algorithm and a 3DES algorithm.

In some implementations of the method, the block of information comprises one of a personal identification code (PIC) and a correspondence table of a scrambled keypad.

In some implementations of the method, the first component is one of a touch controller and an isolated secured area of a processor and the second component is a secure element.

In some implementations of the method, encrypting the block of information is further based on a current version of a noise acquired from the first component, the first current version of the KSN is based on a first previous version of the noise acquired from the first memory of the first component, wherein the accessing from the second memory of the second component further comprises accessing a second previous version of the noise and wherein the second current version of the KSN is based on the second previous version of the noise and wherein the method further comprises: storing, in the first memory of the first component, the first current version of the noise as the first previous version of the noise, and storing, in the second memory of the first component, the second current version of the noise as the second previous version of the noise.

In some implementations of the method, the first current version of the KSN is further based on a previous version of the KSN, the second current version of the KSN is further based on a second previous version of the KSN and wherein the method further comprises: storing, in the first memory of the first component, the first current version of the KSN as the first previous version of the KSN, and storing, in the second memory of the first component, the second current version of the KSN as the second previous version of the KSN.

In some implementations of the method, the key serial number is based on multiple previous versions of the noise.

In some implementations of the method, encrypting the block of information is further based on a nonce, and the method further comprises, after generating a second current version of the second dynamic unique key based on the second previous version of the dynamic unique key: accessing, from the second memory of the second component, a previous acknowledgment key, generating, at the second component, a current acknowledgment key based on the previous acknowledgment key and the noise, generating, at the second component, a current acknowledgment message based on the current acknowledgment key and the nonce, and transmitting, to the first component, the current acknowledgment message.

In some implementations of the method, the method further comprises receiving, at the first component, the current acknowledgment message, generating, at the first component, a control current acknowledgment key based on a second previous acknowledgment key and the noise, generating, at the first component, a control current acknowledgement message based on the nonce, and upon determining that the control current acknowledgement message matches the current acknowledgement message, determining that the second component correctly processed the encrypted block of information.

In accordance with another broad aspect of the present technology, there is provided a system for generating an encrypted and authenticated message for authenticating a first component of the system as the originator of the message, the system comprising: a processor, a non-transitory computer-readable medium comprising instructions, the first component comprising a first memory, the first component being operatively connected to the processor, a second component comprising a second memory, the second component being operatively connected to the processor and the first component, the processor, upon executing the instructions, being configured to cause: encrypting, at the first component, a block of information based on a first encryption key acquired from the first memory associated with a second decryption key in the second memory of the second component so as to generate an encrypted block of information, accessing, from the first memory, a first previous version of a first dynamic unique key, the first previous version of the first dynamic unique key being at least partially based on a first original unique key, generating, at the first component, a first current version of the dynamic unique key based on the first previous version of the first dynamic unique key, generating, at the first component, a message authentication code (MAC) based on the encrypted block of information and the first current version of the first dynamic unique key, and transmitting, by the first component to the second component, the encrypted block of information and the MAC.

In some implementations of the system, the processor is further configured to cause: receiving, at the second component, the message comprising the encrypted block of information and the message authentication code, accessing, from the second memory, a second previous version of a second dynamic unique key, the second previous version of the second dynamic unique key being at least partially based on a second original unique key, generating, at the second component, a second current version of the second dynamic unique key based on the second previous version of the dynamic unique key, generating, at the second component, a control MAC based on the received encrypted block of information and the second current version of the dynamic unique key, and upon determining, at the second component, that the control MAC matches the MAC, determining that the message is authentic and that therefore the first component originated the message.

In some implementations of the system, the processor is further configured to cause: decrypting, by the second component, with a second decryption key acquired from the second memory, the second decryption key associated with the first encryption key, the encrypted block of information.

In some implementations of the system, (<NUM>) the first previous version of the first dynamic unique key and the second previous version of the second dynamic unique key are identical, and (<NUM>) the first current version of the first dynamic unique key and the second current version of the second dynamic unique key are identical.

In some implementations of the system, the first original key has been stored within the first memory of the first component at the time of manufacturing the first component, and wherein the second original key has been stored within the second memory of the second component at the time of manufacturing the second component.

In some implementations of the system, generating a first current version of the first dynamic unique key based on the first previous version of the dynamic unique key is further based on a first current version of the key serial number (KSN) and wherein generating the second current version of the second dynamic unique key based on the second previous version of the second dynamic unique key is further based on a second current version of the KSN.

In some implementations of the system, the transmitting, to the second component the encrypted block of information and the MAC further comprises transmitting the first current version of the KSN, the receiving further comprises receiving the second current version of the KSN, and wherein the second version of the KSN is the first current version of the KSN.

In some implementations of the system, the first encryption key is a public key, the second decryption key is a private key and wherein the block of information is encrypted and decrypted based on an asymmetric algorithm using the public key and the private key.

In some implementations of the system, the first encryption key is a secret key, the second decryption key is the secret key and wherein the block of information is encrypted and decrypted based on a symmetric algorithm using the secret key.

In some implementations of the system, the block of information is encrypted based on at least one of the ElGamal, elliptic curve techniques, paillier cryptosystem, Rivest Shadir Adleman (RSA), and Cramer-Shoup cryptosystem.

In some implementations of the system, the first key is a secret key, the second key is the secret key and the block of information is encrypted and decrypted based on at least one of Twofish, Serpent, Advanced Encryption Standard (AES), Data Encryption Standard (DES), Blowfish, CAST5, Grasshopper, Rivest Cipher <NUM> (RC4), Triple Data Encryption Algorithm (3DES), Skipjack, Safer +/++ and IDEA algorithm using the secret key.

In some implementations of the system, the MAC and the control MAC are generated according to a cipher block chaining message authentication code (CBC- MAC).

In some implementations of the system, the MAC and the control MAC are generated according to at least one of a keyed-hash message authentication code (HMAC), cipher-based message authentication code (CMAC), a one-key CBC-MAC (CMAC) and a parallelizable message authentication code (PMAC).

In some implementations of the system, the cipher block chaining message authentication code uses at least one of a DES algorithm, an AES algorithm, a RC6 algorithm, an IDEA algorithm and a 3DES algorithm.

In some implementations of the system, the block of information comprises one of a personal identification code (PIC) and a correspondence table of a scrambled keypad.

In some implementations of the system, the first component is one of a touch controller and an isolated secured area of a processor and the second component is a secure element.

In some implementations of the system, encrypting the block of information is further based on a current version of a noise acquired from the first component, the first current version of the KSN is based on a first previous version of the noise acquired from the first memory of the first component, wherein the accessing from the second memory of the second component further comprises accessing a second previous version of the noise and wherein the second current version of the KSN is based on the second previous version of the noise and wherein the processor is further configured to cause: storing, in the first memory of the first component, the first current version of the noise as the first previous version of the noise, and storing, in the second memory of the first component, the second current version of the noise as the second previous version of the noise.

In some implementations of the system, system of any of claims <NUM> to <NUM>, where in the first current version of the KSN is further based on a previous version of the KSN, the second current version of the KSN is further based on a second previous version of the KSN and wherein the processor is further configured to cause: storing, in the first memory of the first component, the first current version of the KSN as the first previous version of the KSN, and storing, in the second memory of the first component, the second current version of the KSN as the second previous version of the KSN.

In some implementations of the system, the key serial number is based on multiple previous versions of the noise.

In some implementations of the system, encrypting the block of information is further based on a nonce, and wherein the processor is further configured to cause, after generating a second current version of the second dynamic unique key based on the second previous version of the dynamic unique key: accessing, from the second memory of the second component, a previous acknowledgment key, generating, at the second component, a current acknowledgment key based on the previous acknowledgment key and the noise, generating, at the second component, a current acknowledgment message based on the current acknowledgment key and the nonce, and transmitting, to the first component, the current acknowledgment message.

In some implementations of the system, the processor is further configured to cause: receiving, at the first component, the current acknowledgment message, generating, at the first component, a control current acknowledgment key based on a second previous acknowledgment key and the noise, generating, at the first component, a control current acknowledgement message based on the nonce, and upon determining that the control current acknowledgement message matches the current acknowledgement message, determining that the second component correctly processed the encrypted block of information.

Various exemplary embodiments of the described technology will be described more fully hereinafter with reference to the accompanying drawings, in which exemplary embodiments are shown. The present inventive concept may, however, be embodied in many different forms and should not be construed as limited to the exemplary embodiments set forth herein. Rather, these exemplary embodiments are provided so that the disclosure will be thorough and complete. In the drawings, the sizes and relative sizes of layers and regions may be exaggerated for clarity.

It will be understood that, although the terms first, second, third etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are used to distinguish one element from another. Thus, a first element discussed below could be termed a second element without departing from the teachings of the present inventive concept.

The terminology used herein is only intended to describe particular exemplary embodiments.

In the context of the present technology, "data", "block of information", "plaintext", "cleartext" may refer to information that is used as an input to an encryption algorithm to output a ciphertext or encrypted information.

In the context of the present technology, "encryption" may refer to the process of encoding information so as to only allow one or more authorized parties to read it while precluding unauthorized parties to read it. An authorized party may be an authorized user, an authorized device or an authorized component. Generally, an encryption algorithm receives a plaintext as an input and outputs a ciphertext which can only be read when decrypted. In some embodiments, an encryption algorithm may receive an already encrypted data to input as plaintext.

In the context of the present technology, a "cipher" may refer to algorithm for performing encryption and/or decryption. In some embodiments, stream ciphers may encrypt the bits of information one at a time. In some embodiments, block ciphers may take a number of bits ("block") and encrypt them as a single unit, and may also pad the plaintext so it is a multiple of the block size.

In the context of the present technology, "authentication" may refer to the act of confirming the origin of a component of a device and of the data that it transmits. Such a component may have been installed by the original equipment manufacturer (OEM). Authenticating a component allows other components of the device to confirm the authenticated component as genuine and trusted, thus establishing a secure connection and preventing non-genuine and untrusted components from receiving, transmitting, storing or processing sensitive information. Authentication may be performed using digital certificates, passwords, messages, cryptographic keys and algorithms or other inherent factors.

In the context of the present technology, a "key" may refer to a piece of information or a variable value determining the functional output of a cryptographic algorithm. In the context of encryption, a key may, at least partially, specify the transformation of plain text into ciphertext.

In the context of the present technology, "public-key cryptography", "public key algorithms" or "asymmetric cryptography" may refer to a cryptographic system using a pair of keys; public keys paired with private keys, for authentication, encryption and decryption. A public key may be distributed freely and published. A private key may be kept secret. Generally, data may be encrypted and/or authenticated using the public key and may only be decrypted and/or signed using the corresponding private key. Data may also be encrypted using the private key and decrypted using the public key. Examples of asymmetric key algorithms include DSS, ElGamal, elliptic curve techniques, password- authenticated key agreement techniques, paillier cryptosystem, Rivest Shadir Adleman (RSA), Cramer-Shoup cryptosystem and YAK.

In the context of the present technology, "secret key cryptography," "symmetric cryptography", and "symmetric-key algorithms" may refer to a cryptographic system using the same keys for encryption and decryption. The keys may be identical or there may be a simple transformation to obtain one key from the other. The secret keys may be a shared secret between at least two parties to maintain a secure information link. Generally, symmetric-key cryptography may use stream ciphers or block ciphers. Examples of symmetric keys algorithms include Twofish, Serpent, Advanced Encryption Standard (AES), Data Encryption Standard (DES), Blowfish, CASTS, Grasshopper, Rivest Cipher <NUM> (RC4), Triple Data Encryption Algorithm (3DES), Skipjack, Safer +/++ and International Data Encryption Algorithm (IDEA).

In the context of the present technology, a "cryptographic hash function" or "cryptographic hash algorithm" may refer to an algorithm mapping input data of arbitrary size to an output bit string of fixed size, the hash. The algorithm is designed to be a one-way function, which is a function infeasible to invert, and also so that different input data are very unlikely to produce the same hash. Examples of cryptographic hash functions include SHA, MD, Subhash, WHIRPOOL, RADIOGATÚN.

In the context of the present technology, a "message authentication code" (MAC) may refer to a piece of information used to authenticate a message. A MAC may protect a message's data integrity and authenticity by allowing verifying parties to detect both counterfeit messages and alterations of the content of authentic messages. Generally, a system to generate and verify MACs may include three algorithms: a key generation algorithm selecting a key from a key space, a keyed hashing algorithm returning a MAC given a message and the key, and a verifying algorithm to verify the authenticity of a message given the key and the MAC. A keyed hashing algorithm may be based on a cryptographic hash function (hash-based MAC) or on an encipherment algorithm (cipher-based MAC). Examples of hashed-based MAC algorithms include secret prefix MAC, secret suffix MAC and keyed-hash MAC (HMAC). Examples of cipher-based MAC algorithms include cipher block chaining MAC (CBC-MAC), cipher-based MAC (CMAC), One-key CBC-MAC (OMAC), and parallelizable MAC (PMAC).

In the context of the present technology a "hardware random number generator" or "true random number generator" (TRNG) may refer to a device that generates random numbers from physical processes.

In the context of the present technology, a "pseudorandom number generator" (PRNG) or "deterministic random bit generator" (DRBG) may refer to software methods for generating a sequence of numbers while approximating the properties of sequences of random numbers.

Throughout the present disclosure, reference is made to secure transactions (for example, but without being limitative, contact and contactless transactions), secure elements (for example, but without being limitative, chipset, secured chipset, hardware embedding secured component, software embedding secured component, or firmware embedding secured component) and security standards. Examples of security standards include, without being limitative, certification standards from Europay, MasterCard, and Visa (EMV), EMVCo, MasterCard®, Visa®, American Express®, JCB®, Discover® and from the PCI SSC (Payment Card Industry Security Standards Council), founded by MasterCard®, Visa®, American Express®, Discover® and JCB® and dealing specifically with the definition of security standards for financial transactions. Reference to secure transactions, secure elements, and security standards is made for the purpose of illustration and is intended to be exemplary of the present technology.

In the context of the present technology, a "processor" may refer to a system on chip (SoC), an integrated circuit that integrates components of a computing system in a single chip. A typical SoC may include but is not limited to one or more general-purpose microprocessors or Central Processing Units (CPUs), co-processors such as a digital signal processor (DSP), a Graphics Processing Unit (GPU), and multimedia coprocessors such as MPEG and JPEG encoders and decoders. The SoC may also include modems for various wireless communications interfaces including cellular (e.g. LTE/<NUM>, <NUM>, GSM, CDMA, etc.), Bluetooth, and Wireless Fidelity (Wi-Fi) (IEEE <NUM>). The SoC may include memory controllers for interfacing with on-die or external DRAM memory chips, and on-die memory blocks including a selection of ROM, SRAM, DRAM, EEPROM and flash memory. The SoC may additionally include timing sources, peripherals including counter-timers, real-time timers and power-on reset generators, debug, JTAG and Design For Test (DFT) interfaces, external interfaces, analog interfaces, voltage regulators, power management circuits, etc. The SoC may also include connectivity components such as simple buses or on-chip networks following the ARM® Advanced Microcontroller Bus Architecture (AMBA®) specification connecting these blocks together as known in the art. Some blocks, such as additional integrated circuits, typically memory (flash or RAM), may be packaged separately and stacked on the top of the SoC, a design known in the art as Package-on-package (PoP). Alternatively some blocks, such as additional integrated circuits, may be comprised in distinct integrated circuits (or dies) but packaged together, a design known in the art as a System in Package (SiP).

In the context of the present technology, an "isolated secured area of the processor (ISA)" may refer to a processing entity characterized by specific hardware and/or software components subject to a certification ensuring a specific level of security according to specific security standards. The isolated secured area ensures that sensitive data is stored, processed and protected in a secured and trusted environment of the processor while typically maintaining high processing speeds and large amounts of accessible memory. The isolated secured area may offer isolated execution, secure storage, remote attestation, secure provisioning, trusted boot and trusted path. The isolated secured area allows the processor to operate in two modes: normal world or secure world. The normal world is run by the non-secure area of the processor and may comprise the non-secure Rich Operating System (Rich OS) and the software components and applications that run on top of the Rich OS. The normal world is excluded from accessing resources that are provisioned for exclusive use in the secure world. The secure world is run by the isolated secured area and may comprise the Secure Operating System (Secure OS) and the software components and trusted applications that run on top of the Secure OS. The isolated secure area is the only entity to have access to resources provisioned for use exclusively in the secured area, such as certain delineated ranges of ROM or RAM memory, processor or co-processor configuration registers, and certain peripherals such as display controllers or touch screen controllers, and their associated configuration registers. Some of the resources provisioned for the exclusive use of the isolated secure area may be on the same die or package as the SoC, while others may be contained in a different die or package. Some of the resources may be dynamically provisioned for the exclusive use of the isolated secure area at certain times, while at other times they may be available for use by the normal world. The isolated secured area only runs authorized and trusted applications and provides security against logical attacks generated in the Rich OS environment, attacks aiming to compromise boot firmware, attacks that exploit debug and test interfaces, and other non-invasive attacks. Non-limiting examples of an isolated secured area of the processor include Trusted Execution Environment (TEE), Qualcomm Secure Execution Environment (QSEE), Intel Trusted Execution Technology (TXT), the Trusted Platform Module (TPM), the Hengzhi chip and the IBM Embedded Security Subsystem (ESS) chip. In some embodiments, the isolated secured area of the processor is designed so as to not be accessed, even by a human administrator. In other embodiments, the secure element may be a secure enclave coprocessor, such as the secure enclave present in ARMv8-based processors designed by ARM Holdings and Apple Inc. In some embodiments, the isolated secured area may be implemented partially or completely via a dedicated hardware element such as, but without being limited thereto, a secure element as defined in the paragraph below. Other variations of the isolated secured area may also be envisioned by the person skilled in the art of the present technology without departing from the scope of the present technology.

In the context of the present technology, a "secure element" may refer to a processing entity characterized by specific hardware and/or software components subject to a certification ensuring a specific level of security according to specific security standards. From a hardware perspective, a secure element includes the usual components found in a computing entity: at least one microprocessor (e.g. CPU), memory (e.g. ROM, RAM or FLASH memory), communication interfaces, etc. Specific hardware components may also be included to implement specific functionalities particular to a secure element. For instance, a cryptographic accelerator may be included. Also, various tamper resistance, tamper detection and/or tamper response features may be included to prevent a malicious person from extracting sensitive information from the secure element. Anti-tamper measures may comprise hardware aspects, software aspects, or a combination of hardware and software. Also, certain counter-measures to prevent sidechannel attacks aiming to recover cryptographic keys or other sensitive information may be included in the secure element. Counter-measures against side-channel attacks may include hardware aspects, software aspects, or both. Also, measures to reduce EM emissions, such as shielding, may be included, to protect the secure element from eavesdropping. In the context of financial transactions, the certification of the secure element ensures that various financial entities are willing to use the secure element to store and process critical financial data and associated cryptographic keys, and to perform secured financial transactions using the critical financial data and keys. In some embodiments, the secure element may be solely characterized by software components. The secure element may be, in some embodiments, implemented partially or completely as an isolated secured area of the processor, such as the isolated secured as described in the paragraph above, in which case, the secure element may be implemented, for example, but without being limitative, as a TEE, a TPM and/or an ESS. In other embodiments, the secure element may be a secure enclave coprocessor, such as the secure enclave present in ARMv8 based processors designed by ARM Holdings and Apple Inc. Other variations of the secure element may also be envisioned by the person skilled in the art of the present technology.

In the context of the present technology, a "touch screen" may refer to a touch-sensitive sensor device with an input and/or output interface usually superimposed on top of or integrated with an electronic visual display of an information processing system, the integrated combination of both the touch screen and the visual display being referred to as a "touch display". Touch screens usually work by detecting tactile and/or haptic contact with the touch screen. Touch screen technologies may include, but are not limited to resistive, surface acoustic wave, capacitive, projective capacitive, infrared grid, infrared acrylic projection, optical imaging, dispersive signal technology and acoustic pulse recognition touchscreens. Touch screens may include force sensitive components to detect pressure applied to the screen. Touch screens may also include haptic feedback components. Other variations of the touch screen may also be envisioned by the person skilled in the art of the present technology.

In the context of the present technology, a "touch screen controller" may refer to a controller that detects analog touch signals output by the touch screen, may perform analog-to-digital conversion of the analog output, may perform signal processing steps to condition the signal and deduce the screen coordinates associated with one or more touch events. Typically, but non-limitatively, the coordinates of touch events will be output to a processor using a low-bandwidth serial interface including serial peripheral interface (SPI) and inter-integrated circuit (I<NUM>C) interfaces, as it is known in the art. The touch screen controller may be integrated with the display controller or any other block. Other variations of the touch screen controller may also be envisioned by the person skilled in the art of the present technology.

In the context of the present technology, a "display screen" may refer to an electronic visual display device with an input and/or output interface used to convey visual information the user. Display screen technologies may include, but are not limited to, Liquid Crystal Displays (LCD), displays screens based on Organic Light-Emitting Diode (OLED) technology, displays screens based on active-matrix organic light-emitting diode (AMOLED) technology.

In the context of the present technology, a "display screen controller" may refer to a device capable of inputting digital image data, either from a frame buffer in memory or from a standard digital interface such as MIPI or eDP, and outputting analog or digital video signals suitable for interfacing with the specific display screen technology and at an appropriate frame rate (for example, using LVDS). The display screen controller may be included in the same die or package as the processor SoC, or be a discrete component, or be integrated with the display screen, or a combination. The display screen controller may include functions for image upscaling, downscaling, rotation and blending.

In the context of the present technology, a "trusted user interface (TUI)" may refer to a combination of software, hardware and peripheral resources which may be reserved for the exclusive use of the isolated secure area and may be configured in such a way as to give exclusive and non-interruptible control of the display screen (or a portion thereof) and the touch screen to the isolated secure area and to maintain the integrity and confidentiality of the displayed images and of the touch events generated by the touch screen and controller. The TUI in a device may be subjected to a certification ensuring a specific level of security according to specific security standards. A TUI automatically detects and only allows authorized or trusted applications to access the content of a secure screen memory. In one embodiment, the TUI is one specific mode in which the device is controlled by the isolated secured area of the processor to ensure that the information displayed on the touch screen is from a trusted source and isolated from the operating system. Other variations of the TUI may also be envisioned by the person skilled in the art of the present technology.

Even though the various components defined above are each associated with a definition, it should be understood that each one of the various components should not be construed as being solely limited to the specific functions and/or specifics provided in the associated definition. To the contrary, other functions and/or specifics may be added, removed or combined. In addition, functions and/or specifics may be switched from one component to another component (e.g., a function associated with the touch screen controller may be switched to the touch screen). Some of the various components may also be partially or completely merged together without departing from the scope of the present technology (e.g., the display controller and the processor may be merged together to define a single component).

<FIG> is a block diagram illustrating various exemplary components and features of an illustrative device <NUM> in accordance with one embodiment of the present technology.

In accordance with at least one embodiment described herein, a method and a system for authenticating a component of an electronic device are provided. The electronic device <NUM> (which may equally be referred to as "a device" or "the device") comprises a SoC application processor <NUM> and the SoC processor <NUM> comprises an isolated secured area <NUM>. The device also comprises a LCD display screen <NUM> operatively connected to a display screen controller <NUM>, the display screen controller <NUM> operatively connected to the SoC application processor <NUM>, a projective capacitive (PCAP) touch screen <NUM> operatively connected to a touch screen controller <NUM>, the touch screen controller <NUM> operatively connected to the SoC application processor <NUM> and a secure element <NUM> associated with the SoC application processor <NUM>.

In some embodiments, the electronic device <NUM> may be implemented as any device comprising the components needed to carry a method and a system detailed hereinafter. In some embodiments, the electronic device <NUM> may be a smartphone, a smartwatch and/or a wearable computer, a PDA, a tablet and a computer. In some alternative embodiments, the device may also be embedded in or on objects not solely dedicated to computing and/or information processing functions, such as, but not limited to, a vehicle, a piece of furniture, an appliance, etc..

In the illustrated embodiment, the electronic device <NUM> comprises a mobile package on package (PoP) chipset <NUM>, the PCAP touch screen <NUM> superimposed on the LCD display screen <NUM>, the display screen controller <NUM> and the touch screen controller <NUM>, the secure element <NUM>, a contactless front-end (also known as a Near Field Communication (NFC) controller) <NUM> and a flash memory <NUM>.

In a non-limiting embodiment, the mobile PoP chipset <NUM> comprises a Low Power Double Data Rate (LP DDR) memory <NUM> stacked with the SoC application processor <NUM>. The SoC application processor <NUM> comprises an isolated secured area (ISA) <NUM>, a central processing unit (CPU) <NUM>, a trusted user interface (TUI) <NUM>, a secure read-only memory (ROM) <NUM> and a secure random access memory (RAM) <NUM>. The LP DDR memory <NUM> comprises a secure DRAM memory <NUM>. The mobile PoP chipset <NUM> is connected to the flash memory <NUM>, the flash memory <NUM> comprising secure objects <NUM>.

In some embodiments of the present technology, the electronic device <NUM> may execute a non-secure operating system (OS), such as the Rich OS. Examples of a Rich running on the SoC application processor <NUM> include, but are not limited to, a version of iOS®, or a derivative thereof, available from Apple Inc. ; a version of Android OS®, or a derivative thereof, available from Google Inc. ; a version of PlayBook OS®, or a derivative thereof, available from BlackBerry Inc. It is understood that other proprietary OSs or custom made OSs may be equally used.

In some embodiments of the present technology, the isolated secure area may execute a Secure OS, which is separate, distinct and isolated from the OS being executed by the non-secure area of the processor. The secure OS typically has higher privilege levels than the non-secure OS, which allow it, for example, to exclude the non-secure OS from accessing sensitive resources. The secure OS may be entirely different from the non-secure OS (e.g. a secure microkernel), or may be substantially the same as the nonsecure OS (e.g. a modified version of Linux®).

The touch screen controller <NUM> is connected to the TUI <NUM> by way of a serial peripheral interface (SPI) or inter-integrated circuit (i<NUM>C) interface, serial interfaces known in the art for attaching integrated circuits (ICs) such as processors and microcontrollers. The display screen controller <NUM> is connected to the TUI <NUM> with a mobile industry processor interface display serial interface (MIPI-DSI) or an embedded display port (eDP) connection, communication protocols and serial buses between host and device, as would be recognized by someone skilled in the art. The PCAP touch screen <NUM> is superimposed on the LCD display <NUM>. The secure element <NUM> may be directly connected to the SoC application processor <NUM> by way of a SPI bus interface or indirectly connected to the SoC application processor <NUM> via the contactless front end <NUM>. The secure element <NUM> is also connected to the contactless front end <NUM> by way of a Single Wire Protocol (SWP) interface. The contactless front end <NUM> is connected to the SoC application processor <NUM> with an i<NUM>C interface. In some embodiments, the touch screen controller <NUM> may be securely connected to the TUI <NUM>, such that transmission of data between touch screen controller <NUM> and TUI <NUM> is partially or fully encrypted. In some embodiments, the secure element <NUM> is securely connected to the contactless front-end <NUM> and to the SoC application processor <NUM>, such that transmission of data between the secure element <NUM>, the contactless front-end <NUM> and the SoC application processor <NUM> is partially or fully encrypted. Such examples of devices and connections are only presented for an illustrative purpose, and other variations may be possible, as would be recognized by a person skilled in the art of the present technology.

Reference is now made to <FIG>, which depicts a secure architecture system <NUM> in accordance with some embodiments of the current technology.

Generally, the secure architecture system <NUM> may comprise an encryption module <NUM>, a key serial number (KSN) generation module <NUM>, a dynamic key generation module <NUM> and a message authentication module <NUM>. Each one of the modules <NUM>, <NUM>, <NUM> and <NUM> may be executed in part or entirely by the touch screen controller <NUM> and/or by the secure element <NUM> and/or the ISA <NUM>. As described in the example herein, the secure architecture system <NUM> with the encryption module <NUM>, the KSN generation module <NUM>, the dynamic key management module <NUM> and the message authentication module <NUM> are executed by the touch screen controller <NUM>. In some embodiments, the secure architecture system <NUM> may be executed by secure software executing on the secure element <NUM>. In other embodiments, the secure architecture system <NUM> may be executed by secure software executing on the ISA <NUM>.

Generally, the encryption module <NUM> may be used for encrypting a plaintext message containing sensitive information, such as a PIC or a password, to output an enciphered message. In some embodiments, the method described herein may be, but not necessarily, used with the method described in <CIT> titled SYSTEM FOR AND METHOD OF AUTHENTICATING A USER ON A DEVICE. The touch screen controller <NUM> may receive or acquire a PIN in the form of a KeyBlock <NUM> whose value may be for example [<NUM>,<NUM>,<NUM>,<NUM>]. In some embodiments, to increase the unpredictability of the method, the touch screen controller <NUM> may further receive or acquire a current version of the noise <NUM>, wherein the current version of the noise <NUM> may be collected from the environment of the touch screen controller <NUM>, such as from the randomness of touch event coordinates and/or the timing of the touch events. In other embodiments, the current version of the noise <NUM> may be generated by a TRNG (not depicted) on the electronic device <NUM>. In some embodiments, the current version of the noise <NUM> may be a combination of multiple random noises (not depicted) collected from multiple components of the electronic device <NUM>. The touch screen controller <NUM> may further generate, receive or acquire a number used only once (nonce) <NUM>, which may be generated by a PRNG (not depicted) on the electronic device <NUM>. The KeyBlock <NUM>, the current version of the noise <NUM> and the nonce <NUM> may be concatenated together to form a cleartext <NUM> as an input to an RSA encryption algorithm in the encryption module <NUM>. In some embodiments, the cleartext <NUM> may only be the KeyBlock <NUM>. In other embodiments, the clear text <NUM> may only be the KeyBlock <NUM> concatenated with the current version of the noise <NUM>. The touch screen controller <NUM> may receive or acquire from its memory a public key <NUM>, with a key size typically between <NUM> to <NUM> bits. In some embodiments, the encryption module <NUM> may implement RSA encryption using a public key <NUM> and following the PKCS#<NUM> standard. The public key <NUM> may be used as another input in the RSA encryption algorithm of the encryption module <NUM>. The encryption module <NUM> may then use the cleartext <NUM> and the public key <NUM> in the RSA encryption algorithm to output a ciphertext <NUM>. In some embodiments, another publickey encryption algorithm may be used, such as, but not limited to elliptic-curve cryptography, DiCramer-Shoup cryptosystem, or any other secure algorithm, as it would be recognized by a person skilled in the art of the present technology. In other embodiments, a symmetric-key cryptography algorithm might be used that uses a secret key, such as, but not limited to, AES, Triple DES, Blowfish, Serpent, Twofish or any other secure algorithm, as it would be recognized by a person skilled in the art of present technology.

A key serial number (KSN) generation module <NUM> may also be present. The key serial number generation module <NUM> may be used to generate the first current version of the KSN <NUM>. The first current version of the KSN <NUM> may be between <NUM> and <NUM> bytes long. In some embodiments, the first current version of the KSN <NUM> may be of a different size. The first current version of the KSN <NUM> may be based on a previous version of the noise <NUM>, the previous version of the noise <NUM> acquired from the memory of the touch screen controller <NUM>, the previous version of the noise <NUM> being from a previous transaction. In some embodiments, the first current version of the KSN <NUM> may be further based on a previous version of the KSN <NUM> acquired from the memory of the touch screen controller <NUM>, the previous version of the KSN <NUM> being from a previous transaction. In other embodiments, the first current version of the KSN <NUM> for every transaction may be the result of a function that mixes the previous version of the noise <NUM> and the previous version of the KSN <NUM> through a number of logical or arithmetic operations such as shifting, XORing, addition, etc. As a non-limitative example of the mixing function, the previous version of the KSN <NUM> may be circularly shifted by some number of bits and go through an exclusive or (XOR) operation with the previous version of the noise <NUM>. In some embodiments, the first current version of the KSN <NUM> may not only be based on the previous version of the noise <NUM>, but on multiple previous versions of the noise (not depicted) where a temporary KSN (not depicted) may be defined as the previous version of the KSN <NUM>, and the mixing operation may be repeated several times on the temporary KSN, whereby the temporary KSN may be shifted by some number of bits and go through a XOR operation with a different previous version of the noise each time, for k times. The first current version of the KSN <NUM> may then be defined as the result of this operation. The KSN generation module <NUM> may further store the first current version of the KSN <NUM> as the previous version of the KSN <NUM> in its memory.

The dynamic key generation module <NUM> may be used for generating cryptographic keys so as to secure the secure architecture system <NUM> and use a different key for each session or transaction to prevent or mitigate statistically-based side-channel attacks such as DPA. In the example depicted herein, the dynamic key generation module <NUM> may be used to generate a different secret key for every transaction, as an input to the message authentication module <NUM>. The dynamic key generation module <NUM> may employ a method to derive unique keys per transaction that is based on, adapted from, similar, or identical to that described in ANSI X. <NUM>-<NUM>, also known as the (DUKPT) method. Here, touch screen controller <NUM> may receive or acquire from its memory the first current version of the KSN <NUM>. The first current version of the KSN <NUM> may be used as an input to the dynamic key generation module <NUM>. The touch screen controller <NUM> may acquire, from its memory (not depicted), a first previous version of the dynamic unique key <NUM>, the previous version of the dynamic unique key <NUM> having been used in a previous transaction by the secure architecture system <NUM>. The previous version of the dynamic unique key <NUM> may be based on an original unique key (not depicted). The first previous version of the dynamic unique key <NUM> may be used as an input into the dynamic key generation module <NUM>. The dynamic key management module <NUM> may then generate a first current version of the dynamic unique key <NUM> based on the previous version of the dynamic unique key <NUM> and the first current version of the KSN <NUM>, using a DUKPT-like method. For example, the dynamic key generation module <NUM> may simply use the previous version of the dynamic unique key <NUM> to encrypt, using an algorithm such as DES or AES, the first current version of the KSN <NUM>, in order to obtain the first current version of the dynamic key <NUM>. In some embodiments, the dynamic key generation module <NUM> may be based on other methods used to generate dynamic keys.

The message authentication module <NUM> may be used to generate a message authentication code <NUM>, the message authentication code (MAC) <NUM> for authenticating the message or ciphertext <NUM> together with the touch screen controller <NUM> as the originator of the message. The MAC <NUM> may protect the encrypted block of information's <NUM> data integrity and demonstrate its authenticity. The current version of the dynamic unique key <NUM>, generated by the key generation module <NUM> may be used, together with the ciphertext <NUM>, generated by the encryption module <NUM>, as an input to the message authentication module <NUM>. The message authentication module <NUM> may then use the current version of the dynamic unique key <NUM> and the ciphertext <NUM> as inputs to the cipher block chaining message authentication code (CBC-MAC) method to generate the MAC <NUM>. The message authentication module <NUM> may use an AES, 3DES or any other secure standard block cipher algorithm as the core cipher block of CBC- MAC. Alternatively, the message authentication module <NUM> may use any hash-based MAC generation method, whereby a cryptographic hash function together with the current version of the dynamic unique key <NUM> is used to generate the MAC, for example the secret prefix MAC technique, or the secret suffix MAC technique, or the keyed-hash message authentication code (HMAC) technique. The message authentication module <NUM>, if using a hash-based MAC generation method, may use as the core hash function a cryptographic hash algorithm, such as a SHA-<NUM> or SHA-<NUM> algorithm. An example of a hash-based MAC generation method is the secret suffix method using a SHA3-<NUM> function taking as an input a concatenation of the ciphertext <NUM> and the current version of the dynamic unique key <NUM> and producing a <NUM>-bit MAC. In some embodiments, the message authentication module <NUM> may use other methods or algorithms, such as, but not limited to, data authentication algorithm (DAA), cipher-based message authentication code (CMAC), a one-key CBC-MAC (CMAC), parallelizable message authentication code (PMAC), universal hashing based MAC (UMAC/VMAC) and Polyl305.

Reference is now made to <FIG>, which depicts a secure architecture system <NUM> used for authentication in accordance with some embodiments of the current technology.

The second secure architecture system <NUM> may be executed by a second component of the electronic device <NUM> for authentication of a first component of the electronic device <NUM>. Generally, the second secure architecture system <NUM> may comprise and a second KSN generation module <NUM>, a second dynamic key generation module <NUM>, a second message authentication module <NUM>, a MAC control module <NUM> and a decryption module <NUM>. Each one of the modules <NUM>, <NUM>, <NUM>, <NUM> and <NUM> may be executed in part or entirely by the touch screen controller <NUM> and/or by the secure element <NUM> and/or the ISA <NUM>. As described in the example herein, the second secure architecture system <NUM> with the second KSN generation module <NUM>, the second dynamic key generation module <NUM>, the second message authentication module <NUM>, the MAC control module <NUM> and the decryption module <NUM> and are executed by the second component of the electronic device <NUM>, the secure element <NUM>, for authentication of the first component of the device, the touch screen controller <NUM> and/or the ISA <NUM>. In some embodiments, the secure architecture system <NUM> may be executed by secure software executing on the secure element <NUM>. In other embodiments, the secure architecture system <NUM> may be executed by secure software executing on the ISA <NUM>.

The second KSN generation module <NUM> may be used to generate a second current version of the KSN <NUM>, the second current version of the KSN <NUM> being identical to the first current version of the KSN <NUM>. The second current version of the KSN <NUM> may be generated in a manner identical to the first current version of the KSN <NUM>. The second current version of the KSN <NUM> may be based on a second previous version of the noise <NUM>, the second previous version of the noise <NUM> acquired from the memory of the secure element <NUM>, the second previous version of the noise <NUM> being from a previous transaction. In some embodiments, the second current version of the KSN <NUM> may be further based on a second previous version of the KSN <NUM> acquired from the memory of the secure element <NUM>, the second previous version of the KSN <NUM> being from a previous transaction. In other embodiments, the second current version of the KSN <NUM> for every transaction may be the result of a function that mixes the second previous version of the noise <NUM> and the second previous version of the KSN <NUM> through a number of logical or arithmetic operations such as shifting, XORing, addition, etc. As a non-limitative example of the mixing function, the second previous version of the KSN <NUM> may be circularly shifted by some number of bits and go through an exclusive or (XOR) operation with a second previous version of the noise <NUM>. In some embodiments, the second current version of the KSN <NUM> may not only be based on the second previous version of the noise <NUM>, but on multiple previous versions of the noise (not depicted) where a second temporary KSN (not depicted) may be defined as the second previous version of the KSN <NUM>, and the mixing operation may be repeated several times on the second temporary KSN, whereby the temporary KSN may be shifted by some number of bits and go through a XOR operation with a different previous version of the noise each time, for k times. The second current version of the KSN <NUM> may then be defined as the result of this operation. The second KSN generation module <NUM> may further store the second current version of the KSN <NUM> as the second previous version of the KSN <NUM> in its memory for a future transaction.

The second dynamic key generation module <NUM>, similar to the dynamic key generation module <NUM>, may be used to generate a second current version of the second dynamic unique key <NUM> based on a second previous version of the second dynamic unique key <NUM> acquired or received from another module or component or from the memory of the second component of the electronic device <NUM>, the secure element <NUM>, where the second previous version of the second dynamic unique key <NUM> is based on an original dynamic unique key (not depicted) which may be the same as the original dynamic unique key (not depicted) in secure architecture system <NUM>. Generally, the second dynamic key generation module <NUM> may function exactly as the dynamic key generation module <NUM> and may be used to generate a different secret key for every transaction. The second dynamic key generation module <NUM> may take as an input the second current version of the KSN <NUM> and the second previous version of the dynamic unique key <NUM> to generate the second current version of the dynamic unique key <NUM>. The second dynamic key generation module <NUM> may employ a method to derive the second current version of the dynamic unique key <NUM> that is based on, adapted from, similar, or identical to that described in ANSI X. <NUM>-<NUM>, also known as the (DUKPT) method. The output of the second dynamic key generation module <NUM> may be used as an input to the second message authentication module <NUM>. The second dynamic key generation module <NUM> may then store the second current version of the dynamic unique key <NUM> as the second previous version of the second dynamic unique key <NUM>.

The second message authentication module <NUM> may be used to generate a control MAC <NUM>. Generally, the second message authentication module <NUM> may function exactly as the message authentication module <NUM> to generate the control MAC <NUM> based on the second current version of the dynamic unique key <NUM> and the ciphertext <NUM>.

The MAC control module <NUM> may be used to compare the MAC <NUM> generated by the message authentication module <NUM> of the first component, the touch screen controller <NUM>, and the control MAC <NUM> generated by the second message authentication module <NUM> by the second component, the secure element <NUM>. The MAC control module <NUM> may take as inputs the ciphertext <NUM>, the MAC <NUM> and the control MAC <NUM>. The MAC control module <NUM> may authenticate the first component and determine, based on the comparison of the MAC <NUM> and the control MAC <NUM>, that the touch screen controller <NUM> is an authentic component and the originator of the ciphertext <NUM> and the MAC <NUM>. In case the authentication is positive, the MAC control module <NUM> may forward the ciphertext <NUM> to the decryption module <NUM>.

The decryption module <NUM> may be used to decrypt the ciphertext <NUM> generated by the touch screen controller <NUM>. Decryption may be conditional on the MAC control module <NUM> having, through comparison of the MAC <NUM> and the control MAC <NUM>, determined that the ciphertext <NUM> is authentic. The decryption module <NUM> may access a second key, a private key <NUM> stored in the secure element <NUM> to decrypt the ciphertext <NUM>. The private key <NUM> may be associated with the public key <NUM>. In some embodiments, a symmetric cryptosystem may be used and so the decryption module <NUM> may access a secret key (not depicted) present in the secure element <NUM> associated with a secret key (not depicted) present in the touch screen controller <NUM>. The decryption module <NUM> may also obtain a second current version of the noise <NUM> when decrypting the ciphertext <NUM>, and may further store the second current version of the noise <NUM> as the second previous version of the noise <NUM>. The decryption module <NUM> may also further extract the nonce <NUM> from the cleartext <NUM>.

As it may be understood, a module may be a single instruction of executable code, or many instructions of executable code, and may even be distributed over several different code segments, among different programs, and across several memory devices. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network.

Reference is now made to <FIG>, wherein a communication flow between components of a device is depicted in accordance with embodiments of the current technology.

In the embodiment illustrated in <FIG>, the communication between the touch screen controller <NUM>, the ISA <NUM> and the secure element <NUM> are made through SPI and/or I<NUM>C links connecting the components of the electronic device <NUM>.

The user may have entered, with his fingers or with an electronic pencil, on the PCAP touch screen <NUM> superimposed on the LCD display <NUM>, a PIC in an application of the electronic device <NUM> in the context of a financial transaction. The user may then have pressed a confirmation button. The touch screen controller <NUM> may receive and convert the analog touch events entered by the user on the PCAP touch screen <NUM> superimposed on the LCD display <NUM> into a digital signal in the form of touch event inputs. Touch event inputs may then be further processed in their digital form, for example to generate a sequence of key presses or "key block", such as KeyBlock <NUM>, comprised in the cleartext <NUM>.

The touch screen controller <NUM> may encrypt the cleartext <NUM> with the encryption module <NUM>, resulting in the ciphertext <NUM>. The touch screen controller <NUM> may further generate the first current version of the KSN <NUM> with the KSN generation module <NUM>, generate the first current version of the dynamic unique key <NUM> with the dynamic key generation module <NUM> and generate a MAC <NUM> with the message authentication module <NUM>. The touch screen controller <NUM> may then transmit, to the secure element <NUM> directly or via the ISA <NUM>, the ciphertext <NUM> and the MAC <NUM> for authentication. In one embodiment, the touch screen controller <NUM> may also transmit the first current version of the KSN <NUM>.

The secure element <NUM> may receive the ciphertext <NUM> and the MAC <NUM>. In one embodiment, the secure element <NUM> may also receive the first current version of the first current version of the KSN <NUM>. In some embodiments, the secure element <NUM> may interpret the ciphertext <NUM> and the MAC <NUM> as a request message (not depicted). The secure element <NUM> may generate a control MAC <NUM> based on the ciphertext <NUM>, to authenticate the touch screen controller <NUM> and the ciphertext <NUM>. If the control MAC <NUM> matches the MAC <NUM>, the secure element <NUM> may decrypt the ciphertext <NUM>. In some embodiments, the secure element <NUM> may compute an acknowledgment message (not depicted) as a response to the request message, the acknowledgment message may be based on an acknowledgment key (not depicted) and the nonce <NUM>, as it will be explained below. The secure element <NUM> may then transmit, to the touch screen controller <NUM>, directly or via the ISA <NUM>, the acknowledgment message.

Reference is now made to <FIG>, wherein a method of authenticating a component of a device is depicted in the form of a flow-chart diagram in accordance with embodiments of the current technology.

The method <NUM> may be a first part of a method executed by the first component, the touch screen controller <NUM> to encrypt the block of information, the cleartext <NUM>, and to create a message authentication code <NUM>. The method <NUM> may be executed by the electronic device <NUM> executing the secure architecture system <NUM> as described in <FIG>. In other embodiments, the method <NUM> may be executed by the secure element <NUM>.

A user (not depicted) may need to enter a previously determined PIC on the electronic device <NUM> to confirm his identity during a transaction with a financial institution, to start a transaction with another user, or simply to access the electronic device <NUM> or an application on the electronic device <NUM>. The user may enter his PIC on the electronic device <NUM> via the PCAP touch screen <NUM> superimposed on the LCD display <NUM>. The touch screen controller <NUM> may convert analog touch inputs by the user on the PCAP touch screen <NUM> superimposed on the LCD display <NUM> into touch events and further process touch events to generate keying event inputs, in this case the PIC entry, by the user. After the user has pressed a confirmation key, the method <NUM> may start at step <NUM>.

At a step <NUM>, after having processed touch events and thereby generated the keying events, herein referred to as the KeyBlock <NUM>, the first component, herein the touch screen controller <NUM>, may encrypt a block of information, herein the cleartext <NUM> comprising the KeyBlock <NUM>, based on an encryption key associated with a decryption key stored in a second component of the electronic device <NUM>, herein the secure element <NUM>, so as to generate an encrypted block of information, herein a ciphertext <NUM>. The encryption may be performed using the RSA method following the PKCS#<NUM> standard in the encryption module <NUM> by the touch screen controller <NUM>. The touch screen controller <NUM> may have access to a previously generated public cryptographic key, the public key <NUM>, and may encrypt, using the public key <NUM>, the cleartext <NUM>. In some embodiments, the touch screen controller <NUM> may concatenate a current version of the noise <NUM> collected from the environment of the touch screen controller <NUM> with the KeyBlock <NUM> to form the cleartext <NUM> to be encrypted by the encryption module <NUM>, which outputs a ciphertext <NUM>. In other embodiments, the touch screen controller <NUM> may concatenate the current version of the noise <NUM>, a nonce <NUM> and the KeyBlock <NUM> to form the cleartext <NUM> to be encrypted by the encryption module <NUM>, which outputs the ciphertext <NUM>, as explained in <FIG>. In some embodiments, the touch screen controller <NUM> may encrypt the cleartext <NUM> with a symmetric secret key (not depicted) using a different algorithm rather than the public key of an asymmetric public-private key pair. The method <NUM> may then advance to step <NUM>.

At a step <NUM>, at the same time or at a different time, the touch screen controller <NUM> may access or acquire from its memory a first previous version of a first dynamic unique key <NUM>, the first previous version of the first dynamic unique key <NUM> being at least partially based on a first original unique key (not depicted). The touch screen controller <NUM> may have had a first original key stored in its memory at the time of manufacturing the touch screen controller <NUM>. The first previous version of the first dynamic unique key <NUM> may be derived from the first original unique key by the same method as described below. The method may <NUM> then advance to step <NUM>.

At a step <NUM>, at the same time or at a different time, the touch screen controller <NUM> may generate the first current version of the KSN <NUM>. The first current version of the KSN <NUM> may be generated by the touch screen controller <NUM> with the KSN generation module <NUM> and derived from a previous version of the noise <NUM>, as explained in <FIG>. In other embodiments, the first current version of the KSN <NUM> may be generated by the KSN generation module <NUM> and derived from a previous version of the KSN <NUM> and the previous version of the noise <NUM>, as explained in <FIG>. In some embodiments, the first current version of the KSN <NUM> may be derived from multiple previous versions of the noise (not depicted), as explained in <FIG>. In one embodiment, the first current version of the KSN <NUM> may be associated with the electronic device's <NUM> unique identifier and a number of the transaction, and may be transferred to the dynamic key generation module <NUM>. The method <NUM> may then advance to step <NUM>.

At a step <NUM>, the touch screen controller <NUM> may execute the dynamic key generation module <NUM> to generate a first current version of the dynamic unique key <NUM> based on the first previous version of the first dynamic unique key <NUM> and the first current version of the KSN <NUM>. The first current version of the dynamic unique key <NUM> may be generated using a DUKPT-like method by the key generation module <NUM>, with the previous version of the first dynamic unique key <NUM> and the first current version of the KSN <NUM> serving as inputs. At the same time or at a later time, the first current version of the KSN <NUM> may be stored in the memory of the touch screen controller <NUM> as the previous version of the KSN <NUM> for a future transaction. At the same time or at a later time, the first current version of the dynamic unique key <NUM> may be stored as the previous version of the dynamic unique key <NUM> for a future transaction. The method <NUM> may then advance to step <NUM>.

At a step <NUM>, after having generated the ciphertext <NUM> with the encryption module <NUM> and after having obtained the first current version of the first dynamic unique key <NUM> from the dynamic key management module <NUM>, the touch screen controller <NUM> may execute the message authentication module <NUM> to generate a message authentication code (MAC) <NUM> based on the ciphertext <NUM> and the first current version of the first dynamic unique key <NUM>. The MAC <NUM> may be generated by the message authentication module <NUM> by using a cipher-based method, such as a cipher block chaining message authentication code (CBC-MAC) method, as explained in <FIG>. In some embodiments, a cipher-based MAC (CMAC) may be used to generate the MAC <NUM>. In other embodiments a hash-based method such as a keyed-hash MAC (HMAC) may be used to generate the MAC <NUM>, as explained above. The method <NUM> may then advance to step <NUM>.

At a step <NUM>, the touch screen controller <NUM> may transmit the ciphertext <NUM> and the MAC <NUM> to the secure element <NUM> to authenticate the touch screen controller <NUM> as the originator of the ciphertext <NUM>. In one embodiment, the touch screen controller <NUM> may also transmit the first current version of the KSN to the secure element <NUM>. The method <NUM> may then continue as the method <NUM> at step <NUM> for the secure element <NUM>.

Reference is now made to <FIG>, wherein a method <NUM> of authenticating a component of a device <NUM> is depicted in the form of a flow-chart diagram in accordance with embodiments of the current technology.

The method <NUM> may directly follow the method <NUM>. The method <NUM> may start in a second component of the electronic device <NUM>, such as the secure element <NUM>, after step <NUM> of the method <NUM>. The secure element <NUM> may run a second secure architecture system <NUM>, as depicted in <FIG>, and may execute a second KSN generation module <NUM>, a second dynamic key generation module <NUM>, a second message authentication module <NUM>, a MAC control module <NUM> and a decryption module <NUM>. The secure element <NUM> may have had a second original key associated with the first original key stored in its memory at the time of manufacturing the secure element <NUM>. In other embodiments, the method <NUM> may be executed by the touch screen controller <NUM> to authenticate the secure element <NUM>. The method may start at step <NUM> for the second component.

At a step <NUM>, the secure element <NUM> may receive the ciphertext <NUM> and the MAC <NUM> transmitted by the touch screen controller <NUM>. In one embodiment, the secure element <NUM> may additionally receive the first current version of the KSN <NUM> transmitted by the touch screen controller <NUM>. The method <NUM> may then continue at step <NUM>.

At a step <NUM>, at the same time or at a different time, the secure element <NUM> may access a second previous version of a second dynamic unique key <NUM> located in its memory (not depicted), the second previous version of the second dynamic unique key <NUM> being at least partially based on a second original unique key (not depicted). The second previous version of the second dynamic unique key <NUM> may be identical to the first previous version of the first dynamic unique key <NUM>. The method <NUM> may then advance at step <NUM>.

At a step <NUM>, the secure element <NUM> may generate with the second KSN generation module <NUM>, the second current version of the KSN <NUM>. Generally, the second current version of the KSN <NUM> may be generated in a manner that is identical to the generation of the first current version of the KSN <NUM> by the KSN generation module <NUM>. The second current version of the KSN <NUM> may have been generated by the second KSN generation module <NUM>, and may be based on the second previous version of the noise <NUM> which may be identical to the first previous version of the noise <NUM>. In some embodiments, the second current version of the KSN <NUM> may be further based on the second previous version of the KSN <NUM>. In some embodments, the second current version of the KSN <NUM> may be based on multiple previous versions of the noise (not depicted). In one embodiment, the second current version of the KSN <NUM> may be the first current version of the KSN <NUM> that was transmitted with the ciphertext <NUM> and the MAC <NUM>. The method <NUM> may then advance to step <NUM>.

At a step <NUM>, the secure element <NUM> may execute the second dynamic key generation module <NUM> to generate a second current version of the second dynamic unique key <NUM> based on the second previous version of the dynamic unique key <NUM> and the second current version of the KSN <NUM>. The second dynamic key generation module <NUM> may function in a manner that is identical to the dynamic key generation module <NUM> to generate the second current version of the second dynamic unique key <NUM>. The second current version of the second dynamic unique key <NUM> may be identical to the first current version of the first dynamic unique key <NUM>. The secure element <NUM> may then use the second current version of the second dynamic unique key <NUM> as an input for generating a control message authentication code (MAC) <NUM> by the message authentication module <NUM>. At the same time or at a later time, the second current version of the KSN <NUM> may be stored as the second previous version of the KSN <NUM> in the memory of the secure element <NUM>. The method <NUM> may then proceed at step <NUM>.

At a step <NUM>, the secure element <NUM> may execute the second message authentication module <NUM> to generate the control MAC <NUM> based on the received ciphertext <NUM> and the second current version of the dynamic unique key <NUM>. The method <NUM> may then advance at step <NUM>.

At a step <NUM>, the secure element <NUM> may execute the MAC control module <NUM> to compare the control MAC <NUM>, which was generated based on the second version of the second dynamic unique key <NUM> and the second current version of the KSN <NUM>, with the MAC <NUM> generated by the touch screen controller <NUM> and sent to the secure element <NUM>. Upon determining that the control MAC matches the MAC <NUM>, the secure element <NUM> may determine that the first component, the touch screen controller <NUM>, is authentic and originated the ciphertext <NUM> and the MAC <NUM>. The MAC control module may then transmit the ciphertext <NUM> to the decryption module <NUM>. The method <NUM> may then advance to step <NUM>.

At a step <NUM>, the secure element <NUM> may decrypt, with the decryption module <NUM>, the ciphertext <NUM>. The secure element <NUM> may have access to a second key, the private key <NUM> associated with the public key <NUM>, the private key <NUM> allowing the secure element <NUM> to decrypt the ciphertext <NUM> by executing the decryption module <NUM>. In some embodiments, the decryption module <NUM> may decrypt the ciphertext <NUM> with a secret key (not depicted) from its memory associated with the secret key (not depicted) located in the touch screen controller <NUM> and used for encrypting the ciphertext <NUM> to output the cleartext <NUM>. The decryption module <NUM> may be further configured to split the cleartext <NUM> into the KeyBlock <NUM>, the current version of the noise <NUM> and the nonce <NUM>. At the same time or at a later time, the secure element <NUM> may store the current version of the noise <NUM> in its memory as the second previous version of the noise <NUM> for a future transaction. In some embodiments, the method <NUM> may end. In other embodiments, the method <NUM> may proceed at step <NUM>.

In some embodiments, a request-acknowledgment (REQ-ACK) scheme may be implemented to help ensure secure processing of information by the authentic components and at the same time prevent a loss of synchronization due to message transmission failure and/or power interruptions. The first component, the touch screen controller <NUM>, may require acknowledgment and proof that the second component, the secure element <NUM>, has processed the MAC <NUM> and the ciphertext <NUM>, and will use the current version of the noise <NUM> to generate a future current version of the KSN <NUM>, before generating, at the next transaction a next authentication key (not depicted). To ensure authenticity, the second component, the secure element <NUM>, must prove to the first component, the touch screen controller <NUM>, that is has knowledge of the current version of the noise <NUM> contained in the ciphertext <NUM> through an associated acknowledgment message. If the acknowledgment message is correct, the secure element <NUM> must have decrypted the request message (the ciphertext <NUM>) with the second key present in the secure element <NUM>, the private key <NUM>. Steps <NUM> and <NUM> of method <NUM> describe the additional steps.

At a step <NUM>, the secure element <NUM> may compute an acknowledgment message (not depicted) with an acknowledgment key (not depicted). The acknowledgment key may be computed by performing a circular shift in which a previous version of the acknowledgment key (not depicted) may be shifted by some number of bits and go through a XOR operation with the first current version of the noise <NUM>. The acknowledgment message may then be computed by performing an encryption operation with the acknowledgment key (not depicted) and the nonce <NUM> as inputs. The secure element <NUM> may then transmit, to the touch screen controller <NUM>, the acknowledgment message as proof that it has correctly received and processed the encrypted block of information including the first current version of the noise <NUM>. The secure element <NUM> may then store the acknowledgment key as the previous version of the acknowledgment key for a future transaction. The method <NUM> may then proceed at step <NUM>.

At a step <NUM>, the touch screen controller <NUM> may have a pre-determined time out threshold associated with the reception of the acknowledgment message (not depicted) from the secure element <NUM>. In the case the timeout parameter is over the pre-determined timeout threshold, the touch screen controller <NUM> may resend a request message in the form of the ciphertext <NUM> with its associated MAC <NUM> until the acknowledgment message is received. Once received, the touch screen controller <NUM> may store the acknowledgment message in its memory for comparison with a control acknowledgement message (not depicted). The touch screen controller <NUM> may then compute a control acknowledgement message, in the same manner as described in step <NUM>, using a previously stored acknowledgment key (not depicted) retrieved from its memory and the current version of the noise <NUM>. Upon determining that the received acknowledgement message matches the control acknowledgment message, the touch screen controller <NUM> may determine that the secure element <NUM> has correctly processed the current transaction and updated its internal state accordingly. The touch screen controller <NUM> may then store the acknowledgment key as the previous version of the acknowledgment key for a future transaction. The touch screen controller <NUM> may then allow the next transaction to proceed normally. The method <NUM> may then end.

In some embodiments, the secure element <NUM> may reconstitute a PIC based on KeyBlock <NUM> from the cleartext <NUM>. In other embodiments, the ciphertext <NUM> may be transmitted to the ISA <NUM> before being transmitted to a remote server to finalize the transaction, wherein the remote server may act as the secure element <NUM>.

The methods and systems described in the present disclosure may be executed and applied to any components in an electronic device. Notably, the features and examples above are not meant to limit the scope of the present disclosure to a single embodiment, as other embodiments are possible by way of interchange of some or all of the described or illustrated elements. Moreover, where certain elements of the present disclosure can be partially or fully implemented using known components, only those portions of such known components that are necessary for an understanding of the present disclosure are described, and detailed descriptions of other portions of such known components are omitted so as not to obscure the disclosure. In the present specification, an embodiment showing a singular component should not necessarily be limited to other embodiments including a plurality of the same component, and vice-versa, unless explicitly stated otherwise herein. Moreover, applicants do not intend for any term in the specification or claims to be ascribed an uncommon or special meaning unless explicitly set forth as such. Further, the present disclosure encompasses present and future known equivalents to the known components referred to herein by way of illustration.

The foregoing description of the specific embodiments so fully reveals the general nature of the disclosure that others can, by applying knowledge within the skill of the relevant art(s) (including the contents of the documents cited and incorporated by reference herein), readily modify and/or adapt for various applications such specific embodiments, without undue experimentation, and without departing from the general concept of the present disclosure. Such adaptations and modifications are therefore intended to be within the meaning and range of equivalents of the disclosed embodiments, based on the teaching and guidance presented herein. It is to be understood that the phraseology or terminology herein is for the purpose of description and not of limitation, such that the terminology or phraseology of the present specification is to be interpreted by the skilled artisan in light of the teachings and guidance presented herein, in combination with the knowledge of one skilled in the relevant art(s).

While the above-described implementations have been described and shown with reference to particular steps performed in a particular order, it will be understood that these steps may be combined, sub-divided, or re-ordered without departing from the teachings of the present technology. The steps may be executed in concurrently or sequentially. Accordingly, the order and grouping of the steps is not a limitation of the present technology.

Claim 1:
A method for generating an encrypted and authenticated message by a first component of an electronic device (<NUM>), the message authenticating the first component as the originator of the message, the method comprising:
receiving touch events at an input device (<NUM>) of the first component that identify a personal identification number, PIN, (<NUM>);
receiving noise (<NUM>) obtained from randomness of touch event coordinates;
generating a block of information (<NUM>) comprising a concatenation of the PIN (<NUM>) and the noise (<NUM>);
encrypting the block of information based on a first encryption key (<NUM>) acquired from a first memory (<NUM>) of the first component associated with a second decryption key (<NUM>) in a second component of the device so as to generate an encrypted block of information (<NUM>);
accessing, from the first memory of the first component, a first previous version of a first dynamic unique key (<NUM>), the first previous version of the first dynamic unique key being at least partially based on a first original unique key;
generating a first current version of the dynamic unique key (<NUM>) based on the first previous version of the first dynamic unique key;
generating a message authentication code, MAC, (<NUM>) based on the encrypted block of information and the first current version of the first dynamic unique key; and
transmitting, to the second component the encrypted block of information and the MAC.