Зачем нужна криптография на стороне клиента

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

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

Основные задачи клиентской криптографии

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

2. Целостность данных Использование криптографических хеш-функций и MAC (Message Authentication Code) позволяет обнаружить изменения данных.

3. Аутентификация Клиент может доказать владение секретом (паролем или ключом), не раскрывая его напрямую.

4. Минимизация доверия к серверу Сервер выступает как хранилище или транспорт, но не имеет доступа к открытым данным.

Почему недостаточно HTTPS

Протокол HTTPS защищает данные в процессе передачи, но не решает следующие проблемы:

  • Сервер видит данные в открытом виде
  • Администраторы или злоумышленники с доступом к серверу могут читать информацию
  • Утечка базы данных раскрывает содержимое

Клиентская криптография добавляет уровень защиты поверх HTTPS:

  • Данные шифруются до отправки
  • Сервер хранит только зашифрованные данные
  • Расшифровка возможна только на стороне клиента

Модель «Zero Knowledge»

Один из ключевых сценариев — архитектура с нулевым разглашением (Zero Knowledge):

  • Пароль пользователя не передаётся на сервер
  • Ключ шифрования генерируется на клиенте
  • Сервер не способен расшифровать данные

Пример: менеджеры паролей или защищённые заметки.

Практические сценарии использования

1. Шифрование пользовательских данных

  • заметки
  • сообщения
  • файлы
  • резервные копии

2. Безопасная аутентификация

  • хранение паролей в виде хешей
  • протоколы доказательства владения паролем

3. Защита форм

  • шифрование чувствительных полей перед отправкой

4. Работа в небезопасной среде

  • публичные сети
  • ненадёжные серверы

Ограничения и риски

Несмотря на преимущества, клиентская криптография имеет ряд сложностей:

1. Управление ключами

  • потеря ключа = потеря данных
  • необходимость безопасного хранения

2. Производительность

  • криптографические операции нагружают CPU браузера
  • особенно заметно на мобильных устройствах

3. Уязвимости клиентского кода

  • XSS-атаки могут получить доступ к ключам
  • вредоносные скрипты способны перехватывать данные

4. Доверие к среде выполнения

  • браузер и его расширения могут быть скомпрометированы

Почему используется SJCL

Stanford JS Crypto Library (SJCL) — библиотека, разработанная для безопасной криптографии в браузере:

Ключевые особенности:

  • реализация AES, SHA, HMAC, PBKDF2
  • работа с битовыми массивами
  • генерация криптографически стойких случайных чисел
  • удобный API для шифрования и дешифрования

Причины использования:

  • независимость от серверной криптографии
  • возможность полностью реализовать Zero Knowledge модель
  • контроль над алгоритмами и параметрами

Архитектура с использованием клиентской криптографии

Типичная схема:

  1. Пользователь вводит пароль
  2. На клиенте генерируется ключ (PBKDF2)
  3. Данные шифруются (AES)
  4. Зашифрованные данные отправляются на сервер
  5. Сервер хранит только ciphertext

При получении данных:

  1. Клиент получает зашифрованные данные
  2. Пользователь вводит пароль
  3. Ключ восстанавливается
  4. Выполняется расшифровка

Когда клиентская криптография необходима

  • хранение чувствительных данных (пароли, ключи, документы)
  • работа с недоверенной серверной стороной
  • требования к приватности (GDPR, безопасность пользователей)
  • разработка end-to-end зашифрованных систем

Когда она избыточна

  • публичные данные
  • системы без строгих требований к конфиденциальности
  • когда управление ключами невозможно реализовать корректно

Баланс безопасности

Клиентская криптография не заменяет серверную, а дополняет её:

  • HTTPS защищает канал
  • серверная безопасность защищает инфраструктуру
  • клиентская криптография защищает сами данные

Именно сочетание этих уровней даёт максимально устойчивую систему.

Оглавление