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

[D. J. Bernstein]

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

[Alaric Snell-Pym]

On 18/03/14 23:17, D. J. Bernstein wrote:

> 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.

I see this general point often missed in security discussions; folks get
worried about a particular security weakness to an attacker that has
already gained some set X of powers and throw the baby out with the
bathwater trying to fix it, despite attackers with X being able to
violate the actual security requirements of the system in other ways.
All this tells you is that you need to prevent the attacker from gaining
X in the first place!

I had this recently with an argument about securing something against
people who have managed to breach the UNIX shell account the software
runs under, and which has write access to its configuration *and*
binaries *and* all the data it can read/write...

It's vital to step back and look at the big picture from time to time :-)

ABS

--
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/

[Arnold Reinhold]

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 

[D. J. Bernstein]

Suppose there's a programming bug that trivially exposes user passwords,
long-term SSL keys, and maybe some RNG state to attackers. Do we respond
to this by dribbling fresh entropy into the RNG?

Arnold Reinhold writes, regarding side-channel attacks:

> 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.

Let's try this again slowly.

The attacker is stealing your long-term PGP key, your long-term SSH key,
and your long-term SSL key through side-channel attacks. What exactly do

you think you're accomplishing by dribbling fresh entropy into your RNG?

You say that your strategy is

(1) to make the RNG as "resistant" to these attacks as it can "safely
be" and then
(2) to "try" to similarly protect the rest of the system.

You claim that the first step is what's accomplished by the recent
dribbling paper http://eprint.iacr.org/2014/167.

The simple fact, however, is that dribbling fresh entropy into an RNG
doesn't make the RNG resistant to side-channel attacks. Proper
side-channel defenses directly and comprehensively address the
problem---they stop the attacker from seeing the secret data in the
first place---whereas dribbling fresh entropy into the RNG does not.

So you're not even following the first step of your own strategy.
Furthermore, proper side-channel defenses also apply to the rest of the
system (and in particular the long-term keys), whereas I have no idea
how you think dribbling fresh entropy into an RNG is a step towards
protecting the rest of the system.

---Dan