Encrypt/mask GPS data stored on watch

I was thinking recently, if I lost my watch (or more specifically, it was stolen) while I had GPS data on it, then my home address, work etc is all present there.

I'm interested in peoples' opinions on this - would a patch to runplus and/or a module for apps to encrypt and decrypt GPS data be useful?

Tech / CPU use

I feel like AES might be overkill, and we could instead perform some simple scrambling of the coordinates based on a code the user enters, perhaps offset them from the middle of the Pacific using the user's code as a seed for a PRNG.

Usability

Unless we saved the key on the watch (which defeats the point), the user would have to enter a code each time they wanted to read/write GPS - this wouldn't be great for usability, but I'm a little out of ideas.

How about adding a boot script that wipes the clock if the correct key is not entered? Unless you connect it with bluetooth to a computer it should be pretty safe..

You could definitely bypass that by taking apart the watch and reading the flash chip externally. You could possibly also bypass that by running something over the SWD pins that dumps the file contents. Also, I don't know whether Bluetooth passkey and whitelist are still active even after a reboot without loading code or in DFU mode.

If protection of e.g. the GPS tracks on the watch is the goal here, maybe regular or automatic sync (with auto delete in case no sync happened for a while) of the data to GadgetBridge or wherever and then just deleting it from the watch would be a way to tackle this?

Unless we saved the key on the watch ... but I'm a little out of ideas.

What about storing the key only in RAM and only when connected to the phone?
So the phone stores and provides the key. Shortly after they get separated the key is deleted on the watch. As soon as they are close by again the phone provides the key to the watch again.
This assumes that you only need to watch=decode the data while you have your phone with you. Going to a run and storing=encoding data could be done without phone still using asymmetric keys.

That should be safe as long as the phone is not stolen together with the watch .

Can we request a phone ID or e.g the MAC address or something from the watch via Gadgetbridge? It would be cool to just encrypt the data with e.g. the phones MAC address.

One thing to watch out for is StorageFile can't contain char code 255 so you can't just use normal encryption.

It's not just GPS but I guess there might be other personal info (QR codes, received messages, etc).

What about extending Gadgetbridge and the app loader to allow it to work with E.setPassword? - http://www.espruino.com/Reference#l_E_setPassword (setPassword would have to be in the .bootrst file so it's always run)

Using the phone sounds like an idea, I've created an initial PR to do this without gadget bridge (as I don't have it currently) but would be interested in adjustments to encrypt using a key stored either on the phone, or using some property of the phone.

regular or automatic sync (with auto delete in case no sync happened for a while) of the data to GadgetBridge

This is something I've been thinking about for a while - a bluetooth daemon running on a raspberry pi that regularly updates my watch's clock, fetches health/gps data off the watch and so on

I like the sound of asymmetric keys or using phone IDs/mac addresses to encrypt too. E.setPassword sounds very useful for dealing with more technical attacks - I suppose an existing bluetooth whitelist will cover anyone accessing the console unless an attacker guess the allowed mac addresses too.

I'm thinking the existing scramble GPS app works as a lightweight/ease-of-use "lock", and I have a few ideas for a more lockdown-mode which would incorporate these ideas along with encryption based on some key.

We could either encrypt just GPS and use recorder's existing async prompting to add a password-prompt afterwards, or go for more of a whole-device lock and request a password at either boot or unlock time.

I've been thinking about this more and like the idea of setPassword - my plan would be something like:

• In padlock.boot.js:
  
  • Read padlock.setting.json for the password
    
  • Call E.setPassword(password) (and E.lockConsole())
    
• Only allow padlock.setting.json to be set from the apploader / IDE
  
  • (If the password is setable from the settings app, anyone with physical access can unlock the watch)
    
    

Is there any existing standard setup for adding this into .bootrst ? I don't see any apps using it at the moment so I was going to generate it from all the <app>.bootrst.js files, if that sounds like a plan?

How cautious should I be with this file btw? Could I potentially brick my watch if I accidentally raise an exception or break BLE connections here?

Nothing else writes to .bootrst, so I'd just make your app put it in there direct. No point messing around especially when if things go wrong it's a real disaster.

Maybe add a NRF.on('connect',()=>Bluetooth.print("password:"); or something that the app loader can then detect when it connects?

Bear in mind you'll have to manually eval(Storage.read(".bootcde")) as well as when .bootrst exists bootcde is not run.

I'd say be very careful! I'm pretty sure the file is run all the time and can't be circumvented, so the only way to recover would be to boot back to the bootloader and upload a custom firmware that didn't load it! The app that sets the password should come with similar warnings too :)

About this - the USB cable that comes with the watch, do you know if its pins that connect to the SWD contacts on the watch also hook up to anything on the USB side?

I'm thinking it'd be nice to have a fallback in case I did lock myself out, and SWD would provide a nice way in, but I'm not sure how easy it'd be. I do have a cmsis-dap probe which can talk SWD that I could attempt to manually attach

do you know if its pins that connect to the SWD contacts on the watch also hook up to anything on the USB side?

Yes, it's a bit hacky but they do actually connect right through to USB data - so you can just get a USB socket, wire it up as in https://www.espruino.com/Bangle.js2+Technical#swd and plug the charge cable in and you're sorted.

cmsis-dap would be perfect - I posted how to use it at https://forum.espruino.com/conversations/393757/#17280505

I've setup an SWD probe and am able to access the watch - there is flashing as one option, but let's say something went wrong with this E.setPassword boot code. Are there other ways to reset that over SWD? (such as clearing parts of flash storage)

Well, nrf5x internal flash storage can be erased over SWD quite easily however Bangle.js storage is in external SPI flash which needs custom code to be executed. The password itself is however stored in RAM in variables so the password can be found by dumping RAM.

As for SWD access I have SWD Espruino console implemented via Segger RTT, currently it can be used as ordinary Espruino console from openocd via telnet. Something like

rtt setup 0x20000000 65535 "SEGGER RTT"
rtt start
rtt server start 2222 0

as per https://openocd.org/doc/html/General-Commands.html#Real-Time-Transfer-_0028RTT_0029
And then one could telnet to locahost port 2222 and have espruino console over SWD cable. Unfortunately WebIDE in browser cannot connect to telnet port so it is not that much usable for the IDE.

The second step is using any other espruino device to act as SWD debugger over 2 gpios and read/write RTT buffers in memory and redirect its console to this. So then one could connect to the other espruino device via IDE (over serial/usb/bluetooth) and have console of the device attached over SWD (like Bangle 2). I have the SWD part but not the RTT server part.

If you wanted to get around the setPassword, the other option is to do a custom build that doesn't use the external flash for storing the program data: https://github.com/espruino/Espruino/blob/master/boards/BANGLEJS2_NOFLASH.py

You could then boot up using that and use the flash library to modify what's in flash memory.

But for most users, the main recovery menu (super long-press of the button) should allow you to just to a factory reset and restore everything