[IACS UR E27] Untrusted Network – 38 Cryptographic Integrity Protection

IACS UR E27 - Cryptographic Integrity Protection

 

**Your ship is transmitting engine data to shore right now. Can you prove nobody tampered with it in transit?**

Most maritime engineers would say "yes, we have checksums." That answer is no longer good enough.

 

**What UR E27 Demands**

When a Cyber-Based System communicates over an untrusted network, IACS UR E27 requires cryptographic mechanisms to verify data integrity — not just detect errors. Basic checksums or CRC values only catch accidental corruption. Against an active adversary on an untrusted network, they offer zero protection. This requirement draws directly from IEC 62443-3-3 SR 3.1 RE1 and applies to every OEM remote monitoring session and every shore-based management connection your vessel maintains.

 

**Why This Matters at Sea**

Consider a vessel's performance management system streaming fuel consumption and engine parameters to a fleet operations centre. A man-in-the-middle attacker positioned on a shared satellite link can silently alter those values — skewing analytics, masking a developing fault, or feeding false data into maintenance decision systems. The data arrives intact by every superficial measure. Only cryptographic verification would reveal it was touched.

 

Multiply this across ECDIS updates, ballast water management reporting, and remote diagnostic sessions and the operational stakes become clear. Corrupted data you trust is considerably more dangerous than no data at all.

 

**The IEC 62443-3-3 Technical Foundation**

SR 3.1 RE1 is the SL-3 and SL-4 enhancement to the baseline communication integrity requirement. At these security levels, the standard explicitly rules out non-cryptographic approaches. The technical distinction matters:

→ CRC and basic hashes detect accidental change but provide no tamper evidence

→ Cryptographic MACs (Message Authentication Codes) bind data to a secret key, making undetected modification computationally infeasible

→ TLS, HMAC, or digital signatures are mandatory — not optional controls

 

Certificate pinning is also recommended practice here, preventing an attacker from substituting a fraudulent but technically valid certificate to intercept a session silently.

 

**The Implementation Reality**

The hardest challenge in maritime OT is not deploying TLS — it is the legacy OEM equipment that communicates over proprietary protocols with no native cryptographic support. In these cases, a cryptographic gateway or protocol wrapper at the network boundary becomes necessary, ensuring the untrusted-network leg of every connection meets SR 3.1 RE1 regardless of what the end device natively supports.

 

Has your vessel's remote access architecture been reviewed specifically for cryptographic integrity coverage — or just for authentication controls?

 

IACS UR E27

📌 Post 38/41 in my IACS UR E27 series — breaking down all 41 requirements