W3C home > Mailing lists > Public > public-webpayments-ig@w3.org > May 2015

Re: 答复: Paper on Summary of ISO12812 by Alan Thiemann

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Thu, 21 May 2015 16:55:05 +0200
Message-ID: <555DF1C9.3090802@gmail.com>
To: "孙倩(雪迪)" <sunqian.sq@alibaba-inc.com>, "'Telford-Reed, Nick'" <Nick.Telford-Reed@worldpay.com>, 'Adrian Hope-Bailie' <adrian@hopebailie.com>
CC: Joerg.Heuer@telekom.de, public-webpayments-ig@w3.org, ajthiemann@gmail.com, "'David_E3@VERIFONE.com'" <David_E3@verifone.com>
On 2015-05-21 16:26, 孙倩(雪迪) wrote:
> HCE is an exciting development for the NFC market because
 > it provides an additional means by which to perform NFC transactions.
 > With HCE, transactions take place using credentials stored in the cloud
 > or on the host processor of the NFC-enabled mobile device rather than a
 > tamper resistant Secure Element, such as an embedded security chip, SIM,
 > or microSD card. HCE just simulates NFC and SE communication protocols
 > and implementation. HCE does not implement the SE, just told an NFC
 > communicate with SE support behind the NFC card reader  in the form of
 > virtual SE for NFC business security. HCE just make the reader to believe
 > there is a SE according to the solutions of either cloud simulation or local
 > software simulation.

Right!

Hi Sunqian,

The remaining problem which makes HCE rather difficult to exploit is the lack
of a standardized facility for provisioning SEs, TEEs, TPMs, etc.

As an example all Windows W8 devices have a TPM but Microsoft never bothered
with a TPM provisioning protocol that could be used outside of Active Directory
which doesn't work particularly well for on-line banking or payments.

The same goes for ARM Ltd's TEE (TrustZone) which according to ARM is available in
most ARM-equipped mobile devices.

Google changed this with U2F since it was designed for *consumers* and the web
from the beginning.  However, U2F is probably not exactly what the banking world
had in mind, at least not the one in the EU.

Kind regards,
Anders

>
> But during the payment, for the sensitive data, just like the fingerprint template and private key  should be stored and executed in separate security hardware on the device or
> physically connected to it, and these sensitive data must not be stored in cloud. For example, Iphone’s SecureEnclave is the safe execution environment for the processing of sensitive information, such as: TouchID fingerprint imaging sensors data need to be passed to the SecureEnclave for actual fingerprint identification process. For ApplePay SecureEnclave is responsible for managing the certification process and make payment transactions can be performed.
>
> I think that service providers need to evaluate and determine the best place to store credentials for their solutions, keeping in mind the trade-off between security risks and convenience.  Each model has its merits depending on the use case. For instance, use cases that rely today upon bar codes could immediately benefit from HCE without raising new security concerns. However transactions currently relying upon tamper resistant secure storage of assets would need more thorough considerations. We’re encouraged by the steps being taken by providers of HCE-based solutions to ensure that their offerings meet consumer and business demands for latency and security.
>
> *发件人:*Telford-Reed, Nick [mailto:Nick.Telford-Reed@worldpay.com]
> *发送时间:*2015年5月21日20:32
> *收件人:*'Adrian Hope-Bailie'
> *抄送:*孙倩(雪迪); Joerg.Heuer@telekom.de; public-webpayments-ig@w3.org; ajthiemann@gmail.com; David_E3@VERIFONE.com
> *主题:*RE: Paper on Summary of ISO12812 by Alan Thiemann
>
> I think it _/can/_ be stored there but it doesn’t _/need/_ to be. The point of HCE is that it allows some (perhaps limited) set of credentials to be held in application space on the device so that a payment application developer can create payment applications without needing a commercial and technical relationship with a third-party that holds the keys/controls for a dedicated hardened secure area.
>
> IMO if we restrict the development of payment solutions to architectures that require a complex ecosystem of security providers as well as the solution provider itself, we bake in a set of complexities that have held back mobile payments for years.
>
> There are other ways to manage the risk with things like limited use (by time, channel, device, amount) tokens so that cost of compromise is reduced be implementations remain straightforward.
>
> Your point is well made that in HCE much of the secret sauce is kept off the device – but there is still sensitive material in user space (or at least, there can be).
>
> Nick
>
> --
>
> Nick Telford-Reed
>
> e: nick.telford-reed@worldpay.com <mailto:nick.telford-reed@worldpay.com> | m: +447799473854 | t: +44 203 664 5069
>
> *From:*Adrian Hope-Bailie [mailto:adrian@hopebailie.com]
> *Sent:* 20 May 2015 15:12
> *To:* Telford-Reed, Nick
> *Cc:* ??(??); Joerg.Heuer@telekom.de <mailto:Joerg.Heuer@telekom.de>; public-webpayments-ig@w3.org <mailto:public-webpayments-ig@w3.org>; ajthiemann@gmail.com <mailto:ajthiemann@gmail.com>; David_E3@VERIFONE.com <mailto:David_E3@VERIFONE.com>
> *Subject:* Re: Paper on Summary of ISO12812 by Alan Thiemann
>
> I think you can accommodate HCE by saying that this kind of data should be stored in the SE or TEE etc IF it is stored on the device?
>
> On 20 May 2015 at 11:28, Telford-Reed, Nick <Nick.Telford-Reed@worldpay.com <mailto:Nick.Telford-Reed@worldpay.com>> wrote:
>
> That pretty much at a stroke knocks out Host Card Emulation, which is Google's approach to mobile payments, so I think I would be reluctant to make that step.
>
>
>
> --
> Nick Telford-Reed
> e: nick.telford-reed@worldpay.com <mailto:nick.telford-reed@worldpay.com> | m: +447799473854 <tel:%2B447799473854> | t: +44 203 664 5069 <tel:%2B44%20203%20664%205069>
>
>> -----Original Message-----
>> From:孙倩(雪迪) [mailto:sunqian.sq@alibaba-inc.com <mailto:sunqian.sq@alibaba-inc.com>]
>
>> Sent: 19 May 2015 04:10
>> To:Joerg.Heuer@telekom.de <mailto:Joerg.Heuer@telekom.de>; public-webpayments-ig@w3.org <mailto:public-webpayments-ig@w3.org>
>> Cc:ajthiemann@gmail.com <mailto:ajthiemann@gmail.com>; David_E3@VERIFONE.com <mailto:David_E3@VERIFONE.com>
>> Subject:答复: Paper on Summary of ISO12812 by Alan Thiemann
>>
>> Hi all,
>> So, can we change the description to "Important data, such as the fingerprint
>> template and private key, and sensitive code should be stored and executed
>> in a security area (e.g. TEE, SE etc.) "?
>>
>>
>>
>>
>> -----邮件原件-----
>>发件人: Joerg.Heuer@telekom.de <mailto:Joerg.Heuer@telekom.de> [mailto:Joerg.Heuer@telekom.de <mailto:Joerg.Heuer@telekom.de>]
>>发时间: 2015年5月18日22:58
>>收件人: 孙倩(雪迪); public-webpayments-ig@w3.org <mailto:public-webpayments-ig@w3.org>
>>抄送: ajthiemann@gmail.com <mailto:ajthiemann@gmail.com>; David_E3@VERIFONE.com <mailto:David_E3@VERIFONE.com>
>>主题: RE: Paper on Summary of ISO12812 by Alan Thiemann
>>
>> Hello,
>>
>> While we definitely support the importance of security hardware for the use
>> of privacy-risky technology, I suppose to not explicitly ask for a technology,
>> but rather talk about its capabilities. For several uses an SE might still be okay,
>> though TEE might be desirable for the future. In fact, it might take a long time
>> for TEEs to proliferate until then, we should allow existing solutions to kick in
>> as soon as possible. I'd probably try to even think about how TPM/ MTM
>> could be helpful too.
>>
>> In this case, I'd propose to just refer to a "technology to store and validate
>> fingerprint templates in separate security hardware on the device or
>> physically connected to it".
>>
>> Cheers,
>>       Jörg
>>
>> -----Original Message-----
>> From:孙倩(雪迪) [mailto:sunqian.sq@alibaba-inc.com <mailto:sunqian.sq@alibaba-inc.com>]
>> Sent: Montag, 18. Mai 2015 09:10
>> To: 'David Ezell';public-webpayments-ig@w3.org <mailto:public-webpayments-ig@w3.org>
>> Cc: 'Alan J. Thiemann'
>> Subject:答复: Paper on Summary of ISO12812 by Alan Thiemann
>>
>> Thanks for Alan's summary.
>>
>> For the" Part 2: Security and data protection for mobile financial
>> services",I have some consideration that in order to protect financial
>> privacy useful, the mobile device technology should combines Secure
>> Elements
>> (SE) and a Trusted Execution Environment (TEE) to protect payment
>> credentials. Beacause the SE only has Limited processing and storage
>> capacity, but TEE can offer safe execution of authorized security software,
>> known as 'trusted applications', enables it to provide end-to-end security by
>> enforcing protection, confidentiality, integrity and data access rights.
>>
>> And when we design the payment architecure and use cases, we should also
>> pay attention to that some payment application should be served as a
>> TA(trusted
>> appliation) to run in the TEE for security.
>>
>> For example in the Use case  "6.2.3.1 Non-essential Use Cases -Biometric",
>> we have already emphasized as following:
>> An individual's privacy should be protected when performing any sort of
>> biometric authentication.
>> Important data, such as the fingerprint template and private key, and
>> sensitive code should be stored and executed in a Trusted Execution
>> Environment (TEE).
>>
>> -----邮件原件-----
>>发件人: David Ezell [mailto:David_E3@VERIFONE.com <mailto:David_E3@VERIFONE.com>]
>>发送时间: 2015年5月18日0:56
>>收件人: public-webpayments-ig@w3.org <mailto:public-webpayments-ig@w3.org>
>>抄送: Alan J. Thiemann (ajthiemann@gmail.com <mailto:ajthiemann@gmail.com>)
>>主题: Paper on Summary of ISO12812 by Alan Thiemann
>>
>> Dear Web Payments group:
>>
>> My colleague Alan Thiemann[1] has written a summary of ISO 12812[2].  This
>> work is Alan's opinion of the work - not official.  But it is a very good
>> introduction to the work and the expected trajectory at ISO.
>>
>> I would request that everyone in our group give this paper consideration - it
>> won't take long, and will help inform any needed discussion.
>>
>> Best regards,
>> David
>>
>> [1] Alan is on the Board of Advisors for Conexxus (NACS technology) and
>> does work for NACS.  He serves as chair of the X9 Mirror Group handling ISO
>> 12812 work in the US.
>> [2]
>>https://lists.w3.org/Archives/Member/w3c-archive/2015May/att-
>> 0254/Executive_
>> Summary_of_ISO_12812_05012015.pdf
>> ________________________________
>> This electronic message, including attachments, is intended only for the use
>> of the individual or company named above or to which it is addressed. The
>> information contained in this message shall be considered confidential and
>> proprietary, and may include confidential work product. If you are not the
>> intended recipient, please be aware that any unauthorized use,
>> dissemination, distribution or copying of this message is strictly prohibited. If
>> you have received this email in error, please notify the sender by replying to
>> this message and deleting this email immediately.
>>
>>
>>
>
> This e-mail and any attachments are confidential, intended only for the addressee and may be privileged. If you have received this e-mail in error, please notify the sender immediately and delete it. Any content that does not relate to the business of Worldpay is personal to the sender and not authorised or endorsed by Worldpay. Worldpay does not accept responsibility for viruses or any loss or damage arising from transmission or access.
>
> Worldpay (UK) Limited (Company No: 07316500/ Financial Conduct Authority No: 530923), Worldpay Limited (Company No:03424752 / Financial Conduct Authority No: 504504), Worldpay AP Limited (Company No: 05593466 / Financial Conduct Authority No: 502597). Registered Office: The Walbrook Building, 25 Walbrook, London EC4N 8AF and authorised by the Financial Conduct Authority under the Payment Service Regulations 2009 for the provision of payment services. Worldpay (UK) Limited is authorised and regulated by the Financial Conduct Authority for consumer credit activities. Worldpay B.V. (WPBV) has its registered office in Amsterdam, the Netherlands (Handelsregister KvK no. 60494344). WPBV holds a licence from and is included in the register kept by De Nederlandsche Bank, which registration can be consulted through www.dnb.nl <http://www.dnb.nl>. Worldpay, the logo and any associated brand names are trade marks of the Worldpay group.
>
>
>
> This e-mail and any attachments are confidential, intended only for the addressee and may be privileged. If you have received this e-mail in error, please notify the sender immediately and delete it. Any content that does not relate to the business of Worldpay is personal to the sender and not authorised or endorsed by Worldpay. Worldpay does not accept responsibility for viruses or any loss or damage arising from transmission or access.
>
>
>
> Worldpay (UK) Limited (Company No: 07316500/ Financial Conduct Authority No: 530923), Worldpay Limited (Company No:03424752 / Financial Conduct Authority No: 504504), Worldpay AP Limited (Company No: 05593466 / Financial Conduct Authority No: 502597). Registered Office: The Walbrook Building, 25 Walbrook, London EC4N 8AF and authorised by the Financial Conduct Authority under the Payment Service Regulations 2009 for the provision of payment services. Worldpay (UK) Limited is authorised and regulated by the Financial Conduct Authority for consumer credit activities. Worldpay B.V. (WPBV) has its registered office in Amsterdam, the Netherlands (Handelsregister KvK no. 60494344). WPBV holds a licence from and is included in the register kept by De Nederlandsche Bank, which registration can be consulted throughwww.dnb.nl  <http://www.dnb.nl>. Worldpay, the logo and any associated brand names are trade marks of the Worldpay group.
>
>
>
Received on Thursday, 21 May 2015 14:55:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:08:35 UTC