Introduction to Forseti

Forseti is the programmable policy engine of the Tide Cybersecurity Fabric, designed to manage and execute decentralised authorization logic.

While traditional Identity and Access Management (IAM) systems rely on centralised databases or "God-mode" administrators to grant access, Forseti enables developers to implement dynamic, code-based rules enforced by the Tide Cybersecurity Fabric - a distributed network of independent nodes. It allows vendors to write custom contracts defining exactly when and how a user can perform an action on a vendor key.

At its core, Forseti acts as the gatekeeper for Ineffable Cryptography - a breakthrough where cryptographic keys are generated in fragments and distributed across the Fabric. These keys are never reconstructed or assembled in any single location, even during an operation; Forseti ensures authority is only exercised when specific, gas-metered programmable conditions are met.

Why Forseti?

Traditional security models suffer from the "Authority Problem": hackers only need to compromise the authority that controls security, such as a rogue admin or a misconfigured server. Forseti mitigates this by:

• Decoupling Authority: Authority is removed from application servers and admins and distributed across a network of Orchestrated Recluders of Keys (ORKs).
• Swarm Intelligence: Much like an ant colony, independent nodes collaboratively process requests in parallel, returning "meaningless puzzle pieces" that only form a result at the edge.
• Tamper-Proof Logic: Authorization logic is written in C# contracts and executed in sandboxed environments. Because nodes are compensated to execute these rules, the Fabric provides a secure, resource-bounded environment that cannot be bypassed by a compromised backend.

Prerequisite

For information regarding initial account setup, please refer to the TideCloak New Realm Quickstart Guide.

---

Guide Table of Contents

This guide is structured to take you from architectural concepts to production-level implementation.

Section	Description
Architecture & Flow	A deep dive into the Policy:1 flow.
Forseti Contracts	Technical details on writing and deploying C# contracts to govern resources.
Governance	Explains the Quorum-Enforced Authorization mechanism for rule changes.
Implementation	Practical "how-to" using BaseTideRequest and the SDKs to trigger distributed operations.
Security Analysis	An evaluation of RCE immunity, IL vetting, and the gas metering that prevents resource exhaustion.
Case Study	A review of KeyleSSH, using custom C# contracts to validate SSHv2 public-key authentication payloads.

---

Architecture and the "Policy:1" Flow

Forseti's architecture is built on the principle of decoupling authority from the application and its administrators. Instead of a central vault or server holding a master key, authority is distributed across a decentralised network of independent nodes known as Orchestrated Recluders of Keys (ORKs).

The Decentralised Fabric

The ORK network forms the "Tide Cybersecurity Fabric" where cryptographic keys are never stored or assembled in their entirety.

Key architectural features include:

• Ineffable Cryptography: Keys are manifested in fragments across the ORK nodes. Unlike traditional Multi-Party Computation (MPC) that might momentarily reconstruct a key in a Trusted Execution Environment (TEE), Forseti's protocols remain entirely blind from start to finish.
• Threshold Requirements: Operations only succeed if a mathematically predetermined number of nodes (the "threshold") participate - typically 14 out of 20 in a swarm.
• Swarm Intelligence: Individual ORK nodes hold incomplete authority; they each partially process a request in parallel and return "puzzle pieces" that are interpolated at the edge (the user agent) to form a valid signature or decrypted result.

The Policy:1 Authorization Flow

The Policy:1 flow is the generalized protocol used by Forseti to govern cryptographic actions. It consists of the following phases:

1. Policy Definition and Commitment: Administrators define access rules using templates. These are attested and committed to the network as C# source code, where the unique Contract ID is derived from the SHA512 hash of that source code.
2. Authentication and "Doken" Issuance: A user authenticates through the standard TideCloak OIDC flow. They receive a "doken" (delegated token) cryptographically bound to their specific device and session.
3. Request Initiation: The application constructs a BaseTideRequest - a generalized DTO that allows the ORK to deserialize, validate, and authenticate the specific request data (challenge and metadata).
4. Sandboxed Validation: Each ORK node independently executes the Forseti contract in a secure, isolated process (VmHost). The validation follows a structured lifecycle:
   • ValidateData: Always runs to check request parameters, time-windows, or geo-data.
   • ValidateApprovers: Verifies if the required $M$-of-$N$ quorum signatures are present.
   • ValidateExecutor: Confirms the executor's doken has the required roles for the resource.
5. Multi-Party Authority: If the contract logic is satisfied, nodes produce partial cryptographic operations. These are interpolated on the user's browser to form a valid authoritative artefact, such as an Ed25519 signature.

---

Forseti Contracts (C# Policy Logic)

Forseti moves authorization from the application layer into the Cybersecurity Fabric itself via Forseti Contracts-custom policies written in C# using .NET architecture.

Programmable vs. Static Authorization

Forseti introduces Programmable Policy Enforcement. Unlike application-layer logic, which a rogue administrator could "patch out," Forseti contracts are constraints enforced by the authority Fabric.

If the contract's code returns a failure, the ORK nodes mathematically cannot produce the signatures required to unlock data or sign a request. Execution is gas-metered to prevent resource exhaustion and infinite loops.

Contract Architecture: The IAccessPolicy Interface

Every contract must implement the IAccessPolicy interface, which defines a structured 3-stage validation lifecycle.

Stage	Method	Purpose
1. Data	ValidateData(DataContext ctx)	Always runs. Validates request parameters, business hours, geo-fencing, or payload integrity.
2. Approvers	ValidateApprovers(ApproversContext ctx)	Runs for EXPLICIT policies. Validates that the list of approver "dokens" meets a required threshold.
3. Executor	ValidateExecutor(ExecutorContext ctx)	Runs for PRIVATE policies. Checks the requester's "doken" for specific roles.

Fluent Composition with DecisionBuilder

Forseti utilizes a composition-over-inheritance model. Developers use the Decision builder to chain human-readable checks without complex class hierarchies.

// Implements IAccessPolicy
public PolicyDecision ValidateExecutor(ExecutorContext ctx)
{
    var executor = new DokenDto(ctx.Doken);

    // Fluent chain for readable logic
    return Decision
        .RequireNotExpired(executor)        // Session must be active
        .RequireRole(executor, Res, Role)   // Must have specific role
        .RequireWeekday()                   // Mon-Fri only
        .RequireBusinessHours();            // 9am-5pm UTC
}

Contract Capabilities

1. Policy Parameters: Use the [PolicyParam] attribute to automatically bind configuration values (like required roles or resource IDs) from the administration portal directly into your C# class.
2. Metadata & Payload Inspection: In ValidateData, contracts can deep-parse raw payloads. For example, KeyleSSH parses SSHv2 challenges to ensure the protocol service is ssh-connection and the algorithm is ssh-ed25519 before signing.
3. Identity Governance: Contracts can enforce ForbidSelfApproval or RequireDistinctOrgs to ensure no single entity can bypass the quorum.

Integrity and Identification

To ensure absolute tamper-resistance:

• Contract ID: The unique ID for any contract is the SHA512 hash of its C# source code. If the code changes by even a single character, the ID changes, preventing the accidental execution of unverified logic.
• Sandbox Isolation: Each contract runs in an isolated VmHost process with restricted assembly loading, blocking dangerous namespaces like System.IO or System.Net.

---

Quorum-Enforced Governance

While Forseti Contracts define the logic of access, Quorum-Enforced Governance ensures that the logic itself cannot be subverted.

The Multi-Party Authorization Model

Forseti replaces the "God-mode" admin model with a provably-secure governance model.

• 70% Threshold Requirement: Any change to administrative rules requires cryptographic approval from a majority of nominated administrators.

  $Threshold = 1 \vee \lfloor N_{admins} \times 0.7 \rfloor$

• Decentralized Rule Enforcement: Rules are cryptographically committed to the Fabric which automatically verifies all requested privileges against these signed rules before performing any cryptographic action.

• Tamper-Proof Admin Keys: Every administrator's personal key is also protected by the Fabric using the same zero-knowledge approach as user keys, ensuring that even if an admin's device is compromised, their authority cannot be easily hijacked.

The Security Lifecycle of a Change Request

Every administrative change follows a strict, non-bypassable workflow. While the contract logic dictates what is allowed, this governance process dictates who can change those permissions:

Phase	Description
Drafting	An administrator proposes a modification to access privileges or system configurations.
Review	Nominated Quorum administrators inspect the draft.
Endorsement	Approving admins sign using their personal Tide BYOiD keys.
Commitment	Once the threshold is reached, changes are committed to the Fabric. This creates a mathematical proof of their endorsement that cannot be forged.

---

Developer Implementation & SDK Integration

Integrating Forseti allows developers to perform cryptographic actions - such as signing transactions or decrypting data - without the application ever possessing or reconstructing a private key.

Core Dependencies

• @tidecloak/js: Manages the user's identity, browser-bound session, and the "doken" (delegated token) required for authentication against the Fabric.
• heimdall-tide: Provides the generalized BaseTideRequest and TideMemory structures used to deserialize, validate, and authenticate requests within the ORK network.

The Implementation Workflow

The following logic demonstrates a production-style signer function, utilizing the Policy:1 authorization flow as seen in the KeyleSSH reference implementation.

import { IAMService } from "@tidecloak/js";
import { TideMemory, BaseTideRequest } from "heimdall-tide";

/**
 * Executes a distributed signing request via Forseti.
 * This architecture ensures the backend remains a "dumb terminal" with no 
 * inherent authority to cause systemic compromise.
 */
export async function executeForsetiSign(challengeData: Uint8Array) {
  const tc = (IAMService as any)._tc;

  // 1. Pack Metadata and Challenge
  // Metadata allows Forseti contracts to validate specific roles and 
  // resource identifiers (e.g., 'ssh:root').
  const humanReadable = new TextEncoder().encode("Requesting SSH Signature");
  const draft = TideMemory.CreateFromArray([humanReadable, challengeData]);

  // 2. Define the Request
  // BaseTideRequest generalizes how ORK nodes deserialize and validate 
  // request-specific data.
  const tideRequest = new BaseTideRequest(
    "BasicCustom",     // Protocol
    "BasicCustom<1>",  // Version
    "Policy:1",        // The specific Forseti contract type
    draft, 
    new TideMemory()
  );

  // 3. Authorise with Doken
  // The Doken is a time-limited cryptographic proof of identity that 
  // no man-in-the-middle can obtain or reuse.
  const dokenBytes = new TextEncoder().encode(tc.doken);
  tideRequest.addAuthorizer(TideMemory.CreateFromArray([dokenBytes]));

  // 4. Get the Threshold Signature
  // The SDK manages parallel communication with the ORK swarm.
  const initialized = await tc.createTideRequest(tideRequest.encode());
  
  // 'sigs' contains the valid Ed25519 signature interpolated from 
  // partial operations at the edge.
  const sigs = await tc.executeSignRequest(initialized, true);
  
  return sigs; 
}

Technical Considerations

• Gas Metering: Policy execution is resource-bounded to prevent infinite loops. For example, operations like Claim() cost 5 gas, while Log() costs 25 gas.
• Threshold Requirement: Operations only succeed if a mathematically predetermined number of independent nodes - typically 14 out of 20 - independently validate the request against the C# policy.
• Validation Stages: The ORK backend executes policies through a structured lifecycle: ValidateData (request parameters), ValidateApprovers (M-of-N quorums), and ValidateExecutor (requester roles).
• Edge Interpolation: Because keys are ineffable, they are never reassembled. Partial cryptographic "puzzle pieces" are returned by nodes and only form a meaningful result on the user's device.
• Deterministic Contract IDs: For security, a Contract ID is always the SHA512 hash of the C# source code, ensuring identical logic across all nodes and compilers.

---

Security Analysis and "Cyber Immunity"

The primary objective of Forseti is Cyber Immunity: ensuring a system can suffer a high-privilege breach without catastrophic results. By decoupling authority from the application server, Forseti ensures that even a successful exploit cannot lead to systemic compromise.

Mitigating Remote Code Execution (RCE)

In traditional architectures, RCE is terminal-attackers gain shell access and exfiltrate credentials or keys. Forseti transforms this vulnerability through several architectural layers:

1. The "Dumb Terminal" Effect: The backend server holds no sensitive keys or passwords, only "cryptographic stubs". An attacker executing cat /etc/secrets/key.pem finds nothing of value.
2. Authority Outside the Blast Radius: Critical authority lives in the Fabric (the decentralised ORK network) rather than the application.
3. The Secure Execution Sandbox: When the Fabric executes a C# policy, it applies three layers of protection:
   • IL Vetting: Every contract is scanned at the Instruction Level (IL) to block forbidden namespaces (e.g., System.IO, System.Net) and non-deterministic calls.
   • Process Isolation: Each policy runs in a separate, isolated VmHost process with strict OS-level CPU and memory limits.
   • Gas Metering: Every operation (like logging or claiming data) has a cost. Requests are limited to a specific gas budget to prevent infinite loops and resource exhaustion.

Solving the "Authority Problem"

Traditional Model	Forseti (Cyber-Herd Immunity)
Implied Authority: We trust the IAM system or admin to "do the right thing".	Explicit Authority: Cryptographic actions only manifest through mathematical consensus of the swarm.
God Mode: A single super-admin or root account can override all security controls.	Authorityless Security: No single person, system, or entity has the power to compromise the platform.
The "Key-Under-Mat": Keys are stored in "safer boxes" (vaults, HSMs) that remain a single point of failure.	Ineffable Keys: Keys are fragmented across the network and are never reconstructed, not even in a TEE.

By moving from "access control" to "authority control," the entire class of authentication-bypass exploits is eliminated. Even if the application code is compromised, the authority over sensitive data remains safely out of reach.

---

Case Study: KeyleSSH

KeyleSSH is the primary open-source proof-of-concept for Forseti, demonstrating a "truly keyless" SSH implementation where private keys never exist - not on servers, in bastions, or even in application memory.

Real-World Application of Policy:1

In KeyleSSH, access is not determined by the possession of a .pem file, but by the evaluation of a Forseti C# contract within the Fabric. This contract performs deep inspection of the SSHv2 authentication protocol before any cryptographic action is taken.

• Protocol Validation: The contract uses SshPublicKeyChallenge.TryParse to verify that the "to-be-signed" payload is a legitimate SSH_MSG_USERAUTH_REQUEST (message type 50).
• Strict Constraints: It enforces specific security parameters, such as requiring the ssh-connection service and strictly allowing only the ssh-ed25519 algorithm.
• Role-Based Mapping: Using [PolicyParam] for automatic binding, the contract ensures the SSH username requested in the challenge matches the user's assigned ssh:role (e.g., a user requesting root must have the ssh:root role).
• Distributed Consensus: Only after these C# logic checks pass will the ORK nodes collaboratively generate an Ed25519 signature to answer the SSH challenge.

Architectural Components

• Blind Bastion Tunneling: Uses an oblivious jumpbox (tcp-bridge) for scalable WS↔TCP tunneling. This bastion is "blind," having no access to or knowledge of the content of the encrypted session.
• Eternal Public Keys: Instead of rotating files, the server's authorized_keys file contains a static "Tide SSH public key". This corresponds to an ineffable private key manifested in fragments across the Fabric; it is never reassembled, rendering it immune to theft.

Source Code

For developers looking to build similar "keyless" applications, the full source code for KeyleSSH is available on GitHub as a reference implementation.