What are the dangers of using CPU clock drift for generating random data? From what I understand, a physical source of true randomness could be achieved with a multi-core processor, by using clock drift between two or more cores.

However, a processor is easier to manipulate than nuclear decay or thermal noise when it comes to true random number generation.

My questions are:


Are there any attacks?
Are any of them practical?
Are there any steps that can be taken or conditions satisfied to prevent attackers from effectively manipulating the output of the processor?
And finally, how easy is it to bias the cpu virtually compared to properly implemented and secure CSPRNG libraries offered, like java SecureRandom? 


My last question is really subjective to different libraries but if you can provide examples and scenarios or comparisons of potential attack vectors it would really help me understand.

I am currently under the impression that using a CPU for a TRNG is about as good as a software based CS-PRNG, but I could be wrong.
A TRNG is never used instead of a CSPRNG. They serve different purposes. A TRNG is used to seed a CSPRNG. A CSPRNG alone isn't enough to generate random data since it's reproducible. A hardware entropy source alone isn't enough to generate random data because all entropy sources have biases.

For any purpose that's related to security or cryptography, a random generator (CSRNG) is built by seeding a cryptographically secure pseudorandom generator (CSPRNG) with an entropy source, which is some physically obtained unpredictable, secret input. The CSPRNG whitens the entropy source.

The CSPRNG turns a small amount of data (typically a few thousands of bits) into an effectively endless stream of bits, and ensures that all the bits are independent. More precisely, a CSRNG must have the property that if an adversary sees all the output bits except one (but does not get to see the RNG's internal state), they have no clue what that hidden bit is: it could be either 0 or 1 and the adversary can only guess with a chance of success that's extremely close to $1/2$ — no more than $1/2+2^{-N}$ for a CSRNG with $N$-bit quality (e.g. $N=128$). A CSPRNG guarantees that property provided that its seed is sufficiently “varied”, in that the adversary can't guess the seed with a chance of success that's better than about $2^{-N}$.

A discretization of a physical phenomenon always has biases: some sequences of bits are more probable than others, due to characteristics of the physical phenomenon or to measurement errors. Using this as input to a CSPRNG destroys all the correlations between successive bits. The CSPRNG also has other benefits, including the ability of combining multiple phenomenons, with the safety that combining sources together never weakens the result (even if one of the sources turns out to be partially or totally known to the adversary, the quality of the resulting RNG is still at least as good as the other sources).



Now the real question is, is clock drift (jitter) useful as an entropy source? The answer is yes, it is used in practice. Fast Digital TRNG Based on Metastable Ring Oscillator by Vasyltsov et al. (2008) gives an overview of work in that domain in §2.

If you're an application writer, that's not something you need to care about. Entropy gathering is done by the operating system.

If you're a system integrator, you have to take care that your system has proper entropy sources. All modern PC processors (RDRAND) and smartphones (running iOS, Android or Windows) have hardware RNG (using phyiscal phenomenons that differ from chip to chip). Embedded devices are a very varied breed, some have good entropy sources, others don't; clock drift is often irrelevant in this realm because there aren't enough distinct clocks (unless one has been provided for the very purpose of generating entropy through drift, in which case the manufacturer will generally provide a some firmware or driver code to perform the required measurements).

Measuring clock drift is not trivial. You need to make sure that you're reading data from clocks that aren't synchronized. You need to give the system enough time to get initialized and then for the clocks to get out of synch. You need to beware of environmental parameters; for example some clocks may be effectively unpredictable at sufficiently high temperature but completely predictable at lower temperature. A good hardware RNG will provide a quality estimate. Statistical tests on an entropy source can sometimes help figure out whether it's operating correctly, but often the types of biases depend on the physical construction of the source and tests need to take this physical construction into account in order to be effective.