Peer-to-Peer statt Server-Relay
Video, Audio und Chat fließen per WebRTC direkt zwischen den Teilnehmern. Der Server vermittelt nur die technischen Verbindungsdaten (Signaling) und leitet keine Medien weiter.
Technik im Detail
Wie EUDI Verified Call funktioniert
Vertrauen entsteht durch Architektur, nicht durch Versprechen. Diese Seite erklärt für technisch interessierte Nutzer, wie Identitätsnachweis, Verschlüsselung, Datenschutz und Betrieb zusammenspielen — inklusive der bewussten Grenzen.
Verbindung & Verschlüsselung
Der Anruf läuft direkt zwischen den Browsern. Der Server hilft nur beim Verbindungsaufbau — die Inhalte sieht er nie.
Ende-zu-Ende verschlüsselt
Jede Verbindung ist mit DTLS-SRTP verschlüsselt — den Standard-Verfahren von WebRTC. Die Schlüssel werden direkt zwischen den Browsern ausgehandelt; der Server kennt sie nicht.
Anschaulich erklärt
Stellt euch vor, ihr wollt gemeinsam einen Tresor bauen, ohne dass jemand am Telefon den Code mithören kann: Jeder bringt eine öffentlich sichtbare Hälfte eines mathematischen Schlosses mit. Kombiniert man beide Hälften, entsteht ein gemeinsames Geheimnis — aber nur für die beiden, die je ihre eigene Hälfte kennen. Genau so handeln eure Browser den Sitzungsschlüssel aus, mit dem die Verbindung verschlüsselt wird.
Verbindungsaufbau über STUN/TURN
Um durch Router und Firewalls zu finden, nutzt WebRTC STUN- und (bei restriktiven Netzen) TURN-Relays. Ein TURN-Relay leitet nur die verschlüsselten Pakete weiter und kann sie nicht entschlüsseln.
Strenge Firmen- und Behördennetze sperren oft alles außer Web-Verkehr. Für diesen Fall ist das Relay zusätzlich über Port 443 erreichbar — denselben Port, über den auch Webseiten geladen werden. So kommt ein Anruf auch dort zustande, wo die üblichen Wege verschlossen sind.
Prüfung, bevor es losgeht
Beim Öffnen der Seite prüft der Browser im Hintergrund, ob das eigene Netz einen Anruf überhaupt zulässt. Das dauert den Bruchteil einer Sekunde und meldet sich nur, wenn etwas im Weg steht — dann aber, bevor der Termin beginnt, statt mittendrin.
Der Hinweis nennt die Lage in klaren Worten und schlägt einen Ausweg vor, etwa das Mobilfunknetz des Telefons. Für die IT-Abteilung lässt sich eine Zeile aufklappen, die genau benennt, welche Adressen freigegeben sein müssen.
Mehrparteien per Full Mesh
Bei mehreren Teilnehmern hält jeder eine eigene Direktverbindung zu jedem anderen (Full Mesh). Auch hier bleibt der Server außen vor — er verteilt keine Medienströme.
Identität & Datenschutz
Ausweisen mit dem digitalen Personalausweis (PID) aus der EUDI-Wallet — kryptografisch geprüft, datensparsam und erst nach beidseitiger Zustimmung sichtbar.
Identität aus der EUDI-Wallet (PID)
Namen und Attribute stammen aus dem Personal-Identitätsnachweis (PID) der EUDI-Wallet — amtlich bestätigt statt selbst eingetippt. Es werden ausschließlich echte PID-Nachweise akzeptiert.
Geprüft über OpenID4VP (eIDAS 2.0)
Der Nachweis läuft über das Standard-Protokoll OpenID4VP im europäischen eIDAS-2.0-Rahmen. Die kryptografische Prüfung übernimmt ein spezialisierter Verifier-Dienst (EUDIPLO); die App verarbeitet nur das geprüfte Ergebnis.
Nur PID + geprüfte Vertrauensanker
Die Sicherheit hängt am Aussteller, nicht am Dateiformat: Akzeptiert wird nur der offizielle PID-Typ eines qualifizierten Ausstellers. „PID-ähnliche" selbst ausgestellte Nachweise werden über die Vertrauensanker-Liste des Verifiers abgewiesen.
Privatsphäre-Gate: erst Felder, dann Werte
Vor dem Verbinden seht ihr nur, welche Felder geteilt werden — nicht deren Inhalte. Die tatsächlichen Werte und Namen werden erst sichtbar, wenn beide Seiten ausdrücklich zugestimmt haben.
Datensparsamkeit & selektive Offenlegung
Pro Anruf wird nur ausgewählt, was nötig ist — zum Beispiel „über 18" statt des vollständigen Geburtsdatums. Jede Seite kann auch anonym bleiben.
Anschaulich erklärt
Die Wallet erhält vom Ausweisamt nicht einen Zettel mit allen Daten, sondern viele einzeln verschlossene Umschläge — je einer pro Angabe wie Name oder Geburtsdatum, mit einer zufälligen Geheimzahl darin. Über alle Umschläge zusammen gibt es eine amtlich unterschriebene Liste von Fingerabdrücken. Wird nur „über 18" abgefragt, öffnet die Wallet ausschließlich diesen einen Umschlag — der Rest bleibt verschlossen, bleibt aber durch die Liste nachweislich Teil desselben echten Ausweises.
Weitere Nachweise im Gespräch (Pro)
Im laufenden Anruf kann die Gastgeberseite zusätzliche Nachweise aus der Wallet anfragen — zum Beispiel eine Wohnraum-ID. Das Gegenüber sieht vorab die genaue Feldliste und kann jederzeit ablehnen; die Werte gehen ausschließlich an die anfragende Person, nie an den ganzen Raum und nie in Protokolle. Eine unbeantwortete Anfrage verfällt automatisch.
Sicherheitscode gegen Man-in-the-Middle
Beide Seiten sehen einen kurzen Sicherheitscode, der aus den Zertifikaten beider Browser berechnet wird. Stimmt er mündlich überein, hört niemand heimlich in der Mitte mit.
Was der Server speichert — und was nicht
Es gibt keine Konten und keine Ausweis-Datenbank. Der Server hält den Raum nur im Arbeitsspeicher; in Protokollen erscheinen höchstens die Namen der geteilten Felder, niemals deren Werte.
Dokumente & Signaturen
Im verifizierten Anruf lassen sich PDFs teilen, gemeinsam durchgehen und gemeinsam signieren — komplett Peer-to-Peer. Der Server sieht das Dokument nie, nicht einmal seine Prüfsumme.
Dokumente teilen — ohne Server
PDFs wandern in kleinen Blöcken direkt über den verschlüsselten Datenkanal zwischen den Browsern, mit Fortsetzung nach Verbindungsabbrüchen. Beide Seiten berechnen unabhängig eine SHA-256-Prüfsumme; erst wenn sie übereinstimmt, gilt das Dokument als Bit für Bit identisch.
Anschaulich erklärt
Eine Prüfsumme funktioniert wie ein Mixer: Aus der Datei wird ein „Smoothie" berechnet, aus dem sich die Datei nicht zurückgewinnen lässt. Zwei identische Dateien ergeben immer denselben Smoothie — ändert sich auch nur ein einziges Byte, kommt ein komplett anderer heraus. Stimmen die Smoothies beider Seiten überein, ist das Dokument nachweislich unverändert übertragen worden.
Gemeinsames Durchblättern
Beide sehen dieselbe Seite: Auf Wunsch werden Seitenwechsel live synchronisiert. Der PDF-Viewer läuft vollständig im Browser — es entsteht keine Kopie auf dem Server.
Gemeinsam signieren (Demo)
Beide Parteien signieren das Dokument nacheinander im PDF-Standardformat PAdES. Jede Signatur wird als inkrementelles Update angehängt — spätere Unterschriften können frühere nachweislich nicht verändern, das prüft die Gegenseite Byte für Byte. Aktuell als deutlich gekennzeichnete Demo-Signatur, rechtlich nicht bindend.
Identitätsbindung: Unterschrift = Gesprächspartner
Nach jedem Signaturschritt liest der Browser das Zertifikat direkt aus dem empfangenen Dokument und vergleicht den Namen mit den im Call verifizierten Ausweisdaten. Das Ergebnis steht sichtbar an jeder Signatur: stimmt überein, weicht ab — oder kein Abgleich möglich. Bei Abweichung entscheidet der Mensch, ob es weitergeht.
Prüfansicht für alle Signaturen
Ein Klick prüft jede im Dokument enthaltene Signatur: kryptografische Gültigkeit, Zertifikatsdetails, Signaturzeitpunkt und welcher Teil der Datei abgedeckt ist. Für rechtsverbindliche Prüfungen verweist die App auf ETSI-konforme Prüfdienste wie die EU-DSS-Demonstration.
Offenheit & Betrieb
Selbst hostbar, einbettbar — und zur Veröffentlichung als Open Source bestimmt.
Offenlegung & Editionen
Die Community Edition wird unter der AGPL-3.0 veröffentlicht, sobald die Testphase abgeschlossen ist — dann ist jede Aussage dieser Seite am Quellcode nachprüfbar. Eine Pro Edition ergänzt Zusatzfunktionen wie Mehrparteien-Anrufe, Bildschirmfreigabe oder einen Prüf-Audit-Trail.
Selbst hosten
Mit Docker Compose ist die Anwendung in Minuten selbst betrieben — inklusive eigenem TURN-Relay. So bleiben Betrieb und Daten vollständig unter eigener Kontrolle.
Einbetten auf Drittseiten
Der verifizierte Anruf lässt sich als Widget in andere Websites einbetten. Optional bindet ein signiertes Token die erlaubten Domains und abfragbaren Felder fest — gegen missbräuchliche Einbettung.
Browser-Unterstützung
Läuft in allen modernen Browsern (Chrome, Edge, Firefox, Safari — Desktop und mobil) über HTTPS. Auf dem iPhone fehlt systembedingt die Bildschirmfreigabe; die App blendet nicht verfügbare Funktionen aus und weist darauf hin.
Ehrliche Grenzen
Sicherheit heißt auch, die eigenen Annahmen offenzulegen. Diese Punkte solltet ihr kennen.
Vertrauensanker Verifier-Dienst
Die kryptografische PID-Prüfung geschieht im Verifier-Dienst (EUDIPLO). Wer die Anwendung betreibt, muss dessen Vertrauensanker korrekt konfigurieren — die App vertraut dem geprüften Ergebnis dieses Dienstes.
Metadaten, nicht Inhalte
Der Server sieht keine Gesprächsinhalte, aber technische Verbindungs-Metadaten (wer wann einen Raum betritt). Bei restriktiven Netzen können Medien über ein TURN-Relay laufen — verschlüsselt, aber über den Server geleitet.
Sicherheitscode aktuell für zwei Seiten
Der mündliche Sicherheitscode ist derzeit auf Eins-zu-eins-Gespräche ausgelegt. Bei mehr als zwei Teilnehmern wird er ausgeblendet; ein Gruppen-Sicherheitscode ist als spätere Erweiterung vorgesehen.
Demo-Signatur statt qualifizierter Signatur
Die heutige Dokument-Signatur nutzt selbstsignierte Demo-Zertifikate: technisch vollwertiges PAdES, aber ohne Vertrauenskette und ohne Rechtswirkung — die App sagt das an jeder Stelle deutlich. Die qualifizierte elektronische Signatur (QES) über einen Vertrauensdiensteanbieter, perspektivisch direkt aus der EUDI-Wallet, ist als nächste Ausbaustufe vorgesehen.
Rechtlich ist der Weg dahin bereits vorgezeichnet: eIDAS 2.0 verpflichtet die Wallets, für Privatpersonen bei nicht-beruflicher Nutzung kostenlos qualifiziert signieren zu können. Der Signaturschlüssel bleibt dabei auf einem zertifizierten, „remote" verwalteten Hardware-Modul beim Vertrauensdiensteanbieter; die Wallet spricht es in eurem Auftrag an. Erste Pilotprojekte testen zwei Modelle — wallet-gesteuert (die Wallet zeigt das Dokument und löst die Signatur aus) und anbieter-gesteuert (der Vertrauensdiensteanbieter führt den Vorgang, die Wallet dient nur der starken Authentifizierung). Ein produktiver Rollout wird ab 2027 erwartet, mit unterschiedlichem Tempo je Mitgliedstaat.
Anschaulich erklärt
Wallet und Signaturdienst müssen sich auf ein gemeinsames Geheimnis einigen, ohne dass der Signaturschlüssel je das gesicherte Hardware-Modul verlässt — wie beim Farbenmischen: Beide starten mit demselben, öffentlich bekannten Farbeimer. Jede Seite kippt eine eigene, geheime Farbe hinein — die Mischung lässt sich praktisch nicht mehr in ihre Zutaten zurückrechnen. Beide tauschen nur die fertigen Mischfarben aus, kippen dann noch einmal ihre eigene Geheimfarbe hinzu — und landen unabhängig voneinander bei exakt derselben Endfarbe. Wer nur die ausgetauschten Mischungen sieht, kann diese Endfarbe nicht nachbilden.
Der vollständige Quellcode wird veröffentlicht, sobald die Testphase abgeschlossen ist — dann lässt sich jede hier beschriebene Aussage daran nachprüfen. Bis dahin sind die Zusagen zur Datenabfrage unter /wrp-policy maschinenlesbar abrufbar.
Am besten selbst ausprobieren
Raum erstellen, Link teilen, ausweisen — ohne Konto, direkt im Browser.
Jetzt Anruf starten