In this thesis, a secure execution platform is designed to offer strong assurances regarding the preservation of the integrity, authenticity, availability and confiden-tiality of its host applications. This includes any associated data, both persistently and at run-time. Examples of such platforms include traditional smart cards, Java Card and Secure Elements (SEs). The platform is built to resist significantly greater security threats, including hardware- and software-based attacks.
The next section (Section2.2.1) describes the Common Criteria for Information Technology Security Evaluation (Common Criteria or CC, for short), which is a widely-used computer security framework for evaluating and certifying the security of secure and trusted execution platforms. This is introduced to discuss and briefly compare the assurance levels to which platform is evaluated. The subsequent sections present a review of widely-deployed, hardware-assisted secure execution platforms in mobile and embedded systems. This includes a brief examination of smart cards (Section2.2.2); Secure Elements (SEs), e.g.
UICC and SIM Cards (Section2.2.3); and Java Card (Section2.2.4). Additionally, Host-based Card Emulation is discussed in Section2.2.5 for emulating smart card-based services on mobile platforms.
14HP Envy X2:http://www8.hp.com/us/en/campaigns/envy-x2/overview.html
2.2.1 Common Criteria
The Common Criteria for Information Technology Security Evaluation – com-monly referred to as Common Criteria (CC) – is an international standard for evaluating product security, which is formalised in ISO/IEC 15408 [38]. Ander-son [39] defines security evaluation as “the process of assembling evidence that a system meets, or fails to meet, a prescribed assurance target”. CC replaced individual national schemes, such as the US Department of Defense’s Orange Book and European Information Technology Security Evaluation Criteria (ITSEC), which previously required vendors to ascertain multiple evaluation certificates based on the intended deployment region. CC is used to convince procurers and other stakeholders, such as government agencies, that a security product robustly conforms to a recognised specification.
In CC, the product presented for evaluation by its vendor is known as the Target of Evaluation (TOE). A Protection Profile (PP) is then chosen that stipulates the security requirements of a class of systems; for example, CC PPs have been developed by for TEEs (GlobalPlatform TEE PP [40]) and SEs (GlobalPlatform SE PP [41]). CC PPs explicitly include list of threats, assumptions, organisational policies, security objectives, rationales, security functional (SFR) and assurance (SAR) requirements. A separate but closely-related Security Target (ST) is also often defined that contains implementation-specific details of a TOE, which claims conformance to one or more CC PPs. The vendor makes claims regarding the ST’s attributes to those in the PP, and an independent testing laboratory evaluates the TOE to assess the rigour of those claims.
The degree to which the TOE satisfies the assurances is graded using Evalu-ation Assurance Levels (EALs), ranging from EAL1 for which basic functional testing is required, up to EAL7 requiring a formally verified design. The ST speci-fies the Evaluation Assurance Level (EAL) that the TOE ought to fulfil. The EALs provide confidence that the TOE’s supposed security features are implemented reliably. The CC EALs are described in greater detail in Table2.1.
2.2.2 Smart Cards
A smart card is a lightweight, pocket-sized device containing an embedded inte-grated circuit(s). They are securely packaged using a polymer, such as polyvinyl chloride (PVC), and used to store sensitive personal credentials. Notable appli-cation domains include physical access control systems, like security gates and doors; financial transactions, e.g. credit and debit cards; public transportation tickets and passes; and national identity card schemes, like those used in Belgium, Estonia and Finland [43]. Contact-based smart cards use connective pads for
TABLE2.1: Common Criteria Evaluation Assurance Levels (EALs) based on US-CERT definitions [42].
EAL Description
1 Functionally Tested: Confidence is required in the TOE’s correct operation against non-serious threats; provides evidence that the TOE functions consistently with its documentation and provides useful protection against identified threats.
2 Structurally Tested: Low-to-moderate security assurances, but the complete development record is not readily available. This situation may arise when there is limited developer access or when securing legacy systems.
3 Methodically Tested and Checked: Moderate assurances and a thorough inves-tigation of the TOE and its development without substantial re-engineering.
4 Methodically Designed, Tested and Reviewed: Moderate-to-high assurances in conventional commodity products; prepared to incur additional security-specific engineering costs.
5 Semiformally Designed and Tested: High assurances in a planned develop-ment environdevelop-ment; requires rigorous developdevelop-ment approach that does not incur unreasonable costs from specialist security engineering techniques.
6 Semiformally Verified Design and Tested: Applies to TOEs in high-risk situations where the protected asset value(s) justifies the additional costs.
7 Formally Verified Design and Tested: Applies to TOEs in extremely high-risk situations and where the high value of the assets justifies the higher costs.
electrical activation and data transmission. Contactless smart cards communi-cate with a terminal occurs over a radio frequency interface, usually at a <10cm distance. Contactless and contact-based smart cards are standardised in ISO/IEC 14443 [44] and 7816 [45] respectively. These standards define, among others, the physical characteristics of cards, including dimensions and location of electrical contacts; operational frequency (13.56 MHz); radio power; and initialisation, transmission, anti-collision, application and data management protocols. Stan-dards also exist specifying the operational requirements of smart cards within particular domains, such as EMV15for the technical details of payment cards and terminals.
A typical smart card architecture comprises a 8-/16-/32-bit CPU (usually with <35MHz clock); ROM for hosting a slimline OS and its applications (<32kB);
EEPROM for data storage (<24kB); RAM (<8kB) for temporary in-execution storage; and a security co-processor for performing cryptographic operations, e.g.
3DES, AES and RSA [46]. High-security smart cards, such as credit and national ID cards, are engineered to be tamper-resistant. This includes a co-processor built to resist a range of hardware/physical security threats, such as simple and differential power analysis (SPA/DPA), layered packaging that deters invasive physical attacks without damaging the card, and a rigorously-tested OS. Smart
15EMV: Europay, Mastercard, Visa.
cards are also manufactured and provisioned in a secure production environment.
Cards for high-security commercial applications, e.g. healthcare access control cards, are typically evaluated to CC EAL4 [47].
2.2.3 Secure Elements (SEs)
A Secure Element (SE) is a tamper-resistant platform capable of securely host-ing code and confidential data, such as cryptographic keys, accordhost-ing to the processes established by its owner. SEs are currently available in three form factors: the Universal Integrated Circuit Card (UICC), commonly found in the SIM card format; the embedded SE (eSE), which is integrated into the NFC chip or directly onto the device PCB; and an enhanced secure microSD card. All SE forms accommodate a smart card microcontroller for storing sensitive credentials and hosting a limited set of applications. The use of a microcontroller means SEs typically have restricted memory and processing capacity relative to an SBC or traditional computing system, as discussed in Section2.1.3. SEs are often used in conjunction with NFC for performing payment tokenisation for contactless payments using multi-use tokens provisioned into the SE before deployment [48].
Another common application is the execution of fingerprint matching algorithms and the storage of users’ biometric templates [49]. In general, SEs aim to defend against threats similar to that of a smart card (Section2.2.2), including advanced side-channel analyses, e.g. power analysis, and fault injection [48]. GlobalPlat-form has standardised SEs in the Financial [50], UICC [51], Card Common [52], and Card Contactless [53] configuration specifications.
2.2.4 Java Card
Java Card [54] provides an interoperable secure platform for SEs, which al-lows them to run multiple applications (applets) written in a subset of the Java language. The fundamental components of a Java Card platform are: 1), a Virtual Machine (VM) composed of a bytecode interpreter providing hardware-independence and, from version 3.x, a mandatory embedded bytecode verifier.
2), a set of APIs that abstract the complexity of the underlying smart card com-munications protocols, offer access to cryptographic functionalities, and secure inter-applet data sharing. 3), a Java Card Runtime Environment (JCRE) with additional security mechanisms, such as atomically updating persistent data.
And, lastly, 4), a firewall that maintains strong isolation between applets and the system, and between applets from differing packages (see Figure2.4).
The firewall enforces the security rules by restricting the rights of an applet to applets from the same provider but in different packages, or in the same package from different providers. Applets from the same package are in the same context.
Secure Operating System and Hardware
Application provider A Application provider B
Trusted
FIGURE2.4: Java Card architecture.
An applet may only access objects owned by another applet in a different context if they are explicitly tagged as ‘shared’ items. Notably, while Java Card may host multiple applets, it is a single-threaded environment. The traditional ownership model for Java Card is issuer-centric (ICOM), where only the Java Card issuer can install applications. GlobalPlatform has standardised mechanisms through which authorised third-parties can install applications via the use of Security Domains (SDs), which are described later in Section2.4.7.
2.2.5 Host-based Card Emulation (HCE)
Host-based Card Emulation (HCE), introduced in Android 4.4 (API 19), enables NFC-enabled mobile devices to emulate contactless smart cards [55]. HCE’s aim is to allow mobile devices to fulfil services with existing NFC-based card-reader infrastructures, which would otherwise have been deployed using smart cards, without using discrete SEs [48]. Prior to HCE, data sent and received to a terminal was routed through an NFC controller connected directly to a SE aboard the mobile device (Figure2.5a). With HCE, the host OS handles the routing of the messages, which may use a hardware-based SE or an application executing on the host CPU. In Android, this is implemented as an application service that executes as a long-running background task. This allows the user to place the device against an NFC reader to execute transactions with the correct service in the background, without manually launching a dedicated mobile application. In both SE- and HCE-based deployments, data is routed to a particular application based on its 16-byte Application ID (AID), as stipulated in ISO/IEC 7816-4 [45]. The AIDs are registered with the mobile’s NFC controller, which maintains a routing table of the AIDs belonging to which applications [55]. In NFC transactions, the first Application Protocol Data Unit (APDU) is the SELECT command, also
(A) SE-based (B) HCE-based FIGURE2.5: Card emulation using a SE (a) and HCE (b).
defined in ISO/IEC 7816-4 [45], containing the AID of the application with which to process further NFC transaction messages.
The confusion lies in that, while HCE aims to supplant the role played by hardware SEs and contactless cards, it does not provide the same degree of tamper-resistance. In itself, HCE is a routing mechanism, while credential storage and application execution may, at a minimum, be protected by the security mechanisms afforded by the OS itself, such as application sandboxing, i.e. software-only.
This is opposed to SEs and contactless cards where application execution and credential storage is conducted within a tamper-resistant platform. As such, it is not recommended that critical transactions, like mobile payments and high-security access control, are based solely on HCE [55]. A cloud-based SE is seen as one solution whereby credentials are managed off the device and where the HCE-enabled application acts a medium for acquiring dynamically-generated, limited-use credentials from a remote server [56]. However, this has the drawback of requiring network connectivity. Another solution is the Trusted Execution Environment (TEE), described in Section2.4, to host these credentials; we return to mobile-based NFC transactions in conjunction with TEEs in greater detail in Chapter7.