Why Does ASN.1 Need Formal Verification?

In safety-critical systems, bugs in communication protocol implementations can produce incorrect encodings or silent decoding errors that a finite test suite may not catch. ASN.1 (Abstract Syntax Notation One) is an international standard for describing data structures independently of any programming language or platform.¹ You define your types once (integers, strings, sequences, enumerations). A separate set of encoding rules then determines how those types map to bytes on the wire.

A simple definition looks like this:

Temperature ::= INTEGER (0..100)

This says Temperature is an integer constrained to the range 0–100. The encoding rules then pack that value into as few bits as possible.

The encoding rules used in this thesis are uPER (Unaligned Packed Encoding Rules). uPER is compact, which makes it a natural fit for embedded systems and satellite communication where bandwidth is limited. The European Space Agency uses ASN.1 with uPER for telemetry and telecommand data between spacecraft and ground stations.

What Is ASN1SCC?

Writing encoders and decoders by hand for every type in a specification is tedious and error-prone. The ESA developed ASN1SCC to automate this: an open-source compiler that takes an ASN.1 specification as input and generates the corresponding encoding and decoding code.² It supports C, Ada, and Scala, with a Python backend under active development.

Given the Temperature definition above, ASN1SCC generates a Python class with encode and decode methods. Using them looks roughly like this:

encoder = UPEREncoder.of_size(1)
val = Temperature(42)
val.encode(encoder)
data = encoder.get_bitstream_buffer()

decoder = UPERDecoder.from_buffer(data)
result = Temperature.decode(decoder)
# Is result == val?

The question my thesis set out to answer: can we prove that result == val holds for every valid input, not just the ones we happened to test?

Why Testing Alone Isn’t Enough

Tests are the standard answer. Write inputs, check outputs, add edge cases. Done carefully, this catches a lot of bugs.

But tests only cover the cases you thought to write. A Temperature value of 42 passes. What about 127? What about 128, where the bit-packing crosses a byte boundary? What about the exact edges of the constraint range? What about a complex nested structure with a dozen fields, where the encoder for each field must leave the stream in exactly the right state for the next one?

Formal verification is a different game. You write a mathematical statement about what the code must do for all inputs, and a tool proves or disproves it automatically. No enumeration of cases.

What I Set Out to Prove

The property I focused on is round-trip correctness:

For all valid inputs, decoding the output of an encoder recovers the original value.

Formally: $\forall x . decode(encode(x)) = x$

The proof is scoped to valid inputs: the precondition requires constraint-satisfying values on the encoder side and a well-formed buffer on the decoder side. It says nothing about how the decoder handles malformed input from an untrusted source. But within that scope it gives a precise, unconditional correctness statement: the encoder cannot silently corrupt a value, and the decoder cannot misread what the encoder wrote.

Nagini: Formal Verification for Python

The verifier I used is Nagini, a static analysis tool for Python developed by Marco Eilers at ETH Zurich.³ Nagini lets you annotate Python functions with preconditions and postconditions, then uses an SMT solver to prove those statements hold for every possible execution. Under the hood it translates Python to Viper, an intermediate verification language.⁴

An annotated encode function looks like this:

def encode(self, codec: UPEREncoder) -> None:
    Requires(self.is_constraint_valid())
    Ensures(codec.segments == Old(codec.segments) + segments_of(self))
    # ... implementation ...

Requires is the precondition: the value being encoded must satisfy its constraints. Ensures is the postcondition: the encoder’s state has been extended by exactly the segments representing this value. Once Nagini accepts this, no test needs to cover that contract. It holds unconditionally.

The Segment Abstraction

Encoding writes bits into a shared byte buffer. A single write can span two bytes, and you need to reason precisely about which bits changed and which didn’t. Tracking this at the bit level throughout the whole proof would be unmanageable.

The approach I used is a three-layer architecture. The bottom two layers handle actual bit manipulation: individual bits within a byte, then multi-bit writes across the full buffer. Above those sits a segment abstraction used purely for verification. Instead of tracking which bits changed, each write is recorded as a (value, length) pair called a segment.

Once the bottom layers are proved correct, the segment abstraction guarantees that the sequence of segments corresponds exactly to the buffer contents. Encoder and decoder proofs then work entirely with segments, without bit arithmetic. That separation is what makes the round-trip proofs tractable, and it distinguishes this approach from the bit-list intermediate representation used in the prior Scala verification work.⁵

I’ll cover the segment abstraction and compositional proof structure in more detail in a follow-up post.

What Was Formally Verified

The first component verified was BitStream, the core data structure shared by all generated codecs. The verification establishes absence of runtime errors (index out-of-bounds, overflow) and full functional correctness of all read and write operations: each written value is correctly retrieved by a subsequent read, and previously written data is unchanged. Everything else rests on this.

Building on BitStream, six ASN.1 types were proved to have round-trip correctness under uPER:

• BOOLEAN
• NULL
• ENUMERATED
• INTEGER (constrained range)
• OCTET STRING (fixed size)
• SEQUENCE (with fixed-size, non-optional fields)

Types like SEQUENCE OF, CHOICE, BIT STRING, and REAL were not verified. Most follow the same proof pattern and are primarily a matter of implementing type-specific auxiliary functions. REAL is the exception: it requires further development in Nagini’s floating-point support before it can be tackled at the codec level.

The Cost: Annotation Overhead

Formal verification is not free. Proofs require writing specifications alongside the implementation. Across the verified runtime files, annotation lines account for 39.9% of the codebase: 1,636 specification lines alongside 2,461 lines of implementation.

The distribution is uneven by design. bitstream.py, which establishes the segment abstraction at the byte-sequence level, has more specification than implementation (68% annotation overhead). The encoder and decoder, working at the segment level rather than at the bit level, need far less: 12.6% and 13.5% respectively. The annotation burden concentrates at the foundation, so the higher-level proofs stay comparatively lightweight.

segment.py and verification.py consist entirely of specification code with no runtime counterparts; they exist solely to support the proof.

The generated data classes sit at 54% specification, since each class needs its own postconditions and helper lemmas. That’s the cost of annotating code you didn’t write.

Two Bugs Found Before Running the Prover

Writing formal specifications sometimes finds bugs before the prover even runs. Precisely stating what the code should do exposes gaps between that and what it actually does. Two bugs turned up in the ASN1SCC Python backend this way:

1. The is_constraint_valid check for INTEGER was missing the lower bound of zero, accepting negative values as valid.
2. The is_constraint_valid check for OCTET STRING did not enforce the fixed-size constraint, accepting arrays of any length.

Both were caught just from writing the specification, before running a single proof.

How I Extended Nagini

The verification also required extending Nagini to handle Python features it couldn’t verify before:

• bytearray: a mutable heap-allocated type, modelled as a Seq[Int] in Viper with a permission predicate governing access, plus a pure PByteSeq counterpart for use in specifications
• Shift operators (<< and >>): encoded via integer arithmetic, since SMT integers don’t support bitwise shifts directly; left shift by k becomes multiplication by 2^k, resolved through a case distinction over the shift amount
• Dataclasses: @dataclass-decorated classes with implicit __init__, supporting frozen and non-frozen forms and factory defaults
• IntEnum: integer-backed enumerations, encoded with boxing/unboxing functions that enforce the set of valid values at the type level

Beyond new features, six crashes and three soundness issues in Nagini were identified and reported to the issue tracker, each with a minimal reproducing test case. All were subsequently fixed. One soundness bug was particularly subtle: because a Python integer subclass satisfies A(5) == 5, Nagini was misled into accepting the trivially false assertion assert 2 == 1 as valid, which I found while writing tests that were supposed to fail.

I’ll cover these extensions in more detail in a follow-up post.

Artifacts and Prior Work

The full thesis is available on the completed projects page of the Programming Methodology Group at ETH Zurich. Changes to Nagini have been committed to the Nagini repository directly. ASN1SCC is open source on GitHub.

This work builds on a prior project that applied the same round-trip verification approach to ASN1SCC’s Scala backend.⁵ The aim was to show the same correctness class is achievable in Python.