Today, security plays an important role in many electronic devices and computing environments. For example, conventional mobile electronic devices may be used for payment transactions which require that sensitive payment-related data, such as user credentials, are input and/or stored on said devices. Such mobile electronic devices may for instance be equipped with a near field communication (NFC) interface based on radio frequency (RF) technology, in order to exchange payment-related data with a payment terminal device at a point-of-sale (POS).
Traditionally, sensitive payment-related data have been incorporated into dedicated security tokens such as smart cards, in which the data are inherently confined to a relatively trusted environment. However, with the advent of integrated solutions, in particular the integration of so-called secure elements (SEs) in mobile devices, payment-related data are often exposed to a potentially hostile environment, and therefore the confidentiality of these data may be at stake.
A secure element is often implemented as an embedded chip, more specifically as a tamper-resistant integrated circuit with (pre-) installed smart-card-grade applications, for instance payment applications, which have a prescribed functionality and a prescribed level of security. Alternatively, so-called Subscriber Identity Modules (SIMs) or Universal Subscriber Identity Modules (USIMs) may be used as secure elements. Furthermore, secure digital (SD) cards, such as traditional SD cards or micro-SD cards, may be used as secure elements. A secure element may be embedded in a mobile device or another host device, for example as a small outline package soldered directly on a printed circuit board. Alternatively, a secure element may be comprised in said mobile device as a removable component (e.g. a SIM or an SD card).
Although a secure element offers a relatively secure environment for executing applications, it is relatively difficult to achieve and maintain this level of security, for example when operating components of the secure element need to be installed and/or configured. In particular if the software installed on a secure element needs to be updated, for example the secure element's operating system, then the secure element may be susceptible to attacks. Although many techniques exist for providing secure software updates, these techniques usually do not address updating software on secure elements of the kind set forth. For example, WO 2012/109640 A2 describes a secure software update that provides an update utility with an update definition, a private encryption key and a public signature key to a target device. A software update package is prepared on portable media that includes an executable update program, a checksum for the program that is encrypted with a symmetrical key, an encrypted symmetrical key that is encrypted with a public encryption key and a digital signature prepared with a private signature key. The update process authenticates the digital signature, decrypts the symmetrical key using the private encryption key, and decrypts the checksum using the symmetrical key. A new checksum is generated for the executable update program and compared to the decrypted checksum. If inconsistencies are detected during the update process, the process is terminated. Otherwise, the software update can be installed with a relatively high degree of assurance against corruption, viruses and third party interference.
As another example, WO 2007/014314 A2 describes improved techniques to update software in electronic devices that are already in use. In one embodiment, software can be updated in a secure and controlled manner using cryptography. The authenticity of the updated software as well as its appropriateness for the particular electronic device can be confirmed prior to update. The software can also be updated on a per module basis. In one embodiment, a server hosts software updates for various electronic devices, and supplies the appropriate software update to the electronic devices via a data network.
FIG. 1 shows a conventional computing system in which a secure element is used. The computing system 100 comprises a host device 102, a host device vendor 108, a trusted service manager 110, and a secure element issuer 112. The host device 102 may for example be a so-called smart phone or a tablet equipped with NFC technology, as described above. The host device 102 comprises a central processing unit 104 and a secure element 106.
In order to prepare the computing system 100 for use, the secure element issuer 112 issues a secure element 106 for integration into the host device 102. In addition, the secure element issuer 112, or the secure element producer (not shown) on their behalf, installs an initial version of an operating system on the secure element 106. It is noted that the operating system of the secure element 106 is referred to as “Secure OS” in the remainder of this document. Furthermore, the host device vendor 108 installs an initial version of an operating system of the host device 102 in the host device 102, typically in a Flash memory (not shown) of said host device 102. It is noted that the operating system of the host device 102 is referred to as “Host OS” in the remainder of this document.
In use, both the Secure OS and the Host OS may have to be updated, for example in order to provide additional security features or other functionality. Typically, the host device vendor 108 is responsible for installing updates of the Host OS on the host device 102. For example, many host devices are nowadays configured to automatically receive and install broadcasted updates of the Host OS. An example of such a regularly updated Host OS is the Android operating system. The Secure OS may also have to be updated on a regular basis. However, in this case, a third party referred to as a trusted service manager (TSM) 110 typically acts as an intermediate for installing updates of the Secure OS. In particular, since the secure element issuer 112 no longer has access to secure elements which are already in the field (i.e. in use), it provides updates of the Secure OS to the trusted service manager 110. Subsequently, the trusted service manager 110 manages the installation of the Secure OS updates on the secure element 106.
Unfortunately, however, the mechanisms used to install these updates on the secure element 106 are typically quite cumbersome. In particular, they rely on hardware-specific encryption methods which are complicated and inflexible. Also, they typically require setting up secure point-to-point communication channels between secure elements and trusted service managers. In view thereof, there exists a need to facilitate and simplify the installation of operating system updates on secure elements. It is noted that the same problem may occur if other software updates have to be installed on secure elements; in other words, this problem is not limited to updates of the Secure OS. Thus, in more general terms, there exists a need to facilitate and simplify the installation of software updates on secure elements of the kind set forth.