Re: The "korean bank" use-case

What is the "secure code" referred to here?  Is that a PIN?  And what is the difference between a "secure code" and a "secure code (with SMS auth)"?

On Nov 27, 2011, at 7:54 AM, 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.
> 
> 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 16:47:52 UTC