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

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

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

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

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

1

Решение

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

  1. Используйте «аутентифицированное шифрование» (AE) или же «аутентифицированное шифрование со связанными данными» (AEAD) шифр для этого. Шифры AE (AD) предоставляют «тег аутентификации» поверх текста шифра, либо за один проход, либо с повторяющейся обработкой текста шифрованного текста. Примеры (возможно, доступны в любой используемой вами библиотеке шифров PHP): GCM, EAX, а также CCM. Это рекомендуется, поскольку операция дешифрования завершится неудачно, если тег аутентификации не проверен, и необходим только один общий секретный ключ (ключ).
  2. Вы можете создать систему самостоятельно, используя криптографические примитивы. Это менее идеально, так как вы несете ответственность за более независимые части, вам нужно управлять большим количеством ключей (если у вас есть доступ к Внедрение OMAC, Вы можете использовать тот же ключ), и ваша индивидуальная конструкция не проверяется третьими лицами (коллективная работа в Интернете). Если вы идете по этому пути, вам нужно помнить некоторые ключевые детали:
    • Используйте сильный код аутентификации сообщений на основе хеша (HMAC) такие как HMAC / SHA-256, -384 или -512. Не используйте SHA-1 или MD5, так как они легко перебираются.
    • Проверьте HMAC до расшифровка зашифрованного текста. Любой сбой HMAC означает, что весь текст шифра должен быть отброшен. Вы можете помнить это (на стороне генерации) как Зашифровать затем MAC, и если вы будете искать его, вы увидите, что несоблюдение этого совета является источником многих криптографических уязвимостей и уязвимостей реализации.
    • Проверьте HMAC с помощью постоянное время алгоритм (т. е. не использовать сравнение равенства строк при коротком замыкании, по умолчанию в Java). PHP обеспечивает hash_equals сделать это. Вот быстрое объяснение времени атаки и обзор кода примера PHP.

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

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

2

Другие решения

Других решений пока нет …

А ты уже прошел курс программирования? Супер скидка!
Прокачать скилл $$$
×