Kernel security: beyond bug fixing

Posted Nov 1, 2015 8:08 UTC (Sun) by JdGordy (subscriber, #70103)
In reply to: Kernel security: beyond bug fixing by alonz
Parent article: Kernel security: beyond bug fixing

"Revive TCCBOOT in some form, so devices will build their own kernels at boot time (and thus employ per-device, per-boot randomizations).
Store the kernel as an archive library (.a file) on the device, and make the boot loader complete the link process—and randomize the order of sections/functions while doing so. This can add much more “noise” to kernel addresses than plain KASLR."

Both of those need a good source of randomness at boot time, which IoT devices wont have (or if they have they will be assumed to be backdoored)

Kernel security: beyond bug fixing

Posted Nov 1, 2015 8:37 UTC (Sun) by alonz (subscriber, #815) [Link] (5 responses)

> Both of those need a good source of randomness at boot time, which IoT devices wont have
> (or if they have they will be assumed to be backdoored)

How pessimistic :)

Many chipsets already provide hardware RNGs; I can hope that there will be more of those as time goes by.

As for these RNGs being backdoored... I know the ones I designed were not (alas, I'm not certain what chipsets still use those). I believe this is the case for at least most of the devices: contrary to popular belief, most companies designing IoT devices truly care about their customers' security (or, at least, they truly are afraid of the backlash if they're revealed to have put backdoors in place without advertising them).

Kernel security: beyond bug fixing

Posted Nov 2, 2015 9:51 UTC (Mon) by cladisch (✭ supporter ✭, #50193) [Link] (4 responses)

The problem with quite a few built-in RNGs is that they are completely undocumented ("trust us"), or when they are documented, that they turn out to have weaknesses.

For example, Atmel's ATSHA204* and some other chips appear to have a very poor random source, and try to paper over this with a PRNG based on a unique serial number. They do store the current state in their EEPROM, so you have to choose between repeated values, or risking to wear out the EEPROM.

A very common error is trying to use a von Neumann extractor to remove correlations (this extractor is guaranteed to work only on data that has no correlations to begin with). Lots of software, and Intel's 82802 and Via's Padlock RNGs have this error.

Kernel security: beyond bug fixing

Posted Nov 3, 2015 5:24 UTC (Tue) by JdGordy (subscriber, #70103) [Link] (3 responses)

"A very common error is trying to use a von Neumann extractor to remove correlations (this extractor is guaranteed to work only on data that has no correlations to begin with)."

pardon?!

von Neumann extractor is not useful

Posted Nov 3, 2015 7:42 UTC (Tue) by cladisch (✭ supporter ✭, #50193) [Link] (2 responses)

A von Neumann extractor requires that the pairs "01" and "10" are equally likely in its input. This is true for a Bernoulli sequence (which, in toy examples, can be generated with a biased coin), but this has no relation with most random data occuring in the real world.

von Neumann extractor is not useful

Posted Nov 16, 2015 4:10 UTC (Mon) by kevinm (guest, #69913) [Link] (1 responses)

How exactly do you get two consecutive 01 transitions without an intervening 10 transition?

von Neumann extractor is not useful

Posted Nov 16, 2015 5:55 UTC (Mon) by cladisch (✭ supporter ✭, #50193) [Link]

0101
(You cannot use the same bit for two decisions; that would break the output, too.)