<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""><blockquote type="cite" class="">Mark, couldn't it be sufficient to just set the pass phrase config value during QC instead of burning it into an eFuse?</blockquote></div><div class=""><br class=""></div>I’ve asked the China side. Specifically:<div class=""><br class=""></div><div class=""><ol class="MailOutline"><li class="">Can you print serial number stickers for these modules? I can provide design - and we can print a large batch.</li><li class="">Then, during manufacturing, have one step to enter serial number as password into module, like:</li><ol class=""><li class="">Flash</li><li class="">Connect terminal</li><li class="">QC checks</li><li class="">New step to type: config set wifi.ap OVMS <serialnumber></li></ol></ol><div class=""><br class=""></div><div class="">I’ll let you know what they say. It should be fine, as it is just another part of the QC steps we are laying out for them.</div><div class=""><br class=""></div><div class="">They are producing these in batches of one to two hundred, so just not feasible to automate too much. I just worry they’ll mis-type the serial number or something like that.</div><div class=""><br class=""></div><div class="">Regards, Mark.<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 25 Feb 2018, at 7:05 PM, Michael Balzer <<a href="mailto:dexter@expeedo.de" class="">dexter@expeedo.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">You're right, the MAC would be nonsense. Tom nailed my concern, and all workarounds can be avoided by an individual pass phrase.<br class=""><br class="">Mark, couldn't it be sufficient to just set the pass phrase config value during QC instead of burning it into an eFuse?<br class=""><br class="">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<br class="">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<br class="">entry.<br class=""><br class="">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<br class="">to tell the user about this.<br class=""><br class="">Or am I missing something?<br class=""><br class="">Regards,<br class="">Michael<br class=""><br class=""><br class="">Am 24.02.2018 um 23:24 schrieb Greg D.:<br class=""><blockquote type="cite" class="">Agree, WiFi's MAC is not useful as a passphrase or password, but I don't<br class="">think that we need to go to blowing fuses to solve this.<br class=""><br class="">Michael, you are absolutely right that we shouldn't leave an open wifi<br class="">hotspot sitting there; it's an invitation for abuse. But if we have a<br class="">static passphrase pre-set, and there is nothing one can do with the<br class="">module in that state - plugged in but not configured - I think that the<br class="">window for that abuse is going to be vanishingly small. A new customer<br class="">will get the module and plug it in to either their car or (perhaps<br class="">better) a standalone USB power source, and then configure it. It won't<br class="">be left powered but unconfigured for very long. A new wifi AP<br class="">passphrase can be set during that configuration process (encouraged or<br class="">enforced), and the issue closed.<br class=""><br class="">Especially these days, the most universally accepted means to configure<br class="">something is with a web server. What you have done with the OVMS web<br class="">server is very well designed and executed, and I don't see any<br class="">significant issues with using that approach as the primary means for<br class="">configuring and managing the module. <br class=""><br class="">Greg<br class=""><br class=""><br class=""><br class="">Mark Webb-Johnson wrote:<br class=""><blockquote type="cite" class="">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.<br class=""><br class="">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.<br class=""><br class="">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.<br class=""><br class="">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.<br class=""><br class="">It could also go into the flash as a configured parameter. That would be read/write (allowing someone to change the serial number).<br class=""><br class="">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 ;-)<br class=""><br class="">Regards, Mark.<br class=""><br class=""><blockquote type="cite" class="">On 24 Feb 2018, at 5:21 PM, Michael Balzer <<a href="mailto:dexter@expeedo.de" class="">dexter@expeedo.de</a>> wrote:<br class=""><br class="">Greg, Mark,<br class=""><br class="">I'm a bit concerned about an initially open Wifi access.<br class=""><br class="">I know we're not targeting a mass market, but security is always important, especially for a system that can potentially control a car.<br class=""><br class="">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<br class="">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<br class="">another bitcoin miner. A normal user will never recognize something's fishy.<br class=""><br class="">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<br class="">or have hacked the <a href="http://openvehicles.com" class="">openvehicles.com</a> server to deliver your trojan firmware. But things will evolve.<br class=""><br class="">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.<br class=""><br class="">Is it too expensive to print the Wifi MAC or serial no. onto some label or document for the user?<br class=""><br class="">If so we should at least make this very clear in the user documentation.<br class=""><br class="">Btw, the same password could be used as the default module password, or we could use the module password for both purposes.<br class=""><br class="">Regards,<br class="">Michael<br class=""><br class=""><br class="">Am 22.02.2018 um 05:52 schrieb Mark Webb-Johnson:<br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">There probably isn't a<br class="">need for a custom SSID based on MAC or other serialization; that would<br class="">only be necessary if configuring multiple modules at the same time in<br class="">the same place. Use case?<br class=""></blockquote>Yep. My thoughts exactly.<br class=""><br class=""><blockquote type="cite" class="">it might be<br class="">a good idea to have a required step of the configuration procedure be to<br class="">force a passkey change and re-connect on the part of the user.<br class=""></blockquote>Yep. If we ask them to specify the AP name, and new password, then that resolves both problems.<br class=""><br class=""></blockquote>-- <br class="">Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal<br class="">Fon 02333 / 833 5735 * Handy 0176 / 206 989 26<br class=""><br class=""><br class="">_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.teslaclub.hk" class="">OvmsDev@lists.teslaclub.hk</a><br class="">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev<br class=""></blockquote>_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.teslaclub.hk" class="">OvmsDev@lists.teslaclub.hk</a><br class="">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev<br class=""></blockquote>_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.teslaclub.hk" class="">OvmsDev@lists.teslaclub.hk</a><br class="">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev<br class=""></blockquote><br class="">-- <br class="">Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal<br class="">Fon 02333 / 833 5735 * Handy 0176 / 206 989 26<br class=""><br class=""><br class="">_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.teslaclub.hk" class="">OvmsDev@lists.teslaclub.hk</a><br class="">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev<br class=""></div></div></blockquote></div><br class=""></div></div></body></html>