Tessera for Windows — Standards-Compliant Data-Centric Security

The Problem with Perimeter Security

Traditional network-perimeter security works well when all sensitive work happens inside a controlled boundary. In practice, that boundary is constantly crossed: files are shared with coalition partners, archived on removable media, sent by email, or moved to systems outside the organisation's direct control.

When a file leaves the perimeter, it leaves behind the access controls that were protecting it. At that point there is nothing stopping an unauthorised recipient from reading it — or an authorised one from forwarding it further.

          Data-centric security inverts this model. The protection is not
          in the boundary around the data — it is embedded in the data itself. A
          .ztdf archive can only be decrypted by a Key Access Service that
          has evaluated the requester's attributes against the embedded access policy.
          The policy enforces itself regardless of where the file travels.
        

Perimeter Model

Inside network boundary

Secret file — protected

File crosses boundary

No protection — policy lost

Partner / archive / cloud

Anyone can read

Data-Centric Model

Inside or outside boundary

file.ztdf — encrypted + policy bound

File crosses boundary

Still encrypted + policy bound

Decryption attempt

KAS evaluates policy — ALLOW or DENY

How It Works

Three phases, standards-defined at every step.

Protect

The file is encrypted with AES-256-GCM. A unique Data Encryption Key (DEK) is generated per file, then wrapped with the KAS public key using RSA-OAEP-SHA256. The ABAC access policy — classification level and releasability attributes from the STANAG 4774 label — is bound to the DEK with an HMAC and stored in the manifest. The STANAG 4778 Binding Data Object (BDO, CMS SignedData) ties the label to the content with a digital signature.

Travel

The result is a .ztdf archive — a ZIP container holding the encrypted payload, the manifest (policy + wrapped DEK), and the STANAG 4774 Confidentiality Label with its ADatP-5636 Object Classification Label (OCL). The archive is completely self-describing. It can be stored, forwarded, archived, or transferred to any other system — the access policy travels with it and cannot be stripped without invalidating the signature.

Enforce

When a user attempts to open the file, the local Tessera service sends a rewrap request to the Key Access Service. The KAS verifies the STANAG 4778 binding, evaluates the embedded ABAC policy against the requester's clearance attributes (from the identity token), and either releases the DEK or returns a denial. Decrypted content is never written to disk — it is held in memory only, through a virtual file system driver.

Architecture

Tessera for Windows is a layered system. The Windows-side components handle the user experience and local operations. The backend components handle identity, policy, and key management.

The local service runs as a Windows service and exposes a local API. Office add-ins and the Explorer context menu communicate exclusively with the local service — they never contact the KAS or management service directly. This means the backend can be deployed in an isolated network segment without exposing it to the desktop.

The Key Access Service is stateless: it holds only the KAS private key (used to unwrap the DEK) and its SPIF-driven policy. No plaintext is ever stored or logged. The management service holds audit records and KAS configuration, but never holds decryption keys.

Windows desktop

Word Excel PowerPoint Outlook Explorer extension

↓local API

Tessera.Service

↓

Key Access Service

/rewrap — policy evaluation
/kas_public_key
/spifs — SPIF v2.1 / v3.0
/ca — label-signing CA

↓

Management Service

KAS registration
User / domain / policy config
Audit log

↓

Identity Provider

OIDC / JWKS
User attributes & clearance

Windows Components

Office Add-ins

VSTO add-ins for Word, Excel, PowerPoint, and Outlook. Integrate classification label selection, document protection, and label-aware send enforcement into the native Office ribbon. Outlook enforces that emails carry a valid label before sending.

Windows Explorer Integration

Context-menu entries for Protect with Tessera and Open Tessera File on any file type. Enables .ztdf encryption and transparent decryption without leaving the Windows shell.

Local Windows Service

A Windows service that orchestrates all local operations: encryption, decryption, label construction, DSIG verification, KAS communication, and the SPIF-driven attribute URI mapping. The single point of contact for all Windows-side components.

Backend Components

Key Access Service (KAS)

Server-side service implementing the ACP-240 KAS role. Holds the KAS RSA private key, evaluates ABAC policies derived from the embedded SPIF, and releases Data Encryption Keys only after positive policy evaluation. Supports multi-domain scenarios with domain-scoped ABAC.

Management Console

Web application providing operator access to KAS configuration, user management, domain and SPIF administration, policy review, audit log, and PKI certificate management. Secured with OIDC.

Identity Federation

OIDC identity provider. Stores user clearance attributes (classification level, category authorisations) as claims issued in the JWT access token that the KAS validates on every key-release request.

Security Characteristics

AES-256-GCM payload encryption — authenticated encryption with a unique DEK per file; the GCM tag detects any tampering with the ciphertext.
RSA-OAEP-SHA256 key wrap — the DEK is wrapped with the KAS public key. Only the KAS holding the corresponding private key can unwrap it.
HMAC-bound ABAC policy — the access policy is bound to the wrapped DEK by HMAC. Altering the policy invalidates the binding and the KAS will refuse the request.
STANAG 4778 XML-DSIG label binding — the STANAG 4774 Confidentiality Label is signed against the content hash. Any modification to the label or the payload breaks the signature.
Zero plaintext on disk — decrypted content exists only in memory. A Windows kernel driver exposes it as a virtual file system; no cleartext is ever written to the filesystem or swap.
SPIF-driven ABAC — policy attributes are derived from the XMLSPIF. Classification and category values map to attribute URIs that must be present in the user's identity token.

Standards Implemented

ACP-240

Zero Trust Data Format

The .ztdf archive format and key-access protocol.

STANAG 4774

Confidentiality Labels

XML Confidentiality Label schema; classification level and categories.

STANAG 4778

Binding Data Object (BDO)

CMS SignedData label-to-content binding; ADatP-4778.2 profiles for OOXML, XMP, and sidecar.

ADatP-5636

Object Classification Label (OCL)

JSON OCL record; portioning marking strings, document-level and portion-level marks.

XMLSPIF v2.1/3.0

Security Policy

SPIF parsing for policy-driven attribute URI mapping and ABAC.

RFC 8785

JSON Canonicalisation

JCS-canonical form for deterministic HMAC computation over manifest.

View full standards reference →