Таким образом, проблема, которую AWS решает здесь, заключается в том, что у них есть кортеж значений, а именно сервис, регион и текущая дата, и они хотели бы получить другой секретный ключ, который зависит от всех этих значений.
Вы можете пойти дальше и сделать это с помощью обычного PRF, но тогда вы столкнетесь с проблемой: а именно, вы не хотите иметь ситуацию, когда неверные значения любой из записей кортежа внезапно приводят к конфликтам ключей. Классическая ошибка, например. использовать прямую конкатенацию, и если они не будут осторожны, вы получите (сегодня) и (сегодня) дает один и тот же ключ. Очевидно, что задействованные здесь струны более структурированы, чем в примере, но основная проблема должна быть ясна.
Теперь самый эффективный способ решить указанную выше проблему — использовать функцию сопряжения, которая гарантии что никакие два различных входных кортежа не дают одинаковых выходных данных и, следовательно, одинаковых входных данных для PRF. Однако разработка таких функций также немного подвержена ошибкам.
я предполагать именно из-за этого AWS решила использовать эту запутанную цепочку вызовов HMAC. Теперь им не нужно беспокоиться о сложных функциях сопряжения, и все, что требуется, — это набор оценок HMAC, которые должны быть возможны практически во всех языках/средах. Тот факт, что для этого требуется не менее операций HMAC, компенсируется тем фактом, что все входные данные для получения этого ключа являются в некотором роде static, и вы можете кэшировать ключи примерно на день, если операции HMAC требуют для вас значительного вычислительного времени.
