Technische Whitepapers

Dieses Whitepaper beschreibt die Architektur des Secure-Transfer-Systems von PDF Pro, eines Zero-Knowledge-Mechanismus zur Dateiübertragung, bei dem Dateien vor dem Upload clientseitig mit AES-256-GCM verschlüsselt werden. Der Server speichert ausschließlich opakes Chiffrat und ist zu keinem Zeitpunkt in der Lage, Dateiinhalte zu entschlüsseln, einzusehen oder zu lesen. Das System unterstützt zwei Schlüsselmodi: einen automatisch erzeugten Zufallsschlüssel (der über das URL-Fragment übertragen wird, welches niemals an den Server gesendet wird) oder einen aus einer Passphrase abgeleiteten Schlüssel mittels PBKDF2. In beiden Modi existiert der Verschlüsselungsschlüssel ausschließlich in den Browsern von Absender und Empfänger. Dieses Dokument beschreibt die kryptografischen Primitiven, den Datenfluss, das Bedrohungsmodell sowie die ehrlich dargelegten Einschränkungen des Systems.

Das Secure-Transfer-System folgt einer strikten Trennung zwischen Client und Server, bei der alle kryptografischen Operationen ausschließlich im Browser stattfinden:

• Client (Browser): Schlüsselableitung, Verschlüsselung, Entschlüsselung, Dateilesen, Dateirekonstruktion.
• Server (Supabase Storage + Serverless Functions): Speicherung verschlüsselter Blobs, Verwaltung von Metadaten (Ablauf, Downloadanzahl), Durchsetzung von Zugriffsrichtlinien.

Der Server ist bewusst als „dumme Leitung" für verschlüsselte Daten konzipiert. Er hat keine Kenntnis vom Verschlüsselungsschlüssel, der Passphrase oder den Dateiinhalten. Dies wird architektonisch durchgesetzt und nicht bloß durch Richtlinien.

Die gesamte Dateiverschlüsselung verwendet den authentifizierten Verschlüsselungsalgorithmus AES-256-GCM, der über die native Web Crypto API des Browsers angesprochen wird. Dies gewährleistet sowohl Vertraulichkeit (Daten können nicht gelesen werden) als auch Integrität (Daten können nicht unbemerkt verändert werden).

1.3.1 Algorithmusparameter

1.3.2 Implementierung der Verschlüsselung

// Vereinfachter Verschlüsselungsablauf (Web Crypto API)

const iv = crypto.getRandomValues(new Uint8Array(12));
const salt = crypto.getRandomValues(new Uint8Array(16));

// Schlüssel aus Passphrase ableiten (siehe Abschnitt 1.4)
const key = await deriveKey(passphrase, salt);

// Datei verschlüsseln
const ciphertext = await crypto.subtle.encrypt(
  { name: "AES-GCM", iv: iv },
  key,
  fileArrayBuffer
);

// Paketstruktur: [salt (16B)] + [iv (12B)] + [ciphertext + tag]
const blob = concatenate(salt, iv, ciphertext);

Der finale verschlüsselte Blob ist eine Verkettung dreier Komponenten: des 16 Byte langen Salt (für die Schlüsselableitung verwendet), des 12 Byte langen IV (für AES-GCM verwendet) und des Chiffrats mit angehängtem 16 Byte langen GCM-Authentifizierungs-Tag. Dieser Blob ist das, was der Server empfängt und speichert.

Secure Transfer unterstützt zwei sich gegenseitig ausschließende Schlüsselmodi. Der Modus wird vom Absender beim Erstellen der Übertragung gewählt.

1.4.1 Modus A — Automatisch erzeugter Schlüssel (Standard)

Im Standardmodus ist keine Passphrase beteiligt. Der Browser erzeugt direkt einen kryptografisch zufälligen 256-Bit-AES-Schlüssel:

• Der Browser erzeugt einen zufälligen 256-Bit-AES-GCM-Schlüssel über crypto.getRandomValues() und crypto.subtle.generateKey().
• Der Schlüssel wird als Rohbytes exportiert und im URL-Fragment (#) platziert.
• Gemäß HTTP-Spezifikation wird das URL-Fragment niemals an den Server gesendet — es wird ausschließlich vom Browser verarbeitet.
• Der Absender teilt die vollständige URL (einschließlich des Fragments) dem Empfänger über einen von ihm bevorzugten Kanal mit (z. B. Messenger, E-Mail).
• Der Browser des Empfängers extrahiert den Schlüssel aus dem URL-Fragment und verwendet ihn zur Entschlüsselung der Datei.

1.4.2 Modus B — Passphrasengeschützte Übertragung

Wenn der Absender eine Passphrase festlegt, wird der Schlüssel mittels PBKDF2 aus dieser Passphrase abgeleitet:

• Der Nutzer gibt eine Passphrase ein.
• Aus der Passphrase wird über PBKDF2-SHA256 ein AES-256-Schlüssel abgeleitet.
• Parameter: 600.000 Iterationen, zufälliges 16 Byte langes Salt.
• Der abgeleitete Schlüssel verschlüsselt die Datei.
• Das Salt wird neben dem Chiffrat gespeichert (dem verschlüsselten Blob vorangestellt).
• Die Passphrase wird außerhalb des Systems geteilt (getrennt vom Link).
• Eine Wiederherstellung der Passphrase ist nicht möglich — weder der Server noch PDF Pro können eine vergessene Passphrase wiederherstellen.

1.4.3 PBKDF2-Parameter (Modus B)

1.4.4 Implementierung der Schlüsselableitung (Modus B)

async function deriveKey(passphrase, salt) {
  // Passphrase als rohes Schlüsselmaterial importieren
  const keyMaterial = await crypto.subtle.importKey(
    "raw",
    new TextEncoder().encode(passphrase),
    { name: "PBKDF2" },
    false,
    ["deriveKey"]
  );

  // AES-256-GCM-Schlüssel ableiten
  return crypto.subtle.deriveKey(
    {
      name: "PBKDF2",
      salt: salt,
      iterations: 600000,
      hash: "SHA-256"
    },
    keyMaterial,
    { name: "AES-GCM", length: 256 },
    false,
    ["encrypt", "decrypt"]
  );
}

Der vollständige Lebenszyklus einer sicheren Übertragung verläuft wie folgt:

1.5.1 Senden (Upload) — Modus A (automatisch erzeugter Schlüssel)

1. Der Absender wählt eine Datei im Browser aus.
2. Der Browser erzeugt einen zufälligen 256-Bit-AES-GCM-Schlüssel und einen zufälligen 12 Byte langen IV mit crypto.getRandomValues().
3. Der Browser verschlüsselt die Datei mittels AES-256-GCM und erzeugt Chiffrat und Authentifizierungs-Tag.
4. Der Browser verkettet [IV | Chiffrat+Tag] zu einem einzelnen Blob.
5. Der Browser lädt den verschlüsselten Blob über HTTPS auf den Server hoch.
6. Der Server speichert den Blob in Supabase Storage und erstellt einen Metadatensatz (Übertragungs-ID, Ablauf, Downloadlimit, Dateiname, Dateigröße).
7. Der Server gibt eine Übertragungs-URL zurück. Der Browser hängt den exportierten Schlüssel an das URL-Fragment (#) an.
8. Der Absender teilt die vollständige URL (mit Fragment) mit dem Empfänger.

1.5.2 Senden (Upload) — Modus B (Passphrase)

1. Der Absender wählt eine Datei aus und gibt eine Passphrase im Browser ein.
2. Der Browser erzeugt ein zufälliges 16 Byte langes Salt und einen 12 Byte langen IV mittels crypto.getRandomValues().
3. Der Browser leitet aus der Passphrase mittels PBKDF2 (600.000 Iterationen) einen AES-256-Schlüssel ab.
4. Der Browser verschlüsselt die Datei mittels AES-256-GCM und erzeugt Chiffrat und Authentifizierungs-Tag.
5. Der Browser verkettet [Salt | IV | Chiffrat+Tag] zu einem einzelnen Blob.
6. Der Browser lädt den verschlüsselten Blob über HTTPS auf den Server hoch.
7. Der Server speichert den Blob in Supabase Storage und erstellt einen Metadatensatz (Übertragungs-ID, Ablauf, Downloadlimit, Dateiname, Dateigröße).
8. Der Server gibt eine Übertragungs-URL zurück, die die Übertragungs-ID enthält.
9. Der Absender teilt die Übertragungs-URL und die Passphrase über getrennte Kanäle mit dem Empfänger.

1.5.3 Empfangen (Download) — Modus A

1. Der Empfänger öffnet die vollständige Übertragungs-URL (mit Schlüssel im Fragment).
2. Der Browser extrahiert den AES-Schlüssel aus dem URL-Fragment (wird nie an den Server gesendet).
3. Der Browser lädt den verschlüsselten Blob über HTTPS vom Server herunter.
4. Der Browser extrahiert den IV (erste 12 Byte) aus dem Blob.
5. Der Browser entschlüsselt das Chiffrat mittels AES-256-GCM mit extrahiertem Schlüssel und IV.
6. Ist die Entschlüsselung erfolgreich (GCM-Tag ist gültig), wird die Klartextdatei dem Nutzer bereitgestellt.
7. Der Server aktualisiert den Download-Zähler und löscht den Blob, falls „Burn on read" aktiviert ist.

1.5.4 Empfangen (Download) — Modus B

1. Der Empfänger öffnet die Übertragungs-URL und gibt die Passphrase im Browser ein.
2. Der Browser lädt den verschlüsselten Blob über HTTPS vom Server herunter.
3. Der Browser extrahiert das Salt (erste 16 Byte) und den IV (nächste 12 Byte) aus dem Blob.
4. Der Browser leitet aus Passphrase + Salt mittels PBKDF2 (600.000 Iterationen) den AES-256-Schlüssel ab.
5. Der Browser entschlüsselt das Chiffrat mittels AES-256-GCM mit abgeleitetem Schlüssel und IV.
6. Ist die Entschlüsselung erfolgreich (GCM-Tag ist gültig), wird die Klartextdatei dem Nutzer bereitgestellt.
7. Schlägt die Entschlüsselung fehl (falsche Passphrase = falscher Schlüssel = ungültiger GCM-Tag), wird ein Fehler angezeigt.
8. Der Server aktualisiert den Download-Zähler und löscht den Blob, falls „Burn on read" aktiviert ist.

Alle sicheren Übertragungen sind ihrer Gestaltung nach flüchtig. Es gibt keine Option zur dauerhaften Speicherung.

1.7.1 Ablaufoptionen

1.7.2 Löschgarantie

Wenn eine Übertragung abläuft oder beim Lesen vernichtet wird, wird der verschlüsselte Blob dauerhaft aus Supabase Storage gelöscht. Der Metadatensatz wird 30 Tage lang in einem weich-gelöschten Zustand aufbewahrt (zur Missbrauchsuntersuchung), bevor er endgültig entfernt wird. Der Metadatensatz enthält weder den Verschlüsselungsschlüssel, noch die Passphrase, noch irgendeine Information, mit der die Datei rekonstruiert werden könnte.

1.8.1 Annahmen

• Vertrauenswürdige Browser-Laufzeitumgebung (keine schädlichen Erweiterungen)
• Sicherer Kanal zum Teilen von Link/Passphrase
• Die HTTPS-Terminierung ist vertrauenswürdig
• Das Gerät des Empfängers ist nicht kompromittiert
• Keine Bildschirmaufnahme-Verhinderung

1.8.2 Außerhalb des Geltungsbereichs

• Schadsoftware auf Endgeräten
• Social-Engineering-/Phishing-Angriffe
• Bildschirmaufzeichnung durch Empfänger
• Kompromittierte Browsererweiterungen
• Angriffe durch Quantencomputer (künftige Erwägung)

• Die Stärke der Passphrase liegt in der Kontrolle des Nutzers. Wir können eine Mindestlänge in der Benutzeroberfläche durchsetzen, aber nicht verhindern, dass Nutzer schwache Passphrasen wählen. Die Sicherheit der Verschlüsselung ist direkt proportional zur Entropie der Passphrase.
• Die Übermittlung der Passphrase erfolgt außerhalb des Systems. Wir stellen keinen sicheren Kanal zum Teilen der Passphrase bereit. Wird die Passphrase über einen unsicheren Kanal geteilt (z. B. unverschlüsselte E-Mail zusammen mit der Übertragungs-URL), wird das Sicherheitsmodell geschwächt.
• Datei-Metadaten sind nicht verschlüsselt. Ursprünglicher Dateiname und -größe werden im Klartext auf dem Server gespeichert. Dies offenbart Art und ungefähre Natur der übertragenen Datei, auch wenn ihre Inhalte verschlüsselt bleiben.
• Vertrauen in den clientseitigen Code. Die Nutzer müssen darauf vertrauen, dass das von unserem CDN ausgelieferte JavaScript der korrekte, unveränderte Code ist. Ein kompromittiertes CDN oder ein DNS-Hijack könnte bösartiges JavaScript ausliefern. Dies ist eine grundlegende Einschränkung jeder webbasierten Kryptografie.
• Keine Forward Secrecy. Wird die Passphrase zu irgendeinem Zeitpunkt vor dem Löschen des verschlüsselten Blobs kompromittiert, kann eine gespeicherte Kopie des Blobs entschlüsselt werden. „Burn on read" und kurze Ablaufzeiten mindern dieses Risiko.
• Abhängigkeit vom Sicherheitsmodell des Browsers. Die Sicherheit des Systems hängt von der Implementierung der Web Crypto API im Browser sowie dessen Speicher-Isolation ab. Ein kompromittierter Browser oder eine bösartige Erweiterung könnte sämtliche clientseitigen Schutzmaßnahmen untergraben.
• Quantencomputing. AES-256 gilt als quantenresistent (Grovers Algorithmus reduziert die effektive Sicherheit auf 128 Bit, was weiterhin undurchführbar bleibt). PBKDF2 mit SHA-256 ist jedoch nicht speziell auf Post-Quanten-Resistenz ausgelegt. Dies ist keine kurzfristige Sorge, wird aber der Vollständigkeit halber erwähnt.

Dieses Whitepaper beschreibt die Architektur des Privacy-Signature-Systems von PDF Pro, eines kryptografischen Mechanismus zur Dokumentensignatur, bei dem das PDF-Dokument den Browser des Unterzeichners niemals verlässt. Das System verwendet ECDSA mit der Kurve P-256 und SHA-256-Hashing zur Erzeugung abgetrennter digitaler Signaturen. Nur der Dokumenten-Hash, die kryptografische Signatur und der öffentliche Schlüssel werden an den Server übermittelt. Private Schlüssel werden ausschließlich im Browser des Nutzers erzeugt, verschlüsselt und in IndexedDB gespeichert, geschützt durch PBKDF2-Schlüsselableitung (600.000 Iterationen) und AES-256-GCM-Verschlüsselung. Dieses Dokument beschreibt die vollständige Signier- und Verifizierungsarchitektur, das Schlüsselverwaltungsmodell, das Schema des signierten Payloads, die Gestaltung des Audit-Trails, das Bedrohungsmodell sowie die ehrlich dargelegten Einschränkungen.

Das Privacy-Signature-System ist auf eine fundamentale Einschränkung hin konzipiert: Das PDF-Dokument darf niemals an den Server übermittelt werden. Dies wird architektonisch durch ein Modell abgetrennter Signaturen durchgesetzt.

• Client (Browser): Schlüsselerzeugung, Schlüsselspeicherung (verschlüsselt in IndexedDB), Dokumenten-Hashing (SHA-256), Signaturerzeugung (ECDSA P-256), Signaturverifikation.
• Server (Supabase): Speichert öffentliche Schlüssel, Signatur-Datensätze (Hash + Signatur + Metadaten) und Audit-Trail-Ereignisse. Empfängt niemals das PDF-Dokument, private Schlüssel oder Schlüssel-Passphrasen.

2.3.1 Algorithmusparameter

2.3.2 Signierablauf

// 1. PDF-Dokument hashen (clientseitig)
const fileBuffer = await file.arrayBuffer();
const hashBuffer = await crypto.subtle.digest("SHA-256", fileBuffer);
const hashHex = Array.from(new Uint8Array(hashBuffer))
  .map(b => b.toString(16).padStart(2, '0')).join('');

// 2. Hash mit privatem Schlüssel signieren (clientseitig)
const signature = await crypto.subtle.sign(
  { name: "ECDSA", hash: "SHA-256" },
  privateKey,   // CryptoKey aus IndexedDB (entschlüsselt)
  hashBuffer
);

// 3. An den Server senden: Hash + Signatur + öffentlicher Schlüssel (NICHT das PDF)
await submitSignature({
  documentHash: hashHex,
  signature: base64Encode(signature),
  publicKey: exportedPublicKeyJWK
});

2.4.1 Schlüsselerzeugung

// ECDSA-P-256-Schlüsselpaar erzeugen (Web Crypto API)
const keyPair = await crypto.subtle.generateKey(
  {
    name: "ECDSA",
    namedCurve: "P-256"
  },
  true,   // extrahierbar (für Verschlüsselung + Speicherung erforderlich)
  ["sign", "verify"]
);

// Öffentlichen Schlüssel als JWK für die Server-Registrierung exportieren
const publicKeyJWK = await crypto.subtle.exportKey("jwk", keyPair.publicKey);

// Privaten Schlüssel als JWK zur verschlüsselten Speicherung exportieren
const privateKeyJWK = await crypto.subtle.exportKey("jwk", keyPair.privateKey);

Persistente private Schlüssel werden niemals im Klartext gespeichert. Bevor der private Schlüssel (als JWK-JSON exportiert) in IndexedDB geschrieben wird, wird er nach demselben Muster wie bei Secure Transfer verschlüsselt:

2.5.1 Schutzparameter

2.5.2 Speicher-Schema

// Datensatzstruktur in IndexedDB für einen verschlüsselten Signierschlüssel
{
  "keyId":       "uuid-v4-unique-identifier",
  "publicKey":   { /* JWK-Format, unverschlüsselt */ },
  "encryptedPrivateKey": {
    "salt":       "base64-encoded-16-bytes",
    "iv":         "base64-encoded-12-bytes",
    "ciphertext": "base64-encoded-aes-gcm-ciphertext"
  },
  "algorithm":   "ECDSA",
  "curve":       "P-256",
  "createdAt":   "2026-04-16T00:00:00.000Z",
  "userId":      "supabase-auth-user-id"
}

PDF Pro verwendet ein Modell abgetrennter Signaturen, d. h. die Signatur wird getrennt vom Dokument gespeichert. Dies ist der entscheidende Datenschutzmechanismus: Das Dokument verlässt niemals das Gerät des Unterzeichners.

2.6.1 Was an den Server gesendet wird

• SHA-256-Hash des PDFs (32 Byte, hex-kodiert zu 64 Zeichen).
• ECDSA-Signatur über den Hash (64 Byte, base64-kodiert).
• Öffentlicher Schlüssel des Unterzeichners (JWK-Format).
• Metadaten: Anzeigename des Unterzeichners, E-Mail des Unterzeichners (bei Authentifizierung), Zeitstempel, Signatur-ID.

2.6.2 Was NICHT an den Server gesendet wird

• Das PDF-Dokument selbst — niemals übermittelt.
• Der private Schlüssel — verlässt niemals den Browser.
• Die Signier-Passphrase — verlässt niemals den Browser.
• Jegliche Seiteninhalte, Texte oder Bilder aus dem PDF.

Das folgende JSON-Schema definiert den vollständigen Signatur-Datensatz, der auf dem Server gespeichert wird:

{
  "schemaVersion":  "1.0",
  "signatureId":    "uuid-v4",
  "documentHash":   "sha256-hex-64-chars",
  "hashAlgorithm":  "SHA-256",
  "signature":      "base64-encoded-ecdsa-signature",
  "signatureAlgorithm": "ECDSA",
  "curve":          "P-256",
  "publicKey": {
    "kty": "EC",
    "crv": "P-256",
    "x":   "base64url-encoded-x-coordinate",
    "y":   "base64url-encoded-y-coordinate"
  },
  "signer": {
    "identityLevel": "authenticated | self-asserted",
    "displayName":   "string or null",
    "email":         "string or null",
    "userId":        "supabase-uid or null"
  },
  "timestamp":      "ISO-8601-UTC",
  "metadata": {
    "fileName":     "original-file-name.pdf",
    "fileSize":     123456,
    "pageCount":    12,
    "clientVersion": "2.0.0",
    "userAgent":    "browser-user-agent-string"
  },
  "auditChain": {
    "previousEventHash": "sha256-of-previous-audit-event or null",
    "eventHash":         "sha256-of-this-record"
  }
}

Die Signaturverifikation ist ein zweiphasiger Prozess: clientseitige kryptografische Verifikation, gefolgt von einer serverseitigen Gegenprüfung.

2.8.1 Phase 1: clientseitige kryptografische Verifikation

1. Der Nutzer lädt ein PDF in den Browser.
2. Der Browser berechnet den SHA-256-Hash des geladenen PDFs.
3. Der Browser fragt den Server nach Signatur-Datensätzen, die diesem Hash entsprechen.
4. Für jeden zurückgegebenen Signatur-Datensatz führt der Browser eine ECDSA-Verifikation durch:

   const isValid = await crypto.subtle.verify(
     { name: "ECDSA", hash: "SHA-256" },
     importedPublicKey,
     signatureBuffer,
     hashBuffer
   );

5. Ist isValid === true, so ist die Signatur kryptografisch gültig: Das Dokument wurde seit dem Signieren nicht verändert, und die Signatur wurde vom Inhaber des zugehörigen privaten Schlüssels erzeugt.

2.8.2 Phase 2: serverseitige Gegenprüfung

1. Der Server bestätigt, dass der öffentliche Schlüssel im Signatur-Datensatz einem bekannten Nutzer zugeordnet ist (bei authentifizierten Signaturen).
2. Der Server bestätigt, dass der Signatur-Datensatz nicht widerrufen wurde.
3. Der Server bestätigt die Integrität des Audit-Trails (Hash-Ketten-Validierung).
4. Der Server gibt die Identitätsstufe und den Registrierungsstatus des Unterzeichners zurück.

2.8.3 Verifikationsergebnisse

Jedes Signier- und Verifikationsereignis wird in einem manipulationsevidenten Audit-Trail festgehalten. Die Ereignisse sind hash-verkettet: Jedes Ereignis enthält den SHA-256-Hash des vorherigen Ereignisses und bildet so eine ausschließlich anzufügende Kette, ähnlich einer Blockchain.

2.9.1 Audit-Ereignistypen

2.9.2 Struktur der Hash-Kette

// Jedes Audit-Ereignis enthält:
{
  "eventId":            "uuid-v4",
  "eventType":          "DOCUMENT_SIGNED",
  "timestamp":          "ISO-8601-UTC",
  "data":               { /* ereignisspezifischer Payload */ },
  "previousEventHash": "sha256-of-previous-event-json",
  "eventHash":          "sha256-of-this-event-json-without-eventHash"
}

// Manipulationsdetektion: zur Prüfung der Kette berechnen:
// SHA-256(JSON.stringify(Ereignis ohne eventHash-Feld))
// und bestätigen, dass dies mit eventHash übereinstimmt.
// Anschließend bestätigen, dass previousEventHash dem eventHash des vorherigen Ereignisses entspricht.

Wird irgendein Ereignis in der Kette verändert, brechen alle nachfolgenden Hash-Verknüpfungen, wodurch Manipulationen sofort erkennbar werden. Dies liefert eine starke Garantie für die Integrität des Audit-Trails.

Hinweis: In der Produkt-Benutzeroberfläche kann „self_asserted" als „Selbst erklärte Identität" oder „Gastsignatur" angezeigt werden. „authenticated" kann als „Authentifiziertes Konto" angezeigt werden. Dies sind Anzeigebezeichnungen für dieselben zugrunde liegenden Identitätsstufen.

2.11.1 Annahmen

• Vertrauenswürdige Browser-Laufzeitumgebung
• Die Implementierung der Web Crypto API ist korrekt
• IndexedDB ist für andere Ursprünge nicht zugänglich
• Der Nutzer schützt seine Passphrase
• Der Servercode entspricht dem veröffentlichten Verhalten

2.11.2 Außerhalb des Geltungsbereichs

• Schadsoftware auf Endgeräten
• Social-Engineering-/Phishing-Angriffe
• Bildschirmaufzeichnung durch Empfänger
• Kompromittierte Browsererweiterungen
• Angriffe durch Quantencomputer (künftige Erwägung)

• Keine qualifizierte elektronische Signatur (QES). PDF-Pro-Signaturen erfüllen nicht die Anforderungen der EU-Verordnung 910/2014 (eIDAS) an qualifizierte elektronische Signaturen. Wir sind kein qualifizierter Vertrauensdiensteanbieter (QTSP), und unsere Signierschlüssel werden nicht auf einer qualifizierten Signaturerstellungseinheit (QSCD) erzeugt.
• Nicht eIDAS-qualifiziert. Nach eIDAS besitzen nur qualifizierte elektronische Signaturen in allen EU-Mitgliedstaaten die rechtliche Gleichstellung mit handschriftlichen Unterschriften. PDF-Pro-Signaturen sind bestenfalls fortgeschrittene elektronische Signaturen; ihre rechtliche Wirkung hängt von der jeweiligen Rechtsordnung und dem Anwendungsfall ab.
• Nicht Adobe-vertraut. PDF-Pro-Signaturen erscheinen nicht auf der Adobe Approved Trust List (AATL). Beim Öffnen eines mit PDF Pro signierten Dokuments in Adobe Acrobat wird die Signatur in Adobes Benutzeroberfläche nicht als „vertrauenswürdig" angezeigt. Die Verifikation muss über das Verifikationssystem von PDF Pro erfolgen.
• Keine Zertifizierungsstelle. Wir stellen keine X.509-Zertifikate aus. Unsere Public-Key-Infrastruktur ist PDF Pro-eigen und nicht mit PKI-Systemen interoperabel, wie sie etwa von Behörden oder Zertifizierungsstellen eingesetzt werden.
• Keine Beurkundung. PDF-Pro-Signaturen stellen keine notarielle Beurkundung, keine Apostille und keine staatlich bescheinigte Dokumentenauthentifizierung dar.
• Keine reale Identitätsprüfung. Wir verifizieren E-Mail-Adressen über Supabase Auth, führen jedoch keine Prüfung staatlicher Ausweisdokumente, biometrischen Identitätsprüfungen oder persönlichen Identitätsfeststellungen durch.

2.12.1 Wofür PDF-Pro-Signaturen GEEIGNET sind

• Geschäftliche Abläufe — interne Dokumentenfreigaben, Team-Zeichnungen, Beschaffungsgenehmigungen, bei denen die Parteien dem Identitätsmodell von PDF Pro vertrauen.
• Integritätsprüfung — Nachweis, dass ein Dokument seit einem bestimmten Zeitpunkt nicht verändert wurde.
• Nichtabstreitbarkeit (eingeschränkt) — Nachweis, dass der Inhaber eines bestimmten privaten Schlüssels ein bestimmtes Dokument zu einem bestimmten Zeitpunkt signiert hat. Die Stärke der Nichtabstreitbarkeit hängt davon ab, wie gut der private Schlüssel geschützt ist und wie der öffentliche Schlüssel an eine Identität gebunden wird.
• Audit-Compliance — Bereitstellung eines manipulationsevidenten Audit-Trails von Signier-Ereignissen zur Erfüllung interner Compliance-Anforderungen.
• Vertragssignierung — In vielen Rechtsordnungen sind elektronische Signaturen (einschließlich nicht qualifizierter) für die meisten kommerziellen Verträge rechtlich gültig, etwa nach ESIGN (USA), UETA (USA) und eIDAS Artikel 25 Abs. 1 (EU).