[LLVMdev] Adding diversity for security (and testing)

[Paul Robinson]

On Mon, Aug 26, 2013 at 9:14 PM, Todd Jackson <quantum.skyline at gmail.com>wrote:

>
>  > We would also include a secure random number generator which links
>> > against OpenSSL. This would of course be an optional module disabled
>> > by default, but is necessary so the randomization is cryptographically
>> > secure and useful in security applications.
>>
>> I am not sure why you need this feature.   You can provide LLVM with a
>> SEED value that can be controlled from the command line.  A wrapper (such
>> as a build-script) can control this value.
>
>
> (disclaimer:  I was a member of Stephen's research group and worked on
> this project.)
>
> To my knowledge, the pseudorandom number generator in LLVM is not
> cryptographically secure.  In this use case, the intent is to make it
> difficult to get the random number seed or the generator's state at any
> point in the random number stream by looking at the output.  If the state
> of the generator can be compromised, then an attacker can predict the
> output of the generator by playing it forward.  If an attacker can play the
> generator forward, then the attacker can reproduce the rest of the
> executable, including the randomized components that are no longer random
> to the attacker.  Reproducing the executable means that diversification
> isn't going to work because the attacker can plan around it.
>
> I should think that the choices at each decision point of the randomized
code-generation effect would require only a few bits from the output of
each run of the RNG, and you can run the RNG again for each decision point.
Because the vast majority of the RNG output is therefore not available to
the attacker, it's really really really hard to reconstruct the sequence.
 Even if it's not a crypto-based RNG.

Any RNG with adequately long cycles, reasonable bit-width, and
minimum-width enforcement on the seed value would be fine. And
computationally a lot cheaper than a crypto-based RNG.

> For reproducibility, such as for debugging, a pure software generator is a
> good idea.  This also prevents blocking read operations in the generator,
> slowing down the compiler.  Software generators can be optimized for speed.
>  These are reasons to avoid /dev/random et al.
>
> Personally, I think it is necessary to go for the strongest random number
> generator possible.  Cryptographically secure pseudorandom number
> generators have good properties that make them resistant to compromise.  In
> the case of the generator I think Stephen is proposing -- a generator based
> on running AES-128 in Counter Mode and described in one of NIST's documents
> -- the security comes from strong crypto building blocks, while still
> suitable for embedding in a  compiler.
>

Security comes from careful threat analysis and establishing
counter-measures appropriate to the threats, which might or might not
warrant crypto.  My house would be "more secure" if I put 24x7 armed guards
around it, but the threat level doesn't justify the cost.

As for using AES-128, I see buzzword value, but no real technical need.
 (No question that "crypto == good" syndrome comes into play here; it's
rare that you have to defend using crypto even if it isn't warranted.
 Until you run into a cranky-pants like me!)  In any case you need a
fallback for when OpenSSL isn't available.  I'm not claiming what LLVM has
now is adequate for you (looks like it uses rand(2)) but AES-128 seems like
overkill. (I've lost track of the general crypto-export-control state of
things, but just a reminder that LLVM avoids anything that could possibly
be export-controlled.)

Pogo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130828/4950b4c2/attachment.html>