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.

I don't think the DomCrypt use-case fits banks for several reasons like:

- The concept of PIN and associated policy is completely missing
- Signatures with WYSIWYS seems to be missing as well.

If you are really interested in this, I think we should go somewhere
else.  US banks are *not* into PKI and signatures.

Anders

> 
> 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 Sunday, 27 November 2011 18:02:11 UTC