Passer au contenu principal
Un rapport de conformité n’est utile à un auditeur que s’il peut être sûr qu’il n’a pas été édité depuis que vous l’avez généré. Chaque rapport que produit OrcaRouter porte deux choses qui rendent cette vérification possible sans aucun accès à un compte : un hash de contenu SHA-256 des preuves canoniques et une signature Ed25519 sur ce hash. Cette page montre comment vérifier un rapport de conformité — récupérer la clé publique, confirmer le hash, et vérifier la signature — en n’utilisant que des endpoints publics. Le cas d’usage est concret : vous remettez à un auditeur un rapport signé (ou un lien de portail de partage), et il doit prouver qu’il est authentique et non altéré avant de s’y fier. Il ne touche jamais à votre espace de travail, à votre clé, ni à la console.

​
1. Ce qui voyage avec un rapport

Trois valeurs rendent un rapport auto-vérifiable. Elles apparaissent sur l’artefact de rapport et sur les métadonnées publiques du portail de partage pour le lien.
Un condensé SHA-256 hex minuscule du JSON de preuves canonique du rapport. Les octets sont déterministes pour un rapport donné, donc quiconque possède les mêmes preuves recalcule le hash identique. Toute édition des preuves change cette valeur.
Une signature Ed25519 base64 calculée sur le content_hash hex. Elle prouve que le hash a été signé par la clé de signature d’OrcaRouter et n’a pas été forgé.
Un identifiant court et stable pour la clé publique active (par exemple orca- suivi d’un fragment hex). Le vérificateur l’utilise pour confirmer que le rapport a été signé par la clé actuellement publiée — un rapport signé par un id de clé inconnu échoue de manière fail-closed.
La signature couvre le hash de contenu, pas directement les octets du PDF, du CSV ou du JSON rendu. Les mêmes preuves se rendent dans les trois formats à partir d’un seul hash, donc la garantie d’intégrité porte sur les preuves sous-jacentes — chaque export d’un rapport donné partage un seul content_hash, signature et sig_key_id.

​
2. Récupérez la clé publique

La clé publique de signature est publiée sur un endpoint ouvert — aucune authentification, aucun contexte d’espace de travail. Un auditeur l’appelle directement. 
curl https://api.orcarouter.ai/api/public/compliance/pubkey

{
  "success": true,
  "message": "",
  "data": {
    "algo": "ed25519",
    "key_id": "orca-1a2b3c4d5e6f",
    "public_key": "base64-encoded-ed25519-public-key"
  }
}
La public_key est la clé publique Ed25519 de 32 octets encodée en base64. Le key_id ici doit correspondre au sig_key_id sur le rapport — s’il ne correspond pas, le rapport a été signé par une clé différente (probablement ayant fait l’objet d’une rotation ou plus ancienne) et ne se vérifiera pas contre cette clé publiée.

​
3. Vérifiez la signature

Vous pouvez vérifier la signature de deux façons. Soit demander à OrcaRouter de vérifier le tuple pour vous, soit vérifier entièrement hors ligne avec la clé publique publiée.

​
L’endpoint de vérification hébergé

Faites un POST des trois valeurs du rapport vers l’endpoint de vérification ouvert. Il est public — un auditeur l’appelle sans aucune référence d’identification. 
curl -X POST https://api.orcarouter.ai/api/public/compliance/verify \
  -H "Content-Type: application/json" \
  -d '{
    "content_hash": "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08",
    "signature": "base64-ed25519-signature-from-the-report",
    "sig_key_id": "orca-1a2b3c4d5e6f"
  }'

{
  "success": true,
  "message": "",
  "data": {
    "valid": true,
    "key_id": "orca-1a2b3c4d5e6f"
  }
}
valid: true signifie que la signature est correcte contre la clé active pour cet id de clé. valid: false signifie soit que la signature ne correspond pas au hash, soit que le hash est vide, soit que le sig_key_id ne correspond pas à la clé actuellement publiée.
L’endpoint de vérification renvoie en écho le key_id actif. Comparez-le au sig_key_id que vous avez soumis : s’ils diffèrent, le rapport a été signé par une clé qui n’est plus l’active, ce qui explique l’échec de la vérification.

​
Vérifiez hors ligne avec la clé publique

Un auditeur sceptique n’a pas besoin de faire confiance à l’endpoint de vérification du tout. Parce que l’algorithme est du Ed25519 standard sur le hash de contenu hex, la signature est vérifiable avec n’importe quelle bibliothèque cryptographique : 
import base64
from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PublicKey

# public_key from GET /api/public/compliance/pubkey
pub = Ed25519PublicKey.from_public_bytes(base64.b64decode(PUBLIC_KEY_B64))

# content_hash + signature from the report
message = CONTENT_HASH.encode()            # the hex hash string, as bytes
signature = base64.b64decode(SIGNATURE_B64)

pub.verify(signature, message)             # raises if invalid; returns None if valid
Le message signé est la chaîne de hash hex elle-même, encodée en octets ASCII — pas les 32 octets bruts que le hash décode. Transmettez la valeur content_hash telle quelle avant la vérification de signature, sinon la vérification échouera sur un rapport correct.

​
4. Ce que couvre la signature

Une signature prouve que le content_hash du rapport a été signé par OrcaRouter, et le hash prouve que les preuves ne sont pas éditées. Une subtilité : le hash est calculé sur une forme canonique des preuves que construit la passerelle — pas sur les octets bruts du fichier JSON ou PDF. Donc re-hasher l’artefact téléchargé vous-même ne reproduira pas content_hash. Utilisez l’endpoint de vérification (§2/§3), qui recalcule le hash canonique et vérifie la signature Ed25519 pour vous :
VérificationSignification
signature_valid: trueLe content_hash a été signé par la clé d’OrcaRouter — les preuves sont authentiques et non éditées.
L’id de clé correspondLe sig_key_id du rapport == l’id de clé publié → signé par la clé active.
Les deux passant signifie que le rapport est authentique et non altéré. Une signature échouée signifie que le hash, les preuves ou l’id de clé n’appartiennent pas à la clé de signature d’OrcaRouter.

​
5. Vérifier un rapport partagé

Lorsque vous envoyez à un auditeur un lien de portail de partage au lieu du fichier, les métadonnées du portail portent déjà content_hash, signature et sig_key_id, plus un flag signature_valid calculé côté serveur. L’auditeur peut faire confiance au flag et relancer les vérifications ci-dessus contre la clé publique indépendamment — le portail de partage ne nécessite aucune connexion, et le chemin de vérification est identique.
Un artefact partagé n’est servi que tant que sa région estampillée correspond encore à la région de résidence des données déclarée de votre espace de travail. Si la région a été changée, les téléchargements sont retenus même si les métadonnées de signature restent vérifiables. C’est intentionnel — voir Lectures inter-régions.

​
6. Où aller ensuite

Rapports signés

Comment un rapport signé est généré, quelles preuves il capture, et comment frapper un lien de partage auditeur.

Exporter les preuves

Récupérez les preuves de rapport en PDF, CSV ou JSON pour les documents de travail de votre auditeur.

Résidence des données

Comment l’estampille de région sur un rapport gouverne où il est stocké et servi.

Responsabilité partagée

Ce qu’OrcaRouter garantit sur le chemin de la passerelle versus ce qui reste le vôtre.
La clé de signature est celle d’OrcaRouter ; la vérification est celle de tout le monde. Cette séparation est tout l’intérêt — un auditeur prouve qu’un rapport est authentique sans jamais avoir besoin d’accéder à l’espace de travail qui l’a produit.