Open der-On opened 4 years ago
Thank you for the feedback on our project.
With the serverless approach we circumvent some problems with the security of a central server, but - as you have noticed - we are facing other problems in return, mainly regarding the GSM security risks. Frankly, due to the small size of the project we have so far decided to ignore these issues.
However, let me elaborate a bit on the question you raised.
Generally, one should arguably avoid sending messages with insufficient encryption. However, in our special case, we can identify one main, specific problem: Intercepting an SMS could enable an attacker to locate a bike and (if it is not protected otherwise) steal it.
Thomas Pornin wrote a very good summary over at Security SX on how hard it is to in fact intercept SMS, a very interesting read. To summarize, as you pointed out and as described on Wikipedia, in is in principle possible to intercept a SMS and decrypt the message with decent computational power in matters of hours. However, the attacker literally has to be at the right place, at the right time (between the bike-bean and the mobile base station, at the moment the SMS is sent). This means that it would be extremely unlikely that an attacker can determine the exact location of the bike by intercepting a message.
To mitigate this (still very unlikely) case, it is in principle possible to build an additional E2EE into the firmware on a per-device-basis. A possible implementation could look like this: Users manually create a cryptographic key (e.g. RSA-ish), store it in the firmware and flash it onto their devices. Then, the same key needs to be stored in the Bike-Bean App which would decrypt the messages. The communication between this App and the bike-bean would then be end-to-end encrypted. As this key would never be exchanged over the network, the only chance to crack this would be brute-force (or social engineering). The to-dos for this include the implementation of a corresponding encryption algorithm in the firmware as well as a decryption algorithm inside the App (PRs welcome).
From a privacy point of view, there is no personalized data whatsoever we are sending via SMS.
I hope this answers your question, feel free to add further discussion points here.
@jojo243 Thank you for the brief explanation. I will take a look into the linked articles. Having E2EE by default would be a very nice thing also the feature would be to designed well to not overhelm people with the complexity of encryption keys.
First of all thank you for this project. I really like the concept and the serverless approach.
However there are some concerns regarding GSM security risks (https://de.wikipedia.org/wiki/Global_System_for_Mobile_Communications#Sicherheitsdefizite) which should be considered.
Do you have taken those into account?