HK1178335B - Security architecture for using host memory in the design of a secure element - Google Patents

Abstract

The invention is directed to a security architecture for using host memory in the design of a secure element wherein, embodiments of a security architecture for securely storing applications, such as Near Field Communication (NFC) applications, in host memory of a mobile device are provided. The mobile device includes a host application processor, a non-volatile memory, a NFC controller, and an embedded Secure Element (eSE). The eSE is configured to encrypt code and state data associated with a NFC application; store the code and the state data, after having been encrypted, in the non-volatile memory as a binary large object (blob); load the blob from the non-volatile memory in response to an action performed by the host application processor or the NFC controller; decrypt and authenticate the code and the state data; and execute the code to exchange data with a contactless communication device via the NFC controller. The non-volatile memory is external to the eSE.

Description

Secure architecture using main memory in the design of secure elements

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority from us provisional patent application 61/486,625 filed on 16/2011 and us patent application 13/173,931 filed on 30/2011, which are hereby incorporated by reference in their entirety.

Technical Field

The present application relates generally to security architectures and more particularly to security for near field communication applications.

Background

Near Field Communication (NFC) is a wireless communication technology that allows data to be exchanged between two devices separated by up to ten centimeters. In the near future, NFC-enabled mobile devices are expected to be ubiquitous, being able to function both as contactless (contactless) cards and as card readers to provide the ability to execute payment, payment (royalty), ticketing and access control applications, to name a few. Generally, it is not necessary for the owner of an NFC-enabled mobile device to carry a credit card, bus ticket, or access card (accesscard). The owner's mobile device may function as an "electronic wallet" that contains virtual implementations of these cards and tickets, among other things.

A main application processor (often referred to as a host application processor) of the mobile device may be used to execute a variety of different NFC applications. These NFC applications and associated data may be stored in the main non-volatile memory of the mobile device and retrieved when requested or required for execution. During execution of the NFC application, the host application processor may exchange data and commands with a remote NFC-enabled device in its vicinity using an NFC controller in the mobile device. The data exchange may be performed to implement the functionality of the NFC application.

Because NFC-based applications can be executed on the host application processor and stored in the mobile device's host non-volatile memory, these NFC applications are vulnerable. The primary non-volatile memory of a mobile device is typically insecure and does not protect the data stored therein from inadvertent deletion or intentional manipulation. For security insensitive applications, such as applications for reading and displaying smart tag data on a post, the lack of security is not an issue. However, for applications such as payment, ticketing, and payment applications, any inadvertent deletion, reading, or alteration of code or data associated with these applications can have undesirable consequences, including monetary funds theft and fraud.

A conventional solution to this problem is to further include a Secure Element (SE) in the NFC-enabled mobile device. SE is a tamper resistant (tamperpresesistant) device with an embedded microprocessor. There are three common architectures for performing SE: the first architecture implements the SE as an embedded hardware module built into the mobile device; the second architecture implements the SE in a Subscriber Identity Module (SIM); and a third architecture implements the SE in a removable User Identity Module (UIM) or a Universal Integrated Circuit Card (UICC). An SE implemented according to the first architecture is commonly referred to as an embedded SE (ese).

A legacy NFC-enabled mobile device that includes an eSE stores and executes security-sensitive NFC applications and associated data in the eSE. More specifically, security sensitive NFC applications are stored in non-volatile memory of the eSE to provide protection. The integrated non-volatile memory of the eSE can be flash memory or EEPROM, but it is generally not process-specific (variable). Thus, eses with integrated non-volatile memory are typically implemented in older, less desirable processes. For example, an eSE with non-volatile memory in the prior art can be manufactured in a 90nm process, as opposed to in a 40nm process that is available, due to scalability issues associated with integrated non-volatile memory.

In addition to the above problems, NFC enabled mobile devices are becoming more common and the number of NFC applications that can be securely stored and executed in mobile devices is expected to grow. Therefore, the integrated non-volatile memory in the eSE must be large enough to accommodate a potentially large number of NFC applications.

Therefore, there is a need for a secure architecture that supports eses that can be scaled with process while still providing for the execution and storage of a large number of NFC applications.

Disclosure of Invention

According to an embodiment of the present invention, there is provided a method of securely storing and executing a Near Field Communication (NFC) application using an embedded secure element (eSE) of a mobile device, the method including: storing the code and state data in a non-volatile memory external to the eSE as a binary large object (blob); loading a blob from non-volatile memory in response to an action performed by at least one of a host application processor of a mobile device and an NFC controller of a wireless communication device; validating code and state data stored in a blob loaded from non-volatile memory; and executing code to exchange data with the contactless communication device via the NFC controller.

According to another embodiment of the present invention, there is provided a mobile device including: a primary application processor; a non-volatile memory; a Near Field Communication (NFC) controller; an embedded secure element (eSE) structured to: storing the code and state data in a non-volatile memory as a binary large object (blob); loading the blob from the non-volatile memory in response to an action performed by the host application processor or the NFC controller; validating code and state data stored in a blob loaded from non-volatile memory; and executing code to exchange data with the contactless communication device via the NFC controller, wherein the non-volatile memory is external to the eSE.

Drawings

The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate the present invention and, together with the description, further serve to explain the principles of the invention and to enable a person skilled in the pertinent art to make and use the invention.

Fig. 1 shows a block diagram of a security architecture for securely storing NFC applications in a main memory of a mobile device according to an embodiment of the invention.

Fig. 2 illustrates a block diagram of an eSE without integrated non-volatile memory for storing NSF applications, which can be constructed to operate in the secure architecture of fig. 1, in accordance with an embodiment of the present invention.

Fig. 3 illustrates an example packet (bundle) for detecting a replay attack according to an embodiment of the present invention.

Fig. 4 shows a block diagram of a security architecture for securely storing NFC applications in a main memory of a mobile device and in a non-volatile memory directly coupled externally to an eSE, according to an embodiment of the invention.

Fig. 5 shows a block diagram of a security architecture for securely storing NFC applications in a main memory of a mobile device further comprising a fingerprint sensor directly coupled to an eSE, according to an embodiment of the present invention.

Fig. 6 shows a flow diagram of a method for securely storing an application and associated data in a main memory of a mobile device for execution by an eSE, in accordance with an embodiment of the present invention.

FIG. 7 illustrates a flow diagram of a method for updating a private count value packet corresponding to a security-sensitive application and for securely storing the packet in main memory of a mobile device, according to an embodiment of the present invention.

Fig. 8 illustrates a flowchart of a method of detecting a replay attack using a private count value packet that is securely stored in a main memory of a mobile device and corresponds to a security-sensitive application according to an exemplary embodiment of the present invention.

The present invention will be described with reference to the accompanying drawings. The drawing in which an element first appears is typically indicated by the leftmost digit(s) in the corresponding reference number.

Detailed Description

In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention, including structures, systems, and methods, may be practiced without these specific details. The descriptions and representations are the ones by which those of ordinary skill in the art effectively convey the substance of their work to others of ordinary skill in the art. In other instances, well-known methods, procedures, components, and circuits have not been described in detail as not to unnecessarily obscure aspects of the present invention.

References in the specification to "one embodiment," "an example embodiment," etc., indicate that the embodiment described may include a particular feature, structure, or characteristic. Each embodiment need not necessarily include the particular features, structures, or characteristics. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to effect such feature, structure, or characteristic in connection with other embodiments whether or not described.

In the following description, embodiments of the present invention are described with respect to NFC-enabled mobile devices (e.g., mobile phones) configured to communicate via one or more cellular and/or wireless communication networks. However, it should be understood that embodiments of the present invention are not limited to mobile devices and are broadly applicable to other NFC devices, such as personal computers, laptop computers, Personal Digital Assistants (PDAs), and personal entertainment devices, to name a few.

Fig. 1 shows a block diagram of a security architecture for securely storing applications and associated data in main memory of a mobile device 100, according to an embodiment of the invention. Mobile device 100 includes a host application processor 105, a host non-volatile memory 110, an optional Subscriber Identity Module (SIM) 115, an embedded secure element (eSE) 120, and an NFC controller 125 coupled to an antenna 130. In one embodiment, the antenna 130 is a loop antenna.

In operation, the primary application processor 105 is configured to execute an operating system of the mobile device 100, which may be stored in the primary non-volatile memory 110. The operating system may support execution of a user interface and additional applications (e.g., security insensitive NFC applications) on the host application processor 105. The host application processor 105 may be further configured to control, at least in part, the communication capabilities of the mobile device for exchanging voice and/or data via a cellular network operated by a mobile network operator.

The main non-volatile memory 110 is coupled to the main application processor 105 and is configured to provide long-term, persistent storage of applications and associated data, even when the mobile device 100 is not powered. The main non-volatile memory 110 may include one or more of Read Only Memory (ROM), Electrically Erasable Programmable ROM (EEPROM), and flash memory, to name a few. In addition to providing possible storage for the operating system of the mobile device 100, the main non-volatile memory 110 can further be used to store various additional applications and associated data executed by the main application processor 105, as well as secure data 135 representing the eSE120, as will be explained further below. Security data 135 may include code and data associated with security sensitive applications, such as payment, and ticketing based NFC applications.

As further shown in fig. 1, mobile device 100 also includes an NFC controller 125 configured to transmit data to and receive data from a remote NFC-enabled device according to applicable standards, including, but not limited to, the ECMA-340 standard and/or the ISO/IEC18092 standard. These standards determine the "contactless" operating environment of the NFC-enabled device, the format of the data to be transmitted, and the data transmission rate.

NFC controller 125 may be configured to communicate with a remote NFC-enabled device (not shown) through magnetic field induction using antenna 130. NFC controller 125 may communicate with a remote NFC-enabled device when the remote device is in close proximity (typically within four centimeters) to antenna 130. The communication may be made to perform a contactless transaction, such as a payment, ticketing, or payment transaction (royalty transaction), or to access information content.

Also included in the mobile device 100 is an eSE 120. The eSE120 is a tamper-resistant integrated circuit device with an embedded microprocessor. In an embodiment, the eSE120 is implemented as a stand-alone embedded hardware module built into the mobile device 100 and is structured to provide a secure environment for the execution of security-sensitive applications, in particular security-sensitive NFC applications. The eSE120 provides a secure execution environment for security-sensitive NFC applications by employing logical security techniques (e.g., cryptographic measures), and possibly physical security techniques, to control access to the device and the data it operates on. For example, the physical techniques can include encapsulating the eSE120 in epoxy, and the logical security techniques can include one or more of encryption, decryption, marking, and verification.

Eses in existing NFC-enabled mobile devices typically include integrated non-volatile memory for storing security-sensitive applications and associated data to ensure their protection. However, the integrated non-volatile memory is not process tuned. As a result, eses in existing NFC-enabled mobile devices are typically implemented using older, less desirable processes.

Unlike these prior art eSE implementations, the eSE120 does not include integrated non-volatile memory (not adjustable) for storing security-sensitive applications. Thus, the eSE120 can be fabricated using process technologies previously precluded due to scalability issues associated with the memory. Moreover, removing the (non-adjustable) integrated non-volatile memory for storing security-sensitive applications from the eSE makes it easier to exploit the potential for manufacturing the eSE120 together with the NFC controller 125 on a single chip 145.

As shown in fig. 1, the novel security architecture of the mobile device 100 enables implementation of the eSE120 without the need for (non-adjustable) integrated non-volatile memory for storing security-sensitive applications, while also providing secure execution and storage of a large number of NFC applications. More specifically, the eSE120 is structured to securely access security-sensitive applications (such as NFC applications and associated data) as the secure data 135 in the main non-volatile memory 110. Details of how the eSE120 performs this secure storage are described further below with reference to fig. 2.

Fig. 2 shows one possible block diagram of an eSE120 implementation in accordance with an embodiment of the invention. As shown in fig. 2, the eSE120 does not include integrated (non-adjustable) non-volatile memory for storing security-sensitive applications. Instead, the eSE120 includes an NFC interface 205, a host interface 210, a microprocessor 215, a volatile memory 220, a symmetric and asymmetric key processor (symmetricalkeyprocessor) 225, a Random Number Generator (RNG) 230, a hash processor (hashprocessor) 235, and a replay counter 240. In one embodiment, a bus 255 communicatively couples these components of the eSE120 together.

In operation, microprocessor 215 is configured to execute security-sensitive applications, such as a security-sensitive NFC application. In one embodiment, microprocessor 215 is configured to execute security sensitive applications in a runtime environment specified by the GlobalPlatform and/or JavaCard specifications. NFC application executed by microprocessor 215 may exchange data and commands 245 with a remote NFC-enabled device via NFC interface 205 coupled to NFC controller 125 shown in fig. 1. In addition, NFC applications (and other applications) executed by microprocessor 215 may further exchange data and commands 250 with host application processor 105 via host interface 210.

Security sensitive applications and associated data may be encrypted by eSE120 and stored in main non-volatile memory 110, as shown in fig. 1. In one embodiment, the eSE120 can generate random numbers using the RNG230 to construct one or more asymmetric or symmetric keys. These constructed keys may be used to encrypt security sensitive applications and associated data for storage in the main non-volatile memory 110.

The eSE120 can perform encryption of security-sensitive applications and associated data using the symmetric and asymmetric key processor 220. The symmetric and asymmetric key processor 220 is configured to support symmetric encryption algorithms, such as AES and DES, and asymmetric (i.e., public) encryption algorithms, such as RSA and DSA. Symmetric and asymmetric crypto processor 220 may use one or more keys generated at least in part using RNG230 in conjunction with one or more encryption algorithms it supports to encrypt security-sensitive applications and associated data. Alternatively, the symmetric and asymmetric key processor 220 can use one or more credential keys (endomentkeys) or other keys that are unique to the eSE120 or the user/owner of the mobile device 100 in conjunction with one or more encryption algorithms that support encryption of security-sensitive applications and associated data. In one embodiment, the key used to encrypt the security-sensitive application and associated data is confined within the eSE120 (i.e., it cannot be removed from the eSE 120). In another embodiment, the key used to encrypt the security-sensitive application and associated data is portable and may be transferred to, for example, another SE.

Once the security-sensitive applications and associated data are encrypted by the eSE120, they can be stored in the main non-volatile memory 110 as secure data 135. In an embodiment, the encrypted security-sensitive application (and associated data) is stored in the main non-volatile memory 110 as a binary large object (blob). The eSE120 can transmit the encrypted data to the primary non-volatile memory 110 through the primary application processor 105. In further embodiments, the process of transferring encrypted security-sensitive applications and associated data to and from the main non-volatile memory 110 is handled by a memory manager running on the eSE120 and the main application processor 105. These memory managers can be used to make the main non-volatile memory 110 appear as if it is directly coupled to the eSE120 and accessible to the eSE 120. In other words, the main non-volatile memory 110 is directly addressable by the eSE120 using a memory manager.

In another embodiment, the eSE120 can replace storing encrypted security-sensitive applications and associated data in a Subscriber Identity Module (SIM) 115 as the security data 140, further illustrated in fig. 1. The eSE120 can access the SIM115 through the host application processor 105 and/or through a direct connection (not shown). In an embodiment, encrypted security-sensitive applications (and associated data) are stored in the SIM115 as a blob.

eSE120 can further generate a cryptographic hash (e.g., a digital signature or Message Authentication Code (MAC)) of the security-sensitive application and/or associated data using hash processor 235. In particular, the hash processor 235 can be configured to execute one or more hash algorithms, any of which can be used by the eSE120 to generate a hash. For example, the hash processor 235 may perform one or more of the following hash algorithms: MD5, RIPEMD-160, SHA-1, SHA-256, SHA-384, and SHA-512, to name a few. The resulting cryptographic hash, upon loading and decryption from the main non-volatile memory 110, can thereafter be used by the eSE120 to verify the integrity of the security-sensitive application and/or associated data. The encrypted hash of the security-sensitive application and/or associated data may be stored in the main non-volatile memory 110 along with the encrypted security-sensitive application and/or associated data. In an embodiment, an encrypted hash of the encrypted security-sensitive application and associated data may be stored in the main non-volatile memory 110 as a blob along with the encrypted security-sensitive application and associated data.

The volatile memory 220 of the eSE120 is structured to store encrypted security-sensitive applications and/or associated data loaded from the main non-volatile memory 110. The encrypted security-sensitive application and/or associated data can be loaded from the primary non-volatile memory and stored in the volatile memory 220 of the eSE120 in response to an action by the primary application processor 105 or the NFC controller 125. For example, an application executing on the host application processor 105 may request or require execution of one or more security-sensitive applications. In another example, the NFC controller may request or require execution of a security sensitive NFC application. After these requests and other actions are made by the host application processor 105 and/or NFC controller 125, the eSE120 can load one or more encrypted security-sensitive applications and/or associated data from the host non-volatile memory 110.

Once the encrypted security-sensitive applications and/or associated data are stored in volatile memory 220, they can be decrypted and verified by the eSE 120. The eSE120 can perform validation with a hash processor 235. More specifically, the eSE120 can perform the verification using a cryptographic hash stored with and corresponding to the encrypted security-sensitive application and/or associated data (loaded from the non-volatile memory 110).

Although the eSE120 can prevent and detect changes made to security-sensitive applications and/or associated data stored in the main non-volatile memory 110 through the use of encryption and hashing, these security mechanisms cannot detect or prevent replay attacks of the security-sensitive applications' associated data. A replay attack is an attack in which valid data is copied (repeat). Replay attacks are typically compromised by intercepting valid data and then fraudulently reusing that data in subsequent transactions.

For example, for NFC-based payment applications configured to allow credit card issuers to store balances as association data on a user's mobile device, encrypting and cryptographically hashing the association data may be used to prevent and detect unauthorized changes to the stored balance. However, these security mechanisms do not prevent an attacker from being intercepted and replaying the stored balance in subsequent transactions. That is, even if the balance is signed, the attacker can copy the old form of the signature balance and reuse the copy for future purchases. If the balance is not stored on the central server, or if the merchant is not in contact with the central server where the balance is stored, the merchant will consider the balance to be authentic. However, the merchant cannot distinguish whether the balance is new (fresh) (i.e., not an old copy).

To prevent such replay attacks from occurring, the eSE120 also includes a replay counter 240. In an embodiment, replay counter 240 is a monotonic counter (monoticcounter) that may be used to detect and thereby prevent replay attacks. Because the replay counter 240 is stored in the secure environment of the eSE120, the monotonic count value maintained by the replay counter 240 can be hosted by third parties (e.g., credit card issuers and merchants).

The eSE120, in particular, uses the replay counter 240 to protect a dedicated monotonic count value for one or more secure per-application executions of the eSE120 (requiring and/or requesting a replay counter). The private count values for one or more security-sensitive applications are packaged together, encrypted, and tagged, and then stored by eSE120 in main non-volatile memory 110. In one embodiment, an encrypted and signed packet of a dedicated monotonic count value is stored in the main non-volatile memory 110 as a blob.

Each time the associated data for a security sensitive application is updated or changed, the application specific count value is incremented (increment) within the package and the value of the replay counter 240 is further incremented. Once incremented, a copy of the current technology value of the replay counter 240 is included in a packet of private, monotonic count values, which is then encrypted and signed. When a security-sensitive application attempts to use its associated data (which may include, for example, a stored balance), the eSE120 may check not only that the signature of the associated data is valid, but also that the count value of the replay counter 240 stored in the replay counter package matches the current value of the replay counter 240. If the two values match, the application-specific count value stored in the package is valid and can be used by the merchant or mobile device to prevent replay attacks. In one embodiment, a copy of the application specific count value for a particular application may be stored with the associated data for the particular application in the main non-volatile memory 110. The comparison of the stored copy to the authentication count value for the particular application stored in the packet can detect and thereby prevent replay attacks.

It should be noted that although the eSE120 described above does not include integrated non-volatile memory (which is not adjustable) for storing security-sensitive applications, in other embodiments the eSE120 can include such memory. It should further be noted that while the main non-volatile memory 110 can be used to store the secure data 135, in general, any non-volatile memory external to the eSE120 can be used.

FIG. 3 illustrates an example packet 300 for detecting a replay attack, according to an embodiment of the present invention. As shown in FIG. 3, packet 300 includes N dedicated count values 305, each corresponding to a copy 310 of the count value of security-sensitive application and replay counter 240 shown in FIG. 2. The package 300 may be encrypted, signed, and stored in the primary non-volatile memory 110, which is further illustrated in fig. 2. In one embodiment, the package 300 is encrypted, signed, and stored as a blob in the main non-volatile memory 110.

Referring now to fig. 4, shown is a block diagram of a security architecture for securely storing applications and associated data in the main memory of a mobile device 400 and in a non-volatile memory directly coupled externally to an eSE in accordance with an embodiment of the present invention. The structure of mobile device 400 is similar to mobile device 100 in fig. 1. However, the mobile device 400 also includes additional non-volatile memory 405 that is directly coupled to the eSE 120.

Non-volatile memory 405 may include one or more of Read Only Memory (ROM), Electrically Erasable Programmable ROM (EEPROM), and flash memory, to name a few. In an embodiment, non-volatile memory 405 is configured to store secure data, such as secure data 135, including encrypted and signed security-sensitive applications and associated data. Because the non-volatile memory 405 is directly coupled to the eSE120, the security sensitive applications stored therein, encrypted and signed, can be accessed even when the main application processor 105 is not activated and/or powered up.

Referring now to fig. 5, shown is a block diagram of a security architecture for securely storing applications and associated data in a main memory of a mobile device 500 that also includes a fingerprint sensor coupled directly to an eSE, in accordance with an embodiment of the present invention. The structure of the mobile device 500 is similar to the mobile device 100 shown in fig. 1. However, the mobile device 500 also includes a fingerprint sensor 505 and a non-volatile memory 510 that are directly coupled to the eSE 120.

The fingerprint sensor 505 is configured to scan a finger. For example, fingerprint sensor 505 may be used to scan a tentative user of mobile device 500 to grant or deny access to mobile device functions, or may be used to scan a personal fingerprint to support the functionality of an application executing on mobile device 500. Fingerprint templates corresponding to valid users or individuals may be stored in the non-volatile memory 510. If the fingerprint scanned by the fingerprint sensor 505 matches one or more templates stored in the non-volatile memory 510, the eSE120 can use these templates to authenticate the user or person. In an embodiment, the eSE120 encrypts and signs the fingerprint templates before the templates are stored in the non-volatile memory 510. Because the fingerprint sensor 505 is directly coupled to the eSE120, the fingerprint sensor 505 and the eSE120 can be used in conjunction to authenticate a user even when the host application processor 105 is not activated and/or powered up.

Non-volatile memory 510 may include one or more of Read Only Memory (ROM), Electrically Erasable Programmable ROM (EEPROM), and flash memory, to name a few. In an embodiment, the non-volatile memory 510 is further directly coupled to the eSE120 and can be accessed even if the primary application processor 105 is not activated and/or powered up.

Fig. 6 illustrates a flow diagram 600 of a method of securely storing an application and associated data in a main memory of a mobile device executed by an eSE, in accordance with an embodiment of the present invention. Flowchart 600 is described with the continued exemplary operating environment shown in fig. 1. However, the flowchart 600 is not limited to this embodiment. For example, flowchart 600 is equally applicable to the operating environments illustrated in fig. 4 and 5.

Flowchart 600 begins at step 605 and transitions to step 610. In step 610, code and data associated with the security-sensitive application (e.g., NFC application) are encrypted by the eSE 120. In addition to being encrypted by the eSE120, the encrypted code and data can be further signed.

At step 615, the encrypted code and data are stored in the main non-volatile memory 110 external to the eSE as a blob.

At step 620, the blob is loaded from main non-volatile memory 110 through eSE 120. The blob may be loaded in response to an action or request by at least one of the host application processor 105 and the NFC controller 125. Once loaded, the loaded blob may be stored in non-volatile memory of the eSE 120.

At step 625, the code and data stored as the blob loaded from main non-volatile memory 110 is decrypted and, if signed, verified by eSE 120.

The decrypted (and possibly verified) code and data is executed by the eSE120 at step 630.

At step 635, data associated with the security-sensitive application is updated by the eSE120 based on execution of the code. For example, the data may be updated based on exchanging information with a remote NFC-enabled device, the information exchange occurring after execution of the code.

After step 635, flowchart 600 returns to step 610 where the code and update data for the security-sensitive application may again be encrypted by eSE120 and stored in main non-volatile memory 110.

FIG. 7 illustrates a flow chart 700 of a method for updating a private packet of counter values corresponding to a security-sensitive application and for securely storing the packet of counter values in a primary non-volatile memory of a mobile device, according to an embodiment of the present invention. A dedicated packet of count values may be used to prevent replay attacks. Flowchart 700 is described with continued reference to the exemplary operating environment shown in fig. 1 and 2. However, flowchart 700 is not limited to these embodiments. For example, flowchart 700 may apply equally to the operating environments shown in fig. 4 and 5.

Flowchart 700 begins with step 705 and proceeds to step 710. At step 710, it is determined by the eSE120 whether an update or change has been made to data associated with a security-sensitive application having a corresponding private count value stored in the package. If no updates or changes are made, the flowchart 700 may return to step 705 and the method of flowchart 700 may begin again. If an update or change has been made, flowchart 700 proceeds to step 715.

At step 715, the private count value for the security-sensitive application for which the associated data has been updated or changed is incremented and the replay counter 240 is incremented.

At step 720, a copy of the current count value of the replay counter 240 is included in the packet. This copy may replace the previous copy of the count value of the replay counter 240 stored in the packet.

At step 725, the packet is encrypted, signed and stored in the primary non-volatile memory 110.

Fig. 8 shows a flow diagram 800 of a method for detecting a replay attack using a dedicated packet of counter values securely stored in a main non-volatile memory of a mobile device, the dedicated packet of counter values corresponding to a security-sensitive application, according to an embodiment of the invention. Flowchart 800 is described with continued reference to the exemplary operating environment shown in fig. 1 and 2. However, flowchart 800 is not limited to these embodiments. For example, flowchart 800 is equally applicable to the operating environments described in fig. 4 and 5.

Flowchart 800 begins with step 805 and proceeds to step 810. At step 810, a package of dedicated count values is loaded from main non-volatile memory 110 by eSE120 in response to a request or action, e.g., performed by at least one security-sensitive application (having a corresponding dedicated count value stored in the package).

At step 815, the eSE120 decrypts and validates the private count value package. Authentication may be performed using a cryptographic hash.

At step 820, a copy of the count value of the replay counter 240 stored in the packet is compared to the current count value maintained by the replay counter 240.

At step 825, it is determined by the eSE120 whether the two count values compared in step 820 match. If the two count values do not match, the flowchart 800 proceeds to step 820 and a replay attack involving the storage packet is detected. If the two count values match, flowchart 800 proceeds to step 835.

At step 835, the application-specific count value stored in the package may be considered valid by the merchant or mobile device and may be used to detect replay attacks. In one embodiment, a copy of the application specific count value for a particular application may be stored with the associated data for the particular application in the main non-volatile memory 110. The comparison of the stored copy with the check count value of the particular application stored in the packet can detect and thus prevent replay attacks.

It should be understood that the above-described embodiments of the present invention may be implemented in hardware, firmware, software, or any combination thereof. Embodiments of the invention may be implemented as instructions stored on a machine-readable medium, which may be read and executed by one or more processors. A machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computing device). For example, a machine-readable medium may include Read Only Memory (ROM); random Access Memory (RAM); a magnetic disk storage medium; an optical storage medium; a flash memory device; electrical, optical, acoustical or other form of propagated signals.

The invention has been described above with the aid of functional blocks illustrating the implementation of specific functions and relationships thereof. Boundaries of functional building blocks have been arbitrarily defined herein for the convenience of the description. Other boundaries may be defined so long as the specified functions and relationships thereof are appropriately performed.

Claims (16)

1. A method of executing a near field communication application stored in non-volatile memory external to an embedded secure element of a mobile device using the embedded secure element, the method comprising:

loading code and state data associated with the near field communication application from the non-volatile memory into the embedded secure element;

verifying the code and the state data loaded from the non-volatile memory;

after verifying the code and the status data, executing the code in the embedded secure element to exchange data with a contactless communication device using a near field communication controller;

incrementing a private count value corresponding to the near field communication application in response to the status data being updated based on the data exchanged with the contactless communication device; and

maintaining the private count value in a private count value packet protected by a replay counter of the embedded secure element.

2. The method of claim 1, wherein the code and the state data are stored in encrypted form in the non-volatile memory.

3. The method of claim 1, wherein the code and the status data are decrypted before being verified.

4. The method of claim 1, wherein the non-volatile memory is accessible by the embedded secure element through a host application processor of the mobile device.

5. The method of claim 1, further comprising:

encrypting the updated state data and storing the encrypted updated state data in the non-volatile memory.

6. The method of claim 1, further comprising:

incrementing the replay counter in the embedded secure element in response to an increase in one of the private count values in the private count value packet.

7. The method of claim 6, further comprising:

detecting a replay attack involving the private count value packet using the replay counter in the embedded secure element.

8. The method of claim 1, wherein the near field communication application is a payment application, or a ticketing application.

9. A mobile device, comprising:

an embedded security element is provided, which is,

a non-volatile memory external to the embedded secure element,

wherein the embedded security element is configured to:

loading code and state data associated with an application program from the non-volatile memory;

verifying the code and the state data loaded from non-volatile memory;

executing the code to exchange data with a contactless communication device using a near field communication controller;

incrementing a dedicated count value associated with the application in response to the status data being updated based on the data exchanged with the contactless communication device; and is

Maintaining the private count value in a private count value packet protected by a replay counter of the embedded secure element.

10. The mobile device of claim 9, wherein the code and the status data are stored in encrypted form in the non-volatile memory.

11. The mobile device of claim 9, wherein the code and the status data are decrypted before being verified.

12. The mobile device of claim 9, wherein the non-volatile memory is accessible by the embedded secure element through a host application processor of the mobile device.

13. The mobile device of claim 9, wherein the embedded secure element is further configured to encrypt the updated state data and store the encrypted, updated state data in the non-volatile memory.

14. The mobile device of claim 9, wherein the embedded secure element is configured to increment the replay counter in the embedded secure element in response to an increment of one of the private count values in the private count value packet.

15. The mobile device of claim 14, wherein the embedded secure element is configured to detect a replay attack involving the private count value packet using the replay counter in the embedded secure element.

16. The mobile device of claim 9, wherein the code is a payment application, or a ticketing application.