safemode.space
← All techniques
EXF-0002.04
ST0008Exfiltration
sub-technique

Timing Attacks

Parent: EXF-0002

Description

Execution time varies with inputs and branches; precise measurement turns that variance into information. The attacker times acknowledgments, response latencies, or framing gaps to learn which code paths ran (e.g., MAC verified vs. failed, table entry present vs. absent) and to infer bits of secrets in timing-sensitive routines such as cryptographic checks. On resource-constrained processors and deterministic RTOSes, small differences persist across runs, making remote timing feasible over RF if clocks and propagation are accounted for. Combined with chosen inputs and statistics, these measurements leak internal state faster than brute-force cryptanalysis.

Mappings

EU regulation articles

  • craAnnex I, Part I, (2)(e)
    addresses
    moderate
    direct

    Timing attacks recover secrets through code-path-dependent latency; constant-time cryptographic implementations are part of the 'state of the art mechanisms' (2)(e) requires.

  • craAnnex I, Part I, (2)(k)
    addresses
    high
    direct

    Constant-time MAC verification and branch-free crypto are exploitation-mitigation mechanisms (2)(k) places on the design and production phase.

  • craAnnex I, Part II, (3)
    addresses
    high
    direct

    Timing attacks (primary mapping: Annex I, Part I, (2)(k)) require regular constant-time-implementation testing under (3) — micro-architectural changes can reintroduce timing variance over the support period.

  • eu-space-actArt. 85(1)
    addresses
    high
    direct

    Constant-time implementations of MAC verification and crypto routines — required to defeat timing attacks — are part of the cryptographic concept 85(1) places on operators.

  • eu-space-actArt. 85(2)
    addresses
    moderate
    direct

    Timing attacks (primary: Art. 85(1)) cascade to 85(2) — periodic key rotation limits the window for statistical timing recovery.

  • nis2Art. 21(2)(h)
    addresses
    moderate
    inferred

    Art. 21(2)(h)'s policy on the use of cryptography is domain-relevant, but a crypto-use policy does not mandate the constant-time implementation that defeats a timing side-channel; the interdicting control is an implementation property, not a policy on cryptography use.

  • nis2-implAnnex 13.2.1
    addresses
    moderate
    derived

    Where timing variations leak via observable response latencies on RF links, the protection-against-physical-and-environmental-threats obligation contributes through emission-management and dummy-traffic measures.

  • nis2-implAnnex 6.2.1
    addresses
    high
    derived

    Constant-time implementation of cryptographic and authentication paths is a secure-development discipline that closes timing-channel exfiltration; the rules for that lifecycle govern adoption of these implementation patterns.

ENISA controls

  • ENISA-STL-2025-03-sD.21-i02
    addresses
    moderate

    Coding standards including security constructs cover constant-time crypto and timing-safe operations that defeat remote timing-based key-bit inference.

  • ENISA-STL-2025-03-sD.21-i03
    addresses
    moderate

    A documented secure development lifecycle is relevant to code quality, but the generic secure-engineering-principles excerpt does not name constant-time or timing-safe coding and so does not actively prevent the timing side-channel EXF-0002.04 exploits.

  • ENISA-STL-2025-03-sD.23-i11
    addresses
    moderate

    Use of only approved cryptographic algorithms governs the cryptographic domain that timing attacks (EXF-0002.04) target; the excerpt does not itself assert constant-time/timing-resistant implementation, so the relationship is relevance-level.

Cross-reference controls

SPARTA countermeasures

Cite as SafeMode Space, EXF-0002.04 (SPARTA v3.2).

Built 2026-07-25 from 216 techniques, 334 regulation articles, 125 ENISA controls, 2,610 framework controls, and 90 countermeasures.