[Ovmsdev] Moving to a production cycle

Mon Feb 26 14:28:01 HKT 2018

> Mark, couldn't it be sufficient to just set the pass phrase config value during QC instead of burning it into an eFuse?

I’ve asked the China side. Specifically:

Can you print serial number stickers for these modules? I can provide design - and we can print a large batch.
Then, during manufacturing, have one step to enter serial number as password into module, like:
Flash
Connect terminal
QC checks
New step to type: config set wifi.ap OVMS <serialnumber>

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.

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.

Regards, Mark.

> On 25 Feb 2018, at 7:05 PM, Michael Balzer <dexter at expeedo.de> wrote:
> 
> 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 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
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hk
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at 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 at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180226/ccc20581/attachment.htm>