4 Likes
I seriously don’t expect that I will ever be in the situation where govt would demand that.
If that would be my threat model, i would just stop monitoring the location and accept the chance that I lose it.
I survived the last ~20 years that I owned a phone that way, and never lost one 
If you need an additional protection layer, you can still try with some obfuscation. A good start would be to not use “My phone’s location” as title
I’d would amuse me to send myself mails of the “helo, im Olga from Moscva, looking sirius men for marry” kind, and have a semi-plausible random location in the EXIF data, but then hide the real location data with steganography in the (obligatory) image itself. (Caution, if you do that last step wrong, e.g. by using the same image every time, you might shoot yourself in the foot very hard, at least if the agancy is worth their money and notices that not only the EXIF data is different… )
Unfortunately, nobody would ever appreciate the cleverness of this, so rather than implementing it, I’ll just leave it here 
Admittedly though, an encrypted spam mail might raise some suspicion 
DISCLAIMER: This was purely for amusement. Don’t try this at home, kids and whistle blowers.
On your other remark: NFC is way to complicated. Just have a threshold of ~100m position delta before actually sending an update.
1 Like
How many bits is the GPS info in total?
(rest of this post need not be taken too seriously)
If you are going to use stego in the way that you describe, perhaps best not to use encryption.
My concern with that is how you would be able to find the correct email in amongst all the other similar emails. 
Oh, and wouldn’t your mail provider’s anti-spam solution block the correct email (as well as blocking all the other similar emails)?
I would think that cleverness would be best paired with two additional requirements.
-
You wouldn’t publish your approach (public web site, your adversary and everyone else can read it).
-
Every person would choose a different approach (invent one’s own rather than copying someone else’s).
Never really worked with that. Depends a bit on the representation of the coords. I would assume it’s not more than 2x64 bit, and if you really try hard you could possibly make it less by reducing precision and encoding only a reasonable area around you.
1 Like
In the EXIF data itself, the representation is very expansive indeed, stretching to a full 59 bytes if I got my sums right.
It’s not 2 x something. You get latitude, longitude, altitude, speed and heading, and the last two are not simply derived from consecutive measurements, but calculated directly from doppler shift of sattelite signals. So at least 5x something (probably six, as speed in 3D has three numbers aswell) . How much you’d send home is of course different story.
1 Like
In the context of this discussion (find my phone) you might do without that. When I wrote “GPS info” I did not make clear the scope of the question.
For clarity then … 59 bytes of values in EXIF for latitude, longitude and altitude … and I agreed with the suggestion that that can easily be crunched into 128 bits (if allowing centimetre precision, which is probably more than you would want or need). If attempting to use stego then every bit counts so you would likely want to do better than 128 bits.
1 Like
If you already have Librem One and it includes a VPN tunnel, why to even go the EXIF/stego sado masochism
way? just set a non-default VPN route to your destination server via the VPN interface and as long as VPN
usage is not criminalized in your jurisdiction, you will be fine.
It would “amuse”.
Also, you need to think about the format in which the information exists at the destination. Can it / you be subject to seizure / compulsion? A VPN does not do anything about that issue.
1 Like
I’m just three steps ahead of you. It’s all part of the game. While all of you are now concentrating on the noise I added to Olga’s picture, I peacefully stego the real data into the email text itself. You know, sometimes it’s Marina from Lithuania (not counting the misspellings). Which also is just a distraction from the OTP I encode in the whitespace, serving as the key for the stego info I put in the “IoT device health report” mails, that all of my 168 home automation devices supposedly send…
(Meanwhile somewhere else on the Internet: “Sh**! I thought my idea was unique!” )
2 Likes
I split the data using Shamir secret sharing scheme (ssss FTW!), then upload it to the cloud in US, Soviet and China and my home. To reconstruct it, you need access to three out of four. Given they are all big countries and disliking each other, chances are they will refuse any data retrieval requests out of spite.
Edit: Also, this is not encryption, so I might dismiss any request for disclosing the encryption keys on this ground.
5 Likes
I think that’s actually a pretty decent idea if you really wanted a tracking feature like that.
Yeah you would need something to limit the spam.
@s3ns0r I love that (particular) comic.
And there’s the flaw in that brilliant scheme.
I hope you can find your way out of that tangled web…
1 Like
Meanwhile I’m here thinking why not just save the information to a file you sync to your next cloud server that will keep overwriting itself so that you only have the most recent location not everywhere you’ve ever been (this would of course be configurable if you do want the last 2,3,* locations)… You could still overcomplicate the obfuscation of course, I wouldn’t want to take that away from anyone, but no need to keep an indefinite history if the goal is to find where the phone currently is. I rather like the ssss solution, as long as you “encrypt” each piece of the location data in a haiku.
1 Like
Ah true. That is a better idea. Especially the haiku bit.
This fine <n> day of <month>
I’ve moved to <X,Y> place
Still, same shit around.
2 Likes
Absolutely true.
The only advantage of the mail approach is that basically everybody can install/configure that script within minutes (assuming encryption optional), because everybody has an email address.
It may change, but so far I have resisted the (rather low) temptation to put anything on cloud (a.k.a somebody else’s computer) storage.
1 Like
Dear Librem fans,
TLDR; {
I’ve been working on this for the last several months. I’ve created an end-to-end encrypted protocol for messaging remote devices for the purpose of ringing, tracking, locking and erasing them. My working title is the Secure Device Management Protocol. It’s end-to-end encrypted to prevent reading messages and impersonating the user from any third party including the necessary relay server. What’s more it does all of this using a single password for user convenience, without compromising the security of the communication. I’m also working on a v2 of the protocol that will be a general purpose end-to-end encrypted push protocol.
}
I actually anticipated this problem several months ago and I wrote my dissertation on this very exact issue. It describes a communication protocol that achieves messaging a remote device using a relay server. It uses end-to-end encryption to prevent any intermediary parties from reading messages or impersonating the user. What is more, the Secure Device Management Protocol (SDMP) achieves all of this using a single password for both authentication with the relay server and encrypting messages. They way this is done is by authenticating with the server without actually sharing the user’s password using the SRP protocol.
The problem theoretically isn’t hard, but it also isn’t trivial. One of the primary problems is that messages are sent and received at different times. This is due to the fact that that your phone may be off at the time you issue a command and by the time it turns on your client may be off. So interactive communication is impossible. This means that messages should be self sufficient and should be encrypted and signed. These messages also need to be resistant to replay attacks which adds additional complexity to the protocol. Last but not least, performance, memory usage and bandwidth efficiency are a concern as to minimise cellular data costs and extend the battery life of the device.
I’ve addressed all of these issues and solved them one way or another. The general idea looks very promising, but I would like to extend it a bit further before I write the first implementation. Namely, the protocol can be turned into a general purpose end-to-end encrypted push protocol that could be used by arbitrary services for arbitrary messages. One example of why a such push protocol is necessary for mobile devices (and IoT theoretically) is battery life. Most services on your phone like email, instant messaging, etc. require some sort of polling system to check if there is new data available and download it. Even in an event-driven architecture there is still polling done at the networking layer (ex. TCP socket keepalive). By only using a single system with a single connection, shared between multiple services you can save a lot of computation, wireless networking and extend battery life. This is why Google adopted a push notification system for Android. Their main concern apart from snooping on what you are doing is battery life.
The SDMP protocol requires several modifications to support messages from arbitrary services through the relay server which I am currently working on.
I would appreciate any kind of feedback, of course.
4 Likes
Publish as RFC?
wxyz
@itay-grudev Aye, if you ever get a git page up and running come back and post it here.
I’m sure there would be a lot of interest. 