Sicherheit & Bug-Bounty-Programm

So werden Ihre Daten geschützt – einfach erklärt

Die Kopplung beginnt mit einem QR-Code auf Ihrem PC. Er enthält ein Einmalgeheimnis, das nach zwei Minuten abläuft; nur ein Gerät, das Ihren Bildschirm tatsächlich gesehen hat, kann sich also koppeln. Danach zeigen beide Bildschirme denselben 6-stelligen Code, und Sie bestätigen, dass er übereinstimmt.

• Jede Verbindung ist mit dem Noise-Protokoll (X25519, ChaCha20-Poly1305, BLAKE2s) Ende-zu-Ende-verschlüsselt. Jedes Gerät hat einen eigenen Schlüssel, der es nie verlässt, und Geräte erkennen einander an diesem Schlüssel – nicht an IP-Adresse, Name oder Konto.
• Jede Verbindung und jeder Datenstrom verwendet neue Schlüssel (Forward Secrecy): Ein später gestohlener Schlüssel kann zuvor aufgezeichneten Datenverkehr nicht entschlüsseln.
• Die Verschlüsselung liegt oberhalb des Netzwerks und schützt Sie daher gleich gut im WLAN, über das Internet (QUIC, TCP oder WebRTC) und über unseren Rendezvous-Dienst, der nur versiegelte Nachrichten weiterleitet, die er nicht lesen kann.
• Gekoppelt heißt nicht, dass alles erlaubt ist: Jedes Gerät erhält nur die Berechtigungen, die Sie erteilen, und Ferneingabe sowie Kamera fragen in jeder Sitzung nach Ihrer Zustimmung.
• Empfangene Dateien, Links und Zwischenablage-Inhalte werden vor der Verwendung geprüft: Sie können den Download-Ordner nicht verlassen, gefährliche Link-Typen werden abgelehnt und Größen sind begrenzt.

Die vollständige technische Spezifikation und das Bedrohungsmodell stehen in unserer Sicherheitsdokumentation, die wir Forschenden und Prüfern zur Verfügung stellen.

Audit-Status

Wir sind lieber genau als beeindruckend:

• Interne Sicherheitsprüfung: abgeschlossen. Design, Kopplung, Sitzungsverschlüsselung, Berechtigungen und Eingabeprüfung wurden anhand eines schriftlichen Bedrohungsmodells geprüft, und die Sicherheitsregeln sind durch automatisierte Tests abgedeckt, die bei jeder Änderung laufen.
• Automatisierte Prüfungen: Sicherheitsmeldungen und Lizenzen der Abhängigkeiten werden bei jeder Änderung geprüft, und die Teile, die nicht vertrauenswürdige Eingaben lesen, werden wöchentlich gefuzzt.
• Externes Audit: vor Version 1.0 geplant und noch nicht erfolgt. Sobald es abgeschlossen ist, veröffentlichen wir hier den Prüfer, den Umfang und eine Zusammenfassung der Ergebnisse.

Bis dahin ist Personal Device Bridge eine Vorschauversion. Bitte berücksichtigen Sie das, bevor Sie es für hochsensible Daten einsetzen.

Überprüfen, was Sie herunterladen

Sie müssen uns nicht einfach glauben, dass ein Download echt ist:

• Prüfsummen: Jede Version enthält eine Datei SHA256SUMS, die alle ihre Dateien abdeckt; so können Sie bestätigen, dass Ihre Kopie genau der veröffentlichten entspricht.
• Reproduzierbare Builds: Das Linux-Kommandozeilenwerkzeug wird deterministisch gebaut. Wer den Quellcode zum Release-Tag hat, kann es neu bauen und erhält eine bitgenau identische Datei; eine automatische Prüfung baut es zweimal in unterschiedlichen Umgebungen und schlägt fehl, wenn sich auch nur ein Byte unterscheidet.
• Build-Herkunftsnachweis: Unser Release-Workflow ist darauf vorbereitet, jeder Datei eine signierte SLSA-Provenance-Attestierung (Sigstore) beizufügen, die festhält, welcher Workflow und welcher Commit sie erzeugt haben; prüfen können Sie sie mit dem Befehl „gh attestation verify“. GitHub aktiviert dies, sobald das Quellcode-Repository öffentlich ist; wir geben hier Bescheid, wenn es so weit ist.
• Codesignatur: Unsere Release-Pipeline signiert Windows-Programme und -Installer mit Authenticode (Azure Artifact Signing); vor dem Ausführen können Sie den Herausgeber unter Eigenschaften → Digitale Signaturen prüfen.

Windows- und Android-Builds sind noch nicht reproduzierbar; diese Arbeit ist geplant. Schritt-für-Schritt-Anleitungen zur Überprüfung mit bash und PowerShell stehen in unserem Leitfaden zu reproduzierbaren Builds, den wir auf Anfrage bereitstellen.

Kontinuierliche Tests

Jeder Decoder, der Daten von einem anderen Gerät oder aus dem Netzwerk liest – Nachrichtenumschläge, Kopplungslinks, Discovery-Beacons, Dateinamen und die Nachrichten der einzelnen Funktionen –, wird wöchentlich mit libFuzzer gefuzzt, der ihm Millionen fehlerhafter Eingaben zuführt, um Abstürze und lückenhafte Sicherheitsprüfungen zu finden.

Zusätzlich laufen bei jeder Änderung Unit-, Integrations- und End-to-End-Tests unter Windows und Linux, darunter Tests, bei denen sich zwei echte Prozesse über das Netzwerk koppeln und Dateien übertragen.

Was zum Umfang gehört

Bitte melden Sie alles, was die Sicherheit oder Privatsphäre unserer Nutzer gefährden könnte, in:

• Der Kern-Engine: Geräteidentität und Schlüsselspeicher, QR-Kopplung, verschlüsselte Sitzungen, Übertragungsprotokoll, Transporte (QUIC, TCP, WebRTC), Geräteerkennung, Vertrauen und Berechtigungen sowie allen Funktionen (Dateiübertragung, Zwischenablage, Links, Continue, MyDrop, SmartPrint, Dateibrowser, Benachrichtigungen, Ferneingabe, Kamera).
• Den Apps: dem Kommandozeilenwerkzeug pdb, der Windows-Desktop-App und ihren Installern sowie der Android-App.
• Dem Rendezvous-Dienst, den wir für Verbindungen über das Internet betreiben.
• Dieser Website, personaldevicebridge.com.
• Unserem Release-Prozess: Build- und Release-Workflows, Codesignatur, Prüfsummen und Herkunftsnachweise.

Besonders interessieren uns: Kopplung, ohne den QR-Code gesehen zu haben, das Brechen der Verschlüsselung oder der Geräteauthentifizierung, ein gekoppeltes Gerät, das mehr tut als erlaubt, das Lesen oder Schreiben von Dateien außerhalb des vorgesehenen Ordners, Codeausführung über empfangene Daten und ein Rendezvous-Dienst, der Nachrichteninhalte erfährt oder verändert.

Was nicht zum Umfang gehört

• Denial of Service durch reines Datenvolumen, Lasttests gegen unsere gehosteten Dienste und Spam.
• Social Engineering oder Phishing gegen unser Team oder unsere Nutzer sowie physische Angriffe.
• Angriffe, die ein bereits kompromittiertes Gerät oder Benutzerkonto (etwa Schadsoftware, die als der Benutzer läuft), ein gerootetes oder gejailbreaktes Telefon oder physischen Zugriff auf ein entsperrtes Gerät voraussetzen.
• Informationen, die im lokalen Netzwerk konstruktionsbedingt sichtbar sind, etwa die Anwesenheit eines Geräts oder das Datenvolumen.
• Einschränkungen, die in unserer Sicherheitsdokumentation bereits beschrieben sind, es sei denn, Sie weisen schwerwiegendere Auswirkungen nach.
• Fehler in Plattformen Dritter selbst (Cloudflare, Railway, GitHub, Google) – bitte melden Sie diese dem jeweiligen Anbieter. Wie wir diese Plattformen nutzen, gehört dagegen zum Umfang.
• Meldungen ohne nachgewiesene Sicherheitsauswirkung: fehlende Header auf statischen Seiten, SPF/DMARC-Einstellungen für E-Mail, Self-XSS, Versionsnummern oder Scanner-Ausgaben ohne Proof of Concept.

So melden Sie eine Schwachstelle

Schreiben Sie an [email protected] mit dem Betreff „[SECURITY] kurzer Titel“, auf Koreanisch oder Englisch. Bitte geben Sie an:

• die betroffene App oder Komponente und ihre Version;
• worin das Problem besteht und was ein Angreifer damit tun könnte (ein CVSS-Vektor ist willkommen);
• Schritte zur Reproduktion oder einen Proof of Concept sowie die Plattform, auf der Sie getestet haben;
• ob und wie Sie genannt werden möchten.

Bitte melden Sie Schwachstellen nicht über öffentliche Issues oder soziale Medien.

Verschlüsselung: Wir haben noch keinen PGP-Schlüssel veröffentlicht. Sobald es so weit ist, liegt er im Ordner /.well-known/ dieser Website und wird in personaldevicebridge.com/.well-known/security.txt aufgeführt. Bis dahin gilt: Enthält Ihre Meldung sensible Exploit-Details, senden Sie zuerst eine kurze Nachricht ohne diese, und wir vereinbaren mit Ihnen einen sicheren Kanal.

Unser Quellcode ist proprietär. Wenn Sie für Ihre Forschung oder zur Bestätigung eines Fundes Zugriff darauf benötigen, fragen Sie uns; wir prüfen jede Anfrage einzeln.

Was nach Ihrer Meldung geschieht

• Wir bestätigen den Eingang Ihrer Meldung innerhalb von 72 Stunden.
• Innerhalb von 7 Tagen bewerten wir sie – Gültigkeit, Schweregrad und betroffene Versionen – und informieren Sie mindestens alle 14 Tage, bis sie gelöst ist.
• Behebungsziele ab der Bewertung: Kritisch innerhalb von 30 Tagen (wenn möglich mit einer Abhilfe innerhalb von 7 Tagen), Hoch innerhalb von 60 Tagen, Mittel innerhalb von 90 Tagen, Niedrig in einer späteren planmäßigen Version.

Wir sind ein kleines Team. Wenn wir ein Ziel nicht einhalten können, sagen wir Ihnen, warum und wann Sie mit der Behebung rechnen können.

Prämien

Prämien liegen in unserem Ermessen. Sie hängen von der Auswirkung, der Qualität der Meldung und davon ab, ob uns das Problem neu ist; berechtigt ist, wer ein Problem als Erstes meldet. Den Schweregrad bewerten wir mit CVSS (v3.1 oder v4.0) anhand der neuesten Version und erläutern Ihnen unsere Bewertung.

Duplikate, Probleme außerhalb des Umfangs und Meldungen, die gegen diese Richtlinie verstoßen, werden nicht prämiert. Mehrere verkettete Probleme gelten als ein Fund mit dem resultierenden Schweregrad.

Prämien werden in koreanischen Won ausgezahlt; Dollarbeträge sind Näherungswerte. Die Auszahlung erfordert die Angaben, die das koreanische Steuerrecht und unsere Bank verlangen, und ist nicht möglich, wo Gesetze oder Sanktionen sie verbieten. Sie können uns auch bitten, Ihre Prämie an eine gemeinnützige Organisation zu spenden.

Safe Harbour

Wenn Sie sich in gutem Glauben bemühen, diese Richtlinie einzuhalten, betrachten wir Ihre Forschung als autorisiert. Wir werden deswegen keine rechtlichen Schritte gegen Sie einleiten oder unterstützen und Sie nicht bei Strafverfolgungsbehörden anzeigen. Geht ein Dritter wegen Forschung gegen Sie vor, die dieser Richtlinie folgte, machen wir deutlich, dass Sie mit unserer Autorisierung gehandelt haben.

In gutem Glauben zu handeln bedeutet, dass Sie:

• nur Ihre eigenen Geräte, Installationen, Kopplungen und Rendezvous-Postfächer testen;
• nicht auf Daten anderer zugreifen, sie nicht verändern und nicht behalten – wenn Sie auf solche stoßen, hören Sie auf, informieren uns und löschen sie;
• unsere Dienste nicht stören und keine dauerhaften Änderungen hinterlassen;
• uns Zeit geben, das Problem vor einer Veröffentlichung zu beheben;
• niemals Geld dafür verlangen, etwas nicht zu veröffentlichen.

Tests an Systemen, die uns nicht gehören, können wir nicht autorisieren. Fragen Sie im Zweifel vorher nach.

Koordinierte Offenlegung

Bitte geben Sie uns ab Ihrer Meldung 90 Tage Zeit – oder bis eine Korrektur veröffentlicht ist, falls das früher geschieht –, bevor Sie Details veröffentlichen. Bei einer aufwendigen Korrektur bitten wir eventuell um eine kurze Verlängerung und stimmen den Termin mit Ihnen ab.

Nach der Korrektur veröffentlichen wir einen Sicherheitshinweis in den Versionshinweisen und nennen Sie, sofern Sie nicht anonym bleiben möchten. Wird ein Problem aktiv ausgenutzt, können wir es gemeinsam mit Ihnen früher offenlegen.

Kontaktdaten für Werkzeuge

Unsere Kontaktdaten sind außerdem im maschinenlesbaren Standardformat (RFC 9116) unter personaldevicebridge.com/.well-known/security.txt veröffentlicht, das auf diese Seite verweist. Wir antworten auf Koreanisch oder Englisch.

Hall of Fame

Danke an alle, die helfen, unsere Nutzer zu schützen. Forschende, die gültige Probleme melden, werden hier mit ihrer Zustimmung aufgeführt.

Bisher wurde noch niemand genannt – Ihre Meldung könnte die erste sein.