Replies to post #239437 on Wave Systems Corp. (fka WAVXQ)

[aleajactaest]

"Firstly, Apple’s fully formed mobile payments solution, called Apple Pay, effectively cuts telcos out of the mobile payments business in the Apple ecosystem." - barge

You omitted the first lines of my quote and therefore perhaps didn't notice that as an OS vendor, Apple is part of the obstruction to Wave's progress, along with the carriers! I agree that the OS vendors are pushing the carriers back.

"Third, the last CEO made it clear that it has been hard-going to persuade OS vendors and carriers to grant enterprise access to the trusted mobile market. And without the possibility of trust in all devices, what is the point in deploying an enterprise trust network? This admission by SS seemed to confirm a theory I had proposed that the shape of the mobile market was a serious obstruction and that the reason for the obstruction was all about who would control the cash flow. Will the US government loosen this bottle-neck? It may do, but I am not sure it will do so in a way that protects end-user interests or serves Wave's purposes."

[wavedreamer]

barge,

"Also you might want to take some time to review the Bell ID (which Wave has partnered with) and their technology of Host card emulation, which very neatly bypasses the telcos....completely."

I found this Blog to be very informative on the SE/TEE/HCE and the need for making sure that the device has not been rooted etc.

We know that WEM was designed to be a reporting agent on the device to allow remote attestation on the devices health by utilizing the TPM.

Now that Samsung KNOX has a fTPM on board thanks to Greenhills Software and their secure trusted type 1 hypervisor, Wave can port their products to the Android eco system.

We also know Infineon has a hardware TPM 2.0 5mm x 5mm chip available for phones and small devices and it is in for FIPS 140-2 certification.

I believe the chip will be rated at a higher trust assurance level than the fTPM but the fTPM can be delivered over the air and upgrade millions of devices already in the field that have TrustZone on board. The TPM chip needs to be soldered to the phones board during manufacturing.

The TPM will ensure that all software on the device (OS/TEE/Applications) are certified and measured. The attestation service or health claim of the device (WEM) will ensure via reporting to an attestation server that the phone has not been rooted or the apps modified.

Just takes time:) In the mean time go VSC:)

"How Software Based Card Emulation (HCE) Guarantees NFC Security?

By the introduction of the HCE, no secure element (SE) is needed to emulate a card. As a result, there is no storage to keep the sensitive information of the app emulating the card such as balance, CVV2, PINs, etc.

I just want to know how android fixes this issue? Where the sensitive information of apps should be stored? Does Google Wallet uses this technology? if yes, how the sensitive information are kept secure?

Update 1: Some links on the web refer to the Cloud-Based SE (Cloud SE) while using HCE, but I cannot understand what EXACTLY this Cloud SE do. Any links, documents or further materials on this topic?

Key feature brought by HCE is that, when NFC device is in Card Emulation Mode (CEM), all data coming from NFC controller are routed towards device's CPU (read Android OS) by default. This was not the case before - when default routing in CEM had been towards secure element (SE). Storing sensitive data in OS memory raises severe security issues - the ones you asked - in the case when device is "rooted". There are two ways to mitigate those security risks:

A) Provide more secure location for sensitive data

This "more secure location" could be Trusted Execution Environment (TEE) - Special part of CPU that runs its own separate OS and therefore is not compromised when the main OS is rooted. On the security scale, TEE provides more security then OS and "SE in the cloud", but less than SE. If TEE is not enough (which is the case for services such as open loop payments, authentication services - ID cards, passports) nobody forbids you to use SE on the phone that provides HCE service. In that case, default routing to CPU (Android OS HCE service) can be prevented by using routing tables (data intended for application with specific AID is routed towards SE).

B) Implement security mechanism to make existing location more secure

If you don't have TEE and can't use SE, you can make things more secure by using techniques such as: user verification (something "that user knows" like PIN, or even better if possible "something that user is" - biometrics), transaction constraints (low value transactions, limited number of transactions in one time-frame, etc), tokenization, doing Android OS checks prior transaction (i.e. does user have root priviledges), etc.

The best is to combine A and B.

What you need to understand is that HCE is not intended for high security services. Look on HCE as more-simple-but-less-secure solution, intended to accelerate adoption of NFC services. It has great added value for SPs that can accept a reduced level of security in exchange for an improvement of other factors such as time to market, development costs and the need to cooperate with other parties.

You can read more about this in document written by Thom Janssen & Mark Zandstra, people from UL-TS (former Collis), named "HCE security implications". You can download it from here: http://www.ul-ts.com/downloads/whitepapers/finish/6-whitepapers/289-hce-security-implications.

http://stackoverflow.com/questions/23321217/how-software-based-card-emulation-hce-guarantees-nfc-security/23443091#23443091