API веб-криптографии
![]() | Тема этой статьи Википедии может не соответствовать общему правилу по известности . ( декабрь 2023 г. ) |
API веб-криптографии — это рекомендация Консорциума Всемирной паутины (W3C) в отношении низкоуровневого интерфейса, который повысит безопасность веб-приложений , позволяя им выполнять криптографические функции без необходимости доступа к необработанному ключевому материалу. [1] Этот агностический API будет выполнять основные криптографические операции, такие как хеширование , генерация подписи , проверка и шифрование , а также дешифрование изнутри веб-приложения. [2]
Описание
[ редактировать ]26 января 2017 года W3C опубликовал рекомендации по API веб-криптографии. [3] который мог бы выполнять основные криптографические операции в веб-приложениях. Этот независимый API будет использовать JavaScript для выполнения операций, которые повысят безопасность обмена данными внутри веб-приложений . API будет предоставлять низкоуровневый интерфейс для создания и/или управления открытыми ключами и закрытыми ключами для хеширования , цифровой подписи генерации и проверки , а также шифрования и дешифрования для использования с веб-приложениями.
API веб-криптографии можно использовать для самых разных целей, в том числе:
- Обеспечение аутентификации для пользователей и сервисов
- Электронное подписание документов или кода
- Защита целостности и конфиденциальности связи и обмена цифровыми данными
Поскольку API веб-криптографии является независимым по своей природе, его можно использовать на любой платформе . Он предоставит общий набор интерфейсов , которые позволят веб-приложениям и прогрессивным веб-приложениям выполнять криптографические функции без необходимости доступа к исходному ключевому материалу. Это будет сделано с помощью интерфейса SubtleCrypto, который определяет группу методов для выполнения вышеуказанных криптографических операций. Дополнительные интерфейсы в API веб-криптографии позволят генерировать ключи, получать ключи, а также импортировать и экспортировать ключи. [1]
Предлагаемый функционал
[ редактировать ]В спецификации W3C для API веб-криптографии основное внимание уделяется общим функциональным возможностям и функциям, которые в настоящее время существуют между специфичными для платформы и стандартизированными криптографическими API, а не теми, которые известны лишь немногим реализациям. Рекомендация группы по использованию API веб-криптографии не требует реализации обязательного набора алгоритмов. Это происходит из-за осознания того, что криптографические реализации будут различаться среди соответствующих пользовательских агентов из-за правительственных постановлений , местной политики безопасности , методов и проблем интеллектуальной собственности .
Существует множество типов существующих веб-приложений, для использования с которыми хорошо подходит API веб-криптографии. [1]
Многофакторная аутентификация
[ редактировать ]Сегодня многофакторная аутентификация считается одним из самых надежных методов проверки личности пользователя веб-приложения, например онлайн-банкинга. Многие веб-приложения в настоящее время используют этот метод аутентификации для защиты как пользователя, так и пользовательского агента. Благодаря API веб-криптографии веб-приложение будет иметь возможность обеспечивать аутентификацию изнутри себя, вместо того, чтобы полагаться на аутентификацию на транспортном уровне для секретного ключевого материала для аутентификации доступа пользователя. Этот процесс предоставит пользователю более богатый опыт.
API веб-криптографии позволит приложению находить подходящие клиентские ключи, которые были ранее созданы пользовательским агентом или предварительно предоставлены веб-приложением. Приложение сможет предоставить пользовательскому агенту возможность либо генерировать новый ключ, либо повторно использовать существующий ключ в случае, если у пользователя нет ключа, уже связанного с его учетной записью. Привязав этот процесс к безопасности транспортного уровня , через который проходит аутентификация пользователя, процесс многофакторной аутентификации можно дополнительно усилить за счет получения ключа, основанного на базовом транспорте. [1] [2]
Защищенный обмен документами
[ редактировать ]API можно использовать для защиты важных или конфиденциальных документов от несанкционированного просмотра из веб-приложения, даже если они ранее были безопасно получены. Веб-приложение будет использовать API веб-криптографии для шифрования документа с помощью секретного ключа, а затем обернуть его открытыми ключами, связанными с пользователями, которым разрешено просматривать документ. При переходе к веб-приложению авторизованный пользователь получит зашифрованный документ и получит указание использовать свой закрытый ключ, чтобы начать процесс развертывания, который позволит ему расшифровать и просмотреть документ. [2]
Облачное хранилище
[ редактировать ]Многие предприятия и частные лица полагаются на облачное хранилище . В целях защиты поставщик удаленных услуг может захотеть, чтобы их веб-приложение давало пользователям возможность защищать свои конфиденциальные документы перед загрузкой своих документов или других данных. API веб-криптографии позволит пользователям:
- Выберите частный или секретный ключ
- Получите ключ шифрования из своего ключа, если захотят.
- Зашифруйте свой документ/данные
- Загрузите зашифрованный документ/данные, используя существующие API поставщика услуг. [2]
Электронное подписание документов
[ редактировать ]Возможность электронной подписи документов экономит время, повышает безопасность важных документов и может служить юридическим доказательством принятия документа пользователем. Многие веб-приложения предпочитают принимать электронные подписи вместо письменных подписей. С помощью API веб-криптографии пользователю будет предложено выбрать ключ, который может быть сгенерирован или предварительно предоставлен специально для веб-приложения. Затем ключ можно было использовать во время операции подписания.
Защита целостности данных
[ редактировать ]Веб-приложения часто кэшируют данные локально, что подвергает данные риску компрометации в случае автономной атаки. API веб-криптографии позволяет веб-приложению использовать открытый ключ , развернутый внутри него, для проверки целостности кэша данных. [2]
Безопасный обмен сообщениями
[ редактировать ]API веб-криптографии может повысить безопасность обмена сообщениями для использования в автономных (OTR) и других типах схем подписи сообщений за счет использования соглашения о ключах. Отправитель сообщения и предполагаемый получатель будут согласовывать общие ключи шифрования и кода аутентификации сообщения (MAC) для шифрования и дешифрования сообщений для предотвращения несанкционированного доступа. [2]
Подписание и шифрование объектов JSON (JOSE)
[ редактировать ]API веб-криптографии может использоваться веб-приложениями для взаимодействия с форматами и структурами сообщений, определенными рабочей группой JOSE. [4] Приложение может считывать и импортировать ключи веб-подписи JSON (JWK), проверять сообщения, защищенные с помощью электронной подписи или ключей MAC , и расшифровывать сообщения JWE.
Соответствие API веб-криптографии
[ редактировать ]W3C рекомендует поставщикам избегать использования собственных расширений конкретного поставщика со спецификациями API веб-криптографии. Это связано с тем, что это может снизить совместимость API и разрушить базу пользователей, поскольку не все пользователи смогут получить доступ к конкретному контенту. Если невозможно избежать расширения, специфичного для поставщика, поставщик должен префиксировать его строками, специфичными для поставщика, чтобы предотвратить конфликты с будущими поколениями спецификаций API.
Ссылки
[ редактировать ]- ^ Jump up to: а б с д Тернер, Дон М. «Предложение W3C по API веб-криптографии» . Криптоматика . Проверено 9 мая 2017 г.
- ^ Jump up to: а б с д и ж Уотсон, Марк (ред.). «API веб-криптографии, предложенная W3C, 15 декабря 2016 г.» . W3C . Проверено 23 мая 2017 г.
- ^ Уотсон, Марк (ред.). «Рекомендация W3C API веб-криптографии от 26 января 2017 г.» . W3C . Проверено 3 июля 2018 г.
- ^ Рабочая группа ЖОЗЕ. «Подписание и шифрование объектов Javascript (хосе)» . IETF . Проверено 16 марта 2017 г.