Firefox profile encryption

[Denis Cormier]

<dev-tec...@lists.mozilla.org>Hi everyone,

I am experimenting with profile encryption. The goal is to encrypt any
information that relates to the user's browsing such as usernames,
passwords, bookmarks, browsing history, cookies, homepage, etc. I have
located several files containing this information:

content-prefs.sqlite
cookies.sqlite
downloads.sqlite
formhistory.sqlite
permissions.sqlite
places.sqlite
signons.sqlite

bookmarkbackups.bookmarks-<date>.json
prefs.js
sessionstore.js

I have two questions.

1. Assuming the user does not enter a master password, would key3.db
require further encryption?
2. Am I missing files from the profile that would contain sensitive
information?

Thanks,

- Denis

[David Dahl]

----- Original Message -----
> From: "Denis Cormier" <denis.r...@gmail.com>
> To: dev-tec...@lists.mozilla.org
> Sent: Monday, June 4, 2012 9:10:34 AM
> Subject: Firefox profile encryption

> 1. Assuming the user does not enter a master password, would key3.db
> require further encryption?
> 2. Am I missing files from the profile that would contain sensitive
> information?

I believe the key3.db stores everything encrypted. I am not sure where the key it uses to encrypt things might be stored.

You should also include 'sessionstore.bak' and 'webappsstore.sqlite' (which may only be in pre-releases right now). Also, localstore.rdf has information about extensions and search providers you have installed, my nightly build also has chromeappsstore.sqlite which has web urls in it that are I think pinned to the new tab page.

Is your project hosted anywhere? I am quite interested in how this will work.

Cheers,

David

[Denis Cormier]

Thanks for the reply.

I don't have my project posted. The main parts involve replacing the SQLite
databases with SQLCipher databases to encrypt all the .sqlite files and
using NSS to encrypt the non-sqlite files at the stream level. I am still
working out the details, such as providing a key for SQLCipher and a
key/initialization vector for NSS.

For key3.db, I understood that it contains information about the master
password and another key used to unlock signons.sqlite. Considering I can
encrypt signons.sqlite (with a separate key not contained in key3.db),
should I bother messing with key3.db?

Cheers,

- Denis

> --
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto

[Robert Relyea]

On 06/04/2012 08:20 AM, David Dahl wrote:
> ----- Original Message -----
>> From: "Denis Cormier"<denis.r...@gmail.com>
>> To: dev-tec...@lists.mozilla.org
>> Sent: Monday, June 4, 2012 9:10:34 AM
>> Subject: Firefox profile encryption
>> 1. Assuming the user does not enter a master password, would key3.db
>> require further encryption?
>> 2. Am I missing files from the profile that would contain sensitive
>> information?
> I believe the key3.db stores everything encrypted. I am not sure where the key it uses to encrypt things might be stored.

Yes, key3.db is encrypted. The key is derived from the Master Password.
In fact that is what the master password is (the source of the PBE which
encrypts the key3.db).

If no master password is set, the key is derived from the password "".
The key3.db is still encrypted, but it's contents is trivially encrypted
because the key is known.

Question, what key are you using to encrypt the whole profile?

[Denis Cormier]

I plan on using a randomly generated 32-byte key provided by a trusted 3rd
party. I also plan on using a randomly generated 32-byte initialization
vector generated by NSS within Firefox (to use with the AES Chain Block
Cipher scheme).

What should I do with the initialization vector? I read that you have to
keep changing the initialization vector to preserve security. But to
decrypt the data you need the same initialization vector that you encrypted
the data with (which might not be the same IV as other files in the profile
at that given moment). Now, I know that SQLCipher keeps the initialization
vector at the end of every page it reads/writes to. Should I be doing
something similar with NSS (keeping the IV at the end or at the start of
each file)?

On Wed, Jun 6, 2012 at 3:18 PM, Robert Relyea <rre...@redhat.com> wrote:

> On 06/04/2012 08:20 AM, David Dahl wrote:
>
>> ----- Original Message -----
>>

>>> From: "Denis Cormier"<denis.r.cormier@**gmail.com<denis.r...@gmail.com>
>>> >
>>> To: dev-tec...@lists.mozilla.**org<dev-tec...@lists.mozilla.org>

[Robert Relyea]

On 06/08/2012 01:06 PM, Denis Cormier wrote:
> I plan on using a randomly generated 32-byte key provided by a trusted 3rd
> party. I also plan on using a randomly generated 32-byte initialization
> vector generated by NSS within Firefox (to use with the AES Chain Block
> Cipher scheme).

So you are fetching the key off box through some authenticated and
protected channel?

>
> What should I do with the initialization vector? I read that you have to
> keep changing the initialization vector to preserve security. But to
> decrypt the data you need the same initialization vector that you encrypted
> the data with (which might not be the same IV as other files in the profile
> at that given moment). Now, I know that SQLCipher keeps the initialization
> vector at the end of every page it reads/writes to. Should I be doing
> something similar with NSS (keeping the IV at the end or at the start of
> each file)?

There is no problem using a single generated IV to encrypt a full file.
The IV can and should be public, so you can store the IV with the file.
If you make changes to the file, you should generate a New IV and
encrypt the full file again.

If you want random access (writes or reads), you should generate a new
IV per block that you need to read/write (a la SQLCipher's pages). You
only need to change the IV on write, and there is no problem including
the IV with the data for read.

All of this assumes that writes to these files can be triggered by
untrusted 3 parties which do not have access to the key, but do have
access to the file. This is rare, but it's easier just to protect
against the attack than to analyze if you may be vulnerable to attack.

Also don't use a stream cipher to encrypt the files (RC-4, AES-CTR,
AES-OFB, etc).

bob