InvestorsHub Logo
icon url

wavedreamer

11/03/14 8:56 PM

#239471 RE: barge #239468

barge,

You nailed it:)
icon url

wavedreamer

11/04/14 9:39 AM

#239485 RE: barge #239468

barge,

further to your points and from the article on Bell ID's Mobile Phone solution on Android. If one thinks about what the TPM can bring as a security tool on the device (attestation/TNC/Machine & user ID/verifying the TEE code and applications are correct etc.) then you start to see why Bell ID wants to hook up with Wave in not only harnessing the existing PC space and all those TPM's for card not present transactions but to secure the HCE on the mobile phones:)

"4. Mitigation techniques for HCE-related security risks

4.1 Locations to store sensitive data

The HCE service runs within the Android OS. An SP may require a more secure location to store credentials, generate and process the communication and perform cryptography.
We identify four basic location options, which have a different balance between risk mitigation and associated costs. These options are illustrated in Figure 2.

4.1.1 Host

This is the basic approach, i.e. storing and processing occurs within the application running on Android OS on the host. Apart from Android security mechanisms such as sandboxing, no additional security is added in terms of location for storage and processing.


4.1.2 Cloud-based SE

In this approach, storage and processing of the sensitive data is done in a server somewhere in the “cloud”, to which the NFC device can make a connection. This connection is therefore essential to activate the NFC service. Of course, an internet connection might not always be available and the speed of a mobile connection might cause latency issues. A mobile payment transaction must be completed within narrow time limits, for example 400 ms for MasterCard PayPass M/Chip or 170 ms for PayPass magstripe7.

A real-time calculation on a Cloud-based SE cannot guarantee this kind of transaction speed. Therefore, Cloud-based SE solutions typically include a tokenization mechanism to allow transactions up to a certain number and value. Google Wallet for instance deploys a form of “tokenization”. Section 4.2.3 explains the concept of tokenization.

A fundamental issue with any Cloud-based SE is how to enable the handset to securely identify itself to the cloud. If credentials to the Cloud-based SE are stored inside the HCE service then this severely limits the extra security which can be supplied by the Cloud-based SE solution. This problem could be solved by requiring user interaction for accessing the cloud, which would in turn negatively impact the user experience. Another solution could be to use the hardware SE to authenticate towards the Cloud-based SE.


4.1.3 TEE

The Trusted Execution Environment is a separate execution environment that runs alongside the OS and provides security services to that environment.

As illustrated in Figure 3, the TEE isolates access to its hardware and software security resources from the OS and its applications. The TEE runs its own separate OS and therefore is not compromised when the main OS is rooted. In that way, the TEE can be used to provide a higher level of security than the basic approach described in Section 4.1.1. It does not reach the security level provided by an SE because it does not have the SE’s tamper-resistance.
Note that TEE standardization is not yet finalized.


4.1.4 UICC or embedded SE

This option offers the most advanced form of security on the Android device. It is questionable whether this option in combination with HCE really makes sense to an SP, because it seems to provide no additional advantages over traditional, SE-based NFC. It adds complexity in the routing through the Android OS where a direct link to the SE is available.

4.2.1 User and hardware verification

Payment transactions can be made more secure by verification of the user and/or the hardware that is used in the transaction. Typical verification mechanisms to enhance security include the verification of:

• What the user knows (Username/password combinations, PIN, etc.)

• What the user has. For example Device ID, smartcard reader, sticker, etc.
• How the user behaves. For instance if a payment is done in geographically distant places very quickly after one another, such payment transactions could be denied.
• Biometrics. The use of biometrics for user authentication receives increasing attention, for instance by use of fingerprint-scans, voice- and facial-recognition, iris-scans, etc.

4.2.4 Android OS checks

An Android application is able to verify system settings and can detect whether a device is rooted. Given the risks associated with rooting of a device we would recommend an HCE service to check for this kind of settings (developer options and root access) and take appropriate action as soon as those settings are detected.

http://www.ul-ts.com/downloads/whitepapers/finish/6-whitepapers/289-hce-security-implications