Implementation-Level Provable Security

• Implementation-level provable security is a framework that provides formal security guarantees for concrete artifacts, bridging the gap between abstract models and real-world attacks.
• It employs methodologies such as symbolic execution, concurrent separation logic, and runtime attestation to verify both structural verifiability and behavioral consistency.
• Practical implementations integrate performance metrics and overhead evaluations, ensuring that security proofs align with measurable cost and efficiency trade-offs.

Implementation-level provable security designates security arguments that are attached to concrete implementations—assembly code, protocol implementations, RTL, deployed communication systems, or inference-time architectures—rather than only to algorithmic or symbolic models. The formulation is explicit in “Beyond Algorithmic Proofs: Towards Implementation-Level Provable Security” (Shang et al., 2 Aug 2025), which models an implementation as $$\Pi=(\mathrm{KeyGen},\mathrm{Encrypt},\mathrm{Decrypt},\mathrm{Erase},\mathrm{Check})$$, requires both Structural Verifiability and Behavioral Consistency, and states the target guarantee as

$$\forall \text{ PPT }\mathcal{A}, \exists \text{ PPT }\mathcal{B}\text{ such that } Adv_{\mathcal{A}}(\lambda)\le Adv_{\mathcal{B}}(\lambda)+negl(\lambda).$$

Earlier and parallel work applies the same orientation to software side-channel countermeasures, security-protocol implementations, low-trust architectures, industrial control systems, practical quantum communication, and frozen LLMs (Rauzy et al., 2015).

1. From abstract proofs to concrete artifacts

A recurring motivation is the gap between proofs about models and attacks on implementations. In the side-channel setting, the discrepancy is stated directly: the failure is caused by formal methods’ focus on models rather than implementations, and the proposed remedy is to work on the latter rather than on a high-level model (Rauzy et al., 2015). In security protocols, much existing work is said to focus on the verification of protocol models, which is not sufficient to show that their implementations are actually secure; the proposed alternative is modular verification directly on the level of the protocol implementations (Arquint et al., 2022). In QKD, implementation security is defined as the difficulty of meeting the requirements of mathematical security proofs in real-life QKD systems (Zapatero et al., 2023).

The same pattern appears in systems and hardware. “Security Verification of Low-Trust Architectures” (Tan et al., 2023) treats the ISA as both an abstraction of the hardware for software reasoning and a specification for the hardware, then derives proof obligations that cover both functional and digital side-channel leakage. “Towards Provable Security in Industrial Control Systems Via Dynamic Protocol Attestation” (Amorim et al., 2024) shifts the focus from individual component trust to protocol conformance enforced at run time, even if an adversary compromises a component. In anonymous communication, “Provable Security for the Onion Routing and Mix Network Packet Format Sphinx” (Scherer et al., 2023) argues that the previously-used DDH assumption is insufficient and that GDH is required instead, so even the security foundation of a widely deployed packet format had to be reworked.

Taken together, these works reject the premise that a proof for an abstract cryptographic object automatically transfers to a deployment. This suggests that implementation-level provable security is less a single proof style than a program of aligning formal claims with the exact layer at which attacks are realized.

2. Formal structures and security claims

The most characteristic feature of implementation-level work is that the formal object is the implemented artifact itself. In the DPL assembly approach, security is defined under a leakage model $$\mathcal{L}(v\to v')=\mathrm{HammingDistance}(v,v')$$, and a program is balanced when the sequence of update events does not depend on sensitive data and every relevant Hamming distance is independent of that data; equivalently,

$$\forall s_1,s_2,\; \mathrm{LeakTrace}(P(s_1))=\mathrm{LeakTrace}(P(s_2)).$$

Correctness is not stated as an abstract functionality theorem but as a simulation between the original code and its DPL-transformed variant:

$$\forall S,S'.\; S\vdash c\Rightarrow S' \Rightarrow dpl(S)\vdash c'\Rightarrow dpl(S').$$

The resulting theorem states both semantic preservation and leakage-balance for the transformed assembly program (Rauzy et al., 2015).

At the ISA level, the Sequestered Encryption architecture formalizes low-equivalence and proves a noninterference theorem for any well-typed program $p$: if two initial states are low-equivalent and both executions terminate, then the final states remain low-equivalent and the total execution times are equal. The security goals are “No direct disclosure” and “No side-channel leakage,” instantiated as no secret-dependent variation in instruction stream, address stream, or execution timing (Tan et al., 2023).

The recent CIV architecture for LLMs makes the noninterference form even more explicit. Its Theorem 1 states deterministic, cross-position non-interference: for any positions $p,q$ with $T_p<T_q$, the final hidden state $H_q^{(N)}$ is independent of the embedding $e_p$, written

$$\forall \text{ PPT }\mathcal{A}, \exists \text{ PPT }\mathcal{B}\text{ such that } Adv_{\mathcal{A}}(\lambda)\le Adv_{\mathcal{B}}(\lambda)+negl(\lambda).$$0

The security model couples that theorem to cryptographic authenticity of provenance labels, using HMAC-SHA-256 and a source-trust lattice enforced inside the transformer by a pre-softmax hard attention mask (Gupta, 12 Aug 2025).

Other domains use different but structurally similar notions. Practical QSDC expresses security via Wyner’s wiretap channel and a secrecy-capacity lower bound,

$$\forall \text{ PPT }\mathcal{A}, \exists \text{ PPT }\mathcal{B}\text{ such that } Adv_{\mathcal{A}}(\lambda)\le Adv_{\mathcal{B}}(\lambda)+negl(\lambda).$$1

with reliability and security obtained by choosing a coding rate below $$\forall \text{ PPT }\mathcal{A}, \exists \text{ PPT }\mathcal{B}\text{ such that } Adv_{\mathcal{A}}(\lambda)\le Adv_{\mathcal{B}}(\lambda)+negl(\lambda).$$2 (Qi et al., 2018). Protocol implementation verification expresses agreement, secrecy, and forward secrecy as trace properties over ghost events and prefixes (Arquint et al., 2022). The common feature is that the theorem is bound to an implementation semantics, a hardware abstraction, a trace discipline, or a measured communication channel rather than to an uninstantiated scheme.

3. Verification methodologies and proof machinery

Implementation-level proofs rely on verification machinery that can track concrete state evolution. For security protocols, the modular methodology of (Arquint et al., 2022) uses concurrent separation logic, a single shared ghost data structure called the global trace, a ghost lock, and per-thread local snapshots that are always prefixes of the global trace. All protocol-specific invariants are collected into a single global trace invariant $$\forall \text{ PPT }\mathcal{A}, \exists \text{ PPT }\mathcal{B}\text{ such that } Adv_{\mathcal{A}}(\lambda)\le Adv_{\mathcal{B}}(\lambda)+negl(\lambda).$$3, and verification of each thread reduces to showing that every trace-appending operation preserves $$\forall \text{ PPT }\mathcal{A}, \exists \text{ PPT }\mathcal{B}\text{ such that } Adv_{\mathcal{A}}(\lambda)\le Adv_{\mathcal{B}}(\lambda)+negl(\lambda).$$4. The framework is instantiated for Go with Gobra and for C with VeriFast, with reusable wrappers for send, recv, CreateNonce, Hash, Encrypt, and Decrypt.

For MPC with active security, the EasyCrypt development of Maurer’s protocol reduces security arguments to proofs about program equivalence. The passive case establishes that the non-interference-based definition is equivalent to the standard simulator-based notion, while the active case introduces “input independence” for the first phase of the protocol and combines it with correctness and output simulation. The proof engineering is built around pRHL/equivalence lemmas, abstract adversary modules, extraction of the adversary’s committed input, and explicit functionals such as finalmsg (Haagh et al., 2018).

For ICS protocol conformance, the F* development in (Amorim et al., 2024) embeds a DSL with Skip, Seq, If, and EC commands, proves the main safety lemma as an F* Lemma, and then uses a run-time proxy that maintains both the current state $$\forall \text{ PPT }\mathcal{A}, \exists \text{ PPT }\mathcal{B}\text{ such that } Adv_{\mathcal{A}}(\lambda)\le Adv_{\mathcal{B}}(\lambda)+negl(\lambda).$$5 and an IntCom witness $$\forall \text{ PPT }\mathcal{A}, \exists \text{ PPT }\mathcal{B}\text{ such that } Adv_{\mathcal{A}}(\lambda)\le Adv_{\mathcal{B}}(\lambda)+negl(\lambda).$$6. On each external command, the proxy invokes the decider is_trace, advances the state on success, and otherwise rejects the command and invokes a safe fail-safe RPC.

For RTL-level leakage checking, the SE verification workflow isolates the enclaved RTL and discharges information-flow obligations using Cadence JasperGold Security Path Verification. Secret sources include decrypted-plaintext register bits and the enclave key register; sinks include the data output bus and the valid pin; ciphertext is handled by conditional declassification through not_through constraints. The proof target is a no-flow result or, in buggy variants, a counterexample trace (Tan et al., 2023).

The assembly-level DPL work occupies a similar position at a lower abstraction level. Its OCaml interpreter symbolically tracks sets of possible register and memory values, computes all possible Hamming distances for each instruction, and fails if more than one distinct distance occurs (Rauzy et al., 2015). This suggests a methodological spectrum: separation logic and ghost traces for concurrent code, relational program logics for cryptographic protocols, theorem-prover embeddings plus monitors for cyber-physical conformance, symbolic information-flow tooling for RTL, and symbolic execution over leakage models for assembly.

4. Representative implementations across layers

The breadth of the topic is visible in the implemented artifacts to which proofs are attached.

Domain	Implemented artifact	Security form
Side-channel software	DPL-transformed assembly for PRESENT on an 8-bit AVR smartcard	constant activity under Hamming-distance leakage
Protocol software	Go and C implementations of Needham-Schroeder-Lowe, Diffie-Hellman, and WireGuard	memory safety, secrecy, forward secrecy, injective agreement
Low-trust hardware	SE ISA and seven RTL variants	no direct disclosure and no digital side-channel leakage
ICS control	F*-specified protocol plus C++ proxy on Fischertechnik HBW	protocol conformance that prevents unsafe actions
Quantum communication	1 MHz plug-and-play QSDC over 1.5 kilometers	secrecy capacity and direct communication security
LLM inference	CIV patch for Llama-3-8B-Instruct and Mistral-7B	deterministic per-token non-interference

In the DPL case study, the workflow is concrete: hand-craft a bitsliced PRESENT, translate to the tool’s assembly language, profile the chip to select the best rails, run the OCaml tool to expand Boolean instructions into DPL macros and aligned lookup tables, verify balance by symbolic execution, and map back to real AVR instructions (Rauzy et al., 2015). In protocol verification, the artifact is existing Go or C code, not generated code, and the methodology is explicitly described as language-agnostic (Arquint et al., 2022). In the SE architecture, the claim is for all possible programs over the ISA, with the ISA serving simultaneously as software abstraction and RTL specification (Tan et al., 2023). In ICS, the guarantee is enforced at run time by protocol attestation rather than by full-system verification (Amorim et al., 2024).

The same implementation orientation extends to communication systems. The practical QSDC system combines a 1550 nm source, a phase-coding Mach–Zehnder interferometer, LiNbO₃ phase modulators, InGaAs/InP single-photon detectors, FPGA control, and a coding stack based on pseudo-random repetition, LDPC, and universal hashing, with security instantiated from measured parameters in Wyner’s model (Qi et al., 2018). CIV applies the pattern to frozen LLMs by inserting a small CIVDecoderLayer, extending the KV-cache to hold trust vectors, verifying HMAC-based provenance labels on every layer invocation, and enforcing a hard trust mask before softmax (Gupta, 12 Aug 2025).

This diversity is significant because the topic is not restricted to one attack class. It covers leakage, memory safety, authentication, protocol conformance, information-flow control, anonymity packet formats, and physical-layer communication security, provided that the proof is stated at the layer where the implementation can actually fail.

5. Cost, performance, and measured effect

Implementation-level guarantees are usually accompanied by explicit overhead and empirical evidence. In the AVR PRESENT case study, code size changes from 1620 B → 3056 B (×1.88), RAM use from 288 B → 352 B (+64 B for LUTs), and cycle count from 78 403 → 235 427 (×3.0). The side-channel effect is also quantified: the unprotected implementation breaks with a univariate CPA in ≈400 plain-cipher traces, whereas DPL with rails on bits 1&2 is said to be ≈4 800 traces under the cheating attacker, and did not break up to 100 000 traces under a realistic attacker; overall, the protected code is ≳250× harder to attack in data-complexity (Rauzy et al., 2015).

In the ICS proxy setting, the measured cost over 30 s of random valid RPCs is 0.1452 ± 0.0007 ms average latency without attestation versus 0.1903 ± 0.0007 ms with attestation, with throughput changing from 191 250 to 145 054 msg/s and from 3 060 to 2 321 KB/s. The paper summarizes this as latency increase ≈31 % and message throughput decrease ≈32 % (Amorim et al., 2024).

In low-trust hardware verification, the cost appears in proof time and memory. For the correct RTL implementations, all proofs succeeded in < 0.2 s each; the summary reports secure variants with no-flow proofs in 0.1 s, ≤ 1.6 GB RAM, while vulnerable implementations yielded counterexamples in 0.1–402 s, up to 14.7 GB RAM (Tan et al., 2023).

Practical communication systems exhibit a different trade-off. The QSDC prototype uses a 1 MHz pulse rate over 1.5 km fiber, with Q_B≈3×10⁻³, e≈0.6%, e_x≈e_z≈0.8%, Cs≈1.84×10⁻³ bit/pulse, a chosen coding rate R_total≈9.6×10⁻⁴ bit/pulse, and secure message throughput ≈50 bps (Qi et al., 2018). CIV reports 0% [ASR](https://www.emergentmind.com/topics/adaptive-sampling-refinement-asr) on both suites, 0% FPR, Sim 93.1%, [PPL](https://www.emergentmind.com/topics/pre-pipeline-ppl) Δ < 0.01%, Lat 9.2 s (+109%), compared with a baseline ≈4.4 s/query (Gupta, 12 Aug 2025).

A plausible implication is that implementation-level provable security rarely comes without cost, but the cost is often reported in the same formal and experimental frame as the security claim. That coupling is one of the distinctive marks of the area.

6. Limits, controversies, and open directions

The literature is explicit that implementation-level proofs remain conditional. CIV assumes an untampered software/hardware stack and secrecy of the HMAC key $$\forall \text{ PPT }\mathcal{A}, \exists \text{ PPT }\mathcal{B}\text{ such that } Adv_{\mathcal{A}}(\lambda)\le Adv_{\mathcal{B}}(\lambda)+negl(\lambda).$$7; it does not address same-tier attacks or side-channels, and strict non-interference can break workflows that intentionally intermix SYSTEM+USER content without refactoring (Gupta, 12 Aug 2025). The modular protocol-verification methodology relies on the soundness of the separation-logic verifier and on cryptographic axioms such as perfect encryption/decryption and no collisions; it also requires manual trace invariants, and the annotation burden is described as roughly 4–10× the code size (Arquint et al., 2022).

In cyber-physical settings, dynamic attestation does not provide liveness or timeliness guarantees, assumes fail-safe commands are always safe, and can impose too much overhead in ultra-low-latency contexts (Amorim et al., 2024). In low-trust hardware, the root of trust is limited but still assumed: the enclave key-register and TRNG are assumed correct and untampered, and the attacker cannot observe internal enclave state (Tan et al., 2023). In QKD, composable proofs still depend on device-model assumptions, and the review enumerates concrete vulnerabilities including detection-efficiency mismatch, detector blinding, Trojan-horse attacks, state-preparation flaws, intensity fluctuations, pulse correlations, and malicious equipment (Zapatero et al., 2023).

There are also foundational controversies. For Sphinx, flaws in the underlying proof strategy forced a change from DDH to GDH and a slight adaptation of the packet format; the paper states that its adaptations are necessary and demonstrates an attack on sender privacy that would be possible otherwise (Scherer et al., 2023). In side-channel software protection, the DPL case study notes future directions that include combining DPL with random masking, formally verifying the assembly-to-machine mapping, and automating bitslicing (Rauzy et al., 2015). The ILPS manifesto extends this trajectory by calling for end-to-end formally verified chains “from hardware roots (TPM) through to user-level application” (Shang et al., 2 Aug 2025).

These limitations do not negate the topic; they define it. Implementation-level provable security does not eliminate assumptions, but relocates them to the concrete mechanisms—register writes, ghost traces, RPC streams, RTL signals, detector models, provenance labels, key erasure routines, and timing envelopes—through which deployed systems actually succeed or fail.