You're right, the MAC would be nonsense. Tom nailed my concern, and all workarounds can be avoided by an individual pass phrase.
Mark, couldn't it be sufficient to just set the pass phrase config value during QC instead of burning it into an eFuse?
As the QC procedure should already involve a boot, it would just need to also issue a config command to the running module. With stickers printed at the QC
station, the station could issue the command automatically, or with a pre-printed batch of stickers, the code could be scanned from the sticker to avoid manual
entry.
A later factory reset could also leave this config untouched, so it would only get cleared on an explicit flash erase -- and we can hook into the make targets
to tell the user about this.
Or am I missing something?
Regards,
Michael
Am 24.02.2018 um 23:24 schrieb Greg D.:
Agree, WiFi's MAC is not useful as a passphrase or password, but I don't
think that we need to go to blowing fuses to solve this.
Michael, you are absolutely right that we shouldn't leave an open wifi
hotspot sitting there; it's an invitation for abuse. But if we have a
static passphrase pre-set, and there is nothing one can do with the
module in that state - plugged in but not configured - I think that the
window for that abuse is going to be vanishingly small. A new customer
will get the module and plug it in to either their car or (perhaps
better) a standalone USB power source, and then configure it. It won't
be left powered but unconfigured for very long. A new wifi AP
passphrase can be set during that configuration process (encouraged or
enforced), and the issue closed.
Especially these days, the most universally accepted means to configure
something is with a web server. What you have done with the OVMS web
server is very well designed and executed, and I don't see any
significant issues with using that approach as the primary means for
configuring and managing the module.
Greg
Mark Webb-Johnson wrote:
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@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@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev