Обновлено:

Безопасность zero-knowledge — как это работает на самом деле.

Как Worklist защищает ваши данные сквозным шифрованием и почему даже мы не видим, над чем вы работаете.

Кратко

Worklist использует шифрование ChaCha20-Poly1305 и архитектуру zero-knowledge. Данные шифруются на вашем устройстве криптографией военного уровня ещё до отправки на серверы. Даже с полным доступом к базе данных мы физически не можем читать ваши задачи. Архитектура поддерживает минимизацию данных по GDPR и может помочь с техническими мерами HIPAA/SOC 2 при наличии необходимых соглашений и операционных контролей.

Наш базовый принцип.

Ваши данные шифруются на устройстве ещё до того, как достигнут наших серверов. Мы спроектировали Worklist так, чтобы мы — компания — не могли расшифровывать, читать или получать доступ к вашим рабочим спискам, задачам и комментариям. Это и есть архитектура zero-knowledge.

Чем Worklist отличается.

Обычные таск-менеджеры.

Как работают конкуренты

  • Хранят данные в открытом виде на своих серверах
  • Могут читать каждую задачу, комментарий и файл
  • Могут сканировать содержимое для рекламы, обучения ИИ или «функций»
  • Уязвимы для утечек, раскрывающих всё

Worklist (zero-knowledge).

Как работаем мы

  • Шифрует на вашем устройстве до отправки на серверы
  • Мы не можем расшифровать ваши задачи, даже если бы хотели
  • Никакого сканирования, никакого обучения ИИ на вашей частной работе
  • Утечки данных не раскрывают ничего ценного — только зашифрованные блоки

Как работает zero-knowledge шифрование.

1

Вы создаёте аккаунт.

При регистрации пароль никогда не покидает браузер в открытом виде. Вместо этого:

  • Браузер с помощью Argon2id выводит из пароля обёрточный ключ
  • На устройстве генерируется случайный 32-байтный «ключ данных»
  • Этот ключ данных шифруется обёрточным ключом, полученным из пароля
  • Зашифрованный ключ данных хранится на наших серверах — но без вашего пароля мы его не расшифруем
  • Мы используем протокол OPAQUE PAKE, поэтому серверы никогда не видят пароль в открытом виде

Главное: обёрточный ключ никогда не покидает ваше устройство. Без пароля зашифрованный ключ данных для нас бесполезен.

Зачем тогда хранить зашифрованный ключ данных?

Чтобы вы могли входить с любого устройства. Когда вы пересаживаетесь на другой компьютер или открываете телефон, мы отправляем вам зашифрованный блок, вы снова вводите пароль, он расшифровывается локально — и вы внутри. Без такого хранения пришлось бы вручную копировать 32-байтный ключ между устройствами — ужасный UX при той же безопасности.

2

Вы создаёте рабочий список или задачу.

Каждый чувствительный фрагмент данных шифруется на вашем устройстве:

  • Названия рабочих списков, описания и настройки
  • Названия задач, содержимое, чек-листы и комментарии
  • Шаблоны повторяющихся задач и расписания
  • Всё шифруется с помощью ChaCha20-Poly1305 AEAD (современный, проверенный шифр)
  • У каждого рабочего списка собственный ключ шифрования, выводимый из вашего ключа данных

Наши серверы хранят только зашифрованный шифротекст — открытый текст они прочитать не могут.

3

Вы приглашаете участников.

При совместной работе над рабочими списками:

  • Каждый участник получает свою зашифрованную копию ключа списка
  • Ключи обмениваются через HPKE (Hybrid Public Key Encryption)
  • Открытые ключи публикуются в логе прозрачности (дерево Меркла) для защиты от атак «человек посередине»
  • Если вы удаляете участника, ключ списка ротируется, и все оставшиеся получают новые зашифрованные копии
4

Серверы проверяют, не расшифровывая.

Возможно, вы зададитесь вопросом: «Если сервер не может расшифровать, как он применяет права доступа?»

Мы используем HMAC-доказательства — криптографические подписи, подтверждающие право на доступ без раскрытия открытого текста.

  • Браузер вычисляет HMAC (хэш с ключом) от зашифрованных данных, используя ключ конкретного членства
  • Сервер проверяет HMAC и подтверждает, что вы активный участник
  • Попытка подделки или повтора чужих данных не пройдёт проверку HMAC
  • Содержимое мы никогда не расшифровываем — только проверяем целостность и права

Что серверы (не) видят.

Мы НЕ видим

  • × Названия и описания рабочих списков
  • × Названия задач, их содержание и чек-листы
  • × Комментарии и обсуждения
  • × Шаблоны повторяющихся задач
  • × Любое содержимое в зашифрованных пакетах
  • × Ваш пароль (даже в виде хэша)

Мы видим

  • E-mail аккаунта (для входа)
  • Связи участников (кто в каком списке)
  • Статус задачи (открыта/закрыта) и приоритет
  • Сроки и временные метки
  • Назначения делегирования (только ID пользователей)
  • Метаданные для запросов (ID, даты создания)

Почему часть метаданных видна: Некоторые поля (например, статус задачи и сроки) должны храниться в открытом виде, чтобы серверы эффективно фильтровали запросы, отправляли напоминания о сроках и поддерживали индексы. В этих полях нет чувствительного содержимого — только операционные метаданные, благодаря которым приложение работает.

Гарантии безопасности.

Разблокировка по паролю (только на клиенте).

Пароль никогда не покидает устройство в открытом виде. Argon2id растягивает его в обёрточный ключ, расшифровывающий мастер-ключ данных. Затем HKDF выводит из него отдельные ключи для каждого рабочего списка.

Сервер не может расшифровать данные.

Бэкенд никогда не вызывает операции расшифровки над пользовательскими данными. Он только проверяет HMAC-доказательства для подтверждения прав.

Ротация ключей при изменении состава.

Когда участник удалён или выходит, ключ рабочего списка ротируется. Все оставшиеся получают новые зашифрованные копии, и ушедший участник уже не сможет расшифровывать новые материалы.

Прозрачность ключей приглашений.

Открытые ключи для приглашений записываются в append-only дерево Меркла. Клиенты проверяют доказательства включения и согласованности, поэтому сервер не может незаметно подменить ключи и перехватывать данные.

Open-source криптография.

Мы используем проверенные библиотеки: strong-box (ChaCha20-Poly1305), Argon2id (вывод ключей), OPAQUE (аутентификация по паролю) и HPKE (обмен ключами). Весь криптографический код открыт и поддаётся аудиту.

Как мы проверяем нашу безопасность.

Наши заявления о безопасности проверяемы, а не просто маркетинг. Так мы убеждаемся, что zero-knowledge архитектура работает как обещано:

  • Open-source криптокод на GitHub для публичного аудита исследователями безопасности
  • Проверенные библиотеки: ChaCha20-Poly1305 (RFC 8439), Argon2id, OPAQUE PAKE (RFC 9497) и HPKE
  • Криптографические доказательства (HMAC), математически исключающие расшифровку на сервере
  • Логи прозрачности (деревья Меркла) для обнаружения атак с подменой ключей
  • Клиентский вывод ключей через Argon2id гарантирует, что мы не видим ни пароль, ни ключи шифрования

Компромиссы zero-knowledge.

Нет восстановления пароля.

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

Нет серверного поиска.

Поскольку содержимое задач зашифровано, мы не можем предложить серверный полнотекстовый поиск по всем задачам. Поиск выполняется в браузере после расшифровки.

Снижение риска: мы оптимизируем клиентский поиск индексированными запросами и быстрой расшифровкой, чтобы он оставался быстрым.

Технические характеристики.

Симметричное шифрование ChaCha20-Poly1305 AEAD (через библиотеку strong-box)
Растяжение пароля Argon2id (память 64 MiB, 3 итерации, параллелизм 1) — превращает пароль в обёрточный ключ
Иерархия ключей HKDF-SHA256 — выводит ключи списков и членств из ключа данных
Аутентификация по паролю OPAQUE PAKE (кривая Ristretto255)
Обмен ключами (приглашения) HPKE (Hybrid Public Key Encryption) с X25519
Доказательства целостности HMAC-SHA256
Сериализация CBOR (Concise Binary Object Representation)
Размер ключа 256 бит (32 байта) для всех симметричных ключей

Все криптографические операции выполняются в браузере через WebCrypto API и аудированные WASM-модули, скомпилированные из Rust.

Аудиты и прозрачность.

Open-source криптостек.

Вся наша криптографическая реализация открыта и доступна на GitHub. Мы приглашаем исследователей безопасности проводить аудит нашего кода.

Открыть на GitHub

Соответствие.

Архитектура zero-knowledge поддерживает минимизацию данных по GDPR и может помочь с техническими мерами защиты для HIPAA или SOC 2. Регулируемые PHI по-прежнему требуют письменного соглашения или BAA, а также операционных контролей и подтверждения поставщика, необходимых вашей программе соответствия.

Частые вопросы.

Что будет, если вас взломают?

Если злоумышленник получит доступ к нашей базе, он увидит только зашифрованные блоки — фактически случайные байты. Без вашего пароля (который мы не храним) расшифровать данные современными технологиями математически невозможно.

Могут ли власти заставить вас расшифровать мои данные?

Нет, потому что мы действительно не можем. У нас нет ключей. Даже с ордером мы можем предоставить только зашифрованный шифротекст — без пароля он бесполезен.

Чем это отличается от «шифрования при хранении»?

«Шифрование при хранении» означает, что данные шифруются на дисках сервера, но у сервера есть ключи для расшифровки. Сквозное шифрование — это когда ключи есть только у вас (у конечных точек), а сервер никогда не имеет доступа к открытому тексту.

Могут ли сотрудники Worklist видеть мои данные?

Нет. Наш бэкенд устроен так, что никогда не расшифровывает пользовательские данные. Даже администраторы баз данных с полным доступом к серверам не смогут прочитать ваши рабочие списки и задачи.

Что если я хочу экспортировать данные?

Вы можете в любой момент экспортировать расшифрованные данные из приложения. Расшифровка происходит в браузере, поэтому вы получите читаемые файлы JSON/CSV, а не зашифрованные блоки.

Источники и стандарты.

Наши криптографические решения опираются на индустриальные стандарты и рецензируемые спецификации.

  1. 01
    RFC 8439: ChaCha20 and Poly1305 for IETF Protocols — Наш стандарт симметричного шифрования
  2. 02
    RFC 9497: OPAQUE Asymmetric PAKE Protocol — Аутентификация по паролю zero-knowledge
  3. 03
    RFC 9180: Hybrid Public Key Encryption (HPKE) — Обмен ключами для приглашений в команды
  4. 04
    RFC 9106: Argon2 Memory-Hard Function — Вывод ключа на основе пароля
  5. 05
    NIST SP 800-175B: Guideline for Using Cryptographic Standards — Федеральные криптографические рекомендации
  6. 06
    GDPR Article 32: Security of Processing — Требования ЕС к защите данных

Готовы к настоящей приватности?

Присоединяйтесь к командам, которые доверяют Worklist приватность своей работы. Запустите бесплатный пробный период — банковская карта не нужна.

Начать пробный период

Вопросы по безопасности? Напишите нам на security@worklist.app