Technology and security

Target architecture of the trust hierarchy

The planned infrastructure rests on a two-tier hierarchy and on separate services, each with its own key and its own log.

• A root certification authority kept offline, brought up only for the duration of a key ceremony, which limits its exposure to those operations alone.

• Separate issuing certification authorities per service — signature, seal, timestamping — so that an incident affecting one service does not spread to the others.

• A timestamping authority fed by a trusted time source, separate from the certification authorities.

• A validation service that checks a certificate's state and a signature's validity at the moment it is relied upon.

• A remote signing service, which will produce the signature on the signatory's behalf and under the signatory's sole control.

Key protection

The authorities' private keys are the most sensitive point of the whole system: whoever holds one can produce a signature in the service's name. The target architecture treats them accordingly.

• Keys are generated and held inside a hardware cryptographic module and never leave it in the clear.

• No sensitive operation is carried out by one person: key activation and administrative operations require dual control and a quorum of M out of N holders.

• Roles are separated — administration, operation, audit — and no one person holds two of them.

• Authority keys are generated in a ceremony, following a script written in advance, before witnesses, and recorded in a signed minute.

• Audit logs are timestamped and tamper-evident, so that an alteration is detectable after the fact.

• Key backups are encrypted and their restoration is itself subject to the quorum, never to an individual decision.

• Physical access to the equipment is restricted, traced, and distinct from logical access to the services.

Remote signing and timestamping

In the target model the signatory does not physically hold the key: it is held inside the hardware cryptographic module and is activated only on a request that the signatory alone can produce.

Strong authentication of the signatory is therefore not a mere site login: it is a component of the signing service itself, and it is what gives effect to the sole control required of a signature creation device subject to approval.

The planned timestamping relies on a trusted time source and on a separate authority, so that the date attached to a document depends neither on the user's own clock nor on the clock of the service that produced the signature.

How signing actually happens — nothing to buy, keys kept inside the module, identity based on the electronic national identity card, authorisation from the phone — is described on a page of its own.

How signing will work

Continuity and recovery

• A secondary site is planned, so that the loss of the primary site costs neither the service nor the evidence already produced.

• Backups are encrypted and their restoration is subject to the same quorum as key operations.

• Restoration is exercised for real and at regular intervals: a recovery procedure that has never been played out is not a guarantee, it is an intention.

Targeted standards and references

The texts below are targets. They describe the level the architecture is preparing for, not a level already reached: no conformity is established as of today, and no third-party attestation is claimed.

What is not published, and why

This page describes architectural principles, never equipment. The identity of the hardware — its make, its model, its serial number —, its configuration, and the place where it is installed are not published and will not be.

That silence is a security measure, not reticence: whoever knows the exact reference of a piece of equipment also knows the public list of its flaws. Security by design is judged on the principles stated and on the audit that verifies them, never on the publication of an inventory.