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!” )
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.
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.
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.
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.
)
