[guardian-dev] Remote wipe for CacheWord?

[Tom Ritter]

I am not a big fan of mechanisms that require internet access, as I
often want to use these apps on the plane, the subway, 15 minutes from
my house where coverage stops, etc.  Even apps that require internet
access to function (e.g. a chat app) do not need it to be useful: I'd
like to review old messages, compose a new one, and queue it.

But of course CacheWord is a library, and could be used many ways.
There is little use for a streaming internet radio app to be usable
without an Internet connection. (There's some, but it'd be a
reasonable tradeoff if rejected them in favor of protecting critical
streaming radio secrets...?)

My main point of replying is that I continue to be disappointed at the
inability to use one of the embedded HSMs (SIM, some Android models'
SE) in our smartphones to implement particularly well defended '10
password attempt lockout'.

-tom

On 10 September 2014 08:05, Michael Rogers <michael at briarproject.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi all,
>
> I've been thinking about a way to implement remote wipe for mobile
> apps with encrypted local storage. The idea isn't suitable for Briar
> because it requires internet access, but I thought it might be a
> useful addition to CacheWord. Probably someone's already thought of a
> better way to do this, in which case please ignore this message.
>
> Briefly, the idea is to derive the storage encryption key from three
> things: something the user knows (a password), something stored on the
> device, and something stored in the cloud. By revoking access to the
> thing stored in the cloud, the user or someone they trust can deny
> access to the encrypted local storage, even if the adversary has
> access to the device and everything the user knows.
>
> We need a cloud service that supports three API methods: create, get
> and delete. The API is accessed over HTTPS with certificate pinning.
>
> The create method generates a random username, password and nonce,
> stores them on the server, and returns them to the client. This method
> is used when the app creates its encrypted local storage.
>
> The get method takes a username and password and returns the
> corresponding nonce to the client if the username and password are
> valid. This method is used when the app unlocks its encrypted local
> storage.
>
> The delete method takes a username and password and deletes the
> corresponding nonce if the username and password are valid. This
> method is used by the user or someone they trust to deny access to the
> app's encrypted local storage.
>
> There are various ways to derive the storage encryption key from the
> password, the nonce and something stored on the device. Two simple
> ways spring to mind:
>
> 1. Use the nonce as the PBKDF salt (not stored on the device). Use the
> PBKDF-derived key to encrypt and authenticate the storage key.
>
> 2. XOR the PBKDF-derived key with the nonce, and use the resulting key
> to encrypt and authenticate the storage key.
>
> Either way, an adversary without access to the nonce can't tell
> whether they've got the correct password.
>
> The get method could optionally be used to backup the nonce before
> wiping, in which case the storage could be 'unwiped'. But that creates
> new risks for whoever holds the backup.
>
> Cheers,
> Michael
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
>
> iQEcBAEBCAAGBQJUED5tAAoJEBEET9GfxSfMAZcH/iXY9y8l6Pf5Gsusp6wHouwJ
> pRXm4XRXyihU+IFH7aAi+0Ea8BrdVyK85deGx7kWmh5FwXeIlbiejUz/dTAavPH+
> 8xqVj8jiQJesjCSp5hTqwxgzf0McB91pqrNclLZY75N8GdI+9xk7QCBFHKtL1Zxh
> e+i9MEGHax11TmD/rmXSgkdWVqSAS3Uqori3LjpCBaZ9BL+87HUvUfpu1nCp54d/
> 6XPgCuo1XFzn50bDYJzS7krITaDcvpYc3TwrMLGyKifvquzgJRVJdS8V7iz0J1OC
> J7ujOBxUf3OwB6VsSdgQqbTDh2yuqMk8rAFXKbHUqC6npLr18kMc9l8DzaXJXr8=
> =dcLG
> -----END PGP SIGNATURE-----
> _______________________________________________
> Guardian-dev mailing list
>
> Post: Guardian-dev at lists.mayfirst.org
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>
> To Unsubscribe
>         Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>         Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/tom%40ritter.vg
>
> You are subscribed as: tom at ritter.vg