Secure element and mobile device secure end-to-end pairing

Abstract

By establishing a link over a first protocol between the secure element and the smart device, establishing a secure link over a second protocol between the secure element and the smart device via the link over the first protocol, and generating by the secure element a communication encryption key, associating a state with the encryption key, and assigning the state a first level. Transmitting the key and the state of the key from the secure element to the smart device over the link over the first protocol. The secure element and the smart device are paired over the second protocol, thereby establishing the second protocol link. Transmitting a message encrypted using the key to the smart device over the second protocol link. Upon verifying that the cardholder is an authorized cardholder of the secure element, promoting the state of the communication encryption key from the first level to a second level.

Description

Technical Field

[0001] This invention relates generally to secure elements and mobile devices, and more particularly to the secure pairing of secure elements with mobile devices. Background Technology

[0002] A secure element (SE) is a tamper-proof electronic component typically used to store host applications and confidential and cryptographic data associated with those applications. Here, the term secure element is defined as an embedded integrated circuit that employs tamper-proof features to protect the applications and data stored on it.

[0003] The Secure Elements are described in “Introduction to Secure Elements, Global Platform, https: / / globalplatform.org / wp-content / uploads / 2018 / 05 / Introduction-to-Secure-Element-15May2018.pdf(2018)”.

[0004] While security elements come in many different forms, one application of particular interest in this paper is their use in electronic payment cards and bank cards. Consumers can use electronic payment cards and bank cards to perform financial transactions, such as purchasing goods or services.

[0005] Therefore, secure elements can host payment and financial services applications and their associated credentials. Secure elements provide services such as authentication, digital signatures, and PIN management.

[0006] For the sake of brevity, we will use the term SE card in the following text to refer to a card with embedded security elements, such as a payment or financial services card.

[0007] While secure elements are useful in payment and financial service cards, they are also found in many other devices, such as desktop boxes, vehicles, Internet of Things (IoT) devices, and watches.

[0008] Digital financial transactions are very convenient for users. However, security risks exist. Therefore, it is beneficial to add security features to avoid the risks of fraudulent use of payments and other financial services provided by the SE card. Of course, security elements provide many security features, such as PIN verification. However, providing additional authentication factors enhances the security associated with the SE card. The authentication factor based on PIN verification determines what the person performing the PIN verification knows. Do they know the PIN? The second authentication factor is based on what they possess.

[0009] Therefore, it is desirable for the SE element to verify that the holder of the SE card owns another device linked to the SE card. Furthermore, it is desirable that such device pairing be secure and only authorized by the owner of the SE card. Document US2011 / 0028091A1 describes a method for pairing near-field wireless devices in which keys are exchanged.

[0010] In conclusion, it is evident that an improved method is needed to pair the safety element with the second device. Summary of the Invention

[0011] A secure link over a second protocol (which may be Near Field Communication (NFC)) is established between the secure element and the smart device via a link over the second protocol (which may be Bluetooth Low Energy (BLE)). This process includes establishing a link over the first protocol between the secure element and the smart device, and in response, the secure element generating a communication encryption key and associating a state with the encryption key, and assigning a first level to the state, which in one embodiment is referred to as a candidate state. Subsequently, a message encapsulating the encryption key and the communication encryption key is transmitted from the secure element to the smart device via the link over the first protocol. The secure element and the smart device pair via the second protocol, thereby establishing the second protocol link. The secure element transmits messages encrypted using the communication encryption key to the smart device via the second protocol link.

[0012] On one hand, in response to the detection of pairing via the second protocol, the smart device determines the status of the communication encryption key and provides the cardholder with an informational message on the smart device indicating the pairing of the security element and the smart device and the status of the communication encryption key, for example by displaying such a message on a smartphone or providing a voice message.

[0013] After pairing, the cardholder of the secure element can be authenticated, and in response to verifying that the cardholder is an authorized cardholder of the secure element, the status of the communication encryption key is raised from the first level to the second level, which in one embodiment is referred to as trusted.

[0014] On one hand, in response to a transaction executed using a secure element and a point-of-sale terminal, the state of the communication encryption key is determined, and if the state of the communication encryption key is at level two, transaction details are transmitted to the smart device via a second protocol link; otherwise, no transaction details are transmitted to the smart device.

[0015] In response to receiving transaction details from the smart device, the cardholder's transaction details are displayed on the smart device's screen.

[0016] On the other hand, in response to a transaction executed using a secure element and a point-of-sale terminal, the state of the communication encryption key is determined, and based on the state of the communication encryption key, transaction details, and security policy, an action is taken selected from the following: continue the transaction, block the transaction, or request the cardholder's approval of the transaction by transmitting a request for approval message to the smart device.

[0017] On the one hand, the secure element and the intelligent device accordingly include instructions that direct the processor of these respective devices to perform the aforementioned processes. These instructions can advantageously be stored separately in the program memory of the secure element and the intelligent device. Attached Figure Description

[0018] Figure 1 This is an illustration of a card with a security element, which is used by the cardholder in conjunction with a smartphone to execute payment transactions via a point-of-sale (POS) terminal.

[0019] Figure 2 Used in payment transactions Figure 1 A diagram of the components.

[0020] Figure 3 yes Figure 1 and Figure 2 A high-level block diagram of the device architecture for the Security Element card.

[0021] Figure 4 It is stored in Figures 1 to 3 A block diagram of the program and data in the memory of the Safety Element Card.

[0022] Figure 5 yes Figure 1 and Figure 2 A high-level architecture diagram of a smartphone.

[0023] Figure 6 The diagram is illustrated through Figures 1-4 Payment applications running on secure elements and in Figure 5 The timing diagram shows the NFC channel established between the corresponding phone running on the smartphone and the SE (PhoneToSE) app to securely provide communication encryption keys.

[0024] Figure 7 This is a timing diagram illustrating the progression of the cardholder's user authentication and communication encryption key status from candidate key to trusted key. Detailed Implementation

[0025] In the following detailed description, reference is made to the accompanying drawings, which illustrate specific embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention. It should be understood that the various embodiments of the invention, while different, are not necessarily mutually exclusive. For example, a particular feature, structure, or characteristic described herein in connection with one embodiment may be implemented in other embodiments without departing from the scope of the invention. Furthermore, it should be understood that the position or arrangement of various elements within each disclosed embodiment may be modified without departing from the spirit and scope of the invention. Therefore, the following detailed description should not be construed as limiting, and the scope of the invention is defined only by the appended claims as properly interpreted and the full scope of the claimed equivalents. In the drawings, the same reference numerals refer to the same or similar functions throughout several views.

[0026] The following description includes references to various methods executed by a processor of an integrated circuit chip. As is common in the art, there may be expressions herein indicating that these methods or method steps are executed by software instructions or software modules. As those skilled in the art will appreciate, such descriptions should be understood to mean that the processor actually executes the methods, software instructions, and software modules.

[0027] The techniques described in this article provide secure pairing of devices, particularly secure pairing of secure elements embedded in SE cards and mobile devices (e.g., smartphones).

[0028] Figure 1 This is an illustration of SE card 101, which is used by cardholder 100 in conjunction with smartphone 103 to execute payment transactions via point-of-sale (POS) terminal 105. SE card 101 includes a security element 107. SE card 101 and smartphone 103 belong to the same cardholder 100 and, as discussed in more detail below, are used to protect transactions executed using SE card 101 or to provide cardholder 100 with information related to the executed transactions.

[0029] A first short-range communication channel 108 can be established between the security element 107 and the smartphone 103.

[0030] Subsequently, a second short-range communication channel 109 can be established between the secure element 107 and the smartphone 103. The second communication channel 109 provides numerous options for secure transactions performed using the SE card 101. For example, the presence of the smartphone 103 can be requested to execute certain transactions. This eliminates fraudulent transactions performed using a stolen SE card 101. If the card 101 has been stolen or found after being lost, the second communication channel 109 cannot be established if the corresponding smartphone 103 is not within range of the short-range communication channel 109. Alternatively, the smartphone 103 can be used to provide transaction information to the user 100.

[0031] The first short-range communication channel 108 can be used to transmit a communication encryption key from the secure element 107 to the smartphone 103, so that communication between the secure element 107 and the smartphone 103 on the second short-range communication channel 109 can be encrypted.

[0032] In one embodiment, the SE card 101 is configured to communicate with the smartphone 103 according to two communication protocols. In one embodiment, these protocols are Near Field Communication (NFC) and Bluetooth. Low Energy (BLE) protocol. However, the techniques described in this article are applicable to any of a wide range of communication protocols, including WiFi and Zigbee.

[0033] The attractive features of NFC and BLE for the applications discussed in this paper are their ability to operate over very short distances. In the case of NFC, communication is limited to 4 centimeters and is activated via an "NFC tap" operation, in which the cardholder touches the communicating devices together. In the case of BLE, the theoretical maximum distance is approximately 100 meters; however, shorter distances (10-20 meters) can be expected in practice. BLE is also very sensitive to physical barriers. Therefore, the communication channel established between the secure element and the smartphone via BLE ensures that the two devices are physically close together.

[0034] Figure 2 It is used in payment transactions executed using SE Card 101 Figure 1 The diagram shows the components. The SE card 101 has been paired with the smartphone 103 for communication via the BLE communication channel 109.

[0035] To execute a transaction, the cardholder inserts card 101 into POS terminal 105, whereby the terminal and the security element can communicate via contact pad 203, for example, using the contact smart card communication standard ISO 7816. Communication between SE card 101 and POS terminal 105 can use other communication methods, such as wireless communication under ISO standard 14443 or NFC.

[0036] In one embodiment, the BLE channel from the secure element 107 to the smartphone 103 is used to provide information to the cardholder. For example, when a transaction is about to occur, an information message is transmitted to the cardholder's smartphone 103 to allow the cardholder to know the transaction details. The transaction details can also be stored on the smartphone 103 for record keeping.

[0037] In an alternative embodiment, smartphone 103 is used to provide additional security to ensure that the transaction is as the cardholder expects.

[0038] Transaction details can be transmitted from SE card 101 to smartphone 103 via BLE channel 109, and these transaction details can be displayed 205 for cardholder confirmation. In other embodiments, smartphone 103 notifies the cardholder in other ways. For example, smartphone 103 may provide a voice message to the cardholder to notify them of transaction details.

[0039] The transaction security protocol can allow for many different options, with or without smartphone 103:

[0040] • Allows all transactions and provides information via BLE link on smartphone 103

[0041] Small transactions, such as those less than $10.00 or €10.00, do not require communication with a smartphone.

[0042] For medium-sized transactions, such as those between $10.00 and $100.00, the SE Card 101 must confirm that the smartphone is reachable, i.e., within the scope of the protocol in use.

[0043] For large transactions, such as those exceeding 100.00 (USD or EUR), cardholders must confirm on a smartphone 103.

[0044] During the execution of a financial transaction, the smart device 101 is used in conjunction with the smartphone 103 to request pairing of the two.

[0045] Communication between the smartphone 103 and the secure element 101 must be secure. Therefore, the smartphone 103 and the secure element 101 participate in the pairing process described below to establish a trusted communication encryption key for encrypting messages transmitted between them.

[0046] Figure 3This is a high-level block diagram of the device architecture of an SE card 101 including a secure element 107. The secure element 107 may include a processor 301 connected via a bus 302 to random access memory (RAM) 303, read-only memory (ROM) 304, and non-volatile memory (NVM) 305. The secure element 107 further includes an input / output interface 307 for connecting the processor 301 to a contact pad 203, again typically via the bus 302, through which the secure element 107 can be connected to a POS terminal 105. Alternatively (or additionally), the SE card 103 includes an antenna 311 through which the SE device 103 can wirelessly connect to the POS terminal 105 via the input / output interface 307 using a wireless protocol (e.g., ISO 14443).

[0047] SE card 103 further includes communication interfaces 313 and 309 for communicating using the BLE communication protocol and the NFC communication protocol, respectively.

[0048] ROM 304 and / or NVM 305 may include program memory 401 for storing programs executable by processor 301, such as Figure 4 As shown in the diagram. Although in Figure 4 The description depicts computer programs 401 all residing in ROM 304 or NVM 305, but in practice, there is no such limitation, as programs can be distributed across multiple memories and even temporarily installed in RAM 303. Furthermore, SE card 103 may include multiple ROMs or NVMs.

[0049] The program memory 401 includes a card system program 407, which may include a virtual machine 409, and a driver 411 for NFC and a driver 413 for BLE, for communicating via BLE and NFC interfaces 313 and 309, respectively. The card system 407 may also include a driver 415 for communicating via the ISO 7816 protocol.

[0050] Program 401 also includes a payment application 403 through which user 100 performs payments. Payment application 403 interacts with the merchant service provider via POS terminal 105. Payment application 403 includes a module 405 for communicating with a paired smartphone 103. Thus, for example, when payment application 403 attempts to make a purchase via POS terminal 105, it triggers an action on smartphone 103, and the SE-to-phone module sends an appropriate message to the phone via BLE interface 313.

[0051] As discussed in more detail below, the payment application 403 generates one or more communication encryption keys 417 and stores those keys in non-volatile memory 305.

[0052] Figure 5 This is a high-level architecture diagram of smartphone 103. Smartphone 103 includes a processor 501, a memory 505, an NFC interface 507, and a BLE interface 509. The memory 505 contains a program 511, which includes a phone-to-SE application 503 for communicating with a corresponding SE-to-phone application on the SE-to-phone module 405 of the payment application 403 of the secure element 107.

[0053] The program memory 511 also includes drivers 513 and 515 for communicating via NFC and BLE protocols via NFC interface 507 and BLE interface 509, respectively.

[0054] The non-volatile memory 505 can also be used to store the communication encryption key 517, which corresponds to one or more communication encryption keys (communication encryption key 417) stored on the SE card 101.

[0055] Figure 6 This is a timing diagram illustrating the secure provision of communication encryption keys 417 / 517 via an NFC channel established between a payment application 403 running on a secure element 107 on an SE card 101 and a corresponding phone running on a smartphone 103 and the SE application 503. When the smartphone 103 pairs with the secure element 107 to establish a BLE channel between the two by encrypting messages transmitted between the secure element 107 and the smartphone 103, the communication encryption key transmitted via the NFC channel is used to protect subsequent BLE communications. Any of a variety of encryption standards can be used, including but not limited to Advanced Encryption Standard (AES) and RSA and its variants. For ease of explanation, the description herein corresponds to symmetric encryption, such as AES. However, this technique is also applicable to asymmetric encryption, such as RSA.

[0056] Cardholder 100 “taps” SE card 101 onto smartphone 103, step 601. NFC operates within a range of less than 4 centimeters. Therefore, the tap places SE card 101 and smartphone 103 within this range. The tap establishes an NFC channel 603 from secure element 107 to smartphone 103. At the software layer, this channel allows communication between payment app 403 (which includes instructions for this purpose (here referred to as SE to phone module 405)) and the corresponding application (Phone to SE application 503 running on smartphone 103).

[0057] NFC channel 603 can be a one-way channel from secure element 107 to smartphone 103, allowing smartphone 103 to read NFC Data Exchange Format (NDEF) tags. The NDEF tag encapsulates a communication encryption key from secure element 107.

[0058] Smartphone 103 reads the NDEF tag containing the communication encryption key, step 605.

[0059] Whenever smartphone 103 reads the NDEF tag from secure element 107, secure element 107 provides a new communication encryption key. The communication encryption key can be generated from the master key stored in secure element 107, or it can be a random number.

[0060] The smartphone 103 stores the communication encryption key from the last tap operation as a candidate key in persistent memory, such as in NVM 505, step 607. The candidate key is the communication encryption key that the smartphone 103 has received from the secure element 107, which has not yet been verified by the cardholder. Once the cardholder is verified, the communication encryption key is elevated to a trusted key.

[0061] In one embodiment, if the communication encryption key is merely a candidate key, the BLE link is only used to send information about the link itself; that is, pairing has already occurred between the secure element 107 and the smartphone 103, and the communication encryption keys 417 / 517 are candidate keys. In this embodiment, the call to the SE application 503 notifies the cardholder that the communication encryption key 517 is a candidate key, and cardholder authentication must be performed in order to combine the SE card 101 with the full functionality of the smartphone 103.

[0062] In this embodiment, if the communication encryption key 517 has been upgraded to a trusted key, the BLE link can be used to send personal information, such as transaction details that only the correct cardholder should know.

[0063] Secure element 107 stores the last communication encryption key it generates in response to an NFC tap event, or a sequence of communication encryption keys if the SE card 101 (containing secure element 107) is tapped multiple times against smartphone 103, step 609. Since the NFC link can be a unidirectional link from secure element 107 to smartphone 103, secure element 107 cannot know which key in the generated communication encryption key sequence is stored in smartphone 103. Therefore, secure element 107 sends an encrypted message corresponding to each candidate key stored on secure element 107. If smartphone 103 is able to decode one of those messages using the communication encryption key stored thereon and responds correctly, secure element 107 can infer from that response which communication encryption key in the stored sequence will be used in communication with smartphone 103. The most secure approach is to store only the last key. However, this may lead to pairing failures on the BLE link.

[0064] The communication encryption key, serving as a candidate key, is used to protect BLE link communication between the secure element 107 and the smartphone 103 by encrypting messages sent on the link using the key. However, the communication encryption key, serving as a candidate key, is not considered trusted until the cardholder is verified, and the secure element 107 can limit what actions can be taken until the cardholder is verified and the communication encryption key is elevated to trusted status.

[0065] Before verifying the cardholder 100, the communication encryption key 517 stored by the smartphone 103 and one or more communication encryption keys 417 stored by the secure element 107 are considered untrusted candidate keys.

[0066] Subsequently, the secure element 107 and the smartphone 103 are paired to create a BLE link between them, step 611.

[0067] After each pairing, the call from smartphone 103 to SE APP 503 can check the status (candidate or trusted) of the communication encryption key 517 already stored in smartphone 103 and display an information message on the phone, step 612. This message can declare that smartphone 103 has been paired with SE card 101 and identify the card, for example, "Your BNP Eurocard account ending in 'XYZW' has been paired with this smartphone." The status of the communication encryption key can also be displayed. Before cardholder verification, the communication encryption key is in the status of a candidate key. Therefore, before verification, the displayed message will be "An untrusted key was used in the link to the card."

[0068] In one use case, the above steps can be performed in an offline environment (such as the cardholder's home or office). Subsequent steps, including cardholder verification, can be performed at a POS terminal located at the merchant's location, or offline using a card reader at the cardholder's location.

[0069] At this point, many different usage patterns can emerge. For example, such as... Figure 7 As shown, cardholder 100 may seek to make a purchase at a retail location, such as Figure 7 As shown in the diagram, Figure 7 This is a sequence diagram illustrating the user authentication of the cardholder and the promotion of the communication encryption key from a candidate key to a trusted key. For example, cardholder 100 presents an SE card, inserts the SE card 101 into the POS terminal 105 for contact connection, or places the SE card 101 near the POS terminal 105 for contactless connection, step 713. As used herein, "connection" refers to both contact and contactless connections between the SE card 101 and the POS terminal 105.

[0070] In response to presenting SE card 101 to POS terminal 105, POS terminal 105 creates a communication channel to SE card 101, step 715. In one embodiment, this communication channel is a channel for transmitting APDUs as described in ISO 7816. If there is no active BLE link, SE card 101 attempts a new pairing operation, step 717, and upon establishing a link, a new status message is displayed on smartphone 103, step 719, the new status message including the status of communication encryption key 517.

[0071] In response to being connected to POS terminal 103, SE card 101 sends one or more encrypted messages to smartphone 103 via the previously established BLE link, step 721. If secure element 107 stores multiple candidate keys, secure element 107 sends a message encrypted using each of those candidate keys. The message may be a challenge-response test to confirm that smartphone 103 has stored the correct communication encryption key, thereby verifying that the smartphone is a legitimate smartphone.

[0072] Smartphone 103 responds to the message, step 723.

[0073] If the communication encryption key is trusted (step 725), the transaction continues, and the informational message can be displayed on smartphone 103 by phone to SE App 503.

[0074] If the communication encryption key is untrusted (step 725), the secure element 107 attempts to verify the cardholder 100, for example, by requesting the cardholder to enter a PIN. Therefore, the secure element 107 sends a message on the POS interface 415 to the POS terminal requesting the POS terminal 105 to obtain the PIN from the cardholder 100, step 727.

[0075] A message is displayed on the POS terminal's screen instructing the cardholder 100 to enter their PIN, step 729. Then, the user enters the PIN (step 731), and the POS terminal 105 sends the PIN to the secure element 107 (step 733).

[0076] Secure element 101 verifies the PIN (step 735), and if the PIN is verified, secure element 101 changes the status of communication encryption key 415 from candidate to trusted (step 737), and transmits the status change to the phone-to-SE app 503 on smartphone 103 via the BLE link (step 739). Smartphone 103 displays the status change of communication encryption key 517 to cardholder 100, step 741. After the key is marked as trusted, communication on the BLE channel is considered secure, and the full functionality of the phone-to-SE app 503 is made available, such as displaying personal messages to the cardholder.

[0077] Although Figure 7 Cardholder verification is depicted as being performed in conjunction with a payment transaction; however, in an alternative embodiment, cardholder verification is performed before the SE card 101 is presented to the POS terminal 105. For example, a cardholder with a reader capable of communicating under ISO 7816 or ISO 14443 can use the reader to perform the cardholder verification procedure, for example, at home or in the cardholder's office.

[0078] Use case: Unauthorized repair of SE cards to a second smartphone.

[0079] Consider a scenario involving legitimate pairing between secure element 107 and smartphone 103. A legitimate cardholder 100 hands over SE card 101 to a merchant, thereby transferring temporary control of SE card 101 to another person. If this person attempts to pair SE card 101 with another smartphone 103', a message is transmitted from SE card 101 to the original smartphone 103 via a BLE link. Cardholder 100 can then reject the pairing attempt with the second smartphone 103'.

[0080] Use case: Authorized repair of SE card to second smartphone.

[0081] On the other hand, if cardholder 100 obtains a new smartphone 103, then cardholder 100 can repeatedly... Figure 6 Chinese illustration and combination Figure 6 The sequence of discussion is used to authorize new pairings.

[0082] In alternative embodiments, cardholder verification uses other mechanisms to authenticate the cardholder. Examples include biometric technologies such as fingerprints, iris scanning, and voiceprints.

[0083] In summary, it should be obvious that an efficient and secure mechanism is provided for pairing smartphones with secure elements.

[0084] Although specific embodiments of the invention have been described and illustrated, the invention is not limited to the particular form or arrangement of the components thus described and illustrated. The invention is limited only by the claims.

Claims

1. A method for establishing a secure link over a second protocol between a secure element (107) and a smart device (103) via a link over a first protocol, the smart device including a first application (503) configured to provide multiple functions, the method comprising: Establish a link (108) on a first protocol between the security element and the smart device; In response to the establishment of a link on the first protocol, the security element generates a communication encryption key, associates the state with the encryption key, and assigns a first level to the state; A message containing a state encapsulated with an encryption key and a communication encryption key is transmitted from the secure element to the smart device via a link on the first protocol; only when the first level is assigned to the state, fewer functions than all of the plurality of functions can be used in the first application (503). The security element and the smart device are paired through the second protocol to establish a second protocol link (109); The message, encrypted with a communication encryption key, is transmitted from the secure element to the smart device via the second protocol link; The cardholder (100) of the security element is authenticated by the security element by examining personally identifiable data provided by the cardholder through a physical device linked to the security element; In response to the authentication step of verifying that the cardholder is an authorized cardholder of the security element, the state of the communication encryption key is raised from a first level to a second level; all of the multiple functions can be used in the first application only when the second level is assigned to the state (503).

2. The method of claim 1, wherein the first protocol is Near Field Communication (NFC), and the establishment of a link on the first protocol is performed in response to an NFC tap operation.

3. The method according to claim 1, wherein the second protocol is Bluetooth Low Energy.

4. The method of claim 1, further comprising: In response to the detection of pairing via the second protocol, the smart device determines the status of the communication encryption key and notifies the cardholder by providing an informative message indicating the pairing of the security element and the smart device and the status of the communication encryption key.

5. The method of claim 4, wherein notifying the cardholder of the pairing of the security element and the smart device and the status of the communication encryption key includes displaying an informational message on the smartphone.

6. The method of claim 4, wherein notifying the cardholder of the pairing of the security element and the smart device and the status of the communication encryption key includes providing a voice message to the cardholder via the smart device.

7. The method of claim 1, further comprising: In response to a transaction executed using a secure element and a point-of-sale terminal, the state of the communication encryption key is determined, and if the state of the communication encryption key is Level 2, transaction details are transmitted to the smart device via a second protocol link; otherwise, no transaction details are transmitted to the smart device. In response to receiving transaction details from a smart device, the smart device that provides the transaction details to the cardholder notifies the cardholder of the transaction details.

8. The method of claim 7, wherein notifying the cardholder of transaction details includes displaying a message containing the transaction details on a smart device.

9. The method of claim 7, wherein notifying the cardholder of transaction details includes providing the cardholder with a voice message via a smart device.

10. The method of claim 1, further comprising: In response to a transaction executed using a secure element and a point-of-sale terminal, the state of the communication encryption key is determined, and based on the state of the communication encryption key, transaction details, and security policy, an action is taken selected from the following: continue the transaction, block the transaction, or request the cardholder's approval of the transaction by transmitting a request for approval message to the smart device.

11. A security element (107) having a processor (301) and a program memory storing instructions executable by the processor, the instructions including instructions that cause the processor to perform the following operations: A first communication link (108) is established to the smart device, the smart device including a first application (503) configured to provide multiple functions; Establish a second communication link to the smart device (109); In response to the establishment of a link on the first protocol, a communication encryption key is generated, a state is associated with the encryption key, and a first level is assigned to the state; A message encapsulating an encryption key and a communication encryption key state is transmitted to the smart device on the first communication link; the encryption key authorizes the first application (503) to provide fewer functions than all of the plurality of functions only when the first level is assigned to the state. The message encrypted with the communication encryption key is transmitted to the smart device via the second communication link; User authentication of the cardholder by the secure element is performed by examining personally identifiable data provided by the cardholder through a physical device linked to the secure element; In response to successful cardholder authentication of the secure element, the state of the communication encryption key is raised from a first level to a second level, and the changed state is sent to the smart device; all of the multiple functions can be used in the first application only when the second level is assigned to the state (503).

12. The security element of claim 11, wherein the instructions further include instructions that cause the processor to perform the following operations: In response to detecting pairing via the second protocol, the state of the communication encryption key is determined, and an informational message indicating the state of the communication encryption key is transmitted to the smart device.

13. The security element of claim 11, wherein the instructions further include instructions that cause the processor to perform the following operations: In response to a transaction executed using a secure element and a point-of-sale terminal, the state of the communication encryption key is determined, and if the state of the communication encryption key is Level 2, the transaction details are transmitted to the smart device via a second protocol link; otherwise, no transaction details are transmitted to the smart device.

14. The security element of claim 11, wherein the instructions further include instructions that cause the processor to perform the following operations: In response to a transaction executed using a secure element and a point-of-sale terminal, the status of the communication encryption key is determined, and based on the status of the communication encryption key, transaction details, and security policy, an action is taken from the following: proceed with the transaction, block the transaction, or request the cardholder's approval of the transaction by transmitting a request for approval message to the smart device.

15. A system comprising a smart device and the security element of claim 11, wherein the smart device is a smartphone.

Images