papers/lux-hybrid-certificates.tex

\documentclass[11pt]{article}
\usepackage{shared/luxcover}
\usepackage{amsmath, amssymb, algpseudocode, graphicx, hyperref, booktabs}

\title{Hybrid Certificate Chains and Post-Quantum Trust Anchors for Validator Networks}
\author{
Lux Research\thanks{Corresponding author: [email protected]}\\
\textit{Lux Industries, Inc.}\\
\texttt{[email protected]}
}
\date{2024}

\usepackage{amsthm}
\newtheorem{definition}{Definition}
\newtheorem{theorem}{Theorem}
\begin{document}
\luxcoverpage

\begin{abstract}
We describe Lux Network's hybrid X.509 certificate infrastructure for validator identity, combining classical ECDSA/BLS signatures with post-quantum ML-DSA signatures in a single certificate chain. Each validator holds a dual-signature certificate: one classical signature for compatibility with existing TLS infrastructure, one ML-DSA signature for quantum resistance. Trust anchors are rooted in Q-Chain governance, with on-chain registration of certificate fingerprints and revocation via stake-weighted voting. We specify the certificate profile, the enrollment protocol, the dual-signature verification procedure, and the integration with device identity for hardware-attested validator nodes. The system is deployed on Lux mainnet, securing validator-to-validator TLS and staking key binding.
\end{abstract}

\section{Introduction}

Validator identity in proof-of-stake blockchains rests on public key infrastructure. In Lux, each validator is identified by a TLS certificate (staker.crt) that binds a NodeID to a public key. This certificate is used for peer-to-peer authentication, message signing, and stake registration. If the signature scheme underlying these certificates is broken, the entire validator set's identity collapses.

The NIST post-quantum standardization \cite{nist-pqc} provides new signature schemes (ML-DSA, SLH-DSA) that resist quantum attacks. However, replacing classical certificates wholesale introduces risk: the new schemes are less battle-tested, their implementations are younger, and a flaw in the PQ scheme during a pure-PQ deployment would be catastrophic.

Hybrid certificates address this by requiring \emph{both} a classical and a post-quantum signature on every certificate. An attacker must break both schemes simultaneously to forge a validator identity. This paper specifies:
\begin{enumerate}
\item The hybrid certificate profile for Lux validators.
\item The dual-signature trust anchor rooted in Q-Chain.
\item The enrollment protocol for new validators.
\item Device identity integration for hardware-attested nodes.
\end{enumerate}

\section{Certificate Profile}

\subsection{Structure}

A Lux hybrid certificate extends X.509v3 with a custom extension carrying the post-quantum signature and public key. The certificate is valid if and only if both signatures verify.

\begin{verbatim}
Certificate:
  Version: 3
  Serial: <unique>
  Issuer: CN=Lux Validator CA, O=Lux Network
  Subject: CN=NodeID-<base58>, O=Lux Network
  Public Key (classical): BLS12-381 (48 bytes)
  Extensions:
    x-lux-pq-pubkey: ML-DSA-65 (1952 bytes)
    x-lux-pq-signature: ML-DSA-65 sig (3309 bytes)
    x-lux-node-id: NodeID-<base58>
    x-lux-bls-pop: BLS proof-of-possession
  Signature Algorithm: BLS12-381 (classical)
  Signature: <BLS signature over TBS>
\end{verbatim}

\subsection{Dual-Signature Verification}

\begin{algorithmic}[1]
\State \textbf{function} \textsc{VerifyHybridCert}(cert)
\State $tbs \gets cert.\text{toBeSigned}$
\State $valid_c \gets \text{VerifyBLS}(cert.\text{classicalPubKey}, cert.\text{classicalSig}, tbs)$
\State $valid_{pq} \gets \text{VerifyMLDSA}(cert.\text{pqPubKey}, cert.\text{pqSig}, tbs)$
\State \Return $valid_c \land valid_{pq}$
\State \textbf{end function}
\end{algorithmic}

Both signatures cover identical to-be-signed (TBS) data. The PQ signature is placed in an extension rather than replacing the primary signature to maintain compatibility with standard TLS libraries that parse the classical signature field.

\subsection{Size Analysis}

\begin{table}[h]
\centering
\begin{tabular}{@{}lrr@{}}
\toprule
\textbf{Component} & \textbf{Classical Only} & \textbf{Hybrid} \\
\midrule
Public key (classical) & 48 B & 48 B \\
Public key (PQ) & --- & 1,952 B \\
Signature (classical) & 96 B & 96 B \\
Signature (PQ) & --- & 3,309 B \\
Proof of possession & 96 B & 96 B \\
X.509 overhead & $\sim$200 B & $\sim$300 B \\
\midrule
\textbf{Total} & $\sim$440 B & $\sim$5,801 B \\
\bottomrule
\end{tabular}
\caption{Certificate sizes. The hybrid overhead is $\sim$5.4\,KB per validator, negligible for a set of 21--1000 validators.}
\label{tab:cert-size}
\end{table}

\section{Trust Anchors}

\subsection{On-Chain Root of Trust}

The trust anchor for Lux validator certificates is not a traditional CA hierarchy but the Q-Chain validator registry. When a validator registers its stake, it submits both the classical and PQ public keys. Q-Chain stores the binding:

$$\text{Registry}[\text{NodeID}] = (\text{pk}_{\text{BLS}}, \text{pk}_{\text{MLDSA}}, \text{stakeAmount}, \text{epoch}_{\text{registered}})$$

A certificate is trusted if and only if its public keys match the on-chain registration for the claimed NodeID. This eliminates the need for a separate certificate authority---the blockchain itself is the CA.

\subsection{Revocation}

Certificate revocation occurs through two mechanisms:
\begin{enumerate}
\item \textbf{Stake withdrawal}: Removing stake from Q-Chain automatically revokes the associated certificate. Peers reject connections from unstaked NodeIDs.
\item \textbf{Governance revocation}: A governance proposal can revoke a specific NodeID's certificate (for key compromise, misbehavior). This requires a stake-weighted $>2/3$ vote.
\end{enumerate}

No Certificate Revocation Lists (CRLs) or OCSP responders are needed. Peers query Q-Chain state directly---or use the local state copy synchronized via the consensus protocol.

\section{Enrollment Protocol}

New validator enrollment follows a four-step protocol:

\begin{enumerate}
\item \textbf{Key Generation}: The validator generates a BLS key pair and an ML-DSA-65 key pair locally. If using an HSM, the private keys are generated inside the secure boundary \cite{hsm-boundary}.
\item \textbf{Certificate Request}: The validator constructs a self-signed hybrid certificate containing both public keys and submits it to Q-Chain as part of the stake registration transaction.
\item \textbf{On-Chain Validation}: Q-Chain validates the BLS proof-of-possession, verifies the ML-DSA self-signature, and registers the public keys if the stake meets the minimum (2,000 LUX).
\item \textbf{Peer Distribution}: Once registered, the validator's certificate is distributed to all peers via the standard P2P gossip protocol. Peers verify the certificate against Q-Chain state before accepting connections.
\end{enumerate}

\begin{algorithmic}[1]
\State \textbf{function} \textsc{EnrollValidator}(stake, blsKey, mldsaKey)
\State $cert \gets \text{SelfSignHybrid}(blsKey, mldsaKey)$
\State $pop \gets \text{BLSProofOfPossession}(blsKey)$
\State $tx \gets \text{StakeRegistration}(stake, cert, pop)$
\State $\text{Submit}(tx, \text{Q-Chain})$
\State \textbf{end function}
\end{algorithmic}

\section{Device Identity}

For hardware-attested validator nodes, the hybrid certificate chain extends to include a device identity layer:

\begin{verbatim}
Trust Chain:
  Q-Chain Registry (root of trust)
    -> Validator Hybrid Certificate (BLS + ML-DSA)
      -> Device Attestation Certificate (TPM/TEE)
        -> Runtime Measurement (PCR values / TEE quote)
\end{verbatim}

A validator running in a Trusted Execution Environment (TEE) or with a TPM can bind its hybrid certificate to a hardware attestation \cite{tee-mesh}. This provides assurance that the private keys are held in tamper-resistant hardware and that the validator software has not been modified.

The device attestation is optional---validators without hardware attestation still participate, but their certificates lack the device identity extension. Delegators can use this distinction to prefer hardware-attested validators.

\section{Security Analysis}

\begin{theorem}[Hybrid Binding]
An adversary who compromises only the classical signature scheme cannot forge a valid hybrid certificate.
\end{theorem}

\begin{proof}
A valid hybrid certificate requires both $\text{VerifyBLS}(\cdot) = \text{true}$ and $\text{VerifyMLDSA}(\cdot) = \text{true}$ over identical TBS data. Compromising BLS allows forging $\sigma_{\text{BLS}}$ but not $\sigma_{\text{MLDSA}}$ (which remains secure under lattice hardness). The forged certificate fails the dual-signature check.
\end{proof}

\begin{theorem}[On-Chain Revocation Completeness]
A revoked certificate is rejected by all honest peers within one consensus round after the revocation transaction is finalized.
\end{theorem}

\begin{proof}
Honest peers verify certificates against their local copy of Q-Chain state. Q-Chain finality (via Quasar) occurs within 10--100\,ms \cite{quasar}. Once finalized, all honest peers observe the revocation within one state sync interval. Peers that have not yet synced reject the certificate upon next sync.
\end{proof}

\section{Conclusion}

Hybrid certificates provide defense-in-depth for validator identity: breaking either the classical or post-quantum scheme alone is insufficient to forge an identity. By rooting trust in Q-Chain rather than a traditional CA hierarchy, Lux eliminates external trust dependencies and integrates revocation into the consensus protocol. The enrollment protocol requires no manual CA operations, and device identity integration provides optional hardware attestation for delegators who demand it.

\begin{thebibliography}{99}

\bibitem{nist-pqc}
NIST (2024).
\textit{Post-Quantum Cryptography Standardization: FIPS 203, 204, 205}.
National Institute of Standards and Technology.

\bibitem{quasar}
Kelling, Z. (2025).
\textit{Quasar: Quantum-Secure Multi-Engine Consensus with Triple-Proof Quantum Finality}.
Lux Industries Research.

\bibitem{hsm-boundary}
Kelling, Z. (2025).
\textit{Secure Enclave, HSM, and Threshold Boundary Design}.
Lux Industries Research.

\bibitem{tee-mesh}
Kelling, Z. (2024).
\textit{TEE Computing Mesh for Attestable Validator Infrastructure}.
Lux Industries Research.

\bibitem{pq-suite}
Kelling, Z. (2024).
\textit{Post-Quantum Cryptographic Suite for Blockchain Infrastructure}.
Lux Industries Research.

\bibitem{crypto-agility}
Kelling, Z. (2024).
\textit{Cryptographic Agility Architecture for Long-Lived Blockchain Systems}.
Lux Industries Research.

\bibitem{rfc9162}
Laurie, B. et al. (2021).
\textit{Certificate Transparency Version 2.0}.
RFC 9162.

\end{thebibliography}

\end{document}