Re: [dsfjdssdfsd] Discussion: Malicious Entropy Attacks: Eggs, and Baskets

[Arnold Reinhold <[e-mail]>]

On Tuesday, March 18, 2014 7:17:31 PM UTC-4, D. J. Bernstein wrote:
>
> Arnold Reinhold writes: 
> > A determined attacker might be willing to absorb the effort and risk 
> > to covertly penetrate physical security barriers if doing so will lead 
> > to a permanent compromise of a one-time-seeded PRNG 
>
> You misunderstand the argument that you're responding to. 
>
> The argument, in the case of side-channel attacks, is _not_ "Don't worry 
> about side-channel attacks---you aren't being targeted by those." 
>
> The argument is "When a side-channel attacker is stealing your long-term 
> PGP key, your long-term SSH key, your long-term SSL key, etc., what 
> exactly do you think you're accomplishing by dribbling fresh entropy 
> into your RNG? It's too late! You've already lost! Try paying attention 
> to the actual problem: go back to the system design and start applying 
> side-channel countermeasures." 
>
> There's an extensive public literature on side-channel attacks and 
> defenses, notably in the proceedings of the top-tier Cryptographic 
> Hardware and Embedded Systems conference series. The attacks are much 
> more expensive for RNGs than for long-term keys (RNG state has far less 
> interaction with attacker-controlled input, and each state is used only 
> once), and the defenses are correspondingly easier; anyone capable of 
> protecting the long-term keys is also capable of protecting the RNG. 
>
> Similar comments apply to other "RNG state compromise" attacks. Sure, 
> there have been security failures that allowed attackers to read the 
> system's RNG state, but those failures also allowed attackers to read 
> long-term keys, and that's a much worse problem. Viewing this as an RNG 
> issue, and trying to "recover" from it by complicating the RNG, doesn't 
> make any sense. What makes sense is to address the underlying security 
> failures, protecting _all_ of the secrets stored in the system. 
>
> > We now have something we never had before, an apparently thorough 
> > rigorous analysis of the reseeding issue. 
>
> I see no connection between "the reseeding issue" and actual security. 
>
> ---Dan 
>

I was answering what I perceived as skepticism about the Tempest attack 
threat, but I would like to respond to your broader point. 

A random number generator (RNG) is a component of security systems. 
Electronic signature, symmetric and asymmetric encryption algorithms are 
other components. The argument seems to be that component A need not be 
resistant to attack X because critical component B is even more susceptible 
to X than A is. A counter position is that we should make component A as 
resistant to X as it can safely be, with reasonable effort, and also try to 
improve the resistance of component B to X. 

It’s at least conceivable that credentials can be made less subject to side 
channel attack. One  might, for example, use multi-layer credentials, with 
the operational credentials changed regularly. Transactions would be signed 
and encrypted using working keys with a short lifespan. The top level 
credential would be used very infrequently, limiting its exposure to side 
channels. The top level credential might also subject to further 
protections, perhaps stored in a separate module, or encrypted after 
signing second level credentials, perhaps using a public key of some remote 
station. That station might then authorize decryption for signing only when 
the system is under direct supervision. Such a system could recover from a 
compromise of its short term and intermediate term keys, perhaps in in a 
time frame comparable to an RNG recovery or even synchronized with the RNG 
reseeds.

It might be argued that any credential compromise is damaging, but the 
damage from a short term compromise can be limited. A seed-only-once RNG 
can never recover from a state compromise. 

The context here is a proposed revision for RFC 4086 Randomness 
Requirements for Security. If all goes smoothly the new RFC might come out 
in 2015 or 2016. Any new RNG recommendations it makes will take several 
years to appear in common operating systems and crypto libraries. Secure 
systems based on those components will then likely be in the field for a 
decade or more. That means systems influenced by the new RFC will be 
operating well into the 2030s. I don’t think we can predict all the uses 
for unpredictable quantities and possible attacks in that long a time 
frame. 

The Dodis paper suggests a sound basis for designing RNGs that recover from 
state compromise. It remains to be seen if flaws in their reasoning surface 
and if practical code based on their ideas will emerge free of intellectual 
property restrictions. But I think it is much too soon to rule out 
inclusion of such a scheme in the proposed RFC.

Arnold Reinhold