* David Lang [25.02.2017 20:11]:
> The kernel already includes facilities for signing modules, if you
> are looking for a way to sign and verify things, it seems like it
> would make sense to adapt that to sign the entire image.
It is not about signing the image/modules, but giving a "thrustable"
The kernel already includes facilities for signing modules, if you are looking
for a way to sign and verify things, it seems like it would make sense to adapt
that to sign the entire image.
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http:/
Bastian Bittorf wrote:
> * Michael Richardson [24.02.2017 19:00]:
>> 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.
> the 'bubble-babble' thing is really interesting
* Felix Fietkau [25.02.2017 14:50]:
> > root@LEDE:~ :) usign -B
> > 98021604736550012081493806018992642304441039324849310980174888200312941028157
> > 114543661949658574850110716953530268394806126479026079327889534650057251922973
> I think patching something existing like usign does not make any se
On 2017-02-25 08:00, Bastian Bittorf wrote:
> * Michael Richardson [24.02.2017 19:00]:
>
> [...]
>
>> 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,
* Michael Richardson [24.02.2017 19:00]:
> 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.
the 'bubble-babble' thing is really interesting:
http://bohwaz.net/archives/web/Bubble_Babble
* Michael Richardson [24.02.2017 19:00]:
[...]
> 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 h
* Michael Richardson [24.02.2017 19:00]:
> >> Anyone can multiply two large prime numbers to get the solution.
>
> > oh, i was thinking that when you have a large number, e.g.
> >
> 115420076831901794986704648870740615472645895252280338354537840920338681749721961253499428085040885110
Bastian Bittorf wrote:
> * Michael Richardson [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)
>>
* Michael Richardson [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
Bastian Bittorf wrote:
> * Michael Richardson [23.02.2017 07:57]:
>> Yes, use an asymmetric key, and distribute the public part only.
> thanks people, for all the input and your ideas. our approach is now
> this: we hook into the 'usign' sourcecode and "hide" a secret there: 2
Eric Schultz wrote:
> prpl member IntrinsicID has physically unclonable function technology
> which allows a key to be generated at bootup based upon the physical
> characteristics of the device. It's the same key generated everytime
> but it isn't actually stored in flash. Their
* Eric Schultz [23.02.2017 07:57]:
> prpl member IntrinsicID has physically unclonable function technology which
> allows a key to be generated at bootup based upon the physical
> characteristics of the device. It's the same key generated everytime but it
this is not what i'am looking for: Intrin
* Michael Richardson [23.02.2017 07:57]:
> Yes, use an asymmetric key, and distribute the public part only.
thanks people, for all the input and your ideas. our approach
is now this: we hook into the 'usign' sourcecode and "hide" a
secret there: 2 large random primenumbers. On the serverside,
we
Bastian,
prpl member IntrinsicID has physically unclonable function technology
which allows a key to be generated at bootup based upon the physical
characteristics of the device. It's the same key generated everytime but
it isn't actually stored in flash. Their technology requires a paid
license b
Bastian Bittorf wrote:
> 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, t
* Yousong Zhou [22.02.2017 13:19]:
> How about generating at build time a piece of c code whose output when
> run at the target board will be the source code itself (quine). We
> can use the output content to seed the computation of signature. The
> binary itself should be cross-compiled in a re
On 22 February 2017 at 17:05, Bastian Bittorf wrote:
> 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 c
* Joris de Vries [22.02.2017 10:34]:
> Still it is a very interesting idea and I’d love to read more thoughts on
> this!
i will give a talk about this on battlemesh/vienna.
I the slides are ready, i will poke the list...
bye, bastian
___
Lede-dev mai
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
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,kalu
21 matches
Mail list logo
