-
• #2
i'll say i suppose only thse security related app are likely to be trustable, like the 2FA, pin lock etc.
for other apps i'll treat them as plain text stored.
i'll say one can use "pattern launcher", and when pair with backward helpers, use the one that swipe back to the clock, NOT the launcher.
The pattern launcher already is like a screen lock, except that a press of button or a 10s press of button will boot into launcher or reboot, in both ways you are defeated.thus next level is:
disable the physical button as in the manual. ;
downside is if your watch halt, you cant immeditely reboot. (if just slow, i wrote a soft reboot app but not yet put in the bangle store).but as bangle's SWD is exposed, i guess we will never brick one, is it?
thanks
ps: it's like android in version 2. only screen lock and no encryption.
we better have to wait till bangle 3 or 4 in which the encryption is built in -- the cpu/ram/rom is not prepared.
-
• #3
Hi,
What is stored on the watch from my phone, is it messages emails etc, I assume this is configurable?
- the contents of any notifications on your phone's screen. By default these also get deleted as soon as you disconnect from your phone. So not full emails or anything like that.
- the current weather
- what music is playing if you were playing anything on your phone
- any alarms set in Gadgetbridge (I don't think this syncs with phone alarms)
- If enabled, Calendar entries for the next few days are synced too with the first few hundred chars of the entry. That's probably the biggest privacy issue.
It would be pretty straightforward to have an option that deleted your calendar when your phone bluetooth connection dropped, which would solve that issue though.
Is there any kind of scope for physical access control (a pass code screen lock)/device encryption code?
No - it's been discussed, but it's a bit of a minefield. For instance a 6 digit pin code might be considered a lot - you could encode everything you store in flash memory with that, right?
Once the encoded contents were out of the watch's memory, how long do you think it'd take them to brute-force all 1000000 pin codes by running it against an emulated Bangle.js to see if it boots? Once the code was written, it'd be maybe an hour.
I feel like a lot of big companies are going to rely on some obscurity - either a hidden key in the chip for encoding, or making the memory impossible to read out with custom silicon. But that's completely at-odds with making an open, hackable watch where everyone can see all the firmware :(
Sure, we could make it more difficult to get the data, but if there's one thing I've learnt it's that for the people that care about this, they will never be happy if there's any chance of their data being accessed so I'd rather not even try, and just say that any info stored on the watch should be considered potentially at risk.
Is there any kind of scope for wrist detection (such as on apple watches, the watch auto locks when removed)
The HRM can detect if it's against a surface, so that could be useful although not foolproof.
What data would be accessible without such features/locks if my watch got stolen?
You've got to assume basically anything could be read out by someone sufficiently intelligent.
- I have seen threads regarding secure boot (personally signed firmware/bootloaders). Is there truly any benefit to this if the device is unencrypted?
No, I don't think so. If you have physical access to the device, you can physically unsolder the flash chip and stick it in a programmer.
- When is phone data/notifications removed from the bangle.js2? I assume the majority is not stored in volatile memory and therefore persists following a shutdown?
Yes, it's stored in flash - but as above when bluetooth disconnects messages are removed. however Bangle.js uses a journalling filesystem, so if you were sufficiently clued up you could still dig it out of memory unless
require("Storage").compact
had been called.I should add here that there's nothing built into the Bangle.js low-level firmware that stores messages in flash, it's all JS - in fact as far as I know, when a message is received it's stored in RAM, and if your clock supports fast load the message is kept in RAM (and not written) and the messages app is loaded. If the message is acknowledged at that point, it'll be removed, and at no point will be message have been stored in volatile memory.
If you were willing to potentially lose messages, you could just delete the relevant line that writes the message (https://github.com/espruino/BangleApps/blob/master/apps/messages/lib.js#L140) - or even just paste
require("messages").write = function(){};
into theCustom Boot Code
app, and then no messages would ever get written to volatile memory. - the contents of any notifications on your phone's screen. By default these also get deleted as soon as you disconnect from your phone. So not full emails or anything like that.
I got a banglejs2 about a month ago and it's the best money I've spent on a watch ever. I've been lurking without an account here and seen several people talking about things like screen locks and ROM encryption could possibly be implemented.
One thing I would certainly praise bangle.js2 for is the fact if offers many ways to mitigate attacks on the device via Bluetooth/non physical access. This is not present in many devices on the market.
However, a notable attack vector seems to be physical access. I am still very new to bangle.js but have several questions.
4 is my most pressing question. I mean, I'm not really bothered about a sophisticated attacker analyzing my watch, but I certainly am bothered about a thief stealing my watch and having access to a text from my friend saying my home address or similar sensitive data? Or, even a friend or stranger messing with the watch when unattended for a short period like at a coffee shop etc? Or someone just my data being accessible if I lose the watch.
Is there any way to have the same level of control over physical access as there clearly is for Bluetooth? From what I have read thus far it appears most of these options are currently possible due to hardware limitations. I wondered if any dev's had anything I mentioned on their roadmap, or is there something I am missing?
Thank you to all the devs.