Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Side-channel attack
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
==Countermeasures== Because side-channel attacks rely on the relationship between information emitted (leaked) through a side channel and the secret data, countermeasures fall into two main categories: (1) eliminate or reduce the release of such information and (2) eliminate the relationship between the leaked information and the secret data, that is, make the leaked information unrelated, or rather ''uncorrelated'', to the secret data, typically through some form of randomization of the ciphertext that transforms the data in a way that can be undone after the cryptographic operation (e.g., decryption) is completed. Under the first category, displays with special shielding to lessen electromagnetic emissions, reducing susceptibility to [[Tempest (codename)|TEMPEST]] attacks, are now commercially available. 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 (still in the first category) 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 (or, more generally, using more measurements in the analysis). When the amount of noise in the side channel increases, the adversary needs to collect more measurements. Another countermeasure under the first category is to use security analysis software to identify certain classes of side-channel attacks that can be found during the design stages of the underlying hardware itself. Timing attacks and cache attacks are both identifiable through certain commercially available security analysis software platforms, which allow for testing to identify the attack vulnerability itself, as well as the effectiveness of the architectural change to circumvent the vulnerability. The most comprehensive method to employ this countermeasure is to create a Secure Development Lifecycle for hardware, which includes utilizing all available security analysis platforms at their respective stages of the hardware development lifecycle.<ref>{{cite web|url=http://www.tortugalogic.com/isolation/|title=Identifying Isolation Issues in Modern Microprocessor Architectures|author1=Tortuga Logic|year=2018|access-date=2018-02-23|archive-date=2018-02-24|archive-url=https://web.archive.org/web/20180224113055/http://www.tortugalogic.com/isolation/}}</ref> 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 to be isochronous, that is to run in an exactly constant amount of time, independently of secret values. This makes timing attacks impossible.<ref name="Spadavecchia" >[http://www.era.lib.ed.ac.uk/bitstream/1842/860/1/Spadavecchia_thesis.pdf "A Network-based Asynchronous Architecture for Cryptographic Devices"] {{Webarchive|url=https://web.archive.org/web/20110929081236/http://www.era.lib.ed.ac.uk/bitstream/1842/860/1/Spadavecchia_thesis.pdf |date=2011-09-29 }} by Ljiljana Spadavecchia 2005 in sections "3.2.3 Countermeasures", "3.4.2 Countermeasures", "3.5.6 Countermeasures", "3.5.7 Software countermeasures", "3.5.8 Hardware countermeasures", and "4.10 Side-channel analysis of asynchronous architectures".</ref> 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 (code)|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.<ref name="Spadavecchia"/> On architectures where the instruction execution time is not data-dependent, a PC-secure program is also immune to timing attacks.<ref>[https://www.cs.berkeley.edu/~daw/papers/pcmodel-long.pdf "The Program Counter Security Model: Automatic Detection and Removal of Control-Flow Side Channel Attacks"] {{Webarchive|url=https://web.archive.org/web/20090419094523/http://www.cs.berkeley.edu/~daw/papers/pcmodel-long.pdf |date=2009-04-19 }} by David Molnar, Matt Piotrowski, David Schultz, David Wagner (2005).</ref><ref>{{Cite web |url=https://www.usenix.org/legacy/events/sec05/wips/molnar.pdf |title="The Program Counter Security Model: Automatic Detection and Removal of Control-Flow Side Channel Attacks" USENIX Work-in-Progress presentation of paper |access-date=2014-10-04 |archive-date=2017-08-14 |archive-url=https://web.archive.org/web/20170814055923/https://www.usenix.org/legacy/events/sec05/wips/molnar.pdf |url-status=live }}</ref> 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 (like accessing only the input, outputs and program data, and doing so according to a fixed pattern). For example, data-dependent [[lookup table|table lookups]] must be avoided because the cache could reveal which part of the lookup 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 gate]]s or dual-rail encoding) can reduce the leakage of information about the [[Hamming weight]] of the secret value, although exploitable correlations are likely to remain unless the balancing is perfect. This "balanced design" can be approximated in software by manipulating both the data and its complement together.<ref name="Spadavecchia" /> Several "secure CPUs" have been built as [[asynchronous circuit#Asynchronous CPU|asynchronous CPU]]s; they have no global timing reference. While these CPUs were intended to make timing and power attacks more difficult,<ref name="Spadavecchia" /> subsequent research found that timing variations in asynchronous circuits are harder to remove.<ref>{{Cite book|last1=Jeong|first1=C.|last2=Nowick|first2=S. M.|title=2007 Asia and South Pacific Design Automation Conference |chapter=Optimization of Robust Asynchronous Circuits by Local Input Completeness Relaxation |date=January 2007|chapter-url=https://ieeexplore.ieee.org/document/4196101/;jsessionid=dvEHDfrAohpjVZcxALGqKOFtVVYE7st919bZU5l_tSBwb8sdBn1t!696014846|pages=622β627|doi=10.1109/ASPDAC.2007.358055|isbn=978-1-4244-0629-6|s2cid=14219703}}</ref> A typical example of the second category (decorrelation) is a technique known as ''[[blinding (cryptography)|blinding]]''. In the case of [[RSA (cryptosystem)|RSA]] decryption with secret exponent <math>d</math> and corresponding encryption exponent <math>e</math> and modulus <math>m</math>, the technique applies as follows (for simplicity, the modular reduction by ''m'' is omitted in the formulas): before decrypting, that is, before computing the result of <math>y^d</math> for a given ciphertext <math>y</math>, the system picks a random number <math>r</math> and encrypts it with public exponent <math>e</math> to obtain <math>r^e</math>. Then, the decryption is done on <math>y \cdot r^e</math> to obtain <math>{(y \cdot r^e)}^d = y^d \cdot r^{e\cdot d} = y^d \cdot r</math>. Since the decrypting system chose <math>r</math>, it can compute its inverse modulo <math>m</math> to cancel out the factor <math>r</math> in the result and obtain <math>y^d</math>, the actual result of the decryption. For attacks that require collecting side-channel information from operations with data ''controlled by the attacker'', blinding is an effective countermeasure, since the actual operation is executed on a randomized version of the data, over which the attacker has no control or even knowledge. A more general countermeasure (in that it is effective against all side-channel attacks) is the masking countermeasure. The principle of masking is to avoid manipulating any sensitive value <math>y</math> directly, but rather manipulate a sharing of it: a set of variables (called "shares") <math>y_1, ..., y_d</math> such that <math>y = y_1 \oplus ... \oplus y_d</math> (where <math>\oplus</math> is the [[XOR gate|XOR]] operation). An attacker must recover all the values of the shares to get any meaningful information.<ref>[https://www.iacr.org/archive/eurocrypt2013/78810139/78810139.pdf "Masking against Side-Channel Attacks: A Formal Security Proof"] {{Webarchive|url=https://web.archive.org/web/20170811210617/https://www.iacr.org/archive/eurocrypt2013/78810139/78810139.pdf |date=2017-08-11 }} by Emmanuel Prouff, Matthieu Rivain in Advances in Cryptology β EUROCRYPT 2013.</ref> Recently, white-box modeling was utilized to develop a low-overhead generic circuit-level countermeasure<ref>[https://ieeexplore.ieee.org/document/9062997 "EM and Power SCA-Resilient AES-256 in 65nm CMOS Through >350Γ Current-Domain Signature Attenuation"] {{Webarchive|url=https://web.archive.org/web/20200807075610/https://ieeexplore.ieee.org/document/9062997 |date=2020-08-07 }} by D. Das et al., in IEEE International Solid-State Circuits Conference (ISSCC), 2020,</ref> against both EM as well as power side-channel attacks. To minimize the effects of the higher-level metal layers in an IC acting as more efficient antennas,<ref>[https://ieeexplore.ieee.org/document/8740839 "STELLAR: A Generic EM Side-Channel Attack Protection through Ground-Up Root-cause Analysis"] {{Webarchive|url=https://web.archive.org/web/20200222014211/https://ieeexplore.ieee.org/document/8740839 |date=2020-02-22 }} by D. Das, M. Nath, B. Chatterjee, S. Ghosh, and S. Sen, in IEEE International Symposium on Hardware Oriented Security and Trust (HOST), Washington, DC, 2019.</ref> the idea is to embed the crypto core with a signature suppression circuit,<ref>[https://ieeexplore.ieee.org/document/8351968 "ASNI: Attenuated Signature Noise Injection for Low-Overhead Power Side-Channel Attack Immunity"] {{Webarchive|url=https://web.archive.org/web/20200222014213/https://ieeexplore.ieee.org/document/8351968 |date=2020-02-22 }} by D. Das, S. Maity, S.B. Nasir, S. Ghosh, A. Raychowdhury and S. Sen, in IEEE Transactions on Circuits and Systems I: Regular Papers, 2017, Vol. 65, Issue 10.</ref><ref>[https://ieeexplore.ieee.org/document/7951799 "High efficiency power side-channel attack immunity using noise injection in attenuated signature domain"] {{Webarchive|url=https://web.archive.org/web/20200222014213/https://ieeexplore.ieee.org/document/7951799 |date=2020-02-22 }} by D. Das, S. Maity, S.B. Nasir, S. Ghosh, A. Raychowdhury and S. Sen, in IEEE International Symposium on Hardware Oriented Security and Trust (HOST), Washington, DC, 2017.</ref> routed locally within the lower-level metal layers, leading towards both power and EM side-channel attack immunity.
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)