[Tfug] Securing firmware deployments
Chris Niswander
MOST.SENDERS.ARE._FILTERED.OUT_--FOR.MY.REAL.EMAIL.ADDRESS.check.my.website..tfug.rcvr.x6a3 at bitboost.com
Wed Dec 30 20:33:53 MST 2009
Bexley Hall wrote:
> Hi,
>
> I want to be able to TFTP (et al.) firmware updates to
> appliances. *Often* (i.e., imagine deploying executables
> "on demand" in this way).
>
> Since these appliances are often *not* just "computing
> devices" (i.e., they may control your HVAC, home security,
> etc.), the consequences of someone/thing tampering with
> an executable -- or, illegitimately installing a bogus
> executable -- can have serious financial or health
> impacts.
>
> The obvious solution is to use an encrypted tunnel
> for deployment. Or, to sign the binaries (and have
> the appliance refuse to load binaries with incorrect
> credentials).
...
> I can't go the MS route and embed a private key in the executable
> since that would be visible to anyone inspecting the sources.
Bexley, why not consider public key encryption?
(In case any readers are wondering, public key encryption
lets you encrypt or sign data with a secret key,
while a different, non-secret public key can be used
to decrypt or verify the data. The secret key can
be kept secret even though the public key is well-known.
Often public key encryption is used in other ways,
but this is a supported option.)
You could put a public key in your device's code,
without revealing the secret key that's needed to
forge unauthorized updates.
Enough of the early patents have expired
that you should be able to use it
without difficult intellectual property negotiations.
--Chris Niswander
More information about the tfug
mailing list