Моя команда и я работаем над системой API/Middleware, которая потребует, чтобы все запросы, сделанные на уровне промежуточного слоя, подписывали запрос с открытым и закрытым ключом для обеспечения безопасности. Большинство этих запросов будут сделаны сервером для сервера, за исключением мобильных приложений, таких как приложения для iPhone и Android, которые будут напрямую запрашивать данные из промежуточного программного обеспечения.Проверка подлинности API/промежуточного программного обеспечения - проверка целостности запроса
Мы реализовали наши библиотеки подписей, которые очень точно отражают то, как работает API-интерфейс Amazon Market, используя отсортированные строки запросов, и хеширование HMAC 256 с общедоступными и закрытыми ключами для создания подписи, которая сравнивается при получении с использованием того же алгоритма.
К сожалению, мы только что узнали (немного поздно в игре), что для того, чтобы выпускать приложения для iPhone через магазин приложений, вам необходимо выполнить определенные правительственные критерии для реализации криптографических библиотек (читайте как ограничения экспорта). Теперь нам приходится решать, следует ли нам переписывать наши алгоритмы подписи для использования гораздо более простого метода, такого как добавление закрытого ключа в строку запроса и SHA1() хеширование его для сравнения.
Я НЕНАВИГАЮ, беря очень безопасный метод и сводя его к простому хэшированию в закрытом ключе, но я недостаточно осведомлен о безопасности и криптографии, чтобы узнать, что я теряю в конечном итоге, отбросив HMAC 256. (Примечание : строка запроса уже включает в себя открытый ключ)
к примеру, мы в настоящее время заказать нашу строку запроса и выполнить операцию, как это подписать его:
$signature = base64_encode(hash_hmac('sha256', $querystring, $private_key, TRUE));
Если мы вынуждены не использовать класс крипто в наших приложениях наши подписи будут выглядеть следующим образом:
$signature = base64_encode(sha1($querystring . $private_key));
Технически мы можем соответствовать критериям использования библиотеки в нашем приложении, но я не знаю, хочу ли я рискнуть юридическими последствиями, если правительство США решит, что то, что мы делаем, точно не соответствует их юридическое описание «аутентификации».
Любые советы от вас, гуру безопасности, очень ценятся! Что я теряю, используя второй пример кода, облегчает ли взломать наше промежуточное ПО?
hmac 256 не является методом шифрования. Также функция дайджеста сообщения не является функцией шифрования. Они не могут быть более разными. – rook
Спасибо Rook. Простите мое злоупотребление терминологией, я, по общему признанию, не очень хорошо разбираюсь в лингвисте безопасности (именно по этой причине я задаю этот вопрос). Принимая во внимание то, что я пытаюсь сделать во внимание, вы видите огромную разницу в двух реализациях, учитывая, что моей конечной целью является проверка целостности данных на принимающей стороне? – Shane
Я бы использовал функцию hash_hmac, просто передав ее 'sha1' в качестве первого параметра. hmac - это не просто прямая конкатенация, это дает интересные свойства hmacs, например, они невосприимчивы к столкновениям, даже если уязвимая хеш-функция уязвима. В этом случае sha1 устойчив к столкновениям, но это не повлияет на вас. Также этот вопрос больше ориентирован на обмен файлами crypto. – rook