pith. sign in

arxiv: 2605.06744 · v1 · submitted 2026-05-07 · 💻 cs.CR

A UEFI System with SPDM to Protect Against Unauthorized Device Connections

\'Agatha de Freitas , Marcos A. Simplicio Jr , Bruno C. Albertini , Renan C. A. Alves This is my paper

Pith reviewed 2026-05-11 00:45 UTC · model grok-4.3

classification 💻 cs.CR
keywords UEFISPDMdevice authenticationPCIe securityUSB securityfirmware protectionmalicious peripheralssecure boot
0
0 comments X

The pith

UEFI firmware can use SPDM to authenticate PCIe and USB devices and block unauthorized connections.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper proposes integrating the Security Protocol and Data Model into UEFI to authenticate peripherals attempting to connect via PCIe or USB. A sympathetic reader would care because this directly counters attacks that use malicious hardware to compromise systems without software-level detection. The work includes an open-source emulated proof-of-concept that enforces connection only to allowed devices. Experiments measure a 13 percent rise in instructions and 8 percent in CPU cycles during boot, presented as acceptable for the gained security. Institutions can adapt the approach to their specific security needs.

Core claim

By incorporating SPDM into the UEFI environment, the system authenticates PCIe and USB devices during connection attempts, restricting access exclusively to those previously allowed, thereby protecting against malicious peripherals; this is demonstrated through an emulated implementation whose performance overhead during firmware execution averages 13% more instructions and 8% more CPU cycles.

What carries the argument

SPDM (Security Protocol and Data Model) integrated into UEFI firmware for device authentication and access restriction.

If this is right

  • Only authorized PCIe and USB devices can connect to the system.
  • The approach provides protection against malicious peripheral-based attacks.
  • Performance overhead remains low enough to be practical.
  • Open-source proof-of-concept enables customization for high-security environments.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Similar authentication could be applied to other connection interfaces if SPDM support expands.
  • The mechanism might combine with existing secure boot processes for layered defense.
  • Real hardware validation would be needed to confirm emulation results hold outside virtualized setups.

Load-bearing premise

That the SPDM-based authentication tested in emulation will provide equivalent protection and acceptable performance when deployed on actual physical hardware.

What would settle it

Testing the system on physical hardware with a known malicious USB or PCIe device to see if connection is blocked as intended.

Figures

Figures reproduced from arXiv: 2605.06744 by \'Agatha de Freitas, Bruno C. Albertini, Marcos A. Simplicio Jr, Renan C. A. Alves.

Figure 1
Figure 1. Figure 1: System behavior of secure boot with SPDM. [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: SPDM communication flow. Adapted from [21]. [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Communication between entities in our proposed system. [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Comparison of the average number of (a) instructions and (b) CPU [PITH_FULL_IMAGE:figures/full_fig_p008_4.png] view at source ↗
read the original abstract

Attackers willing to compromise computing systems can use malicious peripherals as an attack vector, threatening users that cannot verify the hardware's authenticity. To address this problem, our work uses the Security Protocol and Data Model to propose a UEFI system capable of authenticating PCIe and USB devices trying to connect with it. We also develop an open source proof-of-concept using emulation to evaluate and illustrate our proposal, which is capable of restricting the devices' connections to only those allowed, thus protecting the system against malicious peripherals. Then, using kernel virtualization features to evaluate the emulation, we collect the number of instructions and CPU cycles during boot. Our experiments reveal that, during firmware execution, the number of instructions and the number of CPU cycles increased respectively 13% and 8% on average. This processing overhead is acceptable in view of enhanced security. Institutions requiring high security levels can leverage our proof-of-concept to tailor their own system based on their own requirements.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 2 minor

Summary. The paper proposes a UEFI firmware design that integrates the Security Protocol and Data Model (SPDM) to authenticate PCIe and USB devices at connection time and restrict access to only authorized devices, thereby protecting against malicious peripherals. It describes an open-source proof-of-concept implemented and evaluated in an emulated environment via kernel virtualization, reporting average increases of 13% in instruction count and 8% in CPU cycles during boot, which the authors consider acceptable for the security gain.

Significance. If the approach can be shown to work on physical hardware, it would provide a concrete firmware-level mechanism for mitigating peripheral-based attacks, a relevant threat in high-security settings. The open-source PoC and quantitative overhead measurements are strengths that support reproducibility and allow others to assess practicality.

major comments (2)
  1. Evaluation section: All claims of functional authentication, connection restriction, and acceptable overhead rest on results from an emulated environment using kernel virtualization. This leaves unaddressed whether the SPDM handshake, certificate validation, and enforcement logic execute correctly under real hardware timing, DMA behavior before authentication completes, USB enumeration quirks, or firmware interactions, directly undermining the central claim of protection against malicious devices on actual systems.
  2. Implementation and threat model sections: The manuscript provides no explicit threat model or analysis of potential bypasses (e.g., devices that complete enumeration before SPDM authentication or exploit UEFI boot timing windows), which is load-bearing for asserting that the design 'protects the system against malicious peripherals.'
minor comments (2)
  1. The abstract and evaluation report overhead 'on average' without standard deviations, raw data, or per-phase breakdowns, which would clarify variability and help readers judge acceptability.
  2. No link or repository reference is given for the claimed open-source PoC, reducing the ability to inspect or reproduce the implementation.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We appreciate the referee's feedback on our manuscript. We have carefully considered the major comments and provide point-by-point responses below. Where revisions are needed, we indicate our plans to update the manuscript.

read point-by-point responses

  1. Referee: Evaluation section: All claims of functional authentication, connection restriction, and acceptable overhead rest on results from an emulated environment using kernel virtualization. This leaves unaddressed whether the SPDM handshake, certificate validation, and enforcement logic execute correctly under real hardware timing, DMA behavior before authentication completes, USB enumeration quirks, or firmware interactions, directly undermining the central claim of protection against malicious devices on actual systems.

    Authors: We acknowledge that our evaluation is conducted in an emulated environment using kernel virtualization, which simulates the UEFI firmware execution but does not fully replicate real hardware behaviors such as DMA timing or specific USB enumeration quirks. This is a limitation of the current proof-of-concept. In the revised manuscript, we will expand the Evaluation section to explicitly discuss these limitations, clarify that the results demonstrate feasibility in a controlled emulation setting, and outline plans for future validation on physical hardware. We believe this addresses the concern by tempering the claims appropriately while maintaining the value of the open-source PoC for further development. revision: yes

  2. Referee: Implementation and threat model sections: The manuscript provides no explicit threat model or analysis of potential bypasses (e.g., devices that complete enumeration before SPDM authentication or exploit UEFI boot timing windows), which is load-bearing for asserting that the design 'protects the system against malicious peripherals.'

    Authors: We agree that an explicit threat model would strengthen the paper. The current manuscript describes the design and its intended protections but does not include a dedicated threat model section analyzing potential bypasses. In the revision, we will add a Threat Model section that outlines the assumed attacker capabilities, such as malicious peripherals attempting to connect, and discusses potential bypasses including timing windows during boot and enumeration sequences, along with how the SPDM integration mitigates them where possible. This will provide a clearer foundation for the protection claims. revision: yes

Circularity Check

0 steps flagged

No circularity: design proposal + independent emulation PoC with direct measurements

full rationale

The paper presents a system design that integrates SPDM into UEFI for device authentication, implements an open-source emulation-based proof-of-concept, and reports direct performance measurements (instruction and cycle counts) from that emulation. No equations, fitted parameters, or derivations are present. No self-citations are used as load-bearing premises for the central claim. The emulation results are obtained by running the implemented code under kernel virtualization and counting instructions/cycles; these are not predictions derived from the design but direct outputs of the implementation. The security claim rests on the described authentication flow and restriction logic being realized in the PoC, which is externally verifiable via the open-source code rather than reducing to the paper's own inputs by construction.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 0 invented entities

The proposal rests on the domain assumption that SPDM can be integrated into UEFI and that emulation results generalize to real hardware; no free parameters or invented entities are introduced.

axioms (1)
  • domain assumption SPDM protocol provides reliable device authentication when properly implemented
    The entire security claim depends on SPDM functioning as intended for PCIe and USB devices.

pith-pipeline@v0.9.0 · 5473 in / 1145 out tokens · 65724 ms · 2026-05-11T00:45:11.336810+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Lean theorems connected to this paper

Citations machine-checked in the Pith Canon. Every link opens the source theorem in the public Lean library.

What do these tags mean?
matches
The paper's claim is directly supported by a theorem in the formal canon.
supports
The theorem supports part of the paper's argument, but the paper may add assumptions or extra steps.
extends
The paper goes beyond the formal theorem; the theorem is a base layer rather than the whole result.
uses
The paper appears to rely on the theorem as machinery.
contradicts
The paper's claim conflicts with a theorem or certificate in the canon.
unclear
Pith found a possible connection, but the passage is too broad, indirect, or ambiguous to say the theorem truly supports the claim.

Reference graph

Works this paper leans on

22 extracted references · 22 canonical work pages

  1. [1]

    Securing hard drives with the Security Protocol and Data Model (SPDM)

    Renan C. A. Alves, Bruno C. Albertini, and Marcos A. Simplicio. “Securing hard drives with the Security Protocol and Data Model (SPDM)”. In:2022 IEEE Computer Society Annual Symposium on VLSI (ISVLSI). Nicosia, Cyprus: IEEE, 2022, pp. 446–447.DOI: 10.11 09/ISVLSI54635.2022.00099.URL: https://doi.org/10.1 109/ISVLSI54635.2022.00099

    work page arXiv 2022

  2. [2]

    Testing the limits of SPDM: Authentication of intermittently connected devices

    Renan C.A. Alves et al. “Testing the limits of SPDM: Authentication of intermittently connected devices”. In: Computers & Security148 (2025), p. 104142.ISSN: 0167-4048.DOI: https://doi.org/10.1016/j.cose.2024.10 4142.URL: https://www.sciencedirect.com/science/arti cle/pii/S0167404824004474

    work page doi:10.1016/j.cose.2024.10 2025

  3. [3]

    Arch Wiki.EFI boot stub. Dec. 2025.URL: https://wi ki.archlinux.org/index.php?title=EFI boot stub&oldid =857950 (visited on 01/07/2026). 2https://github.com/htafr/uefi-spdm/tree/0d8a895

    work page 2025

  4. [4]

    Validating Semantic Artifacts With Large Language Models

    Will Arthur, David Challener, and Kenneth Goldman. A Practical Guide to TPM 2.0. Berkeley, CA: Apress Berkeley, 2015, p. 392.DOI: https://doi.org/10.1007/97 8-1-4302-6584-9

    work page doi:10.1007/97 2015

  5. [5]

    QEMU, a fast and portable dynamic translator

    Fabrice Bellard. “QEMU, a fast and portable dynamic translator”. In:Proceedings of the Annual Conference on USENIX Annual Technical Conference. ATEC ’05. Anaheim, CA: USENIX Association, 2005, p. 41

    work page 2005

  6. [6]

    Earfda: A lightweight and energy-efficient fall detection accelerator for ear-worn devices

    Kais Belwafi et al. “Enhancing Circuit Authentication through Secure Isolation”. In:2024 IEEE International Symposium on Circuits and Systems (ISCAS). Singa- pore, Singapore: IEEE, 2024, pp. 1–5.DOI: 10.1109 /ISCAS58744.2024.10558551.URL: https://doi.org/10 .1109/ISCAS58744.2024.10558551

    work page arXiv 2024

  7. [7]

    Zero-Trust Communication between Chips

    Kais Belwafi et al. “Zero-Trust Communication between Chips”. In:2023 IFIP/IEEE 31st International Con- ference on Very Large Scale Integration (VLSI-SoC). Dubai, UAE: IEEE, 2023, pp. 1–5.DOI: 10.1109/VLSI- SoC57769.2023.10321927.URL: https://doi.org/10.110 9/VLSI-SoC57769.2023.10321927

    work page doi:10.1109/vlsi- 2023

  8. [8]

    Stefan Berger and David Safford.SWTPM - Software TPM Emulator. Dec. 2016.URL: https://github.com/ste fanberger/swtpm/wiki (visited on 04/10/2026)

    work page 2016

  9. [9]

    Vers ˜ao 1.37.0

    BusyBox.BusyBox: The Swiss Army Knife of Embedded Linux. Vers ˜ao 1.37.0. Sept. 2024.URL: https : / / git . b usybox . net / busybox / tree ? h = 137 stable (visited on 01/08/2026)

    work page 2024

  10. [10]

    New technology beefs up BIOS

    L. Dailey Paulson. “New technology beefs up BIOS”. In:Computer37.5 (2004), pp. 22–.DOI: 10.1109/MC.2 004.1297231

    work page doi:10.1109/mc.2 2004

  11. [11]

    Version 3.5.0

    DMTF.DMTF’s Reference Implementation of SPDM. Version 3.5.0. Apr. 2021.URL: https://github.com/DM TF/libspdm/tree/3.5.0

    work page 2021

  12. [12]

    Version 3.5.0

    DMTF.This spdm-emu is a sample SPDM emulator implementation using libspdm. Version 3.5.0. Apr. 2021. URL: https://github.com/DMTF/spdm-emu/tree/3.5.0

    work page 2021

  13. [13]

    June 2024

    Alistair Francis.Initial support for DOE. June 2024. URL: https://github.com/tianocore/edk2/pull/5715

    work page 2024

  14. [14]

    Arthur Gautier and Hugo Landau.ovmfvartool. Sept. 2022.URL: https://github.com/hlandau/ovmfvartool/tre e/f960eed (visited on 03/13/2026)

    work page 2022

  15. [15]

    NSA.Boot Security Modes and Recommendations. Tech. rep. Fort Meade, MD, USA: National Security Agency, June 2019

    work page 2019

  16. [16]

    NSA.UEFI Advantages Over Legacy Mode. Tech. rep. Fort Meade, MD, USA: National Security Agency, Mar. 2018

    work page 2018

  17. [17]

    2022.URL: https://github.com/NVIDIA/ope n-gpu-kernel-modules/tree/565.57.01

    NVIDIA.NVIDIA Linux Open GPU Kernel Module Source. 2022.URL: https://github.com/NVIDIA/ope n-gpu-kernel-modules/tree/565.57.01

    work page 2022

  18. [18]

    OW ASP.IoT Security Testing Guide. Tech. rep. Wilm- ington, DE, USA: Open Worlwide Application Security Project, June 2024

    work page 2024

  19. [19]

    alien traces

    Endres Puschner et al. “Red Team vs. Blue Team: A Real-World Hardware Trojan Detection Case Study Across Four Modern CMOS Technology Generations”. In:2023 IEEE Symposium on Security and Privacy (SP). Los Alamitos, CA, USA: IEEE Computer Society, 10 May 2023, pp. 56–74.DOI: 10.1109/SP46215.2023.10 179341.URL: https://doi.ieeecomputersociety.org/10.1 109/SP...

    work page doi:10.1109/sp46215.2023.10 2023

  20. [20]

    DeviceVeil: Robust Authen- tication for Individual USB Devices Using Physical Unclonable Functions

    Kuniyasu Suzaki et al. “DeviceVeil: Robust Authen- tication for Individual USB Devices Using Physical Unclonable Functions”. In:2019 49th Annual IEEE/I- FIP International Conference on Dependable Systems and Networks (DSN). Portland, OR, USA: IEEE, 2019, pp. 302–314.DOI: 10 . 1109 / DSN . 2019 . 00041.URL: https://doi.org/10.1109/DSN.2019.00041

    work page doi:10.1109/dsn.2019.00041 2019

  21. [21]

    TianoCore.OVMF. Feb. 2017.URL: https://github.com /tianocore/tianocore.github.io/wiki/OVMF (visited on 04/04/2025). [24]TPM Communication over SPDM Secure Session. Trusted Computing Group, Version 1.0, RC 1. TCG. Beaverton, OR, Feb. 2025

    work page 2017

  22. [22]

    bmRequestType

    Jiewen Yao and Wenxing Hou.UEFI DeviceSecurity Support. TianoCore, Jan. 2025.URL: https://github.co m/tianocore/edk2-staging/tree/a380775. APPENDIXA USB CONTROLTRANSFERMESSAGEFORMAT The bitmap “bmRequestType” depends solely on the data transfer direction, assuming 0x0 and 0x80 when it is host-to- device and device-to-host, respectively. We arbitrarily cho...

    work page 2025