RSA шифрование в PHP (openssl), Android/Java, JavaScript и Go / Хабр

Введение в xml signatures

XML Signatures – цифровые подписи, спроектированные для применения в XML-транзакциях.
Стандарт описывает схему для хранения результатов операции цифрового подписания
примененного к любым (чаще XML) данным. Подобно не-XML-подписям (например, PKCS)

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

Главная особенность XML Signatures – возможность подписания лишь части данных XML вместо
всего документа. Это особенно значимо, когда один XML-документ может иметь долгую
историю, в которой различные его части оформляются в разное время разными
исполнителями, и каждый подписывает лишь важную для себя часть.

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

XML-подпись может подтверждать более одного типа ресурсов. Например, одна XML-подпись
может покрывать текстовые данные (HTML), бинарные данные (JPG), XML-шифрованные данные и
определенную секцию XML-документа.

• Быть URI в XML-подписи;
• Находиться внутри того же узла, где находится XML-подпись (на этом же уровне);
• Зависеть от подписи (XML-подпись является родителем);
• Иметь подпись в качестве потомка (XML-подпись является дочерним узлом).

Введение в шифрование открытым ключом

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

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

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

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

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

Эти новые
особенности, и, кроме них, поддержка неотрекаемости (уверенность, что получатель не
может отказаться от факта получения, а отправитель – отправления данных) позволяют
электронным сообщениям получать подпись, аналогом которой в «бумажном» мире является
обычная подпись.

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

Чтобы проверка подписи имела какое-то значение, проверяющему необходима уверенность,
что открытый ключ принадлежит именно отправителю сообщения (в ином случае самозванец
может выдать свой открытый ключ за ключ отправителя).

Большей частью из-за производительных характеристик алгоритма открытого ключа,
кодируется не все тело сообщения, а лишь его малая уникальная проекция, называемая «хешем»
(hash) или «дайджестом» (digest). Так как алгоритм хеширования чрезвычайно чувствителен к
любому изменению тела документа, хеш оригинала позволяет получателю проверить, не был
ли изменен документ (путем сравнения присланного хеша и полученного на основе
полученных данных).

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

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

Javascript шифрование

Шифровать я буду с помощью

$(function () {
  $('#but').click(function(){
     var pub = $('#pub').val();
     var crypt = new JSEncrypt();
     crypt.setPublicKey(pub);
     var data = $('#data').val();
     $('#out').val(crypt.encrypt(data));
  });
});

И получил:

C2uWXwp6OsxLKnr3cXpJIf/RcPzgjlxNXj8IX2R47binEo2dLFhJISDnOioQaM8kAl/lqSSOCLdrYP12Tc/YXQ==

$(function () {
  $('#but').click(function(){
     var key = $('#key').val();
     var crypt = new JSEncrypt();
     crypt.setPrivateKey(key);
     var data = $('#data').val();
     $('#out').val(crypt.decrypt(data));
  });
});

Php – rsa – подпись xml – различное значение подписи в php? – web-answers

Vimeo/psalm

Psalm — инструмент статичного анализа, помогающий определять возможные баги в вашем коде. Хотя есть и другие хорошие инструменты (например, замечательные Phan и PHPStan), но если вам нужна поддержка PHP 5, то Psalm — один из лучших инструментов статичного анализа для PHP 5.4 .

Использовать Psalm просто:

# Version 1 doesn't exist yet, but it will one day:
composer require --dev vimeo/psalm:^0

# Only do this once:
vendor/bin/psalm --init

# Do this as often as you need:
vendor/bin/psalm

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

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

Xml-атаки (xxe, xpath-внедрения)

Есть две основные уязвимости, проявляющиеся в приложениях, которые много обрабатывают XML:

1. Внешние сущности XML (XXE).
2. XPath-внедрения.

XXE-атаки, помимо прочего, могут использоваться как стартовая площадка для эксплойтов локального/удалённого внедрения файлов.

Ранние версии Google Docs были уязвимы к XXE-атакам, но они мало известны за пределами бизнес-приложений, обрабатывающих большие объёмы XML.

Главное, что нужно сделать для защиты от XXE-атак:

libxml_disable_entity_loader(true);

XPath-внедрение очень похоже на SQL-внедрение, только здесь речь идёт об XML-документах.

К счастью, в PHP-экосистеме редко возникают ситуации, когда вводимые пользователями данные передаются в XPath-запросе.

К сожалению, это также означает, что лучшее доступное решение (для заранее скомпилированных и параметризованных XPath-запросов) в PHP-экосистеме отсутствует.

Рекомендуем использовать белые списки разрешённых символов для любых данных, имеющих отношение к XPath-запросам.

Безопасное журналирование событий с помощью chronicle

Подробнее: Chronicle заставит задуматься, нужна ли вам технология блокчейна

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

Помимо более изощрённых способов применения такого журнала, Chronicle превосходно себя проявляет в SIEM, поскольку вы можете отправлять важные с точки зрения безопасности события в личный журнал, после чего они становятся неизменяемыми.

Если ваш Chronicle настроен на перекрёстную запись (cross-sign) суммарного хеша в другие экземпляры Chronicle и/или если есть другие экземпляры, сконфигурированные на репликацию содержимого вашего Chronicle, то атакующему будет крайне сложно подделать ваши журналы событий безопасности.

С помощью Chronicle вы получите надёжность блокчейна без распространённых проблем с приватностью, производительностью или масштабируемостью.

Для публикации данных в локальный Chronicle можно использовать любой API, совместимый с Sapient, но самое простое решение — Quill.

Версии php

Вкратце: ничего не поделаешь, но в 2021-м вы будете пользоваться PHP 7.2, а в начале 2021-го — планировать перейти на 7.3.

PHP 7.2 вышел 30 ноября 2021 г.

На момент написания статьи только PHP 7.1 и 7.2 активно поддерживаются разработчиками языка, а для PHP 5.6 и 7.0 ещё примерно год будут выходить патчи безопасности.

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

Соответственно, вне зависимости от обещаний вендоров всегда старайтесь использовать только активно поддерживаемую версию PHP, если это возможно. Если даже вы какое-то время будете работать с версией, для которой выходят только патчи безопасности, регулярные обновления версий избавят вас от многих неприятных сюрпризов.

Глоссарий

PKCS (Public Key Cryptography Standards) – набор стандартов, разработанных лабораторией RSA Data Security.
Эти стандарты были разработаны для обеспечения совместимости между различными
реализациями алгоритмов криптографии с открытым ключом, поставляемыми различными
разработчиками устройств и программного обеспечения.

PKI (Public key infrastructure) – (дословно: инфраструктура открытых ключей). Система цифровых
сертификатов, сертификации авторства и регистрации авторства, позволяющая проверить,
аутентифицировать и подтвердить авторство обеих сторон, участвующих в электронной
транзакции (обмене информацией).SSL (Secure Socket Layer) – протокол доступа, защищающий информацию от посторонних пользователей.

SSL (Secure Socket Layer) – протокол доступа, защищающий информацию от посторонних
пользователей.

URI (Uniform Resource Identifier) — единообразный идентификатор ресурса. URI — это короткая
последовательность символов, идентифицирующая абстрактный или физический ресурс.
Ранее назывался Universal Resource Identifier — универсальный идентификатор ресурса.

XML (eXtensible Markup Language) — рекомендованный Консорциумом
Всемирной паутины язык разметки, фактически представляющий собой свод общих
синтаксических правил. XML предназначен для хранения структурированных данных (взамен
существующих файлов баз данных), для обмена информацией между программами, а также для
создания на его основе более специализированных языков разметки (например, XHTML), иногда
называемых словарями. XML является упрощённым подмножеством языка SGML.

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

Например, Secure Sockets Layer (SSL) предоставляет защищенный обмен точными данными между
браузером и Web-сервером, но как только данные получаются сервером, они перестают быть
защищенными. Фактически, SSL защищает данные только во время их транспортировки от
клиента к серверу, или, иначе говоря, тогда, когда их редко атакуют.

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

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

Не менее чем защита конфиденциальности данных важна их долговременная
аутентификация (кем они посланы?), целостность данных (менялись ли данные во время
транспортировки?) и поддержка неотрекаемости (может отправитель отказаться от своей
подписи?); другими словами, функциональность, которую существующие технологии (например,
SSL, аутентификация по имени/паролю) обособленно не предоставляют.

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

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

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

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

Две новых технологии, созданных для достижения поставленных задач и использующих все
преимущества особенностей формата XML – XML-подпись (XML Signature) и XML-шифрование (XML Encryption). XML
Signature – результат совместной работы между World Wide Web Consortium (W3C) и Internet Engineering Task Force (IETF), а XML
Encryption разработана усилиями W3C.

Десериализация и внедрение php-объектов

Подробнее: Безопасная (де)сериализация в PHP

Если вы передаёте в unserialize() недоверенные данные, то напрашиваетесь на два варианта развития событий:

1. Внедрение PHP-объекта, который можно использовать для запуска POP-цепочки и срабатывания других уязвимостей из неправильно используемых объектов.
2. Повреждение памяти в самом интерпретаторе PHP.

Многие разработчики предпочитают использовать вместо этого JSON-сериализацию, что является заметным улучшением безопасности ПО. Но имейте в виду, что json_decode()уязвима для DDoS-атак посредством хеш-коллизий. К сожалению, полное решение проблемы хеш-DOS в PHP ещё предстоит найти.

Полностью защититься от этих атак поможет мигрирование с djb33 на Siphash с назначением 1 в качестве старшего бита для хеша строкового входного значения, 0 для целочисленного и с заранее запрошенным ключом, его предоставит CSPRNG.

К сожалению, создатели PHP не готовы частично пожертвовать производительностью, которой они добились в PHP 7, поэтому трудно убедить их отказаться от djb33 (очень быстрого, но небезопасного) в пользу SipHash (тоже быстрого, хотя и не как djb33, но куда более безопасного).

Поэтому лучше поступать так:

• Использовать JSON, это безопаснее unserialize().
• Там, где возможно, аутентифицируйте входные данные, прежде чем десериализовать их.
• Там, где нет возможности аутентифицировать JSON-строки, используйте строгое рейт лимиты и блокируйте IP-адреса для защиты от атаки повторением.

Источники

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

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

Если вы работаете в компании, которая заинтересована в оценке соответствия требованиям (PCI-DSS, ISO 27001 и т. д.), можете нанять нас для аудита своего исходного кода. Мы работаем гораздо более дружественно к разработчикам, чем другие консультанты по безопасности.

Ниже — список источников от PHP-сообщества и сообщества по информационной безопасности.

• PHP: The Right Way — бесплатное руководство по современной PHP-разработке.
• Генератор SSL-конфигураций Mozilla.
• Let’s Encrypt — сертификационная компания, бесплатно предоставляющая TLS-сертификаты ради повышения безопасности интернета.
• Qualys SSL Labs предоставляет простой тестовый набор для TLS-конфигураций. Очень многие используют его для отладки своих наборов шифров и решения проблем с сертификатами, и не просто так: инструмент работает отлично.
• Security Headers умеет проверять, насколько хорош ваш сайт с точки зрения использования браузерных средств безопасности для защиты пользователей.
• Report-URI — замечательный бесплатный ресурс, поддерживающий инициативы по внедрению заголовков безопасности. Вам даётся Report-URI, который вы можете передавать браузерам пользователей, а те будут жаловаться Report-URI, если что-то сломается или обнаружится вектор XSS-атаки. Report-URI собирает все эти ошибки и помогает лучше отлаживать и сортировать статистику.
• The PHP Security Advent Calendar, созданный разработчиками RIPSTech.
• Snuffleupagus — PHP-модуль для улучшения безопасности приложений (и духовный наследник практически заброшенного Suhosin).
• PHP Delusions — сайт, посвящённый улучшению использования PHP. Многое высказано очень категорично, но из-за стремления автора к технической точности и ясности почитать стоит. Особенно тем, кто не очень хорошо разбирается во многих функциях PDO.
• Have I Been Pwned? помогает пользователям узнать, оказались ли их данные среди ранее украденной информации.

Конфигурирование openssl

Openssl поддерживает российские криптоалгоритмы, начиная с версии 1.0. Для того, чтобы их использовать, в openssl требуется подгружать engine gost. В большинстве дистрибутивов openssl эта библиотека присутствует. Чтобы engine подгружалась, можно прописать ее в конфигурационном файле openssl:

[openssl_def]
engines = engine_section

[engine_section]
gost  = gost_section

[gost_section]
engine_id  = gost
default_algorithms = ALL

Если конфигурационный файл openssl не расположен в стандартном месте, то путь к нему можно задать через переменную окружения OPENSSL_CONF.

Другим вариантом подгрузки engine gost является ее передача в параметрах командной строки утилиты openssl.

Если engine gost не расположена в стандартном месте, то через переменную окружения OPENSSL_ENGINES можно задать путь к директории, в которой openssl будет ее искать.

Для получения информации о том, успешен ли был вызов утилиты openssl или нет, с возможностью уточнения ошибки, требуется парсить stdout и stderror. В конце статьи приведена ссылка на PHP-скрипт, который использует данную утилиту.

Теперь перейдем к реализации законченных пользовательских сценариев.

Несколько слов от автора

Проницательный читатель мог заметить, что мы много ссылаемся на собственные работы (статьи и open source проекты), но мы ссылаемся не только на свои работы.

Это неслучайно.

Наша компания с самого основания в начале 2021-го пишет библиотеки для обеспечения безопасности и участвует в повышении защищённости экосистемы PHP.

Мы много путешествуем, и наш инженер по безопасности (чьи недавние усилия по использованию более сильной криптографии в ядре PHP только что отразились в PHP 7.2), по его собственному признанию, не слишком силён в генерировании хайпа или интереса к своей работе. Наверняка вы не слышали и о половине инструментов или библиотек, созданных нами за эти годы.

Но мы не можем стать пионерами во всех направлениях, поэтому везде, где это возможно, связываемся с экспертами индустрии, которые, как нам кажется, больше ориентируются на общественное благо, чем на мелкий эгоизм. Поэтому большая часть раздела, посвящённого безопасности в браузере, снабжена ссылками на работы Скотта Хелме (Scott Helme) и компании. Он вложил много сил в то, чтобы эти новые возможности по обеспечению безопасности стали доступны и понятны разработчикам.

Конечно, это не исчерпывающее руководство. Существует почти столько же способов писать небезопасный код, сколько способов самого написания кода. Безопасность — это больше мышление, чем цель. Мы надеемся, что с помощью всего сказанного и приведённых ниже источников разработчики с сегодняшнего дня смогут создавать защищённые PHP-приложения.

Подпись по гост в php или как подписать soap гост алгоритмами?

adminka@ubuntu-nginx:/$ openssl ciphers|tr ':' 'n'|grep GOST
GOST2021-GOST8912-GOST8912
GOST2001-GOST89-GOST89

openssl req -newkey gost2021_256 -pkeyopt paramset:A -out cert.csr -keyout key.pem
openssl x509 -req -in cert.csr -out cert.pem -signkey key.pem -days 730

Warning: openssl_sign(): key type not supported in this PHP build! in /home/adminka/callbacksoap/test.php on line 11
string(88) "xlRC/hbqWkqDb/ENW0QlvWC/Bx9pqZfr6hEZvA9ZazLKVE7rjIWwWciVFU8xPKH0MKmfHKltouC5xk32GZ3Erg=="

Поиск подключенных устройств

Любой клиентский сценарий начинается с поиска подключенных к компьютеру USB-устройств Рутокен. В контексте данной статьи акцент делается на устройство Рутокен ЭЦП.

var devices = Array();

try 
{
    devices = plugin.enumerateDevices();
}
catch (error) 
{
    console.log(error);
}

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

Рутокен Плагин определяет все подключенные к компьютеру USВ-устройства Рутокен ЭЦП, Рутокен PINPad, Рутокен WEB. Поэтому следующим шагом следует определить тип устройства.

Получение информации об устройстве

Для определения типа устройства следует использовать функцию

с параметром TOKEN_INFO_DEVICE_TYPE. Значение этой константы содержится в объекте плагина.

var type;

try
{  
  type = plugin.getDeviceInfo(deviceId, plugin.TOKEN_INFO_DEVICE_TYPE);
}
catch (error) 
{
    console.log(error);
}

switch (type) 
{
    case plugin.TOKEN_TYPE_UNKNOWN:
        message = "Неизвестное устройство";
        break;
    case plugin.TOKEN_TYPE_RUTOKEN_ECP:
        message = "Рутокен ЭЦП";
        break;
    case plugin.TOKEN_TYPE_RUTOKEN_WEB:
        message = "Рутокен Web";
        break;
    case plugin.TOKEN_TYPE_RUTOKEN_PINPAD_2:
        message = "Рутокен PINPad";
        break;
}

Также с помощью функции getDeviceInfo можно получить:

Проверка xml-подписи

Краткое описание как проверять XML-подпись:

• Проверьте подпись элемента <SignedInfo>. Для этого пересчитайте хеш элемента <SignedInfo>
  (используя алгоритм расчета хеша, указанный в элементе <SignatureMethod>) и
  воспользуйтесь открытым ключом для проверки, что значение элемента <SignatureValue>
  совпадает с хешем элемента <SignedInfo>.
• Если этот шаг пройден, пересчитайте хешы ссылок, содержащихся в элементе <SignedInfo>,
  и сравните их со значениями хешей, представленными в каждом элементе <DigestValue>
  каждого элемента <Reference>.

Работа с ключевыми парами гост р 34.10-2001

1. Для получения декрипторов ключевых пар, хранящихся на устройстве, требуется ввод PIN-кода. Следует понимать, что само значение закрытого ключ получено быть не может, так как ключ является неизвлекаемым.

var keys = Array();

try
{   
    plugin.login(deviceId, "12345678");
    keys = plugin.enumerateKeys(deviceId, null);
}
catch (error) 
{
    console.log(error);
}

2. Для генерации ключевой пары требуется ввод PIN-кода. При генерации ключа параметры могут быть выбраны из набора:

Пример генерации ключевой пары ГОСТ Р 34.10-2001:

var options = {};
var keyId;

try 
{
    keyId = plugin.generateKeyPair(deviceId, "A",  null, options);
}
catch (error) 
{
    console.log(error);
}

3. С помощью функции deleteKeyPair ключевая пара может быть удалена с токена.

Сертификат выдается при регистрации в системе

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

Далее запрос отправляется на сервер, где на его основе выдается сертификат.Для этого на сервере должен быть установлен и правильно сконфигурирован openssl версии от 1.0 и развернут функционал УЦ.

1. Генерация улюча УЦ:

openssl genpkey -engine gost -algorithm GOST2001 -pkeyopt paramset:A -out ca.key

После этого в файле ca.key будет создан закрытый ключ

2. Создание самоподписанного сертификата УЦ:

openssl req -engine gost -x509 -new -key ca.key -out ca.crt

После ввода необходимой информации об издателе в файле ca.crt будет создан сертификат УЦ.

Сертификат уже имеется на токене, выдан внешним уц

Ключевая пара при этом должна быть создана в формате, совместимом с библиотекой rtPKCS11ECP для Рутокен ЭЦП.

Последовательность вызовов на клиенте:

Подпись получается в base64-формате. При проверке ее на сервере с помощью openssl подпись следует обрамить заголовками, чтобы сделать из нее PEM. Выглядеть подобная подпись будет примерно так:

-----BEGIN CMS-----
MIIDUQYJKoZIhvcNAQcCoIIDQjCCAz4CAQExDDAKBgYqhQMCAgkFADCBygYJKoZI
hvcNAQcBoIG8BIG5PCFQSU5QQURGSUxFIFVURjg PFY 0JLRi9C/0L7Qu9C90LjR
gtGMINCw0YPRgtC10L3RgtC40YTQuNC60LDRhtC40Y4/PCE c2VydmVyLXJhbmRv
bS1kYXRhZTI6ZGE6MmM6MDU6MGI6MzY6MjU6MzQ6YzM6NDk6Nzk6Mzk6YmI6MmY6
YzU6Mzc6ZGI6MzA6MTQ6NDQ6ODM6NjY6Njk6NmI6OWY6YTU6MDk6MzQ6YmY6YzQ6
NzY6YzmgggGeMIIBmjCCAUegAwIBAgIBATAKBgYqhQMCAgMFADBUMQswCQYDVQQG
EwJSVTEPMA0GA1UEBxMGTW9zY293MSIwIAYDVQQKFBlPT08gIkdhcmFudC1QYXJr
LVRlbGVjb20iMRAwDgYDVQQDEwdUZXN0IENBMB4XDTE0MTIyMjE2NTEyNVoXDTE1
MTIyMjE2NTEyNVowEDEOMAwGA1UEAxMFZmZmZmYwYzAcBgYqhQMCAhMwEgYHKoUD
AgIjAQYHKoUDAgIeAQNDAARADKA/O1Zw50PzMpcNkWnW39mAJcTehAhkQ2Vg7bHk
IwIdf7zPe2PxHyAr6lH stqdACK6sFYmkZ58cBjzL0WBwaNEMEIwJQYDVR0lBB4w
HAYIKwYBBQUHAwIGCCsGAQUFBwMEBgYpAQEBAQIwCwYDVR0PBAQDAgKkMAwGA1Ud
EwEB/wQCMAAwCgYGKoUDAgIDBQADQQD5TY55KbwADGKJRK bwCGZw24sdIyayIX5
dn9hrKkNrZsWdetWY3KJFylSulykS/dfJ871IT 8dXPU5A7WqG4 MYG7MIG4AgEB
MFkwVDELMAkGA1UEBhMCUlUxDzANBgNVBAcTBk1vc2NvdzEiMCAGA1UEChQZT09P
ICJHYXJhbnQtUGFyay1UZWxlY29tIjEQMA4GA1UEAxMHVGVzdCBDQQIBATAKBgYq
hQMCAgkFADAKBgYqhQMCAhMFAARAco5PumEfUYVcLMb1cnzETNOuWC8Goda8pdUL
W5ASK tztCwM7wpXgAy Y6/sLtClO9sh8dKnAaEY2Yavg3altQ==
-----END CMS-----

Проверка подписи на сервере:

Управление зависимостями

Вкратце: используйте Composer.

Composer — это шедевральное решение по управлению зависимостями в PHP-экосистеме. В книге PHP: The Right Way целый раздел посвящён началу работы с Composer, очень рекомендуем его прочесть.

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

Важно: не забывайте обновлять свои зависимости по мере разработки ПО. К счастью, это можно сделать одной строкой:

composer update

Если вы делаете что-то особенное, требующее использования PHP-расширений (написанных на С), то вы не можете установить их с помощью Composer. Вам также потребуется PECL.

Хеширование паролей

Подробнее: Как в 2021-м безопасно хранить пользовательские паролиБезопасное хранилище паролей раньше было темой активной дискуссии, но сегодня его просто реализовать, особенно в PHP:

$hash = password_hash($password, PASSWORD_DEFAULT);

if (password_verify($password, $hash)) {
    // Authenticated.
    if (password_needs_rehash($hash, PASSWORD_DEFAULT)) {
        // Rehash, update database.
    }
}

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

Что бы вы ни делали, не делайте так, как WordPress.

Если интересно: с PHP 5.5 по 7.2 алгоритмом по умолчанию является bcrypt. В будущем его могут заменить Argon2, победителем в Соревновании по хешированию паролей.

Если до этого вы не использовали API password_* и вам нужно мигрировать легаси-хеши, то сделайте это именно так. Многие компании, например Yahoo, поступили неправильно. Похоже, недавно причиной бага с iamroot у Apple стала некорректная реализация обновления легаси-хешей.

Целостность подресурсов

Однажды в будущем вы станете работать над проектом, использующим CDN для выгрузки традиционных Javascript/CSS-фреймворков и библиотек в центральное расположение. Неудивительно, что специалисты по безопасности предсказали очевидную проблему: если много сайтов используют CDN для предоставления части своего содержимого, то взлом CDN и подмена данных позволит внедрять произвольный код на тысячи (если не миллионы) сайтов.

Поэтому придумали целостность подресурсов (subresource integrity).

Целостность подресурсов (SRI) позволяет закреплять хеш содержимого файла, которое вам должна предоставить CDN. Текущая реализация SRI позволяет использовать только криптографические хеш-функции, поэтому злоумышленники не смогут сгенерировать вредоносные версии контента, приводящие к таким же хешам, как у оригинальных файлов.

Реальный пример: Bootstrap v4-alpha использует SRI в примере кода их CDN.

Шифрование данных на клиенте для сервера

Для того, чтобы обеспечить конфиденциальность обмена данными между клиентом и сервером в плагине предусмотрено шифрование/расшифрование данных. Данные шифруются в формате CMS. Для того, чтобы зашифровать данные в формате CMS, требуется сертификат открытого ключа «адресата».

При этом расшифровать такое сообщение сможет только владелец закрытого ключа. При шифровании данных для сервера рекомендуется хранить сертификат сервера на Рутокен ЭЦП. Этот сертификат может быть записан на устройство при регистрации пользователя на портале.

Для этого следует использовать функцию importCertificate, при этом в качестве параметра category следует передать CERT_CATEGORY_OTHER. Для использования в функции cmsEncrypt нужно получить тело сертификата по его дескриптору с помощью функции getCertificate.

При этом дескриптор является уникальным и неизменным и может быть сохранен в учетной записи пользователя на сервере при импорте сертификата сервера. Для того, чтобы использовалось аппаратное шифрование по ГОСТ 28147-89, требуется установить опцию useHardwareEncryption в true. В противном случае будет использована быстрая программная реализация ГОСТ 28147-89.

Последовательность вызовов приведена на картинке:

Шифрование данных на клиенте:

try
{
    var recipientCert = plugin.getCertificate(deviceId, certRecId);        
}
catch (error) 
{
    console.log(error);
}

var options = {};
options.useHardwareEncryption = true;
var cms;

try
{
    cms = plugin.cmsEncrypt(deviceId, certSenderId, recipientCert, data, options);
}
catch (error) 
{
    console.log(error);
}

Расшифрование данных на сервере, перед расшифрованием сообщение нужно обрамить PEM-заголовками “—–BEGIN PKCS7—–” и “—–END PKCS7—–“:

openssl smime -engine gost -decrypt -in message.cms -inform PEM -recip recipient.crt -inkey recipient.key

recipient.crt — сертификат того, для кого зашифровано сообщение, recipient.key — ключ того, для кого зашифровано сообщение.

Шифрование с возможностью поиска

Подробнее: Building Searchable Encrypted Databases with PHP and SQL

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

1. Проектируем такую архитектуру, чтобы компрометация базы данных не позволила атакующему получить доступ к ключам шифрования.
2. Шифруем данные одним секретным ключом.
3. Создаём многочисленные индексы (с собственными различными секретными ключами) на основе HMAC или безопасного KDF со статической солью (например, Argon2).
4. По желанию: усекаем выходные данные шага 3, используем их в качестве Bloom-фильтра.
5. Используем выходные данные шагов 3 или 4 в запросах SELECT.
6. Расшифровываем результат.

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

Элемент ds:keyinfo

На данный момент мы знаем, как сослаться на содержимое, преобразовать и хэшировать
его, и создать подпись, которая покрывает (защищает) это содержимое. Оно защищено от
обратного преобразования: ds:SignatureValue включает ds:

SignedInfo, который содержит ds:References,
в котором находятся значения хэшей данных приложения. Изменение любого из этих
элементов влечет за собой разрушение цепочки математических вычислений, и подпись не
будет достоверной.

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

Как видите, XML DSIG поддерживает разнообразные типы ключей и инфраструктуры ключей, а
WS-Security пошла еще дальше. Мы рассмотрим только простое имя и сертификат X.509. ds:KeyName
стоит использовать при создании специального приложения для закрытой среды:

За проецирование имени во внутреннее хранилище и выбор подходящего ключа отвечает
процесс, проверяющий достоверность подписи. К обычным значениям ds:KeyName относятся
адрес электронной почты или элемент справочника.

Сертификаты X.509 поддерживаются элементом ds:X509Data. Этот элемент позволяет
подписывающей стороне встраивать свой сертификат (в Base64) или любую из нескольких
альтернативных форм идентификации сертификата: имя субъекта, имя пользователя и
серийный номер, идентификатор ключа или что-либо другое.

Подписывающая сторона также
может включить текущую копию Списка отзыва сертификата (Certificate Revocation List – CRL), чтобы
показать, что идентификатор подписывающей стороны был действителен в момент
подписания документа. Фрагмент Схемы, приведенный ниже, показывает различные способы
идентификации сертификата X.509:

Поскольку различные приложения будут сохранять и извлекать сертификаты, используя
различные схемы, цифровые подписи XML часто включают множество имен одного и того же
ключа, встраивая их в один и тот же элемент ds:KeyInfo.

Элемент ds:reference

Элемент ds:SignatureValue содержит подпись, которая охватывает только элемент ds:SignedInfo:
в хэш подписи включено только содержимое ds:SignedInfo. Тогда как мы на самом деле
подписываем все остальное содержимое? Тонкость и мощь — в элементе ds:Reference.

Из описания схемы элемента ds:SignedInfoType, приведенного выше, подпись может иметь
множество ссылок. Это позволяет одной XML DSIG охватывать множество объектов: все части MIME-сообщения,
XML-файл и XSLT-сценарий, который преобразовывает его в HTML, и т.д.

Элемент ds:Reference ссылается на другое содержимое. Он включает хэш содержимого,
свидетельство того, что хэш был создан (например, SHA1), и определение того, как содержимое
должно бы трансформировано перед генерированием хэша. Трансформации обеспечивают
поразительную гибкость XML DSIG. Здесь представлен фрагмент Схемы:

Атрибут Type может обеспечить подсказку при обработке, но, в общем, бесполезен.

URI указывает на фактическое содержимое, к которому обращаются. Поскольку это — URI,
нам доступна вся мощь Web. Например, я могут подписать содержимое начальной страницы MSDN:

Элемент ds:signature/ds:object

Как мы увидим ниже, XML DSIG может содержать множество элементов. Элемент всегда сможет
существовать самостоятельно, как Web-страница или деловой XML-документ, но иногда элемент
лучше интерпретировать как метаданные для подписанного «настоящего» содержимого.
Например, данные могут быть «собственностью» подписи, как временная метка создания
подписи.

Для размещения таких данных в Signature может использоваться элемент ds:Object:

Атрибут Id позволяет содержать в подписи множество объектов, к каждому из которых
можно обращаться независимо. MimeType используется для идентификации данных, чтобы
другие обработчики могли их использовать; он не имеет значения для DSIG-обработчика.

Encoding определяет, как подготовить содержимое к обработке; на данное время
определено только кодирование base-64.

Вот два объекта (с идентичным содержимым), которые могут использоваться как простые
указатели того, когда был подписан документ. Сервис, содержащий их в своей подписи,
может быть полезен для конкурсов, аукционов или других проводимых в режиме онлайн
действий, которые имеют предельные сроки представления:

Элемент ds:signedinfo

Содержимое ds:SignedInfo может быть разделено на две части: информация о SignatureValue и
информация о содержимом приложения, — как видно из следующего фрагмента XML Schema:

Синтаксис XML довольно небрежен. Например, порядок атрибутов и то, как оформляются
значения, на самом деле не имеет особого значения. Поскольку речь идет о программном
обеспечении для обработки XML, следующие два примера полностью равнозначны:

Но подписям нужны хэши сообщений, и такие различия имеют огромное значение.

Чтобы это обработать, содержимое должно быть канонизировано (canonicalized). Канонизация
или C14N — это процесс выбора одного пути из всех
возможных вариантов выхода, так чтобы отправитель и получатель могли формировать
именно такое же байтовое значение. То, какое промежуточное программное обеспечение XML
может быть вовлечено в это, значения не имеет.

Элемент ds:SignedInfo/ds:CanonicalizationMethod определяет то, как точно воспроизводить поток
байтов. Элемент ds:SignedInfo/ds:SignatureMethod определяет, какой тип подписи — например,
Kerberos или RSA — используется для создания подписи. Вместе эти два элемента указывают нам,
как создать хэш и как защитить его от изменений.

Вот пример: