Secure Platforms

Secure Platforms https://www.secure-platform.eu/feed.xml Mon, 26 Oct 2026 18:26:10 +0000 What are Application Specific Processors? https://www.secure-platform.eu/hardware/2026/10/26/application-specific-processors.html What application-specific processors are, how they are built from an existing program, and why they are more secure in their domain. Dominik Meyer https://www.secure-platform.eu/hardware/2026/10/26/application-specific-processors.html Mon, 26 Oct 2026 00:00:00 +0000 <p> A processor is the central computing element of any computer, IoT device, or Embedded System. It holds very fast but also very small memory called registers and executes small instructions divided into: </p> <ul> <li>Arithmetic operations on registers (+,-, *, /, or, and, xor, ...)</li> <li>Control Flow Operations (decide where to execute next)</li> <li>Memory Operations (moving data from the registers to main memory and vice versa)</li> <li>Processor Status Operations (managing security features like MMU, Processor Modes).</li> </ul> <p> The register file and the instructions of a processor build its Instruction Set Architecture (ISA). Many Instructions form a program (the Software running on the processor). </p> <p> Processors are built as general-purpose machines, so they can solve any problem, but not always very fast nor very efficient. Also, most programs only use a very small subset of the available instructions and registers. </p> <p> Application Specific Processors (ASPs) have been around in research for a long time. In general, they are optimized or adapted processors for a specific application domain. Domains are full application areas but also just one application. </p> <p> <em>In contrast to typical general-purpose processors they are faster, more efficient, or more secure in their specific application domain.</em> </p> <h2>ASP Categories</h2> <p> Today they divide into two broad categories: </p> <ul> <li><strong>Executing Software</strong> <p> ASPs in this category are sometimes also called Application Specific Instruction Set Processors (ASIPs). These ASPs are based on available/ existing Instruction Set Architectures (ISAs), e.g. RISC-V, x86, or Armv7. Their ISA is extended to support a specific application area better. Typical application areas for these ASPs are</p> <ul> <li>Cryptography</li> <li>Video Encoding/Decoding</li> <li>Vector Calculation</li> </ul> <p> There are two very important points to highlight for this category of processors: </p> <ul> <li><em>The goals of this category of ASPs are computing performance and efficiency.</em></li> <li><em>As every standard processor this category executes software.</em></li> </ul> </li> <li><strong>Pure Hardware</strong> <p> This category of ASPs is very new, and the approach behind it is very different. Instead of extending existing ISAs, this approach generates ASPs from scratch, taking existing ISAs only as a guideline. Even the programs are converted from software to hardware, e.g. as a hardware implemented Finite State Machine (FSM). </p> <ul> <li><em>The goals of this category of ASPs are structural elimination to increase trustworthiness and security</em></li> <li><em>It does <strong>not</strong> run software but executes the application purely in hardware</em></li> </ul> </li> </ul> <h2>ASP Implementation/ Production</h2> <p> Both categories of ASPs have two different implementation or production kinds. </p> <figure class="post-hero"> <img width="80%" src="/Images/asp-implementation.png"> <figcaption> <span class="pill ai-generated"> <svg viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" aria-hidden="true"><path d="M12 2.5l2.1 7.4 7.4 2.1-7.4 2.1-2.1 7.4-2.1-7.4-7.4-2.1 7.4-2.1L12 2.5z"/></svg> AI-generated image </span> </figcaption> </figure> <ul> <li><strong>Application Specific Integrated Circuits (ASICs)</strong> <p> ASICs are the typical way of implementing/ producing hardware. A hardware design, e.g. for a processor, is provided to a chip factory and after some optimization to that specific production process some thousands Integrated Circuits (IC) are produced. </p> <em>Advantages</em> <ul> <li>Cheap per IC for a large amount</li> <li>ICs are able to run at high clock rates</li> </ul> <em>Disadvantages</em> <ul> <li>Expensive for small batches</li> <li>Long production times</li> <li>No updates after production (ICs are fixed)</li> </ul> </li> <li><strong>Field Programmable Gate Arrays (FPGAs)</strong> <p> FPGAs are often used in prototyping. They are specially designed ASICs, which support hardware being configured to it after production. Most of the design steps for ASICs and FPGAs are the same, except the last step, mapping a hardware design to the implementing technology. Most FPGAs can be reconfigured many times. </p> <em>Advantages</em> <ul> <li>Cheap for small batches</li> <li>Fast configuration times (seconds)</li> <li>Reconfigurable, so updates to hardware possible</li> </ul> <em>Disadvantages</em> <ul> <li>More expensive compared to ICs for large batches</li> <li>Limited maximum clock rate (< 1 GHz in general)</li> </ul> </li> </ul> <h2>Pure Hardware ASPs</h2> <p> This article focuses on the second category of ASPs. It will provide an overview on how they are developed, where they can be of use, and how they improve the security and efficiency of computing systems. </p> <h3>From Software to Hardware</h3> <figure class="post-hero"> <img src="/Images/asp-development-flow.png"> <figcaption> <span class="pill ai-assisted"> <svg viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" aria-hidden="true"><path d="M12 2.5l2.1 7.4 7.4 2.1-7.4 2.1-2.1 7.4-2.1-7.4-7.4-2.1 7.4-2.1L12 2.5z"/></svg> AI-assisted image </span> </figcaption> </figure> <p> The image above shows the design flow of a pure hardware ASP. </p> <ol> <li>The development starts with an application written in a high-level programming language like C or C++. Rust might also be a possibility in the future but is not supported right now. <br/> A compiler like <em>GCC</em> or <em>clang</em> compiles all source files of this application to RISC-V assembler files. Assembler code is a human-readable form of a processor's instructions. <div class="split c-asm"> <div class="visual"> <p><span class="pill idle">C</span></p> <div class="code"><pre><code><span class="k">int</span> <span class="f">sum</span>(<span class="k">int</span> *p, <span class="k">int</span> n) { <span class="k">int</span> s = 0; <span class="k">while</span> (n > 0) { s += *p++; n--; } <span class="k">return</span> s; }</code></pre></div> </div> <div class="mid"><span class="pill idle">GCC / CLANG →</span></div> <div class="visual"> <p><span class="pill idle">RISC-V ASSEMBLY</span></p> <div class="code"><pre><code><span class="k">sum:</span> <span class="f">mv</span> a5, zero <span class="c"># s = 0</span> <span class="k">loop:</span> <span class="f">ble</span> a1, zero, end <span class="c"># n > 0?</span> <span class="f">lw</span> t0, 0(a0) <span class="c"># *p</span> <span class="f">add</span> a5, a5, t0 <span class="c"># s += *p</span> <span class="f">addi</span> a0, a0, 4 <span class="c"># p++</span> <span class="f">addi</span> a1, a1, -1 <span class="c"># n--</span> <span class="f">j</span> loop <span class="k">end:</span> <span class="f">mv</span> a0, a5 <span class="f">ret</span></code></pre></div> </div> </div> This step is nothing new and compilers have done it for the past decades. </li> <li> This step is the important one. The tool <em>asm2fsm</em> analyzes the RISC-V assembly. <br/> On a software-based processor a program does not start from zero. Before it starts executing, its initial data has to be moved to main memory. On a PC that is the operating system's job, on an embedded device the startup code. <br/> <em>asm2fsm</em> extracts memory information from all the assembly files and builds a memory layout starting at a given start address. It also removes dead code from the assembly files. Dead code is instructions that the program's normal control flow never reaches. Dead code happens if the program uses only a subset of a library's functions. <br/> The output of this stage is the memory layout and the pure instruction flow of the program. </li> <li> In another step <em>asm2fsm</em> converts the instruction flow into a Finite State Machine (FSM). <figure class="post-hero"> <svg viewBox="0 0 640 552" xmlns="http://www.w3.org/2000/svg" role="img" aria-label="Finite state machine generated from the sum() assembly: eight states, one operation each"> <defs> <linearGradient id="fsmbg" x1="0" y1="0" x2="1" y2="1"> <stop offset="0" stop-color="#11203a"/> <stop offset="1" stop-color="#0b1626"/> </linearGradient> <marker id="arr" viewBox="0 0 10 10" refX="8.5" refY="5" markerWidth="6.5" markerHeight="6.5" orient="auto-start-reverse"> <path d="M0 0L10 5L0 10z" fill="#9AA0A8"/> </marker> </defs> <rect x="0" y="0" width="640" height="552" fill="url(#fsmbg)"/>  <g stroke="#9AA0A8" stroke-width="1.5" fill="none"> <path d="M33 64 H58" marker-end="url(#arr)"/> <path d="M175 88 V121" marker-end="url(#arr)"/> <path d="M175 172 V205" marker-end="url(#arr)"/> <path d="M175 256 V289" marker-end="url(#arr)"/> <path d="M175 340 V373" marker-end="url(#arr)"/> <path d="M175 424 V457" marker-end="url(#arr)"/> <path d="M290 148 H367" marker-end="url(#arr)"/> <path d="M485 172 V205" marker-end="url(#arr)"/> <path d="M485 256 V273" marker-end="url(#arr)"/> <path d="M60 484 H28 V148 H57" stroke-linejoin="round" marker-end="url(#arr)"/> </g>  <circle cx="28" cy="64" r="5" fill="#F2EDE0"/>  <circle cx="485" cy="300" r="21" fill="none" stroke="#9AA0A8" stroke-width="1.5"/> <circle cx="485" cy="300" r="16" fill="none" stroke="#9AA0A8" stroke-width="1.5"/>  <g font-family="ui-monospace, SFMono-Regular, Menlo, Consolas, monospace" fill="#F2EDE0" opacity="0.85"> <text x="185" y="194" font-size="11">a1 > 0</text> <text x="328" y="138" font-size="11" text-anchor="middle">a1 ≤ 0</text> <text x="16" y="316" font-size="10.5" text-anchor="middle" transform="rotate(-90 16 316)">j loop</text> <text x="28" y="46" font-size="10" text-anchor="middle" opacity="0.7">start</text> </g>  <g font-family="ui-monospace, SFMono-Regular, Menlo, Consolas, monospace"> <rect x="60" y="40" width="230" height="48" rx="10" fill="#0f1e36" stroke="rgba(255,255,255,0.18)"/> <text x="72" y="58" font-size="10" fill="#5f7098">S0</text> <text x="175" y="76" font-size="13.5" text-anchor="middle"><tspan fill="#ffd479">a5</tspan><tspan fill="#c6d4ef"> := zero</tspan></text> <rect x="60" y="124" width="230" height="48" rx="10" fill="#0f1e36" stroke="#E0A83C"/> <text x="72" y="142" font-size="10" fill="#5f7098">S1</text> <text x="175" y="160" font-size="13.5" text-anchor="middle"><tspan fill="#ffd479">a1 ≤ 0 ?</tspan></text> <rect x="60" y="208" width="230" height="48" rx="10" fill="#0f1e36" stroke="rgba(255,255,255,0.18)"/> <text x="72" y="226" font-size="10" fill="#5f7098">S2</text> <text x="175" y="244" font-size="13.5" text-anchor="middle"><tspan fill="#ffd479">t0</tspan><tspan fill="#c6d4ef"> := M[a0]</tspan></text> <rect x="60" y="292" width="230" height="48" rx="10" fill="#0f1e36" stroke="rgba(255,255,255,0.18)"/> <text x="72" y="310" font-size="10" fill="#5f7098">S3</text> <text x="175" y="328" font-size="13.5" text-anchor="middle"><tspan fill="#ffd479">a5</tspan><tspan fill="#c6d4ef"> := a5 + t0</tspan></text> <rect x="60" y="376" width="230" height="48" rx="10" fill="#0f1e36" stroke="rgba(255,255,255,0.18)"/> <text x="72" y="394" font-size="10" fill="#5f7098">S4</text> <text x="175" y="412" font-size="13.5" text-anchor="middle"><tspan fill="#ffd479">a0</tspan><tspan fill="#c6d4ef"> := a0 + 4</tspan></text> <rect x="60" y="460" width="230" height="48" rx="10" fill="#0f1e36" stroke="rgba(255,255,255,0.18)"/> <text x="72" y="478" font-size="10" fill="#5f7098">S5</text> <text x="175" y="496" font-size="13.5" text-anchor="middle"><tspan fill="#ffd479">a1</tspan><tspan fill="#c6d4ef"> := a1 - 1</tspan></text> <rect x="370" y="124" width="230" height="48" rx="10" fill="#0f1e36" stroke="rgba(255,255,255,0.18)"/> <text x="382" y="142" font-size="10" fill="#5f7098">S6</text> <text x="485" y="160" font-size="13.5" text-anchor="middle"><tspan fill="#ffd479">a0</tspan><tspan fill="#c6d4ef"> := a5</tspan></text> <rect x="370" y="208" width="230" height="48" rx="10" fill="#0f1e36" stroke="rgba(255,255,255,0.18)"/> <text x="382" y="226" font-size="10" fill="#5f7098">S7</text> <text x="485" y="244" font-size="13.5" text-anchor="middle"><tspan fill="#c6d4ef">return</tspan></text> </g> </svg> </figure> The memory layout is copied in front of the FSM in the form of memory stores. So, before starting the program, the FSM itself moves the required initial data to memory and self-initializes.<br/> Converting the FSM to a hardware description language like VHDL is straightforward for any digital hardware engineer or even an AI today. The description is then merged into a System-on-Chip (SoC) framework which provides required peripherals like memory bus, interrupt management, and input/output. The explanation of a SoC framework is part of a future article. </li> <li>The last step is running the synthesis, placement and routing, and mapping flow of the FPGA or ASIC targeted.</li> </ol> <h3>Advantages</h3> <ul> <li><strong>Structural Elimination</strong> A general-purpose processor runs any program, including one an attacker injects. The ASP runs only the single application it was built for. A buffer-overflow attack works by redirecting the processor to run attacker code, the ASP has no way to start running code it wasn’t built with. There is nothing to land on. </li> <li><strong>No speculative execution</strong> Modern processors guess ahead to run faster, and that guessing is what makes side channels like Spectre possible. The FSM just steps through states in a fixed order — it never guesses, so that class of leak has no mechanism. </li> <li><strong>Determinism</strong> On a processor with an OS, how long an operation takes varies with what else is running. On the ASP the same input always takes the same number of cycles. A real-time deadline is a fixed number, not an average. </li> <li><strong>Efficiency</strong> The post’s intro already said a program uses only a small subset of the available instructions and registers. A general-purpose processor still pays for the whole set, a full register file, a decoder for the entire ISA, a branch unit. The ASP builds only what the application actually uses. Less hardware, less power, less space.</li> </ul> <h3>Some Application Areas</h3> <ul> <li><strong>Cryptographic engines</strong> Cryptographic algorithms are in general fixed and known. The processor just needs to execute them. ASPs can protect against side-channel attacks by providing a constant-time behavior by construction. This supports Smart cards, secure elements, and HSMs. </li> <li><strong>Secure boot</strong> The ASP can be considered as a coprocessor sitting next to a general-purpose processor, similar to a Secure Element (SE) or Trusted Platform Module (TPM) and do additional verification of system initialization step. An ASP might even replace part of the SE or TPM functionality. </li> <li><strong>Military / defense systems</strong> Defense systems must be sovereign and hardened. With an ASP the software stack is the one application itself, no OS to compromise, no general-purpose core to exploit, and a small state machine that can be verified. </li> <li><strong>Autonomous Drone Control</strong> Autonomous drones run a fixed flight-control application far from the operator. That application is exactly one thing: read sensors, compute the control loop, drive the motors. An ASP executes it deterministically, with guaranteed cycle times and no general-purpose code path that could be hijacked, a compromise in the communication or AI software cannot become a takeover of the flight control. </li> </ul> <h2>The publications behind this post</h2> <p> The work behind this post is available in the <a href="/asp-research.html">publications</a>: </p> <ul> <li><a href="/asp-research.html#meyer2019hdl"><em>HDL FSM Code Generation Using a MIPS-based Assembler</em></a>, ISIE 2019</li> <li><a href="/asp-research.html#meyer2021"><em>A Modern Approach to Application Specific Processors for Improving the Security of Embedded Devices</em></a>, IECON 2021</li> <li><a href="/asp-research.html#meyer2026"><em>Hardware-Enabled Sovereignty: Securing Military Systems Through a Novel and Resilient Defense Architecture</em></a>, CyCon 2026</li> <li><a href="/asp-research.html#meyer2026trust"><em>Trustworthiness by Structural Elimination</em></a>, FDL 2026</li> </ul> <p> A processor is the central computing element of any computer, IoT device, or Embedded System. It holds very fast but also very small memory called registers and executes small instructions divided into: </p> <ul> <li>Arithmetic operations on registers (+,-, *, /, or, and, xor, ...)</li> <li>Control Flow Operations (decide where to execute next)</li> <li>Memory Operations (moving data from the registers to main memory and vice versa)</li> <li>Processor Status Operations (managing security features like MMU, Processor Modes).</li> </ul> <p> The register file and the instructions of a processor build its Instruction Set Architecture (ISA). Many Instructions form a program (the Software running on the processor). </p> <p> Processors are built as general-purpose machines, so they can solve any problem, but not always very fast nor very efficient. Also, most programs only use a very small subset of the available instructions and registers. </p> <p> Application Specific Processors (ASPs) have been around in research for a long time. In general, they are optimized or adapted processors for a specific application domain. Domains are full application areas but also just one application. </p> <p> <em>In contrast to typical general-purpose processors they are faster, more efficient, or more secure in their specific application domain.</em> </p> <h2>ASP Categories</h2> <p> Today they divide into two broad categories: </p> <ul> <li><strong>Executing Software</strong> <p> ASPs in this category are sometimes also called Application Specific Instruction Set Processors (ASIPs). These ASPs are based on available/ existing Instruction Set Architectures (ISAs), e.g. RISC-V, x86, or Armv7. Their ISA is extended to support a specific application area better. Typical application areas for these ASPs are</p> <ul> <li>Cryptography</li> <li>Video Encoding/Decoding</li> <li>Vector Calculation</li> </ul> <p> There are two very important points to highlight for this category of processors: </p> <ul> <li><em>The goals of this category of ASPs are computing performance and efficiency.</em></li> <li><em>As every standard processor this category executes software.</em></li> </ul> </li> <li><strong>Pure Hardware</strong> <p> This category of ASPs is very new, and the approach behind it is very different. Instead of extending existing ISAs, this approach generates ASPs from scratch, taking existing ISAs only as a guideline. Even the programs are converted from software to hardware, e.g. as a hardware implemented Finite State Machine (FSM). </p> <ul> <li><em>The goals of this category of ASPs are structural elimination to increase trustworthiness and security</em></li> <li><em>It does <strong>not</strong> run software but executes the application purely in hardware</em></li> </ul> </li> </ul> <h2>ASP Implementation/ Production</h2> <p> Both categories of ASPs have two different implementation or production kinds. </p> <figure class="post-hero"> <img width="80%" src="/Images/asp-implementation.png"> <figcaption> <span class="pill ai-generated"> <svg viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" aria-hidden="true"><path d="M12 2.5l2.1 7.4 7.4 2.1-7.4 2.1-2.1 7.4-2.1-7.4-7.4-2.1 7.4-2.1L12 2.5z"/></svg> AI-generated image </span> </figcaption> </figure> <ul> <li><strong>Application Specific Integrated Circuits (ASICs)</strong> <p> ASICs are the typical way of implementing/ producing hardware. A hardware design, e.g. for a processor, is provided to a chip factory and after some optimization to that specific production process some thousands Integrated Circuits (IC) are produced. </p> <em>Advantages</em> <ul> <li>Cheap per IC for a large amount</li> <li>ICs are able to run at high clock rates</li> </ul> <em>Disadvantages</em> <ul> <li>Expensive for small batches</li> <li>Long production times</li> <li>No updates after production (ICs are fixed)</li> </ul> </li> <li><strong>Field Programmable Gate Arrays (FPGAs)</strong> <p> FPGAs are often used in prototyping. They are specially designed ASICs, which support hardware being configured to it after production. Most of the design steps for ASICs and FPGAs are the same, except the last step, mapping a hardware design to the implementing technology. Most FPGAs can be reconfigured many times. </p> <em>Advantages</em> <ul> <li>Cheap for small batches</li> <li>Fast configuration times (seconds)</li> <li>Reconfigurable, so updates to hardware possible</li> </ul> <em>Disadvantages</em> <ul> <li>More expensive compared to ICs for large batches</li> <li>Limited maximum clock rate (< 1 GHz in general)</li> </ul> </li> </ul> <h2>Pure Hardware ASPs</h2> <p> This article focuses on the second category of ASPs. It will provide an overview on how they are developed, where they can be of use, and how they improve the security and efficiency of computing systems. </p> <h3>From Software to Hardware</h3> <figure class="post-hero"> <img src="/Images/asp-development-flow.png"> <figcaption> <span class="pill ai-assisted"> <svg viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" aria-hidden="true"><path d="M12 2.5l2.1 7.4 7.4 2.1-7.4 2.1-2.1 7.4-2.1-7.4-7.4-2.1 7.4-2.1L12 2.5z"/></svg> AI-assisted image </span> </figcaption> </figure> <p> The image above shows the design flow of a pure hardware ASP. </p> <ol> <li>The development starts with an application written in a high-level programming language like C or C++. Rust might also be a possibility in the future but is not supported right now. <br/> A compiler like <em>GCC</em> or <em>clang</em> compiles all source files of this application to RISC-V assembler files. Assembler code is a human-readable form of a processor's instructions. <div class="split c-asm"> <div class="visual"> <p><span class="pill idle">C</span></p> <div class="code"><pre><code><span class="k">int</span> <span class="f">sum</span>(<span class="k">int</span> *p, <span class="k">int</span> n) { <span class="k">int</span> s = 0; <span class="k">while</span> (n > 0) { s += *p++; n--; } <span class="k">return</span> s; }</code></pre></div> </div> <div class="mid"><span class="pill idle">GCC / CLANG →</span></div> <div class="visual"> <p><span class="pill idle">RISC-V ASSEMBLY</span></p> <div class="code"><pre><code><span class="k">sum:</span> <span class="f">mv</span> a5, zero <span class="c"># s = 0</span> <span class="k">loop:</span> <span class="f">ble</span> a1, zero, end <span class="c"># n > 0?</span> <span class="f">lw</span> t0, 0(a0) <span class="c"># *p</span> <span class="f">add</span> a5, a5, t0 <span class="c"># s += *p</span> <span class="f">addi</span> a0, a0, 4 <span class="c"># p++</span> <span class="f">addi</span> a1, a1, -1 <span class="c"># n--</span> <span class="f">j</span> loop <span class="k">end:</span> <span class="f">mv</span> a0, a5 <span class="f">ret</span></code></pre></div> </div> </div> This step is nothing new and compilers have done it for the past decades. </li> <li> This step is the important one. The tool <em>asm2fsm</em> analyzes the RISC-V assembly. <br/> On a software-based processor a program does not start from zero. Before it starts executing, its initial data has to be moved to main memory. On a PC that is the operating system's job, on an embedded device the startup code. <br/> <em>asm2fsm</em> extracts memory information from all the assembly files and builds a memory layout starting at a given start address. It also removes dead code from the assembly files. Dead code is instructions that the program's normal control flow never reaches. Dead code happens if the program uses only a subset of a library's functions. <br/> The output of this stage is the memory layout and the pure instruction flow of the program. </li> <li> In another step <em>asm2fsm</em> converts the instruction flow into a Finite State Machine (FSM). <figure class="post-hero"> <svg viewBox="0 0 640 552" xmlns="http://www.w3.org/2000/svg" role="img" aria-label="Finite state machine generated from the sum() assembly: eight states, one operation each"> <defs> <linearGradient id="fsmbg" x1="0" y1="0" x2="1" y2="1"> <stop offset="0" stop-color="#11203a"/> <stop offset="1" stop-color="#0b1626"/> </linearGradient> <marker id="arr" viewBox="0 0 10 10" refX="8.5" refY="5" markerWidth="6.5" markerHeight="6.5" orient="auto-start-reverse"> <path d="M0 0L10 5L0 10z" fill="#9AA0A8"/> </marker> </defs> <rect x="0" y="0" width="640" height="552" fill="url(#fsmbg)"/>  <g stroke="#9AA0A8" stroke-width="1.5" fill="none"> <path d="M33 64 H58" marker-end="url(#arr)"/> <path d="M175 88 V121" marker-end="url(#arr)"/> <path d="M175 172 V205" marker-end="url(#arr)"/> <path d="M175 256 V289" marker-end="url(#arr)"/> <path d="M175 340 V373" marker-end="url(#arr)"/> <path d="M175 424 V457" marker-end="url(#arr)"/> <path d="M290 148 H367" marker-end="url(#arr)"/> <path d="M485 172 V205" marker-end="url(#arr)"/> <path d="M485 256 V273" marker-end="url(#arr)"/> <path d="M60 484 H28 V148 H57" stroke-linejoin="round" marker-end="url(#arr)"/> </g>  <circle cx="28" cy="64" r="5" fill="#F2EDE0"/>  <circle cx="485" cy="300" r="21" fill="none" stroke="#9AA0A8" stroke-width="1.5"/> <circle cx="485" cy="300" r="16" fill="none" stroke="#9AA0A8" stroke-width="1.5"/>  <g font-family="ui-monospace, SFMono-Regular, Menlo, Consolas, monospace" fill="#F2EDE0" opacity="0.85"> <text x="185" y="194" font-size="11">a1 > 0</text> <text x="328" y="138" font-size="11" text-anchor="middle">a1 ≤ 0</text> <text x="16" y="316" font-size="10.5" text-anchor="middle" transform="rotate(-90 16 316)">j loop</text> <text x="28" y="46" font-size="10" text-anchor="middle" opacity="0.7">start</text> </g>  <g font-family="ui-monospace, SFMono-Regular, Menlo, Consolas, monospace"> <rect x="60" y="40" width="230" height="48" rx="10" fill="#0f1e36" stroke="rgba(255,255,255,0.18)"/> <text x="72" y="58" font-size="10" fill="#5f7098">S0</text> <text x="175" y="76" font-size="13.5" text-anchor="middle"><tspan fill="#ffd479">a5</tspan><tspan fill="#c6d4ef"> := zero</tspan></text> <rect x="60" y="124" width="230" height="48" rx="10" fill="#0f1e36" stroke="#E0A83C"/> <text x="72" y="142" font-size="10" fill="#5f7098">S1</text> <text x="175" y="160" font-size="13.5" text-anchor="middle"><tspan fill="#ffd479">a1 ≤ 0 ?</tspan></text> <rect x="60" y="208" width="230" height="48" rx="10" fill="#0f1e36" stroke="rgba(255,255,255,0.18)"/> <text x="72" y="226" font-size="10" fill="#5f7098">S2</text> <text x="175" y="244" font-size="13.5" text-anchor="middle"><tspan fill="#ffd479">t0</tspan><tspan fill="#c6d4ef"> := M[a0]</tspan></text> <rect x="60" y="292" width="230" height="48" rx="10" fill="#0f1e36" stroke="rgba(255,255,255,0.18)"/> <text x="72" y="310" font-size="10" fill="#5f7098">S3</text> <text x="175" y="328" font-size="13.5" text-anchor="middle"><tspan fill="#ffd479">a5</tspan><tspan fill="#c6d4ef"> := a5 + t0</tspan></text> <rect x="60" y="376" width="230" height="48" rx="10" fill="#0f1e36" stroke="rgba(255,255,255,0.18)"/> <text x="72" y="394" font-size="10" fill="#5f7098">S4</text> <text x="175" y="412" font-size="13.5" text-anchor="middle"><tspan fill="#ffd479">a0</tspan><tspan fill="#c6d4ef"> := a0 + 4</tspan></text> <rect x="60" y="460" width="230" height="48" rx="10" fill="#0f1e36" stroke="rgba(255,255,255,0.18)"/> <text x="72" y="478" font-size="10" fill="#5f7098">S5</text> <text x="175" y="496" font-size="13.5" text-anchor="middle"><tspan fill="#ffd479">a1</tspan><tspan fill="#c6d4ef"> := a1 - 1</tspan></text> <rect x="370" y="124" width="230" height="48" rx="10" fill="#0f1e36" stroke="rgba(255,255,255,0.18)"/> <text x="382" y="142" font-size="10" fill="#5f7098">S6</text> <text x="485" y="160" font-size="13.5" text-anchor="middle"><tspan fill="#ffd479">a0</tspan><tspan fill="#c6d4ef"> := a5</tspan></text> <rect x="370" y="208" width="230" height="48" rx="10" fill="#0f1e36" stroke="rgba(255,255,255,0.18)"/> <text x="382" y="226" font-size="10" fill="#5f7098">S7</text> <text x="485" y="244" font-size="13.5" text-anchor="middle"><tspan fill="#c6d4ef">return</tspan></text> </g> </svg> </figure> The memory layout is copied in front of the FSM in the form of memory stores. So, before starting the program, the FSM itself moves the required initial data to memory and self-initializes.<br/> Converting the FSM to a hardware description language like VHDL is straightforward for any digital hardware engineer or even an AI today. The description is then merged into a System-on-Chip (SoC) framework which provides required peripherals like memory bus, interrupt management, and input/output. The explanation of a SoC framework is part of a future article. </li> <li>The last step is running the synthesis, placement and routing, and mapping flow of the FPGA or ASIC targeted.</li> </ol> <h3>Advantages</h3> <ul> <li><strong>Structural Elimination</strong> A general-purpose processor runs any program, including one an attacker injects. The ASP runs only the single application it was built for. A buffer-overflow attack works by redirecting the processor to run attacker code, the ASP has no way to start running code it wasn’t built with. There is nothing to land on. </li> <li><strong>No speculative execution</strong> Modern processors guess ahead to run faster, and that guessing is what makes side channels like Spectre possible. The FSM just steps through states in a fixed order — it never guesses, so that class of leak has no mechanism. </li> <li><strong>Determinism</strong> On a processor with an OS, how long an operation takes varies with what else is running. On the ASP the same input always takes the same number of cycles. A real-time deadline is a fixed number, not an average. </li> <li><strong>Efficiency</strong> The post’s intro already said a program uses only a small subset of the available instructions and registers. A general-purpose processor still pays for the whole set, a full register file, a decoder for the entire ISA, a branch unit. The ASP builds only what the application actually uses. Less hardware, less power, less space.</li> </ul> <h3>Some Application Areas</h3> <ul> <li><strong>Cryptographic engines</strong> Cryptographic algorithms are in general fixed and known. The processor just needs to execute them. ASPs can protect against side-channel attacks by providing a constant-time behavior by construction. This supports Smart cards, secure elements, and HSMs. </li> <li><strong>Secure boot</strong> The ASP can be considered as a coprocessor sitting next to a general-purpose processor, similar to a Secure Element (SE) or Trusted Platform Module (TPM) and do additional verification of system initialization step. An ASP might even replace part of the SE or TPM functionality. </li> <li><strong>Military / defense systems</strong> Defense systems must be sovereign and hardened. With an ASP the software stack is the one application itself, no OS to compromise, no general-purpose core to exploit, and a small state machine that can be verified. </li> <li><strong>Autonomous Drone Control</strong> Autonomous drones run a fixed flight-control application far from the operator. That application is exactly one thing: read sensors, compute the control loop, drive the motors. An ASP executes it deterministically, with guaranteed cycle times and no general-purpose code path that could be hijacked, a compromise in the communication or AI software cannot become a takeover of the flight control. </li> </ul> <h2>The publications behind this post</h2> <p> The work behind this post is available in the <a href="/asp-research.html">publications</a>: </p> <ul> <li><a href="/asp-research.html#meyer2019hdl"><em>HDL FSM Code Generation Using a MIPS-based Assembler</em></a>, ISIE 2019</li> <li><a href="/asp-research.html#meyer2021"><em>A Modern Approach to Application Specific Processors for Improving the Security of Embedded Devices</em></a>, IECON 2021</li> <li><a href="/asp-research.html#meyer2026"><em>Hardware-Enabled Sovereignty: Securing Military Systems Through a Novel and Resilient Defense Architecture</em></a>, CyCon 2026</li> <li><a href="/asp-research.html#meyer2026trust"><em>Trustworthiness by Structural Elimination</em></a>, FDL 2026</li> </ul> Open source ≠ sovereignty https://www.secure-platform.eu/sovereignty/2026/06/10/oss-sovereignty.html Open source moves the dependency from a vendor SLA to a maintainer inbox. It does not remove it. Sovereignty is about the structure of the dependency, not the license text. Dominik Meyer https://www.secure-platform.eu/sovereignty/2026/06/10/oss-sovereignty.html Wed, 10 Jun 2026 00:00:00 +0000 <p>While attending the 18th International Conference on Cyber Conflict (CyCon 2026) in Tallinn, 26–29 May 2026 I had many discussions about improving <em>Digital Sovereignty</em> by using Open-Source Software (OSS). The reasons I kept hearing were the standard ones: <ul> <li>freedom from vendor lockin</li> <li>no license fees</li> <li>IT-Security</li> <li>Adaptability</li> <li>Auditability</li> </ul> These are the right reasons for a first step. They are not, on their own, sovereignty. </p> <h2>What is Open-Source Software</h2> <p> Open-Source Software (OSS) is a Software whose Source-Code is available under an Open-Source License as approved by the Open Source Initiative (OSI). Typical building blocks of an Open-Source License are: <ul> <li><strong>The right to</strong> <ul> <li>Use, study, copy, modify, create derivatives</li> <li>Redistribute (original or modified)</li> </ul> </li> <li><strong>Conditions</strong> <ul> <li>Preserve copyright and license notices (attribution)</li> </ul> </li> <li><strong>Disclaimer</strong> <ul> <li>no warranty of any kind</li> <li>No liability for damages</li> <li>No endorsement, no trademark rights granted</li> <li>No sublicensing (usually)</li> </ul> </li> </ul> No clause obligates the author to keep the software alive. </p> <h2>Why using OSS is the way to go</h2> <p> OSS is an important building block of digital sovereignty. The rights given by an open-source license support many important aspects of digital sovereignty. </p> <h3>Adaptability</h3> <p> You are not forced to accept the update cycle and the development goals of the upstream project. If they do not fit your requirements, you can modify the software yourself or fork it — provided you have the competence and the resources to maintain the result. </p> <h3>Auditability</h3> <p> Verification that software does not contain backdoors or kill-switches is very important for digital sovereignty. Access to the source code is the requirement for verification. </p> <h3>IT-Security</h3> <p> Many people auditing the source code improves the IT-Security of an application — if there are many people auditing it. </p> <h3>No Vendor Lock-In</h3> <p> Vendor lock-in means that the vendor holds the off-switch. Prices, end-of-life decisions, and legal compulsion can all be turned against you. The only document that obligates the vendor to keep providing the software is the service-level agreement (SLA). An open-source license contains no such obligation. </p> <p> Note what all of the above has in common. It is about what you are permitted to do. A license grants permission. It does not do the work. </p> <h2>Why OSS is not enough</h2> <p> Under a proprietary license, keeping the software working is a contractual obligation of the vendor. Patches, updates, and support are delivered because the SLA says so. Under an open-source license, none of that is covered by anything. And the license does not just stay silent. It actively disclaims every warranty and every liability. </p> <h3>The work</h3> <p> Running a piece of software is not one action. It is a continuous process of tracking upstream changes, applying patches, testing, releasing, and reacting to vulnerability reports. A full software lifecycle management is required. The license tells you that you may do all of this. It does not tell you who will do it. </p> <h3>The maintainers</h3> <p> In practice, the work is done by a handful of maintainers. Many of them are volunteers; many work for companies whose goals are not yours. You can read the code and inspect the process, but goodwill is not a schedule, and an inbox is not a SLA. </p> <h3>The takeover</h3> <p> Maintainers leave. When they do, you must find someone to take over — or become that person. In 2015 the maintainer of the small npm package left-pad deleted it from the registry. There was no vendor to call and no contract to enforce. The package simply stopped existing until someone else picked it up. </p> <h2>Digital Sovereignty</h2> <p> There is a way out of this. You buy the work back. Companies sell maintenance, patches, and support for open-source components, and that is a legitimate model. But notice what it is. You have replaced one vendor SLA with another. You have not removed the dependency. You have changed the contract. </p> <p>While attending the 18th International Conference on Cyber Conflict (CyCon 2026) in Tallinn, 26–29 May 2026 I had many discussions about improving <em>Digital Sovereignty</em> by using Open-Source Software (OSS). The reasons I kept hearing were the standard ones: <ul> <li>freedom from vendor lockin</li> <li>no license fees</li> <li>IT-Security</li> <li>Adaptability</li> <li>Auditability</li> </ul> These are the right reasons for a first step. They are not, on their own, sovereignty. </p> <h2>What is Open-Source Software</h2> <p> Open-Source Software (OSS) is a Software whose Source-Code is available under an Open-Source License as approved by the Open Source Initiative (OSI). Typical building blocks of an Open-Source License are: <ul> <li><strong>The right to</strong> <ul> <li>Use, study, copy, modify, create derivatives</li> <li>Redistribute (original or modified)</li> </ul> </li> <li><strong>Conditions</strong> <ul> <li>Preserve copyright and license notices (attribution)</li> </ul> </li> <li><strong>Disclaimer</strong> <ul> <li>no warranty of any kind</li> <li>No liability for damages</li> <li>No endorsement, no trademark rights granted</li> <li>No sublicensing (usually)</li> </ul> </li> </ul> No clause obligates the author to keep the software alive. </p> <h2>Why using OSS is the way to go</h2> <p> OSS is an important building block of digital sovereignty. The rights given by an open-source license support many important aspects of digital sovereignty. </p> <h3>Adaptability</h3> <p> You are not forced to accept the update cycle and the development goals of the upstream project. If they do not fit your requirements, you can modify the software yourself or fork it — provided you have the competence and the resources to maintain the result. </p> <h3>Auditability</h3> <p> Verification that software does not contain backdoors or kill-switches is very important for digital sovereignty. Access to the source code is the requirement for verification. </p> <h3>IT-Security</h3> <p> Many people auditing the source code improves the IT-Security of an application — if there are many people auditing it. </p> <h3>No Vendor Lock-In</h3> <p> Vendor lock-in means that the vendor holds the off-switch. Prices, end-of-life decisions, and legal compulsion can all be turned against you. The only document that obligates the vendor to keep providing the software is the service-level agreement (SLA). An open-source license contains no such obligation. </p> <p> Note what all of the above has in common. It is about what you are permitted to do. A license grants permission. It does not do the work. </p> <h2>Why OSS is not enough</h2> <p> Under a proprietary license, keeping the software working is a contractual obligation of the vendor. Patches, updates, and support are delivered because the SLA says so. Under an open-source license, none of that is covered by anything. And the license does not just stay silent. It actively disclaims every warranty and every liability. </p> <h3>The work</h3> <p> Running a piece of software is not one action. It is a continuous process of tracking upstream changes, applying patches, testing, releasing, and reacting to vulnerability reports. A full software lifecycle management is required. The license tells you that you may do all of this. It does not tell you who will do it. </p> <h3>The maintainers</h3> <p> In practice, the work is done by a handful of maintainers. Many of them are volunteers; many work for companies whose goals are not yours. You can read the code and inspect the process, but goodwill is not a schedule, and an inbox is not a SLA. </p> <h3>The takeover</h3> <p> Maintainers leave. When they do, you must find someone to take over — or become that person. In 2015 the maintainer of the small npm package left-pad deleted it from the registry. There was no vendor to call and no contract to enforce. The package simply stopped existing until someone else picked it up. </p> <h2>Digital Sovereignty</h2> <p> There is a way out of this. You buy the work back. Companies sell maintenance, patches, and support for open-source components, and that is a legitimate model. But notice what it is. You have replaced one vendor SLA with another. You have not removed the dependency. You have changed the contract. </p> When Security Undermines Sovereignty https://www.secure-platform.eu/security/2026/06/01/when-security-undermines-sovereignty.html At CyCon 2026 we presented our work on hardware-enabled sovereignty. The core argument: standard cyber defense tooling trades sovereignty for security, and for long-lived critical systems that trade must be made deliberately in the hardware, not in another software layer. Dominik Meyer https://www.secure-platform.eu/security/2026/06/01/when-security-undermines-sovereignty.html Mon, 1 Jun 2026 00:00:00 +0000 <p>At the 18th International Conference on Cyber Conflict (CyCon 2026) in Tallinn, 26–29 May 2026, my co-authors Rishab Somu, Ankur Jayaraj, and I presented our work on hardware-enabled sovereignty for military systems. One argument from the paper stands on its own, and it applies far beyond the military context we framed it in.</p> <h2>The standard toolkit is the problem</h2> <p>In practice, critical systems today are protected by a stack of software services: endpoint detection and response, intrusion detection, cloud-based threat intelligence. None of these is a bad idea on its own. But they all do the same thing: they move part of the system's security outside the operator's own control.</p> <ul> <li>Cloud integration means the security of your system depends on infrastructure you do not control, in jurisdictions you cannot audit.</li> <li>Every additional agent expands the attack surface of the very system it is supposed to protect.</li> <li>On classified systems, such integrations are often not allowed at all — the connection itself would compromise the classification level.</li> </ul> <p>In practice, every security decision on a critical system is also a sovereignty decision — whether anyone treats it as one or not.</p> <p>Then there is the timescale. Military and industrial systems are not refreshed every three years; they are built for ten to twenty years of operation. You cannot protect a system that has to run for two decades with tools whose providers may not exist in five.</p> <h2>More security tooling means less sovereignty</h2> <p>For a system built for decades, the trade cannot be ignored. Piling on more tools makes it more resilient against known attacks — and less sovereign against the threats that matter most for long-lived systems: withdrawal, coercion, dependency. Every additional external dependency is a sovereignty leak: a path by which a vendor, a jurisdiction, or an attacker can reach into the system's operation.</p> <p>More security or more sovereignty is a decision someone has to make. In practice it is usually made implicitly, one procurement at a time, one integration at a time — and a trade made that way is hard to reverse once a system is deployed. Where sovereignty is a requirement for the system, that decision has to be made deliberately and in the architecture: the security properties of the system are defined by the hardware it runs on, not by what is layered onto it.</p> <h2>Sovereignty, enabled by hardware</h2> <p>In the paper we demonstrate this with SOSA, the Sovereign Sensor and Actuator: a network sensor whose core is an application-specific processor SoC on FPGA. The core implements exactly the functionality the sensor requires, and nothing else. So the attack surface is not reduced by filtering or patching — it is reduced by absence. Only what the application requires is ever built, and what is not built cannot be exploited.</p> <ul> <li>The components integrate independently into existing systems, without cloud dependencies.</li> <li>The minimal core is resilient against a wide range of attacks.</li> <li>We validated the approach with a working implementation adapted to a naval combat management system.</li> </ul> <p>The same principle runs through our broader ASP research: trustworthiness by structural elimination. You do not add verification on top of a system; you build only what the application requires. That is what sovereignty means at the hardware layer.</p> <h2>The takeaway</h2> <p>Sovereignty is often treated as a policy promise: a statement in a procurement document, a framework, a mandate. A promise does not make a system sovereign. Architecture does — sovereignty is a property the hardware gives the system, and no software layer can restore it once it is lost.</p> <p>For any system that must stay operational for the next twenty years, the trade between security and sovereignty has to be made somewhere: deliberately, in the architecture — or by default, one dependency at a time. In the silicon, or in the mandate.</p> <p>The full paper is available in the <a href="/asp-research.html#meyer2026">publications</a>: <em>Hardware-Enabled Sovereignty: Securing Military Systems Through a Novel and Resilient Defense Architecture</em>, CyCon 2026.</p> <p>At the 18th International Conference on Cyber Conflict (CyCon 2026) in Tallinn, 26–29 May 2026, my co-authors Rishab Somu, Ankur Jayaraj, and I presented our work on hardware-enabled sovereignty for military systems. One argument from the paper stands on its own, and it applies far beyond the military context we framed it in.</p> <h2>The standard toolkit is the problem</h2> <p>In practice, critical systems today are protected by a stack of software services: endpoint detection and response, intrusion detection, cloud-based threat intelligence. None of these is a bad idea on its own. But they all do the same thing: they move part of the system's security outside the operator's own control.</p> <ul> <li>Cloud integration means the security of your system depends on infrastructure you do not control, in jurisdictions you cannot audit.</li> <li>Every additional agent expands the attack surface of the very system it is supposed to protect.</li> <li>On classified systems, such integrations are often not allowed at all — the connection itself would compromise the classification level.</li> </ul> <p>In practice, every security decision on a critical system is also a sovereignty decision — whether anyone treats it as one or not.</p> <p>Then there is the timescale. Military and industrial systems are not refreshed every three years; they are built for ten to twenty years of operation. You cannot protect a system that has to run for two decades with tools whose providers may not exist in five.</p> <h2>More security tooling means less sovereignty</h2> <p>For a system built for decades, the trade cannot be ignored. Piling on more tools makes it more resilient against known attacks — and less sovereign against the threats that matter most for long-lived systems: withdrawal, coercion, dependency. Every additional external dependency is a sovereignty leak: a path by which a vendor, a jurisdiction, or an attacker can reach into the system's operation.</p> <p>More security or more sovereignty is a decision someone has to make. In practice it is usually made implicitly, one procurement at a time, one integration at a time — and a trade made that way is hard to reverse once a system is deployed. Where sovereignty is a requirement for the system, that decision has to be made deliberately and in the architecture: the security properties of the system are defined by the hardware it runs on, not by what is layered onto it.</p> <h2>Sovereignty, enabled by hardware</h2> <p>In the paper we demonstrate this with SOSA, the Sovereign Sensor and Actuator: a network sensor whose core is an application-specific processor SoC on FPGA. The core implements exactly the functionality the sensor requires, and nothing else. So the attack surface is not reduced by filtering or patching — it is reduced by absence. Only what the application requires is ever built, and what is not built cannot be exploited.</p> <ul> <li>The components integrate independently into existing systems, without cloud dependencies.</li> <li>The minimal core is resilient against a wide range of attacks.</li> <li>We validated the approach with a working implementation adapted to a naval combat management system.</li> </ul> <p>The same principle runs through our broader ASP research: trustworthiness by structural elimination. You do not add verification on top of a system; you build only what the application requires. That is what sovereignty means at the hardware layer.</p> <h2>The takeaway</h2> <p>Sovereignty is often treated as a policy promise: a statement in a procurement document, a framework, a mandate. A promise does not make a system sovereign. Architecture does — sovereignty is a property the hardware gives the system, and no software layer can restore it once it is lost.</p> <p>For any system that must stay operational for the next twenty years, the trade between security and sovereignty has to be made somewhere: deliberately, in the architecture — or by default, one dependency at a time. In the silicon, or in the mandate.</p> <p>The full paper is available in the <a href="/asp-research.html#meyer2026">publications</a>: <em>Hardware-Enabled Sovereignty: Securing Military Systems Through a Novel and Resilient Defense Architecture</em>, CyCon 2026.</p>