Attestor

The Attestor is the cryptographic heart of the KRNL Protocol. While executors run workflow logic, the attestor ensures that every step is secure, verifiable, and policy-compliant. It acts as the developer’s private guardian, responsible for attesting to the integrity of execution and safeguarding master secrets, without ever becoming a centralized point of trust.

Role in the Protocol

At a high level:

• Executor = runs the workflow logic (open-source, community-audited).

• Attestor = enforces trust boundaries and signs off on the results (developer-controlled, security-hardened).

---

Core Responsibilities

1. Cryptographic Signing

   • Generates execution signatures using ephemeral keys derived from a master secret.

   • Guarantees that every workflow run is uniquely bound to its execution context, preventing replay or forgery.

   • Signs both raw execution outputs and the network attestation hash, producing end-to-end verifiable proofs.

2. Network Monitoring

   • Acts as a transparent interceptor for all network traffic (HTTP, HTTPS, DNS).

   • Detects tampering, MITM attempts, or injection by monitoring every request and response.

   • Produces cryptographically sealed logs that provide forensic-grade auditability.

3. Secret Management

   • Safely holds the developer’s master key material.

   • Derives one-time-use ephemeral keys per execution, minimizing exposure.

   • Optionally integrates with external Remote Signers or hardware-based Trusted Execution Environments (TEEs) for heightened security.

4. Execution Environment Validation

   • Verifies that executors run in correct, reproducibly built sandbox environments (e.g., gVisor containers).

   • Enforces policies on which executors are authorized and under what conditions.

   • Provides an auditable chain of custody for every workflow step.

Every attestor is anchored by a developer-controlled master key.

• Who generates it? The dApp developer (or organization) creates the master key when setting up their attestor.

• How is it used?

  • Never directly for signing.

  • Instead, it serves as the cryptographic seed from which ephemeral execution keys are derived per workflow run.

• Where is it stored?

  • Typically compiled into the attestor binary with advanced protections against reverse engineering.

  • Optionally isolated in a Remote Signer or TEE (Intel SGX, AMD SEV, ARM TrustZone) for hardware-backed security.

This means the master key never leaves the attestor environment, never appears on-chain, and is never reused. It exists purely as a local root of trust, bound to the developer’s attestor deployment.

---

Attestation Data Structures

The attestor doesn’t just sign results, it builds a multi-layered proof system:

• Request Attestation: Every outbound API call is logged with full method, endpoint, headers, payload, and a timestamp.

• DNS Attestation: All DNS queries and responses are cryptographically recorded, ensuring transparency at the lowest layer.

• Response Attestation: Each inbound response (status, headers, payload, TLS metadata) is bound to its request and signed.

• Network Summary: A cryptographic digest of the entire execution session, aggregating request/response patterns into a compact verifiable proof.

Together, these structures transform the “black box” of off-chain execution into a glass box, anyone can independently verify exactly what happened, when, and under which conditions.

---

Security Model

• Isolation: Attestors run in isolated gVisor environments, with optional TEE deployment for hardware-backed guarantees.

• Ephemeral Keying: No key reuse, no persistent signing keys exposed; every run is cryptographically unique.

• Developer Authority: dApp developers own their attestor, meaning only they define the policies, whitelists, and trust boundaries.

• Auditability: The attestor’s signed outputs can be verified both on-chain (via standard signature recovery) and off-chain (via forensic inspection of attestation logs).

---

Why It Matters

Traditional oracles or middleware rely on trust in third-party operators. The attestor eliminates that dependency by giving developers full control over verification. This unlocks:

• Regulatory-grade compliance – produce audit-ready reports of every API call and signature.

• User confidence – end users can see verifiable evidence, not just promises.

• Security resilience – even if an executor is compromised, the attestor prevents forged results from entering the workflow.

In short: Executors compute, attestors prove. This clear division of responsibility is what makes KRNL’s architecture uniquely trustworthy.

What's next?

Vault