Где следует хранить ключи при использовании шифрования на стороне клиента в веб-приложении?

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

Как пользователи будут хранить свои ключи для такого приложения, не создавая неудобств при его использовании?

Есть ли простой способ сохранить ключ в браузере?

Или каждый пользователь должен будет хранить свой ключ в локальном файле на своем компьютере (компьютерах) и импортировать его в веб-приложение каждый раз, когда они входят в систему? Могут ли они использовать отдельный менеджер паролей, такой как Apple Keychain?


javascript encryption security cryptography webcrypto-api
person gesgsklw    schedule 13.07.2016    source источник
comment
developer.mozilla.org/en-US/docs/Web/API/ Web_Storage_API   -  person gre_gor    schedule 13.07.2016
comment
лучше не хранить ключи, а получать их из пароля, введенного пользователем. пользователи могут использовать менеджер паролей, если они не хотят вводить его каждый раз, но сам ключ нельзя потерять вместе с устройством.   -  person dandavis    schedule 18.07.2016

Ответы (1)


arrow_upward
3
arrow_downward

Прорыв API веб-криптографии заключается в обеспечении встроенной поддержки создания, использования и хранения криптографических ключей без раскрытия содержимого закрытых ключей.

В итоге:

  1. Сгенерируйте ключи с помощью WebCrypto и пометьте их как не подлежащие экспорту.
  2. Сохраните ключ в IndexedDB

Вы можете использовать криптографический ключ, но его содержимое будет скрыто как для пользователя, так и для программиста. Обратите внимание на изображение, что объект «cryptoKey» скрыт браузером.

Индексированная БД со скрытым криптографическим ключом

Почему бы не использовать...

  • Файлы cookie/локальное хранилище: разрешить хранение только текста. Ключ должен быть экспортирован в текстовый формат base64, а его содержимое может быть скопировано злоумышленником или даже пользователем...
  • Локальный файл: это совсем не удобно для пользователя. Защита ключей полностью в руках пользователя. Каждое приложение потребует от пользователя импорта ключа в WebCrypto. Это решение не защищено политикой одинакового происхождения. Пользователь может использовать ключ на другом сайте.

Альтернативы (комментарий @dandavis)

  • Не сохранять ключ Получите ключ из пароля, который будет использоваться с алгоритмом симметричного шифрования, таким как AES. Ключ выводится при необходимости, запрашивая пароль у пользователя. Преимущество Использование менеджера паролей возможно, но тогда браузер сохранит строку пароля. Ключ можно использовать с нескольких компьютеров

Эти решения подходят, когда данные должны быть скрыты от сервера. Чтобы сервер мог обрабатывать ваши клиентские данные, вам необходимо (в зависимости от типа ключа)

  • симметричные ключи: вам необходимо предоставить серверу сам ключ (поэтому он должен быть извлекаемым) или пароль для расшифровки данных.

  • асимметричные ключи: сервер использует пару ключей (открытый/закрытый). Сервер отправляет открытый ключ клиенту. Данные, отправляемые с клиента на сервер, шифруются с помощью открытого ключа сервера и расшифровываются с помощью закрытого ключа. Данные, отправляемые с сервера клиенту, шифруются с помощью открытого ключа клиента и расшифровываются с помощью закрытого ключа клиента.

person pedrofb    schedule 17.07.2016
comment
как indexedDB более безопасен, чем localStorage? - person dandavis; 18.07.2016
comment
Ключи бинарные. Для сохранения в localStorage ключ необходимо экспортировать и преобразовать в текстовый формат. Тогда он не будет защищен webcrypto. Злоумышленник, имеющий доступ, может извлечь ключи. С IndexedDB это невозможно. Ключи Webcrypto можно хранить напрямую без необходимости экспорта, а содержимое не видно - person pedrofb; 18.07.2016
comment
если ключи доступны для вредоносного скрипта, я не вижу, как видимость или формат хранения влияет на безопасность, только неясность. Короче говоря, если вы можете запустить код для использования ключей, то сможет и злоумышленник. Firefox имеет встроенный механизм хранения паролей (например, prompt()) в их криптографическом API, но я не думаю, что это то, о чем вы говорите... - person dandavis; 18.07.2016
comment
Нет, я не говорю о Firefox. Самая большая разница, которую я вижу, заключается в том, что даже с вредоносным скриптом злоумышленник может гипотетически использовать ваш ключ, но он не может извлечь его из вашего браузера, потому что закрытый ключ непрозрачен. Проверьте этот интересный блог blog.engelke.com /2014/09/19/ - person pedrofb; 18.07.2016
comment
ключи не нужно извлекать, чтобы украсть, но я полагаю, что это добавляет некоторый запас реалистичной защиты, touchè. - person dandavis; 18.07.2016
comment
ключом к этому является пометка их как не экспортируемых. пользователь root все еще может видеть это, но теперь ваш Frenemy внутри (веб-страницы) тоже не может (государственный / мошеннический служащий). Я полагаю, это как блеск для солнцезащитного крема, вполне неплохо может сработать. - person Tomachi; 23.07.2019