6.2.1 Secure Service Platforms

The ‘traditional’ OTA platform offered the means for MNOs to provision new subscriptions and remotely manage the SIM card contents, e.g., updating applets. This concept is developing further to provide advanced functionalities. One example of such development is the Allynis Advanced Over‐the‐Air (AOTA) SaaS platform. Sprint uses this platform to facilitate LTE service activations and to manage the complexities of providing multi‐band 4G LTE connectivity [1]. There are various other solutions in the market, including solutions based on the SmartTrust Delivery Platform [9].

6.2.2 SEs

SEs have an integral role in the most secure connections, provisioning, authentication and encryption of the communications. SEs have many different physical forms such as the traditional SIM/UICC with Form Factors of 2FF, 3FF and 4FF. In addition, there is a growing number of eSEs adapted from the M2M Form Factor MFF2, which so far is the only internationally standardized variant. It is expected that there will be a growing need for physically much smaller embedded elements along with the rapidly increasing number of IoT devices and wearables such as smart watches. More detailed information about SEs can be found in Chapter 4.

The SE that functions especially with NFC forms an important part of the NFC device. The SE in this case may be the UICC, eSE or external microSD. The environment also contains the NFC controller, NFC chip, and protocol stack for the communications between the NFC element and baseband processor of the device. NFC can be used as a very logical base for the payment platforms for mobile wallet solutions. This also requires fluent functioning and an intuitive user interface for the respective applications. The communication protocols and interfaces related to the NFC environment include ISO 7816, ISO 14443, SWP, UART, I²C and SPI.

The SE requires a respective OS which is typically capable of handling Java applets. This ensures the interactions between multiple systems of MNOs, TSMs, data preparation systems and POS transactions. As an example, GlobalPlatform, SIMalliance and ETSI are working on the SE interoperability for advanced platforms via international specifications.

The communications of the SEs take place via secure channels (between card and remote servers) and APDUs transmitted between the card and external world (card reader of the device). The benefit of modern SIM/UICC is that it can house multiple applications and security domains. Thus, it is possible to utilize various payment schemes, such as mobile wallets of different providers, as well as access and transit services and any other wireless solutions that rely on the SIM/UICC application/applet. The SIM/UICC security is useful for many platforms.

6.3.1 SIM as a Basis for OTA

Being a tamper‐resistant HW element, the SIM/UICC functions well for the mobile communications environment. It provides user authentication, authorization, and ciphering for the users’ connections. In addition to the basic functionalities, the SIM/UICC also works as a platform for adding applets that enrich the user experience. Nevertheless, the SIM/UICC also has some limitations such as the communications speed between the card and respective card reader (mobile equipment). For that reason, it might not be an optimal solution for environments where many fast transactions are needed, especially if the communications are based on the short message bearer. With more modern methods such as CAT/BIP, the communications speed of the SIM/UICC clearly increases.

The applications executed via the mobile device’s OS provide fluent user experiences but they lack the highest security regardless of virus defences and other typical means for protecting the device. Thus, novel methods have been developed for coping with the security issues while providing fluent execution of the code. These methods include technologies such as TEE that relies on the processor HW, and HCE that may provide a completely HW‐free environment. For the highest protection level with these new methods, the combination of the SIM/UICC is still valid.

The SIM/UICC is based on ISO/IEC 7816 smartcard definitions. Along with the development of the mobile system generations, the subscriber card has also evolved, supporting more advanced protection mechanisms, a better, more suitable Java Card for interoperable Java applets and additional services such as NFC. As the mobile communications’ value‐added services have been increased, the SIM/UICC has also been following the development and is capable of providing secure solutions, e.g., in automotive and banking environments.

As the user device types are evolving, one example is the growing popularity of wearables, the ‘traditional’ Form Factors of the cards face new challenges; the original Form Factors 2FF, 3FF and 4FF are simply not small enough to fit into miniature devices. This has resulted in the need for embedded Form Factors. There are also other variants that are still chip‐set vendor‐specific for the pin layout and size. The benefit of the embedded SIM/UICC is the considerable space savings, but new methods are needed for the OTA subscription management as they are no longer removable, unlike the previous 2FF, 3FF and 4FF.

The strong security of the SIM/UICC is based on the message types between the card/element and the reader device (mobile equipment). There is no direct I/O communication, instead the communication takes place via APDU messages as described in section 4.11.1. This makes the SIM/UICC comparable to a standalone ‘computer’ with its own memory elements, processors and messaging protocols with the external world. The main bottleneck of the SIM/UICC is related to the communications speed between the card reader and card. This might be a limitation if an embedded applet is utilized for real‐time video contents display with very frequent key derivation.

The SIM/UICC, whether it is of traditional removable form or eSE, is resistant to security attacks, and is suitable for basic protection as well as any additional services the card can support. It is especially suitable for protecting payment transactions as the relevant information such as keys can be stored in a secure way.

Figures 6.1 and 6.2 depict examples of mobile payments based on NFC and the SIM/UICC or eSE. The mobile user, who has installed a payment application (typically referred to as a ‘mobile wallet’), triggers the payment event (1) by tapping the wireless NFC reader located at the POS of, e.g., a retail store. The payment request (2) is sent to the payment service provider (bank) which has its own SP TSM. The TSM communicates with the secure mobile application (3) residing in the SE (SIM/UICC) of the MNO. In order for this ecosystem to be functional, the service needs to be first initiated, i.e., provisioned for the end‐user by the bank and MNO (a, b). After the service has been initialized, the TSM of the SP is able to manage the funds of the payment app within the SE. In this mode, the MNO ‘leases’ SIM/UICC space for the bank’s app, which is thus one of the ‘tenants’ of the card, now being able to communicate with the SIM/UICC in order to accept the payment transactions of the respective end‐user.

6.3.2 TSM

TSM represents a ‘trusted third party’. Its role is to bring the participating service providers together for the provisioning and lifecycle management of secure payment, access, transit and other transactions based on the credentials related to the respective app within and communications with the SE. Some commercial TSM providers include Giesecke & Devrient and Gemalto.

The TSM functionality includes the provision and deletion of services, key management, data preparation and post‐issuance lifecycle management OTA. Different TSM models include TSM for the MNO (communications with the MNO’s SE), and TSM for Service Providers (SPs). The overall model for the TSM ecosystem is presented in Chapter 3.

For the TSM deployment, there are different models, which come in simple, delegated and authorized mode (see Figure 6.3). In the simple mode, the MNO performs the card content management and TSM can monitor it. In the delegated mode, the card content management is delegated to a TSM via prior authorization. Finally, in the authorized mode, the card content management is fully delegated to a TSM.

6.3.3 TEE

The TEE is located outside of the SIM/UICC but is still based on the HW within the user device. The idea of the TEE is to divide the processing functions of the mobile equipment into normal and secure domains, or normal and secure worlds. The Normal World (NWd) refers to the Rich Execution Environment (REE) while the Secure World (SWd) refers to the TEE. In addition to the TEE, the SWd has a set of containers that are isolated from the external world. They are similar to the secure domains of the NWd. The containers store trusted applications, or trustlets, which are similar to the applications of the NWd. Figure 6.4 depicts the joint architecture of the REE and TEE.

The OS of the NWd is called Rich OS, and it offers a variety of user experiences along with commercial OS variants such as Android and Windows and respective applications. The Rich OS is open for the third‐party SW and, regardless of the versatile protection mechanisms, it is vulnerable to security risks such as viruses. The TEE, in turn, is a protected environment of the mobile device that is based on both SW and HW residing within the processor. The TEE protects against software security attacks that may happen via the NWd. The TEE participates in the access and isolates the trustlets from the NWd OS [3–5].

One example of the benefits of the TEE is the service provider’s audio/video content display (such as a chargeable premium sports event) on the mobile device during a limited time period in such a way that the data stream cannot be replicated or copied to other devices or users. This contents delivery via TEE can be based on basically any bearer like PTP packet data or eMBMS.

The TEE thus provides a protection mechanism for the apps execution as they are completely isolated in the processor chip level. The respective level of security is close to that provided by the SIM/UICC, extending the use cases for protecting the device functions such as display, keyboard and microphone. As a highly concrete example, an app that is executed via TEE can be protected in such a way that the keyboard strokes cannot be recorded by (potentially harmful) background app when typing confidential information such as PIN codes.

TEE is a protected part of the OS within the processor HW that can used independently from the architectures. Previously, there were equipment vendor‐dependent TEE solutions but nowadays the TEE is standardized by the GlobalPlatform. Currently, the most popular practical solutions are based on Advanced Reduced instruction set computer Machine concept (ARM.) An example of a commercial TEE solution is Trustonic t‐base which is located to the application processor. The trusted applications of the TEE (trustlet, or trusted applet) can be deployed and managed via a separate TEE–TSM element as long as the user’s device supports TEE.

The TEE is applicable to many practical situations requiring data integrity, privacy and confidentiality. The current mobile communications environment has changed rapidly as a result of smart devices from the beginning of 2000. At the same time, the previously quite closed telecommunications services have been liberated and there is ever growing quantity of third‐party apps. Also, the ports to the public data networks have opened doors for unpredictable security breaches. This has resulted in dangers such as installation of malicious software into the mobile devices that are capable of executing apps. The same protection mechanisms can be used in the mobile environment that have been applied in fixed Internet, but it is obvious that updating of, e.g. virus protection software, is not always able to respond early enough, especially in the case of zero‐vulnerability cases.

The TEE is one of the solutions tackling these challenges. Optimal benefit is achieved via the commonly interoperable, standardized solutions, which means cooperation between the OEMs, MNOs and chip manufacturers. The standardized TEE provides a high level of protection in the MNO’s services to the customers via the service providers, which in turn increases customer satisfaction. The contents providers can also benefit from the standardized TEE because it provides certified protection for products (such as video streaming) as well as maintenance independently from the utilized platforms, which in turn speeds up the entrance to market and unifies the user experience.

As a base for the TEE architecture, the following summarizes the key terminology:

• System on Chip (SoC) refers to the IC, CPU and any peripherals involved with TEE. The CPU in turn may contain apps and a baseband unit, i.e. modem.
• Silicon Provider (SiP) refers to the chip manufacturer. The task of SiP is to manufacture and provide SoC. Examples of SiP are Qualcomm, Intel, Marvell and CGT.
• Trusted Zone (TZ) refers to chip‐set architecture of, e.g., ARM or any other TEE manufacturer.
• Normal World (NWd) refers to the area which contains Rich OS and related applications.
• Secure World (SWd) refers to isolated compartments, e.g., within ARM TrustZone‐enabled SoC.
• Trusted Execution Environment (TEE) refers to the secure microkernel within SWd.
• Rich OS refers to the operating system working within NWd. Examples of Rich OS are Android and Linux.
• Container refers to the secure area within SWd which is similar to the security domain.
• Trustlet is an executable unit, or trustlet applet, within Container which is used for secure operations.

Following the example of these terms specific to the t‐base TEE ecosystem, the architecture contains elements as shown in Figure 6.5.

As can be observed from Figure 6.5, the heart of the TEE architecture of this example is a combination of Trustonic and ARM TrustZone support. ARM provides IP‐based TEE HW TrustZone to the SiP, which in turn has integrated the t‐base within the chip‐set. The task of the OEM is to manufacture the TEE‐capable device and ensure it is added with respective serial number to the t‐base. The task of Back End (BE) is to store device‐specific authentication keys such as K, AUTH and SOC while the Service Enabler (SE) manages the unlocking of the t‐base Container to be utilized by the TSM. The TSM, in turn, provides key management services for the end‐user device, and communicates with the and SP. The task of the MNO is to distribute t‐base enabled devices for the customers while the role of the SP is to develop and make available TEE‐based applications. The SP also authorizes the Container’s (i.e., device‐specific) activation by relying on apps developers. Finally, after this chain of roles, the end‐user is able to consume secure apps that are stored within the secure world of the device.

In order to make TEE work, the SiP partners should cover important parts of the OEM devices while ARM provides the chip architecture and SiP embeds the TEE into the silicon level. When the equipment supports TEE, the task of OEM is to initialize the TEE with a key procedure for the BE to receive a serial number key table for its database. The task of the SE is to create the actual TEE with the end‐user device by creating the SP container within it. The SP can be any party requiring trustful execution of the SP’s apps (trustlets), such as those meant for secure banking services. As soon as the respective Container exists, the TSM provides lifecycle management for it in such a way that Trustonic provides the trustlet APIs.

The TSM works for post‐loaded, secured applets so that the SP delivers secured apps for the TSM, which delivers them further to the device’s secure world Containers via personalized OTA access, and which manages the lifecycle for operations and data to the respective devices. The TSM is thus a hosted service offering an adequate security level for the safe provisioning and execution of the apps in t‐base trustlets.

When the user installs a new app, it triggers the trustlet process as summarized in Figure 6.6, via the TEE OTA lifecycle management of the secured apps.

Following the data flow of Figure 6.6, the initial phase of (a) makes the OEM device binding via Trustonic procedures, and delivers the key and device ID to the BE. Then, in stage (b), the key is delivered in a secured way to the TSM of the SP. The SP uploads a secure app to a typical app store (1). Now, as soon as the end‐user downloads and starts to install the SP’s app to his/her smart device (2), it triggers the delivery of the secured app to the TSM, which further installs the secured app to the TEE Container of the user’s device via OTA (4). As soon as the installation is done, the end‐user is able to start utilizing it.

In addition to the actual secure installation via OTA and utilization of the apps, TEE also provides useful functionalities adding value to the apps. Some of these functionalities include secure user interface and secure end‐point.

This example is related to the ARM‐based solution which represents about 95% penetration of the devices. Trustonic, on the other hand, is one of various TEE facilitators, having been initiated in 2013. At this moment, Trustonic is a joint effort of ARM and Gemalto while the former cooperating parties have been Nokia and Giesecke & Devrient, the latter providing the TEE TSM services (TSM owner). TEE product‐wise, the TEE t‐base 300 is a GlobalPlatform compliant solution. As for the commercial markets, Qualcomm, Samsung LSI and Broadcom have incorporated TEE in some chip‐sets (application processors), and Samsung has released various devices equipped with TEE support. More information about TEE can be found in Ref. [2].

6.3.4 HCE and the Cloud

The basic idea of the cloud services is to distribute the mobile services away from the actual physical device so that the user may rely on the remote entity for executing the software and for storing contents. The term cloud refers to such remote functionalities supported by the network and its connectivity. Ideally, the benefit of the cloud service is the independency from the used device for utilizing any service and for storing data. Furthermore, once the execution of the code residing in the cloud has been initiated, it can be continued with another device, and the locally stored information can be transferred between the devices. In addition, cloud services can be used for a variety of environment, including mobile payment [6].

One of the practical solutions based on the cloud concept is HCE as depicted in Figure 6.7. HCE is especially suitable for small‐scale payments in the format of a mobile wallet which are based on dynamically changing data objects, i.e., tokens, which serve for acknowledging the payment event. In practice, a token may be, e.g., a reference to the Personal Account Number (PAN) which is valid either for a single payment event, for a series of payments or during a certain, limited time period. Please note that the validity of such tokens may be set for several years. Regardless of the validity period, the idea of the token is to protect the original, permanent PAN of the user.

The token‐based payment event requires a method for the digital issuance as well as for application management and an HCE element that resides either in the cloud or within the device. The HCE system takes care of the forming of the token, as well as its storage and integrity checking. The distribution system manages the virtual payment account residing in the cloud as well as the related keys, and offers business logics for the initiation of the virtual card. Application management, in turn, takes care of the secure transport of the information and utilization between each mobile device and HCE system while the SW of HCE client protects the data within the virtual card.

The challenge of the cloud services is that by default they are not based on an HW‐based SE but on an SW which is either a separate application or is embedded into the SW or OS of the device. Thus, the security level of such a solution might be lower compared to, e.g., the SIM‐based SE. Another challenge is related to the dynamic character of the token. If the token is selected on a one‐time basis, for each new purchase the user requires a new token each time. If the user happens to be in an outage area of the mobile services, the new transaction would not be valid unless there is a locally pre‐stored set of new tokens within the device.

In principle, the more tokens stored beforehand in the device increases the risk of potential cyber‐attacks against that specific account. In other words, the sole token does not protect the payment transaction per se because if it is exposed, someone may be able to misuse it. The HCE services are thus critical for the protection against external intentions to capture and modify tokens. It is of utmost importance that HCE identifies correctly the device, end‐user and the service. The virtual card stored into the device, as well as the related cryptographic functions, must be protected in such a way that they cannot be copied or changed physically from the device or via the communication link. HCE is thus especially suitable for small‐scale one‐time payments which do not include large risks even if the payment credentials were copied and misused.

The system architecture of the cloud‐based payment service may be, e.g., as depicted in Figure 6.8. As can be noted, the role of the MNO can be removed completely due to the fact that the SIM card that MNO manages is not necessarily needed in this solution, nor are the TSM elements. The solutions thus simplify the payment service that is based on the SE. In the HCE service, a set of tokens are pre‐loaded from the cloud server into the device for the acceptance of the forthcoming transactions. In the HCE solution, instead, a set of tokens (one or more) can be downloaded from the cloud server into the NFC equipment for the payment transactions. In addition to the principle shown in Figure 6.8, there can also be an SE based on the HW element such as the SIM/UICC or eSE. Commercial‐wise, Android supports HCE as of the version 4.4 (KitKat).

6.3.5 Comparison

Each of the methods presented previously can be applied in their optimal environments. The SIM/UICC and its developed variants, permanently installed eSEs integrated into a microSD provide a good level of protection. Figure 6.9 and Table 6.1 summarize the usability of each solution.

6.4.1 PAN Protection

Tokenization refers to a concept that represents a high value with the help of something with low value, as is the case with casino chips. In wireless payment, tokenization is a functional solution for representing the PAN in such a way that the original PAN is hidden by replacing it with a token. EMVCo has produced the payment tokenization specification for the respective framework.

More specifically, EMVCo allows the replacement of the original PAN with a PAN‐type of identification. In practice, the last four digits of the original PAN are typically maintained in order to ease the identification of the customer, e.g., for merchandize return and loyalty programmes. For the purchase transactions, the POS transfers the tokenized pseudo‐PAN to the issuer. In order to recover the original PAN, the issuer relies on the tokenization system which maps the original and tokenized PANs. Only the trusted tokenization system is capable of mapping the PANs.

It is possible to use tokens with all the Cardholder Verification Methods (CVMs). Nevertheless, tokenization limits the environment in such a way that it can be focused, e.g., on only a single merchant. Also, it is possible to set a maximum expiration time for the tokens. Thanks to this limitation, together with the fact that the PAN cannot be reverse‐engineered, this ensures a good level of security for the transactions, making the Payment Card Industry Data Security Standard (PCI‐DSS) risk on merchants minimal [7]. PCI‐DSS is a proprietary information security standard for organizations that handle branded credit cards from the major card schemes including Visa, MasterCard, American Express, Discover and JCB. Private label cards – those which aren't part of a major card scheme – are not included in the scope of the PCI‐DSS. In addition, the tokenization specifications include risk management measures which can be based on, e.g., account activity trends. Tokens need to have a special Bank Identification Number (BIN) range to ease the identification of the pseudo‐PAN to indicate that it belongs to the contactless cloud payment realm.

6.4.2 HCE and Tokenization

Tokenization can be used basically with any payment method described previously. It is especially useful with HCE. HCE is based on the card data placed in the cloud. Visa and MasterCard have jointly worked on related HCE specifications. HCE offers an alternative approach for the SE‐based procedures that are based on, e.g., the SIM/UICC. It also changes the business environment from the previously MNO‐centric (as the network operator owns the SIM/UICC and its containers) into an MNO‐independent direction. In the former, the processes for the payment solution certificates for devices and SIM/UICC cards as well as applications may be time consuming and limits the role of service providers. Instead, the HCE solution changes the environment towards service provider‐centric as it reduces the number of stakeholders and eases the integration of the services. For that reason, financial institutes are evaluating the feasibility to move the card credentials from SEs into the cloud.

The first Android devices support HCE as of the OS 4.4 (KitKat), making it possible to move business and personal data into the cloud from the mobile device’s SIM/UICC SE. However, the transfer of such sensitive data in an encrypted way for all transactions is not feasible as it would lower the security as well as user experience. HCE thus includes tokenization, together with other techniques such as limited use keys, account replenishment and risk assessment scores, to ensure security by balancing the user experience when transactions are executed.

More detailed information about tokenization can be found in Refs. [7,8] as well as from the EMVCo payment tokenization specification.

6.5.1 Identity Solutions

The mobile equipment is a highly useful base for many services and solutions requiring high protection levels, for both individuals as well as businesses. One example of the new business environment can be see, e.g., via the wider adaptation of the mobile equipment and tablets with cellular connectivity to replace the old POS terminals, and converting them as mobile POS terminals (mPOS). Table 6.2 presents some typical identity‐related solutions as interpreted from Ref. [9].

6.5.2 Multi‐operator Environment

The MNO partnering trends include the concept of planned partnering, which refers to the solution forming local partners as a part of the proposition to the OEM. The practical setup of this concept include MNO alliances formed and marketed to global and regional OEMs, and M2M service providers and MVNOs seeking to expand their service offering to current and new M2M customers. The other trend is called dynamic partnering, which refers to project‐specific partnering. This means that large global enterprises and OEM customers select their preferred MNOs in different regions. As an example, the MNO as the issuer of the SE may retain ownership of the end‐user through contractual agreements with its MNO partners.

The GSMA specification that was released in December 2013 for embedded SIM remote provisioning architecture is one of the feasible industry solutions as it provides a means for deploying full profile download and security domains. The solution may use HTTP OTA as the primary channel, and it allows the support of existing M2M UICC HW while providing SIM card multi‐vendor interoperability.