Security considerations?

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

1 Like

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

1 Like

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

1 Like

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 :slight_smile: )

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