Impersonating users of 'protest' app Bridgefy was as simple as sniffing Bluetooth handshakes for identifiers An instant messaging app whose creators promoted it as secure and end-to-end encrypted was in fact no such thing, according to researchers at Royal Holloway. The University of London college found, according to a paper it published yesterday, that the app "permits its users to be tracked, offers no authenticity, no effective …
"Bridgefy was promoting itself earlier this year as the app of choice for protesters in Hong Kong and India to organise their activities without being easily spied upon by law enforcement agencies."
If it's that easy to break into it, you have to wonder whether it was actually written with that level of snooping in mind.
Now if you'll excuse me, I'm off to polish my collection of tinfoil hats. Can't let them get too dull, you know, it impairs their efficiency...
Hi everyone, I'm Jorge, founder at Bridgefy.
We're acutely aware of this conversation, and know that we must prioritize the safety of our user base. All of the issues reported on this article are already being fixed, and we should have updates published in the next few weeks.
Here's our blog post: https://bridgefy.me/bridgefys-commitment-to-privacy-and-security/
As always, we're available to keep the conversation going; please refer to the email address included in the blog post.
Thanks!
You actually said:
"We realized that Bridgefy's security model was appropriate for a small startup,"
No it wasn't, of course. Unless Bridgefy was originally designed as a hideously insecure mess, in which case, yeah sure. A secure messging system should be secure regardless of how many people use it.
You promoted your app as being "secure", which caused the (Admittedly unintended) side effect of protesters - a group that have a lot to lose up to and including their freedom if you get security and privacy wrong - misplacing their trust in you.
You were told about these defects in April, didn't publicly address them until August, and won't have a baseline secure version that includes such revolutions as "All payloads will be encrypted" ready until September
What you have done is borderline irresponsible.
Nice: a "secure" app which clearly has put zero thought into security.
plaintext sender and receiver addresses?
The crypto sigs is a bit more understandable - running those packages on low end cell phones is trickier than an iPhone only crowd.
Nonetheless, the pattern seems much more Zoom than Signal.
Thing is, the product they're trying to peddle already exists: https://briarproject.org/
Briar is designed to work over Bluetooth, Wi-Fi access points (no Internet connection required), and TOR.
(Supposedly it is also end-to-end encrypted, but I do not know if it has been audited for that functionality.)
From what I've read on the mater, Bridgefy was originally meant as an app for communicating or passing emergency information in places and situations where mobile coverage and internet were scarce. With that purpose of a "text-based walkie-talkie" in mind, perhaps it didn't have to be super secure and anonymous. However, when it started being used in situations where the communication and users were expected to be cybersecurity targets, it's rudimentary and flawed communication encryption became woefully inadequate.
"Fun" fact: according to ArsTechnica, the encoding method utilized by the app was introduced in 1993 and deprecated in 1998! How on Earth?!?!?! How does a modern app end up using something that was deprecated over 20 years ago?!
"the encoding method utilized (PKCS#1) by the app was introduced in 1993 and deprecated in 1998"
As an explanation rather than an excuse, this likely a combination of library defaults (it looks like the MessagePack serializer defaults to PKCS#1) and compatibility (based on experience supporting BYOD deployments in HK/India, supporting older mobile OS's was likely considered a high priority). While it can be decrypted (via Bleichenbacher’s attack), its still requires a significant number of messages to be sent (~1 million) before that is possible.
The reality is that this isn't even the key issue as message decryption is only an issue if you aren't already in the groups - anonymizing user information (my assumption is device information is mandatory for BLE comms) by authenticating to groups and using group key rotation would likely be sufficient to make decryption difficult in real-time/near real-time and prevent users being identified directly other than by their device identifier.
Which then leads to the device identifier showing you were present unless you use disposable phones or utils to alter the Bluetooth MAC - which is likely to be practical for organisers at least.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
