Dokumenty techniczne

Niniejszy dokument techniczny opisuje architekturę systemu Bezpiecznego transferu PDF Pro, mechanizmu transferu plików z szyfrowaniem end-to-end, w którym pliki są szyfrowane po stronie klienta za pomocą AES-256-GCM przed przesłaniem. Serwer przechowuje tylko nieprzezroczysty zaszyfrowany tekst i nie ma możliwości odszyfrowania, sprawdzenia ani odczytania zawartości pliku w żadnym momencie. System obsługuje dwa tryby kluczy: automatycznie wygenerowany losowy klucz (przesyłany przez fragment URL, który nigdy nie jest wysyłany na serwer) lub klucz wyprowadzony z hasła za pomocą PBKDF2. W obu trybach klucz szyfrowania istnieje tylko w przeglądarkach nadawcy i odbiorcy. Niniejszy dokument szczegółowo opisuje prymitywy kryptograficzne, przepływ danych, model zagrożeń i uczciwe ograniczenia systemu. Uwaga dotycząca terminologii: ten system nie używa dowodów wiedzy zerowej (ZKP). Gdy mówimy, że serwer ma "zerową wiedzę" o Twoich plikach, mamy na myśli, że — w wyniku szyfrowania po stronie klienta — serwer zawsze przechowuje tylko zaszyfrowany tekst, którego nie może odszyfrować.

System Bezpiecznego transferu stosuje ścisłą separację klient-serwer, w której wszystkie operacje kryptograficzne odbywają się wyłącznie w przeglądarce:

• Klient (przeglądarka): Wyprowadzanie klucza, szyfrowanie, odszyfrowywanie, odczyt pliku, rekonstrukcja pliku.
• Serwer (Supabase Storage + funkcje serverless): Przechowuje zaszyfrowane bloby, zarządza metadanymi (wygaśnięcie, liczba pobrań), egzekwuje polityki dostępu.

Serwer jest celowo zaprojektowany jako "głupia rura" dla zaszyfrowanych danych. Nie ma wiedzy o kluczu szyfrowania, haśle ani zawartości pliku. Jest to egzekwowane architektonicznie, a nie tylko przez politykę.

Całe szyfrowanie plików wykorzystuje algorytm uwierzytelnionego szyfrowania AES-256-GCM, dostępny przez natywne Web Crypto API przeglądarki. Zapewnia to zarówno poufność (dane nie mogą być odczytane), jak i integralność (dane nie mogą zostać zmodyfikowane bez wykrycia).

1.3.1 Parametry algorytmu

1.3.2 Implementacja szyfrowania

// Uproszczony przepływ szyfrowania (Web Crypto API)

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

// Wyprowadź klucz z hasła (zobacz sekcję 1.4)
const key = await deriveKey(passphrase, salt);

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

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

Końcowy zaszyfrowany blob jest konkatenacją trzech komponentów: 16-bajtowej soli (używanej do wyprowadzania klucza), 12-bajtowego IV (używanego dla AES-GCM) oraz zaszyfrowanego tekstu z dołączonym 16-bajtowym tagiem uwierzytelniania GCM. Ten blob jest tym, co serwer otrzymuje i przechowuje.

Bezpieczny transfer obsługuje dwa wzajemnie wykluczające się tryby kluczy. Tryb jest wybierany przez nadawcę w momencie tworzenia transferu.

1.4.1 Tryb A — automatycznie wygenerowany klucz (domyślny)

W trybie domyślnym hasło nie jest zaangażowane. Przeglądarka generuje kryptograficznie losowy 256-bitowy klucz AES bezpośrednio:

• Przeglądarka generuje losowy 256-bitowy klucz AES-GCM przez crypto.getRandomValues() i crypto.subtle.generateKey().
• Klucz jest eksportowany jako surowe bajty i umieszczany we fragmencie URL (#).
• Zgodnie ze specyfikacją HTTP fragment URL nigdy nie jest wysyłany na serwer — jest przetwarzany wyłącznie przez przeglądarkę.
• Nadawca udostępnia pełny URL (w tym fragment) odbiorcy preferowanym kanałem (np. aplikacja do wiadomości, e-mail).
• Przeglądarka odbiorcy wyodrębnia klucz z fragmentu URL i używa go do odszyfrowania pliku.

1.4.2 Tryb B — transfer chroniony hasłem

Gdy nadawca zdecyduje się ustawić hasło, klucz jest wyprowadzany z tego hasła za pomocą PBKDF2:

• Użytkownik podaje hasło.
• Hasło jest używane do wyprowadzenia klucza AES-256 przez PBKDF2-SHA256.
• Parametry: 600 000 iteracji, losowa 16-bajtowa sól.
• Wyprowadzony klucz szyfruje plik.
• Sól jest przechowywana wraz z zaszyfrowanym tekstem (dołączona na początku zaszyfrowanego bloba).
• Hasło jest udostępniane poza pasmem (oddzielnie od linku).
• Odzyskiwanie hasła nie jest możliwe — ani serwer, ani PDF Pro nie mogą odzyskać zapomnianego hasła.

1.4.3 Parametry PBKDF2 (tryb B)

1.4.4 Implementacja wyprowadzania klucza (tryb B)

async function deriveKey(passphrase, salt) {
  // Importuj hasło jako surowy materiał klucza
  const keyMaterial = await crypto.subtle.importKey(
    "raw",
    new TextEncoder().encode(passphrase),
    { name: "PBKDF2" },
    false,
    ["deriveKey"]
  );

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

Pełen cykl życia bezpiecznego transferu przebiega następująco:

1.5.1 Wysyłanie (przesyłanie) — tryb A (automatycznie wygenerowany klucz)

1. Nadawca wybiera plik w przeglądarce.
2. Przeglądarka generuje losowy 256-bitowy klucz AES-GCM i losowy 12-bajtowy IV za pomocą crypto.getRandomValues().
3. Przeglądarka szyfruje plik za pomocą AES-256-GCM, tworząc zaszyfrowany tekst + tag uwierzytelniania.
4. Przeglądarka konkatenuje [IV | zaszyfrowany tekst+tag] w pojedynczy blob.
5. Przeglądarka przesyła zaszyfrowany blob na serwer przez HTTPS.
6. Serwer przechowuje blob w Supabase Storage i tworzy rekord metadanych (ID transferu, wygaśnięcie, limit pobrań, nazwa pliku, rozmiar pliku).
7. Serwer zwraca URL transferu. Przeglądarka dodaje wyeksportowany klucz do fragmentu URL (#).
8. Nadawca udostępnia pełny URL (z fragmentem) odbiorcy.

1.5.2 Wysyłanie (przesyłanie) — tryb B (hasło)

1. Nadawca wybiera plik i wprowadza hasło w przeglądarce.
2. Przeglądarka generuje losową 16-bajtową sól i 12-bajtowy IV za pomocą crypto.getRandomValues().
3. Przeglądarka wyprowadza klucz AES-256 z hasła za pomocą PBKDF2 (600 tys. iteracji).
4. Przeglądarka szyfruje plik za pomocą AES-256-GCM, tworząc zaszyfrowany tekst + tag uwierzytelniania.
5. Przeglądarka konkatenuje [sól | IV | zaszyfrowany tekst+tag] w pojedynczy blob.
6. Przeglądarka przesyła zaszyfrowany blob na serwer przez HTTPS.
7. Serwer przechowuje blob w Supabase Storage i tworzy rekord metadanych (ID transferu, wygaśnięcie, limit pobrań, nazwa pliku, rozmiar pliku).
8. Serwer zwraca URL transferu zawierający ID transferu.
9. Nadawca udostępnia URL transferu i hasło odbiorcy oddzielnymi kanałami.

1.5.3 Odbieranie (pobieranie) — tryb A

1. Odbiorca otwiera pełny URL transferu (z kluczem we fragmencie).
2. Przeglądarka wyodrębnia klucz AES z fragmentu URL (nigdy nie wysyłanego na serwer).
3. Przeglądarka pobiera zaszyfrowany blob z serwera przez HTTPS.
4. Przeglądarka wyodrębnia IV (pierwsze 12 bajtów) z bloba.
5. Przeglądarka odszyfrowuje zaszyfrowany tekst za pomocą AES-256-GCM z wyodrębnionym kluczem i IV.
6. Jeśli odszyfrowanie się powiedzie (tag GCM zwalidowany), plik tekstu jawnego jest prezentowany użytkownikowi.
7. Serwer aktualizuje licznik pobrań i, jeśli włączone jest spalanie po przeczytaniu, usuwa blob.

1.5.4 Odbieranie (pobieranie) — tryb B

1. Odbiorca otwiera URL transferu i wprowadza hasło w przeglądarce.
2. Przeglądarka pobiera zaszyfrowany blob z serwera przez HTTPS.
3. Przeglądarka wyodrębnia sól (pierwsze 16 bajtów) i IV (kolejne 12 bajtów) z bloba.
4. Przeglądarka wyprowadza klucz AES-256 z hasła + soli za pomocą PBKDF2 (600 tys. iteracji).
5. Przeglądarka odszyfrowuje zaszyfrowany tekst za pomocą AES-256-GCM z wyprowadzonym kluczem i IV.
6. Jeśli odszyfrowanie się powiedzie (tag GCM zwalidowany), plik tekstu jawnego jest prezentowany użytkownikowi.
7. Jeśli odszyfrowanie się nie powiedzie (złe hasło = zły klucz = nieprawidłowy tag GCM), wyświetlany jest błąd.
8. Serwer aktualizuje licznik pobrań i, jeśli włączone jest spalanie po przeczytaniu, usuwa blob.

Wszystkie bezpieczne transfery są efemeryczne z założenia. Nie ma opcji trwałego przechowywania.

1.7.1 Opcje wygaśnięcia

1.7.2 Gwarancja usunięcia

Gdy transfer wygasa lub jest spalany po przeczytaniu, zaszyfrowany blob jest trwale usuwany z Supabase Storage. Rekord metadanych jest zachowywany przez 30 dni w stanie miękkiego usunięcia (do badania nadużyć), zanim zostanie trwale wyczyszczony. Rekord metadanych nie zawiera klucza szyfrowania, hasła ani żadnych informacji, które mogłyby być użyte do zrekonstruowania pliku.

1.8.1 Założenia

• Zaufane środowisko wykonawcze przeglądarki (brak złośliwych rozszerzeń)
• Bezpieczny kanał do udostępniania linku/hasła
• Zakończenie HTTPS jest zaufane
• Urządzenie odbiorcy nie jest skompromitowane
• Brak zapobiegania przechwytywaniu ekranu

1.8.2 Poza zakresem

• Złośliwe oprogramowanie na urządzeniach końcowych
• Inżynieria społeczna / ataki phishingowe
• Przechwytywanie ekranu przez odbiorców
• Skompromitowane rozszerzenia przeglądarki
• Ataki obliczeń kwantowych (kwestia przyszła)

• Siła hasła jest kontrolowana przez użytkownika. Możemy egzekwować minimalną długość w UI, ale nie możemy zapobiec wybieraniu przez użytkowników słabych haseł. Bezpieczeństwo szyfrowania jest wprost proporcjonalne do entropii hasła.
• Transmisja hasła jest poza pasmem. Nie zapewniamy bezpiecznego kanału do udostępniania hasła. Jeśli hasło jest udostępniane niezabezpieczonym kanałem (np. niezaszyfrowany e-mail wraz z URL transferu), model bezpieczeństwa jest osłabiony.
• Metadane pliku nie są szyfrowane. Oryginalna nazwa pliku i rozmiar pliku są przechowywane w postaci jawnej na serwerze. To ujawnia typ i przybliżoną naturę przesyłanego pliku, mimo że jego zawartość pozostaje zaszyfrowana.
• Zaufanie do kodu po stronie klienta. Użytkownicy muszą ufać, że JavaScript dostarczany przez nasz CDN to poprawny, niezmodyfikowany kod. Skompromitowany CDN lub przejęcie DNS mogłoby dostarczyć złośliwy JavaScript. To fundamentalne ograniczenie wszystkich kryptografii opartych na sieci.
• Brak forward secrecy. Jeśli hasło zostanie skompromitowane w dowolnym momencie przed usunięciem zaszyfrowanego bloba, przechowywaną kopię bloba można odszyfrować. Spalanie po przeczytaniu i krótkie czasy wygaśnięcia łagodzą to.
• Zależność od modelu bezpieczeństwa przeglądarki. Bezpieczeństwo systemu zależy od implementacji Web Crypto API przez przeglądarkę i jej izolacji pamięci. Skompromitowana przeglądarka lub złośliwe rozszerzenie przeglądarki mogłoby podważyć wszystkie ochrony po stronie klienta.
• Obliczenia kwantowe. AES-256 jest uważane za odporne na ataki kwantowe (algorytm Grovera redukuje efektywne bezpieczeństwo do 128 bitów, co pozostaje niewykonalne). Jednak PBKDF2 z SHA-256 nie jest specjalnie zaprojektowane pod kątem odporności postkwantowej. To nie jest problem krótkoterminowy, ale jest odnotowywany dla kompletności.

Niniejszy dokument techniczny opisuje architekturę systemu Podpisu prywatności PDF Pro, kryptograficznego mechanizmu podpisywania dokumentów, w którym dokument PDF nigdy nie opuszcza przeglądarki podpisującego. System wykorzystuje ECDSA z krzywą P-256 i hashowanie SHA-256 do wytwarzania oddzielonych podpisów cyfrowych. Tylko hash dokumentu, podpis kryptograficzny i klucz publiczny są przesyłane na serwer. Klucze prywatne są generowane, szyfrowane i przechowywane wyłącznie w przeglądarce użytkownika za pomocą IndexedDB, chronione przez wyprowadzanie klucza PBKDF2 (600 000 iteracji) i szyfrowanie AES-256-GCM. Niniejszy dokument szczegółowo opisuje pełną architekturę podpisywania i weryfikacji, model zarządzania kluczami, schemat podpisanego ładunku, projekt śladu audytu, model zagrożeń i uczciwe ograniczenia.

System Podpisu prywatności jest zaprojektowany wokół fundamentalnego ograniczenia: dokument PDF nigdy nie może być przesłany na serwer. Jest to egzekwowane architektonicznie przez model oddzielonego podpisu.

• Klient (przeglądarka): Generowanie kluczy, przechowywanie kluczy (zaszyfrowanych w IndexedDB), hashowanie dokumentu (SHA-256), generowanie podpisu (ECDSA P-256), weryfikacja podpisu.
• Serwer (Supabase): Przechowuje klucze publiczne, zapisy podpisów (hash + podpis + metadane), zdarzenia śladu audytu. Nigdy nie otrzymuje dokumentu PDF, kluczy prywatnych ani haseł kluczy.

2.3.1 Parametry algorytmu

2.3.2 Przepływ podpisywania

// 1. Hashuj dokument PDF (po stronie klienta)
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. Podpisz hash kluczem prywatnym (po stronie klienta)
const signature = await crypto.subtle.sign(
  { name: "ECDSA", hash: "SHA-256" },
  privateKey,   // CryptoKey z IndexedDB (odszyfrowany)
  hashBuffer
);

// 3. Wyślij na serwer: hash + podpis + klucz publiczny (NIE PDF)
await submitSignature({
  documentHash: hashHex,
  signature: base64Encode(signature),
  publicKey: exportedPublicKeyJWK
});

2.4.1 Generowanie kluczy

// Generuj parę kluczy ECDSA P-256 (Web Crypto API)
const keyPair = await crypto.subtle.generateKey(
  {
    name: "ECDSA",
    namedCurve: "P-256"
  },
  true,   // ekstraktowalny (potrzebny do szyfrowania + przechowywania)
  ["sign", "verify"]
);

// Eksportuj klucz publiczny jako JWK do rejestracji na serwerze
const publicKeyJWK = await crypto.subtle.exportKey("jwk", keyPair.publicKey);

// Eksportuj klucz prywatny jako JWK do zaszyfrowanego przechowywania
const privateKeyJWK = await crypto.subtle.exportKey("jwk", keyPair.privateKey);

Trwałe klucze prywatne nigdy nie są przechowywane w postaci jawnej. Przed zapisaniem w IndexedDB klucz prywatny (eksportowany jako JWK JSON) jest szyfrowany przy użyciu tego samego wzorca co Bezpieczny transfer:

2.5.1 Parametry ochrony

2.5.2 Schemat przechowywania

// Struktura rekordu IndexedDB dla zaszyfrowanego klucza podpisywania
{
  "keyId":       "uuid-v4-unikalny-identyfikator",
  "publicKey":   { /* format JWK, niezaszyfrowany */ },
  "encryptedPrivateKey": {
    "salt":       "base64-zakodowane-16-bajtów",
    "iv":         "base64-zakodowane-12-bajtów",
    "ciphertext": "base64-zakodowany-zaszyfrowany-tekst-aes-gcm"
  },
  "algorithm":   "ECDSA",
  "curve":       "P-256",
  "createdAt":   "2026-04-16T00:00:00.000Z",
  "userId":      "id-uzytkownika-supabase-auth"
}

PDF Pro używa modelu oddzielonego podpisu, co oznacza, że podpis jest przechowywany oddzielnie od dokumentu. To krytyczny mechanizm prywatności: dokument nigdy nie opuszcza urządzenia podpisującego.

2.6.1 Co jest wysyłane na serwer

• Hash SHA-256 PDF (32 bajty, kodowane hex do 64 znaków).
• Podpis ECDSA hasha (64 bajty, kodowane base64).
• Klucz publiczny podpisującego (format JWK).
• Metadane: nazwa wyświetlana podpisującego, e-mail podpisującego (jeśli uwierzytelniony), znacznik czasu, ID podpisu.

2.6.2 Czego NIE wysyła się na serwer

• Sam dokument PDF — nigdy nie przesyłany.
• Klucz prywatny — nigdy nie opuszcza przeglądarki.
• Hasło do podpisywania — nigdy nie opuszcza przeglądarki.
• Wszelka zawartość strony, tekst lub obrazy z PDF.

Następujący schemat JSON definiuje pełen rekord podpisu przechowywany na serwerze:

{
  "schemaVersion":  "1.0",
  "signatureId":    "uuid-v4",
  "documentHash":   "sha256-hex-64-znaków",
  "hashAlgorithm":  "SHA-256",
  "signature":      "base64-zakodowany-podpis-ecdsa",
  "signatureAlgorithm": "ECDSA",
  "curve":          "P-256",
  "publicKey": {
    "kty": "EC",
    "crv": "P-256",
    "x":   "base64url-zakodowana-współrzędna-x",
    "y":   "base64url-zakodowana-współrzędna-y"
  },
  "signer": {
    "identityLevel": "authenticated | self-asserted",
    "displayName":   "ciąg lub null",
    "email":         "ciąg lub null",
    "userId":        "supabase-uid lub null"
  },
  "timestamp":      "ISO-8601-UTC",
  "metadata": {
    "fileName":     "oryginalna-nazwa-pliku.pdf",
    "fileSize":     123456,
    "pageCount":    12,
    "clientVersion": "2.0.0",
    "userAgent":    "ciąg-user-agent-przeglądarki"
  },
  "auditChain": {
    "previousEventHash": "sha256-poprzedniego-zdarzenia-audytu lub null",
    "eventHash":         "sha256-tego-rekordu"
  }
}

Weryfikacja podpisu to dwufazowy proces: kryptograficzna weryfikacja po stronie klienta, po której następuje weryfikacja krzyżowa po stronie serwera.

2.8.1 Faza 1: Kryptograficzna weryfikacja po stronie klienta

1. Użytkownik wczytuje PDF do przeglądarki.
2. Przeglądarka oblicza hash SHA-256 wczytanego PDF.
3. Przeglądarka pyta serwer o wszelkie zapisy podpisów pasujące do tego hasha.
4. Dla każdego zwróconego zapisu podpisu przeglądarka wykonuje weryfikację ECDSA:

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

5. Jeśli isValid === true, podpis jest kryptograficznie ważny: dokument nie został zmodyfikowany od podpisania, a podpis został wykonany przez posiadacza odpowiedniego klucza prywatnego.

2.8.2 Faza 2: Weryfikacja krzyżowa po stronie serwera

1. Serwer potwierdza, że klucz publiczny w zapisie podpisu jest zarejestrowany dla znanego użytkownika (dla podpisów uwierzytelnionych).
2. Serwer potwierdza, że zapis podpisu nie został odwołany.
3. Serwer potwierdza integralność śladu audytu (walidacja łańcucha hashy).
4. Serwer zwraca poziom tożsamości i status rejestracji podpisującego.

2.8.3 Wyniki weryfikacji

Każde zdarzenie podpisywania i weryfikacji jest rejestrowane w odpornym na manipulacje śladzie audytu. Zdarzenia są łączone hashami: każde zdarzenie zawiera hash SHA-256 poprzedniego zdarzenia, tworząc łańcuch tylko do dodawania podobny do blockchaina.

2.9.1 Typy zdarzeń audytu

2.9.2 Struktura łańcucha hashy

// Każde zdarzenie audytu zawiera:
{
  "eventId":            "uuid-v4",
  "eventType":          "DOCUMENT_SIGNED",
  "timestamp":          "ISO-8601-UTC",
  "data":               { /* ładunek specyficzny dla zdarzenia */ },
  "previousEventHash": "sha256-poprzedniego-zdarzenia-json",
  "eventHash":          "sha256-tego-zdarzenia-json-bez-eventHash"
}

// Wykrywanie manipulacji: aby zweryfikować łańcuch, oblicz:
// SHA-256(JSON.stringify(zdarzenie bez pola eventHash))
// i potwierdź, że pasuje do eventHash.
// Następnie potwierdź, że previousEventHash pasuje do eventHash poprzedniego zdarzenia.

Jeśli jakiekolwiek zdarzenie w łańcuchu zostanie zmodyfikowane, wszystkie kolejne ogniwa hashy zostaną przerwane, czyniąc manipulację natychmiast wykrywalną. Zapewnia to silną gwarancję integralności śladu audytu.

Uwaga: W UI produktu "self_asserted" może być wyświetlane jako "Tożsamość samodzielnie zadeklarowana" lub "Podpisywanie gościa". "authenticated" może być wyświetlane jako "Uwierzytelnione konto". Są to etykiety wyświetlania tych samych poziomów tożsamości.

2.11.1 Założenia

• Zaufane środowisko wykonawcze przeglądarki
• Implementacja Web Crypto API jest poprawna
• IndexedDB nie jest dostępne dla innych źródeł
• Użytkownik chroni swoje hasło
• Kod serwera odpowiada opublikowanemu zachowaniu

2.11.2 Poza zakresem

• Złośliwe oprogramowanie na urządzeniach końcowych
• Inżynieria społeczna / ataki phishingowe
• Przechwytywanie ekranu przez odbiorców
• Skompromitowane rozszerzenia przeglądarki
• Ataki obliczeń kwantowych (kwestia przyszła)

• Nie są kwalifikowanym podpisem elektronicznym (QES). Podpisy PDF Pro nie spełniają wymagań rozporządzenia UE 910/2014 (eIDAS) dla kwalifikowanych podpisów elektronicznych. Nie jesteśmy kwalifikowanym dostawcą usług zaufania (QTSP), a nasze klucze podpisywania nie są generowane na kwalifikowanym urządzeniu do składania podpisu (QSCD).
• Nie są zgodne z eIDAS. Zgodnie z eIDAS, tylko kwalifikowane podpisy elektroniczne mają prawny odpowiednik podpisów odręcznych we wszystkich państwach członkowskich UE. Podpisy PDF Pro są w najlepszym razie zaawansowanymi podpisami elektronicznymi, a ich status prawny zależy od konkretnej jurysdykcji i przypadku użycia.
• Nie są zaufane przez Adobe. Podpisy PDF Pro nie pojawiają się na Adobe Approved Trust List (AATL). Podczas otwierania dokumentu podpisanego przez PDF Pro w Adobe Acrobat, podpis nie pojawi się jako "zaufany" w UI Adobe. Weryfikacja musi być wykonana przez system weryfikacji PDF Pro.
• Nie jesteśmy urzędem certyfikacji. Nie wydajemy certyfikatów X.509. Nasza infrastruktura kluczy publicznych jest zastrzeżona dla PDF Pro i nie jest interoperacyjna z systemami PKI, takimi jak te używane przez agencje rządowe lub urzędy certyfikacji.
• Nie jest to notarializacja. Podpisy PDF Pro nie stanowią notarializacji, apostille ani żadnej formy uwierzytelniania dokumentów potwierdzonego przez rząd.
• Brak weryfikacji tożsamości w świecie rzeczywistym. Weryfikujemy adresy e-mail przez Supabase Auth, ale nie wykonujemy weryfikacji dokumentów tożsamości wydanych przez rząd, weryfikacji biometrycznej ani weryfikacji tożsamości osobistej.

2.12.1 Do czego podpisy PDF Pro są odpowiednie

• Workflow biznesowe — Wewnętrzne zatwierdzenia dokumentów, akceptacje zespołowe, autoryzacje zaopatrzeniowe, gdzie strony ufają modelowi tożsamości PDF Pro.
• Weryfikacja integralności — Udowodnienie, że dokument nie został zmodyfikowany od określonego momentu w czasie.
• Niezaprzeczalność (ograniczona) — Wykazanie, że posiadacz konkretnego klucza prywatnego podpisał konkretny dokument w konkretnym czasie. Siła niezaprzeczalności zależy od tego, jak dobrze klucz prywatny jest chroniony i jak klucz publiczny jest powiązany z tożsamością.
• Zgodność audytowa — Zapewnienie odpornego na manipulacje śladu audytu zdarzeń podpisywania dokumentów dla wewnętrznych wymagań zgodności.
• Podpisywanie umów — W wielu jurysdykcjach podpisy elektroniczne (w tym niekwalifikowane) są prawnie ważne dla większości umów handlowych zgodnie z prawami takimi jak ESIGN (USA), UETA (USA) i eIDAS Artykuł 25(1) (UE).