PaperlayerView exact revision on arXiv

Source-linked AI summary

A Survey of Microarchitectural Side-channel Vulnerabilities, Attacks and Defenses in Cryptography

Xiaoxuan Lou, Tianwei Zhang, Jun Jiang, Yinqian Zhang

arXiv:2103.14244v1cs.CR

TL;DR

Microarchitectural side channels threaten cryptographic confidentiality because performance-oriented hardware can expose secret-dependent behavior. The paper surveys attacks and defenses across software, operating systems, and hardware, then evaluates real cryptographic applications. It concludes that vulnerabilities remain possible, but active remediation has prevented large-scale severe real-world attacks so far.

  • Problem

    Microarchitectural features can leak cryptographic secrets, while prior work does not comprehensively connect software vulnerabilities, hardware flaws, mitigations, and real-world application status.

  • Method

    The paper systematizes attacks, surveys application-, OS-, and hardware-level defenses, and evaluates cryptographic applications using vulnerability severity and response measurements.

  • Results

    Large-scale severe real-world attacks have not occurred so far because the community actively resolved discovered vulnerabilities and fortified common cryptographic libraries and applications.

  • Takeaways & Limitations

    The continuing arms race requires discovering unknown vulnerabilities, evaluating more applications, and developing new countermeasures.

  • Takeaways & Limitations

    The survey’s coverage is limited because microarchitectural studies generally require source code, leaving vulnerabilities in closed-source applications unclear.

Abstract

from arXiv · show

Side-channel attacks have become a severe threat to the confidentiality of computer applications and systems. One popular type of such attacks is the microarchitectural attack, where the adversary exploits the hardware features to break the protection enforced by the operating system and steal the secrets from the program. In this paper, we systematize microarchitectural side channels with a focus on attacks and defenses in cryptographic applications. We make three contributions. (1) We survey past research literature to categorize microarchitectural side-channel attacks. Since these are hardware attacks targeting software, we summarize the vulnerable implementations in software, as well as flawed designs in hardware. (2) We identify common strategies to mitigate microarchitectural attacks, from the application, OS and hardware levels. (3) We conduct a large-scale evaluation on popular cryptographic applications in the real world, and analyze the severity, practicality and impact of side-channel vulnerabilities. This survey is expected to inspire side-channel research community to discover new attacks, and more importantly, propose new defense solutions against them.

1 INTRODUCTION

Microarchitectural side channels arise when performance-oriented hardware features expose secret-dependent behavior, creating a persistent tension between system performance and cryptographic security. This survey organizes attacks, defenses, and the vulnerability status of cryptographic applications across software and hardware.

  • 1 INTRODUCTION: Shared performance features such as SMT and caches can expose secret-dependent execution behavior through contention and timing differences.SMT shares cores and functional units among threads, while caches and related components can reveal victim access traces.
  • 1 INTRODUCTION: Disabling microarchitectural features is impractical because of its substantial performance cost, while eliminating all software and hardware vulnerabilities remains difficult.The continuing difficulty of complete mitigation sustains an arms race between attacks and defenses.
  • 1 INTRODUCTION: The survey categorizes microarchitectural attacks, examines software vulnerabilities and hardware flaws, identifies application-, OS-, and hardware-level mitigations, and evaluates cryptographic applications.Its evaluation addresses vulnerability severity, practicality, and current prevalence in real-world cryptographic software.
  • 1 INTRODUCTION: Earlier surveys often addressed physical, network, or fault attacks, focused only on hardware flaws, or omitted the combined software-and-hardware perspective targeted here.These differences motivate a survey centered specifically on microarchitectural side channels in cryptographic applications.

2 BACKGROUND

Microarchitectural attacks infer secrets by correlating secret-dependent application behavior with observable hardware characteristics, using shared processor, cache, memory, or other components. The background defines the relevant architecture, cryptographic settings, and threat-model boundaries, including passive attackers and exclusions such as network side channels.

  • 2 BACKGROUND: Attackers recover secrets by correlating secret input, application runtime behavior, and observable microarchitectural characteristics such as memory-access patterns.Hardware observations may be direct state checks on shared components or indirect timing measurements.
  • 2.2 Multi-core Architecture: Modern multicore systems expose sharing across pipelines, SMT threads, caches, memory controllers, DRAM banks, and row buffers, creating observable contention and timing differences.The system hierarchy spans cores and caches within packages connected to memory controllers and DRAM.
  • 2.2 Multi-core Architecture: Caches, TLBs, and related components accelerate repeated accesses but expose state-dependent timing that can reveal victim activity.Caches use hierarchical levels and set associativity, while TLBs accelerate virtual-to-physical address translation.
  • 2.2 Multi-core Architecture: TEEs isolate execution and encrypt memory but do not inherently prevent side channels, allowing malicious operating systems to obtain fine-grained information through interrupt manipulation.The passage discusses ARM TrustZone and Intel SGX as examples of TEE implementations.
  • 2.3 Cryptography: Asymmetric cryptography uses private and public keys for confidentiality and digital signatures, while symmetric cryptography includes stream and block-cipher constructions.RSA, ElGamal, and ECC are presented as asymmetric examples; block ciphers process fixed-length plaintext blocks with key blocks.
  • 2.4 Threat Model: The threat model assumes passive spying by a normal user on a shared machine, with remote timing attacks restricted to querying the victim and active integrity attacks excluded.Network side channels based on application responses or packet patterns are excluded, although timing leaks from remote microarchitectural states remain in scope.

3 CHARACTERIZATION OF HARDWARE ATTACK VECTORS

The survey characterizes hardware attack vectors by system level and side-channel information, covering instruction, cache, and memory-management channels. These attacks exploit shared microarchitectural resources to infer cryptographic secrets.

  • Instruction Level: Instruction-level attacks identify victim instructions through contention on shared CPU functional units, including multiplier operations used in RSA.SMT can let attacker and victim share a physical core while executing concurrently, improving attack success rates.
  • Attack-Vector Organization: Table 1 organizes hardware attack vectors by the sharing required among attacker and victim, including CPU-core, package, and computer-level sharing.The table’s markers distinguish sharing the same CPU core, package, or computer.
  • Cache Attacks: Cache attacks monitor victim activity at cache-set, cache-line, or replacement-policy granularity using techniques such as Prime-Probe, Evict-Time, Flush-Reload, and Flush-Flush.Prime-Probe infers cache-set use from slower accesses after the victim potentially touches the set; Flush-Flush is stealthier but noisier.
  • Cache Attacks: Prime-Probe attacks progressed from L1 caches to LLCs, enabling attacks without same-core sharing and demonstrating cross-VM RSA-key recovery and SGX-enclave leakage.LLC attacks reverse-engineer cache-slice mappings, while malicious operating systems can coordinate cache attacks against enclaves.
  • Memory-Management Channels: Memory-management channels expose page-level access patterns through TLB behavior and page faults, although their granularity is coarser than instruction- or cache-level attacks.A malicious OS can restrict physical pages and observe page faults; Rowhammer-based bit flips have also revealed adjacent RSA private-key bits.

4 CHARACTERIZATION OF SOFTWARE ATTACK VECTORS

The survey organizes software vulnerabilities around secret-dependent control flow and data flow in cryptographic implementations. It traces how operand selection, branches, memory accesses, and implementation bugs expose secret values despite constant-time-oriented designs.

  • Overview: Table 2 classifies software vulnerabilities by cryptographic operation, cause, attack technique, and whether the leakage arises from control flow or data flow.The survey systematically maps vulnerable operations across cryptographic algorithms and protocols.
  • Modular Multiplication: Operand-dependent selection between naive and Karatsuba multiplication leaks operand sizes because the faster Karatsuba routine changes execution time.Timing observations can reveal operand sizes and enable recovery of a secret key.
  • Modular Exponentiation and Scalar Multiplication: Square-and-multiply and double-and-add expose secret bits because they invoke different arithmetic operations according to each bit, allowing attackers to recover the scalar or exponent from traces.RSA, GnuPG, and EdDSA attacks have used cache Prime-Probe, Flush-Reload, and TLB observations.
  • Modular Exponentiation and Scalar Multiplication: Sliding-window implementations leak through secret-dependent branches for zero windows and secret-dependent table accesses, exposing window values in RSA, ElGamal, and ECDSA.The method represents exponents or scalars as bounded windows and uses precomputed tables indexed by window values.
  • Windowed Implementations: Fixed-window implementations remove a critical branch but remain vulnerable to cache-bank timing, while masked-window implementations access all window values to hide those patterns.A software bug in OpenSSL 1.0.2h could disable the fixed-window exponentiation implementation.
  • Scalar-Multiplication Defenses: Branchless Montgomery ladders remove branch timing channels with bitwise swaps, but lookup-table accesses inside PointAdd and PointDouble can still leak ECDH secrets.The defense therefore removes one leakage source without eliminating all implementation-level side channels.
  • Modular Inversion: BEEA improves big-integer efficiency but introduces operand-dependent branches vulnerable to branch-prediction attacks, whereas EEA avoids secret-dependent branches at lower efficiency.EEA has no discovered side-channel vulnerabilities in the described implementation, although library bugs can accidentally disable it.
  • Post-Quantum Cryptography: Practical attacks on BLISS exploit cache or branch traces to recover rejection-sampled blinding values and infer secrets from randomized signing decisions.The attacks target both sampled values and random decisions controlling blinding signs or signature acceptance.

5 SUMMARY OF SIDE-CHANNEL COUNTERMEASURES

The survey groups countermeasures into application-, system-, and hardware-level strategies that unify runtime behavior, isolate shared resources, or detect leakage. Application changes are most practical today, while broader isolation and architectural defenses face deployment and performance barriers.

  • Defense Taxonomy: The survey categorizes defenses into three application-level, four system-level, and three hardware-level strategies.This taxonomy spans cryptographic implementations, operating-system mechanisms, and processor or memory-system designs.
  • Application-level Strategies: Application defenses equalize control flow by executing all paths and selecting results conditionally, and equalize data flow by accessing all critical locations or computing values on demand.These strategies support square-and-multiply-always, double-and-add-always, masked-window arithmetic, and related constant-time designs.
  • Application-level Strategies: Blinding randomizes secret keys or plaintexts/ciphertexts while preserving correct cryptographic results, so side-channel observations recover randomized values rather than the true secret.Key blinding uses algebraically equivalent randomized keys; plaintext/ciphertext blinding works when correct outputs can be reconstructed from randomized inputs.
  • System-level Strategies: System-level defenses isolate processes through spatial partitioning, page mapping, scheduling, browser permissions, and transactional-memory mechanisms that reduce shared-cache interference.Examples include cache partitioning, avoiding cache-line sharing, reducing cross-domain eviction, and preventing adversarial eviction from transactional memory.
  • Architecture-level Strategies: Hardware defenses partition shared resources, especially caches, but static cache partitioning can reduce effective capacity and cause substantial performance degradation and unfairness.Dynamic partitioning instead protects selected lines or enforces fine-grained replacement-time separation; related designs isolate TLB and enclave accesses.
  • Discussion: Application-level defenses dominate practice because they are easy to patch and impose little computational overhead, but they are non-general and require expert manual analysis.System- and architecture-level solutions are harder to deploy on existing machines and may introduce performance problems, leaving algorithm and implementation changes most practical.

6 EVALUATION OF CRYPTOGRAPHIC LIBRARIES

The evaluation examines the severity, response, cross-branch consistency, and countermeasure evolution of side-channel vulnerabilities in OpenSSL and GNU Crypto, while comparing their coverage across applications. It finds that most vulnerabilities were addressed quickly, but gaps remain in branch patching and less-evaluated or closed-source software.

  • 6.1 Vulnerability Severity: Side-channel vulnerabilities receive lower severity assessments than denial-of-service, code-execution, buffer-overflow, and memory-corruption vulnerabilities because they require stronger capabilities and generally cause partial confidentiality breaches.The comparison attributes the lower scores to reduced Exploitability and Impact, while other vulnerability classes can enable arbitrary code execution or disable services.
  • 6.1 Vulnerability Severity: Protocol-padding vulnerabilities are generally more severe than asymmetric-cipher vulnerabilities because padding-oracle attacks more often use network access vectors.The evaluation reports no post-quantum cryptography CVEs and omits symmetric ciphers because only two CVEs were reported and AES-NI mitigates existing vulnerabilities.
  • 6.2 Vulnerability Response: 56% of OpenSSL vulnerabilities and 50% of GNU Crypto vulnerabilities were fixed before publication, while more than 80% were fixed within one month of disclosure.Each library had only one case lasting more than four months; the longest was 198 days in GnuPG. Network and local attacks were fixed at similar speeds despite differing severity.
  • 6.2 Vulnerability Response: Most discovered vulnerabilities were addressed, but microarchitectural padding-oracle vulnerabilities remained in both libraries at the time of writing.The authors suggest these attacks may receive less attention because they require stronger adversarial capabilities and work only in limited contexts.
  • 6.3 Cross-branch Patch Consistency: Most patches covered all live branches simultaneously, but some fixes were missing from older or concurrent branches, leaving exploitable cross-branch windows.OpenSSL’s sliding-window replacement reached version 1.1.0i but not 1.0.2, and several fixes were never ported to branches before end of life.
  • 6.4 Countermeasure Type: OpenSSL shifted from introducing new implementations toward minor bug fixes and proactive hardening, whereas GNU Crypto retained traditional, sometimes less efficient solutions and lagged several years behind.For sliding-window scalar multiplication, OpenSSL adopted masked-window multiplication while Libgcrypt regressed to double-and-add-always.
  • 6.5 Comparisons with Other Libraries: The evaluation finds vulnerabilities widely across applications and argues that many remain undiscovered because research concentrates on common libraries and microarchitectural attacks usually require source code.Closed-source applications are chiefly represented by remote timing or message-side-channel findings, leaving their exposure to microarchitectural padding-oracle attacks unknown.
  • 6.5 Comparisons with Other Libraries: The coverage analysis cannot determine whether some vulnerabilities were solved when public information about their remediation is insufficient.This limitation affects a few cases in the cross-library coverage assessment.

7 CONCLUSION

Microarchitectural side-channel attacks against cryptographic implementations have persisted for over 20 years, but active remediation has so far prevented large-scale severe real-world damage. The paper expects the arms race between attacks and defenses to continue.

  • Active remediation has prevented large-scale side-channel attacks causing severe real-world damage so far.Years of defensive effort have strengthened common cryptographic libraries and applications.
  • Recently discovered vulnerabilities have generally been less significant or surprising after years of hardening cryptographic libraries and applications.
  • Researchers should continue discovering attacks, evaluating wider application ranges, and developing novel countermeasures.
Loading 2103.14244v1…