Re: A somewhat lame Web Crypto PIN provisioning solution

On 2013-04-02 21:40, Ryan Sleevi wrote:
> I am happy (and would prefer) for now to leave that in the hands of
> applications and their policies as to whether they require user
> interaction for key operations.
> 
> This is something we can always revisit in a future version - but we
> need to finish the current version first. I also have a lot of
> hesitation with exposing more controls for applications to force
> interaction - as shown by things like window.alert, it's fairly easy
> to abuse. If anything, ISTM that "prompt to use this key" is something
> the user themselves should set - but that would also require
> interacting on key generation, which should be something we should
> strive to avoid.
> 
> I think the best thing you could do at this point would be to actually
> put together a use case that demonstrates how none of the available
> techniques are suitable, and to show how the security assumptions
> being made actually make sense and can be treated as actionable by the
> user.

Dear Ryan,
I would put this slightly different.  Although it seems to piss-off a lot of
people the fact is that banks _practically_without_exceptions_, replace the
"PKI-client" for web-applications as well as for "Apps" since this side of the
system when using on-line-distributed "soft tokens" doesn't support the banks'
take on PIN-protection.

To get away from this obvious "impedance mismatch", I think the Web Crypto WG
should create an Application Note or so telling how _they_ feel that
PIN-protection should/could be facilitated through the Web Crypto API.

I'm currently designing an entirely proprietary one-of-a-kind solution for
a major central-European bank so this is definitely not something I say just
to be obnoxious; I'm a rather nice guy actually :-)

Cheers
Anders

> 
> On Tue, Apr 2, 2013 at 12:32 PM, Anders Rundgren
> <anders.rundgren@telia.com> wrote:
>> On 2013-04-02 20:48, Ryan Sleevi wrote:
>>> As I'm sure you are no doubt aware, for the same reasons that you're
>>> proposing that the browser chrome implement a PIN dialog because of a
>>> 'lack of trust' in web applications, the vast number of cryptographic
>>> APIs do not provide access to pin dialog to applications themselves.
>>
>> The sole idea was adding a PIN code to a key and have the platform
>> (not the application), require the user to type in a PIN when the
>> key is subject to a private-key operation.  The latter is equivalent
>> to how existing APIs deals with PIN-protected tokens.
>>
>> Anders
>>
>>>
>>> As such, based on my experience with a number of these APIs and their
>>> considerations for how/if/when UI is shown, I do not believe your
>>> proposal is implementable at all given current technologies, APIs, and
>>> trends. Fundamentally changing cryptographic APIs may make it
>>> possible, but that's far out of scope for our deliverables.
>>>
>>> I'm not sure I see the connection between "arbitrary signing" and "pin
>>> dialog" though. Are you simply trying to accomplish a forcing function
>>> for user interaction when a key is used by an origin? If so, why - the
>>> origin created the key themselves, they should have full control.
>>>
>>> If an origin does not trust itself (for example, it expects to host
>>> both 'sensitive' and 'hostile' code on the same origin), then it
>>> should use the same technique that sites have been deploying for the
>>> past decade - separating security zones on the basis of origins.
>>> Google, for example, has done this quite successfully with
>>> accounts.google.com versus the rest of its domains, as have a number
>>> of other large sites. This is not limited to the Web Crypto API - this
>>> is a security approach fundamental to the web.
>>>
>>> On Tue, Apr 2, 2013 at 7:36 AM, Anders Rundgren
>>> <anders.rundgren@telia.com> wrote:
>>>> On 2013-04-02 16:13, Mountie Lee wrote:
>>>>> we have to be careful creating any new UI and related specifications.
>>>>>
>>>>> it has serious and many issues
>>>>> - languages
>>>>> - encodings
>>>>> - web accessibility for disabilities
>>>>> - security policies (control of password or account lockout policy)
>>>>> - availabilities for CSS style
>>>>>
>>>>> I can not say yes for your approach without above considerations.
>>>>
>>>> In my opinion the PIN dialog would follow other alert dialogs in the
>>>> browser with respect to language (locale) and accessibility.
>>>>
>>>> The PIN dialog would not have links to CSS because it comes from
>>>> the platform when a key is subject to a private/secret key-operation.
>>>>
>>>> The PIN policy is (in the proposal...) limited to x number of retries.
>>>> If you screw-up your only option would be getting a new key.
>>>>
>>>> PIN encoding would follow the rest of Web Crypto, I guess.
>>>>
>>>>
>>>> The advantage with this scheme compared to server-based PINs is
>>>> the issuer doesn't have to store or validate PINs.
>>>>
>>>> An option could be a local PIN input based on a server-based
>>>> policy.  This is an intrinsic part of my SKS/KeyGen2 scheme
>>>> and I think it works pretty nice.
>>>>
>>>> Regards,
>>>> Anders
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Apr 2, 2013 at 8:10 PM, Anders Rundgren <anders.rundgren@telia.com <mailto:anders.rundgren@telia.com>> wrote:
>>>>>
>>>>>     Since an issuer of a key has (if I didn't got it all wrong...) full "usage" access to a key it has issued including signing whatever it wants there are obviously some trust isolation limits of the Web Crypto API.  Note: I don't see that as a big problem.
>>>>>
>>>>>     Anyway, in such a context it wouldn't be completely wrong adding something like a "setPIN (value, retries)" method to a key which for subsequent uses of the key would require the user providing a matching PIN.
>>>>>
>>>>>     The policy of the PIN would be defined in a traditional web-process.
>>>>>
>>>>>     Anders
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Mountie Lee
>>>>>
>>>>> PayGate
>>>>> CTO, CISSP
>>>>> Tel : +82 2 2140 2700
>>>>> E-Mail : mountie@paygate.net <mailto:mountie@paygate.net>
>>>>>
>>>>> =======================================
>>>>> PayGate Inc.
>>>>> THE STANDARD FOR ONLINE PAYMENT
>>>>> for Korea, Japan, China, and the World
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
> 
>

Received on Wednesday, 3 April 2013 03:57:09 UTC