Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/38—Payment protocols; Details thereof
  • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
  • G06Q20/3821—Electronic credentials
  • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
  • G06F16/23—Updating
  • G06F16/2365—Ensuring data consistency and integrity
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/60—Protecting data
  • G06F21/602—Providing cryptographic facilities or services
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/60—Protecting data
  • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
  • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
  • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
  • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
  • H04L9/3278—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response using physically unclonable functions [PUF]
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q2220/00—Business processing using cryptography

Definitions

• the present invention relates generally to the field of payment and authorization methods. More particularly this disclosure relates to using a computing device that does not have or does not rely on a secure element to make payments, authorizations or exchange information with other devices.
• the present invention relates to a method and system for improving the security of transaction in an emulated Integrated Circuit (ICC).
• ICC emulated Integrated Circuit
• a communication device can be placed in proximity to an access device such as a point-of-sale (POS) terminal to transfer account information from the communication device to the access device to conduct a transaction.
• POS point-of-sale
• secure elements such as SIM cards, micro- SD cards or mobile phone embedded chips has been looked during quite a long time as the right place to securely store the most sensitive part of mobile applications of the service providers.
• the secure element is considered secure because account information, keys and secret data are stored in tamper- resistant hardware, which protects these information from malware or viruses that may have infected the operating system or an application running on the communication device.
• HCE Host Card Emulation
• the NFC payment application installed into the smartphone comprises libraries including one or more Java libraries and one or more native libraries.
• a native library includes functions written in a conventional language that are compiled into machine code.
• a Java library comprises functions written in a portable language and run by a virtual machine.
• the NFC payment application may include native library for a number of reasons including performance, access to operating system services which are unavailable to Java code, access to legacy code, and other reasons.
• a transaction cryptogram to conduct the transaction is generated at the native library side from information provided by the Java library.
• the transaction can be authorized by the remote computer based on at least the verification and the validation of the transaction cryptogram.
• native libraries may be installed on a user's device before the execution of applications which use the native libraries. Since native libraries are dynamically loaded, by nature they are susceptible to being compromised. It is generally fairly easy to replace a portion of an application, or a library, written in Java. If the native library is compromised, all applications that use that library, whether protected or not, will be compromised as well when the compromised library is used by that application.
• Java has a number of mechanisms to protect Java code from inspection and/or from modification. Some frequently used mechanisms may include signed code, cryptographic obfuscation of the Java Archive (JAR) file and symbolic obfuscation.
• Code signing allows a program to verify the origin of any classes it is going to call.
• Cryptographic obfuscation of the JAR file prevents inspection or modification of the contents without knowledge of the obfuscation key and algorithm, and where a special class loader may be used to de-obfuscate the JAR file at runtime.
• Symbolic obfuscation involves scrambling the symbols of the class files in a JAR file to make it difficult to reverse engineer.
• One traditional means of protecting the integrity of an application is to create a cryptographic binding between its various components.
• the cryptographic binding allows the caller to verify the origin of the code it is going to call.
• it may also allow the callee to verify the origin of the code which called it.
• This technique is most often used to create a binding between two native libraries.
• This technique may also be used to create a binding that protects the integrity of a Java application that contains a native library.
• this method does not adequately prevent the native library from being compromised.
• a hacked native library which replaces the original native library may easily inspect the Java code which called it.
• the keys which are used to create the binding may be easily discovered by the replacement library, allowing the replacement library to successfully impersonate the original library.
• passing the arguments and return values for each call through a cryptographic process negatively affects the performance of the calls into the native library. Therefore, a traditional cryptographic binding degrades the performance of the application while offering minimal integrity protection.
• An attacker may compromise native libraries used by an application either by replacing the library on the file system, or by preloading a native library that exports the same symbols.
• a first native library may export a symbol aaa and a second native library may also export the symbol aaa. If the second native library is loaded before the first native library can be loaded, the Java application that calls for aaa will call the aaa symbol in the second native library instead of the aaa symbol in the first native library because Java uses the first symbol it sees of a particular name. Thus, the second native library (i.e., a rogue native library) will be called instead of the intended first native library.
• Java applications frequently do not need to be installed on a user's computer. They may be downloaded from a network as needed. However, if a Java application uses a native library, that application, or a portion of it typically must be installed. This encumbers the deployment of the application and increases the risk of native library being compromised.
• Embodiments of the present invention address these and other problems individually and collectively. Specifically, embodiments of the invention address the problem of security concerns with conducting payment transactions with a software smart card emulation into a communication device.
• the present invention addresses the aforementioned security drawbacks of transaction with a software smart card emulation into a communication device.
• the present invention provides techniques for enhancing the security of a communication device (e.g., a communication device) when conducting a transaction using the communication device.
• This object is achieved through a method directed to proposing counter- measures against data lifting and code-lifting for dynamically linked native library of a mobile application.
• An embodiment of the present invention proposes a method for securing the use of a shared native library written in a more-secure-but-hard-to-implement environment (low-level language such as C) to protect the computation of the transaction cryptogram while still relying on the less-secure-but-easy-to-implement environment (high-level language such as Java) on the remaining parts to save the cost.
• a more-secure-but-hard-to-implement environment low-level language such as C
• high-level language such as Java
• the transaction execution is performed in native code, through a native shared (dynamically linked) library.
• the present invention propose a method preventing an attacker to code-lift the native shared library, as well as installing a malware on victim's device to monitor the data flow to reuse all the logic without the need to understand what exactly is inside the native shared library.
• the countermeasures method proposed may provide a countermeasure value which may be used as input during the computation of the cryptogram. If the native shared library is compromised, the computed countermeasure value is wrongly computed. With the wrongly computed cryptogram, the transaction will be rejected at the remote computer side.
• none stop condition is inserted into the mobile application when the native library is compromised. Instead, the execution of the mobile application continue corrupting silently the computation of the cryptogram, the malicious individual will not be able to understand why and when the generation of the cryptogram is failing.
• the computation of the countermeasure value may be performed during the computation of the cryptogram.
• the computation of the countermeasure value may be virtually undistinguishable from the cryptogram computation.
• an attacker would not be able to detect the ongoing countermeasures with only the application and/or the software smart card emulation and the undistinguishable countermeasure operations from the cryptogram computation. This makes static and dynamic analysis quite difficult and time consuming for an attacker.
• an anti-cloning device fingerprint countermeasure may be applied on the data transitioning from the component in Java to the native shared library into the mobile application.
• the device fingerprint may be computed at the very first launch of the mobile application. In an embodiment this device fingerprint may be computed on the Java side of the mobile application.
• the computed fingerprint may be stored in a secure storage.
• the device fingerprint is extracted from the secure storage and may be used to encrypt the transaction data to get a first encrypted data before sending to the native library.
• the native library is configured to retrieve the device fingerprint and may decrypt the first encrypted data. If at least one part of the native library has been lifted after the first launch of the application, the retrieved of the device fingerprint may result on a wrong value and the decryption may return an incorrect value. This incorrect value may be used in the computation of the countermeasure value which may be used as input of the computation of the cryptogram which will be sent to a remote computer for verification, validation and authorization of the ongoing transaction.
• the device fingerprint may be generated and stored to the storage during installation of the application and the native library is configured to retrieved the device fingerprint, it may be established a binding between the storage of the application and the native library.
• an anti-replay countermeasure may be applied on the data transitioning between the component in Java into the application to the native shared library and vice versa.
• a timestamp may be generated. This timestamp may be used by the component Java to generate an encryption key. This encryption key may be used to encrypt the first encrypted data to get a second encrypted data before sending it to the native library.
• the native library may request a timestamp from the system and uses it to derive its encryption key. This derived encryption key may be used to decipher the second encryption data. If the timestamp is wrong, the decryption of the second encrypted data may result on an incorrect value.
• This incorrect value may be used in the computation of the countermeasure value which may be used as input of the computation of the cryptogram which will be sent to a remote computer for verification, validation and authorization of the ongoing transaction.
• This countermeasure even if an attacker may capture the data on the stack of the process, he would still have to understand all the logic how the transaction data is ciphered with the timestamp and the device fingerprint to recover the original data.
• an anti-tampering countermeasure may be applied on the data transitioning from the component in Java into the mobile application to the native shared library.
• An integrity key is derived from a mobile application certificate such the public key.
• a first integrity data is generated encoding the transaction data with the derived integrity key.
• a second integrity data is generated encoding the decrypted second encrypted transaction data with the derived integrity key.
• the first integrity data and the second integrity data are compared to validate the authenticity of the transaction data. If validation of the authenticity of the transaction data failed, an incorrect value is returned. This incorrect value may be used in the computation of the countermeasure value which may be used as input of the computation of the cryptogram which will be sent to a remote computer for verification, validation and authorization of the ongoing transaction.
• an anti-tampering countermeasure may be applied on the certificate of the application.
• an integrity key is derived from the certificate of the application.
• An authentication data is generated by encoding the integrity key with an embedded key into the native library. The embedded key and the authentication data may be protected as secrets on the native library side.
• the native library may generate the integrity key from the application certificate and compute the authentication data of said integrity key with its embedded key. The computed authentication data is compared to the secret authentication data to validate the authenticity of the application certificate. If validation of the authenticity of the certificate failed, an incorrect value is returned. This incorrect value may be used in the computation of the countermeasure value which may be used as input of the computation of the cryptogram which will be sent to a remote computer for verification, validation and authorization of the ongoing transaction.
• the countermeasure value computed by the native library may be the result of an integrity check of the transaction data and an integrity check of the application certificate.
• the present invention provides a strong binding between the secure storage, the application, the shared library and the execution time. Further protections can be applied with the timestamp, such as the sequence of timestamp should always be incremental in a small threshold.
• the invention proposes a system for enhancing security of a communication device when conducting transaction using a transaction application installed into the communication device, wherein
• the transaction application comprising a processing unit and a controlling unit, the controlling unit comprising a security module,
• the processing unit being operated to transmit to the security module of the controlling unit, a transaction data
• the security module being configured to:
• the present invention also relates to a transaction application for enhancing security of a communication device when conducting transaction using the communication device, wherein
• the transaction application comprising a processing unit and a controlling unit, the controlling unit comprising a security module,
• the processing unit being operated to transmit to the security module of the controlling unit, a transaction data
• the security module being configured to:
• the computation of the first integrity check value associated with the transaction data comprises the following steps:
• the processing unit being operated to encrypt the transaction data with a generated device fingerprint key to provide a first encrypted data
• the processing unit being operated to encrypt the first encrypted data with a key derived from a generated timestamp to provide a second encrypted data
• controlling unit being operated to decrypt the second encrypted data with a key derived from a generated timestamp to provide a first decrypted data
• controlling unit being operated to decrypt the first decrypted data with a generated device fingerprint key to provide a decrypted transaction data
• controlling unit being operated to transmit to the security module the decrypted transaction data
• the processing unit being operated to apply an integrity algorithm to the transaction data with the application certificate to provide a first integrity data
• the security module being operated to apply the integrity algorithm to the decrypted transaction data with the application certificate to provide a second integrity data
• the security module being operated to apply a comparison operation on the first integrity data and the second integrity data to provide the first integrity check value.
• the device fingerprint is generated by inputting information pertaining to hardware characteristics of the communication device into a one-way cryptographic function that generates a unique sequence of data, the hardware characteristic being a serial number or other assigned hardware identifier of components of the communication device.
• the device fingerprint is a PUF value generated with a physically unclonable function (PUF) circuit.
• PUF physically unclonable function
• the device fingerprint is generated once and stored in a secure storage of the communication device or stored as hard-coded text into the code of both the controlling unit and the processing unit.
• the computation of the second integrity check value associated with the application certificate comprises the following steps:
• the security module being operated to:
• the embedded key and the second authentication data previously generated are stored as hard-coded text into the code of the security module.
• the security module is a white box cryptography or a Trusted Execution Environment.
• the processing unit and the controlling unit are in the form of a software developer kit integrated into the transaction application.
• the processing unit is implemented in platform independent code and the controlling unit is implemented in native code.
• the platform independent code is Java.
• the present invention also relates to a method for enhancing security of a communication device when conducting a transaction using a transaction application of the communication device according to one the previous claims, the method comprising:
• the transaction application of the communication device being operated to: - compute a first integrity check value associated with a transaction data wherein the integrity check value is a return of a verification function of the integrity of the transaction data;
• the present invention also relates to a communication device comprising:
• - a memory coupled to the processor and storing a transaction application that performs operations for enhancing security of the communication device when conducting transaction using the communication device according to any of the previous claims.
• FIG. 1 illustrates the different entities in a communication device involved in a transaction.
• FIG. 2 illustrates an example of implementation of the different entities of a system involved in a transaction.
• FIG. 3 illustrates the different components in a mobile application involved in a transaction.
• FIG. 4 is a logic flow diagram in accordance with an exemplary embodiment of this invention during the computation of a cryptogram.
• FIG. 1 to FIG. 4 may communicate via any suitable communication medium (including the Internet), using any suitable communication protocol.
• Embodiments of the present invention provide techniques for enhancing the security of the communication device when conducting a transaction using the communication device without involving a secure element.
• the techniques described herein can be used with a communication device that may or may not have a secure element, because the techniques do not require the use of a secure element but the secure element could be present.
• the present invention provide techniques for enhancing the security of the communication device when conducting a transaction using the communication device by using an emulated Integrated Circuit Card ICC also called emulated ICC card.
• the emulated integrated circuit card ICC is an emulated smart card.
• the emulated smart card is an emulated banking card, such as an emulated EMV card.
• Emulation refers to the use of a computer program or hardware to provide (i.e., emulate) the functionality of other software or hardware.
• An emulator can include modules that correspond to hardware components of an emulated device.
• an emulator can provide emulation of a central processing unit (CPU), memory subsystem, and input/output devices.
• CPU central processing unit
• memory subsystem memory subsystem
• input/output devices input/output devices.
• an operating system and other applications can be interpreted by the emulator, rather than being run by native hardware.
• a software- based emulator can also emulate a particular hardware architecture than the architecture of a host device on which the emulator executes.
• an emulator is configured to emulate the integrated circuit (e.g., a CPU) that has a different instruction set than a physical integrated circuit of the host device.
• the emulated integrate circuit can duplicates the instruction cycle and instruction cycle timing of the physical integrated circuit.
• the emulated ICC card can include emulated hardware, operating systems, software modules, applications, plugins, runtime environments, graphics engines, input/output methods, drivers, abstraction layers clients, connection protocols, security protocols, storage, memory, and virtualized peripherals. Further, the emulated ICC card can select different CPU instructions sets for operation that can be different from the instruction set used by the CPU of the host device.
• the emulated ICC card can execute on an operating system (OS) of a host device and can enable device-based authentication/authorization services for mobile and electronic commerce merchants and service providers.
• OS operating system
• the emulated ICC card can provide transaction authorization request through a mobile application and cloud-based web services in a secure manner.
• the emulated ICC card enables the secure storage, exchange, and transmission of information to and from various forms of mobile and non-mobile devices, instruments, computers, and other systems.
• various devices, systems, programs, instruments, and equipment can be emulated using the techniques described herein, such as, kiosks, workstations, handheld devices for point of sale systems, banking devices, automated teller machines, retail and payment systems, healthcare devices, defense and government equipment, voting and data collection devices, and other data storage and transmission devices.
• a cryptogram may refer to an encrypted representation of some information.
• a cryptogram can be used by a recipient to determine if the generator of the cryptogram is in possession of a proper key, for example, by encrypting the underlying information with a valid key, and comparing the result to the received cryptogram.
• An issuer may typically refer to a business entity (e.g., a bank) that maintains an account for a user that is associated with a communication device such as an account enrolled in the mobile application 18 installed on the communication device 10.
• An issuer may also issue account parameters associated with the account to a communication device.
• An issuer may be associated with a host system that performs some or all of the functions of the issuer on behalf of the issuer.
• An access device may be any suitable device for communicating with a merchant computer or payment processing network, and for interacting with a payment device, a user computer apparatus, and/or a user mobile device.
• An access device may generally be located in any suitable location, such as at the location of a merchant.
• An access device may be in any suitable form.
• Some examples of access devices include POS devices, cellular phones, PDAs, personal computers (PCs), tablet PCs, hand-held specialized readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), kiosks, security systems, access systems, Websites, and the like.
• An access device may use any suitable contact or contactless mode of operation to send or receive data from, or associated with, a portable communication device.
• an access device may comprise a POS terminal
• any suitable POS terminal may be used and may include a reader, a processor, and a computer-readable medium.
• a reader may include any suitable contact or contactless mode of operation.
• exemplary card readers can include radio frequency (RF) antennas, optical scanners, bar code readers, or magnetic stripe readers to interact with a portable communication device.
• RF radio frequency
• a key may refer to a piece of information that is used in a cryptographic algorithm to transform input data into another representation.
• a cryptographic algorithm can be an encryption algorithm that transforms original data into an alternate representation, or a decryption algorithm that transforms encrypted information back to the original data. Examples of cryptographic algorithms may include triple data encryption standard (TDES), data encryption standard (DES), advanced encryption standard (AES), etc.
• TDES triple data encryption standard
• DES data encryption standard
• AES advanced encryption standard
• An authorization request message may be an electronic message that is sent to request authorization for a transaction.
• the authorization request message can be sent to a payment processing network and/or an issuer of a payment card.
• An authorization request message according to some embodiments may comply with ISO 8583, which is a standard for systems that exchange electronic transaction information associated with a payment made by a user using a payment device or payment account.
• the authorization request message may include information that can be used to identify an account.
• An authorization request message may also comprise additional data elements such as one or more of a service code, an expiration date, etc.
• An authorization request message may also comprise transaction information, such as any information associated with a current transaction, such as the transaction amount, merchant identifier, merchant location, etc., as well as any other information that may be utilized in determining whether to identify and/or authorize a transaction.
• the authorization request message may also include other information such as information that identifies the access device that generated the authorization request message, information about the location of the access device, etc.
• source code refers to programming code that is a platform independent code.
• the source code is interoperable as it may be run without being modified on any kind of devices such as an integrated circuit card ICC which supports a virtual machine VM. It is written in a portable language and run by a virtual machine. Once compiled, the source code generates virtual machine instructions;
• - virtual machine instructions refers to programming code that is run through a virtual machine instead of a unit processor, such as the unit processor of the ICC.
• Such programming code is a platform-independent code.
• Said virtual machine instructions are issued from the compilation of source code;
• a virtual machine VM is an interpreter which decodes and executes virtual machine instructions
• a native function refers to programming code which when compiled generates a native code
• - native code (also called machine language) refers to programming code that is configured to run on the unit processor. Native code will generally not run if used on a unit processor other than the one it was specifically written for. It is a platform- dependent code.
• a native code is linked to the emulated unit processor of said emulated integrated circuit card;
• an operation (also called functionality) refers to a functional process
• an instruction refers to a code instruction.
• the source code may be written in Java, .NET or JavaCardTM or any existing platform independent language.
• the native function may be written in the C language, assembler language or
• Some embodiments are described herein in the context of an EMV-compliant payment transaction at a merchant Point of Sale (POS) terminal using near field communications (NFC).
• POS Point of Sale
• NFC near field communications
• the embodiments described herein may be used in connection with ATM transactions, unattended kiosk or vending machine transactions, e-commerce and other similar transactions.
• protocol variations on EMV for NFC transactions may be employed with other protocols or standards.
• a user communication device 10 comprises a native operating system 1 1 executing on a device hardware 12.
• the user device 10 can be a mobile or other device, such as a smartphone, smart watch, smart glasses, tablet computer, desktop computer, portable computer, television, gaming device, music player, mobile telephone, laptop, palmtop, smart or dumb terminal, network computer, personal digital assistant, wireless device, information appliance, workstation, minicomputer, mainframe computer, or other computing device that can execute the functionality described herein.
• the native operating system 1 1 can be a mobile, desktop, server, or other operating system such as an Apple iOS® platform, a Google AndroidTM platform, a Microsoft Windows® operating system, an Apple OS X® operating system, a Linux® operating system, a variants of a UNIX® operating system, and the likes.
• Device hardware 12 can include one or more processors suitable for the execution of a computer program, including both general and special purpose microprocessors.
• a processor receives instructions and data stored on a read-only memory or a random access memory or both.
• Information carriers suitable for embodying computer program instructions and data include all forms of nonvolatile memory.
• One or more memories can store instructions that, when executed by a processor, form the modules and other components described herein and perform the functionality associated with the components.
• the processor and the memory can be supplemented by, or incorporated in special purpose logic circuitry.
• the user device 10 can include a plurality of software processing modules stored in a memory and executed on a processor.
• the program modules can be in the form of one or more suitable programming languages, which are converted to machine language or object code to allow the processor or processors to execute the instructions.
• the software can be in the form of a standalone application, implemented in a suitable programming language or framework.
• a software processing module of the user device 10 comprises the emulated ICC card 13.
• the emulated ICC card 13 can include emulated hardware 14 and emulated software, such as emulated operating system 16.
• Emulated hardware 14 can include one or more emulated processors, such as emulated central processing unit (CPU) 15, emulated memories and other storage mediums, emulated input and/or output devices, emulated communications ports and other interfaces, and so on.
• the emulated operating system 16 can be configured to communicate with the native operating system 1 1 through an emulated network interface of the emulated ICC card 13.
• the emulated ICC card 13 can also comprise services container 17, in which one or more services can execute.
• the services 17 can include, but are not limited to, secure input/output, storage, key management, Quick Response Code (QRC) management, near field communication (NFC), mobile applications 18, Host Card
• Emulation and other security and storage services are Emulation and other security and storage services.
• the mobile application 18 may be provided by a mobile application provider.
• the mobile application 18 may be a mobile banking application or a separate mobile payment application.
• the provider is a mobile wallet provider such as a mobile network operator or third- party wallet provider that supports multiple issuers
• the mobile application 18 may be a mobile wallet application.
• the mobile application 18 may be a merchant's own mobile application from which consumers can conduct e-commerce or point of sale transactions with that merchant, or may be a mobile wallet application that supports multiple merchants.
• the provider of the mobile application 18 can be others suitable entities.
• the card emulation technology e.g., Host
• HCE Card Emulation
• OS operating system
• Examples of contactless interface may include one or more radio frequency
• contactless interface may include an optical interface (e.g., a display screen) to present payment information in the form of an image such as a quick response (QR) code, or bar code, etc. to a contactless which includes an optical code scanner or reader.
• optical interface e.g., a display screen
• the mobile application 18 comprises a processing unit 18a and a controlling unit 18b.
• the controlling unit 18b may comprise a security module 29.
• the security module 29 may be implemented with a highest level of security.
• the security module 29 may comprise a White box cryptographic, or "WB cryptographic,” which is a unique cryptographic technology that protects cryptographic algorithms so that their operations can execute within a hostile environment without leaking a cryptographic key and other cryptographic values.
• WB cryptographic White box cryptographic
• the security module 29 may comprise a TEE (Trusted Execution Environment).
• the processing unit 18a of the mobile application 18 is implemented in Java and the controlling unit 18b in native code.
• the processing unit 18a and the controlling unit 18b of the mobile application can be in the form of a software developer kit (SDK)) integrated into the mobile application to support the transaction functionalities.
• SDK software developer kit
• the processing unit 18a and the controlling unit 18b may perform functions to facilitate transactions such as to generate transaction cryptograms for transmission to a remote system 21 .
• the components of system 20 may include a remote system 21 to manage transactions conducted using the communication device 10.
• the remote system 21 may be implemented using one or more computing devices or computers, such as one or more server computers, and can be associated with or be operated by a service provider such as an issuer, payment processor, and/or other suitable entities.
• the remote system 21 may manage user accounts, provide verification functions for transactions, manage lifecycle messages from issuer/host system, as well as initiate lifecycle management events.
• remote system 21 To ensure that the transactions are processed appropriately, several core functions are implemented in the remote system 21 (not shown) to manage the deployment and usage of the account parameters. These functions may include provisioning, active account management, verification for payment, transaction processing, lifecycle management, and post-payment processing.
• the remote system 21 may perform enrollment functions to enroll a mobile cardholder, and a set of provisioning functions that facilitates the preparation and delivery of account parameters.
• the remote system 21 may perform account parameters replenishment functions to facilitate the account parameter replenishment process for the provision on communication device, and account management functions that manage the replenishment.
• the processing unit 18a of the application may comprise a provisioning service 22 configured to facilitate communications between the mobile application 18 executing on the communication device 10 and other entities in the remote system 21 .
• the provisioning service 22 may communicate with the remote system 21 via a communications network such as the Internet.
• the provisioning service 22 may implement authentication and signature functionalities to authenticate the user and/or the communication device 10 when the communication device 10 communicates with the other entities of the remote system 21 .
• the authentication functionalities may ensure that a user and/or a communication device communicating with the system is an authorized one.
• the provisioning service 22 may comprises a set of provisioning functions that facilitates the management of account parameters.
• the provisioning service 22 may comprise account parameters replenishment functions to facilitate the account parameter replenishment process from the remote system 21 on the communication device 10.
• the processing unit 18a may comprise a digitized card manager 23 configured to manage appropriately on the communication device the set of account parameters provided to the mobile application 18b by the remote system 21 .
• the digitalized card manager 23 comprises a set of functionalities to manage account parameters for transactions conducted using the user communication device 10.
• the processing unit 18a of the application 18a may comprise a Card Holder Code Verifier 25.
• This Card Holder Code Verifier 25 provides the means to manage in a secure way user inputs in the format of digits. It can be used to manage PIN and activation code inputs.
• the processing unit 18a may comprise a payment service 26.
• This component may comprise:
• the payment engine 28 may be a component completely implemented in a native code, C or C++.
• the payment engine 28 may implement VISA, MasterCard payment flows, and/or any transaction flow.
• the native library of the controlling unit 18b may be embedded in a Java Native Interface (JNI) library.
• JNI Java Native Interface
• the Java Native Interface (JNI) may provide a facility to bridge two-way interoperations and interactions between the Processing unit 18a Java world (which includes a JVM, Java applications, and libraries in bytecode loaded within the JVM) and the controlling unit 18b native code world (which applications or shared libraries are written in other languages, such as
• the JNI of the controlling unit 18b may comprise a native shared library 30.
• the native shared library 30 may include native language code.
• Native language code includes native language instructions
• native language code can include a C language function and/or subroutine.
• the native shared library 30 may provide a standard interface for Java applications.
• the JNI may comprise at least one security module 29 implemented in native functions (C/C++).
• the security module 29 can co-execute within the JVM via the JNI so that the given
• Java application can invoke secure operations within the security module 29 where such secure operations can access the Java application and other Java library code loaded within the JVM and perform protections.
• the security module 29 acts as the root of the trust and as a protection trampoline and engine within the JVM to launch and perform the various cryptography computation of the authorization request to be send to the remote system 21 .
• the security module 29 is a White box cryptographic, or WB cryptographic, which is a unique cryptographic technology that protects cryptographic algorithms so that their operations can execute within a hostile environment without leaking a cryptographic key and other cryptographic values.
• WB cryptographic White box cryptographic
• FIG. 4 illustrates an example communication flow between a Java processing unit 18a and the native controlling unit 18b during a transaction, according to some embodiments.
• a certificate is associated with the mobile application 18.
• the certificate will usually be authorized by a body known as a certification authority (i.e., certificate authority) which stores the public key in a database and distributes it to any other entity which requests it.
• the public/private key pairs of the certificate may be generated using RSA or elliptic curve cryptography (ECC) techniques as well as any other relevant techniques associated with public key infrastructure (PKI).
• ECC elliptic curve cryptography
• PKI public key infrastructure
• the public key PK of the certificate may be used to derivate key which will be involved to the computation of the countermeasure value.
• a key derivation function may be applied to the public key PK to derive the key APP_SIG_KEY.
• the key derivation may be a key derivation hash function as a SHA256.
• a master derivation key (MDK) associated to the mobile application 18 is used to generate an authentication key WB_APP_SIG_KEY.
• This authentication key WB_APP_SIG_KEY can be generated by a remote key management system during compilation time of the native library.
• the authentication key WB_APP_SIG_KEY may be stored into the secure module 29 of the controlling unit 18b of the mobile application 18.
• the authentication key WB_APP_SIG_KEY is stored as hard-coded text into the code of the secure module 29.
• An authentication data WB_APP_SIG is generated by encoding the derived key APP_SIG_KEY with the authentication key WB_APP_SIG_KEY with an encoding algorithm that takes the derived key APP_SIG_KEY and the authentication key WB_APP_SIG_KEY as inputs and generates the authentication data as an output.
• the encoding algorithm is a symmetric key encryption algorithm.
• the symmetric key encryption may include block cipher algorithms, such as the Data Encryption Standard (DES) based algorithm(s) and Advanced Encryption Standard (AES) based algorithm(s), and stream cipher algorithms, such as RC4.
• DES Data Encryption Standard
• AES Advanced Encryption Standard
• RC4 stream cipher algorithms
• the encoding algorithm is an integrity algorithm.
• the integrity algorithm may be a hash algorithm or any suitable algorithm that may be, for example, one version of a cyclic redundancy check (CRC) algorithm, message-digest (MD) algorithm, or secure hash algorithm (SHA).
• CRC cyclic redundancy check
• MD message-digest
• SHA secure hash algorithm
• the integrity function used to generate the authentication data is a one-way mathematical function. That is, the derived key APP_SIG_KEY and the authentication key WB_APP_SIG_KEY cannot be recovered from the authentication data. Also, the authentication data is unique to the particular derived key APP_SIG_KEY and the authentication key WB_APP_SIG_KEY that are used.
• the computed authentication data WB_APP_SIG may be stored into a secure memory.
• the authentication data WB_APP_SIG is stored as hard- coded text into the code of the secure module 29.
• This embedded authentication data WB_APP_SIG serves to ensure that the certificate (public key) of the transaction application 18 remains unaltered during a transaction. It should be noted that step 41 may start before or during compilation time of the native side of the mobile application 18.
• a device fingerprint DF to protect against subversion by substitution may be generated.
• the device fingerprint DF may be generated by inputting information pertaining to hardware characteristics of the communication device 10 into a cryptographic hash function.
• the cryptographic hash function in this example, is preferably a one-way cryptographic function that generates a unique sequence of bits or hash code.
• the hardware characteristic may be a serial number or other assigned hardware identifier of components of the communication device 10.
• the device fingerprint DF may be a PUF value generated with a physically unclonable function (PUF) circuit.
• PUFs are functions that are derived from the inherently random, physical characteristics of the communication devicel O in which they are built. For example, a silicon PUF may exploit variations in the delay through interconnects and gates or slight differences in threshold voltage. Since the PUF exploits physical variations of the device or material in which it is built, each PUF should provide a unique (although perhaps noisy) response.
• the generated device fingerprint DF and the associated public key PK of the mobile application 18 may be stored in a secure storage SS of the emulated ICC card 13.
• the generated device fingerprint DF and the associated public key PK of the mobile application 18 may be stored in a storage of the communication device 10.
• step 42 may start before, during the compilation time of the mobile application 18 or at the very first launch of the mobile application 18.
• the generated device fingerprint DF and the public key PK may be stored as hard-coded text into both the code of the native library 30 during compilation time.
• This device fingerprint DF may be generated after the communication device 10 is manufactured and before it is packaged for shipment to the first distributor in the supply chain.
• this generated device fingerprint DF stored into the device communication may be requested and stored into the secure storage SS by the mobile application 18 at the first launch of said mobile application.
• the device fingerprint DF generation and storage of the device fingerprint DF are merely examples, various existing methods and means for obtaining the device fingerprint data and storage may be used and others data can be employed as device fingerprint DF such as an identifier of the CPU, sensors identifiers, etc.
• the communication device 10 can be used to execute a transaction.
• the executed transaction is by contactless, for example, by placing the communication device in proximity to a contactless reader of an access device 27.
• the mobile application 18 may receive, store, and/or dynamically build information such as transaction flow parameters related to the contactless transaction in order to return the necessary information to the contactless reader for the transaction to be successfully executed.
• the Java processing unit 18a may extract the device fingerprint DF from the secure storage SS, in step 43.
• this extracted device fingerprint DF is used to encrypt transaction data D received by the mobile application 18 from the access device 27.
• the transaction data D may comprise authorized amount, other amount, terminal country code, terminal verification results, transaction currency code, transaction data, transaction type, and/or an unpredictable number etc.
• the processing unit 18a encrypts the transaction data D with the device fingerprint DF to provide as output an encrypted data D1 .
• a timestamp engine (not illustrated) of the mobile application 18 may generate a first timing information (e.g., such as timestamps, sequence numbers, or the like).
• the generated first timestamp may be used for any suitable purpose, such as stamping the transaction data D with a capture time or interval.
• the timestamp engine may use a clock of the communication device 10 to generate the first timestamp.
• the first timestamp may be a time interval which is bound with the transaction data D.
• the timestamp engine generates a first timestamp having a predetermined number of bits and including a count field. The count indicates the time interval since the timer was started. The time interval may be defined according to a predetermined interval of time needed by the mobile application 18 to compute the cryptogram transaction.
• the processing unit 18a may derive a first encryption key K from the generated timestamp.
• K may be obtained from several existing different algorithms (not described) in use for deriving a key from data.
• the first encryption key K may be used to encrypt the encrypted transaction data D1 to get a verifier data D2.
• the verifier data D2 is sent to the payment engine 28 of the native controlling unit 18b through the native shared library.
• the Java processing unit 18a may extract the mobile application certificate public key PK from the secure storage SS.
• a key derivation function of the processing unit 18a may be applied to the public key PK to derive the key APP_SIG_KEY.
• the processing unit 18a may apply an integrity algorithm to the transaction data D with the derived key APP_SIG_KEY to provide an integrity data D3.
• the integrity algorithm may be a one-way cryptographic function that generates a unique sequence of bits.
• the integrity algorithm may be a hash algorithm or any suitable algorithm that may be, for example, one version of a cyclic redundancy check (CRC) algorithm, message-digest (MD) algorithm, or secure hash algorithm (SHA).
• CRC cyclic redundancy check
• MD message-digest
• SHA secure hash algorithm
• the integrity data D3 may be send to the secure mobile 29 of the controlling unit 18b through the native library 30.
• the native library 30 may process all the data received and extract all the data needed and send them to the security module 29 for computation of the cryptogram.
• step 53 to step 61 are performed on native library 30 side.
• a second timestamp is generated.
• the native library 30 may derive a second encryption key K' from the generated second timestamp.
• the second encryption key K' may be used to decrypt the received verifier data D2 to get a decrypted encrypted transaction data D1 '.
• the native library 30 may extract the device fingerprint DF from the secure storage SS or from its code.
• the device fingerprint DF is generated by the native library 30 according to the generation mechanism implemented in step 42.
• this extracted device fingerprint DF is used to decrypt the decrypted encrypted transaction data D1 ' returned by step 55.
• the native library 30 may provide in return a decrypted transaction data D'.
• the native library 30 may send the decrypted transaction data D' to the security module 29 for the computation of the cryptogram.
• the native library 30 may extract the device certificate public key
• a key derivation function of the native library 30 may be applied to the public key PK to derive the key APP_SIG_KEY.
• the native library 30 may send the key APP_SIG_KEY to the security module 29 for the computation of the cryptogram.
• the security module 29 may apply the derivation algorithm to the public key PK to derive the key APP_SIG_KEY.
• the native library 30 may send the public key PK to the security module 29.
• step 62 to step 66 are performed on the security module 29 side to generate the computation of the cryptogram transaction from data received from the native library 30.
• the security module 29 may apply the integrity algorithm to the received decrypted transaction data D' with the derived key APP_SIG_KEY to provide an integrity data D3'.
• the security module 29 may compare the integrity data D3 received at step 52 with the computed integrity data D3' in step 62. This comparison may return a first check value Mc. In case the first check value is not correct (different of zero), i.e., in case the integrity check fails, it can be determined that at least one of the following component is corrupted: the storage, the transaction data, the timestamp, and/or the device fingerprint DF.
• the security module 29 may extract the embedded key WB_APP_SIG_KEY from its code.
• the security module 29 may generate an authentication data WB_APP_SIG' by applying the same algorithm than step 41 in conjunction with the extracted embedded key WB_APP_SIG_KEY and the received derived key APP_SIG_KEY.
• the security module 29 may extract the stored authentication data WB_APP_SIG from its code.
• the security module 29 may compare the extracted authentication data WB_APP_SIG with the computed authentication data WB_APP_SIG' in step 64. This comparison may return a second check value Mi. In case the second check value is not correct (different of zero), i.e., in case the integrity check fails, it can be determined that the application certificate is corrupted.
• the security module 29 may compute a countermeasure value through an operation of the first check value Mc and the second check value Mi. In an embodiment, this operation may be an addition.
• the native library 30 provides, at step 67, the transaction data D received from the access device 27 to the security module 29.
• the security module 29 may generate a new transaction data D" from the transaction data D received from the access device 27 and the computed countermeasure value though a transformation operation.
• the transformation operation is configured so that the transaction data D is equal to the new transaction data D" when none integrity checks failed. If the integrity check at step 63 and step 65 are correct, the countermeasure value may be equal to zero.
• the new transaction data D" is then equal to the received transaction data D.
• the transformation operation may be an addition in this example.
• the security module 29 computes the transaction cryptogram with the new transaction data D".
• the cryptogram can be understood as a signature on the new transaction data D".
• the security module 29 generates the cryptogram by encoding the new transaction data D" with a session key using for example a hash function that takes the new transaction data D" and the session key as inputs and generates the cryptogram as an output.
• the hash function used to generate the cryptogram is a one-way mathematical function. This cryptogram may be computed according to the EMV specifications published by EMVCo and available on EMVCo's web site.
• the access device 27 may generate a transaction authorization request message to request authorization of the transaction from the issuer.
• the transaction authorization request message may include at least the track-2 equivalent data and the transaction cryptogram.
• the transaction authorization request is sent by the access device 27 to the remote system 21 for verification and validation.
• the remote system 21 can generate a cryptogram from the transaction data D using its known cryptographic key and comparing it to the cryptogram that was generated by the controlling unit 18b.
• the remote system 21 rejects the transaction.
• the user can be notified of the failure.
• the user device can be blacklisted of performing transaction.
• the different steps processed by the java processing unit 18a, the native library 30 and the security remote 29 described above is just an example, and that the messaging sequence in some embodiments may have different variations.
• the computation of the verifier data D2 and the integrity data D3 into the processing unit 18a may be performed in parallel or sequentially.
• the computation of the transaction data D' and the key APP_SIG_KEY into the native library may be performed in parallel or sequentially.
• the computation of the first check value Mc and the second check value Ml into the security module 29 may be performed in parallels or sequentially.
• the device communication is a smartphone and the mobile application is a contactless payment application.
• An HCE-based NFC payment SDK (where there is no presence of a Secure Element) is implemented.
• the SDK contains all the flows from provisioning, replenishment of one-time-use transaction keys (under EMV tokenization technology), and the transaction itself.
• Most of the components are coded in Java.
• the transaction execution (APDU exchange and cryptogram generation) is performed in native C, which is done in a shared (dynamically linked) library for example an ELF-formatted .so file.
• CM Comparison Masking function to create a mask that indicates if the integrity data D3 is corrupted or not
• WB_APP_SIG The checksum of PK generated with a key WB_APP_SIG_KEY.
• the WB_APP_SIG being pre-configured before or during building the White Box.
• WB_APP_SIG_KEY an authentication key that is used to validate the authenticity of the PK.
• the WB_APP_SIG_KEY being pre-configured before or during building the White Box.
• the device fingerprint may be computed from Java side. It is computed for this implementation at the very first time the SDK is used (after application installation), and persisted to the secure storage for any subsequent use. For Native side, the fingerprint may be read from the storage every time it is used or generated.
• the device fingerprint DF may be composed of the following data:
• This countermeasure not only binds the transaction data D with the fingerprint of the device but also binds the transaction data D to the Secure Storage of the SDK (as the fingerprint is generated in the Java interface only once), using a function called AC, as described below:
• the decryption (reversion of AC, or AC "1 ) of D1 is the same as AC.
• the decryption is performed in the native side (Payment Engine).
• this timestamp may be associated with a current time window called Precision Range (PR).
• PR Precision Range
• This timestamp binds the transaction data D with the current time window using a function called AR.
• the pair of (PR, 2 * PR) may be used to indicate the minimum and maximum acceptable time differences wherein derived key from the timestamp is accepted.
• the pair of (PR, 2 * PR) is determined according to the interval of time since the data is prepared in Java until it reaches the JNI.
• the derived key from the timestamp is considered accepted according to the followings rules:
• the derived key from the timestamp is the expected one
• the derived key from the timestamp may be the expected one (but not guaranteed, depending on which timeframes).
• AR -1 The AR and reverse AR (AR -1 ) functions have the following implementation:
• the PR is set at 10 milliseconds.
• the data D1 is now ready to be used by the reverse AC (AC -1 ) to recover D.
• This countermeasure methods allows to bind the transaction data D to the application certificate, in particular the public key PK of the certificate.
• the data D is signed by a key derived from the PK (called APP_SIG_KEY).
• a checksum of the APP_SIG_KEY is pre-computed and a pre-coded into the WBC to validate its authenticity.
• the integrity data is then appended to the end of the verified D2 to generate a message to send to the native library for the computation of the cryptogram.
• Native library side
• the APP_SIG_KEY is preferably computed outside the White Box but could be done by the White Box side.
• the checksum is re-computed for D with the given APP_SIG_KEY and the data D', using the function AT, as described before, to generate D3' (the integrity data computed by the White Box).
• the Checksum Mask is applied to the two values D3 and D3', using the function CM.
• the mask return 0 indicating equality between the two values.
• the Integrity Mask is applied to the APP_SIG_KEY and the WB secrets WB_APP_SIG and WB_APP_SIG_KEY to validate the authenticity of the PK.
• the computed integrity value Mi and Mc contain respectively information about the authenticity and integrity of the data D and the public key PK. These computed integrity value contain only 0 in the good condition. Using this information, the transaction data D is manipulated in a way to discretely fail the cryptogram validation if the integrity checks are incorrect, by using function M.
• the computed cryptogram will fail.
• the cryptogram is sent to the access device 27 or the remote system 21 .
• the remote system 21 can apply a risk of management policy.
• the remote system 21 can alert the user, informing him that his user device is compromised and should be denied authorization or otherwise banned from performing transactions.
• User can be worn by the remote system by a SMS message.
• the subject matter herein is not limited to the example in which users are notified of unsuccessful transaction and/or the threat through the remote system. Users may be notified in any manner.
• the mobile application 18 may be a merchant's own mobile application from which consumers can conduct e-commerce or point of sale transactions with that merchant, or may be a mobile wallet.
• Embodiments of the present invention can be performed by a communication devices with or without a secure element.
• Embodiments of the present invention provide techniques for enhancing the security of a communication device when conducting a transaction using the communication device without involving a secure element.
• the techniques described herein can be used with a communication device that may or may not have a secure element, because the techniques do not require the use of a secure element but the secure element could be present.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Theoretical Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• Business, Economics & Management (AREA)
• Health & Medical Sciences (AREA)
• Software Systems (AREA)
• Computer Hardware Design (AREA)
• General Health & Medical Sciences (AREA)
• Bioethics (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Accounting & Taxation (AREA)
• Strategic Management (AREA)
• General Business, Economics & Management (AREA)
• Finance (AREA)
• Databases & Information Systems (AREA)
• Data Mining & Analysis (AREA)
• Mobile Radio Communication Systems (AREA)
• Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Priority Applications (3)

Applications Claiming Priority (2)

Publications (1)

Family

ID=55083318

Family Applications (1)

Country Status (4)

Families Citing this family (9)

Citations (4)

• 2015
  • 2015-12-24 EP EP15307143.6A patent/EP3185168A1/en not_active Withdrawn
• 2016
  • 2016-12-21 MX MX2018007695A patent/MX2018007695A/es unknown
  • 2016-12-21 WO PCT/EP2016/082209 patent/WO2017108971A1/en active Application Filing
  • 2016-12-21 EP EP16819088.2A patent/EP3394788B1/en active Active
  • 2016-12-21 US US16/065,794 patent/US20190012664A1/en not_active Abandoned

Patent Citations (4)

Also Published As

Similar Documents

Legal Events