On 11/03/2014 07:07 AM, Lars Boegild Thomsen wrote: > On Sunday 02 November 2014 12:08:15 Lars Boegild Thomsen wrote: >> 1. 100 % Automatic >> >> The device check at regular intervals if a new binary firmware is available >> and if that is the case it just updates. This one is entirely possible and >> not hard to implement. I am however not sure I like it. If someone managed >> to hijack our domain name that someone could brick all devices in one go. >> There is also the possibility of accidental bricking of thousands devices >> (even Microsoft have released updates that crashed Windows, and Google have >> screwed up their android updates quite often). In short - I personally >> don't like this one but I am willing to stand corrected and be convinced >> otherwise. >> >> 2. Automatic update of Tor alone >> >> This is a bit software as in the binary firmware stays as it is but only the >> Tor package gets updated. It's got the same security issues as number 1, >> but less of a risk of bricking accidentally and a path to recovery IF a bad >> update was submitted. >> >> 3. Visual indication of "action needed" >> >> In our current hardware design we actually included a RGB LED for this very >> reason. We could have that flashing RED (and label it "Update needed" on >> the box) if not up to date but still leave it for the user to update. I am >> personally leaning towards this one unless the issues with 1 or 2 can be >> solved but I am aware that a lot of people won't update. >> >> 4. Refuse to function unless updated >> >> Would flash red as in 3 but refuse to run unless the firmware is updated. I >> personally think this one is too annoying from a usability point of view. > > I thought of another one that might be the best option so far: > > 5. Have a dedicated status LED that will flash RED if system need upgrade. I > don't like the idea of a fully automatic upgrade, but the device _will_ have > a button and it could be that when the RED upgrade LED flashes, the device > can be upgraded with a press of the button. That approach is still to some > degree vulnerable to a man in the middle (DNS hijack) attack though. >
Well, I hope you will implement firmware signature check… this would prevent most of the MitM problems. This should be optional though, in order to let "power-users" mess with their own firmware if they want. Better: let them push their own key on their very own device so that they might as well secure their updates. -- tor-talk mailing list - [email protected] To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
