Countermeasures
Because side channel attacks rely on emitted information (like electromagnetic radiation or sound) or on relationship information (as in timing and power attacks), one method of countering such attacks is to reduce the release of such information or access to those relationships. Displays are now commercially available which have been specially shielded to lessen electromagnetic emissions reducing susceptibility to TEMPEST attacks. Power line conditioning and filtering can help deter power monitoring attacks, although such measures must be used cautiously since even very small correlations can remain and compromise security. Physical enclosures can reduce the risk of surreptitious installation of microphones (to counter acoustic attacks) and other micro-monitoring devices (against CPU power draw or thermal imaging attacks).
Another countermeasure is to jam the emitted channel with noise. For instance, a random delay can be added to deter timing attacks, although adversaries can compensate for these delays by averaging multiple measurements together (or, more generally, using more measurements in the analysis). As the amount of noise in the side channel increases, the adversary needs to collect more measurements.
In the case of timing attacks against targets whose computation times are quantized into discrete clock cycle counts, an effective countermeasure against is to design the software so that it is isochronous—so it runs in an exactly constant amount of time, independent of secret values. This makes timing attacks impossible. Such countermeasures can be difficult to implement in practice, since even individual instructions can have variable timing on some CPUs.
One partial countermeasure against simple power attacks, but not differential power analysis attacks, is to design the software so that it is "PC-secure" in the "program counter security model". In a PC-secure program, the execution path does not depend on secret values—in other words, all conditional branches depend only on public information. (This is a more restrictive condition than isochronous code, but a less restrictive condition than branch-free code.) Even though multiply operations draw more power than NOP on practically all CPUs, using a constant execution path prevents such operation-dependent power differences—differences in power from choosing one branch over another—from leaking any secret information. On architectures where the instruction execution time is not data-dependent, a PC-secure program is also immune to timing attacks.
Another way in which code can be non-isochronous is that modern CPUs have a memory cache: accessing infrequently used information incurs a large timing penalty, revealing some information about the frequency of use of memory blocks. Cryptographic code designed to resist cache attacks attempts to use memory in only a predictable fashion (such as accessing only the input, outputs and program data, and doing so according to a fixed pattern). For example data-dependent look-up tables must be avoided because the cache could reveal which part of the look-up table was accessed.
Other partial countermeasures attempt to reduce the amount of information leaked from data-dependent power differences. Some operations use power that is correlated to the number of 1 bits in a secret value. Using a constant-weight code (such as using Fredkin gates or dual-rail encoding) can reduce the leakage of information about the Hamming weight of the secret value, although exploitable correlations will likely remain unless the balancing is exactly perfect. This "balanced design" can be approximated in software by manipulating both the data and its complement together.
Several "secure CPUs" have been built as asynchronous CPUs; they have no global timing reference. While these CPUs were intended to make timing and power attacks more difficult, subsequent research found that timing variations in asynchronous circuits are harder to remove.
Read more about this topic: Side Channel Attack