Qualifizierte elektronische Signatur: das Smartphone als Schlüssel

KI-generiert, menschlich reviewt

27.9.2026 · eudi-wallet

Wer heute einen Vertrag rechtsgültig digital unterschreiben will, braucht eine qualifizierte elektronische Signatur (QES). Die ist rechtlich einer handschriftlichen Unterschrift gleichgestellt, aber im Alltag umständlich: Konto bei einem Vertrauensdiensteanbieter, Identifizierung per Online-Ausweis oder Video-Ident, dann Signieren über dessen Portal. Der Schlüssel liegt im Rechenzentrum des Anbieters. Mit der EUDI-Wallet kann das eigene Telefon zum Schlüssel werden. Wir haben das Verfahren in id-call.eu bereits gebaut und zeigen, wie die Signatur im PDF landet.

Was sich mit eIDAS 2.0 ändert

Die überarbeitete eIDAS-Verordnung (EU 2024/1183) verpflichtet jeden Mitgliedstaat, seinen Bürgerinnen und Bürgern eine EUDI-Wallet bereitzustellen. Zu den Pflichtfunktionen gehört, dass natürliche Personen damit qualifiziert elektronisch signieren können, und zwar kostenlos, zumindest für nicht berufliche Zwecke. In Deutschland startet die staatliche Wallet d-you am 2. Januar 2027; die Signaturfunktion soll nach Angaben des Bundes im Laufe des Jahres 2027 folgen. Mehr zum Zeitplan und zur Anbindung steht in unserem Überblick zur EUDI-Wallet-Integration.

Das Telefon als kryptographischer Schlüssel

Jede digitale Signatur beruht auf einem Schlüsselpaar. Der private Schlüssel erzeugt die Signatur, der öffentliche Schlüssel prüft sie. Entscheidend ist also, wo der private Schlüssel liegt und wer an ihn herankommt.

Moderne Smartphones haben dafür einen eigenen Sicherheitschip, die Secure Enclave beim iPhone und StrongBox bei Android. Ein dort erzeugter Schlüssel verlässt den Chip nie, auch nicht für ein Backup. Der Chip signiert nur nach einer frischen biometrischen Bestätigung. In unserer iOS-App ist der Schlüssel zusätzlich an die aktuell registrierten Face-ID-Daten gebunden: Registriert jemand ein weiteres Gesicht, wird der Schlüssel unbrauchbar.

Die Face-ID-Bestätigung ist damit zugleich die Willenserklärung. Man sieht das Dokument, bestätigt, und erst dann rechnet der Chip.

Wer bestätigt, dass der Schlüssel Ihnen gehört?

Ein Schlüssel allein sagt nichts über seinen Inhaber. Diese Verbindung stellt ein Zertifikat her: Eine Zertifizierungsstelle bestätigt mit ihrer eigenen Signatur, dass dieser öffentliche Schlüssel zu Erika Mustermann gehört. Bei einer QES muss diese Stelle ein qualifizierter Vertrauensdiensteanbieter sein, der in der Vertrauensliste der EU geführt wird.

Hier liegt auch der ehrliche Stand: Heute zertifiziert noch kein qualifizierter Vertrauensdiensteanbieter Schlüssel, die im Sicherheitschip eines Smartphones liegen. Ob die Wallet-Signatur am Ende über einen solchen lokalen Schlüssel oder über ein entferntes Signaturmodul des Anbieters läuft, ist in der europäischen Architektur noch nicht abschließend entschieden. Wir haben die lokale Variante gebaut, weil sie den Schlüssel dort lässt, wo die Person ist.

So simulieren wir das Verfahren heute bei id-call.eu

In id-call.eu, unserem Videoanruf mit Identität aus der Wallet, lassen sich Dokumente gemeinsam unterschreiben. Mit der iOS-App läuft das so ab:

sequenceDiagram
    participant W as EUDI-Wallet
    participant A as id-call-App
    participant C as Sicherheitschip
    participant S as id-call-Server (Demo-CA)
    W->>S: Personalausweisdaten (PID) im Anruf vorlegen
    A->>C: Zertifikatsanfrage signieren
    C-->>A: Face ID, dann Signatur
    A->>S: Zertifikatsanfrage (nur öffentlicher Schlüssel)
    S-->>A: Zertifikat auf den Namen aus der PID
    A->>C: Dokument signieren
    C-->>A: Face ID, dann Signatur
    A->>A: Signatur ins PDF einbetten

Identität: Die Person legt im Anruf ihren digitalen Personalausweis (PID) aus der Wallet vor. Der Server prüft ihn.
Zertifikat: Die App erzeugt eine Zertifikatsanfrage und lässt sie vom Chip signieren (erste Face-ID-Bestätigung). Der Server stellt das Zertifikat aus, und zwar auf den Namen aus der geprüften PID, nicht auf den Namen, der in der Anfrage steht.
Signatur: Für jedes Dokument folgt genau eine weitere Face-ID-Bestätigung.

Das Dokument selbst geht Ende-zu-Ende-verschlüsselt direkt zwischen den Teilnehmenden hin und her, der Server sieht es nie.

Was davon heute schon echt ist und was simuliert:

Baustein	Heute in id-call.eu	Mit QES-fähiger Wallet
Schlüssel im Sicherheitschip, Freigabe per Face ID	echt	unverändert
Identität aus der EUDI-Wallet	echt	unverändert
PDF-Signatur nach ETSI-Standard (PAdES)	echt	unverändert
Zertifikatsaussteller	eigene Demo-CA, nicht rechtsgültig	qualifizierter Vertrauensdiensteanbieter
Vertrauenswürdiger Zeitstempel	fehlt	vom Anbieter

Die Demo-CA spielt also genau die Rolle, die später ein qualifizierter Anbieter übernimmt. Jedes Zertifikat trägt im Namen den Hinweis „DEMO, nicht rechtsgültig“, und die Oberfläche weist sichtbar darauf hin.

Wer im Browser statt in der App teilnimmt, kann mit dem Telefon unterschreiben: Nach dem Scan eines QR-Codes bekommt das Telefon das vollständige PDF, nicht nur einen Hash, und zeigt jede Seite selbst an. Ein Telefon, das einen fremd gelieferten Hash signiert, würde sonst alles unterschreiben, was der Browser behauptet.

Wie die Signatur ins PDF gelangt

Eine PDF-Signatur ist kein Stempelbild auf der Seite, sondern ein Datenblock in der Datei. Damit spätere Signaturen die früheren nicht zerstören, wird die Datei nie umgeschrieben, sondern nur ergänzt: Jede Signatur hängt einen neuen Abschnitt an das Ende an (ein sogenanntes inkrementelles Update).

Ein echtes, mit dem id-call-Code erzeugtes Beispiel; im angehängten Abschnitt steht dieses Signaturobjekt (gekürzt):

5 0 obj
<<
/Type /Sig
/Filter /Adobe.PPKLite
/SubFilter /ETSI.CAdES.detached
/ByteRange [0 619 33389 750]
/Contents <308205ad06092a864886f70d010702a082059e3082059a…0000>
/M (D:20260927173216Z)
/Name (Erika Mustermann)
>>

So entsteht es:

Platz reservieren: Zuerst wird das Objekt mit einer Lücke in /Contents geschrieben, 16.384 Byte Platz, als Hexadezimalzahlen voller Nullen.
Byte-Bereiche festlegen: /ByteRange beschreibt, was signiert wird: 619 Bytes ab Position 0, dann 750 Bytes ab Position 33.389. Dazwischen liegt genau die Lücke. Signiert wird also die ganze Datei außer dem Platz, in den die Signatur gleich kommt.
Fingerabdruck bilden: Über diese Bytes wird ein SHA-256-Hash berechnet, ein digitaler Fingerabdruck, der sich bei jeder Änderung vollständig ändert. Im Beispiel ist das 206dd4e7…e78d29.
Signieren: Der Hash kommt zusammen mit einem Verweis auf das Zertifikat in ein kleines Paket signierter Attribute. Dieses Paket signiert der Chip, nicht das Dokument selbst.
Einbetten: Signatur, signierte Attribute und Zertifikatskette bilden einen CMS-Container (ein standardisiertes Signaturformat). Er wird hexkodiert in die Lücke geschrieben; der Rest bleibt mit Nullen aufgefüllt.

Die Angabe ETSI.CAdES.detached besagt, dass die Signatur dem europäischen PAdES-Standard folgt. Unsere Signaturen erfüllen dessen Grundstufe B-B. Die Signaturzeit in /M ist dabei nur eine Behauptung des signierenden Geräts. Einen belastbaren Zeitpunkt liefert erst ein qualifizierter Zeitstempel, wie wir ihn in unserem Artikel zur gerichtsfesten Beweissicherung beschreiben. Damit wäre die Stufe B-T erreicht.

Selbst nachprüfen

Jede Signatur lässt sich ohne unsere Software prüfen. Dieses Python-Skript schneidet die signierten Bytes und den Signaturcontainer aus dem PDF:

import hashlib, re

pdf = open("vertrag-signiert.pdf", "rb").read()
a, b, c, d = map(int, re.search(rb"/ByteRange\s*\[\s*(\d+) (\d+) (\d+) (\d+)", pdf).groups())

signiert = pdf[a:a + b] + pdf[c:c + d]          # alles außer der Lücke
open("signierte-bytes.bin", "wb").write(signiert)
print("SHA-256:", hashlib.sha256(signiert).hexdigest())

raw = bytes.fromhex(pdf[a + b + 1:c - 1].decode())  # Hex zwischen < und >
laenge = 4 + int.from_bytes(raw[2:4], "big")         # DER-Kopf 30 82 LL LL
open("signatur.p7s", "wb").write(raw[:laenge])       # Rest ist Null-Auffüllung

Anschließend prüft OpenSSL zwei Dinge getrennt:

# 1. Passt die Signatur zu den Bytes? (Zertifikatskette wird übersprungen)
openssl cms -verify -binary -inform DER -in signatur.p7s \
  -content signierte-bytes.bin -noverify -out /dev/null
# → CMS Verification successful

# 2. Ist der Aussteller vertrauenswürdig?
openssl cms -verify -binary -inform DER -in signatur.p7s \
  -content signierte-bytes.bin -out /dev/null
# → Verify error: self-signed certificate in certificate chain

Genau dieser Unterschied ist der Kern: Mathematisch ist die Signatur einwandfrei, und das Dokument ist nachweislich unverändert. Rechtlich zählt sie erst, wenn der Aussteller des Zertifikats einer vertrauenswürdigen Stelle zugeordnet werden kann.

Prüfen im Acrobat Reader

Acrobat Reader trennt genauso. Unsere Signatur trägt kein Bild auf der Seite; man öffnet sie über die Signaturleiste oben bzw. den Signaturbereich. Dort zeigt Acrobat:

Dokument unverändert: Die Prüfung von Hash und Signatur ist bestanden.
Identität unbekannt: Die Demo-CA steht weder in Adobes eigener Vertrauensliste noch in der Vertrauensliste der EU. Die Gültigkeit der Signatur wird deshalb als unbekannt ausgewiesen.
Zeit laut Gerät: Ohne Zeitstempel stammt die Signaturzeit von der Uhr des Unterzeichnenden.

Unter „Signatureigenschaften“ und „Zertifikat anzeigen“ sieht man die Kette: das Zertifikat auf Erika Mustermann, darüber die „id-call Demo-CA“, jeweils mit dem Demo-Hinweis im Namen.

Bei einer echten QES ändert sich nur der Aussteller. Acrobat hält einen regelmäßig aktualisierten Auszug der EU-Vertrauensliste vor. Führt die Zertifikatskette zu einem dort gelisteten qualifizierten Anbieter, weist Acrobat die Signatur ausdrücklich als qualifizierte elektronische Signatur nach der eIDAS-Verordnung aus. Unabhängig von Adobe prüft der Validator EU DSS der EU-Kommission, einschließlich der PAdES-Stufe.

Was bis zur qualifizierten elektronischen Signatur noch fehlt

Ein qualifizierter Anbieter, der Schlüssel im Smartphone-Chip zertifiziert und damit die Demo-CA ersetzt.
Ein Nachweis, dass der Schlüssel wirklich im Chip liegt: Apple und Google bieten dafür Bestätigungen an (Key Attestation), die ein Anbieter vor der Zertifizierung prüfen würde. Heute kann unsere Demo-CA das noch nicht belegen.
Qualifizierte Zeitstempel, um von B-B auf B-T zu kommen.

In id-call.eu ist der Zertifikatsaussteller ein austauschbarer Baustein; alles andere bleibt, wie es ist.

Kurz zusammengefasst

Mit der EUDI-Wallet sollen Bürgerinnen und Bürger kostenlos qualifiziert elektronisch signieren können; in Deutschland ist das für 2027 angekündigt.
Der Signaturschlüssel kann im Sicherheitschip des eigenen Telefons liegen und wird nur nach Face ID benutzt.
In der PDF-Datei signiert eine Signatur alle Bytes außer ihrer eigenen Lücke (/ByteRange); jede weitere Signatur wird angehängt.
Ob eine Signatur rechtlich zählt, entscheidet der Zertifikatsaussteller. Acrobat und EU DSS prüfen das gegen die EU-Vertrauensliste.
id-call.eu simuliert den kompletten Ablauf heute mit einer Demo-CA und ist bereit für den Tausch gegen einen qualifizierten Anbieter.

Wenn Sie Signaturen oder Wallet-Identitäten in eigene Abläufe einbinden wollen, klären wir im ersten Schritt, welche Dokumente welches Signaturniveau brauchen. Mehr dazu auf unserer Seite zur EUDI-Wallet-Integration und in der Case Study zur id-call-App.

Dieser Text ist ein technischer Überblick und keine Rechtsberatung.