Re: The "korean bank" use-case

Ron,

Regarding the provisioning the general answer from the today entirely
US-centric platform vendors is that "there is no business case".
This is actually quite wrong, I'm working with real bank and government
customers who indeed ask for this feature all the time!

If eToken can be provisioned on-line or not is hard to say since the middleware
is secret which is yet another reason why progress is zero.

> Nowadays it is possible to prototype hardware almost as easily as software.

Yes, indeed.

> Designing a simple spec and building, say, an arduino-based reference
> implementation of that spec is something that could conceivably be done by
> this WG.

I doubt that this WG has the motivation and competence to do such a thing.
If there are people out there who really have such interests, they must
be pretty shy because I'm haven't noticed them :-)

> Having a spec and a reference implementation might be enough for
> some scrappy startup to decide to turn that spec and reference implementation
> into a business.

The #1 issue is getting the design supported by at least one major
platform/browser vendor.  Then existing and new vendors could hook
into that with moderate costs.

Anders
Open Security Hardware Rocks!
http://webpki.org/papers/keygen2/sks-api-arch.pdf


On 2011-11-27 19:44, Ron Garret wrote:
> 
> On Nov 27, 2011, at 9:52 AM, Anders Rundgren wrote:
> 
>> On 2011-11-27 17:31, Ron Garret wrote:
>> <snip>
>>
>>>> I.e. my quest for a simpler "web token" is a more realistic take on this topic in spite of
>>>> the fact that you need new hardware.
>>>
>>> Why do you think you need new hardware?  There are existing hardware solutions that are simpler than full-blown smart cards:
>>>
>>> https://www.swekey.com/
>>> http://www.safenet-inc.com/products/data-protection/two-factor-authentication/certificate-based-pki-usb-authenticators/
>>> http://www.cryptomate.com/
>>
>> These are good "solutions" but are unsuitable as foundations for standards.
> 
> That depends on what you mean by being a foundation for a standard.  But I don't want to quibble over terminology, I'm just pointing these things out so we can make sure we're all on the same page about what is the current state of the art.
> 
>> If we take the eToken for example, it has existed for a decade but it cannot
>> be provisioned from a browser.
> 
> Why not?  Is there something inherent in the design of the eToken that makes this fundamentally impossible, or is this merely a missing feature in current browsers?  And if it's the latter, isn't that exactly (part of) the problem we're supposed to be here to solve?
> 
>> A system that is supposed to be browser-friendly must IMHO support browser provisioning.
> 
> Swekey can be provisioned within a browser.  I'm not advocating swekey; I think it has other problems.  I'm just pointing to it as an existence proof that provisioning at least one kind of secure token within a browser is currently possible.
> 
>> I believe that requires hardware that is designed for this use-case.
>> Progress is zero in this space.  Only dedicated stuff like the Google
>> Wallet seems to work.  Maybe the fact that Google intends to make money
>> on the Wallet is the differentiating factor :-)
> 
> Just because progress is zero doesn't mean it has to remain zero.  If "progress has been zero" necessarily entailed "progress will continue to be zero" nothing new would ever get done.
> 
> Nowadays it is possible to prototype hardware almost as easily as software.  Designing a simple spec and building, say, an arduino-based reference implementation of that spec is something that could conceivably be done by this WG.  Having a spec and a reference implementation might be enough for some scrappy startup to decide to turn that spec and reference implementation into a business.
> 
> Once again, I'm not necessarily advocating this course of action.  I'm just saying it should not be ruled out a priori.
> 
> rg
> 
>

Received on Sunday, 27 November 2011 19:56:38 UTC