Digital sovereignty begins with holding exclusive custody of your cryptographic keys. Today, digital signatures, identity verification, and TLS certificates have been largely captured by commercial SaaS platforms and closed Certificate Authorities (CAs) that charge expensive annual fees, log sensitive document metadata on corporate servers, and lock users into proprietary formats. This project proves how independent hackerspaces, engineering teams, and civic labs can operate their own mathematically verifiable cryptographic infrastructure with zero reliance on corporate cloud intermediaries.

Self-Sovereign Identity & Ed25519 Cryptography

Cryptographic sovereignty means that private keys never leave local physical possession: - Modern Edwards-Curve Signatures (Ed25519): We prioritize the Ed25519 signature algorithm (RFC 8032) based on Curve25519. Offering a robust 128-bit security level, Ed25519 delivers blindingly fast signing speeds, compact 64-byte signatures, and constant-time arithmetic that is inherently immune to cache-timing side-channel vulnerabilities. - Open Hardware Security Keys: Native integration with open-hardware security tokens (Nitrokey 3, SoloKey) and smartcards running open-source OpenPGP and PIV applets. Private keys are generated and isolated directly on the secure microcontroller; cryptographic signing operations execute inside the chip, making physical key exfiltration impossible. - Elimination of SaaS Middlemen: Document signatures are verified using pure mathematics and public key cryptography, eliminating the need for vendor accounts, subscription tiers, or proprietary PDF plugins.

Local PKI with step-ca & Automated Local ACME

To manage the certificate lifecycle across our hardware lab, solar stations, and mesh servers, we deploy step-ca (Smallstep Certificate Authority)—a lightweight, open-source PKI daemon: - Trust Hierarchy: An air-gapped, offline Root CA whose private key resides on an encrypted hardware token, paired with an active Intermediate CA running as a systemd daemon on an independent edge server. - Local ACME Protocol Engine: An embedded ACME provisioner enabling automatic issuance and continuous renewal of TLS certificates for internal IoT nodes, charge controllers, and local mesh domains (*.lab.internal, *.solar.mesh) via Caddy or Nginx without exposing nodes to the public internet. - Short-Lived X.509 Certificates: Certificates are provisioned with short 8-hour to 24-hour lifespans using OIDC single-use tokens or SSH certificates. This architecture drastically reduces the threat window of compromised keys and eliminates the latency and failure modes of traditional Certificate Revocation Lists (CRLs). - Certificate-Based SSH Authentication: Replacing static, fragile authorized_keys files with step ssh, which issues ephemeral, cryptographically signed SSH certificates linked to authenticated contributor identities.

Cryptographic PDF Document Signing with pyHanko (PAdES-LT / LTA)

To produce legally unambiguous and archive-grade digitally signed documents, we employ pyHanko—an open-source Python library and CLI engine: - European PAdES Standard (ETSI EN 319 142): Authoring signatures compliant with European PAdES Baseline-LT (Long-Term) and Baseline-LTA (Long-Term Archival) profiles, embedding complete certificate validation material and revocation status so that signatures remain verifiable decades into the future. - Cryptographic Timestamping (RFC 3161 TSA): Integrating an independent Time-Stamping Authority token that provides mathematical, tamper-evident proof that the document existed in that precise bitwise state at that exact second. - Vector Visual Signatures: Embedding clean, SVG-rendered signature blocks containing cryptographic fingerprint hashes, QR verification links, and signer metadata without proprietary formatting.

Zero-Cloud Offline Verification

The defining architectural principle of our stack is strict zero-cloud data containment: 1. 100% Client-Side Processing: The document is digested (SHA-256 / SHA-512) directly in local memory. Not a single byte of document text, title, or metadata ever leaves the machine. 2. Offline Verification: Any collaborator or recipient can verify document integrity and signatures offline using standard PDF readers (such as Adobe Reader or PDF-XChange) or via the open-source CLI command pyhanko sign validate --fps, validating against the locally imported root CA trust anchor. 3. Open Project Governance: We use this pipeline to sign maker collaboration agreements, lab hardware handovers, firmware release manifests, and electrical schematics. All CA bootstrapping automation and pyHanko signing scripts are open source and published in our git repository.