[LEDE-DEV] automated signed firmware upgrades / hide a secret in image
mcr at sandelman.ca
Fri Feb 24 09:44:19 PST 2017
Bastian Bittorf <bb at npl.de> wrote:
> * Michael Richardson <mcr at sandelman.ca> [24.02.2017 09:03]:
>> > large random primenumbers. On the serverside, we store the product >
>> (aka: solution) of these 2 numbers. This is repeated for each
>> generated > image. (sorry, it breaks reproducable builds for now)
>> Anyone can multiply two large prime numbers to get the solution.
> oh, i was thinking that when you have a large number, e.g.
> you can not easily say what the 2 prime factors are to get this result?
> Or is this really a "fast" cumputation?
That's the essence of assymetric cryptographic algorithms, yes.
But, you don't want to create your own, because there are subtlies which
matter. And I don't think you used this mechanism right. If you really want
to go this way, and can assume you have libssl around, then it will let
do a signature rather easily.
>> So I can't understand what you are doing. You can't hide things in
>> binaries. That's total snake oil.
> It is, it's only about having a proof, that the image runs. If several
> people "say" that the image runs, other routers start to automatically
> flash it. I want to make sure, that nobody can fake that information it
Ah, I see. So what you want is a stamp in the image which is returned to
a server as a kind of "weather report" on whether or not the image is
succesfully being used.
The threat profile is rather moderate.
Nobody really gains that much by gaming the system.
I think having a stamp in the image which uniquely identifies it is enough.
I don't think you need any cryptography at all. Just https: POST the
contents of the magic file to the vote taker.
===== but ===== too-long version follows :-)
If you want to do some kind of defense against spamming of the server by
random twits, then do this:
1) create your secret on build server, make it 32-bytes in length.
(SHA256 output of some stuff on the build server, including time)
2) call the first 16 bytes the build-identifier, base64 it. Or perhaps
bubble-babble it, and show it to the user, etc. as the recognizable
-> returns 16-byte random challenge, Q.
3) call the second 16 bytes the build-secret.
AES128 encrypt (Q) using build-secret as the key. Call this the
post-content has base64 of response token.
4) the server can use it's copy of the build-secret to decrypt the
response-token, and verify that it is the same challenge that it
gave out before.
The server can either given everyone during a period of an hour the same
random challenge, it can make them up and store them, or it can construct
them as the HMAC-SHA256 of, for instance, the IP address which is asking,
such that it never has to record any of them.
A script kiddie now needs to do some work each time, has to request a new
token each time, and if the challenges are based upon IP address, the kiddie
can vote once per IP address they have. So, now they need a bot net to
vote a lot... probably that's okay.
>> I thought from the subject line and explanation that it was to permit
>> a firmware image to be validated as being uncorrupted/tained. One
>> might do this before flashing a device with it.
> how should this be done before flashing? if there is a mistake
> (e.g. forgotten package during build) the image itself is fine, but not
Right. So getting the stamp into the image at the very last moment is the
key. That way the build is reproduceable if you ignore those very few bytes.
Ideally, there is a spot in the image that shows up to userspace. Have you
figured this part out? I would attempt to make it a kernel boot command
line option, if that can be tweaked easily.
I think you've figured this part already though.
For a u-boot image, maybe skipping it into the image name.
I'm not sure what the sysupgrade.bin format is... mkimage -l says
those images are corrupt, but file says it's a uboot legacy image.
> and an sha256_signature if the image-hash. These hashes are added to
> the info.json:
> (see: 'bittorf').
> Other users have installed my public.key and can so check the
> signature. Also to flag "firmware_manually_checked" is changed to
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 487 bytes
Desc: not available
More information about the Lede-dev