PHP двухстороннее шифрование с контрольной суммой

Question

Я пытаюсь передать строку JSON из одного веб-приложения в другое с использованием параметров URL (для внутреннего сервера единого входа).

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

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

Целью этого является то, чтобы пользовательская полезная нагрузка не была изменена в процессе транзита либо случайно, либо намеренно.

Answer 1

Вы хотите предоставить больше, чем «контрольную сумму» (обычно определяемую как «исчисляемую любой стороной»); вы хотите предоставить идентификационный тег или код аутентификации сообщения (MAC). У вас есть несколько вариантов:

1. Используйте "authenticated encryption" (AE) или "authenticated encryption with associated data" (AEAD) шифра, чтобы сделать это. Шифры AE (AD) обеспечивают «тег аутентификации» над текстом шифрования либо за один проход, либо с повторным процессом по зашифрованному шифрованному тексту. Примеры (вероятно, доступны в любой библиотеке шифрования PHP, которую вы используете): GCM, EAX и CCM. Это рекомендуется, так как операция дешифрования не будет выполнена, если тег аутентификации не проверен, и необходим только один общий секрет (ключ).
2. Вы можете самостоятельно построить систему, используя криптографические примитивы. Это не так идеально, поскольку вы отвечаете за более самостоятельные части, вам нужно управлять большим количеством ключей (если у вас есть доступ к OMAC implementation, вы можете использовать тот же ключ), и ваша индивидуальная конструкция не проверяется третьими лицами (иначе говоря, коллективная работа в Интернете). Если вы следуете этому пути, вам нужно сохранить некоторые ключевые сведения:
   • Используйте сильную hash-based message authentication code (HMAC), такую ​​как HMAC/SHA-256, -384 или -512. Не используйте SHA-1 или MD5, так как они легко грубые принудительно.
   • Проверка HMAC до Расшифровка шифрованного текста. Любой HMAC, который терпит неудачу, означает, что весь текст шифрования должен быть отброшен. Вы можете запомнить это (на стороне генерирования) как Шифровать затем MAC, и если вы его найдете, вы увидите, что не в соответствии с этим советом является источником многих криптографических уязвимостей и эксплойтов реализации.
   • Проверьте HMAC с помощью алгоритма с постоянным временем (т. Е. Не используйте сравнение равенства строк короткой цепи, по умолчанию в Java). Для этого PHP предоставляет hash_equals. Вот quick explanation of timing attacks и code review of a PHP example.

Для любой выбор вы хотите, чтобы кодировать полученный зашифрованный текст и тег аутентификации с URL-сейф Base64 для того, чтобы избежать потери или повреждения данных. Если формат сообщения не является строго структурированным с включенными длинами, вам придется предварительно предоставить протокол заранее (т.для сообщения m длины n байт ->16 bytes IV | n-48 bytes cipher text | 32 bytes HMAC).

Последнее примечание: всегда использует уникальный, непредсказуемый IV для каждого сообщения, зашифрованного ключом. Многие люди замалчивают это, потому что «просто использовать 0x00 * 16», но любой режим шифрования потока, такой как CTR, используемый в качестве основы GCM и CCM, потеряет фундаментальную безопасность, если два сообщения зашифрованы с помощью того же IV и ключа ,