Re: security of a client-side JS API?

Hi.
I think End-to-End encryption is easily implementable with current
webcrypto API spec.

standardization for E2E is diffucult issue.

many E2E mechanisms can be implemented per web application or service
requirements.

regards
mountie.

On Thu, Nov 1, 2012 at 12:54 AM, Arthur D. Edelstein <
arthuredelstein@gmail.com> wrote:

> Again, Ryan, thanks for your time and effort in answering my questions.
>
> > > What sort of legal reasons do you have in mind? I think if legal
> protection
> > > for providers is the most notable motivation for providing the Crypto
> API,
> > > that should be explained in the draft, as well as any other important
> > > motivations.
> >
> > I think you misunderstood what I meant.
>
> Sorry about that, I did indeed.
>
> > If a provider is wishing to accept some form of signature as being
> > provided by a user (say, for document signing), then the provider is
> > typically legally (via appropriate government standards) prohibited
> > from key escrow, which is effectively what you are suggesting.
> >
> > So no provider will want to, or necessarily be able to, keep the
> > private key that is supposed to identify the user *on the server*.
>
> I had the impression from the API spec that crypto operations would
> use private keys without exposing to the web app the actual value of
> those private keys. Nonetheless the user would still be exposed to
> signing the wrong document. So I still think stating in the spec that
> legal protections are required for this part of the API to work, is
> very important.
>
> > > But I think it's also important to mention the issue of hostile web
> bots --
> > > it's really impossible for the server to trust crypto results from the
> web
> > > client.
> >
> > And that's not a goal of the API.
>
> Why is signature verification included in the API, then?
>
> > To put it differently, "it's really impossible for the server to trust
> > form results from a web client over TLS" - no matter how much client
> > JS validation they put in.
>
> Exactly.
>
> > >> But even more broadly, how does this at all differ from native
> > >> applications? They're just as dependent on the platforms cryptographic
> > >> stack. Servers have no control over that end.
> > >
> > >
> > > Yes, I agree. Which is why server-side crypto is necessary for the
> securing
> > > the provider's data. Platform vulnerabilities are a problem, but that
> > > doesn't excuse vulnerabilities in user agents.
> >
> > I apologize, but with the context with your earlier remarks, I'm still
> > not entirely sure the point you were originally trying to make or
> > where the gap is, but would be happy to try to better understand.
>
> Sorry, perhaps I don't understand your point about native apps. I
> agree that native apps have similar vulnerabilities, but I don't
> understand why that is relevant to the question of whether this API is
> useful for providing security.
>
> > >> Perhaps I'm mistaken, but we're not trying to necessarily provide new
> > >> security guarantees over existing native applications - we're
> > >> attempting to bring (some of) the same security model to the web -
> > >> which suggests improving the web security model.
> > >
> > > I'm arguing that you're not improving the web security model.
> >
> > That is correct. We are not trying to improve the web security model
> > and that is not part of our charter. WebAppSec is the general W3C WG
> > for focusing on such security issues.
>
> I'm sorry, I misunderstood your phrase "suggests improving the web
> security model."
>
> > > Web browsers
> > > already support secure communication between a provider and a user
> agent (by
> > > TLS), but users are forced to trust the provider with their (user)
> data.
> > > This API, even with CSP, similarly requires that the web app provider
> be
> > > trusted by the user not to leak data.
> > >
> > > So all the additional cryptographics primitives, because they are
> untrusted
> > > by both users and providers, don't plug any holes that weren't already
> > > plugged by TLS.
> >
> > This is true for some use cases, but is not true nor applicable to the
> > broad set of use cases already collected. My suspicion based on this
> > response is that you're looking at this API with a particular use case
> > in mind, and deeming it unable or unwilling to address that use case.
> > This is quite possibly true, and it would be good to understand that
> > use case.
>
> No, I have in mind the use cases in your draft. Here's the attacks I
> see (Forgive me if I'm misunderstanding something fundamental. I think
> these concrete cases really illustrate my concerns and help to clarify
> what I have been attempting to express.):
>
> 2.2. Protected Document Exchange & 2.3. Cloud Storage
> Attack: The web app indicates to the user that a document is being
> encrypted, and requests a public encryption key, but retains an
> unencrypted copy of the document.
>
> 2.4. Document Signing
> Attack: The web app presents the user with a document to sign,
> requests a key from the keystore for signing, and then invisibly uses
> that key to sign a different document.
>
> 2.5. Data Integrity Protection
> Attack: The User Agent provides a false verification of stored data.
>
> 2.6. Secure Messaging
> Attack: The web app steals plaintext OTR messages after they have been
> decrypted for display to the user.
>
> 2.7. Javascript Object Signing and Encryption (JOSE)
> Attack: The User Agent provides a false verification, or the web app
> steals decrypted user data.
>
> Two I'm less sure about:
>
> 2.1. Multi-factor Authentication
> I admit this may be secure (I'd need to study it more), but I don't
> see any advantage over TLS + server-side multi-key verification.
>
> 2.8. Out-of-Band Key Provisioning
> I'm not sure I understand what crypto operations the web app client
> side is performing here.
>
> So, what prevents these attacks from happening? Isn't this a serious
> problem for the API design?
>
> > That said, and as I mentioned earlier, you can use this, **in addition
> > with other APIs**, to implement exactly what you propose [end-to-end
> encryption]. For example,
> > using system apps/extensions/webapps/whatever your browser vendor or
> > standards body of choice calls them, you could implement a secure (eg:
> > NOT part of the target origin) application that provided input
> > methods, and output encrypted text.
>
> Exactly, and if the Crypto API were limited to this usage, I would
> have no objection. I'm concerned about its exposure and use in web
> apps.
>
> > You can already see this model in extensions like CryptoCat, to some
> > degree. The utility of this API, in such a scenario, is that it makes
> > it *easier* to develop such applications, and ideally, *more
> > efficient*, and does not require such extension/app authors to be
> > fully versed in the implementation details of how SHA-1 is
> > implemented, and can instead be aware that SHA-1 should be used (for
> > example).
>
> I agree, absolutely.
>
> > > Browsers could provide a means for users to encrypt the text the wish
> to
> > > enter in a TextArea, to display decrypted text, and to encrypt and
> decrypt
> > > files, all safely outside the page's JS runtime. This enhancement
> would give
> > > users of existing web services, such as web-based email, chat and file
> > > storage a major security boost. PGP and OTR modes would both be useful.
> > >
> > > Is there any chance the Web Crypto WG could recommend this kind of
> browser
> > > end-to-end crypto design? I think this alternative offers huge
> advantages
> > > over the proposed API for addressing the use cases you describe in the
> > > draft.
>
> > And thank you for your feedback! It's provided an excellent
> > opportunity to provide a better explanation of what we're (currently)
> > trying to do, and hopefully provides some context as to where this
> > fits in the overall web platform. Hopefully we'll be able to provide
> > more high-level details (eg: not directly in the spec) that may help
> > better demonstrate where the current spec sits, and where the overall
> > work in the WG fits within the web platform. I think you'll find that
> > we're actually working towards the same thing,
>
> Yes, I'm sure we are. I am looking forward to hearing more details at
> your meeting.
>
> > just at different
> > levels and with the understanding and assumption that some of the
> > problems you raised are either already addressed or being addressed
> > elsewhere within the W3C and the web community.
>
> If you have any hints on who in W3C might be working on a proposal for
> an end-to-end encryption standard for the browser, I'd be very
> grateful! I haven't found it yet. :)
>
> I hope your meetings go well and that you're enjoying Lyon in between
> answering my emails!
>
> Best regards,
> Arthur
>
>


-- 
Mountie Lee

PayGate
CTO, CISSP
Tel : +82 2 2140 2700
E-Mail : mountie@paygate.net

=======================================
PayGate Inc.
THE STANDARD FOR ONLINE PAYMENT
for Korea, Japan, China, and the World