Platform security model

Understand VOS3 domain separation, secure boot, tamper handling, and protected card data flow.

VOS3 protects the platform through hardware separation, verified startup, and restricted access to sensitive services.

Use this page to understand the core security architecture and tamper behavior.

Domain separation

VOS3 uses a dual-processor architecture.

This physically and logically separates the most sensitive functions and assets, including PIN data and plaintext keys, from the application processor environment.

The application processor also uses privilege separation.

This limits the impact if any single component is compromised.

Secure boot and system verification

All images up to and including the application boot loader are verified during secure boot using cryptographic authentication.

The Linux kernel image and initramfs are also verified during secure boot.

User space software, including applications, is verified by the Verifier module.

The Compromise Detection Daemon checks device integrity, records tamper state, and triggers the 24-hour automatic reboot process.

A reboot is also triggered when tamper is detected during operation.

Files and related resources are protected through Linux discretionary access control and capabilities.

Tamper state

When the device detects a physical tamper event or a logical security alert, it enters tamper state.

In tamper state, the device shows a tamper banner during boot and then provides access to the MAC desktop.

From there, the operator can open the Security Panel and review the tamper log.

When tamper occurs:

• the internal system key is deleted
• installed warrantied and customer keys are invalidated
• some security functions are blocked

To clear tamper, connect the device to a trusted key-loading device and reload the warrantied keys.

Protected cardholder data flow

On VOS3, the SDI server is always present.

It manages the interface to the secure processor and protects cardholder data by default.

This enables support for P2PE-style cardholder data protection.

Payment and sensitive card data are not provided in clear text by default.

You can leverage SDI P2PE support only when you stay inside the SDI protection model.

If you load the vos3-cards plugin or otherwise bypass SDI protection, you cannot rely on SDI P2PE certification.

The ADK client libraries still expose familiar interfaces.

On VOS3, those interfaces connect through SDI rather than bypassing it.

The SDI server runs as a system process and continues to encapsulate cardholder data by default.