Siqn
Back to documentation

Architecture

The Quantum-Safe PKI project is built on a microservices architecture, with each component designed to perform a specific function within the overall PKI ecosystem. This modular approach allows for flexibility, scalability, and easier maintenance.

System Overview

The system consists of several independent microservices that communicate with each other through well-defined APIs. Each service is responsible for a specific aspect of the PKI functionality:

Microservices Architecture

  • CA Service

    Core certificate authority that issues and manages certificates using post-quantum cryptography.

  • ACME Server

    Implements the ACME protocol for automated certificate management, interacting with the CA Service.

  • Signing Service

    Provides hybrid signature capabilities for software artifacts using both classical and post-quantum algorithms.

  • Transparency Log

    Records all issued certificates in an append-only log for auditability and transparency.

  • Device Service

    Handles certificate provisioning for devices, forwarding CSRs to the CA Service.

  • CLI

    Command-line interface for interacting with the Signing Service to sign software artifacts.

Service Interactions

The microservices interact with each other through well-defined APIs, forming a cohesive PKI ecosystem:

  • acme-server calls ca-service /sign endpoint to get certificates for ACME clients.
  • acme-server calls ca-service /revoke-cert endpoint when certificates need to be revoked.
  • acme-server (optionally) calls ca-service /crl endpoint for client certificate validation.
  • device-service calls ca-service /sign endpoint to obtain certificates for devices.
  • cli calls signing-service /v1/signatures endpoint to sign software artifacts.
  • TLS clients connecting to acme-server, ca-service, signing-service may undergo mTLS verification including CRL checks against the ca-service CRL.
  • acme-server, ca-service, signing-service fetch OCSP staples for their own certificates from the ca-service /ocsp endpoint.

Cryptographic Architecture

The project implements a hybrid cryptographic approach, combining classical and post-quantum algorithms:

  • Digital Signatures: Uses both ECDSA P-256 (classical) and EdDilithium2 (post-quantum) for digital signatures, providing security against both classical and quantum attacks.
  • Key Exchange: Implements X25519+MLKEM768 hybrid key exchange for TLS, combining the classical X25519 with the post-quantum ML-KEM algorithm.
  • Certificate Chain: The CA uses an ECDSA P-256 key for its own root certificate (for compatibility with existing systems) but signs issued certificates with EdDilithium2.
  • JWS: The ACME server supports JSON Web Signatures using RSA, ECDSA, and EdDilithium2, extending the JWS standard to support post-quantum algorithms.

Deployment Architecture

The microservices can be deployed in various configurations depending on the requirements:

  • Development: All services can run on a single machine with local storage for keys and certificates.
  • Production: Services can be deployed across multiple machines or containers, with appropriate network security and key management.
  • Key Storage: Keys can be stored either on the filesystem (fs) or in a PKCS#11 hardware security module (pkcs11) for enhanced security.
  • Databases: The ACME server requires a PostgreSQL database for state management, while the Signing Service uses SQLite for storing signing logs and metadata.

Next Steps

Now that you understand the architecture of the Quantum-Safe PKI project, you might want to explore:

  • CA Service: Learn about the core Certificate Authority service.
  • ACME Server: Understand the automated certificate management service.
  • Prerequisites: Learn what you need to set up before building the services.