consider encrypting the actual location data?

[molobrakos]

http://owntracks.org/booklet/features/security/ states that it is possible to use encrypted communication as well as authentication with the servers. However, as I understand it, the actual location data is still visible to the servers. When using a third party hosted solution, would it be convenient to be able to encrypt the actual location data using a symmetric crypto and a key, shared and only known to the data publisher and the subscribing clients? (not sure if this is the correct place to make suggestions like this).

[jpmens]

Thanks for your suggestion. We do actually encrypt the data when it is in transit, if you configure TLS which we strongly recommend. As soon as the data reaches your MQTT broker, it is unencrypted, that is correct. While we have thought of this previously, we see no reason to do this currently. The location data must be visible to servers because programs like OwnTracks Recorder need to store it.

To be honest, we also felt that symmetric encryption would also be a challenge in terms of key distribution (server-side, and apps, say of family members or friends). While it may be possible that we revisit this opition some time, it won't happen soon.

[molobrakos]

The main use case would be to be able to use third party, or public brokers (where anyone can subscribe to any topic) without exposing your location (to the entire internet).

My suggestion would be to use symmetric encryption with a password, e.g. the client would expose the options "Encrypt position data yes/no", and "Password: [...]" in the user interface. Similarly, any subscriber would also have to have the same password configured.

The position data could be encrypted by passing the json payload { "_type": "location", "lat": X, "lon": Y } through a symmetric crypto, using the configured password, then base64-encoding it and putting it inside a new message: { "_type": "xlocation", "data": "" }

[jpmens]

I hope you'll be glad to know we are discussing this now. 😄

These are some very preliminary notes I've jotted down about how we would do this. I'd appreciate some feedback.

Payload encryption

Starting in version x (iOS) and version x (Android), the apps can be configured to transmit encrypted payloads. We have implemented this for people who insist in using public brokers without considering the implications of publishing their location data for everybody to read publically. While TLS (if enabled) protects the data in transit, a public broker will store (retain) messages for everybody to see.

If enabled, encryption requires the use of a secret key. This key is entered on the device in the form of up to 32 characters. (The apps strip leading and trailing white space, and fill up the 32 octets with binary zero.)

As soon as the device has encryption enabled on it, the full JSON payload our apps would otherwise publish in the clear is encrypted with libSodium as follows:

1. A nonce is generated
2. The JSON payload (_type: location, lat: xx, lon: yy, ...) is encrypted with the user's secret key and the nonce
3. The resulting ciphertext is base64-encoded
4. A new payload is published

The new payload will look like:

{
  "_type": "encrypted",
  "data": "vG0sAik3/+1KwrZ4b...lgku7eP19FeNjJugxhYnF9pvlxDBzUxYg=="
}

The receiving application detects encrypted payloads from the _type and reverses the process using its copy of the secret key:

1. Extract data
2. Base64-decode that data into the ciphertext
3. Use the authentication-tag and the nonce in the first 40 bytes of the ciphertext to decode the ciphertext with the secret key.

A client which is unable to decrypt data will simply ignore it and continue.

In particular, the OwnTracks Recorder will have a run-time option to specify a table of secret keys which can map topics from family or friends to their key:

owntracks/jjolie/iphone s3cr1t
owntracks/jane/n5  veryGold
...

The Recorder will store decrypted data in its original (unencrypted) JSON format in its storage.

[matbor]

@jpmens haven't looked into libSodium yet, but wonder if something like this will work with arduino to encrypt the data since tls isn't working yet.

[jpmens]

I'm not aware of libsodium actually fitting (space-wise) on a microcontroller.

[jpmens]

We have successfully tested payload encryption in iOS, Android and the Recorder. This means that we'll be releasing this when we're satisfied it's all ready and documented.

I am now closing this ticket.

[molobrakos]

Is it 32 characters or 32 octets?
Maybe a password hash as the key could be used to permit any password length?

[jpmens]

The field will accept 32 octets.