Closed Bug 777917 Opened 12 years ago Closed 7 years ago

Implement Full Disk Encryption (FDE)

Categories

(Firefox OS Graveyard :: General, enhancement)

Product:
Firefox OS Graveyard
Component:
General
Platform:
ARM
Gonk (Firefox OS)
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: gkw, Unassigned)

References

Details

(Keywords: feature, foxfood, sec-want) 

Having Full Disk Encryption (FDE) eventually on B2G will be a decent additional security feature. Some BH 2012 talks mentioned FDE being one of the technologies to make phone hacking a little more difficult (note: it does not make it impossible.)

ref http://en.wikipedia.org/wiki/Full_disk_encryption
This may also be useful for data protection in case people lose phones or have their phones stolen etc.
The Android "FDE" implementation is not truly FDE as in it only encrypt certain partitions, the others being read-only. I think we could do the same. Its reasonably secure and we don't have to mess with the boot loader.
Keywords: sec-want
OS: All → Gonk (Firefox OS)
Hardware: All → ARM
There have been attacks against phones which have disk encryption in Android, by freezing the phone.

"The trio discovered that quickly connecting and disconnecting the battery of a frozen phone forced the handset into a vulnerable mode. This loophole let them start it up with some custom-built software rather than its onboard Android operating system. ... The German research group is now working on defences against the attack that ensures encryption keys are never put in vulnerable memory chips."

Basically one should ensure that the encryption keys are only used in "memory directly attached to a phone's processor".

http://www.bbc.co.uk/news/technology-21697704
On x86 there is such memory space in the CPU that can be used against this type of attacks (although I'm sure eventually one could find a way to extract them). See http://en.wikipedia.org/wiki/TRESOR

As long as the decryption key is present (ie device is running) there is a possibility to extract it.

I don't currently know if there is such a memory area in ARM chips, but that would indeed raise the bar. Still, storing keys in RAM is still a more complicated attack than just imaging the phone and mounting the image.
Imho, the freeze-mem attach is negligible when compared to the current situation of having NO data protection at all and should be treated on a lower priority than actually getting some sort of encryption into the system!

Apart from the suggestions already present, another approach could be to use the standard luks mechanism. There have been (successful) efforts in porting it to android already:

https://github.com/scintill/yaffsunlock
https://github.com/guardianproject/luks/wiki

Unlike the rather complicated mechanism in Android which is pretty tricky with the mounting readonly - unmounting-again - remounting-rw approach, this approach is much cleaner and uses a minimal UI for entering the password for the encrypted partition. This has several advantages:

- except the UI, most parts are already implemented and readily available
- separation of the screen-lock mechanism from the actual encryption key is already there
- you can optionally move the complete encrypted data partition to the SD card (even if your phone is fully encrypted, would you like to send it in for repairs with all your data in case of a broken screen?)

Together with the yaffsunlock developer, I have put together some thoughts and documented them in the wiki:

https://github.com/scintill/yaffsunlock/wiki

Maybe some of them could be considered for merging into the current wiki?
For now I would assign this bug to myslef, will try to implement it. The initial idea is te leverage a work done in our lab: http://www.isti.tu-berlin.de/fileadmin/fg214/matthias_petschick.pdf
Assignee: nobody → marta
As I found recently, we might be able just to re-use the existing implementation of Anfroid 4. Actually, it *does* support separating the PIN from the encryption key. The functionality is contained in the backend but only missing in the UI. See this article:

http://pof.eslack.org/2012/07/30/fortifying-a-galaxy-nexus-with-stock-ish-image-and-root-access/

The relevant line is this one:

vdc cryptfs changepw <new_password>

I have tested this and can confirm, that it really requires two different passwords for decryption and PIN and applying this step.
Since I see that vdc is involved here, I just thought I'd mention that there is already code in the Volume/VolumeService code for talking to vdc (and tracking state changes, etc).

I think that this would be the logical place to initiate any vdc operations. See bug 841660 for the patches which added support for formatting a volume.

This should then more or less automatically tie into device storage and media apps as far as volume availability is concerned (which encrypting).
Whiteboard: [apps watch list]
@marta@sec.t-labs.tu-berlin.de : Are there any updates regarding this bug?
Status: NEW → ASSIGNED
Whiteboard: [apps watch list]
From speaking to Marta last month, I believe there may be a student working on this bug. But I don't know where it is up to or if its being actively worked on. Marta, if this student is working on this, can we get an update (and maybe then assign this bug to them). I'd prefer not to leave this bug taken if its not being actively worked on though.
Assignee: marta → nobody
Hi I'm marta's student. For FDE, there are some approaches for implementation. I had then decided to upgrade from Vold and then wanted to write HTML 5 to the calling for Vold. The compile process runs through, but I have a problem with the debugging of Vold, SD cards can no longer be mount or are not available in FFOS.
Flags: needinfo?(nobody)
(In reply to Daniel Kulesz from comment #6)
> - separation of the screen-lock mechanism from the actual encryption key is
> already there

This is particularly important. It's a huge pain that in order to have a decently long disk encryption pass phrase on Android, I have to enter the same long screen unlock phrase every time I unlock the screen.

Please don't require the disk encryption pass phrase for normal screen unlock and allow a shorter password for screen unlock. (If the user fails at screen unlock thrice or so, then it's OK to ask for a longer pass phrase, but the point is that you shouldn't have to have a tradeoff between unlock usability and disk crypto security.)

Android and OS X get this wrong. Ubuntu and Windows get this right.
Henri: As I posted in comment #8 Android does not get this wrong - at least the back-end supports this and with a rooted phone having separate passphrases works fine! The problem is just that the back-end does not support that, so it's a pure UI problem. Of course, I would highly welcome it if B2G's UI would not suffer from this flaw.
(In reply to sebastian from comment #12)
> Hi I'm marta's student. For FDE, there are some approaches for
> implementation. I had then decided to upgrade from Vold and then wanted to
> write HTML 5 to the calling for Vold. The compile process runs through, but
> I have a problem with the debugging of Vold, SD cards can no longer be mount
> or are not available in FFOS.

Did you mean to set the need-info flag? I assume not. Is there anything that you need help with ? Do you have a plan for when you might get towards a work-in-progress patch, or a prototype?
Flags: needinfo?(nobody)
FWIW, bug 1049244 is about enabling MTP. If the camera photos, etc., are exposed to a PC over MTP rather than by letting the PC mount a FAT partition, the partition holding photos, music, etc. could be encrypted but still exposed to a PC over MTP when the screen is unlocked.
Where are we at on this right now?
I work with a primarily business communications oriented user base that would be very interested in transitioning to the FFOS platform as a light-weight, secure, open source alternative. I have identified 6 key features, in relative order of importance, that I believe are essential to this use case. Of the 6, only 2 are currently lacking and full disk encryption is the most important one. In my opinion, making the platform viable for business use would greatly help the project in terms of support and funding.  Does anyone else agree / disagree with any of this?

1.  Full disk encryption (currently lacking)
2.  Basic voice and data capabilities (existing)
3.  IMAP / SMTP e-mail client (existing)
4.  CalDAV calendar sync support (existing)
5.  CardDAV contact sync support (lacking)
6.  Modern web browser (existing)
I also agree that full disk encryption is an important feature. I'm a cryptoparty animator and for the moment, I hesitate to promote FirefoxOS because of the lake of this feature...
After doing various experiments with the crypto implementation in Android, I am wondering why FirefoxOS does not simply re-use the existing implementation. Yet it's a bit hacky and yes it has some defaults hardcoded which are not sensible (e.g. using just 128bit for the key), but this would be easy to fix. Since this feature is now lacking for more than 2,5 years since it was first reported here, and nobody came up with a working alternative implementation, I would suggest to take the implementation of Android 4.4 and go with that.

The following article explains the existing mechanism pretty well:

http://nelenkov.blogspot.de/2014/10/revisiting-android-disk-encryption.html
What does it take to give this issue some more weight and a developer to take it on? Its a bit hard to understand that this is not higher priority. I agree with those like Daniel saying it would be better to have encryption that has some issues than no encryption at all. I feel it is sending the wrong signals if the Moilla community isn't taking this seriously. Maybe we could launch a wider appeal? What would be the best channel for this?
Well, I guess the "best channel" would be if someone would develop and contribute a working patch - which could be based on the regular android stuff. We are looking forward to the 3.0 release of B2G and this release still does not offer any sort of disk/flash encryption...

I am not familiar with how issues are escalated at Mozilla. I assume contacting the management directly (I assume Andreas Gal would be the top-most person in charge) is not the preferred way.
(In reply to Daniel Kulesz from comment #21)
> Yet it's a bit hacky and yes it has some defaults hardcoded
> which are not sensible (e.g. using just 128bit for the key)

Since the other flavors of AES aren't as much stronger as the 128 flavor as originally advertised, avoiding burning CPU on larger keys is most likely sensible. See https://web.archive.org/web/20120119065719/https://cryptolux.org/FAQ_on_the_attacks
Keywords: foxfood
Summary: Consider implementing Full Disk Encryption (FDE) for B2G → Implement Full Disk Encryption (FDE)
Can we have a working adb authentication when developer mode is enabled, before we start encrypting the phone?
(In reply to Michal Purzynski [:michal`] (use NEEDINFO) from comment #25)
> Can we have a working adb authentication when developer mode is enabled,
> before we start encrypting the phone?

Bug 842747 is for implementing secure adb (as its implemented by android)
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.