Securing Cryptographic Software via Typed Assembly Language (Extended Version)

2025-09-10

AI Summary

Speculative execution attacks (e.g., Spectre) enable leakage of stack-resident secret data in cryptographic software; existing source-level mitigations struggle to precisely track secret flows within the stack and often incur substantial performance overhead. This paper proposes a stack isolation scheme built upon the typed assembly language Octal: leveraging compile-time static type inference to automatically identify secret data, it drives assembly-level rewriting to enforce strict spatial separation between secret and public data on the stack—thereby guaranteeing constant-time execution. Our approach overcomes the limitations of source-level annotations in modeling stack memory, enabling fine-grained, low-overhead security hardening. Evaluation across multiple mainstream cryptographic libraries shows an average performance overhead of only 1.2%, significantly outperforming prior solutions. To the best of our knowledge, this is the first work to achieve both efficiency and formally verifiable security for speculative-execution-aware cryptographic implementations.

Technology Category

• Machine Learning: Hardware-aware ML
• Constraint Satisfaction and Optimization: Satisfiability Modulo Theories
• Application Domains: Security

Application Category

• Security and Privacy: Applications of cryptography
• Responsible Web: Data and user privacy-enhancing technologies for the Web
• Search and Retrieval-Augmented AI: Vertical and domain-specific search

Abstract

Authors of cryptographic software are well aware that their code should not leak secrets through its timing behavior, and, until 2018, they believed that following industry-standard constant-time coding guidelines was sufficient. However, the revelation of the Spectre family of speculative execution attacks injected new complexities. To block speculative attacks, prior work has proposed annotating the program's source code to mark secret data, with hardware using this information to decide when to speculate (i.e., when only public values are involved) or not (when secrets are in play). While these solutions are able to track secret information stored on the heap, they suffer from limitations that prevent them from correctly tracking secrets on the stack, at a cost in performance. This paper introduces SecSep, a transformation framework that rewrites assembly programs so that they partition secret and public data on the stack. By moving from the source-code level to assembly rewriting, SecSep is able to address limitations of prior work. The key challenge in performing this assembly rewriting stems from the loss of semantic information through the lengthy compilation process. The key innovation of our methodology is a new variant of typed assembly language (TAL), Octal, which allows us to address this challenge. Assembly rewriting is driven by compile-time inference within Octal. We apply our technique to cryptographic programs and demonstrate that it enables secure speculation efficiently, incurring a low average overhead of $1.2%$.

Problem

• Securing cryptographic software against speculative execution attacks like Spectre
• Tracking and partitioning secret versus public data on the stack
• Addressing performance overhead and semantic loss in assembly rewriting

Innovation

• Uses assembly rewriting to partition secret and public data
• Introduces typed assembly language variant Octal for semantic recovery
• Employs compile-time inference within Octal to drive transformation