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

[Michael Richardson]

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.
    > 11542007683190179498670464887074061547264589525228033835453784092033868174972196125349942808504088511053804942426194431961451801392254016733776993893835781

    > 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
    > easily.

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
   build name.

     GET https://server.example.com/nonce/build-identifier-stuff
     -> 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
     build-challenge-response token.

     POST https://server.example.com/nonce/build-identifier-stuff
     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
    > "good".

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:
    > http://intercity-vpn.de/networks/liszt28/firmware/models/Buffalo%20WZR-HP-AG300H/testing/Standard,DSLR,fotobox,kalua/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
    > 'true'.



--
]               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...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20170224/78b85457/attachment.sig>