# Technology and security This page describes the target architecture of YORYX TRUST: what the trust infrastructure will be when it enters service. Nothing below is presented as already achieved. The components are in preparation, the standards cited are targets, and no third-party attestation is claimed. What is this? The target technical architecture that will protect keys and signatures. Who is it for? For anyone curious how security will actually be ensured. What can I do here? See how keys will be kept inside a dedicated module. - [See the cryptographic module](https://trust.yoryx.ma/en/technology#tech-module) ## 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. - Back to top ## 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. - Back to top ## 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](https://trust.yoryx.ma/en/signing) - Back to top ## 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. - Back to top ## 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. ## CEN EN 419 221-5 — target protection profile Protection profile applicable to cryptographic modules used as signature or seal creation devices. It is the acquisition target set for the module. ## Common Criteria EAL4+ — target evaluation level Target security evaluation level for the cryptographic module. It is an acquisition target: the exact position of the hardware finally chosen will be verified before any assertion is made. ## FIPS 140-2 and FIPS 140-3, level 3 — target reference United States requirements reference for cryptographic modules, whose level 3 imposes physical intrusion resistance and detection. Targeted on the same footing as the European protection profile. ## ETSI EN 319 401, ETSI EN 319 411-1, ETSI EN 319 411-2, ETSI EN 319 421 and ETSI EN 319 422 — target standards General requirements for trust service providers, requirements specific to certificate issuers, and requirements specific to timestamping. They structure the policy and practices the register will publish. ## DGSSI references Ref\_PSCo\_AG and Ref\_QSCD — target references Requirement references published by the national authority: one for trust service providers subject to approval, the other for signature creation devices. They are what the application will have to satisfy. - Back to top ## 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. - Back to top ## Our regulatory status today YORYX TRUST is preparing its declaration and its application for approval with the Direction Générale de la Sécurité des Systèmes d'Information (DGSSI) under Law No. 43-20 on trust services for electronic transactions. As of today, YORYX TRUST is neither declared nor approved. - Back to top