Zum Hauptinhalt springen
Ein Compliance-Report ist für einen Auditor nur nützlich, wenn er darauf vertrauen kann, dass er seit Ihrer Erzeugung nicht bearbeitet wurde. Jeder Report, den OrcaRouter produziert, trägt zwei Dinge, die diese Prüfung ohne jeden Kontozugang möglich machen: einen SHA-256-Content-Hash des kanonischen Nachweises und eine Ed25519-Signatur über diesen Hash. Diese Seite zeigt, wie Sie einen Compliance-Report verifizieren — den öffentlichen Schlüssel holen, den Hash bestätigen und die Signatur prüfen — nur mit öffentlichen Endpunkten. Der Anwendungsfall ist konkret: Sie übergeben einem Auditor einen signierten Report (oder einen Share-Portal-Link), und er muss beweisen, dass er authentisch und unverfälscht ist, bevor er sich darauf verlässt. Er berührt niemals Ihren Workspace, Ihren Schlüssel oder die Konsole.

​
1. Was mit einem Report mitreist

Drei Werte machen einen Report selbstverifizierend. Sie erscheinen auf dem Report-Artefakt und auf den öffentlichen Share-Portal-Metadaten des Links.
Ein Kleinbuchstaben-Hex-SHA-256-Digest des kanonischen Nachweis-JSON des Reports. Die Bytes sind für einen gegebenen Report deterministisch, sodass jeder mit demselben Nachweis den identischen Hash neu berechnet. Jede Bearbeitung des Nachweises ändert diesen Wert.
Eine base64-Ed25519-Signatur, berechnet über den Hex-content_hash. Sie beweist, dass der Hash von OrcaRouters Signing-Key signiert und nicht gefälscht wurde.
Ein kurzer, stabiler Identifier für den aktiven öffentlichen Schlüssel (zum Beispiel orca- gefolgt von einem Hex-Fragment). Der Verifizierer nutzt ihn, um zu bestätigen, dass der Report von dem aktuell veröffentlichten Schlüssel signiert wurde — ein Report, der von einer unbekannten Key-ID signiert wurde, failt closed.
Die Signatur deckt den Content-Hash ab, nicht direkt die gerenderten PDF-, CSV- oder JSON-Bytes. Derselbe Nachweis rendert aus einem Hash zu allen drei Formaten, sodass die Integritätsgarantie auf dem zugrunde liegenden Nachweis liegt — jeder Export eines gegebenen Reports teilt einen content_hash, eine signature und eine sig_key_id.

​
2. Den öffentlichen Schlüssel holen

Der öffentliche Signing-Schlüssel wird an einem offenen Endpunkt veröffentlicht — keine Auth, kein Workspace-Kontext. Ein Auditor ruft ihn direkt auf. 
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"
  }
}
Der public_key ist der base64-codierte 32-Byte-Ed25519-Public-Key. Die key_id hier muss mit der sig_key_id auf dem Report übereinstimmen — wenn nicht, wurde der Report von einem anderen (wahrscheinlich rotierten oder älteren) Schlüssel signiert und wird nicht gegen diesen veröffentlichten Schlüssel verifizieren.

​
3. Die Signatur verifizieren

Sie können die Signatur auf zwei Wegen verifizieren. Entweder bitten Sie OrcaRouter, das Tupel für Sie zu prüfen, oder Sie verifizieren vollständig offline mit dem veröffentlichten öffentlichen Schlüssel.

​
Der gehostete Verify-Endpunkt

Posten Sie die drei Werte vom Report an den offenen Verify-Endpunkt. Er ist öffentlich — ein Auditor ruft ihn ohne Credentials auf. 
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 bedeutet, dass die Signatur gegen den aktiven Schlüssel für diese Key-ID aufgeht. valid: false bedeutet entweder, dass die Signatur nicht zum Hash passt, der Hash leer ist oder die sig_key_id nicht zum aktuell veröffentlichten Schlüssel passt.
Der Verify-Endpunkt gibt die aktive key_id zurück. Vergleichen Sie sie mit der sig_key_id, die Sie übermittelt haben: Wenn sie sich unterscheiden, wurde der Report von einem Schlüssel signiert, der nicht mehr der aktive ist, weshalb er nicht verifiziert wurde.

​
Offline mit dem öffentlichen Schlüssel verifizieren

Ein skeptischer Auditor muss dem Verify-Endpunkt überhaupt nicht vertrauen. Weil der Algorithmus Standard-Ed25519 über den Hex-Content-Hash ist, ist die Signatur mit jeder Crypto-Bibliothek prüfbar: 
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
Die signierte Nachricht ist der Hex-Hash-String selbst, codiert als ASCII-Bytes — nicht die rohen 32 Bytes, zu denen der Hash decodiert. Geben Sie den content_hash-Wert unverändert weiter, bevor Sie die Signatur verifizieren, sonst schlägt die Prüfung bei einem korrekten Report fehl.

​
4. Was die Signatur abdeckt

Eine Signatur beweist, dass der content_hash des Reports von OrcaRouter signiert wurde, und der Hash beweist, dass der Nachweis unbearbeitet ist. Eine Feinheit: Der Hash wird über eine kanonische Form des Nachweises berechnet, den das Gateway baut — nicht über die rohen Bytes der JSON- oder PDF-Datei. Daher wird das eigenhändige Neuhashen des heruntergeladenen Artefakts den content_hash nicht reproduzieren. Nutzen Sie den Verify-Endpunkt (§2/§3), der den kanonischen Hash neu berechnet und die Ed25519-Signatur für Sie prüft:
PrüfungBedeutung
signature_valid: trueDer content_hash wurde von OrcaRouters Schlüssel signiert — der Nachweis ist authentisch und unbearbeitet.
Key-ID passtReport-sig_key_id == die veröffentlichte Key-ID → vom aktiven Schlüssel signiert.
Wenn beide bestehen, ist der Report authentisch und unverfälscht. Eine fehlgeschlagene Signatur bedeutet, dass der Hash, der Nachweis oder die Key-ID nicht zu OrcaRouters Signing-Key gehört.

​
5. Einen geteilten Report verifizieren

Wenn Sie einem Auditor einen Share-Portal-Link statt der Datei senden, tragen die Portal-Metadaten bereits content_hash, signature und sig_key_id, plus ein serverseitig berechnetes signature_valid-Flag. Der Auditor kann dem Flag vertrauen und die obigen Prüfungen unabhängig gegen den öffentlichen Schlüssel erneut ausführen — das Share-Portal braucht kein Login, und der Verifizierungspfad ist identisch.
Ein geteiltes Artefakt wird nur ausgeliefert, solange seine gestempelte Region noch mit der deklarierten Datenresidenz-Region Ihres Workspaces übereinstimmt. Wenn die Region geändert wurde, werden Downloads zurückgehalten, auch wenn die Signatur-Metadaten verifizierbar bleiben. Das ist beabsichtigt — siehe Regionsübergreifende Lesezugriffe.

​
6. Wohin als Nächstes

Signierte Reports

Wie ein signierter Report erzeugt wird, welchen Nachweis er erfasst und wie man einen Auditor-Share-Link prägt.

Nachweise exportieren

Ziehen Sie Report-Nachweise als PDF, CSV oder JSON für die Arbeitspapiere Ihres Auditors.

Datenresidenz

Wie der Region-Stempel auf einem Report regelt, wo er gespeichert und ausgeliefert wird.

Geteilte Verantwortung

Was OrcaRouter auf dem Gateway-Pfad garantiert versus was Ihnen bleibt.
Der Signing-Schlüssel gehört OrcaRouter; die Verifizierung gehört jedem. Diese Trennung ist der ganze Punkt — ein Auditor beweist, dass ein Report authentisch ist, ohne je Zugang zu dem Workspace zu benötigen, der ihn produziert hat.