Quantum Resistant Healthcare

Quantum Resistant Healthcare

Speakers: Katarina Amrichova, Cyber Security Researcher, Siemens Health

Conference: DEF CON

YouTube: https://www.youtube.com/watch?v=KpxHU5NPsPk

Overview

Katarina Amrichova's talk, "Quantum Resistant Healthcare," addresses the critical and looming threat that quantum computing poses to current cryptographic standards, particularly within the healthcare sector. As a Cyber Security Researcher at Siemens Health, Amrichova highlights the unique vulnerabilities of healthcare systems, characterized by exceptionally long data shelf lives and system lifecycles, which make them prime targets for "harvest now, decrypt later" attacks. The presentation serves as a stark warning and a practical guide for healthcare organizations to proactively prepare for the advent of cryptographically relevant quantum computers.

The core of Amrichova's presentation details Siemens Health's pioneering efforts in developing a strategic roadmap for transitioning to Post-Quantum Cryptography (PQC). This initiative includes implementing early-stage prototypes to understand the practical implications of PQC integration and developing novel methodologies for creating Crypto Bill of Materials (CBoMs). These CBoMs are essential for identifying and prioritizing cryptographic assets within complex software ecosystems, enabling targeted and efficient migration strategies. The talk underscores the urgency for the healthcare industry to move beyond theoretical discussions and begin concrete implementation steps to safeguard sensitive patient data and critical medical infrastructure against future quantum threats.

This work is particularly significant because healthcare data, such as medical images (MRI, CT) and patient records, often requires confidentiality for decades, far exceeding the projected timeline for the emergence of quantum computing capabilities. The regulatory landscape, with directives like CNSA 2.0 already incorporating PQC, further emphasizes the imperative for the industry to act. Amrichova's insights provide a valuable framework for other organizations facing similar challenges, demonstrating a pragmatic, multi-faceted approach to an unprecedented cybersecurity paradigm shift.

Background

▶ Watch: Welcome and introduction to quantum resistant healthcare (0:00)

The looming threat of quantum computing to modern cryptography stems from the potential for sufficiently powerful quantum computers to efficiently break currently used asymmetric cryptographic algorithms. While symmetric algorithms and hashing functions (like AES and SHA) are generally considered resilient with only a doubling of key sizes to counter Grover's algorithm, asymmetric algorithms, which form the backbone of secure communication (e.g., TLS, digital certificates), are highly vulnerable to Shor's algorithm. This vulnerability presents a significant problem, particularly the "harvest now, decrypt later" attack scenario. In this threat model, adversaries can intercept and store encrypted communications today, with the intention of decrypting them years or decades later once a cryptographically relevant quantum computer (CRQC) becomes available.

For the healthcare industry, this threat is profoundly magnified due to two critical factors: data shelf life and system lifecycle. Medical records, patient images, and other sensitive health information often need to remain confidential for 30, 50, or even more years. Simultaneously, large medical devices such as MRI, CT, X-ray, and ultrasound machines have extremely long operational lifecycles, often remaining in service for decades. Amrichova illustrates this with a risk graph, placing big modalities at the highest risk due to their combined long data shelf life and extended system lifecycles. Smaller devices like blood pressure monitors and chemical analyzers, while having shorter lifecycles, still handle sensitive patient data, placing them at a slightly lower but still significant risk. Medical software, with its generally shorter lifecycle, faces the lowest comparative risk but remains a concern.

Estimates for the arrival of a CRQC, often referred to as "Q-day," vary, but projections based on the exponential growth of qubits suggest it could occur around 2040. Breaking a 256-bit elliptic curve, a common standard, is estimated to require approximately 1 million physical qubits (where one logical qubit might comprise around 100 physical qubits due to error correction). While these are projections, regulatory bodies are already responding. The CNSA 2.0 (Commercial National Security Algorithm Suite 2.0), for instance, already incorporates PQC algorithms. Given that the FDA requires medical device manufacturers to comply with standards like CNSA 1.0 and Suite B ciphers, it is anticipated that the FDA will soon push for a transition to PQC, making proactive preparation essential for compliance and security. This confluence of long-term data sensitivity, extended hardware lifecycles, and emerging regulatory pressure compels the healthcare industry to take immediate and decisive action toward PQC adoption.

Key Findings

▶ Watch: Explaining Q-day, PQC importance, and 'harvest now' attacks (2:00)

Siemens Health's proactive engagement with the quantum threat has yielded several key findings and contributions, shaping a pragmatic approach to PQC transition in healthcare.

Firstly, the development of an internal PQC transition timeline underscored the critical need for widespread awareness—both internal among developers, project managers, and cybersecurity personnel, and external among third-party suppliers. This awareness is crucial for initiating necessary negotiations and ensuring all stakeholders understand the impending cryptographic shift.

Secondly, the practical implementation of a PQC prototype within a secure DICOM communication environment demonstrated the feasibility and highlighted unforeseen challenges. This proof-of-concept revealed that while PQC algorithms are becoming more "production-ready," their integration into existing infrastructures can expose issues like large key sizes causing network fragmentation and middleware failures, as observed by Google and Cloudflare in earlier experiments. This emphasizes that theoretical PQC readiness does not equate to seamless deployment without careful testing. Amrichova's work successfully integrated PQC into a DICOM/TLS stack using OpenSSL and OQS provider, showcasing a tangible step towards quantum-secure medical data exchange.

Thirdly, the initiative identified a significant gap in current cybersecurity tooling: the absence of robust solutions for generating Crypto Bill of Materials (CBoMs). A CBoM, analogous to a Software Bill of Materials (SBoM), lists all cryptographic algorithms used within a software product and its dependencies. The research found that building an effective CBoM requires combining Static Application Security Testing (SAST) capabilities with Software Composition Analysis (SCA) to accurately identify crypto hiding deep within dependency trees. This finding led to a second proof-of-concept for a CBoM generation pipeline, leveraging open-source tools from IBM Research. This demonstrates a crucial step for healthcare vendors to gain visibility into their cryptographic footprint, enabling data-driven prioritization of PQC migration efforts based on threat and risk analysis.

Technical Deep Dive

▶ Watch: Analyzing quantum attack risk for different medical devices (4:00)

The technical work presented by Katarina Amrichova focused on two primary proof-of-concept implementations: securing DICOM communication with PQC and building a robust Crypto Bill of Materials (CBoM).

PQC Prototype in Secure DICOM Communication

The first prototype addressed the critical need to secure DICOM (Digital Imaging and Communications in Medicine) communication, a standard protocol for handling, storing, printing, and transmitting medical imaging information. This is particularly vital given the long shelf life of medical images. The goal was to integrate PQC into an existing secure DICOM channel, specifically one wrapped in TLS (Transport Layer Security).

The architecture involved three main layers:

1. DICOM Layer: Implemented using the DCMTK (DICOM Tool Kit) library.
2. TLS Layer: Handled by the OpenSSL library.
3. PQC Component: Provided by the OQS provider and libOQS (Open Quantum Safe) libraries.

A significant challenge arose because DCMTK, by default, expects a vanilla version of OpenSSL and is not designed to work with external providers like OQS. To overcome this, Amrichova had to make minor modifications to the DCMTK library, adding specific lines of code to enable it to recognize and utilize the OQS provider for PQC handshakes. This modification was crucial for allowing the PQC algorithms to be negotiated and used within the TLS handshake initiated by the DICOM client and server.

The successful implementation was demonstrated through a Wireshark capture, which displayed the server hello message containing a key share entry for Kyber 768. Kyber 768 is a specific PQC key encapsulation mechanism (KEM) algorithm, currently a candidate for standardization by NIST. This visual proof confirmed that a quantum-secure key exchange was successfully established between the DICOM client and server. Amrichova noted that for production environments, a hybrid approach (combining a classical algorithm with a PQC algorithm) and potentially stronger PQC algorithms with longer key sizes would be advisable, given the relative newness of PQC algorithms and the ongoing cryptoanalysis.

A crucial clarification during the Q&A session highlighted that this prototype specifically focused on quantum-secure key exchange (KEM) for confidentiality. This choice was deliberate, prioritizing protection against passive "harvest now, decrypt later" attackers by securing the encryption keys. The speaker acknowledged that quantum-secure digital signatures for authentication would be a subsequent and equally important phase once a CRQC becomes a reality and active attacks become more prevalent.

Crypto Bill of Materials (CBoM) Generation

The second technical deep dive focused on creating a methodology and toolchain for generating Crypto Bill of Materials (CBoMs). The purpose of a CBoM is to provide a comprehensive list of all cryptographic algorithms, primitives, and libraries used within a software product, including its entire dependency tree. This granular visibility is essential for healthcare vendors to perform effective threat and risk analysis, enabling them to prioritize which parts of their vast software portfolios need PQC transition first.

The primary challenge in building CBoMs is that no single, readily available tool offers complete coverage. Cryptographic implementations can be deeply embedded within source code or hidden within third-party dependencies. To address this, Siemens Health developed a proof-of-concept pipeline that combines two distinct but complementary capabilities:

1. Static Application Security Testing (SAST): For analyzing the project's own source code.
2. Software Composition Analysis (SCA): For identifying and analyzing third-party dependencies.

The pipeline, implemented in Azure DevOps, integrates open-source tools developed by IBM Research:

• Sonar Crypto plug-in: This plug-in for SonarQube is used for static code analysis to detect cryptographic invocations within the project's source code. At the time of the talk, it supported Java and Python, with detection capabilities for specific libraries like Python's crypto library, Bouncy Castle and JCA (Java Cryptography Architecture) in Java. Siemens Health is actively collaborating with IBM Research to enhance its coverage, particularly by adding support for C/C++ and other libraries like Google's Tink.
• CBoM Kit: This tool serves as a database and analysis engine for storing and managing CBoMs. It can process package URLs (PURLs) extracted from SBoMs to identify and scan individual dependencies for cryptographic content.

The CBoM generation process within the pipeline involves two main stages:

1. Project CBoM Scan: The project's source code is built and sent to a SonarQube instance equipped with the Sonar Crypto plug-in. The identified cryptographic uses are then stored in the CBoM Kit database.
2. Third-Party Dependency CBoM Scan: An SBoM (dependency list) is generated for the project. The pipeline parses this SBoM for PURLs. For each PURL, it checks the CBoM Kit database to see if a CBoM for that specific package already exists. If not, a new scan is invoked to generate a CBoM for that third-party dependency, which is then added to the database.

Current limitations include the restricted language and library coverage of the Sonar Crypto plug-in, requiring ongoing development. Additionally, the CBoM Kit currently lacks project and user management features, meaning all CBoMs are stored in a single flat structure, which needs improvement for enterprise-scale deployment. Despite these, this pipeline represents a significant step towards automated, comprehensive cryptographic inventory management, crucial for informed PQC migration.

Demo / Proof of Concept

▶ Watch: Cubit extrapolation, Q-day prediction, and regulatory reactions (6:00)

Katarina Amrichova presented two distinct but interconnected proofs of concept, demonstrating both the technical feasibility of integrating PQC and the necessary tooling for managing a large-scale transition.

The first demonstration involved the PQC-secured DICOM communication prototype. This PoC showcased a client-server setup where DICOM messages were exchanged, with the entire communication wrapped in a TLS layer enhanced with PQC. The visual evidence presented was a Wireshark capture of the network traffic. This capture prominently displayed the server hello message during the TLS handshake, containing a key share entry specifically identifying Kyber 768. This confirmed that the PQC algorithm was successfully negotiated and used for the key exchange, signifying a quantum-secure channel for medical image transmission. This prototype, potentially "one of the first PQC secured DICOM exchanges ever," illustrated the practical integration of PQC into a critical healthcare protocol using DCMTK, OpenSSL, and the OQS provider.

The second proof of concept detailed the Crypto Bill of Materials (CBoM) generation pipeline. This demonstration focused on the automated process for discovering and cataloging cryptographic algorithms within software. The pipeline, built in Azure DevOps, integrated open-source tools from IBM Research: the Sonar Crypto plug-in for static analysis and the CBoM Kit for data management. The speaker described the two-part process:

1. Scanning the project's own code: The pipeline builds the project, sends it to a SonarQube instance with the Sonar Crypto plug-in, which identifies crypto invocations (currently for Java and Python, with specific libraries like crypto, Bouncy Castle, JCA, and Tink).
2. Scanning third-party dependencies: The pipeline generates an SBoM (dependency list), parses it for PURLs (package URLs), and queries the CBoM Kit database. If a CBoM for a specific dependency doesn't exist, a scan is initiated to generate it.

While no live demo of the pipeline execution was shown, the detailed explanation of its architecture and workflow, coupled with the identification of specific tools and their functionalities (e.g., Sonar Crypto's language/library support and ongoing development), effectively demonstrated the methodology and capability for building comprehensive cryptographic inventories. This PoC highlighted the foundational work required to understand an organization's cryptographic attack surface before embarking on a PQC migration.

Defensive Implications

▶ Watch: Siemens Health's PQC transition timeline: awareness and prototyping (8:00)

The insights from Katarina Amrichova's talk provide a clear mandate for defenders, particularly within the healthcare sector, to proactively address the quantum threat. The proposed steps form a comprehensive strategy for PQC transition:

1. Spread Awareness: This is the foundational step. Organizations must educate all internal stakeholders—developers, project managers, cybersecurity personnel—about PQC, the "Q-day" threat, and the "harvest now, decrypt later" risk. Equally important is engaging external third-party suppliers, as many critical systems rely on third-party components where cryptographic choices are outside direct control. Negotiations and discussions with these suppliers about their PQC roadmaps should begin immediately.

1. Implement Prototypes and Proofs of Concept: As demonstrated by the DICOM PQC prototype, theoretical PQC readiness does not guarantee seamless integration. Defenders must initiate internal prototypes to understand how PQC algorithms (especially their larger key sizes) interact with existing network infrastructure, middleware, and application layers. This will help identify potential issues like fragmentation failures and inform necessary remediations and fallback plans, preventing widespread communication failures when PQC is eventually deployed. Focusing initially on Key Exchange Mechanisms (KEMs) for confidentiality is crucial to mitigate the "harvest now, decrypt later" threat from passive adversaries.

1. Develop Crypto Bill of Materials (CBoMs): To effectively prioritize PQC transition efforts across complex software portfolios, organizations need a clear understanding of their cryptographic footprint. Defenders should invest in building CBoMs by combining Static Application Security Testing (SAST) and Software Composition Analysis (SCA) capabilities. This involves enhancing existing SAST rules to detect all types of cryptographic usage, not just vulnerabilities, and scanning both proprietary code and third-party dependencies. Tools like the Sonar Crypto plug-in and CBoM Kit can serve as a starting point, but organizations should be prepared to contribute to their development or build custom solutions to achieve comprehensive coverage across all programming languages and libraries in use.

1. Perform Threat and Risk Analysis with Quantum in Mind: Once CBoMs are established, defenders can conduct targeted threat and risk analyses. This analysis should consider the "Q-day" timeline, the data shelf life, and the system lifecycle of each component. This will enable data-driven prioritization, ensuring that the most critical and long-lived systems are transitioned to PQC first.

1. Advocate for and Monitor Language/Library Support: The PQC transition is heavily dependent on the underlying software ecosystem. Defenders should monitor and advocate for native PQC support in programming languages and cryptographic libraries they utilize (e.g., OpenSSL, .NET). While some libraries like OpenSSL already offer good PQC support, others are still evolving, and native PQC support at the TLS layer is not yet universal. This external dependency requires ongoing engagement and strategic planning.

1. Prepare Strategic Documentation and Directives: To ensure widespread adoption and consistency, organizations must develop strategic documents, directives, and guidelines that mandate the use of PQC-ready tools and processes. This includes requiring business lines to generate CBoMs, perform quantum-aware risk assessments, and incorporate PQC into new development and updates. This can only be effectively enforced once the underlying tools and language support mature sufficiently.

1. Consider Intermediate Network Layers for Legacy Devices: For legacy medical devices with extremely long lifecycles that cannot be easily updated, a potential defensive strategy could involve implementing an intermediate network layer or wrapper. This layer would intercept outgoing TLS communication from the device and transform it into PQC-secured communication before it leaves the local network, effectively backporting quantum resistance without modifying the device itself. While not explored in depth, this highlights the need for creative solutions for embedded and long-lived systems.

By implementing these defensive strategies, healthcare organizations can proactively fortify their systems against the quantum threat, ensuring the long-term confidentiality and integrity of sensitive patient data and critical medical infrastructure.

Key Takeaways

• Healthcare is uniquely vulnerable to quantum attacks: Due to exceptionally long data shelf lives and system lifecycles (e.g., MRI machines for 30-50 years, patient data for decades), the "harvest now, decrypt later" threat poses an existential risk to the confidentiality of sensitive medical information.
• Proactive PQC adoption is imperative, driven by regulation: While "Q-day" (the advent of a cryptographically relevant quantum computer) is projected around 2040, regulatory bodies like CNSA 2.0 are already mandating PQC. The FDA is expected to follow, making early transition crucial for compliance and long-term security.
• Prototypes are essential to uncover integration challenges: Early PQC implementations, like the DICOM prototype, are vital for identifying practical issues such as large PQC key sizes causing network fragmentation and middleware failures. This hands-on experience allows organizations to develop necessary remediations and fallback plans before widespread deployment.
• Crypto Bill of Materials (CBoMs) are critical for prioritization: Building comprehensive CBoMs, which list all cryptographic algorithms and libraries within software and its dependencies, is fundamental. This requires combining SAST and SCA capabilities, as no single tool currently provides full coverage, enabling data-driven threat and risk analysis for prioritizing PQC migration.
• Initial focus on Key Exchange for confidentiality: To counter passive "harvest now, decrypt later" attacks, the primary focus should be on implementing quantum-secure Key Exchange Mechanisms (KEMs) to protect the confidentiality of communications. Quantum-secure digital signatures for authentication will become a more pressing issue once active quantum attacks are feasible.
• PQC transition requires a multi-faceted, strategic approach: Successful migration involves spreading awareness, developing prototypes, building specialized tooling (CBoMs), performing quantum-aware risk assessments, advocating for language/library support, and establishing strategic documentation and directives across the organization.

About the Speaker(s)

Katarina Amrichova is a Cyber Security Researcher at Siemens Health. She has dedicated four years to Siemens Health, initially starting her journey as an ethical hacker with a focus on reverse engineering. Her passion for research led her to explore topics such as homomorphic encryption, a technology she considers the "holy grail of cryptography" for its ability to perform computations on encrypted data. This research interest eventually transitioned into her current role, where she now specializes in post-quantum cryptography. Amrichova's connection to computers dates back to her early childhood in the 2000s, where she fondly recalls playing games on a Windows 98 machine and interacting with Clippy, whom she still considers her "best debugging buddy." Her diverse background and deep-seated interest in cybersecurity have positioned her as a key contributor to Siemens Health's efforts in preparing for the quantum computing era.