I really like this product and would buy it if i knew how “safe” it was. Im not so keen on having my car on the cloud.
After reading some threads I noticed that you have a local webserver on the dongle, what I want to know is what functionality i loose using the local webserver.
Regards
Chris
Hi @Elmion
Welcome to the AutoPi forum.
Just to address your security concern. The AutoPi is one of the most secure devices you will find on the market. Our device is always up-to-date with the latest security patches and releases. Many of our competitors sell a device, which does not give them possibility to address security issues after its been send to the customer. We’ve all heard of old equipment (routers etc), which cannot be upgraded and contains security holes, just because they are old. Since the AutoPi is always online, this is not a concern for us. We use AES encryption over ZeroMQ to communicate with all devices. This is built into SaltStack.
I do however understand your concern. This is also why it’s at our highest focus.
So, on the question you had. The local webserver is, at the moment, used for configuration and debugging of the device. All the “good stuff” is in the Cloud solution. We do have plans for moving some of the functionality to the local webserver, I just cannot say when that will be. But, the AutoPi core is fully open source, so you can really do any tweaking you want to make sure your setup fits your exact need.
I hope it was the answer you were seeking.
best
Peter
Hi,
I’mvery concern about my car also being connected to the cloud, does the pi has the ability to read and write to the car or just read?
If it cannot write to the car internal systems it can really do any damage, right? I’m concerned about hacking security
since you can use “cmd.run” on the cloud you can run any command on the linux cli of the pi, therefore you can do pretty much anything that is possible with the odb2 device, i hope that we can disable such write functions in the future.
Theorethical(not that theoretical actually): you can tell the pi to download a script, execute it and open a tunnel so you can even access the device via ssh and after that you can do everything without the “AutoPI Cloud” actually notice.
BR
Hi
Right now we are working on this with the philosophy that the platform should be as open as possible to allow people to build whatever they want, ie, instead of closing doors and locking things down, we’d like to keep most doors open or at least openable (ie. locked, but openable using a key).
Regarding security of the device.
We monitor security updates to the raspbian distro, and push those to the devices if anything critical occurs.
We are working on several things that will add additional layers of security on top of the OBD2 communication layer, including needing to opt-in for specific features and an extra layer of encryption when executing OBD2 or CAN BUS commands.
We want it to be as open as possible, but without compromising security.
We really, really appreciate your feedback!
So if you have any ideas, critique etc, we would love to hear it.
Best regards
/Malte
In this particular case i rather sacrifice the possibility of openness, but sure that the device would not interfere with my ability to control my vehicle, no amount of good information about my vehicle justifies the opportunity of a bad intention person to tamper with it, my family is on board and i simple wont take that chance if the device has that possibility. but if the device simple do not have the write pins it cant fiscally talk to the car, it can listen just fine, maybe having two devices one that can read and write and other only read. or interchangeable connector heads with the different pins.
Hi Luis
The autopi device is a maker platform, that aims to bridge the gap between IoT and cars, and our aim is to allow people to interface with their car in a simple and straight-forward way. This is the core idea of the platform, for private consumers and businesses.
Unfortunately there are no seperate pins for writing and reading, that’s not how this works.
There are pins for the different protocols, and how it works is that the autopi device (or any OBD device), requests a specific piece of information via a (somewhat) standardized list of PIDs, by sending a request, and then listens for the response, so if you somehow blocked the ability to write to the car, you would not be able to read anything either.
We have made efforts to make sure that the device is locked down, firewalls are enabled and configured, ports are closed etc. And the way we communicate with the device, is done through an encrypted connection via a open source enterprise grade system called SaltStack, used by many huge companies to secure and control their servers.
Not to mention that we continually update the devices to make sure they are always up to date, this is one of the most important features, security-wise, as it will continually apply updates, security fixes and other critical issues.
The closest thing to what you request regarding connector heads with different pins, is that you could use this cable or a similar one, to power your device in your car, but as i mentioned, that will severely reduce the features that the device provides, including but not limited to automatic trip creation and position logging etc.
I hope this answers your questions.
Best regards
/ Malte
I think the data transport is secure. Would be nice to have an option to disable the Wifi access point and only enable it by an hardware button. I don’t need it as Internet share. But this is not what I wanted to ask.
If somebody is able to hack the cloud account (get knowledge of the password). He will know actual position of the car. Is it possible to unlock the car or even steel it by sending special OBD commands?
I saw a report on TV some time ago, where they were able to disable anti theft and start the car by a special dongle after they had prevented locking by a jammer transmitter.
Hi Saimen
Disabling / switching between wifi modes is on our roadmap. But we don’t have any hardware buttons, and we need some way to switch between the modes, as the hotspot is currently the way to configure the device.
(if you have any suggestions to a good way to implement this, as always, suggestions are always welcome 
)
If someone uses your password to log into your account then they can see that same things as you can, so keeping your password secure is very important.
We do what we can by requiring long and complicated passwords, but we can’t however prevent users from reusing their passwords on multiple services. (Although integrating with Troy Hunt’s password service would prevent users from using already compromised passwords, which would be a great start)
With that said, we are working on additional levels of security, with specific focus on the execution of commands, as we will always keep the security of the product in an ongoing state, and never consider it ‘finished’.
I hope this answers your questions.
As always, any questions, suggestions etc, we welcome it all.
Best regards
/Malte
You could make your own bluetooth or USB switch/button. If you want to get spiffy you could simply use a remote control and an IR receiver for the bus. Wouldn’t take you very long to put that together.
When depressed/enabled run this script. Script looks for on or off… if this, do that.
This one from Amazon might be a bit too James Bondish, but all kinds of fun at the same time.
Yes, or even via the GPIO pins.
I have been toying with the idea of a small header with soldered on buttons, so that you get a small header that will fit right down on the GPIO pins, and match the cut out dimensions in the casing, so that the whole thing flushes to the casing and doesn’t expose wires, and just the tiny button sticks out.
I’m sure we could find other cool uses for buttons at some point.
But then again, depending on how you install the device, it may or may not be easily accessible, so you might not want to use the buttons for everyday stuff, but instead as mentioned only for rarely used stuff, like toggling the wifi hotspot.
Best regards
/Malte
Hi, I’m still in the process of getting the AutoPi 3G certified in my country by the radio communications regulator.
Anyway, I am a Telecom’s engineer with expertise in Mobile Netoworks and I’m interested in Security.
What I would like to know is if you are working with the MicroSD encrypted and also if you thought about hardening the device local access, leaving only the LTE network via Cloud.
I mean for example closing the USB ports and shut down WiFi and Bluetooth, when the hardware is already installed in the customer and you will leave it exposede to breaches.
It might have some option in the Cloud for Hardening Security locally and giving options of what you want to block access + microSD encryption.
A backup of the microSD card would be needed before in the cloud for that device, in case you lose remote access via LTE and need to access phisically by changing the microSD card.
You might lose contact if you are using a Prepay SIM that runs out of credit or something might happen with the LTE access. In that case the regular reboot suggested could fix this issue.
It’s just a suggestion for Security Improvement if it’s not already considered.
Would it be possible to get two factor authentication incorporated as well? I am new to the community, so my apologies if it is already an option.
There is a great and quite exhaustive write-up on possible attack vectors done by some researchers at the KTH in Stockholm on the AutoPi; KTH Research Paper
TLDR: (I’d recommend you to read it yourself though)
The AutoPi is architecturally mostly safe except for a vector that can be improved with proper configuration:
Remove the “AutoPi QC” network from the WiFi settings of the dongle (comes default, although it should not), since it allows for an attacker to open a WiFi and coax your dongle to connect to it. If you happen to have SSH enabled (not default), and you still have the default password set you are in big trouble. So:
* Remove the network from configs (should be done by manufacturer in the first place...)
* Change the SSH password to something safe (if you enable SSH, you should do this either way!!)
* Alternatively disable SSH login altogether, or
* Disable SSH password login in favour of key based authentication
As for MitM attacks, the dongles are properly secured end to end with AutiPi’s cloud infrastructure. If you customize things and/or add your own stack you should take care to do the same towards your own infrastructure. Proper certificates and properly setup trust chains.
This is relevant since Wifi’s WPA2 is fairly bruteforceable. Something you can also improve somewhat by strengthening the default password of the hotspot the device opens. You can also disable it completely after initial configuration in favour of having it connect to a network of your choosing. Mind you, that the connection credentials to your network are stored clear-text on the dongle. Which means you have to change it if any of the devices get fiscally compromised.
All this said THIS IS NOT EXAUSTIVE and you should always be aware and think about possible ways of exploiting your systems! Never assume anything!
Good find Iweberk,
The paper, however, is from 2019 and the mentioned issue with “AutoPi QC” has been fixed since then. But thank you for keeping an eye out for security issues, as it helps make the device more secure.
Also, see this blog post: