Take a look at the device health claim diagram that NSTIC is developing into their Trust Frame Work section to get an idea of what is coming and what part attestation services will provide to relying parties like banks/enterprises etc.
And Wave provides a product technology (WEM) as a reporting agent that can be used in that Trust Frame Work. Or as Alea calls it the Trust Matrix.
"Use Case Description
Establish an integrity (aka health) claim for a device that, together with other security measures, is good evidence of the integrity of the information exchanged with the user. Today many relying parties do ensure that users can only access their services with devices that are known to be in the possession of the user. This case extends that to allow the relying party to specifically request an integrity claim from the user's device.
Integrity has two meanings in computer security. The first relates to the device not having been changed in any way since it was created. The second relates to the device reliably behaving in an expected manner. In a modern operating system, with vulnerabilities patched every month, the former definition is not practical and so the later definition is the one that applies in this use case.
This use case distinguishes between two actors which are typically conflated in other use cases. The user is a carbon-based life form that has no innate capability to interface to any digital network. The user device is a silicon-based life form that is extremely good at interfacing to the digital networks at high speed, but communicates only a few bits per second to the user with a user experience that is often sub-optimal. For high value resources on the network, the resource owner would like to assure that the data once available on the user device is not leaked to unauthorized users. This is not possible if the resource owner (aka the relying party) does not trust the user's device's integrity with respect to confidential material placed on the device. There are other mechanisms to control data leakage, like remote device wipe, which are to be considered in other use cases.
CUT
"Process Flow
-The user establishes an account with one or more IdPs. -The user’s device is registered with a device attribute provider. -The user accesses a web site which requires identity attributes of some sort to continue to process the user request. That web site then becomes a relying party. -The RP uses a standard protocol and taxonomy to request the information needed from the user. -This request for information is intercepted by an agent for the user that can: Determine if the requested information is available, Determine if the user has already authorized release of the requested information to this RP, Display any remaining choices to the user to acquire more attributes or release those already available, Compose user and device claims in a way the RP can evaluate the data, Send the composed claims to the RP who has sole responsibility to determine if sufficient identity and attribute information has been proved to provide the requested access. Repeat these steps until the RP is satisfied or one side gives up and abandons the effort.
The above figure shows the user agent as a part of the user device. Other implementations are certainly possible. It is responsible for collecting, storing and releasing a collection of claims to the relying party based on informed user consent. The Secure Token Service / Device Attribute Provider is called a remote attestation service in some environments. It accepts the information created by the device at boot time in a Trusted Platform Module (TPM) to compare with known good configuration information to attest to the integrity (health) of the device by means of a device attribute claim.
Cloud Platform Audit and Asset Management using Hardware-based Identities at http://docs.oasis-open.org/id-cloud/IDCloud-usecases/v1.0/cn01/IDCloud-usecases-v1.0-cn01.html#_Toc324801965. This oasis-developed use case describes the companion problem of establishing trust in a cloud provider using a virtual machine environment. The use is very detailed and provides two relevant comparisons to the present use case. First the devices now in development for users often are enabled on virtual machine technology and so can help with the implementation of device integrity of the user device. Second providers of identity and attribute data could directly use the oasis use case to provide proof of their integrity to both the user and to the relying party.
Hi Wavedreamer---Bell ID concedes it needs hardware security on the device.
You write: "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?"
This recent Aug 2014 Bell ID Blog article seems to concede the necessity of hardware security on the client side, where security is critical. This Bell ID piece came out about the time of the Wave/Bell PR. And I might also add that the Bell ID piece also, almost grudgingly, concedes that Trustzone mitigates risk over simply using HCE.
"Mobile payments user experience Issuers should therefore find a balance between security, acceptable risk and user friendliness that works for them and their customers. For issuers that still consider HCE as ‘too insecure’, there may ultimately be a role for what Bell ID has called the ‘hybrid solution’, combining the benefits of the cloud with a physical SE on the device. This is a route to market which we also supported, with an implementation for a large Canadian issuer last year, but the current trend is strongly for ‘pure’ cloud solutions based on HCE."
"Security is important however and to mitigate the risk caused by the absence of hardware security there are a number of ways in which additional security layers can be added to HCE-based mobile payments such as white box cryptography, obfuscation of programming code (security through obscurity), use of a TrustZone and further securing the communication channels between the device and the server such as (layered) encryption, mutual authentication and use of dual channels."
Robert Wessels- Technical Sales Consultant 20 August 2014 mobile payments security
Since Google announced support for host card emulation (HCE) in Android KitKat 4.4 last year, the industry has been divided. Many recognize the value and opportunity that this brings to banks, mobile network operators (MNOs) and service providers for the deployment of mobile services – like payments, transit and loyalty – while others have sought to focus on security concerns that apparently limit the technology’s potential.
The balance of risk & reward
While some may consider the use of HCE less secure as there is no physical secure element (SE) involved, it is really a matter of perspective. Instead of storing the card data in the SE, ‘tokens’ are downloaded to the device and used to complete the transaction at the point of sale (POS). Any breach of security would expose only one or a limited amount of tokens (typically associated with a low transaction value), not the account itself. The limited gain available to hackers in return for the considerable investment of effort and time is more likely to make them put their focus on more attractive targets.
Mobile payment tokens Many issuers and payment schemes therefore see this as an acceptable balance of risk and reward. With the value of the token being so low, it is questionable whether the highest level of security is required. As a comparison, your house is also less secure than a bank vault; the same level of protection is not required due to the value of the contents. Layered security options for HCE
Security is important however and to mitigate the risk caused by the absence of hardware security there are a number of ways in which additional security layers can be added to HCE-based mobile payments such as white box cryptography, obfuscation of programming code (security through obscurity), use of a TrustZone and further securing the communication channels between the device and the server such as (layered) encryption, mutual authentication and use of dual channels.
Overall, the benefits that HCE can bring – such as the simplification of the business model, increased processing power and speed, greater storage capacity and further control over projects – are many and wide ranging. Some observers may consider that the strongest security concerns have come from those with the biggest vested interest in maintaining the SIM as an essential component. Many of these concerned parties followed the Google announcement last October by asserting that the card schemes would never certify such solutions. This fear proved groundless with the subsequent statements from Visa and MasterCard in February, detailing their plans to support cloud payments.
Security versus usability
I am not arguing that security is not needed or important, but simply that it should be balanced and proportionate. Focusing too much on security limits functionality, which will in turn limit consumer uptake. In general, the more security measures there are implemented, the less user friendly it becomes. An issuer should consider that something as simple as requiring an additional Cardholder Verification Method (CVM) such as a PIN for each contactless payment transaction could be a usability nightmare. This could mean that a user needs to enter a PIN to open the phone, enter a PIN/Passcode to open their Banking/Payment App, enter a PIN to allow the transaction and if the POS happens to be an old one, they may be asked to type a PIN on the POS. Far from the ‘tap and go’ experience the user is expecting and this is not even considering the fact that all these PIN codes may be different values!
Mobile payments user experience Issuers should therefore find a balance between security, acceptable risk and user friendliness that works for them and their customers. For issuers that still consider HCE as ‘too insecure’, there may ultimately be a role for what Bell ID has called the ‘hybrid solution’, combining the benefits of the cloud with a physical SE on the device. This is a route to market which we also supported, with an implementation for a large Canadian issuer last year, but the current trend is strongly for ‘pure’ cloud solutions based on HCE.
Overall, many banks have already recognized that the opportunity that HCE offers more than outweighs the risks that it presents, especially seeing as so many of the banks are already happy with the limited risk associated with contactless payments. This debate is certainly one to watch over the coming months as we see more service providers make their moves.
Learn more about HCE in this short explanatory video, read this article about why Australia is a perfect market for HCE mobile payments here or check out this infographic on market readiness for HCE mobile payments.
News 
Market Data 
Discover 
