Software & Consulting
Architecture of Feranor PQC Suite
Feranor PQC Suite runs entirely in your infrastructure. Feranor hosts nothing for it and receives nothing from it, neither your data, nor your keys, nor any telemetry. The license key is checked offline and conditions no cryptographic function. Only the console, which neither encrypts nor signs, closes when the license key expires.
The diagram below shows who uses which component, where the keys are, and what crosses your boundary, the messages you exchange with your partners and the signed archive of each version above all.
Who does what
- SDK for .NET. Your .NET 10 applications encrypt, decrypt, sign and verify in process, through dependency injection, Native AOT included.
- fpqc. The command line for scripts and batch jobs. It streams files of any size, and manages, backs up and rotates keys.
- Sidecar. The same operations as an HTTP API for every other language, on a Unix socket, or on TCP with an access token. Each operation is recorded in a hash-chained audit journal before it runs, whose records follow a published JSON Schema for your SIEM. Its contract is public, as an OpenAPI 3.1 description.
- Console. A web page over the sidecar, in French and English, for business users who encrypt, sign and check files. It holds no key and does no cryptography of its own, and reaches the sidecar like any other client.
- One engine. The SDK, fpqc and the sidecar share it, so they write and read the same standard CMS messages. It runs on the cryptography of the platform (.NET, with OpenSSL 3.5 or later on Linux) and refuses any algorithm outside its profile.
Where the keys are
Private keys stay with you, in a key store of standard PEM files, encrypted with PBES2 and readable by their owner only. Its secret comes from a mounted file, or straight from Azure Key Vault, AWS Secrets Manager, Google Cloud Secret Manager or HashiCorp Vault. A signing key can stay in an HSM.
Keys are rotated without downtime, the processes sharing the store following the rotation. Key material is wiped from memory as soon as it is no longer needed, errors included.
What crosses your network
- Your messages. What you encrypt and sign goes to your partners as standard CMS messages (RFC 5652), which any implementation of the same algorithms can read.
- The release. Each version is one archive, the same for every customer, whose checksums are signed with Feranor's release certificate. You check it before installing it, as the releases page shows.
- Revocation checks. When a signature is verified, the platform checks online by default that the signer's certificates are not revoked, at the addresses your PKI writes in them. It can be set offline.
- Nothing to Feranor. No call to Feranor, no update check, no telemetry. Logs, metrics and traces go only where you send them, through OpenTelemetry.
Interfaces and exposure
- The SDK and fpqc listen on nothing.
- The sidecar listens on a Unix socket or on loopback, and requires an access token beyond loopback. TLS is left to your proxy or service mesh. Its limits on size, connections and concurrent operations are set by you.
- The console belongs behind a reverse proxy that terminates TLS. Its sign-in is throttled, its session cookie is bound to the site, and per-user access comes through your single sign-on in front of it.
- The container images are minimal, with no shell, and run as a non-root user.
Going further
The releases page gives the certificate that checks every archive, and the security advisories page what we publish when a vulnerability is fixed. For your supplier assessment, our security pack (security assurance plan, product security, detailed architecture, standards and profiles, in English or French) is sent on request to sales@feranor.com.