← Latest papers
💻 computer science

Granite: A Modular Methodology for Foundational Verification of Hardware-Software Leakage Contracts

Granite introduces a modular, foundational methodology that verifies both functional correctness and non-leakage of RTL processors by establishing trace equivalence with deterministic ISA leakage contracts, thereby enabling the composition of hardware and software proofs to eliminate intermediate specifications from the trusted computing base.

Original authors: Stella Lau, Andres Erbsen, Adam Chlipala

Published 2026-07-31
📖 7 min read🧠 Deep dive

Original authors: Stella Lau, Andres Erbsen, Adam Chlipala

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are building a super-fast race car. You want it to be incredibly quick, so you add turbochargers, predictive steering, and a system that guesses which turn you'll take next. But there's a catch: if the car's engine makes a specific "clunk" sound only when you are turning left, a sneaky spy listening from the sidelines could figure out your entire route just by the noise. In the world of computer chips, this is called a "timing side channel." For years, programmers tried to write code that took the exact same amount of time no matter what secret data it was handling, like a spy trying to walk through a hallway without making a sound. But as chips got faster and smarter, they started making tiny, unpredictable noises—like a sudden pause to check a mirror or a burst of speed—that accidentally revealed secrets. This paper tackles the terrifying idea that even if your code is perfect, the hardware itself might be leaking your secrets through the very rhythm of its heartbeat.

The researchers behind this work, known as Granite, have built a new way to mathematically prove that a computer chip is keeping its secrets safe. They didn't just guess or run tests; they created a rigorous, step-by-step mathematical argument that connects the high-level rules of how a computer should behave (the "Instruction Set") all the way down to the tiny wires and transistors (the "RTL"). Their main finding is a method to prove that a chip's timing is determined only by things that are allowed to be public, like which button was pressed, and never by the secret data it's processing, like a password or an encryption key. They explicitly rule out the idea that you can just trust a chip because it looks right or because it passed standard tests; they show that without this specific kind of proof, hidden leaks are almost guaranteed to exist. They are not just suggesting this works; they have formally proved it for a processor design that was successfully synthesized for an FPGA, though it was not yet integrated into a full system-on-chip for post-synthesis testing.

The Great Chip Detective Story

Think of a computer processor as a bustling, chaotic kitchen in a high-end restaurant. The chefs (the hardware) are preparing meals (running programs) for customers. The "Instruction Set Architecture" (ISA) is the menu and the recipe book. It tells the kitchen, "If you get an order for a burger, you must eventually serve a burger." But the menu doesn't say how long it takes to make the burger, or when the chef grabs the knife.

In the old days, chefs were told to be "constant-time." This meant they had to chop vegetables at the exact same speed whether the customer was ordering a salad or a steak, so a spy watching from the window couldn't tell what was being cooked by the rhythm of the chopping. But then, the kitchen got too fast. Chefs started using "speculation"—they would guess what the customer wanted and start chopping onions before the order was even confirmed. If they guessed wrong, they'd throw the onions away and start over. This guessing game created new, accidental noises: the time it took to realize a mistake, or the time it took to grab a specific spice, started leaking information. A spy could listen to the kitchen and deduce, "Ah, the chef hesitated for 0.0001 seconds; they must have been cooking something with secret onions!"

Enter Granite, the ultimate kitchen inspector. Granite doesn't just watch the chefs; it rewrites the rules of the kitchen to make sure no secrets can escape through the timing of the chopping.

The Magic of the "Shadow Chef"

The genius of Granite lies in a clever trick involving a "Shadow Chef." Imagine you have the real chef, who knows all the secret recipes (the secret data). You also have a shadow chef who is blindfolded and only knows the public parts of the order (the public data).

Granite's method says: "We will prove that the real chef and the shadow chef move in perfect lockstep." If the real chef takes 5 seconds to chop an onion because the onion was big, the shadow chef must also take exactly 5 seconds, even though the shadow chef doesn't know the onion was big. The shadow chef's timing is driven only by the public order. If the real chef's timing ever depends on a secret (like the type of onion), the two chefs will fall out of sync, and the proof will fail.

To make this work, Granite introduces a "Driver" and a "Witness."

  • The Driver is like a metronome that only listens to the public order. It decides when the kitchen should move forward, ensuring that the timing of the kitchen's actions is dictated only by what the customer wants to be known, not by the secret ingredients.
  • The Witness is a placeholder for the messy, unpredictable parts of the kitchen (like a random delay because a pan was hot). The Witness says, "Okay, we don't care exactly what happens here, as long as it doesn't depend on the secret."

By proving that the real kitchen behaves exactly like a kitchen run by the Driver and the Witness, Granite proves that the kitchen's rhythm (timing) cannot possibly reveal the secret ingredients.

The Modular Puzzle

One of the hardest parts of checking a whole kitchen is that it's too big to look at all at once. Granite solves this by breaking the kitchen into small, independent stations: the chopping station, the grilling station, the plating station.

Granite proves that each station is safe on its own. For example, the "Multiplier" station (which does math) is checked to ensure that if it takes longer to multiply two numbers, it's only because the numbers were zero (which is allowed to be known), not because of some secret value. Once every single station is proven safe, Granite snaps them together like Lego bricks. Because the proof is "modular," if you swap out the grilling station for a faster one, you don't have to re-check the whole kitchen; you just check the new station, and the whole system remains safe.

The Final Verdict

The researchers didn't just talk about this; they built a processor design and ran their proof on it. They took a piece of software that was already known to be "constant-time" (a cryptographic program called Salsa20) and proved that when it runs on their processor design, it leaks absolutely no secrets through timing.

This is a big deal because it changes what you need to trust. Usually, you have to trust a complex contract between the software and the hardware. Granite shows that if you connect their hardware proof with a verified software proof, the hardware-software contract itself can be eliminated from the trusted list. However, the proof still relies on a few core components, such as the formal definition of the Instruction Set contract and the tool that translates the code into hardware description, which remain in the "Trusted Computing Base." They even found a bug in their own design: they realized that writing to certain control switches (CSRs) could leak information, and they fixed it before the proof was complete.

In short, Granite is a new way to build computer chips that are mathematically guaranteed to keep their secrets, even when they are running fast, guessing, and making noise. It turns the chaotic, noisy kitchen of modern computing into a silent, secret-keeping fortress, proving that you can have speed and security at the same time.

Drowning in papers in your field?

Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.

Try Digest →