Re: Alternative roads to Trusted Payment UIs

On 2013-11-06 17:01, Kumar McMillan wrote:
> On Nov 5, 2013, at 9:10 PM, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
>
>> Through my TrustedComputingGrouop membership I just got an entirely
>> different solution the trusted UI/chrome issued created by GlobalPlatform.
>>
>> It's essentially the same system pushed by Intel as IPT (Identity Protection Technology)
>> which among a number things _bypasses_the_operating_system_ by (temporarily) taking
>> over the keyboard and screen.  To make the scheme less susceptible to spoofing user-defined
>> information information is also displayed such as a picture of something personal.
>> http://www.intel.com/content/www/us/en/architecture-and-technology/identity-protection/protected-transation-display.html
>>
>> So it seems that there are three quite distinct approaches on the table:
>> - The "sledge-hammer" approach (pardon me GP and Intel...) outlined above
>> - White-listing mentioned by Manu and Kumar
>> - Yours truly's K2C (Key to Code) scheme for making spoofed data "useless"
>>
> When you talk about a trusted payment UI are you talking solely about preventing phishing (i.e. spoofing a UI to get sensitive info)? To me, that's the only threat that a trusted UI needs to solve. 

Agreed.

> All other threats can be solved in better ways like signature checking. There are also lots of strategies for detecting phished account usage with patterns. Google and others do this to detect compromised passwords. Two factor auth is also a strategy against phishing.

Absolutely!

>
>
>> Given these facts,  I would be pretty cautious making trusted chrome a part of
>> a possible payment standard.  The white-listing concept seems to currently lack
>> a write-up doesn't it?
>
> I wouldn't say white-listing is a strategy to prevent phishing. In the case of Firefox OS' payment window it's only a strategy to restrict access to sensitive device APIs that could be abused.
>
> The Firefox OS strategy against phishing is to never ask the user for sensitive info that can be phished. When users make a payment they are asked to enter a PIN code. If this is phished, it's not very useful because an attacker needs to have both the PIN code and the Persona login to make a fraudulent payment. The Persona login is a long term device login so it would be surprising if a payment page asked the user to re-enter their Persona login. However, this last part is still theoretical because we haven't fully shipped the UX to make this work. For example, Persona login on first run (when unboxing a phone) is a feature that has not fully landed yet. There are also some edge cases not addressed yet where Persona login re-entry is required, such as PIN code resets. In other words, phishing is still possible on Firefox OS currently just as it is possible on Android and iOS and on the web.


I believe I got this, what I don't know (or understand) is how you customize the payment window and how the payment window binds to a payment application in a trustworthy and flexible manner.


>
> A sledge hammer approach where the user could set up a photo to use during payments was once part of the design but was scrapped due to poor usability.

That was IMO a wise decision.

Anders


>
> -Kumar
>
>> Anders
>>
>>
>>

Received on Wednesday, 6 November 2013 16:32:46 UTC