Verifiable Science on Modified PCR Machine

Scientific fraud kills. At Duke, 117 cancer patients received wrong treatments due to fabricated data. At Harvard, fake cardiac stem cell research led to years of invalid clinical trials. At Brigham and Women's, fictional pain studies changed treatment protocols nationwide.

These aren't isolated incidents. They represent a systemic problem: in biomedicine, there's currently no way to verify that published experimental results match the raw data from lab instruments.

Solving The Problem (We Hope)

We set out to take a widely-used piece of scientific equipment and make its results cryptographically verifiable, preventing result falsification. We chose PCR (Polymerase Chain Reaction) machines - the workhorses of molecular biology that detect DNA sequences in samples, used in everything from COVID testing to cancer research. By adding cryptographic signing directly to the instrument, results can't be altered after they're generated.

Think of it as a digital notary for your PCR machine - once a result is signed, it can't be altered without detection.

The Horrific Technical Struggle

Scientific equipment is notoriously difficult to modify. The ThermoFisher 7500 Fast, for instance, can only be operated using a Windows XP application that relies on proprietary drivers. Rewriting its firmware to work with a secure operating system risks damaging this $25,000 machine’s precise thermal control and optical systems. This did not stop us. We ran the original PCR software inside a locked-down Windows XP virtual machine -- which itself is hosted within a Trusted Execution Environment (TEE). This setup lets users operate the PCR machine via the familiar 7500 application interface, while the virtualized XP environment is stripped of any additional functionality (attempts to modify test results are effectively blocked). The data is then automatically exported from the VM via a virtual serial bus, then cryptographically signed by the TEE’s secure element and made accessible via an instance of SSH running on the host operating system.

This approach may be extended to many types of scientific equipment, regardless of how old they are.

Key Security Features

• Cryptographic signing of all test results via the Zymbit (TEE) secure element
• Tamper-evident resin seals on all connections and access points
• Any attempts to open or modify the machine result in visible damage to security seals
• Secure boot and runtime attestation of the control software

The (Minor) Catch

The system is designed for use in supervised laboratory environments where sample chain of custody is maintained. While the machine can't prevent sample swapping before testing, it ensures that once a sample is tested, the results cannot be manipulated.

Future versions will incorporate sample ID verification and process recording, reducing the risk of sample swapping or improper measurement procedures.

Toward Verifiable Science

This project is a first step toward a future where scientific results are cryptographically verifiable from instrument to publication. Imagine:

• DNA sequencers that produce verifiable genome data
• Clinical trial data that can be traced back to original instruments
• Journals that require proof of raw data

By starting with PCR - one of the most widely used and frequently manipulated techniques in biology - we're creating a template for how other scientific instruments can be modified to produce trustworthy, verifiable data.

Pictures Of The PCR Machine Working With Zymbit

Modified ThermoFisher Scientific 7500 Fast

The current implementation modifies a ThermoFisher Scientific 7500 Fast real-time PCR system by integrating a Zymbit secure element.

System Architecture

This system addresses a fundamental challenge in digital laboratory equipment: how do we ensure that test results haven't been falsified or tampered with?

Core Security Model

There is a one-way flow of information:

[PCR Machine] → [Sealed VM Environment] → [Virtual Serial] → [Host System]

This entire chain of execution occurs in tamper-evident environment.

The integrity of the environment is guaranteed by tamper-evident seals on all connections, and the use of Secure Boot within the Zymbit.

Data Flow Pipeline

1. Generation

   • PCR tests run within the isolated Windows XP VM
   • Results are generated by unmodified ThermoFisher software
   • The OS is locked-down, has no network access and can't install additional software
   • We're assuming that, in this heavily locked-down setting, the user has no ability to tamper with the results

2. Transport

   • The VM may forward results to the host system via a virtual serial channel
   • The channel is unidirectional: data can only flow out of the VM
   • The data is stored securely in the host, within a protected directory
   • We make use of cgroups and other isolation mechanisms to keep this safe

3. Attestation

   • The host's attestation daemon (attestation_daemon.py) receives results
   • Each result is immediately signed (soon using the Zymbit secure element)
   • Signatures are created using Ed25519 public-key cryptography
   • The private key will never the hardware security module

4. Storage & Access

   • Signed results and their signatures are stored in a protected directory
   • Files can only be added, never modified or deleted
   • Results can be verified using the system's public key
   • Access is provided through the read-only SSH account

Guaranteeing Integrity

1. Physical Security
   The PCR machine and Zymbit module are physically sealed with tamper-evident resin. Any attempt to modify the hardware or inject false signals leaves visible evidence.

2. Virtualization Barrier
   The PCR software runs in a pristine Windows XP environment that:

   • Resets to a known-good state on every boot via Windows SteadyState
   • Has no network access or ability to install additional software
   • Can only communicate results through a single, monitored virtual serial channel
   • Is accessible only through SPICE protocol for direct operation

3. Cryptographic Attestation
   Results follow a one-way path:

   • Generated by the PCR software
   • Transmitted via virtual serial to the host
   • Immediately signed using the Zymbit hardware security module
   • Stored in a write-once, read-many directory

Access Control

The system enforces strict role separation through three highly-restricted user accounts:

• SPICE Access (7500Fast)
  Allows operators to run tests by tunneling the SPICE protocol over SSH. This account:

  • Has no shell access
  • Can only forward the SPICE port
  • Requires key-based authentication

• Results Reader (result_reader)
  Provides secure access to signed results via SSH. This account:

  • Has read-only access to the results directory
  • Cannot modify or delete existing results
  • Requires key-based authentication

• WiFi Configuration (wifi_setup)
  Allows network setup through a restricted interface. This account:

  • Has no password
  • Can only run the nmtui network configuration tool
  • Cannot access any other system functions

The Codebase

├── README.md                           
├── Taskfile.yml                        # Build Automation
├── access-ui.sh                        # Use This To Connect To The Machine!!
│
├── 7500FastXP/                         # Windows XP VM componentsv
│   ├── HOW.md                          # Documentation
│   └── service.py                      # Windows Service For Transferring Results To Host For Signing
│
├── zymbit_image/                       # Raspbian Image Customization
│   └── scripts/                        
│       ├── 00-prelude.sh               # System Hardening
│       ├── 01-tailscale.sh             # VPN Setup
│       ├── 02-qemu.sh                  # VM Environment Setup
│       ├── 03-7500FastXP.sh            # VM Deployment
│       ├── 04-attestation_daemon.sh    # Result Signing Service Setup
│       ├── 05-create_users.sh          # User Management
│       ├── 06-clear_apt_cache.sh       # Cleanup
│       └── files/                      # Configuration files
│           ├── attestation_daemon.py   # Result Signing Daemon
│           └── vm/                     # VM Configuration Files
│               ├── 7500FastXP.xml      # VM Definition
│               └── 7500FastXP          # VM Disk Image
│
└── patch_over_ssh/                     # Remote Management Tools
    ├── add-auto-configure-to-zymbit.sh # Remote Setup Script
    ├── harden-ssh-zymbit.sh            # SSH Security Configuration
    └── script.py                       # Remote Configuration Utility

How Do I Build The Raspberry Pi Image?

There's a Taskfile in this repository that you can use to run the update scripts locally.

• Install Taskfile
• Install Docker
• Create a workspace directory and place your input.img in that
• Run task build

Alternatively, you can also manually run docker:

docker run --rm --privileged -v $(pwd)/workspace:/CustoPiZer/workspace $(pwd)/zymbit_image/scripts:/CustoPiZer/workspace/scripts ghcr.io/octoprint/custopizer:latest

What's Next?

• Integration With Our Own CA.
• Cross-Verifying Results Against What Enters The Unit.
• Increasing The Level Of Auditability, Security On Zymbit.
• Hardening The Windows XP Image.

Acknowledgements

Much of this software was written and designed by Arbion Halili (@ToxicPine on GitHub).

We thank Causality Network for their consistent support, particularly for providing the PCR machine!