877535 - Provide secure data storage in Firefox OS (Keychain API)

Status: RESOLVED INVALID

(Firefox OS Graveyard :: General, defect)

Description

[Paul Theriault [:pauljt] (no longer reading bugmail)]

We should provide a way for apps for to store sensitive data in Firefox OS. Typically apps store data in indexeddb or other mechanisms which result in cleartext (albeit encoded) data being stored in the user profiles. While this data is protected by file permissions we can strengthen protection of this data by providing an API which encrypts data with a key derived from the user's passcode. 

Even with a weak passcode, I see the following benefits here:
- even with a weak passcode, provides some additional barrier to attacks 
- encouraging the adoption of a standard API means that future improvements ( stronger user passwords, hardware keystore etc) can be more quickly adopted
- having a central store for 'sensitive' data allows for features like 'clear all credentials' from my device (again, not strong without secure delete, but an improvement on the current situation)

Comment 1

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

There's also Bug 867899, which is a meta bug for importing PKCS12 on B2G.
However we didn't file bugs for those API (KeyManager or KeyStorage or KeyChain, whenever which name is better) yet, as we thought there's already WebCrypto Bug 865789 for this.

But we'd love to see the discussion of the API in this bug.

Comment 2

[Matěj Cepl]

Well I have mentioned in http://thread.gmane.org/gmane.comp.mozilla.devel.gaia/2581/focus=2597 that something similar to 
https://addons.mozilla.org/en-US/developers/docs/sdk/latest/modules/sdk/passwords.html could be a good start.

Comment 3

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Paul Theriault [:pauljt] from comment #0)
> We should provide a way for apps for to store sensitive data in Firefox OS.
> Typically apps store data in indexeddb or other mechanisms which result in
> cleartext (albeit encoded) data being stored in the user profiles. While
> this data is protected by file permissions we can strengthen protection of
> this data by providing an API which encrypts data with a key derived from
> the user's passcode. 
> 
> Even with a weak passcode, I see the following benefits here:
> - even with a weak passcode, provides some additional barrier to attacks 
> - encouraging the adoption of a standard API means that future improvements
> ( stronger user passwords, hardware keystore etc) can be more quickly adopted
> - having a central store for 'sensitive' data allows for features like
> 'clear all credentials' from my device (again, not strong without secure
> delete, but an improvement on the current situation)

The W3C is already working on DOMCrypt, which provides a way for web apps to encrypt data in a secure way, which they can then write to LocalStorage, IndexedDB, etc. as they see fit. It is being designed expressly to compose with those storage APIs.

Besides that, I would suggest that we first try to protect *all* the data storage on the device, before we put effort into selective protection. After all, I would say that all user data is sensitive data at some level. This is the approach that iPhone and (AFAICT) Android have taken. Basically, if you have a device password, you get protected storage for everything.

Comment 4

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

Hi, Paul
In Bug 865789, it's a bug for implementing WebCrypto.
Can you share the KeyChain API you had in mind ?
Does WebCrypto and KeyDiscovery can fit your requirement for 'Key Chain API'?

It seems in this bug, you also include the 'Credential Storage", 
does this bug overlap with Bug 865789?

Comment 5

[Paul Theriault [:pauljt] (no longer reading bugmail)]

While web crypto provides the primitives for applications to perform encryption and key derivation etc, this isn't exactly what I had in mind here. Or maybe my thoughts have evolved here since I raise this bug. Perhaps with Web Crypto, and the upcoming Message Ports API we could implement the centralized credential store that I had in mind. To cite some specific use cases:

- wiping credentials remotely as part of a 'lost my phone' feature
- wiping credentials as part of enabling system debugging
- sharing credentials between applications 

Feel free to reply, but at this point I am thinking this bug is too vague and I need to come back with some more specific requirements. I'll probably take this to the list then advocate for this as a future feature via the normal product process.

Comment 6

[Karen Ward [:kward]]

Paul - Is this bug in the queue to be moved into an upcoming release?

Comment 7

[Paul Theriault [:pauljt] (no longer reading bugmail)]

 (In reply to Karen Ward [:kward] from comment #6)
> Paul - Is this bug in the queue to be moved into an upcoming release?

It wasn't for 1.4, but I have seen some movement on the list about this. It probably makes sense to at least have it on the backlog for 1.5 (or beyond). I'll talk to the product team about this. Note there has been some discussion recently in this area on the dev-webapi list: https://groups.google.com/d/msg/mozilla.dev.webapi/dKcfvARJVMI/Pg7C1NPjLvAJ

Comment 8

[Anders Rundgren]

I think it would be unfortunate starting such a development without having at least mentioned some of the options here like:
1 Secure keys without secure enrollment; is it really useful?
2 Since keys are (usually) externally provided resources the issuer typically want to apply a specific policy which can be:
2.A must be unlocked by a PIN (which in turn follows a policy)
2.B may be used by a set of specific applications
Requirement #2 leads to #1
3. #1 should (also) be usable with WebCrypto.  It would (IMO) be a waste of resources making a duplicate enrollment system.

Comment 9

[Anders Rundgren]

http://webpki.org/papers/PKI/certenroll-features.pdf

The existing mechanism in Firefox was designed 1995 and doesn't meet current requirements

Comment 10

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

FxOS no longer in codebase. Marking INVALID.