attestium.com

Attestium

Attestium Logo

CI npm version License: MIT Node.js Version Security Audit TPM 2.0

📄 Read the Technical Whitepaper — 16 pages covering our architecture, security model, TPM 2.0 integration, and adoption roadmap.

Element of Attestation - Runtime code verification and integrity monitoring for Node.js applications

Forward Email

Attestium is a project by Forward Email – the 100% open-source, privacy-focused email service.

We created Attestium to provide transparent, hardware-backed proof of our own server-side code integrity. We believe in open, verifiable systems, and Attestium is our contribution to a more trustworthy internet.

🧪 What is Attestium?

Attestium is a runtime code verification and integrity monitoring library that provides cryptographic proof of your application’s code integrity. Like an element in the periodic table, Attestium represents the fundamental building block of attestation - the ability to prove that your code is running exactly as intended, without tampering or modification.

Core Concept: Element of Attestation

Just as chemical elements have unique properties and atomic structures, Attestium provides:

🎯 Why Attestium Exists

The Problem: Trust in Distributed Systems

In today’s world of cloud computing and distributed systems, users need to trust that:

Research Background

Attestium was developed based on extensive research into existing solutions and their limitations. This research was inspired by:

[!NOTE] Research Foundation: Attestium addresses the specific need for runtime code verification that emerged from Forward Email’s commitment to transparency and Mullvad’s pioneering work in system transparency.

🔍 Comprehensive Analysis of Existing Solutions

Before developing Attestium, we conducted extensive research into existing verification, attestation, and integrity monitoring solutions. This comprehensive analysis examines 20+ solutions across different categories to understand their capabilities, limitations, and suitability for runtime code verification.

Solution Primary Purpose Runtime Verification Third-Party APIs Hardware Requirements Complexity Cost Node.js Integration Application Focus Continuous Monitoring Description Notes
Attestium Runtime Verification ✅ Yes ✅ Yes ✅ TPM 2.0 Required 🟢 Low 🟢 Free ✅ Native ✅ Yes ✅ Yes (Audit Status) Hardware-backed runtime code verification for Node.js applications with TPM 2.0 integration Our solution - addresses gaps in existing tools with hardware security
SigSum Transparency Logging ❌ No ✅ Yes ❌ No 🟡 Medium 🟢 Free ❌ No ❌ No ⚠️ Log Only Minimal design for public transparency logs of signed checksums with witness verification Excellent for transparency but no runtime verification
SigStore Code Signing ❌ No ⚠️ Limited ❌ No 🟡 Medium 🟢 Free ⚠️ Limited ❌ No ❌ No Keyless code signing for software supply chain security with transparency logs Build-time signing only, no runtime capabilities
Keylime Remote Attestation ⚠️ Limited ✅ Yes ✅ TPM Required 🔴 High 🟢 Free ❌ No ⚠️ Limited ⚠️ Limited Remote attestation framework using TPM for hardware-backed verification Infrastructure-focused, requires specialized hardware
Intel TXT Hardware Attestation ❌ No ⚠️ Limited ✅ Intel CPU 🔴 High 🟡 Hardware ❌ No ⚠️ Boot Only ❌ No Hardware-based platform attestation with measured boot process Boot-time only, no application-level verification
AMD SVM Hardware Attestation ❌ No ⚠️ Limited ✅ AMD CPU 🔴 High 🟡 Hardware ❌ No ⚠️ Boot Only ❌ No Hardware virtualization security with memory encryption Limited to virtualization security
ARM TrustZone Hardware Attestation ⚠️ Limited ⚠️ Limited ✅ ARM CPU 🔴 High 🟡 Hardware ❌ No ⚠️ Limited ❌ No Hardware security architecture with secure/non-secure worlds ARM-specific, complex development
Intel SGX Secure Enclaves ⚠️ Enclave Only ⚠️ Limited ✅ Intel CPU 🔴 High 🟡 Hardware ❌ No ⚠️ Enclave Only ⚠️ Limited Secure enclaves for protected code execution with remote attestation Being deprecated, limited memory
AWS Nitro Enclaves Cloud Attestation ⚠️ Limited ⚠️ Limited ✅ AWS Only 🟡 Medium 🔴 Expensive ❌ No ⚠️ Limited ❌ No Isolated compute environments with cryptographic attestation AWS-only, expensive for continuous use
Google Asylo Secure Enclaves ⚠️ Enclave Only ⚠️ Limited ✅ SGX/TrustZone 🔴 High 🟢 Free ❌ No ⚠️ Enclave Only ❌ No Framework for confidential computing across multiple TEE technologies Complex development, limited ecosystem
Microsoft VBS Virtualization Security ⚠️ Limited ❌ No ✅ Windows Only 🟡 Medium 🟡 Windows ❌ No ⚠️ Limited ❌ No Windows security using hypervisor isolation for code integrity Windows-only, limited cross-platform support
Docker Content Trust Container Signing ❌ No ❌ No ❌ No 🟡 Medium 🟢 Free ❌ No ❌ No ❌ No Container image signing and verification with role-based delegation Container-focused, no runtime verification
Notary Content Signing ❌ No ⚠️ Limited ❌ No 🟡 Medium 🟢 Free ❌ No ❌ No ❌ No Framework for publishing and managing trusted collections of content Generic signing, no application-specific features
Cosign Container Signing ❌ No ⚠️ Limited ❌ No 🟡 Medium 🟢 Free ❌ No ❌ No ❌ No Container signing with keyless signatures using OIDC Container-focused, part of SigStore ecosystem
in-toto Supply Chain Security ❌ No ⚠️ Limited ❌ No 🟡 Medium 🟢 Free ❌ No ❌ No ❌ No Framework for securing software supply chains with cryptographic evidence Build-time verification, complex policy definition
SLSA Supply Chain Framework ❌ No ❌ No ❌ No 🟡 Medium 🟢 Free ❌ No ❌ No ❌ No Framework for supply chain integrity with security levels Framework only, requires implementation
Grafeas Metadata API ❌ No ✅ Yes ❌ No 🟡 Medium 🟢 Free ❌ No ❌ No ❌ No Metadata API for software supply chain with vulnerability tracking Metadata storage only, no verification
Binary Authorization Policy Enforcement ❌ No ⚠️ Limited ❌ No 🟡 Medium 🟡 GCP ❌ No ❌ No ❌ No Deploy-time security policy enforcement for container images GCP-specific, deployment-time only
AIDE File Integrity ⚠️ Files Only ❌ No ❌ No 🟢 Low 🟢 Free ❌ No ⚠️ Files Only ⚠️ Scheduled Advanced intrusion detection with file integrity monitoring File-level only, no runtime code verification
Tripwire File Integrity ⚠️ Files Only ❌ No ❌ No 🟡 Medium 🔴 Commercial ❌ No ⚠️ Files Only ⚠️ Scheduled Commercial file integrity monitoring with enterprise features Commercial licensing, file-level monitoring
OSSEC Security Monitoring ⚠️ Files Only ⚠️ Limited ❌ No 🟡 Medium 🟢 Free ❌ No ⚠️ Files Only ⚠️ Limited Host-based intrusion detection with file integrity checking Security-focused, not verification-focused
Samhain File Integrity ⚠️ Files Only ❌ No ❌ No 🟡 Medium 🟢 Free ❌ No ⚠️ Files Only ⚠️ Scheduled File integrity monitoring with stealth capabilities File-level only, scheduled checks
AFICK File Integrity ⚠️ Files Only ❌ No ❌ No 🟢 Low 🟢 Free ❌ No ⚠️ Files Only ❌ No Another file integrity checker with simple configuration Basic file monitoring, no API
Chainlink Blockchain Oracles ❌ No ✅ Yes ❌ No 🔴 High 🔴 Expensive ❌ No ❌ No ❌ No Decentralized oracle network for external data verification High cost, high latency, no code verification
Ethereum Attestations Blockchain ❌ No ✅ Yes ❌ No 🔴 High 🔴 Gas Fees ❌ No ❌ No ❌ No On-chain attestation protocols with immutable audit trails High gas costs, environmental concerns
Hyperledger Fabric Blockchain ❌ No ✅ Yes ❌ No 🔴 High 🟡 Infrastructure ❌ No ❌ No ❌ No Enterprise blockchain platform with permissioned networks Complex infrastructure, no application focus

Why Existing Solutions Weren’t Sufficient

Based on our comprehensive analysis, we identified critical gaps that existing solutions couldn’t address for our specific requirements:

1. Runtime Application Verification Gap

2. Third-Party Verification API Gap

3. Developer Experience Gap

4. Node.js Ecosystem Gap

5. Cost and Complexity Gap

6. Granular Monitoring Gap

7. Continuous Verification Gap

🧪 Attestium’s Unique Approach

Attestium addresses these gaps by providing:

✅ Runtime Code Verification

✅ Third-Party Verification APIs

✅ Developer-Friendly Design

✅ Granular File Categorization

✅ Cryptographic Proof Generation

✅ Modern Workflow Integration

🔒 Tamper-Proofing and Security Considerations

The Challenge of Runtime Tampering

One of the most significant challenges in software verification is preventing runtime tampering - the ability for malicious actors to modify code in memory after it has been loaded and verified. Traditional approaches like Object.freeze() and VM isolation provide some protection, but determined attackers with system access can potentially bypass these mechanisms.

Attestium’s Multi-Layered Defense

Attestium employs several innovative approaches to address runtime tampering:

1. Tamper-Resistant Memory Protection

2. External Validation Network

3. Continuous Integrity Monitoring

Limitations and Considerations

While Attestium provides significant protection against tampering, it’s important to understand the fundamental limitations of software-only solutions:

The Verification Paradox

Practical Security Model

Attestium is designed to:

Best Practices for Maximum Security

  1. Deploy in Controlled Environments: Use containers, restricted user accounts, and access controls
  2. Enable External Monitoring: Set up independent verification nodes
  3. Regular Baseline Updates: Keep verification baselines current with legitimate changes
  4. Combine with Other Security Measures: Use alongside firewalls, intrusion detection, and access logging
  5. Monitor Verification APIs: Watch for unusual patterns in verification requests

🔐 TPM 2.0 Hardware-Backed Security

Why TPM 2.0 is Critical for Attestium

Attestium requires TPM 2.0 for production deployments where maximum security is needed. While Attestium can operate in software-only mode for development and testing, TPM 2.0 integration is essential for addressing the fundamental limitations of software-only verification systems.

[!IMPORTANT] TPM 2.0 Requirement: For production environments handling sensitive data or requiring regulatory compliance, Attestium must be deployed with TPM 2.0 hardware support. Software-only mode should only be used for development, testing, or non-critical applications.

The Fundamental Problem: Software-Only Verification Limits

Attack Vectors Possible Without TPM 2.0

When running in software-only mode, Attestium is vulnerable to several sophisticated attack vectors:

How TPM 2.0 Solves These Problems

TPM 2.0 provides a hardware root of trust that mitigates these attacks:

TPM 2.0 Architecture in Attestium

block-beta
  columns 2
  block:app["Attestium Application"]:2
    columns 2
    block:sw["Software Verification"]
      A["File checksums"]
      B["Runtime monitoring"]
      C["External validation"]
      D["Tamper detection"]
    end
    block:hw["TPM 2.0 Hardware Integration"]
      E["Hardware random generation"]
      F["Cryptographic attestation"]
      G["Sealed storage"]
      H["PCR measurements"]
    end
  end
  block:tpm["TPM 2.0 Hardware Chip"]:2
    columns 2
    block:left[" "]
      I["Secure key storage"]
      J["Hardware RNG"]
      K["Sealed data"]
    end
    block:right[" "]
      L["Platform measurements"]
      M["Attestation signing"]
      N["Tamper resistance"]
    end
  end

Attestium’s TPM 2.0 Integration

Attestium leverages these TPM 2.0 features to provide a secure verification environment:

🚀 Quick Start

1. Installation

npm install attestium
# or
pnpm add attestium

2. Basic Usage

const Attestium = require("attestium");

async function main() {
  const attestium = new Attestium({
    projectPath: process.cwd(),
    autoDetectTpm: true,
  });

  const report = await attestium.generateVerificationReport();
  console.log("Verification Report:", report);

  const securityStatus = await attestium.getSecurityStatus();
  console.log("Security Status:", securityStatus);
}

main().catch(console.error);

⚙️ Configuration

Attestium uses cosmiconfig for configuration. You can configure Attestium in:

Configuration Options

Option Type Default Description
projectPath string process.cwd() Path to the project to be verified.
autoDetectTpm boolean true Automatically detect and use TPM if available.
enableTpm boolean false Force enable/disable TPM (overrides autoDetect).
fallbackMode string software Fallback when TPM unavailable: software or disabled.
productionMode boolean false Enable production security features.
includePatterns string[] [] Glob patterns to include files.
excludePatterns string[] [] Glob patterns to exclude files.
gitignore boolean true Respect .gitignore rules.
tpm object {} TPM 2.0 specific settings.
tpm.keyContext string attestium.ctx Path to TPM key context file.
tpm.sealedDataPath string attestium-sealed.dat Path to sealed data file.
tpm.pcrList number[] [0, 1, 2, 3, 7, 8] Platform Configuration Registers to use.
externalValidation object {} External validation network settings.
externalValidation.enabled boolean false Enable external validation.
externalValidation.requiredConfirmations number 1 Number of required confirmations.
externalValidation.nodes string[] [] List of external validation nodes.

🤖 Continuous Monitoring with Audit Status

For enterprise-grade continuous monitoring, automated server auditing, and real-time notifications, use Audit Status, which is built on top of Attestium.

Audit Status

Upptime Integration

You can integrate Audit Status with Upptime for a comprehensive uptime and integrity monitoring solution.

  1. Expose an audit health endpoint on your server. See the health endpoint example.
  2. Add the endpoint to your .upptimerc.yml:
sites:
  - name: Production API
    url: https://api.example.com

  - name: Production Audit Status
    url: https://api.example.com/health/audit
    expectedStatusCodes:
      - 200

🤝 Contributing

Contributions are welcome! Please see our contributing guidelines for more information.

📜 License

Attestium is licensed under the MIT License.

Element of Attestation

This site is open source. Improve this page.