Bastian Bittorf <b...@npl.de> wrote: > * Michael Richardson <m...@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 [ ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev