Re: The "korean bank" use-case

On 2011-11-27 16:54, Channy Yun wrote:
> Dear all,
> 
> Avoiding confusing ... please refer to
> http://www.w3.org/community/webcryptoapi/2011/09/15/why-web-crypto-api/
> Korean's use-cases and web cryptography.

Hi Channy,
I definitely do not want to confuse, only try to see if there is
any agreement to be found :-)

http://html5.creation.net/webcrypto-api

AFAICT, this is essentially an improved version of Mozilla's current
JS crypto.  That's fine but IMO it doesn't support security HW
in a way that makes sense to a bank since there is no way you can
assure that keys are stored in HW or SW.

If we follow the smart card industry we get schemes that are about
100 times as complex as Mozilla's generateCRMFObject().  I don't
think that is realistic which is the reason why have designed a
system that is "only" 25 times as complex and also utilizes
the network much better than for example GlobalPlatform.

However, as fully proven by Google's wallet and Microsoft's
Win8/TPM stuff, none of the big vendors are prepared to standardize
anything of this kind at this stage.  In fact, these solutions
are currently *secret*.

So I don't think the "Korean bank" case will move one mm in W3C
because of this.  However, that doesn't mean that you should
give up; you may rather come up with another plan.  One option
that you could consider is working with Mozilla, Me and
Korean USB-token and Phone vendors.  Funding remains a major
obstacle for me and I guess 99% of all other people who do not
have the job description "standardizer" :-(

I'm actively looking for government money since projects like
these by mainly are non-commercial.

Regards,
Anders
http://webpki.org/auth-token-4-the-cloud.html

> 
> There has been a guideline of security grade for internet banking in Korea
> by transaction of amount of money.
> 
> Grade I: USD 420,000 per day = *Personal Certificate*+ Secure Code(with SMS
> auth) + One-time password(device)
> Grade II: USD 210,000 per day = *Personal Certificate* + Secure Code (with
> SMS auth)
> Grade III: USD 42,000 per day = *Personal Certificate* + Secure Code
> 
> Actually, there is no HSM/Smartcard use cases in Korea. I don't know why
> smart card is Korean's use-cases.
> I guess some of vendors in Korea wrote Mozilla's DOMCrypt use-case page and
> in fact considered by government agency.
> This is why personal certificate is very insecure for hacking because the
> key store is located in c:\Program Files\NPKI.
> 
> Over 15 million personal certificates by Korean national CA chains are
> issued and renewed based on Active X plugin in every year.
> Recently it transferred to iOS and Android application to treat
> certificates. As well as, some of banks made NPPlugins for non-IE browsers.
> 
> So, the rapid implementation of Web Crypto (key issue and digital sigining)
> is very important for Korean use cases in real problem.
> 
> Channy
> ---------------------
> Tech Evangelist : Web 2.0, Web Standards, Open Source and Firefox
> http://channy.creation.net
> 
> 
> 
> 
> 
> 2011/11/28 Anders Rundgren <anders.rundgren@telia.com>
> 
>> Just to get the discussion going...
>>
>> in case devices are in scope you should know that the
>>
>> GlobalPlatform Card Specification 2.2.1
>> http://www.globalplatform.org/specificationscard.asp
>>
>> is well over 300 pages and in turn refers to 500 pages+ of additional
>> information.
>>
>> IMO, this is also the reason why the *current* smart card technology is
>> unsuitable
>> for browser integration.
>>
>> FYI, I recently tested the JRE 1.6 standard library "javax.smartcardio.*"
>> and found
>> that it worked extremely bad on the 3 platforms I tried it on.
>>
>> As often pointed out, smart cards *do* work with certain combinations of
>> operating
>> systems, readers and middleware but as a foundation for consumers it
>> simply doesn't
>> cut  it.
>>
>> 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.
>>
>> Anders
>>
>>
>>
> 

Received on Monday, 28 November 2011 04:20:57 UTC