FB's Conceal secure-storage API

Tom Ritter tom at ritter.vg
Fri Feb 7 20:02:18 PST 2014


It's not like preventing root from getting the key is some attribute
they omitted by accident or incompetence - it's a significant design
change that changes the way the application would work.

It seems like everyone criticizing Facebook is angry that they're not
compromising their design principals for added security.  They have
very clear priorities: We are _going_ to benchmark and make sure any
code we add does not increase UI latency beyond an unacceptable limit.
 We are _going_ to cache some large MB of data on the phone, because
it makes the app faster. We are _not_ going to take up more space than
we need. We are _going_ to support old phones that have an SD Card,
and if that's where we cache the data, then so be it. We are _not_
going to require the user to enter a password or PIN on app startup.
We are _not_ going to require the phone to be online to used the
cached data.

With requirements like those, what you get is exactly this library. It
adds some small level of security against a very specific attack: data
stored on the SD Card and accessible to other programs. (It may even
be a way to get the security they need to permit themselves to store
cached data on the SD Card, which is a desirable situation because it
makes the app faster.)

If you relax some of those requirements, you can add security
features. Relax the latency or minimal storage requirement and you can
create an encrypted container, and hide metadata like filenames,
sizes, and times (like IOCipher). Relax the password requirement, and
you can have the user enter a password on app startup and prevent root
from getting the key unless it's in memory or entered.  Relax the
latency and offline requirement, and you can have the server send down
a key to decrypt the data.

Facebook is starting with the User Experience and adding as much
security as it allows.

-tom



More information about the cypherpunks mailing list