Paper 2025/2223

Analysis of the Security Design, Engineering, and Implementation of the SecureDNA System

Alan T. Sherman, University of Maryland, Baltimore County (UMBC)
Jeremy J. Romanik Romano, University of Maryland, Baltimore County (UMBC)
Edward Zieglar, National Security Agency (NSA), University of Maryland, Baltimore County (UMBC)
Enis Golaszewski, University of Maryland, Baltimore County (UMBC)
Jonathan D. Fuchs, University of Maryland, Baltimore County (UMBC)
William E. Byrd, Hugh Kaul Precision Medicine Institute, Heersink School of Medicine, University of Alabama at Birmingham
Abstract

We analyze security aspects of the SecureDNA system regarding its system design, engineering, and implementation. This system enables DNA synthesizers to screen order requests against a database of hazards. By applying novel cryptography involving distributed oblivious pseudorandom functions, the system aims to keep order requests and the database of hazards secret. Discerning the detailed operation of the system in part from source code (Version 1.0.8), our analysis examines key management, certificate infrastructure, authentication, and rate-limiting mechanisms. We also perform the first formal-methods analysis of the mutual authentication, basic request, and exemption-handling protocols. Without breaking the cryptography, our main finding is that SecureDNA's custom mutual authentication protocol SCEP achieves only one-way authentication: the hazards database and keyservers never learn with whom they communicate. This structural weakness violates the principle of defense in depth and enables an adversary to circumvent rate limits that protect the secrecy of the hazards database, if the synthesizer connects with a malicious or corrupted keyserver or hashed database. We point out an additional structural weakness that also violates the principle of defense in depth: inadequate cryptographic bindings prevent the system from detecting if responses, within a TLS channel, from the hazards database were modified. Consequently, if a synthesizer were to reconnect with the database over the same TLS session, an adversary could replay and swap responses from the database without breaking TLS. Although the SecureDNA implementation does not allow such reconnections, it would be stronger security engineering to avoid the underlying structural weakness. We identify these vulnerabilities and suggest and verify mitigations, including adding strong bindings. Software Version 1.1.0 fixes SCEP with our proposed SCEP+ protocol. Our work illustrates that a secure system needs more than sound mathematical cryptography; it also requires formal specifications, sound key management, proper binding of protocol message components, and careful attention to engineering and implementation details.

Note: A shorter version of this paper will appear in the Proceedings of the Network and Distributed System Security Symposium (NDSS) 2026 published by the Internet Society.

Metadata
Available format(s)
PDF
Category
Cryptographic protocols
Publication info
Published elsewhere. Major revision. A shorter version of this paper will appear in the Proceedings of the Network and Distributed System Security Symposium (NDSS) 2026 published by the Internet Society.
Keywords
BiosafetyCrypto. Protocol Shapes Analyzer (CPSA)DNA synthesisFormal MethodsProtocol AnalysisSecureDNA
Contact author(s)
sherman @ umbc edu
jeremyr2 @ umbc edu
ezieg1 @ umbc edu
golaszewski @ umbc edu
jfuchs2 @ umbc edu
webyrd @ uab edu
History
2025-12-12: approved
2025-12-10: received
See all versions
Short URL
https://ia.cr/2025/2223
License
No rights reserved
CC0

BibTeX

@misc{cryptoeprint:2025/2223,
      author = {Alan T. Sherman and Jeremy J. Romanik Romano and Edward Zieglar and Enis Golaszewski and Jonathan D. Fuchs and William E. Byrd},
      title = {Analysis of the Security Design, Engineering, and Implementation of the {SecureDNA} System},
      howpublished = {Cryptology {ePrint} Archive, Paper 2025/2223},
      year = {2025},
      url = {https://eprint.iacr.org/2025/2223}
}
Note: In order to protect the privacy of readers, eprint.iacr.org does not use cookies or embedded third party content.