Security Architecture

Dyber IP cores are designed to resist not only mathematical cryptanalysis (the algorithms themselves are NIST-standardized) but also implementation attacks — side-channel analysis, fault injection, and physical tampering that target the hardware execution of cryptographic operations. This document describes the security properties built into every Dyber IP core and the optional enhanced countermeasures available for high-assurance applications.

Overview #

The security architecture is organized in layers. Every Dyber IP core includes the baseline protections (constant-time execution, uniform memory access, key isolation). Optional enhanced countermeasures (masking, fault detection) are available as separately licensed modules that wrap the baseline cores.

Constant-Time Execution #

All Dyber IP cores guarantee that execution time is independent of secret data. This is the most fundamental side-channel protection and the most commonly violated property in software implementations.

What this means in practice:

No secret-dependent branches: The control flow of every operation follows the same path regardless of key material, plaintext, or intermediate values. There are no conditional statements that depend on secret data — the hardware FSM follows a fixed state sequence for every invocation of a given operation type.

No secret-dependent memory access patterns: Memory addresses are computed from public parameters (polynomial index, NTT stage) only. An attacker observing cache access patterns, DRAM row activations, or memory bus traffic cannot distinguish between different secret key values.

Deterministic cycle counts: Each operation (KeyGen, Encaps, Decaps, Sign, Verify) completes in a fixed number of clock cycles for a given parameter set. The host CPU can predict completion time precisely without polling status registers — though status registers are available for polling or interrupt-driven designs.

Uniform Memory Access #

Cryptographic operations in Dyber IP access memory in patterns that are independent of the data being processed. This prevents cache-timing attacks and memory bus analysis.

Polynomial memory: NTT butterfly access patterns follow a fixed schedule determined by the transform stage and butterfly index — never by coefficient values. The access pattern is identical for every NTT computation regardless of input data.

Twiddle factor ROM: Read addresses are computed from the NTT stage counter only. No data-dependent ROM lookups.

Key buffer: Private key reads use a sequential scan pattern — the entire key buffer is read in order even if only a subset is needed for the current operation. This prevents address-based information leakage about which key bytes are being used.

Table lookups: Where table lookups are required (e.g., CBD sampling), full-table reads with masking are used instead of direct indexing. The hardware reads all table entries and selects the correct one via constant-time multiplexing.

Power Analysis Countermeasures #

The optional DYBER-MASK module provides first-order masking countermeasures against Differential Power Analysis (DPA) and Simple Power Analysis (SPA). Masking is the primary defense against power and electromagnetic side-channel attacks in hardware implementations.

Boolean masking: All secret-dependent logic operations (AND, OR, XOR on key-derived values) are split into two shares: x = x₁ ⊕ x₂, where x₁ is the masked value and x₂ is a random mask. Operations are performed on individual shares independently, ensuring that the power consumption of any single share is statistically independent of the secret value.

Arithmetic masking: Modular additions involving secret values use arithmetic shares: x = x₁ + x₂ mod q. Conversion between Boolean and arithmetic masks uses the Goubin method with constant-time execution.

Mask refresh: Fresh random masks are generated for each operation using the integrated DRBG. Mask entropy is drawn from DYBER-QRNG when available, or from an external entropy input.

Verification: Masked implementations are verified against the TVLA (Test Vector Leakage Assessment) methodology. First-order t-test evaluations confirm that no statistically significant leakage is present at the recommended trace count. TVLA evaluation reports are included in the DYBER-MASK deliverables.

Fault Injection Resistance #

The optional DYBER-FI-DETECT module protects against fault injection attacks — voltage glitching, clock manipulation, laser fault injection, and electromagnetic fault injection — that attempt to induce computational errors revealing secret key information.

Redundant computation: Critical operations (NTT butterfly, modular multiplication, hash permutation) are executed twice with independent data paths. Results are compared before output; a mismatch triggers the fault response.

Temporal redundancy: Key operations are re-executed with a time offset to defeat synchronized glitch attacks that affect both redundant paths simultaneously.

Infection countermeasures: When a fault is detected, the output is randomized before any error signal is raised — preventing the attacker from observing the faulted output even if the detection signal arrives late. The randomized "infected" output is cryptographically useless.

Fault response: On fault detection, the core immediately triggers key zeroization (if DYBER-KMU is present), raises a hardware interrupt to the host CPU, and locks the accelerator until a reset sequence is performed. The response is configurable: alert-only, alert + lock, or alert + lock + zeroize.

Key Isolation & Zeroization #

Private key material is the most sensitive asset in any cryptographic system. Dyber's architecture enforces hardware-level isolation guarantees:

Bus isolation: Private keys stored in the key buffer or DYBER-KMU are accessible only to the internal algorithm pipeline. There is no register-mapped read path from the AMBA bus to the key buffer — it is physically impossible for the host CPU to read back key material through the bus interface, regardless of software privilege level.

Memory isolation: Key buffers use dedicated BRAM instances that are not shared with coefficient memory, twiddle factor ROM, or any other data structure. In ASIC implementations, the key buffer region can be placed in a physically isolated memory block with independent power and tamper monitoring.

Zeroization: Hardware-guaranteed key destruction that overwrites key memory with random data (from DYBER-QRNG or a LFSR), then verifies the overwrite by read-back comparison. Zeroization completes within a bounded number of clock cycles and is formally verified using SVA assertions. Three trigger modes: software command (explicit key delete), tamper signal (external tamper mesh detection), and power-down (voltage monitor triggers zeroization before SRAM contents become readable during power ramp-down).

Security Boundary Definition #

For FIPS 140-3 certification, a clear security boundary must be defined separating the cryptographic module from the rest of the system. Dyber provides pre-documented boundary definitions for each IP core and common integration configurations:

Dyber provides the security boundary documentation, self-test implementations, and Known Answer Test (KAT) vectors required for FIPS certification. The certification submission itself is a joint effort between Dyber and the integrator, as the final module boundary depends on the specific SoC integration.

Certification Support #

Threat Model #

Dyber's security architecture is designed to resist the following attacker capabilities:

Security Verification #

Dyber employs multiple verification methodologies to confirm that security properties hold in the actual hardware implementation:

Formal verification: SVA (SystemVerilog Assertion) properties formally prove that secret-dependent branching never occurs, key material never appears on external bus interfaces, and zeroization completes within bounded cycles. These properties are verified using commercial and open-source formal solvers.

TVLA evaluation: Power trace analysis using the Test Vector Leakage Assessment methodology. Fixed-vs-random t-test evaluations at first order confirm no statistically significant leakage. Evaluation reports are provided with DYBER-MASK deliverables.

Constant-time analysis: Automated tooling verifies that no secret-dependent multiplexer control signals, memory addresses, or branch conditions exist in the synthesized netlist. This analysis runs on the post-synthesis gate-level netlist to catch tool-introduced timing dependencies.

NIST KAT validation: All algorithm implementations are validated against the complete NIST Known Answer Test vector sets. Every RTL revision is regression-tested against KAT vectors before release.