Patent Application
20200167778
This application claims priority to European Application Serial No. 18208728.8, filed Nov. 27, 2018, which is incorporated herein by reference in its entirety
The present disclosure relates to trusted communication in transactions. In embodiments, it relates to a method of establishing trusted communication between a payment device and a point of interaction, and to a payment device and a point of interaction adapted to support such a method.
Payment cards such as credit cards and debit cards are very widely used for all forms of financial transaction. The use of payment cards has evolved significantly with technological developments over recent years. Originally, transactions were on paper, using an imprint of a transaction card and confirmed by a signature. This approach was largely replaced by use of a magnetic stripe of a transaction card swiped through a magnetic stripe reader on a point of sale (POS) terminal to perform a transaction. Transaction cards developed to contain an integrated circuit (“chip cards” or “smart cards”) that communicates with a smart card reader in the POS terminal. Using this approach, a transaction is typically confirmed by a personal identification number (PIN) entered by the card user. Cards of this type typically operate under the EMV specifications for interoperation of chip cards and associated apparatus (such as POS terminals and ATMs). ISO/IEC 7816 provides a standard for operation of cards of this type. EMV specifications are managed by EMVCo for relevant industries, and can be found at https://www.emvco.com/document-search/.
Technology has further developed to provide payment cards which operate contactlessly—under EMV, these are covered under the ISO/IEC 14443 standard. Using such cards, the primary account number (PAN) can be read automatically from the card by a POS terminal using NFC protocols—this approach is generally referred to as “contactless” or “proximity” payment. This is typically enabled by embedding an NFC chip in a card body together with a suitable antenna to allow transmission and receipt of wireless signals—the transmissions may be powered by a magnetic inductive field emitted by a proximity reader in the POS terminal. For an effective transaction to be made; the payment card may need to be brought into close proximity to the proximity reader—EMVCo has defined this range under the Level 1 operating volume range of 0-4 cm.
A potential problem with any sensitive communication is the risk of eavesdropping during data exchange between parties. This is potentially a concern for any transaction type, though requires particular attention for wireless transactions such as contactless transactions. The concern in the case of such eavesdropping is that an eavesdropper may be able to obtain sensitive data relating to the transaction, with the risk that this information will be reused in some way to cause loss to cardholders or merchants or compromise cardholder privacy. EMV specifications contain various security mechanisms to defend against such risks, including in particular the use of RSA for encrypting the cardholder PIN when transmitted to the card. It is however known that strategies for attackers to obtain sensitive data from transaction information by eavesdropping are still being developed.
Despite existing security measures, it would therefore be desirable to take further measures to reduce any risk that sensitive information in transaction data could be compromised by eavesdroppers thereby improving data security. It would also be desirable to do this in such a way that existing infrastructure could be upgraded without fundamental modification.
In a first part of a first aspect, the disclosure provides a method for a first computing device to establish trusted communication with a second computing device in a transaction process, the method comprising, during a transaction process: the first computing device establishing a communication channel with the second computing device; the first computing device providing a secure communication to the second computing device, the secure communication comprising cryptographic material encrypted by a public key of an asymmetric cryptographic method for the second computing device to decrypt using a private key of the asymmetric cryptographic method; and the first computing device communicating with the second computing device for trusted communication using a further cryptographic method using the cryptographic material.
In a second part of a first aspect, the disclosure provides a method for a second computing device to establish trusted communication with a first communication device in a transaction process, the method comprising, during a transaction process: the second computing device establishing a communication channel with the first computing device; the second computing device receiving a secure communication from the first computing device, the secure communication comprising cryptographic material encrypted by a public key of an asymmetric cryptographic method; the second computing device decrypting the cryptographic material using a private key of the asymmetric cryptographic method; and the second computing device communicating with the first computing device for trusted communication using a further cryptographic method using the cryptographic material.
This approach is advantageous, as it allows for security mechanisms to be upgraded to provide better trust without changing basic protocol elements of a transaction protocol—if, for example, the asymmetric cryptographic method is embedded in the transaction protocol, the transaction protocol can be enhanced but not changed at a basic level without updating legacy apparatus, and new cryptographic methods which are more secure or which can be used more flexibly than the asymmetric cryptographic method can be deployed.
In embodiments, the further cryptographic method is symmetric and trusted communication is provided by a secure channel using the symmetric further cryptographic method to protect privacy of information private to an owner or controller of at least the first computing device. This allows a minimally disruptive way to provide a secure channel allowing two way communication between the two computing devices. This symmetric further cryptographic method may be AES.
In embodiments, the further cryptographic method may be asymmetric and trusted communication may be provided by using the asymmetric further cryptographic method to replace the asymmetric cryptographic method in one or more processes. In embodiments, the asymmetric cryptographic method is RSA and the further asymmetric cryptographic method is ECC, with ECC used instead of RSA for digital signatures provided by the first communication device. In embodiments, other approaches (such as use of a Message Authentication Code) may be used instead of a digital signature to authenticate origin of information.
In embodiments, there may be more than one further cryptographic method, wherein the more than one further cryptographic methods comprise a symmetric further cryptographic method and an asymmetric further cryptographic method. Using this approach, the cryptographic material may contain parts to establish both symmetric and asymmetric further cryptographic methods, or the symmetric further cryptographic method may be used to convey cryptographic material to establish the asymmetric further cryptographic method (e.g. information to set up ECC as an alternative asymmetric cryptographic scheme may be conveyed over an AES channel).
Providing both an upgraded asymmetric method and a symmetric method provides a flexible solution that also achieves a high level of security. Such use of an upgraded asymmetric method may allow ECC to be used instead of RSA for digital signatures, for example, while AES may be used to preserve privacy in communication between devices.
These first and second computing devices may communicate to agree a transaction for authorisation over a transaction scheme. This transaction scheme may operate according to the EMV protocol.
This approach allows existing EMV protocols to be enhanced so that ECC methods can be used rather than RSA for dynamic signatures, with AES symmetric methods used for providing privacy protection for sessions involving payment devices and terminals.
In a second aspect, the disclosure provides a first computing device comprising a memory and a processor programmed to perform actions executed by the first computing device in the method of the first aspect above.
This first computing device may be a payment device adapted for use by a cardholder to make payments on behalf of the cardholder. In embodiments, this may be a payment card, or a mobile telephone or other computing device, typically acting as a proxy for a payment card.
In a third aspect, the disclosure provides a second computing device comprising a memory and a processor programmed to perform actions executed by the second computing device in the method of the first aspect above.
This second computing device may be a point of sale terminal.
Embodiments of the disclosure will now be described, by way of example, with reference to the accompanying Figures, of which:
General and specific embodiments of the disclosure will be described below with reference to the Figures.
Normally, card schemes—payment networks linked to payment cards—are based on one of two models: a three-party model or a four-party model (adopted by the present applicant). For the purposes of this document, the four-party model is described in further detail below.
The four-party model may be used as a basis for the transaction network. For each transaction, the model comprises four entity types: cardholder 110, merchant 120, issuer 130 and acquirer 140. In this model, the cardholder 110 purchases goods or services from the merchant 120. The issuer 130 is the bank or any other financial institution that issued the card to the cardholder 110. The acquirer 140 provides services for card processing to the merchant 120.
The model also comprises a central switch 150—interactions between the issuer 130 and the acquirer 140 are routed via the switch 150. The switch 150 enables a merchant 120 associated with one particular bank acquirer 140 to accept payment transactions from a cardholder 110 associated with a different bank issuer 130.
A typical transaction between the entities in the four-party model can be divided into two main stages: authorisation and settlement. The cardholder 110 initiates a purchase of a good or service from the merchant 120 using their card. Details of the card and the transaction are sent to the issuer 130 via the acquirer 140 and the switch 150 to authorise the transaction. Should the transaction be considered abnormal by the issuer 130, the cardholder 110 may be required to undergo an additional verification process to verify their identity and the details of the transaction. Once the additional verification process is complete the transaction is authorised.
On completion of the transaction between the cardholder 110 and the merchant 120, the transaction details are submitted by the merchant 120 to the acquirer 140 for settlement.
The transaction details are then routed to the relevant issuer 130 by the acquirer 140 via the switch 150. Upon receipt of these transaction details, the issuer 130 provides the settlement funds to the switch 150, which in turn forwards these funds to the merchant 120 via the acquirer 140. Separately, the issuer 130 and the cardholder 110 settle the payment amount between them. In return, a service fee is paid to the acquirer 140 by the merchant 120 for each transaction, and an interchange fee is paid to the issuer 130 by the acquirer 140 in return for the settlement of funds.
In practical implementations of a four-party system model, the roles of a specific party may involve multiple elements acting together. This is typically the case in implementations that have developed beyond a contact-based interaction between a customer card and a merchant terminal to digital implementations using proxy or virtual cards on user computing devices such as a smart phone.
The cardholder 1 has a user payment device 6—here, in the form of a cellular phone handset acting as a proxy for a payment card 8. The user payment device 6 here interacts with a POS terminal 7 of a merchant 2 over NFC to perform a contactless transaction. While embodiments of the disclosure are particularly relevant to contactless transactions, they are not so limited—they also have application to a direct contact interaction between a payment card 8 and a POS terminal 7, for example.
The transaction infrastructure 5 provides the computing infrastructure necessary to operate the card scheme and provide routing of transactions and other messaging to parties such as the acquirer 3 and the issuer 4. While the Figure shows a direct relationship between the cardholder 1 and the issuer 4, and between the merchant 2 and the acquirer 3, some or all communications between them relating to transactions may in practice be mediated by the transaction infrastructure 5.
In embodiments of the disclosure, the card 8 may interact directly with the terminal 7—the embodiments describe interaction of a payment device with a terminal, wherein either a payment card 8 or a computing device 6 acting as a proxy for a payment card can be the payment device. The card 8 will have many of the same elements—it will have a computing environment comprising a payment application and a proximity payment system environment, and it will be adapted for short range wireless communication using NFC protocols with a terminal. The card 8 will not typically have a wallet application or a biometric sensor—it will also typically not have its own power source, but will instead be inductively powered by the terminal during an interaction.
The proximity payment system environment 332 does not itself process the transaction, but it enables communication between a payment application 331 and the terminal 7 and its point of sale application 335. It can also establish whether the payment device has a payment application 331 available to process the transaction.
The payment application 331 may be one of a number of payment applications present on the device. It may be implemented as a state machine, adapted to provide responses to commands received from the point of sale application 335 to provide the cardholder contribution to a transaction process. For this purpose, it will comprise or have access to secrets for use in cryptographic processes and data sensitive to the cardholder (such as the card number, expiry date and cardholder credentials). The payment application 331 will perform processes that may be used by transaction processes—such as cardholder verification—and provides an application cryptogram used by the issuer in determining whether the transaction is to be authorised.
The point of sale application 335 establishes communication with the payment device through the proximity payment system environment 332 and establishes a connection with a suitable payment application 331. The point of sale application is provided with details of the transaction (these may be determined through other processes at the terminal interacting with the point of sale application 335), and communicates with the payment application to establish that the payment device is valid and to obtain an application cryptogram that can be sent with the transaction details so that the transaction can be authorised by the issuer of the cardholder.
A process according to an embodiment of the disclosure is described generally with respect to
An EMV-type contactless transaction implementing an embodiment of the disclosure will now be described in more detail—basic steps in the transaction process are shown in
On establishment of communication 510 between the payment device 6, 8 and the terminal 7, the terminal issues a Get Processing Options command 520, to which the card responds with a GPO response 530 which includes an Application Interchange Profile (AIP) and Application File Locator (AFL). In general terms, this is a conventional EMV process—however in this case the Get Processing Options command 520 and the GPO response 530 may indicate that the terminal and the payment device both support use of a privacy protection mechanism and ECC digital signatures. This process is described below as XDA—Extended Data Authentication—as it goes beyond currently used cryptographic data authentication processes such as static data authentication (SDA), dynamic data authentication (DDA) and combined DDA and generation of an Application Cryptogram (CDA). The GPO response 530 includes an RSA encrypted element including an AES session key—in the embodiment described, an ECC public key for the payment device is also included. When trusted communication using a further cryptographic method is required 540, this data is encrypted or signed by the relevant device using the further cryptographic method enabled by the cryptographic material included in the RSA encrypted element, and communicated for use by the other device 550. These individual steps, and their application to existing EMV processes, will be described below.
The AES encryption and XDA processes here described are of particular value for contactless transactions as there may be perceived to be a greater eavesdropping risk and speed requirement than for contact transactions—one option would therefore be for the AES encryption and XDA process to be available for use for transactions of any kind, but in practice only selected for contactless transactions.
Application Selection
The SELECT command is used to select which payment application is to be used. When an application is selected, the payment device responds with a Processing Options Data Objects List (PDOL), indicating the data items that it requires from the terminal to perform its functions for the transaction. In addition to existing EMV functionality, the enhanced process (also termed “privacy protection” below) requires two additional data items: Terminal Public Exponent Indicator and Terminal Public Key Modulus. Tags are selected for these items such that the tags can be ignored by legacy terminals that do not support this functionality. These tags are here included at the end of PDOL with each DOL entry specifying a length of one byte.
Get Processing Options
The Get Processing Options command is used by the terminal to establish with the card what processing steps are to apply to the present transaction—the card responds with a response comprising an Application Interchange Profile (AIP). The terminal populates the Terminal Public Exponent Indicator and Terminal Public Key Modulus in the PDOL data of the Get Processing Options command. A legacy terminal or a terminal not supporting privacy protection would populate both Terminal Public Exponent Indicator and Terminal Public Key Modulus as one byte of ‘00’. The one byte Terminal Public Key Modulus can then be used by the card to detect that the terminal does not support privacy protection. If the length of the Terminal Public Key Modulus is not 1, not at least 96 bytes, and not a multiple of 16 bytes the card would return a length error.
The card then responds to the Get Processing Options command with an AIP that indicates that XDA is supported. An exemplary AIP structure is shown in Table 1 below, which indicates that XDA is supported in byte 2 bit 7.
If the card has detected the terminal supports privacy protection it creates an RSA Encrypted Payload in the following way. A random 16 byte AES privacy protection session key is generated. A buffer the size of the Terminal Public Key Modulus is populated with ‘7F’|Number of Session Keys (‘01’)|Privacy Protection Session Key|App Data Tag (‘70’ or ‘EF’)|Length App Data|App Data and filling the remaining space with random data. (In practice the initial buffer byte might be extended to provide more structure). The buffer is then RSA encrypted with the Terminal Public Key Modulus and the exponent indicated by the Terminal Public Exponent Indicator. In an embodiment, the App Data consists of the Primary Account Number (PAN), Track 2 Equivalent Data (as defined in EMV specifications), and the payment device ECC Public Key, including their tags and lengths. The App Data Tag, Length, and Value will be personalised in the card, and can be personalised in a record for use when the terminal does not support privacy protection to allow the same payment device public key certificate to be reused. Care must be taken when selecting the tag value for the ECC Public Key as the record would need to be accepted by legacy terminals.
For example, using this approach the plaintext prior to RSA encryption would be of the form:
7F010123456789ABCDEFFEDCBA987654321070415A0854133390000015135 7125413339000001513D20122010000000000009F682043CA1837F6B4321CA7 0262902037EFCE790DC583828AEA628FFAAEFC08618658 followed by the random padding to the length of the buffer
If the card has detected the terminal supports privacy protection (Terminal Public Key Modulus length not equal to 1) it responds with the Privacy Protection AFL (Application File Locator). AFL is a standard EMV field, but the Privacy Protection AFL differs slightly in that it doesn't identify the record that contains the App Data. This new Privacy Protection AFL is personalised in the payment device.
The RSA Encrypted Payload is thus returned to the terminal in the Get Processing Options response, and the terminal can start to decrypt it in parallel to reading the card data. In addition to the RSA Encrypted Payload, a one byte Algorithm Suite Indicator with value ‘00’ is returned—this can be hard coded in the application and does not require personalisation. Alternatively, this can be provided in the response to the SELECT command.
The application maintains a 16 byte IV value that is initialised to 00000000000000000000000000000000 during the Get Processing Options command.
In embodiments, when storing the PDOL Related Data for subsequent signature generation any supplied Terminal Public Key Modulus may be truncated after the first byte.
An exemplary Get Processing Options Response using this approach is shown in Table 2 below.
Once the RSA Encrypted Payload has been decrypted the terminal should extract the Privacy Protection Session Key from the 3rd to the 18th byte of the recovered plaintext and the App Data from an offset from the 2nd byte determined by multiplying the value of the 2nd byte by 16 and ensuring that no buffer overrun occurs. If a buffer overrun is detected the transaction is terminated.
At this point, the terminal and payment device are now equipped for privacy protection as enhanced security is available. An AES session key has been shared for general protection of communications between the terminal and the payment device—AES is the generally used standard for symmetric encryption.
In addition, an ECC public key for the payment device has been provided to the terminal so that the card can use its ECC private key for digital signatures. The use of this approach will be described further by application to other EMV commands.
Read Record
A READ RECORD command asks the payment device to provide certain data. A tag can be used at the start of a record to indicate whether privacy protection should be used or not. For example, ‘EF’ may be used for privacy protection, and ‘70’ for no privacy protection required. If ‘70’ is used, then the record can be returned in plaintext, and if privacy protection is not supported by the terminal, the tag can be changed to 70′ and the record returned in plaintext (in the absence of any practical alternative).
When a Read Record command is received the card application inspects the template tag at the start of the record. If the template tag is ‘EF’ and the card has detected that the terminal supports privacy protection then the card enciphers the value field of the record template.
In embodiments, privacy protection in providing the record may be achieved by using AES Counter (CTR) mode with the privacy protection session key generated during the Get Processing Options command and the current value of the Privacy Protection IV. Counter (CTR) mode is the preferred method as this will prevent expansion of the enciphered data. After the encipherment, the first eight bytes of the Privacy Protection IV are incremented so that a new IV value is used for each record that is enciphered. The enciphered record with the ‘EF’ tag is returned to the terminal. As the record has an ‘EF’ tag, the terminal knows that the record needs to be deciphered. The terminal is able to do this once the privacy protection session key becomes available after decryption of the RSA Encrypted Payload.
Generate AC
GENERATE AC (Application Cryptogram) is the central command in the transaction process between the payment device and the terminal—the terminal commands the payment device to provide an application cryptogram for indicating to the payment device issuer what has been agreed between the terminal and the payment device in respect of the transaction and providing evidence to the issuer that it is a legitimate use of the indicated payment device. Using the privacy protection process described, existing application cryptogram generation can be modified to support use of ECC signatures, rather than RSA signatures as previously without revealing to an eavesdropper the ECC public key value that could be used to track the payment device. This approach may similarly be used for other asymmetric encryption models and not solely ECC.
To indicate this, two new bits may be defined in the P1 parameter of GENERATE AC to allow XDA ECC signatures to be requested. For existing definition of GENERATE AC, the person skilled in the art is directed to the EMVCo specifications as previously. The resulting definition of the P1 parameter is as set out in Table 3 below.
For security purposes, XDA may be considered equivalent to CDA (as discussed above), and consequently the Card Verification Results are treated as being the same as if CDA had been performed (i.e. the CDA Returned In First/Second Gen AC bits become CDA/XDA Returned In First/Second Gen AC). The same principle applies to the Decline If CDA Not Performed And RRP Performed bit in Application Control—it becomes Decline If CDA/XDA Not Performed And RRP Performed.
The Generate AC Response contains the same data items as a non-CDA response (i.e. with Application Cryptogram), but may be extended if RRP (Relay Resistance Protocol—an EMV specification option for prevention of relay attacks) is performed. This extension may be provided by adding RRP Data with a 14 byte value consisting of the concatenation of Terminal Relay Resistance Entropy, Device Relay Resistance Entropy, Min Time For Processing Relay Resistance APDU, and Transmission Time For Relay Resistance R-APDU.
If an XDA signature is requested, and in the case of ‘XDA for TC Responses Requested’ a TC response is determined, the payment device generates an ECC signature. A TC (Transaction Certificate) response is an Application Cryptogram used for a transaction approved by a payment device—after which the transaction can complete. The ECDSA—Elliptic Curve Digital Signature Algorithm—is one recognised way of producing digital signatures using ECC. Other forms of ECC signature may also be used, for example the Schnorr variant ECSDSA. Alternatives to a digital signature may also be used—other approaches to confirming authentic origin of information include use of a Message Authentication Code (MAC) using an AES key. The ECC signature may be generated with the SHA-256 cryptographic hash algorithm over PDOL Related Data, CDOL1 Related Data, CDOL2 Related Data (in case of a 2nd Gen AC), and Generate AC Response Data (except the Signed Dynamic Application Data). As before, these are all established EMV data fields, and the person skilled in the art is directed to EMVCo specifications for further reference. The ECC signature consists of a pair (r,$), in this case provided as the 32 byte value of r followed by the 32 byte value of s. This 64 byte signature is returned as the Signed Dynamic Application Data. The NIST P-256 curve is used as specified in Table 4 below.
A complete Generate AC Response may thus be as indicated in Table 5 below.
When the terminal has received the Generate AC Response and has finished decrypting the RSA Encrypted Payload and deciphering the enciphered Read Record Responses it proceeds to verify the XDA signature contained in the Signed Dynamic Application Data. The most efficient way to verify the signature is to calculate the y-coordinate of the payment device ECC Public Key from the x-coordinate contained in the ECC Public Key as follows:
y′=(x3+ax+b)((p+1)/4)mod p
y=min(y′,p−y′)
Having determined the x and y coordinates of the payment device ECC Public Key Q=(x,y), the ECC signature (r & s) can be verified which for ECDSA is performed in the following way (this will typically be available as a primitive in a crypto library covering ECC—this may be held in the terminal).
Other approaches to verification are possible (for example, if the crypto library used by the terminal supports ANSI/SEC compressed point representation, this may be used).
Static Data Authentication
Static Data Authentication is an EMV cryptographic check process to ensure that static data read from the payment device has not been modified or is otherwise not legitimate. For XDA, a new data item Extended SDA Tag List may be defined that contains a list of the tags of data items to be included in the static data to be authenticated. Again, the tag value used for the Extended SDA Tag List needs to be selected so that legacy terminals can ignore the data item. The Extended SDA Tag List can be stored in a signed plaintext record and would typically identify the data items included in the App Data in the RSA Encrypted Payload.
When privacy protection is invoked (Terminal Public Key Modulus length not equal to 1), the terminal assembles the static data to be authenticated by concatenating the records indicated in the AFL as participating in offline data authentication (excluding the ‘70’ template tag and record length), followed by the data items identified in the Extended SDA Tag List (including their tags and lengths), and finally the value field of the AIP (excluding its tag and length) if the SDA Tag List exists (it must only contain the AIP). If privacy protection has not been invoked (Terminal Public Key Modulus length equal to 1) the Extended SDA Tag List is ignored.
In this manner the same payment device Public Key Certificate can be used on legacy terminals (where the App Data which in the described embodiment consists of PAN, Track 2 Equivalent Data, and ICC ECC Public Key are returned in a Read Record response) and on terminals supporting privacy protection (where PAN, Track 2 Equivalent Data, and ICC ECC Public Key are returned in the RSA Encrypted Payload). If payment device Public Key Certificates are to be reused, care must be taken to ensure that the signed data identified by the Privacy Protection AFL, Extended SDA Tag List, and SDA Tag List is exactly the same as the data identified by the legacy AFL and SDA Tag List.
Generate ECC Key
The payment device ECC key will in some embodiments be personalised into the card. In other embodiments, a payment device may not be provisioned with an ECC key pair, and is instead instructed to generate one when required with a GENERATE ECC KEY command. This is a new command type, and would be answered with response data that consists of the 32 byte x-coordinate of the ECC public key that has been generated. The corresponding private key would be stored in the payment application.
The following method of elliptic curve key pair generation can be used, which follows ISO/IEC 15946-1.
The private key d for a given elliptic curve E with base point G of order n consists of a positive integer d, satisfying 1<d<n−1.
The corresponding public key point is P=dG on the curve E.
Given an elliptic curve, all parameters including the base point are fixed. Therefore, key generation consists solely of random or pseudorandom generation of d and subsequent computation of the public key point P=dG and thereby its x-coordinate representation.
In embodiments described here, public keys are represented using only their x-coordinate. For any non-zero point (x,y) on the curve, (x,−y) will also be on the curve. The signature verification is sensitive to the value of the y-coordinate. For this reason the card ECC key must be generated to ensure that the verifier can determine the correct value of the y-coordinate of the Public Key from knowledge of only the x-coordinate.
This can be achieved if payment device keys are generated to ensure that the y-coordinate as an integer modulo p is less than (p+1)/2. This enables the terminal to generate the correct y-coordinate given the correct x-coordinate.
Two approaches to achieve this are described below—the first approach involves more computation, but the second approach may require additional logic.
The public key is then calculated to be the point P=dG and its representation is the x-coordinate of P.
Even if an ECC pair has originally been provisioned, or if an ECC pair has been generated, it may be desirable to allow provisioning of a new ECC pair to the card if required, or to require a new ECC pair to be generated in appropriate circumstances.
As can be seen, this approach allows for enhanced security in transactions by using a secure transmission scheme that already exists in the protocol—in this case, asymmetric encryption using RSA—as the basis for transmitting cryptographic material for establishing one or more further secure transmission schemes—in this case, symmetric encrypted communication using an AES session key for privacy protection, and an asymmetric mechanism using ECC for improved digital signatures. While both a symmetric and an asymmetric mechanism are provided here, embodiments may provide only one of these enhancements—for example, simply the provision of an ECC public key within an RSA encrypted element to allow digital signatures to be carried out using ECC rather than RSA. This allows security of the transmissions to be improved significantly while enhancing, without fundamentally changing, existing transaction protocols. This approach could be used to incorporate new secure transmission paradigms in the same way—for example, another symmetric mechanism rather than AES, or another asymmetric mechanism rather than ECC.
As the person skilled in the art will appreciate, modifications and variations to the above embodiments may be provided, and further embodiments may be developed, without departing from the spirit and scope of the disclosure. Reference to standards and proprietary technologies are provided for the purpose of describing effective implementations, and do not limit the scope of the disclosure.
| Number | Date | Country | Kind |
|---|---|---|---|
| 18208728.8 | Nov 2018 | EP | regional |
