[Ovmsdev] Moving to a production cycle

[Mark Webb-Johnson]

I’m not sure that Wifi MAC helps. That is broadcast as part of the WiFi station announcement, so using it as the password is really not any more secure than a fixed OVMS password.

Printing the wifi MAC also would be troublesome, because it would have to be entered into some printing program, and labels individually printed. Messy. Hand-written would not be good.

A better approach would be to come at it from the other way. Have the serial numbers / password stickers pre-printed in a large batch. Then, have the factory enter them into the number into the module during initial flashing / QC tests.

There is BLK3 of eFuses, but I find those scary. Supposedly it is not used (other than for a custom MAC address), and there are 192/256 bits available. That would be a one-time flash. We could store the serial number as a locally administered MAC address there.

It could also go into the flash as a configured parameter. That would be read/write (allowing someone to change the serial number).

BLK3 is probably the correct way of doing things, but very scary. That is a one time write (it literally sends too much current down a little wire in the chip - burning it out), and not so easy to debug the code ;-)

Regards, Mark.

> On 24 Feb 2018, at 5:21 PM, Michael Balzer <dexter at expeedo.de> wrote:
> 
> Greg, Mark,
> 
> I'm a bit concerned about an initially open Wifi access.
> 
> I know we're not targeting a mass market, but security is always important, especially for a system that can potentially control a car.
> 
> We need to be -and stay- aware this may introduce a way to hack & hijack the system. You would for example scan for new OVMS wifi networks, do an automatic
> passkey change to get access, then get the module to install a trojan firmware that mimicks the original behaviour (root kit style) and voila, you've got
> another bitcoin miner. A normal user will never recognize something's fishy.
> 
> With our current OTA function that's an unlikely attack vector, you would need to either control the GSM cell / DNS to redirect the download to your trojan site
> or have hacked the openvehicles.com server to deliver your trojan firmware. But things will evolve.
> 
> Some users may also not care about the Wifi access (i.e. using just Bluetooth / USB / GSM) and then not be aware it's actually active & open.
> 
> Is it too expensive to print the Wifi MAC or serial no. onto some label or document for the user?
> 
> If so we should at least make this very clear in the user documentation.
> 
> Btw, the same password could be used as the default module password, or we could use the module password for both purposes.
> 
> Regards,
> Michael
> 
> 
> Am 22.02.2018 um 05:52 schrieb Mark Webb-Johnson:
>>> There probably isn't a
>>> need for a custom SSID based on MAC or other serialization; that would
>>> only be necessary if configuring multiple modules at the same time in
>>> the same place.  Use case?
>> 
>> Yep. My thoughts exactly.
>> 
>>> it might be
>>> a good idea to have a required step of the configuration procedure be to
>>> force a passkey change and re-connect on the part of the user.
>> 
>> Yep. If we ask them to specify the AP name, and new password, then that resolves both problems.
>> 
> 
> -- 
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
> 
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev