Technical Specifications

Table of Contents

Executive Summary

Sacred.Vote is a zero-trust, cryptographically verifiable voting platform designed for the CARTA (Continuous Adaptive Risk and Trust Assessment) framework. Every security guarantee is derived from mathematical proofs, hardware-rooted attestation, and distributed cryptographic quorums.

The architecture addresses thirteen critical technology domains: hardware-bound identity verification, post-quantum cryptographic signatures, zero-knowledge eligibility proofs, fully homomorphic tallying, verifiable delay functions, adversarial machine learning defenses, coercion resistance, formal logic verification, continuous adaptive risk assessment, distributed consensus infrastructure, public audit mechanisms, and integration with the peer-reviewed Belenios voting system.

1. Cryptographic Identity & Authentication

Hardware-Bound Attestation (FIPS 140-3 Level 3)

All administrative and voter sessions are anchored to Secure Elements (SE) using the WebAuthn/FIDO2 protocol (CTAP 2.1). Private keys used for ballot signing are generated inside FIPS 140-3 Level 3 validated hardware modules (Yubikey, Nitrokey, or smartphone Secure Enclave) and are physically non-exportable. The public key is signed by the device's Attestation Certificate, proving to the server that the key was generated inside a tamper-resistant chip.

Reference: NIST FIPS 140-3: Security Requirements for Cryptographic Modules (2024) — csrc.nist.gov/pubs/fips/140-3/final

Reference: WebAuthn Level 3 Security Specifications — w3.org/TR/webauthn-3/

Deterministic Token Generation (argon2id)

Identity nullifiers are derived from canonicalized personally identifiable information (PII) using the argon2id hashing algorithm. Argon2id is a memory-hard function resistant to GPU and ASIC-based cracking attacks, combining data-dependent and data-independent memory access patterns.

Reference: RFC 9106: Argon2 Memory-Hard Function for Password Hashing

Blind Signature Enrollment

Ghost voting (administrators casting ballots for non-participating voters) is prevented via a four-step blind signature protocol that decouples voter identity from ballot authorization:

When voting, the voter submits this token. The Gatekeeper cannot link the token to any voter identity because the unblinded token was never transmitted. Double votes are detected by checking token uniqueness against the ledger.

Reference: Privacy Pass: Blind Signature Protocol (IETF)

Reference: Cloudflare Privacy Pass Implementation

Sybil-Resistance via Recursive Social Attestation

For elections lacking a central voter registry, Sacred.Vote implements decentralized Proof of Personhood (PoP) through a recursive social attestation graph. Verified administrators attest to voters they know, who in turn attest to others. Every attestation is recorded on a transparent, append-only Merkle Tree.

If a verification node is found creating fraudulent accounts, that node's entire subtree is recursively revoked, containing the blast radius of the compromise. This structural approach ensures that fraud is not merely detected but systematically pruned from the attestation graph.

Reference: Proof of Personhood: Sybil-Resistant Decentralized Identity (2025)

Reference: The Limits of ZK for Age/Identity Verification (Brave, 2026)

Semantic Collision Resolution

Phonetic canonicalization (e.g., double-metaphone) handles human data entry errors such as "Stephen" vs. "Steven." However, in large-scale elections, phonetically similar names combined with identical dates of birth create collision vectors where distinct citizens generate the same canonical identity.

Sacred.Vote appends high-entropy, non-phonetic attributes to the identity string before hashing:

ID_final = Hash(Phonetic(Name) || DOB || Last4(VerifiedID))

This preserves phonetic resilience for usability while ensuring mathematical uniqueness across the voter population.

Reference: Deterministic Identity Canonicalization for Electoral Systems

2. Post-Quantum Cryptography (NIST 2024 Standards)

The Post-Quantum Migration Imperative

Post-quantum cryptography (PQC) is the development of cryptographic algorithms secure against attacks by quantum computers. Most widely-used public-key algorithms (RSA, ECC) depend on the difficulty of integer factorization or the discrete logarithm problem. These are solvable in polynomial time by Shor's algorithm on quantum computers.

Mosca's Theorem provides the urgency framework: If X + Y > Z (where X = migration time, Y = data secrecy duration, Z = time until quantum computers arrive), migration is urgent. For election data that must remain confidential indefinitely, migration is critically urgent now.

The "Harvest Now, Decrypt Later" (HNDL) threat model describes adversaries recording encrypted data today for future decryption when quantum computers become available. Sacred.Vote implements post-quantum algorithms to neutralize this threat.

Reference: NIST Post-Quantum Cryptography Standards (2024)

Reference: Mosca's Theorem: Risk Analysis Framework for PQC Migration

Lattice-Based Digital Signatures (ML-DSA / Dilithium-3)

All ballots and source code manifests are signed using NIST FIPS 204 ML-DSA (Module-Lattice-Based Digital Signature Algorithm), specifically the Dilithium-3 (ML-DSA-65) parameter set. ML-DSA security derives from the Short Integer Solution (SIS) problem over module lattices, which is mathematically resistant to Shor's algorithm.

Reference: NIST FIPS 204: Module-Lattice-Based Digital Signature Standard (2024) — csrc.nist.gov/pubs/fips/204/final

Key Encapsulation (ML-KEM / Kyber-768)

Ephemeral session keys are established using NIST FIPS 203 ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism), formerly CRYSTALS-Kyber-768. The client generates a random 32-byte secret, encapsulates it under the server's public key, and sends the encapsulation. The server decapsulates to recover the shared secret, which becomes the root key for AES-256-GCM session encryption.

Reference: NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Standard (2024) — csrc.nist.gov/pubs/fips/203/final

Six Families of Post-Quantum Algorithms

Post-quantum cryptography research focuses on six mathematical approaches:

1. Lattice-Based Cryptography

Security based on Short Vector Problem (SVP) and Closest Vector Problem (CVP) in lattices. Includes Ring-LWE, NTRU, and the NIST-standardized ML-DSA and ML-KEM. Sacred.Vote uses this family exclusively.

2. Multivariate Polynomial Cryptography

Security based on solving systems of multivariate polynomial equations over finite fields. Includes Rainbow (Unbalanced Oil and Vinegar). Reduction to NP-hard MQ problem.

3. Hash-Based Signatures

Security based on one-way property of cryptographic hash functions. Includes Merkle trees, XMSS, SPHINCS+, WOTS. Provably secure with reduction to hash function security.

4. Code-Based Cryptography

Security based on difficulty of decoding random linear codes (Syndrome Decoding Problem). McEliece cryptosystem has resisted cryptanalysis for 40+ years.

5. Isogeny-Based Cryptography

Security based on computing isogenies between supersingular elliptic curves. Includes CSIDH. Smallest key sizes but slower computation.

6. Symmetric-Key Quantum Resistance

Existing symmetric algorithms (AES, SHA-3) are quantum-resistant with doubled key sizes. Grover's algorithm provides only quadratic speedup; AES-256 remains secure.

Reference: PQCrypto Conference Series (2006-2026)

Reference: European Telecommunications Standards Institute (ETSI) Quantum Safe Cryptography Workshops

Post-Quantum Anonymity: Plover (Lattice-Based Threshold Blind Signatures)

Sacred.Vote utilizes Plover, a lattice-based Threshold Blind Signature (TBS) scheme, to decouple voter identity from the ballot in a post-quantum environment. Plover replaces classical blind RSA signatures with a lattice-based approach grounded in the Short Integer Solution (SIS) problem.

The signer (Gatekeeper) approves voter eligibility without ever seeing the actual ballot hash. This provides quantum-resistant "blindness" that neutralizes future quantum de-anonymization attacks.

Reference: Plover: Practical Lattice-based Threshold Blind Signatures (2025) — eprint.iacr.org/2025/001

Side-Channel Hardening

Post-quantum implementations are protected against physical side-channel attacks (electromagnetic eavesdropping, power analysis, timing attacks). Domain-Oriented Masking (DOM) masks all intermediate cryptographic values with random data, making computation statistically independent of the secret key. NTT (Number-Theoretic Transform) operations use randomized ordering to prevent instruction cache analysis.

Countermeasures:

Reference: Securing PQC Implementation Against AI-Enhanced Side-Channels (arXiv:2603.06969, 2026)

Crypto-Agility & Hybrid Deployment

Sacred.Vote is designed with crypto-agility: the ability to replace cryptographic primitives without major architectural changes. If a weakness is discovered in lattice-based cryptography, the system can transition to alternative post-quantum primitives (code-based, hash-based, isogeny-based) without rewriting core logic.

Hybrid approaches combine classical (RSA/ECC) and post-quantum algorithms simultaneously during the transition period, providing defense-in-depth.

Reference: NIST Migration Guidelines for Post-Quantum Cryptography (2024)

3. Zero-Knowledge Proofs (ZKPs)

Definition

A zero-knowledge proof (ZKP) is a cryptographic protocol in which one party (the prover) can convince another party (the verifier) that a given statement is true, without conveying any information beyond the mere fact of the statement's truth.

Application in Voting: A voter can prove they are eligible to vote (their identity hash exists in the registered voter set) without revealing who they are. The system learns "this is a valid voter" but never learns the voter's identity.

Reference: Goldwasser, Micali, Rackoff: The Knowledge Complexity of Interactive Proof Systems (1985)

The Three Properties of Zero-Knowledge Proofs

1. Completeness

If the statement is true and both parties follow the protocol, the verifier will be convinced. No false negatives.

2. Soundness

If the statement is false, no cheating prover can convince an honest verifier, except with negligible probability. A dishonest voter cannot fabricate valid credentials.

3. Zero-Knowledge

The verifier learns nothing beyond the truth of the statement. A simulator can produce transcripts indistinguishable from real interactions without access to the secret.

Reference: Interactive Proof Systems (Goldwasser, Micali, Rackoff, 1985)

Abstract Example: The Ali Baba Cave

Peggy (prover) knows the secret word that opens a door in a ring-shaped cave. Victor (verifier) wants proof that Peggy knows the secret without learning the word itself.

Victor waits outside as Peggy enters the cave and takes either path A or B at random

Victor enters and randomly calls either "A" or "B"

If Peggy knows the secret, she opens the door and exits from whichever path Victor called

If she does not know the word, she has a 50% chance of guessing correctly per round

After 20 repetitions, the probability of successful deception is 1 in 2^20 (approximately one in a million)

Even if the entire interaction is recorded, the recording cannot prove knowledge of the secret to third parties, because any two people could produce an identical recording by agreeing on the sequence in advance.

Reference: Quisquater et al.: How to Explain Zero-Knowledge Protocols to Your Children (1990)

Abstract Example: The Red Card Proof

Peggy draws a card from a standard 52-card deck and wants to prove it is red (heart or diamond) without revealing which card. She shows Victor all 26 black cards remaining in the deck. Since a standard deck contains exactly 26 red and 26 black cards, and all black cards are accounted for, Victor concludes with certainty that Peggy's hidden card is red.

Victor learns the card is red but gains no information about whether it is a heart or diamond, or which specific rank it is. If Peggy held a black card, she could not produce all 26 black cards from the remaining deck, demonstrating soundness.

Reference: Card-Based Cryptographic Protocols (2019)

Interactive vs. Non-Interactive ZKPs

Interactive ZKPs require multiple message exchanges between prover and verifier. Soundness error decreases exponentially with the number of rounds.

Non-Interactive ZKPs (NIZKs) allow the prover to send a single message. The Fiat-Shamir heuristic converts interactive proofs into non-interactive ones using a cryptographic hash function as a random oracle.

Sacred.Vote uses non-interactive ZKPs (specifically zk-SNARKs with Groth16) because voters cannot maintain persistent communication with the election server. A single proof is generated client-side and verified cryptographically.

Reference: Fiat-Shamir Heuristic: Non-Interactive Zero-Knowledge Proofs (1986)

zk-SNARKs in Sacred.Vote

zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge) are used in multiple capacities:

Reference: Groth16: On the Size of Pairing-based Non-interactive Arguments (2016)

Reference: PlonK: Permutations over Lagrange-bases for Oecumenical Noninteractive arguments of Knowledge (2019)

4. Privacy-Preserving Tallying

Fully Homomorphic Encryption (BFV Scheme)

Individual votes are never decrypted. Sacred.Vote implements the Brakerski-Fan-Vercauteren (BFV) fully homomorphic encryption scheme. Encrypted ballots can be mathematically combined without decryption: E(vote_1) + E(vote_2) = E(vote_1 + vote_2).

Each voter encrypts their choice under the public election key. The server performs additive homomorphic operations on the ciphertexts to compute an encrypted final tally. Only the administrative quorum (k-of-n trustees) can decrypt the final aggregate result. No individual ballot is ever exposed as plaintext at any point in the pipeline.

Reference: Microsoft SEAL: Homomorphic Encryption Library — microsoft.com/en-us/research/project/microsoft-seal/

Reference: Brakerski-Fan-Vercauteren Scheme (2012)

Distributed Decryption (Shamir's Secret Sharing)

The master decryption key is never held by a single entity. Using Shamir's Secret Sharing (SSS), the key is split into n shares where any k shares can reconstruct the key, but k-1 shares reveal no information about the key (information-theoretic security).

Reference: How to Share a Secret (Adi Shamir, ACM, 1979) — dl.acm.org/doi/10.1145/359168.359176

5. Temporal Integrity & Anti-Injection

Verifiable Delay Functions (Wesolowski VDF)

To prevent last-minute ballot stuffing or result manipulation, the tallying phase is cryptographically locked behind a Verifiable Delay Function. Based on the Wesolowski scheme over an RSA group of unknown order, this requires a strictly sequential 10-minute compute window that cannot be parallelized.

No results can be computed or viewed until the VDF proof is complete. This ensures a verified cooling-off period after polls close, preventing administrators or attackers from viewing trends or injecting ballots at the final moment.

Reference: Efficient Verifiable Delay Functions (Boneh et al., 2018) — eprint.iacr.org/2018/601.pdf

Reference: VDF Applications in Decentralized Systems (MDPI, 2022) — mdpi.com/1424-8220/22/19/7524

Merkle Mountain Range (MMR) Audit Trail

Every encrypted ballot is hashed into a Merkle Mountain Range (MMR), a dynamic Merkle Tree structure. The server publishes the Merkle Root (a single 32-byte hash) to a public, immutable source every 10 minutes.

Proof of Inclusion: A voter uses their receipt to verify that their encrypted ballot hash is included in the published Merkle Root. If the hash is missing, the voter has mathematical proof of vote suppression or fraud.

Reference: Merkle Mountain Ranges for Append-Only Verification

Deterministic & Reproducible Build Pipeline (Nix)

All dependencies—compiler versions, libraries, kernel headers—are pinned to specific cryptographic hashes using Nix Flakes. Any auditor can execute the build locally and produce a binary with the exact same SHA-256 hash as the production server.

If the hashes differ, the binary has been tampered with. This eliminates the possibility of supply-chain attacks or backdoor injection during the compilation process.

Reference: Reproducible Builds: Strategic Importance — reproducible-builds.org

6. Adversarial Machine Learning (AML) Defense

RobEns (Robust Ensemble) Verification

For physical-to-digital ballot scanning, Sacred.Vote employs a multi-layered defense against adversarial pattern injection. Scanned ballots are processed by an ensemble of three distinct machine learning architectures:

Consensus across architecturally diverse models prevents single-model adversarial exploits. A perturbation optimized to fool one architecture is unlikely to simultaneously fool all three.

Reference: Analyzing Physical Adversarial Example Threats (arXiv:2603.00481, March 2026)

Feature Squeezing

All input scans undergo bit-depth reduction and median filtering before classification. This "squeezes" out L1/L2 norm adversarial perturbations—small, carefully-crafted pixel modifications designed to trick ML classifiers.

Reference: Feature Squeezing: Detecting Adversarial Examples in Deep Neural Networks (2018)

7. Coercion Resistance

Anamorphic Encryption

Anamorphic encryption allows a single ciphertext (the ballot) to be decrypted into two different plaintext messages depending on which key is used:

Under coercion, the voter provides Key B. The coercer verifies the ballot and is satisfied. The election system, using the actual master key, tallies only the real vote. The coercer cannot distinguish between a real key and a panic key.

Reference: Anamorphic Encryption: Private Communication Against a Dictator (Persiano et al., 2022)

Nullifiable Commitment Schemes

Modern coercion-resistance research utilizes nullifiable commitment schemes. Voters receive one "real" key and multiple "fake" keys from the credential authority. A zero-knowledge proof demonstrates that the ballot is well-formed (structurally identical to a real vote), but only the tallier—using a master secret—can identify and silently discard fake ballots during summation.

The coerced voter submits a valid-looking ballot that is cryptographically indistinguishable from a genuine one but has no effect on the final tally.

Reference: zkVoting: Coercion-Resistant E-Voting with Nullifiable Commitments (2026)

8. Formal Verification & Build Integrity

Formal Logic Proof (TLA+ / Coq)

Standard unit testing verifies code under anticipated conditions only. For high-stakes elections, the core state machine logic is formally verified using TLA+ or Coq, providing mathematical proof of correctness under all possible states and transitions.

Verified Invariants:

These proofs are mathematical certainties, not probabilistic test outcomes.

Reference: CompCert: Formally Verified C Compiler — compcert.org

Reference: TLA+ Specification Language (Lamport, 1999)

Zero-Trust Architecture

Sacred.Vote assumes a fundamentally adversarial environment: the network is considered compromised, the server is considered under surveillance, and endpoints are considered potentially infected. All systems are modeled as hostile witnesses.

Security derives exclusively from mathematical properties of cryptographic algorithms, distributed quorums with no single point of failure, hardware-rooted attestation, and formal verification. Even complete server compromise does not breach voter privacy or ballot integrity.

Reference: NIST SP 800-207: Zero Trust Architecture (2020)

Continuous Source Attestation

At startup, the server computes a SHA-256 hash of its execution context (binary, libraries, configuration), signs the hash with the post-quantum ML-DSA private key, and publishes it to a public, immutable ledger. Any auditor can query the /manifest endpoint to receive the current code hash and verify it against the server's published commitment. Hash mismatch indicates binary tampering.

Reference: Provably Improving Election Verifiability in Belenios (Baloglu et al., IACR 2021)

9. CARTA: Continuous Adaptive Risk & Trust Assessment

Beyond Role-Based Access Control

Traditional Role-Based Access Control (RBAC) assigns static permissions that do not adapt to changing threat conditions. CARTA replaces static access models with Attribute-Based Access Control (ABAC), enabling continuous, context-aware security assessment in real-time.

Access decisions are made dynamically based on user attributes (authentication method, hardware verification status), device attributes (integrity, network), environmental attributes (geographic anomalies, request patterns), resource sensitivity, and temporal context.

Reference: Gartner: Continuous Adaptive Risk and Trust Assessment (CARTA) Framework (2010)

CARTA Implementation Phases

Plan Phase

Establish threat models and risk priorities. Determine data protection requirements, access policies, and acceptable risk baselines aligned with organizational objectives.

Build Phase

Integrate security into the development process (DevSecOps). All dependencies and third-party libraries are scanned for vulnerabilities. Cryptographic primitives and access controls are evaluated at every commit.

Run Phase

Real-time monitoring using automated analytics. Anomalies are detected and responded to immediately. Micro-segmentation ensures that a compromised component does not cascade to critical systems.

Reference: NIST Risk Management Framework (RMF)

Reference: OWASP Risk Rating Methodology

CARTA Key Components

Reference: ETSI Quantum Safe Cryptography: Risk Assessment Framework

CARTA and Zero-Trust: Complementary Frameworks

Zero-Trust establishes the baseline: no user or device is inherently trusted. CARTA extends this with continuous evaluation: trust is not a binary state but a continuously-updated assessment that adapts to real-time risk conditions.

Sacred.Vote implements both: zero-trust posture (assume breach) combined with CARTA's continuous adaptive assessment (respond dynamically to emerging threats). High-risk operations such as opening vote tallies or modifying election parameters trigger immediate re-authentication with hardware attestation.

Reference: NIST SP 800-207: Zero Trust Architecture

10. Distributed Infrastructure & Resilience

Byzantine Fault Tolerance (BFT) Consensus

A single server is a single point of failure. Sacred.Vote is designed for deployment across a distributed network of BFT nodes (e.g., Tendermint or HotStuff protocol). The election continues to operate correctly as long as fewer than 1/3 of the nodes are compromised.

Geographically distributed nodes ensure that infrastructure seizure in any single jurisdiction does not halt the election. Remaining nodes continue processing and tallying ballots.

Reference: Tendermint: Byzantine Fault Tolerant Middleware

Reference: HotStuff: BFT Consensus in the Lens of Blockchain (2019)

IPFS-Pinned Frontend (Content-Addressed Deployment)

The Sacred.Vote frontend is served from content-addressed storage (IPFS). The URL is not a domain name but a multihash of the code itself. If a single character of the frontend code is modified by an attacker, the hash changes, the URL breaks, and the voter is immediately alerted to tampering.

This prevents JavaScript injection attacks where a compromised CDN replaces encryption scripts with malicious versions that leak cryptographic keys.

Reference: IPFS: Content-Addressed, Peer-to-Peer Hypermedia Protocol

Reference: Subresource Integrity (SRI) — W3C Recommendation

Visual Cryptography (Analog Hole Defense)

Even with perfect encryption, the voter's device screen is a physical vulnerability. Malware or hidden cameras can record the screen during ballot selection.

Sacred.Vote implements visual cryptography: the ballot is not displayed as plain text. The server sends two "share" images. One is displayed on-screen and the other is provided to the voter via a separate channel. Only when both shares are combined can the voter see the candidate names. A screen recorder captures only meaningless visual noise.

Reference: Visual Cryptography: Secret Sharing for Images (Naor & Shamir, 1994)

11. Audit & Transparency

Public Audit Ledger

Anonymized, encrypted ballots are published in real-time to content-addressed storage (IPFS) for independent verification. Any observer can monitor the stream of encrypted ballots without gaining information about individual vote contents. The ledger is append-only and immutable.

Reference: IPFS: InterPlanetary File System Protocol

Deterministic Build Badge

A real-time status indicator displays the SHA-256 hash of the currently running binary alongside the hash of the latest GitHub main branch commit. If the hashes match, the running code is verified. If they diverge, the system flags potential binary tampering.

Reference: Reproducible Builds — reproducible-builds.org

Client-Side Vote Verification Tool

A client-side "Audit My Vote" tool allows voters to paste their cryptographic receipt and verify its inclusion in the encrypted tally via Merkle Proof of Inclusion. The verification runs entirely in the voter's browser. The receipt does not reveal the voter's choice to anyone, including the verification tool itself.

Reference: Belenios: Verifiable Electronic Voting Specification — belenios.org/specification.pdf

12. Belenios Integration & End-to-End Verifiability

Belenios Overview

Belenios is a peer-reviewed, open-source verifiable voting system developed by INRIA, LORIA, and CNRS (France). It has been deployed in real elections globally and certified by leading cryptographers. Key properties include end-to-end verifiability (every voter can verify their ballot was counted), vote privacy (no party can learn an individual voter's choice), and verifiable credential schemes (separating voter identity from ballot authorization).

Reference: Belenios Official Website — belenios.org

Threshold Decryption & Quorum

Belenios implements threshold decryption where n decryption trustees are designated. Each trustee generates their own key pair. Ballots are encrypted under the combined election public key. At tally time, each trustee computes a partial decryption. Only when at least k trustees collaborate (e.g., 3 out of 5) can the tally be decrypted.

This prevents any single authority from unilaterally accessing results. Even if the server is compromised, results cannot be decrypted without trustee cooperation.

Reference: Belenios Protocol Specification: Distributed Key Generation (DKG)

Plover Integration (Lattice-Based Threshold Blind Signatures)

Classical Belenios relies on ElGamal encryption, which is quantum-vulnerable. Sacred.Vote integrates Plover, a lattice-based Threshold Blind Signature (TBS) scheme, to replace classical blind signatures with post-quantum alternatives.

Plover decouples voter identity from the ballot using lattice-based cryptography grounded in the Short Integer Solution (SIS) problem, providing quantum-resistant blindness where the signer approves eligibility without seeing the ballot hash.

Verifiable Credential Scheme

Belenios uses credentials to prove voter eligibility without revealing identity. A credential authority generates a key pair for each registered voter. To vote, the voter uses their credential to prove eligibility. The ballot is signed with the credential (proving only registered voters cast it), but the credential is not included in the encrypted ballot, maintaining anonymity.

Reference: Belenios Documentation: Credential Generation and Management

13. Forensic Comparison Matrix

Threat Defense Matrix

14. Geographic Access Control (ZK-ABAC)

Sacred.Vote rejects live telemetry (IP geolocation, browser GPS APIs) as a geographic restriction mechanism. IP tracking is neutralized by Tor/I2P onion routing, and client-side HTML5 GPS data is trivially spoofed via browser extensions. Furthermore, if the server learns the voter's location at the moment of voting, the anonymity mandate is destroyed. Sacred.Vote treats location as a cryptographic claim issued during enrollment, not a live telemetry feed.

1. Deterministic Spatial Indexing (H3 Grid)

Arbitrary human-drawn polygons (city limits, district lines) cannot be evaluated inside zero-knowledge cryptographic circuits due to computational complexity. Sacred.Vote utilizes Uber's H3 Hexagonal Hierarchical Spatial Index, which overlays the globe with a deterministic grid of hexagons at multiple resolutions, from continent-scale down to square meters.

A physical precinct is translated by the administrative interface into an array of discrete H3 indices (e.g., 892a10089dbffff, 892a10089cfffff). This converts messy geographical borders into exact, mathematically provable strings suitable for zk-SNARK circuit evaluation.

Reference: Uber Engineering, 'H3: Uber Hexagonal Hierarchical Spatial Index,' 2018

2. Out-of-Band Material Binding (Enrollment)

A voter's location is verified exactly once, in material reality, before any digital token is issued. During the double-blind registration phase, the Gatekeeper physically or forensically verifies the voter's address via utility bill, tax record, or organizational roster.

Reference: Chaum, D., 'Blind Signatures for Untraceable Payments,' Crypto 1982

3. Client-Side Policy Evaluation (zk-SNARK Circuit)

The server never enforces access by requesting the voter's attributes. The server broadcasts requirements and demands a mathematical proof of eligibility.

Protocol Sequence

Reference: Groth, J., 'On the Size of Pairing-Based Non-interactive Arguments,' EUROCRYPT 2016

4. Intersection Vulnerability & k-Anonymity Enforcement

Highly granular geographic targeting introduces a de-anonymization vector via intersection. If an election is restricted to a single city block AND requires a specific attribute (e.g., a particular ancestry or profession), the eligible anonymity set may collapse to a single individual. Even with homomorphic tallying, if only one person is eligible, the published tally reveals their exact choice.

Mandatory Safeguard: Minimum Anonymity Set

The voting smart contract enforces a minimum anonymity set (k-anonymity threshold). The administrative interface performs a census check and refuses to initialize any election where the mathematical intersection of targeted geo-attributes yields a potential voter pool below a safe threshold (e.g., k = 50).

Reference: Sweeney, L., 'k-Anonymity: A Model for Protecting Privacy,' International Journal of Uncertainty, Fuzziness and Knowledge-Based Systems, 2002

Audit Methodology

All systems are modeled under the assumption that the network is compromised, the server is under surveillance, and endpoints may be infected. Reliability is derived strictly from mathematical proofs, hardware-rooted attestation, and distributed cryptographic quorums. Security is an emergent property of the mathematics, not a claim requiring trust.

Sacred.Vote is free and open-source software (FOSS). The complete source code, formal verification proofs, and build manifests are publicly available for independent audit.

Engineered & Maintained by PlausiDen

Sacred.Vote is engineered and maintained by PlausiDen.

15. Zero-Trust Infrastructure

Zero-Trust is a security model that eliminates the concept of implicit trust from any interaction, regardless of whether it originates inside or outside a network perimeter. Under NIST SP 800-207, the definitive federal standard, no user, device, or network segment is inherently trusted — every request must be authenticated, authorized, and continuously validated before access is granted to any resource.

Foundational Principles: NIST SP 800-207

The traditional perimeter-based security model assumes that everything inside a network boundary is safe. This assumption is catastrophically invalid in modern environments where nation-state adversaries, malicious insiders, and supply-chain compromises are routine. John Kindervag's Zero-Trust model (Forrester, 2010), later formalized by NIST, replaces this with a single axiom:

"Never trust, always verify."

— NIST SP 800-207 core principle

NIST identifies seven tenets of Zero Trust that Sacred.Vote implements across the entire voting lifecycle:

Reference: NIST SP 800-207: Zero Trust Architecture (2020) — csrc.nist.gov/pubs/sp/800/207/final

Reference: Kindervag, J., 'No More Chewy Centers: Introducing The Zero Trust Model Of Information Security,' Forrester Research, 2010

Reference: CISA Zero Trust Maturity Model v2.0 (2023) — cisa.gov/zero-trust-maturity-model

Elliptic Curve Cryptography as the Sole Primitive

Sacred.Vote restricts all classical cryptographic operations to Elliptic Curve Cryptography (ECC). RSA and Diffie-Hellman over multiplicative groups are prohibited because their security relies on the hardness of integer factorization and discrete logarithms over finite fields — problems efficiently solvable by Shor's algorithm on a sufficiently powerful quantum computer.

ECC provides equivalent security to RSA with dramatically smaller key sizes, reducing attack surface:

Sacred.Vote deploys ECC for legacy-compatible operations (Curve25519 / P-256 for session initiation) and immediately hybridizes with ML-KEM (Kyber-768) and ML-DSA (Dilithium-3) for all ballot-critical operations, achieving defense in depth: an adversary must simultaneously break both ECC discrete logarithm and lattice reduction problems to compromise a single ballot.

Reference: Bernstein, D.J. & Lange, T., 'SafeCurves: Choosing Safe Curves for Elliptic-Curve Cryptography,' 2013 — safecurves.cr.yp.to

Reference: NIST FIPS 186-5: Digital Signature Standard (DSS), 2023

Reference: SEC 2: Recommended Elliptic Curve Domain Parameters, Certicom Research, 2010

Micro-Segmentation and Assumed Breach Posture

Sacred.Vote's infrastructure is partitioned into cryptographically isolated segments with no lateral movement possible between them. The assumed breach posture means the system is designed to operate correctly even when one or more components are fully compromised:

Even if an adversary achieves complete control of the Tallier Layer, they receive only an encrypted aggregate ciphertext. Ballot integrity and voter anonymity are preserved by the mathematics of homomorphic encryption, not by network security that can be defeated.

Reference: CISA: Zero Trust Maturity Model, Version 2.0 (2023)

Reference: Rose, S. et al., 'Zero Trust Architecture,' NIST SP 800-207 (2020)

Reference: Microsoft: Zero Trust Deployment Guide (2023) — microsoft.com/security/business/zero-trust

Primary Reference

NIST SP 800-207: Zero Trust Architecture — csrc.nist.gov/pubs/sp/800/207/final

Published by the National Institute of Standards and Technology. The authoritative U.S. federal standard defining Zero Trust Architecture principles, components, and deployment models.

16. Strict Role-Based Access Control (RBAC)

Role-Based Access Control (RBAC) is a security paradigm in which system access privileges are assigned to roles rather than directly to individual users. Users acquire permissions by being assigned to roles, and roles are defined by the set of operations they are permitted to perform. NIST RBAC (NIST IR 7316) defines a four-level model ranging from flat RBAC to constrained RBAC with separation-of-duty enforcement.

NIST RBAC Model Hierarchy

The NIST RBAC model defines four increasingly sophisticated levels:

RBAC0 — Core RBAC

Users, roles, permissions, and sessions. A user can activate multiple roles in a session; permissions are associated with roles, not users.

RBAC1 — Hierarchical RBAC

Roles inherit permissions from senior roles. A SuperAdmin role inherits all permissions of Admin, which inherits all permissions of Operator.

RBAC2 — Constrained RBAC

Adds Separation of Duty (SoD) constraints. Mutually exclusive roles cannot be assigned to the same user — a Trustee cannot also be an Administrator.

RBAC3 — Symmetric RBAC

Combines hierarchical inheritance with SoD constraints. The complete model used in high-assurance systems including voting infrastructure.

Sacred.Vote implements RBAC3 with SoD enforcement. The system enforces that no single identity can hold conflicting roles simultaneously — a design that prevents any single actor from compromising both the issuance and tallying phases of an election.

Reference: Sandhu, R. et al., 'Role-Based Access Control Models,' IEEE Computer, 1996

Reference: NIST IR 7316: Assessment of Access Control Systems (2006) — nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir7316.pdf

Reference: Ferraiolo, D. et al., 'Proposed NIST Standard for Role-Based Access Control,' ACM TISSEC, 2001

Sacred.Vote Role Model

Six distinct roles are defined with strictly non-overlapping permission sets. Each role is bound to a hardware-attested credential and cannot be escalated without multi-party authorization:

Reference: OWASP Access Control Cheat Sheet — owasp.org/www-project-cheat-sheets

Reference: Ferraiolo, D. & Kuhn, D.R., 'Role-Based Access Controls,' 15th National Computer Security Conference (NCSC), 1992

Separation of Duty (SoD) Enforcement

Separation of Duty is a control mechanism that ensures no single individual can execute a complete, sensitive transaction unilaterally. It is the digital equivalent of the two-person rule used in nuclear launch authorization and bank dual-control procedures.

Sacred.Vote enforces two categories of SoD:

Static SoD (assignment-time constraint)

A user assigned to the Trustee role cannot simultaneously hold the Gatekeeper or Administrator role. This is enforced at credential issuance time by a multi-party ceremony that cryptographically binds roles to hardware tokens.

Dynamic SoD (activation-time constraint)

During an active election session, the Auditor role cannot be activated by any user who has already activated the Administrator role in the same session, even if their credential technically permits both. The enforcement is cryptographic: role activation tokens are mutually exclusive and non-transferable.

The practical effect is that colluding actors cannot concentrate sufficient authority to alter an election outcome without recruiting at least k of n trustees, which requires a globally distributed conspiracy detectable in the public audit log.

Reference: Clark, D.D. & Wilson, D.R., 'A Comparison of Commercial and Military Computer Security Policies,' IEEE Symposium on Security and Privacy, 1987

Reference: Sandhu, R., 'Separation of Duty in Computerized Information Systems,' IFIP WG 11.3 Database Security, 1990

Evolution to CARTA: When RBAC Is Not Enough

Classic RBAC assigns static permissions based on organizational roles. This model fails to account for contextual risk signals: a user holding valid credentials who is suddenly authenticating from an unfamiliar geography, using a different device fingerprint, or generating anomalous request patterns should have their access dynamically restricted despite holding a valid role assignment.

Sacred.Vote augments RBAC3 with CARTA's continuous adaptive assessment (documented in Section 9). Every access decision evaluates not just "what role does this credential hold?" but "what is the current risk score of this session, device, network origin, and behavioral pattern?" Roles define the ceiling of allowed access; CARTA dynamically applies the floor based on real-time risk.

Reference: Gartner: Continuous Adaptive Risk and Trust Assessment (CARTA) Framework

Reference: NIST SP 800-162: Guide to Attribute Based Access Control (ABAC) Definition and Considerations (2014)

Primary References

NIST RBAC Project — csrc.nist.gov/projects/role-based-access-control

NIST IR 7316: Assessment of Access Control Systems (PDF) — nvlpubs.nist.gov

NIST's definitive documentation on RBAC models, formal definitions, and implementation guidance for high-assurance systems.

17. FOSS-First Commitment

Free and Open Source Software (FOSS) is software that grants users the freedom to run, study, modify, and distribute the software and its source code. For election systems specifically, FOSS is not merely a preference — it is an ethical and security requirement. A democratic institution cannot credibly claim that votes are counted correctly if the counting software is a black box that citizens are legally prohibited from inspecting.

The Four Freedoms and Why They Matter for Elections

The Free Software Foundation defines four fundamental freedoms that free software must guarantee. Richard Stallman's formulation, applied to election infrastructure:

Freedom 0 — Run for Any Purpose

Any election authority, civic organization, academic researcher, or independent auditor must be able to deploy and run Sacred.Vote's software without restriction. No licensing fees, no vendor lock-in, no geographic exclusions.

Freedom 1 — Study and Modify

The complete source code must be publicly accessible so that cryptographers, security researchers, and adversarial reviewers can independently verify that the system functions as claimed. Secret source code in a voting system is an assertion of authority that democratic systems cannot accept.

Freedom 2 — Redistribute Copies

Any municipality may copy, redistribute, and deploy the software without legal restriction. This enables smaller jurisdictions without IT resources to benefit from security improvements made by larger organizations.

Freedom 3 — Distribute Modified Versions

Jurisdictions may adapt the software to local requirements and share improvements back to the community. Security patches discovered by a researcher in one jurisdiction benefit all deployments globally.

Reference: Stallman, R.M., 'The GNU Project,' Free Software Foundation — gnu.org/gnu/thegnuproject.html

Reference: Free Software Definition, FSF — gnu.org/philosophy/free-sw.html

Reference: Open Source Definition, OSI — opensource.org/osd

Reproducible Builds and Deterministic Compilation

Publishing source code alone is insufficient if the distributed binary cannot be verified to correspond to that source code. Ken Thompson's 1984 Turing Award lecture, "Reflections on Trusting Trust," demonstrated that a malicious compiler could insert backdoors that are invisible in source code inspection.

Sacred.Vote mandates reproducible builds: the build process is deterministic such that any auditor starting from the published source code, using the pinned toolchain, must arrive at a binary with an identical SHA-256 hash to the deployed production binary. This is verified through:

1. Nix Flake Lockfile

All dependencies are pinned to cryptographic content hashes in flake.lock. No dependency can change without a corresponding hash change that appears in the public git history.

2. Deterministic Build Pipeline

Build timestamps, filesystem ordering, and compiler output are normalized to eliminate sources of non-determinism. Two independent builds on two different machines produce byte-identical output.

3. Binary Attestation

The production binary's SHA-256 hash is signed by the ML-DSA post-quantum key and published to the IPFS audit ledger. Querying /api/manifest returns the current hash for independent verification.

4. Diverse Double-Compiling (DDC)

Critical cryptographic modules are compiled using two independently audited toolchains and the resulting binaries are compared. A mismatch indicates supply-chain compromise.

Reference: Reproducible Builds Project — reproducible-builds.org

Reference: Wheeler, D.A., 'Countering Trusting Trust through Diverse Double-Compiling (DDC),' ACSAC 2005

Reference: NixOS Foundation: Nix Flakes and Reproducible Development Environments — nixos.org

The Belenios Foundation: Peer-Reviewed FOSS Election Software

Sacred.Vote's cryptographic tallying layer is built upon Belenios, a voting system developed by researchers at INRIA, LORIA, and CNRS — France's national research institutions. Belenios has been formally analyzed, peer-reviewed in international cryptography conferences, and deployed in real-world elections across academic and governmental contexts.

Key FOSS properties of Belenios:

Reference: Cortier, V. et al., 'Belenios: A Simple Private and Verifiable Electronic Voting System,' INRIA Research Report RR-9365, 2021

Reference: Baloglu, S. et al., 'Provably Improving Belenios Verifiability,' IACR ePrint 2021/283

Reference: Belenios Project — belenios.org (INRIA, LORIA, CNRS)

Public Audit Rights and Citizen Verification

Every citizen who casts a ballot in Sacred.Vote is entitled to perform an independent audit of the election outcome. This is not a promised feature — it is a cryptographic guarantee that cannot be removed by administrators or vendors:

These four verifiability properties together constitute end-to-end verifiability (E2E-V), the gold standard for election integrity recognized by the U.S. Election Assistance Commission and international election observers.

Reference: Verified Voting Foundation — verifiedvoting.org

Reference: Open Source Election Technology (OSET) Institute — osetfoundation.org

Reference: EAC: Voluntary Voting System Guidelines (VVSG) 2.0 — eac.gov/voting-equipment/voluntary-voting-system-guidelines

GNU Free Software Definition

Open Source Initiative (OSI) — opensource.org

Reproducible Builds Project — reproducible-builds.org

Belenios Voting System (INRIA) — belenios.org

OSET Institute: Open Source Election Technology — osetfoundation.org

Learn More: Belenios Verifiable Voting

Sacred.Vote builds upon Belenios, a peer-reviewed, open-source voting system developed by INRIA, LORIA, and CNRS. Belenios is deployed globally in real elections and provides proven end-to-end verifiability and threshold decryption.

SacredVote is open-source civic infrastructure developed by PlausiDen Technologies LLC. Individual deployments are operated by the organizations that adopt the platform.