Ein Signer-Interface, vier Laufzeiten: C2PA-Signierung in native iOS- und Android-Krypto überbrücken

Auf dem Handy ist das richtige Zuhause für einen Signaturschlüssel der Plattform-Keystore, nicht JavaScript. Aber unsere Manifest-Logik ist TypeScript, und wir wollten sie nicht pro Plattform forken. Die Lösung ist eine schmale Brücke: Unsere Open-Source-Bibliothek c2pa-ts definiert die Interfaces Signer, TimestampProvider und Krypto, und dünne native Adapter injizieren Plattform-Callbacks für Signieren, Hashen und Zufall. Eine auditierte Manifest-Codebasis läuft auf iOS, Android, im Browser und in Lambda. Das Zuhause des Schlüssels wird zur Deployment-Entscheidung, nicht zum Architektur-Fork.

Interface-first-Kryptografie

Alles in der Bibliothek, das Kryptografie berührt, hängt an Interfaces, nicht an Implementierungen. Browser-Deployments verdrahten WebSigner und WebCrypto. Server-Deployments nutzen LocalSigner und Node-Krypto. Mobil nutzt NativeSigner über Plattform-Callbacks. Der Manifest-Code oberhalb dieser Interfaces ist auf allen vier byteweise identisch. Wenn wir einen Claim-Encoding-Bug fixen, ist er überall gefixt, einmal.

Browser-Schlüssel: Erzeugung, Validierung und 30-Tage-Rotation

Beweise im Browser zu signieren heißt, der private Schlüssel lebt in IndexedDB. Dieser Satz macht Sicherheitsingenieure nervös, und das sollte er. Das sind software-gehaltene Browser-Schlüssel, kein hardware-gestütztes Schlüsselmaterial, und das Design behandelt sie entsprechend.

In-situ-Kryptografie heißt: Signiert wird bei der Erfassung, auf dem Gerät, am Edge. Läge der private Schlüssel auf einem Server, bräuchte jede Erfassung einen Roundtrip, der entweder den Schlüssel oder den Beweis transportiert, und beide Optionen brechen das Modell. WebCrypto erzeugt ECDSA-P-256-Paare und kann CryptoKey-Objekte in IndexedDB persistieren. Die Fähigkeit ist da. Die Disziplin muss von einem selbst kommen.

Niemals einem gespeicherten Schlüssel trauen. IndexedDB ist für den Nutzer sichtbarer, bearbeitbarer Speicher. Also behandelt getKeyPair jeden abgerufenen Schlüssel als verdächtig, bis das Gegenteil bewiesen ist. Die Validierungsleiter, in Reihenfolge: Ist der Eintrag jünger als 30 Tage; trägt er eine Client-Identität; ist er tatsächlich ein Schlüsselobjekt des richtigen Typs mit den richtigen Usages; und schließlich, die entscheidende Prüfung, kann der gespeicherte öffentliche Schlüssel eine frische Signatur des gespeicherten privaten Schlüssels verifizieren? Ein Schlüsselpaar, das eine Sprosse verfehlt, wird gelöscht und neu erzeugt. Die letzte Sprosse ist die, die alle überspringen, und sie ist die einzige, die Bitflips, Teil-Schreibvorgänge und manipulierte Speicher erwischt. Strukturprüfungen beweisen die Form. Ein Signatur-Verifizierungs-Roundtrip beweist die Funktion.

Dreißig Tage, dann Neuanfang. Langlebige Browser-Schlüssel akkumulieren Exposition, denn jede Extension, jedes XSS-Fenster, jede Shared-Device-Session summiert sich. Rotation begrenzt den Explosionsradius, und weil Zertifikate pro Schlüssel über unsere API ausgestellt werden, ist Rotation ein routinemäßiger CSR, keine Migration. Vergänglichkeit ist eine Eigenschaft des Sicherheitsmodells, keine Unannehmlichkeit, für die man sich entschuldigt.

Schlüssel an Geräte binden. Ein Thumbmark-Fingerprint wird neben dem Schlüssel als dessen Client-Identität gespeichert. Das ist keine PUF, und wir behaupten das nicht: Browser-Fingerprints sind probabilistisch und veränderbar. Was er bringt, ist Missbrauchsanalyse und Lebenszyklus-Kontext, ein pragmatisches Web-Analogon zur Gerätebindung. Wo die Hardware echte Schlüssel-Attestierung erlaubt, sollte man die nutzen. Wo nicht, schlägt ehrliche schwache Bindung das so-tun-als-ob.

Vom Schlüsselpaar zum Zertifikat. Ein PKCS#10-CSR wird aus dem Browser-Schlüssel erzeugt, über die DPoP- und HMAC-geschützte API eingereicht, und die zurückgegebene Kette wird geparst und in einen WebSigner verpackt, der das C2PA-Signer-Interface implementiert. Das gesamte Leben des Schlüssels, Erzeugung, Validierung, Zertifizierung, Rotation, Signierung, läuft in einer Schleife, die das SDK ohne Nutzerbeteiligung treibt.

Die native Bridge im Detail

setupCrypto nimmt sieben Callbacks entgegen: Einmal-Digest, Streaming-Digest-Erzeugung, Streaming-Update, Streaming-Finalisierung, Signaturverifikation, Signierung und Zufall. Streaming-Digest-IDs lassen nativen Code große Assets inkrementell hashen, ohne Puffer hin- und herzuschieben. NativeTimestampProvider delegiert den gesamten RFC-3161-Roundtrip an Plattform-Code, weil Networking und Certificate Pinning zur App gehören, nicht zur Bibliothek.

Das Interface ist die ganze Architektur. Alles andere ist Klempnerei.

Die Signaturformat-Steuer: ASN.1 gegen P1363

Hier der subtile Teil, der Programmierern Tage kostet. COSE und C2PA erwarten ECDSA-Signaturen in IEEE-P1363-Form: r und s konkateniert, mit fester Breite. Plattform-APIs, iOS, Android, die meisten HSMs, liefern ASN.1 DER. Die Brücke konvertiert in beide Richtungen über einen ASN.1-EC-Signatur-Formatter: DER zu P1363 auf dem Weg aus nativen Signern, P1363 zu DER auf dem Weg in native Verifizierer.

Signaturen scheitern einfach in fremden Werkzeugen, lautlos, an Dateien, die die eigenen Nutzer längst ausgeliefert haben. Das ist die Fehlerklasse, die man mit Konformitäts-Testvektoren findet, nicht mit Unit-Tests, weshalb unsere Krypto-Grenze von beiden abgedeckt ist.

Warum das für Robotik und Edge-Geräte zählt

Roboter, fahrerlose Transportfahrzeuge und Industriekameras sind native Code-Umgebungen mit echten Keystores. Diese Architektur ist ihre Rampe: dieselbe Manifest-Pipeline, mit Schlüsseln in der Hardware, die die Plattform bietet. PUF-abgeleitete Schlüssel aus unserer Visual-Handshake-Arbeit stecken im selben Callback-Interface. Signieren am Edge, zum Erfassungszeitpunkt, ist das Muster, das unser Mutual-Witnessing-Patent beschreibt, und diese Brücke ist der Weg zu Geräten, die nie einen Browser ausführen werden.

Häufige Fragen

Warum keinen Rust-Kern auf jede Plattform kompilieren? Das kehrt unsere Investition um: Der Wert liegt in der geteilten, auditierten Manifest-Schicht. Schmale Krypto-Callbacks pro Plattform sind günstiger zu reviewen als eine volle FFI-Fläche.

Bremst die Brücke das Signieren? Signiert werden einige hundert Bytes über die Grenze. Das Volumenproblem ist das Hashen, und genau deshalb ist die Digest-API streamingfähig.

Kann eine Roboterflotte Hardware-Attestierung nutzen? Ja, auf der nativen Schicht. Die Bibliothek sieht einen Signer; ob der Schlüssel von einem Secure Element attestiert ist, ist eine Eigenschaft der Callback-Implementierung.

Ist IndexedDB sicher für private Schlüssel? Sicher genug für das Browser-Bedrohungsmodell, mit nicht-extrahierbaren Schlüsseloptionen, wo unterstützt, und Validierung-beim-Lesen als Sicherheitsnetz. Es ist keine Secure Enclave, und unsere Sicherheitsbehauptungen tun nicht so.

Warum 30 Tage und nicht 90? Kürzere Fenster schrumpfen die Exposition, vervielfachen aber die Zertifikatsausstellung. Dreißig Tage balancieren beides für die Beweiserfassungs-Volumina, die wir sehen. Die Konstante ist eine Policy-Entscheidung, kein Naturgesetz.

Plattformübergreifende Provenance ist üblicherweise eine Geschichte über Kompromisse. Interface-first-Design ist, wie unsere stattdessen zu einer Geschichte über Wiederverwendung wurde.