Sicherheit bei qub

Gültig ab: 23. September 2026 Version: 1.1 — Prüfung auf Implementierungsgenauigkeit

Für Forschende — Schnellreferenz:

• Wohin Berichte senden: support@qub.social mit dem Betreffpräfix [SECURITY].
• Was beifügen: die Schwachstelle, Schritte zur Reproduktion und ein etwaiger Proof-of-Concept.
• Unsere Reaktion: Wir bestätigen den Eingang innerhalb von 3 Geschäftstagen und streben an, einen Fix innerhalb von 90 Tagen auszuliefern.
• Safe Harbor: Wir werden keine rechtlichen Schritte gegen Forschung in gutem Glauben einleiten, die den Regeln in §12 folgt (kein Zugriff auf Daten, die Ihnen nicht gehören, keine Dienstverschlechterung, keine Aufbewahrung erlangter Daten über das hinaus, was nötig ist, um das Problem zu demonstrieren, und Einräumung eines angemessenen Offenlegungsfensters).

Vollständige Details finden Sie in §12 (Koordinierte Offenlegung).

Wer wir sind

qub.social wird betrieben von VSPRY AUSTRALIA PTY LIMITED (ABN 41 631 026 330), Level 38, 71 Eagle Street, Brisbane QLD 4000, Australien. Verweise auf „qub", „wir", „uns" und „unser" beziehen sich auf diese Gesellschaft.

Sicherheitskontakt: support@qub.social mit dem Betreffpräfix [SECURITY].

1. Unser Ansatz

qub ist Vertrauensinfrastruktur. Das Produkt ist wertlos, wenn es nicht sicher ist, daher ist Sicherheit kein Feature — es ist das Substrat. Diese Seite beschreibt in konkreten Worten, wie wir unseren Stack, Ihre Daten und die Integrität versiegelter Inhalte schützen.

Der Wert einer verifizierbaren zeitlichen Verpflichtung wächst, je mehr des Internets maschinengeneriert wird. Eine verifizierte Speichertransaktion oder ein verankerter Transparenz-Log-Eintrag kann belegen, dass der Chiffretext spätestens zu seiner Blockzeit existierte; das versiegelte Artefakt belegt davon getrennt die Inhaltsintegrität, die Bindung an die drand-Runde und etwaige Urheberschaftssignaturen. Diese Aussagen klar zu trennen, ist die Latte, an der diese Seite gemessen wird.

Wir bitten Sie nicht, uns zu vertrauen. Wir entwerfen so, dass das von uns geforderte Vertrauen so klein wie möglich ist, und wo Vertrauen erforderlich ist, erklären wir genau, worauf vertraut wird und warum.

Drei Prinzipien treiben jede Designentscheidung:

• Minimieren Sie, was der Server sehen kann. Im standardmäßigen Nachrichtenfluss im Browser verbleiben Klartext und Wrapper-Schlüssel auf Ihrem Gerät. Die serverseitige Builder-Versiegelung, die Pakt-Mitunterzeichnung und die ausdrücklich aktivierte Wiederherstellung haben andere, unten offengelegte Vertrauensgrenzen. Wo wir Metadaten halten, beschränken wir sie auf das, was die gewählte Funktion benötigt.
• Machen Sie eine Kompromittierung lokal eingegrenzt. Eine Verletzung einer einzelnen Komponente (unser Server, der E-Mail-Anbieter, ein drand-Knoten) sollte keine versiegelten Inhalte preisgeben, die ihre Enthüllungszeit noch nicht erreicht haben.
• Machen Sie das Protokoll auditierbar. Das versiegelte Artefakt ist Ende-zu-Ende mit öffentlicher Kryptografie verifizierbar. Sie müssen qub dem Dienst nicht vertrauen, um einen qub das Artefakt zu verifizieren.

2. Bedrohungsmodell

2.1 Wovor wir schützen

• Ein Angreifer, der vor der Enthüllungszeit Lesezugriff auf unsere serverseitig gespeicherten Daten erlangt. Im standardmäßigen privaten Browserfluss erhält er Metadaten und undurchsichtige verpackte Bytes, nicht Klartext oder K. Dieser Schutz gilt nicht für ein ausdrücklich zur Wiederherstellung aufbewahrtes K, für die öffentliche/unverpackte Bereitstellung nach ihrer drand-Runde oder für Klartext, der vorübergehend an die Builder-Workflows /api/v1/seal und Pakt übermittelt wird.
• Ein Angreifer, der den Verkehr zwischen Ihrem Browser und unserer Infrastruktur abfängt. TLS endet an unserem CDN-Edge; versiegelte Nutzlasten sind bereits vor der Übertragung verschlüsselt.
• Ein Angreifer, der eine gespeicherte Nutzlast manipuliert. Die Authentifizierung des äußeren Wrappers (sofern vorhanden), die kanonische Dekodierung, der Body-Hash, die erneute Ableitung der qub_id, die Rundenbindung und optionale Signaturen lassen die Manipulation bei der Verifikation scheitern; der Viewer weigert sich, sie zu rendern.
• Ein Angreifer, der versucht, eine gefälschte Autoren-E-Mail an einen Signaturschlüssel zu binden. Die E-Mail-Attestierung erfordert sowohl den Besitz des privaten Signaturschlüssels als auch eines einmaligen Codes, der an den E-Mail-Posteingang geliefert wird.
• Ein kompromittierter drand-Beacon-Betreiber. Das drand-Netzwerk verwendet Threshold-BLS-Signaturen über mehrere unabhängige Betreiber; eine Minderheit kann keine vorzeitig freigegebenen Signaturen fälschen.

2.2 Wovor wir nicht schützen können

Wir sind ehrlich über unsere Grenzen. qub kann sich nicht verteidigen gegen:

• Eine Kompromittierung Ihres Geräts vor der Versiegelung. Lokale Keylogger, bösartige Browser-Erweiterungen oder physischer Zugriff auf ein entsperrtes Gerät können Klartext am Punkt der Komposition erfassen.
• Einen Zusammenbruch des drand-Schwellenwerts. Mehrere unabhängige Organisationen betreiben das drand-Netzwerk genau, um dies schwierig zu machen, aber es ist nicht kryptografisch unmöglich: Wenn sich genug Betreiber verschwören, könnten sie Timelock-Schlüssel vorzeitig ableiten.
• Die Freigabeeigenschaften einer gültigen Kopie. Ein öffentlicher/unverpackter qub kann nach seiner drand-Runde entschlüsselt werden. Ein privater/verpackter qub erfordert zusätzlich K; wer sowohl die gespeicherten Bytes als auch K erhält, kann ihn nach der Runde entschlüsseln. Einträge im dauerhaften Speicher und in verankerten Logs lassen sich nicht allein dadurch zurückrufen, dass sie von der qub-Produktoberfläche entfernt werden.
• Einen globalen Gegner, der die zugrundeliegende Kryptografie bricht (AES-GCM, BLS12-381-Pairing-Annahmen, SHA3-256, ML-DSA-65). Wenn diese Primitiven fallen, hat das kryptografische Ökosystem im Großen und Ganzen größere Probleme.

3. Clientseitige Kryptografie

Im standardmäßigen Nachrichtenfluss im Browser erfolgt die Inhaltsverschlüsselung vor der Upload-Anfrage. Zwei ausdrückliche Pfade unterscheiden sich davon: Builder /api/v1/seal sendet Klartext und das vom Aufrufer erzeugte K bewusst zur Versiegelung im Arbeitsspeicher an den Worker, und die Vorbereitung/Mitunterzeichnung eines Pakts sendet den signierten strukturierten Pakt an den Dienst, damit dieser das bilaterale Artefakt fertigstellen kann. Keine der beiden Ausnahmen darf mit einer Ende-zu-Ende-Verschlüsselung des Browserpfads verwechselt werden.

3.1 Timelock-Verschlüsselung

qub verwendet tlock — identitätsbasierte Verschlüsselung, die an eine zukünftige drand-Beacon-Runde gekoppelt ist. Die Verschlüsselung erfolgt in Ihrem Browser unter Verwendung des öffentlichen Schlüssels des drand-Netzwerks; der Entschlüsselungsschlüssel wird vom drand-Netzwerk nur dann öffentlich freigegeben, wenn die Zielrunde erreicht ist. Niemand, einschließlich uns, kann den Entschlüsselungsschlüssel im Voraus rekonstruieren.

Wir zielen auf die quicknet-Kette:

• 3-Sekunden-Rundenperiode
• Unchained-Modus (jede Runde ist unabhängig)
• BLS12-381-G1-Signaturen
• Chain-Hash 52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971

Der öffentliche Schlüssel und die Genesis-Zeit der quicknet-Kette werden in den Client einkompiliert. Wir holen Ketten-Parameter zur Laufzeit nicht ab, sodass ein bösartiger Knoten keine Kette ersetzen kann, die wir kontrollieren.

3.2 Symmetrische Verschlüsselung

Das tlock-Schema kapselt einen AES-256-GCM-Inhaltsschlüssel. AES-GCM bietet authentifizierte Verschlüsselung: Ein einzelnes umgekipptes Bit im Geheimtext lässt die Entschlüsselung fehlschlagen, anstatt still beschädigten Klartext zu erzeugen.

3.3 Kanonische Serialisierung

Protokollstrukturen werden mit deterministischem CBOR (RFC 8949 §4.2 Core Deterministic Encoding) serialisiert. Zwei Implementierungen, die dieselbe logische Struktur kodieren, erzeugen identisches CBOR. Vollständige versiegelte Nutzlasten sind nicht deterministisch: Die tlock- und Outer-Wrapper-Verschlüsselung verwenden frische Zufallswerte. Der Body-Hash wird über die rohen Body-Bytes berechnet, während die kanonische Kodierung die umgebenden signierten und Wire-Strukturen eindeutig macht.

Wir haben den CBOR-Encoder für unsere Client- und Server-Implementierungen von Hand geschrieben, anstatt uns auf eine generische Serialisierungsbibliothek zu verlassen — die Anforderung ist Genauigkeit, nicht Ergonomie, und Property-Tests laufen in beiden Implementierungen, um zu verifizieren, dass sie übereinstimmen.

Ein Regressionstest behauptet, dass das kanonische Wire-Format keine qub-Marken-Bytefolge über den Protokoll-primitiven qub_id-Feldschlüssel hinaus enthält. Das Wire-Format ist absichtlich markenagnostisch — jeder konforme Viewer (unser oder der eines Dritten) kann jeden qub aus dem dauerhaften Speicher rendern, unabhängig davon, welche Bereitstellung ihn versiegelt hat. Der Test ist ein Stolperdraht, der verhindert, dass eine zukünftige Änderung versehentlich eine Markenreferenz in Bytes einbäckt, die, sobald sie im dauerhaften Speicher sind, nicht umgeschrieben werden können.

3.4 Body-Hashing und Pre-Reveal-Integrität

Jede versiegelte Nutzlast trägt einen SHA3-256-Hash ihrer rohen Body-Bytes. Der Hash ist in die qub_id und, wenn die Urheberschaftssignatur aktiviert ist, in die V2-Signatureingabe gebunden. Ein Viewer berechnet ihn nach der Entschlüsselung neu und weist eine Abweichung zurück.

Die 32-Byte-Inhaltskennung qub_id wird aus einem 108-Byte-Preimage abgeleitet, das die Protokollversion, den Inhaltstyp, die Erstellungs- und Entsperrzeitstempel, den optionalen Ergebniszeitstempel (oder dessen Null-Sentinel), die Zielrunde von drand, den Body-Hash und SHA3-256 des optionalen NFC-normalisierten Titels umfasst. Ein Gateway oder CDN kann kein gebundenes Feld konsistent ändern und dennoch die erneute Ableitung bestehen. Titel sind auf 100 NFC-Codepunkte begrenzt und werden bei der gemeinsamen Klasse feindlicher/Steuer-Codepunkte abgewiesen (einschließlich Bidi-Overrides, Zero-Width-Zeichen, Tag-Block, BOM, C0, C1 und DEL).

3.5 Signatur (ML-DSA-65)

Die Urheberschaftssignatur verwendet ML-DSA-65 (FIPS 204), ein vom NIST standardisiertes post-quantum Signaturschema. Wir haben bewusst eine post-quantum Primitive für die Signatur gewählt, weil versiegelte Inhalte dauerhaft sind: Eine Signatur, die heute verifiziert, muss auch in Jahrzehnten noch verifizieren, einschließlich nach dem praktischen Aufkommen großmaßstäblicher Quantencomputer.

Signierschlüssel werden im Browser erzeugt. Das lokale Geheimnis wird vor der Speicherung in IndexedDB unter einem nicht extrahierbaren WebCrypto-Schlüssel verpackt. Wenn die kontoweite geräteübergreifende Wiederherstellungsfunktion verwendet wird, wird ein AEAD-verschlüsseltes portables Schlüsselblob serverseitig gespeichert; der Chiffretext des geheimen Schlüssels ist an die unveränderliche Konto-ID gebunden, und der Dienst validiert die öffentliche Hülle, kann das geheime Material aber nicht entschlüsseln. Rohe Bytes des privaten Schlüssels werden nicht an den Server gesendet. Öffentliche Schlüssel und Attestierungseinträge werden zur Verifikation und Identitätsanzeige gespeichert.

Dieselbe Im-Browser-tlock-Entschlüsselung gilt innerhalb des qub-Embeds: Wenn ein versiegelter qub durch <qub-embed> auf einer Drittanbieter-Seite gerendert wird, erfolgt die Entschlüsselung weiterhin im Embed-iframe im Browser des Empfängers. Der Embed ändert nicht das Vertrauensmodell — Klartext wird niemals auf einem qub-Server entschlüsselt.

3.6 Öffentliche Zuschreibung — Opt-In

Versiegelte qubs tragen keinen On-Chain-Verweis auf ihren Ersteller, es sei denn, der Ersteller wählt explizit, einen anzubringen. Wenn Sie einen qub versiegeln, sendet die Referenz-App ein Author-Speicher-Tag (einen 64-Zeichen-Hex-Fingerabdruck Ihres öffentlichen Signaturschlüssels) nur dann, wenn „Öffentliche Zuschreibung" im Datumsauswahlschritt aktiviert ist. Mit ausgeschaltetem Schalter — der Standardeinstellung — wird kein Author-Tag geschrieben, und der qub ist im dauerhaften Speicher nicht zugeschrieben: Nichts im Speicher verbindet den Upload mit Ihrem Handle, Ihrer E-Mail oder Ihren anderen qubs. Mit eingeschaltetem Schalter löst sich der Fingerabdruck über die Attestierungskette in §6.3 / §10 zu Ihrem @handle auf, und der Viewer-Countdown zeigt vor der Enthüllung „Versiegelt von @{handle}".

Dies ist ein bewusster Schutz gegen das Aufzählungsrisiko, das ein Always-on-Author-Tag erzeugen würde: Eine dritte Partei, die den Fingerabdruck eines Erstellers erfährt, könnte sonst den dauerhaften Speicher nach dem Tag durchsuchen und die vollständige historische Ausgabe dieses Erstellers rekonstruieren. Opt-in-Zuschreibung schließt diesen Kanal — nur qubs, die der Ersteller explizit zuschreibt, erscheinen unter einem Fingerabdruck im dauerhaften Speicher.

Die Profilseite /u/{handle} ist eine verifizierte Identitätskarte — Handle, optionaler Anzeigename + URL, „verifizierte E-Mail"-Abzeichen (keine Adresse) und die kryptografische Fingerabdruck-Kurzform. Sie listet die qubs eines Erstellers nicht auf. Besucher, die einen bestimmten qub von einem Ersteller sehen wollen, folgen direkt der Lieferungs-URL dieses qubs.

3.7 Äußerer Verschlüsselungs-Wrapper

Selbst nachdem die Timelock-Entschlüsselung mathematisch möglich ist—sobald die drand-Signatur für die gebundene Runde veröffentlicht wurde—würde die kanonische Timelock-Schicht allein es einem Indexierer ermöglichen, auffindbare qubs massenweise zu entschlüsseln. Die private Bereitstellung schließt diesen Kanal mit einer zusätzlichen symmetrischen Schicht um die timelock-verschlüsselten Bytes (Protokoll §13). Die öffentliche Bereitstellung lässt den Wrapper bewusst weg, damit Benachrichtigungs-, Embed- und Discovery-Links ohne geheimes Fragment funktionieren.

Der Wrapper verwendet AES-256-GCM, einen vom NIST standardisierten authentifizierten Cipher, mit einem frischen 256-Bit-Schlüssel K, der pro qub vom CSPRNG Ihres Browsers generiert wird. K ist als authentifizierte zusätzliche Daten an die qub_id des qubs gebunden, sodass ein Schlüssel von einem qub nicht zur Entschlüsselung eines anderen qubs wiederverwendet werden kann.

Im standardmäßigen privaten Browserfluss erreicht K niemals unsere Server. Er wird in das URL-Fragment des Teilen-Links kodiert (https://qub.social/c/<tx_id>#<base64url(K)>). Browser übertragen URL-Fragmente nicht an Server—RFC 3986 platziert das Fragment außerhalb der Anfrage—sodass qub.social, Speicher-Gateways, CDNs und Anfrageüberwachung in diesem Fluss für K blind sind. Der gespeicherte OuterWrapper ist erkennbar strukturiertes CBOR, doch sein authentifiziertes Ciphertext-Feld verbirgt die innere SealedQub-Struktur und lässt sich ohne K nicht öffnen.

Netto-Konsequenzen:

• qub.social kann standardmäßige private Browser-Versiegelungen nicht allein aus gespeicherten Daten entschlüsseln. Eine Kompromittierung des Datenspeichers erreicht ohne K undurchsichtigen Chiffretext. Öffentliche qubs und qubs mit aktivierter Wiederherstellung haben entwurfsbedingt eine andere Exposition.
• Ein Fragmentverlust ist ohne einen gewählten Wiederherstellungskanal nicht behebbar. Wenn Sie einen privaten Link ohne das Fragment speichern und die Wiederherstellung nicht aktiviert haben, wird der qub über diesen Link unlesbar. Der Versiegelungsfluss zeigt aus diesem Grund eine explizite „Speichern Sie diese URL"-Offenlegung.
• Opt-in-Wiederherstellung. Wenn Sie Ersteller-Lebenszyklus-E-Mails für einen qub aktivieren UND die E-Mail mit Ihrer verifizierten Identität übereinstimmt, akzeptieren wir K mit dem Upload, speichern die vollständige Lieferungs-URL im Versiegelungs-Verlauf-Eintrag Ihrer Identität und verwenden sie als Link in der Versiegelungsbestätigungs-E-Mail. Dieser Tausch — ein serverseitiger Wiederherstellungskanal im Tausch gegen einen Teil der Ende-zu-Ende-Reinheit — greift nur bei explizitem Opt-in und nur für diesen qub. Die Standardhaltung ist Krypto-Schreddern.

Der serverseitige /api/v1/seal-Endpunkt des Workers (verwendet von KI-Agenten und anderen API-Aufrufenden) verlangt vom Aufrufer, K mit einem CSPRNG zu erzeugen, ihn lokal aufzubewahren und ihn als wrapper_key_b64url bereitzustellen. Der Worker sieht auf diesem ausdrücklich vertrauenswürdigen Pfad zwangsläufig sowohl den Klartext als auch K im Speicher, persistiert aber keines von beiden. Ein obligatorischer Idempotency-Key verhindert, dass eine verlorene Antwort einen zweiten abgerechneten qub erzeugt, während der vom Aufrufer aufbewahrte K mit der wiederholten, fragmentlosen URL kombiniert werden kann. Dies unterscheidet sich vom standardmäßigen Browser-Pfad, bei dem K den Worker niemals erreicht, sofern die erstellende Person die Wiederherstellung nicht ausdrücklich aktiviert.

4. Transport und Edge

4.1 TLS

Browser-Verkehr zu qub wird am Cloudflare-Edge über HTTPS bereitgestellt. Antworten setzen HTTP Strict Transport Security (max-age=63072000; includeSubDomains; preload). Die genaue ausgehandelte TLS-Version und Cipher-Suite werden von der aktiven Edge-Konfiguration bestimmt und nicht vom Anwendungscode zugesichert. Wir legen keinen separat erreichbaren Origin-Server offen.

4.2 Inhaltssicherheit

Der kompilierte Client wird mit strengen Content-Type- und Cache-Headern bereitgestellt. Die SPA-Hülle ist eine einzelne Origin. Wir betten keine Drittanbieter-Skripte für Analyse oder Werbung ein. Die zwei Drittanbieter-Berührungspunkte im Produkt sind beide eng abgegrenzt: Der Kauffluss verlässt die SPA vollständig mit einer Vollseiten-Umleitung zum Stripe-gehosteten Checkout (https://checkout.stripe.com/…) — die UI von Stripe wird niemals in unserer Origin ausgeführt, und wir sehen niemals Kartendaten — und der Versiegelungsfluss lädt das Turnstile-Widget von Cloudflare, eine datenschutzfreundliche CAPTCHA-Alternative, die Cloudflare innerhalb seines eigenen sandboxierten iframes rendert. Keine der beiden Parteien kann den Rest der Seite lesen.

Der qub-Embed-iframe (bereitgestellt von qub.social/embed/{tx_id} und durch embed.js in Drittanbieter-Seiten geladen) trägt seine eigene Content-Security-Policy. Seine connect-src-Allowlist lautet 'self', https://qub.social, https://arweave.net, https://ar-io.dev, https://permagate.io, https://api.drand.sh und https://drand.cloudflare.com. Der iframe läuft mit sandbox="allow-scripts allow-top-navigation-by-user-activation" (nicht mit allow-same-origin): Die Host-Seite kann sein DOM nicht lesen, und er kann den Host nur nach einer Benutzeraktion navigieren.

4.3 CORS und Fetch-Bereich

Der Browser-Client führt Fetch-Anfragen nur an Folgendes aus:

• Unsere eigene API (api.qub.social und Staging-Äquivalente)
• Speicher-Gateways (read-only, zum Abruf gewrappter privater oder unverpackter öffentlicher Bytes — §3.6)
• drand-Beacon-Endpunkte (read-only, für Enthüllungszeit-Rundensignaturen)

Die Ziele des Embeds werden durch seine CSP erzwungen. Die vorgesehenen Ziele der Haupt-SPA sind in Code und Konfiguration festgelegt und werden durch Browser- und Integrationstests geprüft; Subresource Integrity ist keine Kontrolle für Netzwerkziele.

Der Embed ruft gespeicherte Bytes über die zugelassenen qub-/Speicher-Origins ab, entpackt private Nutzlasten im Browser mit K aus seinem URL-Fragment und ruft Enthüllungszeit-Rundensignaturen von den zwei zugelassenen drand-Origins ab. Die Haupt-SPA verwendet den Vier-Endpunkte-Fallbacksatz in config/drand-endpoints.json (drand.cloudflare.com, api.drand.sh, api2.drand.sh und api3.drand.sh), sodass der Ausfall eines Endpunkts die Enthüllung nicht blockiert. Die Embed-CSP verweigert Verbindungen außerhalb ihrer ausdrücklichen Liste.

5. Serverseitige Infrastruktur

5.1 Serverless Edge

Unsere API läuft vollständig auf einer verwalteten Serverless-Laufzeit am Edge. Es gibt keine VMs, keine Container und keine persistenten Server-Prozesse, die wir verwalten. Das reduziert die Angriffsfläche, für die wir verantwortlich sind, dramatisch: Wir betreiben kein Betriebssystem, keinen Webserver oder eine Anwendungs-Laufzeit, die wir patchen müssen.

Eine separate Public-CORS-Middleware wird angewendet Access-Control-Allow-Origin: * zu dem folgenden implementierten Pfadset: /embed.js, /embed/v1.js, alles darunter /embed/; /api/v1/telemetry; /api/v1/openapi.json; alles darunter /api/v1/qub/ (einschließlich Bytes, Metadaten, Beweis, Engagement, Benachrichtigung und Push-Unterrouten); alles unter /api/v1/log/; öffentliche Behandlung von Nachschlagen unter /api/v1/handle/; und öffentlicher Avatar liest darunter /api/v1/identity/avatar/. Seine Startgenehmigungen GET, POST, und OPTIONS mit dem Content-Type Anforderungs-Header. Diese prefix-basierte Oberfläche ist weiter gefasst als nur die Aufrufe, die das Embed derzeit tätigt, sodass jeder Handler unterhalb dieser Präfixe weiterhin seine eigene Validierung, Authentifizierung, Ratenbegrenzungen und Missbrauchskontrollen durchsetzen muss. Andere API-Pfade behalten die qub.social-eingeschränkte CORS-Richtlinie bei.

5.2 Speicherung

• Metadaten- und Koordinationsspeicher enthalten Identitäts- und Attestierungseinträge, Berechtigungen und Abrechnungsreferenzen, API-Schlüsseleinträge, Sperrlisteneinträge, Sitzungen, Idempotenzstatus, Warteschlangen sowie Ratenbegrenzungs- und Parallelitätsstatus. Für unterschiedliche Konsistenzanforderungen werden KV, D1 und Durable Objects verwendet, statt eines einzigen universellen Speichers.
• Unser Object Store ist ebenfalls eine Dauerhaftigkeitsschicht. Er enthält die exakten verpackten oder unverpackten qub-Bytes, deren Upload bestätigt wurde, Transparenz-Log-Blätter und koordinatenindizierte Merkle-Knoten, Ankermaterial, strukturierte Ereignisprotokolle sowie Antwort- und Metadaten-Caches.
• Dauerhafter öffentlicher Speicher enthält Transparenz-Log-Anker und, für den T3-Pfad oder eine aufgeschobene Veröffentlichung, einzelne qub-Transaktionen. Wir betreiben dieses Netzwerk nicht. Private Browser-Nutzlasten bleiben dort undurchsichtig, sofern die besitzende Person nicht auch K hat; öffentliche/unverpackte Nutzlasten besitzen diese zusätzliche schlüsselbasierte Zugriffsschicht bewusst nicht.

Der standardmäßige Nachrichtenfluss im Browser persistiert keinen Klartext auf der qub-Infrastruktur. Builder /api/v1/seal verarbeitet Klartext und K im Arbeitsspeicher, persistiert aber keines von beiden. Bei der Pakt-Vorbereitung wird der signierte strukturierte Pakt zwangsläufig gespeichert, bis er mitunterzeichnet oder zurückgezogen wird oder abläuft. Die optionale Wiederherstellung speichert eine Lieferberechtigung (den vollständigen fragmenttragenden Link), damit sie später wiederhergestellt werden kann. Daher bezeichnen wir die gesamte Speicherebene nicht als „nur Metadaten".

5.3 Geheimnisse

Geheimnisse (Signatur-Wallets, Anbieter-Tokens und HMAC-Schlüssel) werden über Secret-/Umgebungs-Bindings der Plattform statt über die Quellcodeverwaltung bereitgestellt. Laufzeitkomponenten erhalten nur die Bindings, die sie benötigen. Rotations- und Überlappungsverfahren sind komponentenspezifisch; wir behaupten keinen einzigen universellen automatischen oder auditierten Rotationsmechanismus.

5.4 Logging und Telemetrie

Strukturierte JSON-Logs werden bei jeder API-Anfrage geschrieben, wobei eine Korrelations-ID im X-Request-Id-Antwort-Header sichtbar ist. Die Client-Telemetrie ist anonym — keine Gerätekennung, keine IP-Adresse, keine Inhaltsvorschau. Ereignisse werden im Speicher gepuffert und auf Best-Effort-Basis ausgespült; ein fehlgeschlagenes Ausspülen wird verworfen, nicht wiederholt. Telemetrie ist so konzipiert, dass sie auf der Netzwerkschicht deaktivierbar ist, ohne das Produkt zu beeinträchtigen.

6. Authentifizierung

6.1 Magic-Link-Anmeldung

Die Anmeldung verwendet ein einmaliges, HMAC-signiertes Token, das an Ihren E-Mail-Posteingang geliefert wird. Der Link ist 15 Minuten lang gültig, und seine Einlösung wird atomar beansprucht, sodass eine gleichzeitige oder wiederholte Verwendung geschlossen fehlschlägt. Bei Erfolg erhält der Browser ein undurchsichtiges __Host-qub_session-Cookie mit den Attributen Secure, HttpOnly, SameSite=Strict und Path=/.

Sitzungen haben ein Inaktivitätslimit von 30 Tagen und ein absolutes Limit von 90 Tagen, rotieren nach 24 Stunden und akzeptieren nur die unmittelbar vorherige Generation während einer 120-sekündigen Schonfrist für verlorene Antworten. Sensible Kontoänderungen erfordern eine Authentifizierung innerhalb der letzten 10 Minuten. Das HMAC-Signiergeheimnis ist ein Plattform-Binding; ein reiner Lesezugriff auf Metadaten reicht allein nicht aus, um ein gültiges Token zu erstellen.

6.2 API-Schlüssel (Developer-Tier)

Developer-API-Schlüssel verwenden das Präfix qub_sk_ zur einfachen Erkennung und Greppbarkeit. Jeder Schlüssel:

• Ist an ein Konto, Berechtigungsbereiche und eine optionale IP-CIDR-Allowlist gebunden
• Wird einmal im Rohformat angezeigt; dauerhaft gespeicherte Einträge enthalten seinen SHA-256-Hash, nicht das Bearer-Geheimnis
• Kann mit einer einstündigen Übergangszuordnung rotiert werden, in der der alte Schlüssel auf den Ersatzschlüssel verweist
• Hat einen unabhängigen Kontingent- und Ratenbegrenzungsstatus
• Wird niemals in vollem Umfang protokolliert; Logs zeichnen nur die Schlüsselkennung auf

Admin-Schlüsselverwaltungs-Endpunkte sind hinter einer separaten Admin-Anmeldung verschlossen.

6.3 E-Mail-Attestierung (Urheberschaftssignatur)

Die Bindung einer E-Mail-Adresse an einen Signaturschlüssel erfordert:

1. Besitz des privaten Signaturschlüssels (Sie signieren eine Herausforderung)
2. Besitz des E-Mail-Posteingangs (Sie geben einen 6-stelligen Code ein, der per E-Mail geliefert wird)

Eines allein ist unzureichend. Der Widerruf ist ein signierter Eintrag auf Ihrem eigenen Konto und tritt sofort in Kraft; Empfänger, die die Attestierung abrufen, sehen den widerrufenen Zustand und zeigen entsprechend an.

7. Zahlungen

Karteneingabe und -verarbeitung erfolgen im von Stripe gehosteten Checkout. Wir erhalten niemals Kartennummern, Ablaufdaten oder CVCs. Wir speichern Stripe-Kunden- und Abonnementkennungen, Abonnementstatus und Periodendaten in Berechtigungs-/API-Schlüsseleinträgen, damit Zugriff, Verlängerungen, Verbrauchserfassung, Kündigungen und Rückerstattungen abgeglichen werden können. Die Datenschutz- und Sicherheitserklärungen von Stripe regeln den Umgang mit Zahlungsdaten.

Der Versiegelungsendpunkt vergleicht den Berechtigungseintrag mit der Gerätekennung und, für angemeldete Nutzer, mit der verknüpften Identität. Eine Berechtigung kann nicht über Geräte hinweg wiederverwendet werden, ohne dass der Nutzer sie explizit über die Magic-Link-Anmeldung wiederherstellt.

8. Missbrauchsresistenz

8.1 Bot-Erkennung

Der Versiegelungsfluss wird von einer datenschutzfreundlichen CAPTCHA-Alternative gesteuert, die keine Cookies zum Tracking verwendet und kein Fingerprinting zu Werbezwecken durchführt. Eine fehlgeschlagene Herausforderung wird von unserem Edge-Worker abgewiesen, bevor irgendeine versiegelungsseitige Verarbeitung erfolgt.

8.2 Ratenbegrenzung

Ratenbegrenzungen werden auf mehreren Schichten erzwungen:

• Pro-IP- und Pro-Schlüssel-Begrenzungen auf Versiegelungs-, Lese- und Auth-Endpunkten
• Pro-E-Mail-Begrenzungen auf Magic-Link-Anfragen (verhindert Posteingangs-Flutung)
• Pro-Gegenpartei-Begrenzungen auf Pakt-Einladungs-E-Mails (zehn pro Empfängeradresse pro UTC-Tag, die primäre Spam-Relay-Minderung; ehrliche Pakte nähern sich der Obergrenze fast nie)
• Pro-IP-Begrenzungen auf Telemetrie-Einreichung

Zähler und atomare Beanspruchungen sind entsprechend den Konsistenzanforderungen des Endpunkts auf KV, Durable Objects und Ratenbegrenzungs-Bindings der Plattform verteilt. Ratenbegrenzte Anfragen erhalten 429; Endpunkte, die ein Wiederholungsfenster berechnen können, geben Retry-After an.

8.3 Inhalts-Moderation

Die Standard-Route für den Browser-Upload kann den Inhalt nicht scannen: sie empfängt nur das vom Client versiegelte Artefakt. Der Builder /api/v1/seal Die Route sieht den Klartext vorübergehend, und die Pakt-Staging hält strukturierte Bedingungen bis zur Fertigstellung, aber diese Vertrauens-Ausnahmen machen den allgemein byte-blinden Upload-Pfad nicht zu einem Inhaltsscanner. Operative Moderation ist eine Ablehnungsliste Auf der Betrachter-Ebene: Ein auf der Sperrliste stehender Qub wird von unserem Betrachter abgelehnt, unabhängig davon, ob die gespeicherte Nutzlast weiterhin erreichbar ist. Die Sperrliste zieht keine dauerhaften Bytes, Einträge im Transparenzprotokoll oder bereits veröffentlichte permanente Netzwerkinformationen zurück.

Missbrauchsmeldungen werden mit einem Einweg-Hash der IP des Meldenden ratenbegrenzt; wir speichern IPs zu diesem Zweck nicht im Klartext.

9. Lieferkette und Build-Integrität

9.1 Toolchain-Pinning

Compiler- und Laufzeitversionen werden in der Repository-Konfiguration festgeschrieben, und Abhängigkeiten werden über eingecheckte Lockfiles aufgelöst. Die CI prüft die Aktualität generierter Dateien und reproduzierbarkeitssensible Invarianten. Wir stellen nicht die weitergehende Behauptung auf, dass jeder saubere Build auf allen unterstützten Rechnern bitgenau identisch ist.

9.2 Lints und statische Analyse

Der Workspace aktiviert unsere strengsten Lint-Gruppen auf der deny-Ebene. Die CI behandelt jede Warnung — einschließlich Dokumentations-Link-Warnungen — als Build-Fehler. Das ist beabsichtigt: Wir verwenden die Lint-Strenge als Stolperdraht für subtile Regressionen.

9.3 CI-Gates

Der CI-Workflow umfasst Formatierung und strenge Lints; Rust-, WASM-/Browser-, Worker-, Embed- und API-Tests; Typprüfung; Code-Coverage; Mutations-/Invariantenprüfungen; statische Analyse von Abhängigkeiten und Workflows; Prüfungen von i18n-Schlüsseln, Abdeckung, Drift und feindlichen Codepoints; die Aktualität generierter Dokumentation, API und Wissensbasis; Dokumentinventar und interne Links; Stylesheet- und Bundle-Budgets sowie OpenAPI-Validierung. Einige aufwendige Mutation-Jobs werden planmäßig statt bei jedem Push ausgeführt.

Ein einziges erforderliches ci-Roll-up bleibt rot, wenn ein erforderlicher Job fehlschlägt. Workflows für geschützte Branches und Deployments verwenden dieses Ergebnis, statt ein kleineres Sicherheits-Gate zu duplizieren.

9.4 Mutation-Testing

Ein wöchentlicher Job führt Mutation-Testing gegen die sicherheitskritischen reinen Module aus: Hashing, kanonisches CBOR, Versiegelung, Entsperrung, die Wire-Format-Newtypes, die Protokoll-Typvalidierer und der Handle-Namespace. Mutation-Testing beantwortet „Fängt unsere Test-Suite subtil falschen Code?" — wenn eine mutierte Implementierung weiterhin alle Tests besteht, wissen wir, dass wir eine Test-Coverage-Lücke haben und beheben sie.

9.5 Git-Hooks

Lokale Hooks (pre-commit, pre-push) spiegeln die CI-Gates wider, sodass Regressionen erkannt werden, bevor sie den Rechner des Entwicklers verlassen. Hooks werden über ein Repo-Skript installiert; sie werden in unserem Workflow nicht umgangen, und die CI ist das maßgebliche Gate, falls sie übersprungen werden.

10. Tests

Sicherheitskritischer Code trägt drei Arten von Tests:

• Unit-Tests verifizieren das erwartete Verhalten auf bekannten Eingaben, einschließlich Testvektoren, die aus der Protokollspezifikation abgeleitet sind.
• Property-Tests generieren Tausende beliebiger Eingaben und behaupten Invarianten: kanonische CBOR-Round-Trips, Signaturverifikations-Round-Trips, E-Mail-Bindungs-Prädikate, Pakt-Bestätigungs-Determinismus.
• Cross-Implementierungs-Tests verifizieren, dass unsere Client- und Server-Implementierungen Byte für Byte über kanonische Kodierungen übereinstimmen. Das fängt Divergenz zwischen den beiden Implementierungen ab, bevor sie in die Produktion gelangt.

11. Branch- und Release-Hygiene

Feature-Branches gelangen nur über einen Gate-1-Pull-Request in staging: Das erforderliche ci muss grün sein, es darf keine ungelöste Änderungsanforderung und keinen Merge-Konflikt geben, und der geprüfte Arbeitsbaum muss sauber sein; der Merge erfolgt per Squash, danach wird der Branch gelöscht. main wird nur über den Gate-2-Pull-Request staging → main weitergeführt und bewahrt die Abstammung mit einem Merge-Commit. Direkte Branch-Pushes gehören nicht zum Release-Workflow.

Staging- und Produktions-Deployments werden nach der CI aus den entsprechenden geschützten Branch-Zuständen staging und main ausgelöst. Pull-Request-Code und Fork-Zugangsdaten erhalten keine Deployment-Geheimnisse.

Geheimnisse, die in Deploy-Workflows verwendet werden, sind durch unsere CI-Plattform auf die Deploy-Umgebung beschränkt. Sie sind für Pull-Request-Workflows aus Forks nicht verfügbar.

12. Koordinierte Offenlegung

Wenn Sie glauben, eine Sicherheitslücke in qub gefunden zu haben, wollen wir schnell davon hören und verpflichten uns, die Meldung professionell zu behandeln.

• Senden Sie eine E-Mail an support@qub.social mit dem Betreffpräfix [SECURITY].
• Beschreiben Sie die Schwachstelle, Schritte zur Reproduktion und einen etwaigen Proof-of-Concept.
• Geben Sie uns ein angemessenes Offenlegungsfenster (typischerweise 90 Tage), bevor Sie an die Öffentlichkeit gehen.
• Greifen Sie nicht auf Daten zu, die Ihnen nicht gehören, beeinträchtigen Sie nicht den Dienst für andere Nutzer und bewahren Sie während der Forschung erlangte Daten nicht über das hinaus auf, was zur Demonstration des Problems notwendig ist.

Wir bestätigen den Eingang innerhalb von drei Geschäftstagen und halten Sie informiert, während wir untersuchen. Mit Ihrer Zustimmung erwähnen wir Meldende in den Release Notes.

12.1 Safe Harbor

Wenn Ihre Forschung den obigen Regeln folgt (Untersuchung in gutem Glauben, kein Schaden für andere Nutzer oder den Dienst, angemessenes Offenlegungsfenster), werden wir keine rechtlichen Schritte gegen Sie einleiten, und wir werden auch nicht die Strafverfolgungsbehörden bitten, dies zu tun. Wir behandeln Ihre Arbeit als autorisierte Tests und es ist uns lieber, Sie finden den Bug als jemand anderes.

Diese Safe Harbor gilt für:

• Forschung am Live-Dienst qub.social (nicht an Test-Fixtures, die wir zu diesem Zweck veröffentlichen).
• Reverse-Engineering unserer veröffentlichten Binaries und der Open-Source-Crates qub-core / qub-app.
• Jede Schwachstellenklasse — Protokoll, Anwendung, Infrastruktur, Lieferkette — die qub betrifft.

Sie gilt nicht für Social Engineering von qub-Teammitgliedern, Denial-of-Service-Tests oder den Zugriff auf Daten anderer Nutzer über das hinaus, was zur Demonstration des Problems notwendig ist. Wenn Sie unsicher sind, ob etwas innerhalb der Safe Harbor liegt, fragen Sie zuerst mit demselben [SECURITY]-Betreffpräfix.

13. Ehrliche Begrenzungen

Sicherheit ist eine Praxis, kein Zustand. Einige Begrenzungen sind es wert, direkt benannt zu werden:

• Wir sind ein kleines Team. Unsere Prüftiefe entspricht nicht der einer dedizierten Anwendungssicherheitsfunktion eines großen Konzerns. Wir kompensieren mit strengen automatisierten Gates und einer minimalen Angriffsfläche, beanspruchen aber keine Unfehlbarkeit.
• Die Dauerhaftigkeit unseres Speicher-Backends ist eine Einbahnstraße. Wenn ein Fehler dazu führt, dass versiegelte Inhalte früher als beabsichtigt entschlüsselbar werden, können wir das nicht rückgängig machen. Wir behandeln den Versiegelungsfluss mit entsprechender Sorgfalt.
• Das drand-Netzwerk ist eine externe Abhängigkeit. Ein katastrophales Versagen von drand würde das Enthüllungsverhalten jedes qubs beeinflussen. Wir überwachen die Gesundheit von drand und haben Kontingentdokumentation für die Ketten-Migration, falls erforderlich. Für Freischaltdaten, die mehr als 2 Jahre in der Zukunft liegen, zeigt der Bestätigungsdialog zum Versiegelungszeitpunkt eine explizite Offenlegung: Langhorizont-qubs hängen von der drand-Ketten-Dauerhaftigkeit ab, und eine zukünftige drand-Ketten-Migration kann Wiederherstellungsschritte zur Entsperrung des qubs erfordern. Für Freischaltdaten, die mehr als 5 Jahre in der Zukunft liegen, müssen Sie ein zusätzliches Kästchen ankreuzen, das bestätigt, dass Sie dieses Risiko gelesen und akzeptiert haben, bevor die Versiegelung fortschreitet.
• Kryptografische Primitiven, auf die wir uns verlassen, sind standardisiert und weit überprüft, aber Kryptografie entwickelt sich. Wo wir Wahlmöglichkeiten haben (post-quantum Signatur, authentifizierte Verschlüsselung), wählen wir die konservativere Option.

14. Änderungen dieser Seite

Wesentliche Änderungen werden durch Aktualisierung des Inkrafttretensdatums oben vermerkt. Wo eine Änderung eine konkrete Sicherheitsverbesserung widerspiegelt, beschreiben wir sie kurz im öffentlichen Changelog. Wo eine Änderung eine Richtlinienklarstellung widerspiegelt, beschreiben wir, was sich geändert hat und warum.

Bei Fragen zu allem auf dieser Seite schreiben Sie eine E-Mail an support@qub.social mit dem Betreffpräfix [SECURITY].

15. Änderungsprotokoll