Forseti: Programmable Policy Enforcement | Cyber Immunity Whitepaper

Overview

This document specifies Forseti, the programmable policy engine of the Tide Cybersecurity Fabric. Forseti governs whether an authority action proceeds. Every threshold operation - decryption, signing, blind delegation, verifiable randomness - passes through Forseti before any ORK contributes its partial MPC computation.

In traditional IAM, authorization policy runs at the application layer: software guards evaluate a JWT before passing the request to a KMS or database. A sufficiently privileged attacker can bypass these guards and invoke the key directly. Forseti eliminates this vulnerability by moving authorization logic inside the cryptographic authority. Each ORK independently loads and executes a deterministic C# contract in a sandboxed environment. If the contract fails, the ORK cannot produce its partial computation. The policy is not a gate in front of the key - it is a precondition of the key's operation.

The protocol defines the Policy:1 authorization flow: policy commitment → Doken issuance → request construction → sandboxed 3-stage validation → threshold MPC output. The relationship to the sibling protocol is: Forseti decides; Hermetic E2EE (and other authority actions) executes. The three validations visible in the decryption flow - ValidateToken_A(V), ValidateSignature_k(T_{1..n}), CheckTags(T_{1..n}, T_{1..x}) - are Forseti operations. This protocol specifies the engine that runs those validations; the sibling protocol specifies what the ORK computes after the engine passes.

Loading diagram...

Preconditions

The Doken (Delegated Authority Token)

The Doken is the authorization instrument that bridges the user's authenticated session to the ORK swarm. Unlike a JWT (which authorizes the user to the application server), the Doken authorizes the SWE directly to the Fabric for cryptographic operations. The Doken and JWT are issued simultaneously during token exchange but travel different paths: the JWT targets to the application server via standard OIDC, while the Doken targets direct ORK communication.

Artifact	Description
Doken	VVK-signed delegated token, issued alongside the JWT during OIDC token exchange
`Doken.sessionKey` / $B$	Ephemeral session public key ( $B = G \cdot b$ ), binding the token to the current SWE session
`Doken.roles`	Roles and permissions from quorum-approved authorization proofs (Article 5)
`Doken.expiry`	Session-scoped time limit
`Doken.signature`	VVK threshold signature - each ORK can independently verify the Doken was signed by the vendor's ineffable key

The Forseti Contract

Artifact	Description
Contract source	C# source code implementing the `IAccessPolicy` interface
Contract ID	$\textsf{SHA512}(\text{source code})$ - deterministic, tamper-evident. A single-character change produces a new ID.
Policy type	`PUBLIC` (ValidateData only), `EXPLICIT` (+ ValidateApprovers), or `PRIVATE` (+ ValidateExecutor)
Policy parameters	Configuration values bound via `[PolicyParam]` attribute (e.g., required roles, resource IDs)

The BaseTideRequest

Artifact	Description
`BaseTideRequest`	Generalized DTO: request ID, authorization flow ID (`"Policy:1"`), challenge data, and metadata
Authorized Payload	The payload to be processed (e.g., ciphertext to decrypt, message to sign, SSH challenge)
Informational Payload	Additional informational data in the request not signed by an Approver
Policy	Section of the `BaseTideRequest` DTO reserved for adding a Policy to be executed against an uploaded Forseti Contract

Forseti Contract Lifecycle

Phase 1: Policy Definition and Commitment

Loading diagram...

Contract commitment follows the quorum-enforced governance workflow (Protocol: Authorization Proofing). No single admin can deploy a contract. The deterministic Contract ID (

\textsf{SHA512}

of the C# source) ensures all 20 ORKs execute identical logic - if any ORK has a different version, the ID mismatch prevents execution.

Phase 2: Authentication and Doken Issuance

Loading diagram...

This establishes the two-channel architecture: the JWT flows to the application server for standard API authorization; the Doken flows to the SWE for cryptographic agency against the Fabric. The application server never gains authority to command the ORK swarm. A compromised application server can read the JWT (standard OIDC) but cannot forge a Doken (VVK threshold signature required) and cannot intercept or replay a Doken (session key binding prevents use from a different connection).

Phases 3-5: Request, Validation, and MPC Output

Loading diagram...

The SWE dispatches the request directly to all 20 ORKs via POST /Key with the Doken as a bearer token, bypassing the application server entirely.

Phase 4 detail - Outer Gate: Before loading the Forseti contract, each ORK validates the Doken itself (see Algorithm 1). This is a systemic check: is the Doken authentic (VVK-signed), session-bound (connection encrypted with the Doken's session key

B

), and hasn't expired? Only if the Outer Gate passes does the ORK instantiate the sandboxed execution environment.

Phase 4 detail - Inner Gate: The ORK loads the contract identified by the Contract ID, instantiates an isolated VmHost process, and executes the 3-stage validation lifecycle (see Algorithm 2). Each Forseti contract is configured along two independent settings that determine which validation stages execute:

Setting	Values	Effect
Approval Type	`IMPLICIT` or `EXPLICIT`	`EXPLICIT` activates Stage 2 (ValidateApprovers): $M$ -of- $N$ multi-party authorization for the requested operation
Execution Type	`PUBLIC` or `PRIVATE`	`PRIVATE` activates Stage 3 (ValidateExecutor): the requester's Doken is evaluated against the specific resource being accessed

Stage 1 (ValidateData) always runs regardless of configuration. The two settings are independent: a policy requiring both multi-party approval and executor role verification sets EXPLICIT + PRIVATE, causing all three stages to execute in sequence. A policy requiring only data validation sets IMPLICIT + PUBLIC.

Configuration	Stages Executed
`IMPLICIT` / `PUBLIC`	ValidateData
`EXPLICIT` / `PUBLIC`	ValidateData, ValidateApprovers
`IMPLICIT` / `PRIVATE`	ValidateData, ValidateExecutor
`EXPLICIT` / `PRIVATE`	ValidateData, ValidateApprovers, ValidateExecutor

If any stage fails or the contract exhausts its gas budget, the ORK aborts without computing a partial result. See Algorithm 3 for the sandbox security model.

A critical design property: the contract runs before the ORK touches its key shard. The ORK loads

ai

into ephemeral memory only after the contract returns a successful PolicyDecision. This means contract code, which is vendor-authored, never has access to the shard. The sandbox separation is both logical (IL vetting blocks dangerous namespaces) and temporal (the shard is not loaded until the contract completes).

Phase 5 detail: If the contract passes, the ORK proceeds to compute its partial MPC result. The specific computation depends on the authority action type - partial proxy-re-encrypted decryption (Protocol: Hermetic E2EE), partial EdDSA signature, partial VRF output, or partial blind signature. The SWE (or a Vendor intermediary for decryption flows) collects

\geq 14

partial results and Lagrange-interpolates to produce the final output.

Threshold guarantee: If more than 6 ORKs reject (contract failure, Doken invalid, or node offline), the authority action is impossible - insufficient partial results exist for valid interpolation.

The 3-Stage Validation Lifecycle

Loading diagram...

Stage 1 - ValidateData always runs, regardless of policy type. It inspects request parameters, payload integrity, temporal windows, geographic constraints, and protocol-specific rules. Concrete capabilities include: deep-parsing binary payloads to verify protocol conformance, enforcing time-of-day restrictions (e.g., "only during business hours 9am-5pm UTC"), validating IP-based geofencing, and checking transaction volumes against contractual limits. Example (KeyleSSH): the contract uses SshPublicKeyChallenge.TryParse to verify the payload is a legitimate SSH_MSG_USERAUTH_REQUEST (message type 50), checks the service is ssh-connection, and requires the ssh-ed25519 algorithm.

Stage 2 - ValidateApprovers runs for EXPLICIT policies. It enforces M-of-N multi-party authorization: verifies distinct approver Dokens meet the quorum threshold, enforces ForbidSelfApproval (the executor cannot also be an approver), and can enforce RequireDistinctOrgs (approvers from different organizations). Use case: high-value financial transactions requiring "3 of 5 designated signers must approve this wire transfer before the Fabric signs the authorization."

Stage 3 - ValidateExecutor runs for PRIVATE policies. It evaluates the executor's Doken against the specific resource being accessed: role-to-resource matching via [PolicyParam] bindings, expiry checks, and custom business logic. Example (KeyleSSH): the contract maps the SSH username in the challenge payload (e.g., root) to the required Doken role (ssh:root) via [PolicyParam] - if the Doken lacks the matching role, execution aborts.

Each validation stage receives a typed context containing the policy definition, the current user, and stage-specific data. DataContext includes the raw challenge payload (Data), supplementary dynamic data (DynamicData), and a RequestId identifying the flow being validated. ApproversContext includes the list of approver Dokens. ExecutorContext includes the executor's Doken. All three contexts carry the User object, enabling contracts to inspect user attributes alongside policy parameters.

The DecisionBuilder fluent API provides a composition-over-inheritance model for validation logic:

csharp

public PolicyDecision ValidateExecutor(ExecutorContext ctx)
{
    var executor = new DokenDto(ctx.Doken);
    return Decision
        .RequireNotExpired(executor)
        .RequireRole(executor, Res, Role)
        .RequireWeekday()
        .RequireBusinessHours();
}

Case Study: KeyleSSH

KeyleSSH is the reference implementation demonstrating all phases of the Policy:1 flow for threshold signing. The target server's authorized_keys file contains a static public key whose private counterpart is an ineffable key across the ORK swarm. No .pem file exists on any developer laptop, bastion host, or CI/CD pipeline.

When a developer initiates an SSH session to root@production-db, the SSH agent generates a standard cryptographic challenge (SSH_MSG_USERAUTH_REQUEST). The SWE captures this challenge, constructs a BaseTideRequest with Policy:1, attaches the developer's Doken, and submits to the ORK swarm. Each ORK executes the KeyleSSH Forseti contract: ValidateData deep-parses the SSH challenge (message type 50, service ssh-connection, algorithm ssh-ed25519), and ValidateExecutor maps the SSH username (e.g., root) to a required Doken role (e.g., ssh:root) via [PolicyParam] binding. Only if both stages pass do the ORKs produce partial Ed25519 signatures. The SWE interpolates and submits the complete signature to the SSH server.

The architecture includes a blind bastion (tcp-bridge) for WS↔TCP tunneling - the bastion relays traffic without access to session content. The server holds "eternal public keys" corresponding to ineffable private keys; key rotation becomes unnecessary because the private key cannot be stolen. KeyleSSH eliminates an entire class of vulnerabilities - key theft, key sprawl, orphaned keys, stolen bastion credentials - by replacing key possession with policy-governed key action.

Algorithms

Algorithm 1

The Outer Gate is a systemic check that runs before any contract code is loaded. A stolen Doken used from a different device fails step 2 (session binding mismatch).

Algorithm 2

Inner Gate - 3-Stage Contract Lifecycle (per ORK)

Input: BaseTideRequest (payload, authorizers), Contract ID, policy type
Output: PolicyDecision (pass with authorization context) or ABORT

Load contract: $\text{contract} \leftarrow \textsf{LoadContract}(\text{ContractID})$ $\textsf{ASSERT } \textsf{SHA512}(\text{contract.source}) = \text{ContractID}$
Instantiate sandbox: $\text{vm} \leftarrow \textsf{CreateVmHost}(\text{contract},\ \text{gasLimit})$
Stage 1 (always): $\text{result}_1 \leftarrow \text{vm}.\textsf{ValidateData}(\text{DataContext}(\text{payload}, \text{timestamp}, \text{metadata}))$ $\textsf{ASSERT } \text{result}_1.\text{passed}$
Stage 2 (if EXPLICIT): $\text{result}_2 \leftarrow \text{vm}.\textsf{ValidateApprovers}(\text{ApproversContext}(\text{approverDokens}, \text{threshold}))$ $\textsf{ASSERT } \text{result}_2.\text{passed}$
Stage 3 (if PRIVATE): $\text{result}_3 \leftarrow \text{vm}.\textsf{ValidateExecutor}(\text{ExecutorContext}(\text{executorDoken}, \text{roles}))$ $\textsf{ASSERT } \text{result}_3.\text{passed}$
return authorization context for partial MPC computation

Gas exhaustion at any step → ABORT. Any ASSERT failure → ABORT.

Algorithm 3

Sandbox Security Model (VmHost)

Input: compiled C# contract (IL bytecode)
Output: isolated execution environment or REJECT

IL vetting: Scan compiled IL for forbidden namespace references (configurable; defaults include System.IO, System.Net, System.Reflection) Block non-deterministic calls: DateTime.Now, Guid.NewGuid, and other sources of divergence between ORKs Fail closed on unresolved tokens (unknown references are rejected, not ignored) $\textsf{ASSERT}$ no violations detected → else REJECT contract from registry
Process isolation: Instantiate separate OS-level process with strict resource limits Default limits: 10 seconds CPU, 1024 MB memory Load only whitelisted .NET assemblies
Gas metering: Composite gas budget (default: 50,000 gas) charged across four dimensions:
- CPU time: 1,000 gas per millisecond of execution
- Peak memory: 100 gas per MB
- GC allocations: 50 gas per MB allocated
- Garbage collection events: 500 gas per Gen0 GC triggered If budget exhausted → terminate execution, return PolicyDecision failure
Statelessness: Sandbox created per invocation, purged on return No persistent state between requests
Determinism enforcement: Non-determinism blocking ensures all 20 ORKs reach the same policy decision for the same input. If one ORK's contract produced a different result due to DateTime.Now or random values, the threshold signature would fail. The IL vetter prevents this class of divergence at deployment time.

Notation Reference

Symbol	Description
`BaseTideRequest`	Generalized request DTO for all Forseti-governed actions
`Policy:1`	Forseti contract authorization flow identifier
Contract ID	$\textsf{SHA512}(\text{source code})$ - deterministic contract identifier
`IAccessPolicy`	C# interface that all Forseti contracts implement
`ValidateData`	Stage 1 - request parameter and payload validation (always runs)
`ValidateApprovers`	Stage 2 - M-of-N quorum verification (`EXPLICIT` policies)
`ValidateExecutor`	Stage 3 - executor Doken role verification (`PRIVATE` policies)
`DataContext`	Context object for Stage 1 (request parameters, timestamp, payload)
`ApproversContext`	Context object for Stage 2 (approver Dokens, threshold)
`ExecutorContext`	Context object for Stage 3 (executor Doken, roles)
`PolicyDecision`	Return type from each validation stage (pass/fail with reason)
`Decision` / `DecisionBuilder`	Fluent API for composing validation checks
`DokenDto`	Deserialized Doken data transfer object
`[PolicyParam]`	C# attribute for automatic binding of configuration values
`VmHost`	Sandboxed execution environment for contracts
Gas	Computational cost unit for metered execution
Doken	VVK-signed delegated authority token
$B = G \cdot b$	Session public key embedded in Doken

Actors and Trust Assumptions

Actor	Description	Trust Assumption
User (Executor)	The party requesting the authority action. Holds a valid Doken and session key in the SWE.	Identity is Tide-protected (CMK/BYOiD). Bound by Doken role constraints.
Secure Web Enclave (SWE)	Browser-side runtime. Constructs `BaseTideRequest`, attaches Doken, communicates directly with ORKs.	Coordinates but cannot forge Dokens or bypass ORK validation.
Client / Relying Party	The application server. Handles standard OIDC and routes users to the SWE.	"Dumb terminal" - holds no keys, cannot forge authority.
Admin (Policy Author)	Authors Forseti C# contracts. Contracts committed through quorum governance (Article 5).	Cannot unilaterally deploy contracts. Contract ID = $\textsf{SHA512}(\text{source})$ prevents silent modification.
VVK ORK Swarm	20 independent nodes holding key shards. Each independently executes Forseti contracts in sandboxed `VmHost` environments.	Standard threshold trust ( $\leq 13$ may collude). Independent execution - no "master ORK."

Layer Traversal

Layer	How Forseti Engages It
Legitimacy	Doken validation (VVK signature, session binding, role check). Gas metering prevents resource exhaustion. Contract ID verification ensures code integrity.
Authority	Forseti governs whether Authority Layer shards are exercised. The contract is the precondition for shard computation.
Agency	Primary layer. Forseti IS the Agency Layer's decision mechanism. The 3-stage validation lifecycle determines whether the ORK participates in the threshold operation.
Settlement	Gas metering provides economic bounding. Contract execution outcomes feed audit trails.

Security Properties

Property	Mechanism	Assumption
Policy inside authority	The contract is a localized precondition of MPC execution. If the contract fails, the partial computation does not execute. There is no separate gate to bypass.	-
Independent execution	All 20 ORKs execute the contract independently in isolated sandboxes. A compromised node cannot spoof a successful evaluation for other nodes.	Independence of node operators.
Threshold resilience	14 of 20 must independently pass. A compromised minority ( $\leq 6$ ) cannot override policy. A compromised majority ( $\geq 14$ ) is equivalent to compromising the key itself (the threshold assumption throughout the architecture).	Honest-majority threshold assumption.
Deterministic Contract IDs	$\textsf{SHA512}(\text{source code})$ ensures all ORKs execute identical logic. A modified contract produces a different ID → mismatch → rejected.	Collision resistance of SHA-512.
Sandbox isolation	`VmHost`: separate OS-level process, restricted assemblies, blocked namespaces (`System.IO`, `System.Net`, `System.Reflection`), strict CPU/memory limits.	Kernel-level process isolation integrity.
IL vetting	Compiled IL scanned for forbidden namespace references and non-deterministic calls before the contract enters the execution pool.	-
Gas metering	Bounded computation per request. Operations carry explicit costs (e.g., `Claim()` = 5, `Log()` = 25). Budget exhaustion terminates execution. Prevents infinite loops and resource exhaustion.	-
Quorum-governed deployment	Contracts deployed through quorum governance (Article 5). No single admin can deploy or modify policy.	Threshold of honest administrators.
Session-bound authorization	Doken is session-scoped, device-bound (session key $B$ ), and VVK-signed. A stolen Doken fails session binding verification on the ORK.	ECDH security / SWE memory isolation.
Dumb terminal architecture	The application server executes no security policy. Full server compromise grants zero ability to bypass Forseti - policy runs on ORKs.	-
Stateless contracts	Contracts hold no persistent state between invocations. No accumulated state for an attacker to corrupt or leverage.	-

Call Summary

Call	Direction	Purpose
`CommitPolicy`	Admin Quorum → VVK Swarm	Commit quorum-signed C# contract to the Fabric, registering the deterministic Contract ID.
`TokenExchange`	TideCloak → VVK Swarm	Identify user with `_tide_` roles, request threshold-signed JWT + Doken during OIDC exchange.
`POST /Key`	SWE → all $n$ ORKs	Dispatch `BaseTideRequest` containing payload, Contract ID, and Doken to the swarm.
`ValidateData / ValidateApprovers / ValidateExecutor`	ORK local (`VmHost`)	Internal 3-stage Forseti lifecycle evaluating the request against contract constraints.
`partialCompute`	$t$ ORKs → SWE / TideCloak	Return partial MPC output (proxy-re-encrypted decryption shard, partial signature, etc.) after successful Forseti evaluation.

References

Tide Developer Documentation: docs.tidecloak.com
KeyleSSH Reference Implementation: github.com/sashyo/keylessh