[guardian-dev] Remote wipe for CacheWord?

[Hans of Guardian]

I like the core idea of a remote disabling function, I think it will definitely be a useful feature. Like Tom said, relying on internet access limits the use cases for it. There are other possibilities, like something more like CA or PGP revokation the opportunistically checks for revokation via the internet, which provides a weak promise of lockout.  This can be made quite transparent to the user, but does not provide the same level of guarantee.

A whole other approach would be a internet-based heartbeat, so that cacheword would automatically delete its key blob if it was not able to reach a heartbeat server on the internet within a given timeframe.

.hc

On Sep 12, 2014, at 7:33 AM, Tom Ritter wrote:

> 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
> _______________________________________________
> 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/hans%40guardianproject.info
> 
> You are subscribed as: hans at guardianproject.info