Towards Hardware-Governed Benchtop DNA Synthesizers

I found the problem and framing to be quite good in presentation. There was some jargon used from the hardware/AI/cyber-security side, but I think most could follow. I thought the connection to printer ink cartridge authentication was a clear example, and I think more analogues or exemplars could have been used in other proposal areas.

Since this was an evaluation and under a time-limit, the designs are understandably conceptual, and Figure 1 provides useful context. However, an additional diagram(s)/table(s) illustrating the broader threat landscape and potential failure points would have been nice.

One area that was neglected is how calibration, maintenance protocols, and service contracts would fall into this design (ex. how might calibration drift affect pipetting or volume-detection and then be adjusted). This would likely be an area where security could be firmed up, but it would be useful to identify where it may provide failure-points or access to bad-actors.

With the increasing accessibility of benchtop synthesizers, knowing how to mitigate the synthesis of sequences of concern is vital. This paper gives concrete recommendations for screening and authorization in a benchtop synthesizer and how to prevent tampering of the synthesizer. The recommendations against tampering were interesting and well worth consideration.

However, I found the recommendations for screening and the requirement for the regulator to pre-approve each sequence to be impractical. The vast majority of sequences are benign, and having them require approval would be a huge burden. Rather, sequences with high homology with sequences of concern should be pre-authorized only. There was also little data to validate the approaches. Recommendations on how the screening tool can be updated without tampering and how it would handle AI-generated oligos would have been useful as well.

This is a nice set of countermeasures, but there's an unfortunate

feasibility problem with the entire idea: Having personally advised

benchtop vendors on their machine security, it's apparent that even

spending the small amount of extra money it takes for a single-board

computer which allows adding a TPM chip (as opposed to ones which

don't even have a place on the board one may be attached) isn't

something vendors are going to do unless forced, such as via

legislation. Expecting them to do a good job about secure boot chains

and the like isn't likely in the near future absent some way to make

this a commercial priority, much less adding all kinds of hardware

to check that the machine is producing what it thinks it's producing.

It would be *very nice* if vendors really did this, but absent

incentives, the chances of vendors actually incorporating any of

these ideas seems near zero. (And it's not just the hardware;

doing security *right* takes expertise, which isn't the core

competency of a synthesizer producer, and hiring those people

also takes money. So the problem here is the incentives.)

As for the technical details:

(a) The guarantee processor seems to have all kinds of issues re

vulnerability to attacks, staleness, revelation of nonpublic hazards,

cost, etc, mostly because you're having it recapitulate the work of

screening a second time; this seems to make it large and with a large

attack surface. In particular, asking the GP to recompute the DOPRF

means asking it to be at least as powerful as the main CPU in the

benchtop. Given that you're citing SecureDNA's system here (which

was designed for benchtops), what you should probably do instead

is to take advantage of the "verified screening" mode, which

cryptographically signs over the results and a hash of the input

sequence. Then the GP need only check that signature, along with the

other state-of-the-machine verification it's already tasked to do.

(b) The ping time-of-flight isn't novel (not your problem but that of

the paper you cite); it's quite old. But the problem with it in the

case of benchtops is that you're at the mercy of the typically

terrible network infrastructure of random labs, which often have very

high latency and jitter (for all you know, the benchtop is on a

wireless network) and also tends to disenfranchise non-first-world

labs because their bandwidth is typically even worse. (It's even

worse if it's also competing with the network traffic from running the

SecureDNA protocol or of any other high-usage devices on that lab's

network.) Depending on ping times is a good way to randomly inhibit

legitimate synthesis due to poor infrastructure. ("AI chips" are

likely being run in a first-class data center, which is an *entirely*

different network environment than the typical university biolab.)

(c) Reagent verification is a nice idea, but again, expensive.

That's unfortunately the crippling flaw with most of the things

presented here, even if we wish is weren't so.

(d) Locking cartridges so they can't be rearranged also runs into the

same failure mode as use of crypto (and the DMCA's anti-circumvention

provisions) in the printer market: extreme vendor lock-in. This is

a problem for customers and not all courts have looked favorably on

the very concept, for precisely that reason. In the case of reagent

swaps in particular, the SecureDNA system is resilient to them: its

screening already accounts for that possibility and checks all 2! = 24

permutations simultaneously at zero additional computational overhead.

(This doesn't lead to an increase in false positives because DNA is

very non-random.)