Technical Технические документы

В этом техническом документе описана архитектура системы безопасной передачи PDF Pro — механизма передачи файлов со сквозным шифрованием, при котором файлы шифруются на стороне клиента с помощью AES-256-GCM до загрузки. Сервер хранит только непрозрачный шифротекст и ни в какой момент не имеет возможности расшифровать, осмотреть или прочитать содержимое файлов. Система поддерживает два режима ключей: автоматически сгенерированный случайный ключ (передаваемый через URL-фрагмент, который никогда не отправляется на сервер) или ключ, производный от парольной фразы с использованием PBKDF2. В обоих режимах ключ шифрования существует только в браузерах отправителя и получателя. В этом документе детально описаны криптографические примитивы, поток данных, модель угроз и честно раскрытые ограничения системы. Замечание о терминологии: система не использует доказательства с нулевым разглашением (ZKP). Когда мы говорим, что сервер обладает «нулевым знанием» о ваших файлах, мы имеем в виду, что — как следствие шифрования на стороне клиента — сервер всегда хранит только шифротекст, который не может расшифровать.

Система безопасной передачи следует строгому разделению клиента и сервера, при котором все криптографические операции выполняются исключительно в браузере:

• Клиент (браузер): деривация ключа, шифрование, расшифрование, чтение файла, восстановление файла.
• Сервер (Supabase Storage + бессерверные функции): хранит зашифрованные blob-объекты, управляет метаданными (срок действия, счётчик загрузок), применяет политики доступа.

Сервер намеренно спроектирован как «тупой канал» для зашифрованных данных. Он не имеет сведений о ключе шифрования, парольной фразе или содержимом файла. Это обеспечивается архитектурно, а не только политикой.

Всё шифрование файлов использует алгоритм аутентифицированного шифрования AES-256-GCM, доступный через нативный Web Crypto API браузера. Это обеспечивает как конфиденциальность (данные невозможно прочитать), так и целостность (данные невозможно изменить незаметно).

1.3.1 Параметры алгоритма

1.3.2 Реализация шифрования

// Упрощённый поток шифрования (Web Crypto API)

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

// Производный ключ из парольной фразы (см. Раздел 1.4)
const key = await deriveKey(passphrase, salt);

// Шифрование файла
const ciphertext = await crypto.subtle.encrypt(
  { name: "AES-GCM", iv: iv },
  key,
  fileArrayBuffer
);

// Пакет: [salt (16Б)] + [iv (12Б)] + [ciphertext + tag]
const blob = concatenate(salt, iv, ciphertext);

Итоговый зашифрованный blob представляет собой объединение трёх компонентов: 16-байтовой соли (используемой для деривации ключа), 12-байтового IV (используемого для AES-GCM) и шифротекста с присоединённым 16-байтовым тегом аутентификации GCM. Именно этот blob получает и хранит сервер.

Безопасная передача поддерживает два взаимоисключающих режима ключей. Режим выбирается отправителем в момент создания передачи.

1.4.1 Режим A — автоматически сгенерированный ключ (по умолчанию)

В режиме по умолчанию парольная фраза не используется. Браузер напрямую генерирует криптографически случайный 256-битный ключ AES:

• Браузер генерирует случайный 256-битный ключ AES-GCM через crypto.getRandomValues() и crypto.subtle.generateKey().
• Ключ экспортируется в виде сырых байтов и помещается в URL-фрагмент (#).
• Согласно спецификации HTTP, URL-фрагмент никогда не отправляется на сервер — он обрабатывается исключительно браузером.
• Отправитель делится с получателем полным URL (включая фрагмент) через предпочитаемый канал (например, мессенджер, email).
• Браузер получателя извлекает ключ из URL-фрагмента и использует его для расшифрования файла.

1.4.2 Режим B — передача с парольной фразой

Когда отправитель решает задать парольную фразу, ключ выводится из этой парольной фразы с помощью PBKDF2:

• Пользователь предоставляет парольную фразу.
• Из парольной фразы выводится ключ AES-256 через PBKDF2-SHA256.
• Параметры: 600 000 итераций, случайная 16-байтовая соль.
• Производный ключ шифрует файл.
• Соль хранится вместе с шифротекстом (добавлена в начало зашифрованного blob-объекта).
• Парольная фраза передаётся внеполосно (отдельно от ссылки).
• Восстановление парольной фразы невозможно — ни сервер, ни PDF Pro не могут восстановить забытую парольную фразу.

1.4.3 Параметры PBKDF2 (режим B)

1.4.4 Реализация деривации ключа (режим B)

async function deriveKey(passphrase, salt) {
  // Импорт парольной фразы как сырого материала ключа
  const keyMaterial = await crypto.subtle.importKey(
    "raw",
    new TextEncoder().encode(passphrase),
    { name: "PBKDF2" },
    false,
    ["deriveKey"]
  );

  // Деривация ключа 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"]
  );
}

Полный жизненный цикл безопасной передачи следует следующему пути:

1.5.1 Отправка (загрузка) — режим A (автоматически сгенерированный ключ)

1. Отправитель выбирает файл в браузере.
2. Браузер генерирует случайный 256-битный ключ AES-GCM и случайный 12-байтовый IV с помощью crypto.getRandomValues().
3. Браузер шифрует файл с помощью AES-256-GCM, получая шифротекст и тег аутентификации.
4. Браузер объединяет [IV | шифротекст+тег] в единый blob.
5. Браузер загружает зашифрованный blob на сервер по HTTPS.
6. Сервер сохраняет blob в Supabase Storage и создаёт запись метаданных (идентификатор передачи, срок действия, лимит загрузок, имя файла, размер файла).
7. Сервер возвращает URL передачи. Браузер добавляет экспортированный ключ в URL-фрагмент (#).
8. Отправитель делится с получателем полным URL (с фрагментом).

1.5.2 Отправка (загрузка) — режим B (парольная фраза)

1. Отправитель выбирает файл и вводит парольную фразу в браузере.
2. Браузер генерирует случайную 16-байтовую соль и 12-байтовый IV с помощью crypto.getRandomValues().
3. Браузер выводит ключ AES-256 из парольной фразы с помощью PBKDF2 (600 тыс. итераций).
4. Браузер шифрует файл с помощью AES-256-GCM, получая шифротекст и тег аутентификации.
5. Браузер объединяет [соль | IV | шифротекст+тег] в единый blob.
6. Браузер загружает зашифрованный blob на сервер по HTTPS.
7. Сервер сохраняет blob в Supabase Storage и создаёт запись метаданных (идентификатор передачи, срок действия, лимит загрузок, имя файла, размер файла).
8. Сервер возвращает URL передачи, содержащий идентификатор передачи.
9. Отправитель передаёт URL передачи и парольную фразу получателю по разным каналам.

1.5.3 Получение (скачивание) — режим A

1. Получатель открывает полный URL передачи (с ключом во фрагменте).
2. Браузер извлекает ключ AES из URL-фрагмента (никогда не отправляется на сервер).
3. Браузер скачивает зашифрованный blob с сервера по HTTPS.
4. Браузер извлекает IV (первые 12 байт) из blob-объекта.
5. Браузер расшифровывает шифротекст с помощью AES-256-GCM, используя извлечённые ключ и IV.
6. Если расшифрование успешно (тег GCM валиден), пользователю предоставляется файл в открытом виде.
7. Сервер обновляет счётчик загрузок и, если включён режим самоуничтожения после прочтения, удаляет blob.

1.5.4 Получение (скачивание) — режим B

1. Получатель открывает URL передачи и вводит парольную фразу в браузере.
2. Браузер скачивает зашифрованный blob с сервера по HTTPS.
3. Браузер извлекает соль (первые 16 байт) и IV (следующие 12 байт) из blob-объекта.
4. Браузер выводит ключ AES-256 из парольной фразы и соли с помощью PBKDF2 (600 тыс. итераций).
5. Браузер расшифровывает шифротекст с помощью AES-256-GCM, используя производный ключ и IV.
6. Если расшифрование успешно (тег GCM валиден), пользователю предоставляется файл в открытом виде.
7. Если расшифрование не удалось (неверная парольная фраза = неверный ключ = невалидный тег GCM), показывается ошибка.
8. Сервер обновляет счётчик загрузок и, если включён режим самоуничтожения после прочтения, удаляет blob.

Все безопасные передачи эфемерны по своему замыслу. Опция постоянного хранения отсутствует.

1.7.1 Параметры срока действия

1.7.2 Гарантия удаления

Когда передача истекает или уничтожается после прочтения, зашифрованный blob окончательно удаляется из Supabase Storage. Запись метаданных сохраняется в течение 30 дней в состоянии «мягкого удаления» (для расследования злоупотреблений), после чего окончательно удаляется. Запись метаданных не содержит ключа шифрования, парольной фразы или какой-либо информации, которую можно было бы использовать для восстановления файла.

1.8.1 Допущения

• Доверенная среда выполнения браузера (без вредоносных расширений)
• Безопасный канал для передачи ссылки/парольной фразы
• Терминация HTTPS является доверенной
• Устройство получателя не скомпрометировано
• Защита от захвата экрана не предусмотрена

1.8.2 Вне области действия

• Вредоносное ПО на конечных устройствах
• Социальная инженерия / фишинговые атаки
• Захват экрана получателями
• Скомпрометированные расширения браузера
• Атаки с использованием квантовых вычислений (рассмотрение в будущем)

• Надёжность парольной фразы контролируется пользователем. Мы можем требовать минимальную длину в интерфейсе, но не можем помешать пользователям выбирать слабые парольные фразы. Безопасность шифрования прямо пропорциональна энтропии парольной фразы.
• Передача парольной фразы внеполосна. Мы не предоставляем безопасный канал для передачи парольной фразы. Если парольная фраза передаётся по небезопасному каналу (например, по незашифрованному email вместе с URL передачи), модель безопасности ослабляется.
• Метаданные файла не шифруются. Исходное имя и размер файла хранятся на сервере в открытом виде. Это раскрывает тип и приблизительную природу передаваемого файла, хотя его содержимое остаётся зашифрованным.
• Доверие к клиентскому коду. Пользователи должны доверять тому, что JavaScript, доставляемый нашим CDN, является корректным, неизменённым кодом. Скомпрометированный CDN или захват DNS может привести к доставке вредоносного JavaScript. Это фундаментальное ограничение всей веб-криптографии.
• Отсутствие прямой секретности. Если парольная фраза скомпрометирована в любой момент до удаления зашифрованного blob-объекта, сохранённая копия blob-объекта может быть расшифрована. Самоуничтожение после прочтения и короткие сроки действия смягчают этот риск.
• Зависимость от модели безопасности браузера. Безопасность системы зависит от реализации браузером Web Crypto API и изоляции памяти. Скомпрометированный браузер или вредоносное расширение могут подорвать все защиты на стороне клиента.
• Квантовые вычисления. AES-256 считается устойчивым к квантовым атакам (алгоритм Гровера снижает эффективную безопасность до 128 бит, что остаётся вычислительно невозможным). Однако PBKDF2 с SHA-256 не разработан специально для постквантовой устойчивости. Это не близкая по времени проблема, но отмечается для полноты.

В этом техническом документе описана архитектура системы приватной подписи от PDF Pro — механизма криптографической подписи документов, при котором PDF-документ никогда не покидает браузер подписанта. Система использует ECDSA с кривой P-256 и хеширование SHA-256 для создания отделённых цифровых подписей. На сервер передаются только хеш документа, криптографическая подпись и публичный ключ. Приватные ключи генерируются, шифруются и хранятся исключительно в браузере пользователя в IndexedDB, защищённом деривацией ключа PBKDF2 (600 000 итераций) и шифрованием AES-256-GCM. В этом документе детально описаны полная архитектура подписания и проверки, модель управления ключами, схема подписанной полезной нагрузки, дизайн аудиторского следа, модель угроз и честно раскрытые ограничения.

Система приватной подписи спроектирована вокруг фундаментального ограничения: PDF-документ никогда не должен передаваться на сервер. Это обеспечивается архитектурно через модель отделённой подписи.

• Клиент (браузер): генерация ключей, хранение ключей (зашифрованных в IndexedDB), хеширование документа (SHA-256), создание подписи (ECDSA P-256), проверка подписи.
• Сервер (Supabase): хранит публичные ключи, записи подписей (хеш + подпись + метаданные), события аудиторского следа. Никогда не получает PDF-документ, приватные ключи или парольные фразы ключей.

2.3.1 Параметры алгоритма

2.3.2 Поток подписания

// 1. Хеширование PDF-документа (на стороне клиента)
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. Подписание хеша приватным ключом (на стороне клиента)
const signature = await crypto.subtle.sign(
  { name: "ECDSA", hash: "SHA-256" },
  privateKey,   // CryptoKey из IndexedDB (расшифрованный)
  hashBuffer
);

// 3. Отправка на сервер: хеш + подпись + публичный ключ (НЕ сам PDF)
await submitSignature({
  documentHash: hashHex,
  signature: base64Encode(signature),
  publicKey: exportedPublicKeyJWK
});

2.4.1 Генерация ключа

// Генерация пары ключей ECDSA P-256 (Web Crypto API)
const keyPair = await crypto.subtle.generateKey(
  {
    name: "ECDSA",
    namedCurve: "P-256"
  },
  true,   // extractable (нужно для шифрования + хранения)
  ["sign", "verify"]
);

// Экспорт публичного ключа в формате JWK для регистрации на сервере
const publicKeyJWK = await crypto.subtle.exportKey("jwk", keyPair.publicKey);

// Экспорт приватного ключа в формате JWK для зашифрованного хранения
const privateKeyJWK = await crypto.subtle.exportKey("jwk", keyPair.privateKey);

Постоянные приватные ключи никогда не хранятся в открытом виде. Перед записью в IndexedDB приватный ключ (экспортированный в виде JWK JSON) шифруется по той же схеме, что и в системе безопасной передачи:

2.5.1 Параметры защиты

2.5.2 Схема хранения

// Структура записи IndexedDB для зашифрованного ключа подписи
{
  "keyId":       "uuid-v4-unique-identifier",
  "publicKey":   { /* формат JWK, незашифрованный */ },
  "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 использует модель отделённой подписи, что означает, что подпись хранится отдельно от документа. Это ключевой механизм конфиденциальности: документ никогда не покидает устройство подписанта.

2.6.1 Что отправляется на сервер

• SHA-256 хеш PDF (32 байта, в hex-кодировке — 64 символа).
• Подпись ECDSA по хешу (64 байта, в base64-кодировке).
• Публичный ключ подписанта (формат JWK).
• Метаданные: отображаемое имя подписанта, email подписанта (если авторизован), временная метка, идентификатор подписи.

2.6.2 Что НЕ отправляется на сервер

• Сам PDF-документ — никогда не передаётся.
• Приватный ключ — никогда не покидает браузер.
• Парольная фраза для подписи — никогда не покидает браузер.
• Любое содержимое страниц, текст или изображения из PDF.

Следующая JSON-схема определяет полную запись подписи, хранимую на сервере:

{
  "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"
  }
}

Проверка подписи — двухэтапный процесс: криптографическая проверка на стороне клиента с последующей серверной перекрёстной сверкой.

2.8.1 Этап 1: криптографическая проверка на стороне клиента

1. Пользователь загружает PDF в браузер.
2. Браузер вычисляет хеш SHA-256 загруженного PDF.
3. Браузер запрашивает у сервера любые записи подписей, соответствующие этому хешу.
4. Для каждой возвращённой записи подписи браузер выполняет проверку ECDSA:

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

5. Если isValid === true, подпись криптографически действительна: документ не был изменён с момента подписания, и подпись создана владельцем соответствующего приватного ключа.

2.8.2 Этап 2: серверная перекрёстная сверка

1. Сервер подтверждает, что публичный ключ в записи подписи зарегистрирован за известным пользователем (для авторизованных подписей).
2. Сервер подтверждает, что запись подписи не была отозвана.
3. Сервер подтверждает целостность аудиторского следа (валидация хеш-цепочки).
4. Сервер возвращает уровень идентификации подписанта и статус регистрации.

2.8.3 Результаты проверки

Каждое событие подписания и проверки регистрируется в аудиторском следе с защитой от подделки. События связаны хеш-цепочкой: каждое событие содержит хеш SHA-256 предыдущего события, образуя цепочку только для добавления, аналогичную блокчейну.

2.9.1 Типы событий аудита

2.9.2 Структура хеш-цепочки

// Каждое событие аудита включает:
{
  "eventId":            "uuid-v4",
  "eventType":          "DOCUMENT_SIGNED",
  "timestamp":          "ISO-8601-UTC",
  "data":               { /* полезная нагрузка, специфичная для события */ },
  "previousEventHash": "sha256-of-previous-event-json",
  "eventHash":          "sha256-of-this-event-json-without-eventHash"
}

// Обнаружение подделки: для проверки цепочки вычислите:
// SHA-256(JSON.stringify(событие без поля eventHash))
// и убедитесь, что значение совпадает с eventHash.
// Затем убедитесь, что previousEventHash совпадает с eventHash предыдущего события.

Если какое-либо событие в цепочке изменено, все последующие хеш-связи нарушатся, что делает подделку сразу обнаруживаемой. Это обеспечивает надёжную гарантию целостности аудиторского следа.

Замечание: в интерфейсе продукта «self_asserted» может отображаться как «Самозаявленная идентичность» или «Гостевое подписание». «authenticated» может отображаться как «Авторизованный аккаунт». Это отображаемые метки для одних и тех же базовых уровней идентификации.

2.11.1 Допущения

• Доверенная среда выполнения браузера
• Корректная реализация Web Crypto API
• IndexedDB недоступен другим источникам
• Пользователь защищает свою парольную фразу
• Серверный код соответствует опубликованному поведению

2.11.2 Вне области действия

• Вредоносное ПО на конечных устройствах
• Социальная инженерия / фишинговые атаки
• Захват экрана получателями
• Скомпрометированные расширения браузера
• Атаки с использованием квантовых вычислений (рассмотрение в будущем)

• Не являются квалифицированной электронной подписью (QES). Подписи PDF Pro не соответствуют требованиям регламента ЕС 910/2014 (eIDAS) для квалифицированных электронных подписей. Мы не являемся квалифицированным поставщиком доверительных услуг (QTSP), и наши ключи подписи не генерируются на квалифицированном устройстве для создания подписей (QSCD).
• Не являются квалифицированными по eIDAS. По eIDAS только квалифицированные электронные подписи имеюридический эквивалент собственноручным подписям во всех странах-членах ЕС. Подписи PDF Pro в лучшем случае являются усиленными электронными подписями, и их юридический статус зависит от конкретной юрисдикции и сценария использования.
• Не являются доверенными в Adobe. Подписи PDF Pro не входят в список Adobe Approved Trust List (AATL). При открытии документа, подписанного PDF Pro, в Adobe Acrobat подпись не будет отображаться как «доверенная» в интерфейсе Adobe. Проверка должна выполняться через систему проверки PDF Pro.
• Не являются удостоверяющим центром. Мы не выпускаем сертификаты X.509. Наша инфраструктура открытых ключей является собственной разработкой PDF Pro и несовместима с PKI-системами, такими как те, что используются государственными органами или удостоверяющими центрами.
• Не являются нотариальным заверением. Подписи PDF Pro не являются нотариальным заверением, апостилем или какой-либо формой государственно-сертифицированной аутентификации документов.
• Без проверки реальной идентичности. Мы проверяем адреса электронной почты через Supabase Auth, но не выполняем проверку государственных документов, биометрическую проверку или личное подтверждение идентичности.

2.12.1 Для чего подписи PDF Pro ПОДХОДЯТ

• Бизнес-процессы — внутренние согласования документов, командные подтверждения, авторизация закупок, где стороны доверяют модели идентификации PDF Pro.
• Проверка целостности — подтверждение того, что документ не был изменён с определённого момента времени.
• Невозможность отказа от авторства (ограниченная) — демонстрация того, что владелец конкретного приватного ключа подписал конкретный документ в конкретное время. Надёжность невозможности отказа зависит от того, насколько хорошо защищён приватный ключ и как публичный ключ привязан к идентичности.
• Аудиторское соответствие — предоставление защищённого от подделки аудиторского следа событий подписания документов для требований внутреннего соответствия.
• Подписание договоров — во многих юрисдикциях электронные подписи (включая неквалифицированные) юридически действительны для большинства коммерческих договоров согласно таким законам, как ESIGN (США), UETA (США) и статья 25(1) eIDAS (ЕС).