When the Attacker Holds the Hardware: Securing a Vessel That Can Be Captured

Most cybersecurity is written on the comforting assumption that your computers sit safely in a locked building or a guarded data centre. The attacker is far away, poking at your defences over the internet. Autonomous vessels break that assumption. A vessel operates alone, sometimes far from help, in waters where a determined party could physically reach it, disable it, and take it away. Once that happens, the attacker isn’t knocking on the door – they’re holding the whole house.
This is one of the things that makes securing an autonomous vessel closer to protecting a defence system than a typical business application. The design has to answer an uncomfortable question honestly: if someone takes this vessel and takes it apart at their leisure, what can they learn, and what can they do with it?

The problem with secrets on a stolen machine

Every connected vessel holds secrets — the cryptographic keys that let it prove its identity and unlock its communications. Those secrets are exactly what protect it from remote takeover, as we saw in Post 2. But if the vessel is captured, those same secrets are sitting inside a machine the attacker controls completely. If they can extract the keys, they might impersonate the vessel, decrypt its stored data, or use it as a way into the wider fleet. The strength that protected the vessel at sea becomes a liability the moment it’s in the wrong hands.

Encrypting the vessel’s memory

The first line of defence is to encrypt the vessel’s storage, so that the information on its drives is scrambled and useless without the right key. This is the same idea as locking your phone: even if someone holds the device, they can’t read what’s on it. But it raises an immediate question. If the drive is locked, something has to unlock it when the vessel powers up — and that vessel is at sea, with no human to type a password. Where does the key to unlock the vessel come from?
This is the central design problem, and it has a good answer: make automatic unlocking depend on conditions an attacker cannot reproduce. Tie the unlock to specific, tamper-resistant hardware, so that the drives stay locked in any other machine. Tie it to the vessel’s continued membership of its fleet, so that hardware removed from its normal operating environment refuses to give up its secrets. The vessel unlocks itself at sea. It does not unlock itself in a stranger’s workshop.

Hardware that guards its own keys

A powerful tool here is specialised security hardware — a small, tamper-resistant chip whose entire job is to hold secrets and never hand them over. Rather than storing a key as an ordinary file that could be copied, the vessel stores it inside this chip. The chip will perform operations using the key — signing a message, unlocking a channel — but it is built so that the raw key itself can’t be read out, even by someone who has the physical device and the patience to probe it. It’s the difference between writing your password on a sticky note and keeping it in a safe that will only ever confirm “yes, that’s correct” without ever showing you the contents.
This hardware also gives each vessel a strong, unique identity that can’t be cloned. When a vessel connects to the fleet, that identity is rooted in its physical chip — so a counterfeit vessel, or a stolen one that has been tampered with, can be recognised and shut out.

Limiting the blast radius

The final principle is containment. Even with the best protections, you plan for the possibility that one vessel is compromised, and you make sure that one loss doesn’t cascade into a fleet-wide disaster. Each vessel holds only its own credentials, not the keys to the kingdom. Compromising one vessel should teach the attacker almost nothing about the others. If the worst happens, the compromised vessel’s access can be revoked — its credentials struck off the list — so that even with the physical hardware in hand, it can no longer participate in the fleet