[LEDE-DEV] automated signed firmware upgrades / hide a secret in image

Joris de Vries j.s.de.vries at gmail.com
Wed Feb 22 01:20:51 PST 2017


This is a fascinating idea, although I think conceptually it is similar to DRM where in the end it is impossible to avoid giving the user the keys needed to decrypt content. In your scenario, I cannot see a way to avoid a rogue admin gaining access to the runtime-secret (but that certainly does not mean such a way does not exist).

Rather than a technical solution, you might try and find a solution in the process you use to release? You could have multiple (at least three? Two might be enough if requiring consensus) admins sign off on a release. That way, a single rogue admin cannot approve a release.

Still it is a very interesting idea and I’d love to read more thoughts on this!

Cheers,

Joris

> On 22 Feb 2017, at 10:05, Bastian Bittorf <bb at npl.de> wrote:
> 
> dear devs,
> 
> I'm polishing up our work-in-progress regarding automated
> firmware-upgrades in our community network and I have a concept problem:
> 
> our images/the sha256-sum's are signed:
> http://intercity-vpn.de/networks/liszt28/firmware/models/Buffalo%20WZR-HP-AG300H/testing/Standard,DSLR,fotobox,kalua/info.json
> 
> The downloader checks against a list of signatures, where
> e.g. 3 signatures must match the sha256 sum.
> 
> There are "automated" signatures (e.g. from builbot) and manual ones,
> from humans. For protecting ourselfes from bad admins, there
> should be a "secret thing" which is baked into the firmware and
> only seeable during runtime: this way we can prevent, that a lazy
> admin "signs" a sha256 sum, without really has flashed the image
> and can make sure that it really runs.
> 
> Now the question: a secret can be e.g.
> # ls -la /etc | md5sum
> 
> This is naive, and a dumb admin can e.g. unsquashfs the
> image for getting the data. are there better methods? any ideas?
> 
> bye, bastian
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev




More information about the Lede-dev mailing list