Re: UseCase for B2C personal information exchange

For the sake of completeness: There *are* cases where modern browsers do protect keys from being exposed to other processes, but it generally requires some support from the OS.  

For example, Chrome on Mac OS uses the Keychain API for this function.  Chrome on Windows, on the other hand, stores passwords in a manner that is subject to access from other user processes.
<http://securityxploded.com/chromepassworddecryptor.php>
I'm not sure what the state of the art is on Linux, but it seems like you could implement the proper protections using SELinux's per-process permissions.

Net of all that, I still think that Ryan is correct that this sort of thing is out of scope for this spec, given the platform dependencies.

--Richard






On Aug 2, 2012, at 12:33 PM, Ryan Sleevi wrote:

> 
> 
> On Wed, Aug 1, 2012 at 6:09 PM, Mountie Lee <mountie.lee@gmail.com> wrote:
> hi.
> one of the benefit using web crypto than TLS is
> it can encrypt message in user agent level.
> 
> if PC is compromised, 
> many attackers check virtual memory in OS ("pagefile.sys" file in Windows) to find out credit card numbers or other sensitive information.
> just with TLS, the message sent to server will be exist in virtual memory of PC for long time.
> if we encrypt the message in user agent level, the message is not exposed even in virtual memory.
> TLS + WebCrypto API is more safe that just with TLS.
> 
> Sorry Mountie,
> 
> This is not true in modern browsers. For many schemes, the plaintext message and/or keying material is kept in memory and eventually serialized to the page file.
> 
> Any attempts to operate securely in a compromised environment are not in scope, because these are fundamentally not possible, for any type of execution or computation (web or native code).
> 
> As noted in the Editor's Draft of Security Considerations, this API  does *not* seek to protect keying material from other local applications. It merely prevents keying material from being accessible to the content scripts themselves. A fully conforming user agent could store all of the keying material in plaintext on the user's hard disk. This is by design.
> 
> So such a use case/threat model is very much out of scope. While it's certainly possible to use the API in the specified manner, the security assurances provided by the API do not match your claims, and thus do not and will not provide the security desired.
>  
> 
> shortly describing the sequence.
> 1. make TLS session between server and client
> 2. server generate kay pair( ex: RSA 1024bit) that is only available on session.
> 3. server return public key to client
> 4. client encrypt message with public key by WebCrypto API (previously by JS frameworks)
> 5. client send encrypted message via TLS session.
> 6. server receive and decrypt with private key from the session.
> 7. if session is invalidated, the private key will be also invalidated.
> 
> more questions and answer.
> 
> is this WebCrypto API WG is focusing to just for mobile environment? or all available environment?
> is windows or traditional environment is out of scope?
> I think NO.
> 
> This WG is not focused on any environment other than the environments that implement user agents - so both mobile and desktop user agents are in scope. Further, consideration/awareness is being made for existing, non-user-agent based implementations (such as node.js), although such implementations are not the primary nor secondary focus of this API.
>  
> 
> we have to consider all cases.
> 
> best regards
> mountie.
> 
> 
> On Mon, Jul 30, 2012 at 2:43 PM, Anders Rundgren <anders.rundgren@telia.com> wrote:
> On 2012-07-30 07:06, Mountie Lee wrote:
> > Hi.
> >
> > I have comments for http://www.w3.org/2012/webcrypto/wiki/Use_Cases#B2C_personnal_information_exchange
> >
> > as a Korean Citizen
> > I receive many encrypted mails from card company or banks.
> >
> > the basic mechanism is as following.
> > the sender send mail with application download link and encrypted mail attachment.
> > the user is able to decrypt the mail attachment after installing the application via the link.
> > the passphrase is normally the last 7 digits of my personal SSN.
> >
> > the sender forces user installing application to their WINDOWS PC.
> >
> > I think we can not replace this case with web crypto implementations.
> >
> > because
> >
> > has conflict "same origin" policy of browser.
> > we can not make sure the email client has always web browsing capability
> > and the content is normally loaded from local file system.
> >
> > has alternatives
> > the sender can invite user to their web site
> > and verify user identity.
> > then show sensitive message on the web.
> 
> Hi Mountie,
> That's a much better solution.  Variants of this are established
> since 15 years back!  It is IMO a web "de-facto" standard.
> 
> Here I run into the question:
> Could the sender use Web Crypto to encrypt the message rather than TLS?
> To me it is unclear to me what the advantage would be.  In fact the entire
> encryption part of Web Crypto is unclear to me.
> 
> Anders
> 
> >
> > so my comment is
> > remove those use case "B2C personnal message exchange"
> > (sorry Channy ^^!)
> >
> > best regards
> >
> > --
> > Mountie Lee
> >
> > Tel : +82 2 2140 2700
> > E-Mail : mountie@paygate.net <mailto:mountie@paygate.net>
> > Twitter : mountielee
> >
> > =======================================
> > PayGate Inc.
> > THE STANDARD FOR ONLINE PAYMENT
> > for Korea, Japan, China, and the World
> >
> >
> >
> >
> 
> 
> 
> 
> -- 
> Mountie Lee
> 
> Tel : +82 2 2140 2700
> E-Mail : mountie@paygate.net
> Twitter : mountielee
> =======================================
> PayGate Inc.
> THE STANDARD FOR ONLINE PAYMENT
> for Korea, Japan, China, and the World
> 
> 
>

Received on Thursday, 2 August 2012 21:16:32 UTC