Вопрос или проблема
Насколько я читал, нет никаких преимуществ у MAC по сравнению с цифровой подписью, кроме того факта, что ее быстрее генерировать и обрабатывать.
Это правда? Цифровые подписи (асимметричное шифрование) кажутся достаточно быстрыми, что почти каждый веб-сайт использует их. Так что это не может быть такой уж большой недостаток на сегодняшний день.
Я упускаю что-то важное?
Только производительность является причиной использовать MAC.
Рассмотрим соединение TLS. Для каждого пакета принимающая сторона должна проверить, что пакет не был изменен при передаче злоумышленником. Таким образом, для каждого пакета отправитель должен вычислить MAC/подпись, а получатель должен ее проверить. Если вы хотите, например, скорость передачи 10 МБ/с и средний размер пакета 10 кБ, это означает, что у вас есть только доля 1 мс для вычисления или проверки подписи. Это слишком медленно для цифровой подписи.
Времени, необходимого для создания и проверки асимметричной подписи, достаточно мало, чтобы это не было проблемой, если вы делаете это один раз при установлении соединения, при условии, что у вас есть высокопроизводительное оборудование, такое как ПК, сервер или смартфон (это может быть проблемой на встроенных устройствах). Но это не сработает, если вам нужно делать это для каждого пакета.
Цифровая подпись обладает тем преимуществом, что ее может проверить сторона, которая не может сгенерировать поддельную подпись. Это не имеет значения в случае соединения TLS. Для TLS две стороны устанавливают сеансовый ключ, который является симметричным ключом, случайно сгенерированным в начале соединения. После этого только две стороны, которые знают этот ключ, — это клиент и сервер. Если клиент видит действующий MAC (который он не сгенерировал сам), его мог сгенерировать только сервер, и наоборот. Аналогичным образом, как только сеансовый ключ сгенерирован, он (а не асимметричная криптография) используется для шифрования.
(По сути, один и тот же ключ не следует использовать для разных целей, таких как MAC и шифрование, даже если он имеет правильный формат. Я немного упростил ситуацию выше. «Сеансовый ключ» на самом деле представляет собой некоторый секретный материал, из которого генерируются ключ шифрования и ключ MAC — или, в некоторых шифрах, один ключ аутентифицированного шифрования, хотя алгоритм AE затем генерирует два ключа внутри.)
Как HMAC, так и подпись могут быть использованы для проверки целостности данных и аутентификации сообщений. Однако подписи также обеспечивают свойство необратимости: имея сообщение и его подпись, вы можете доказать, что сообщение действительно было написано отправителем.
Вам может не понадобиться это свойство. Например, вы можете хотеть обмениваться сообщениями конфиденциально с кем-то, кому вы не доверяете. Если ваши сообщения подписаны, другая сторона сможет раскрыть компрометирующее сообщение и доказать, что вы его написали. Используя HMAC, вы все равно можете быть уверены в конфиденциальности разговора, но другая сторона не сможет доказать, что вы написали это компрометирующее сообщение, потому что она тоже могла его написать.
Я думаю, что мог придумать возможный ответ.
С подписью получатель (клиентское приложение) может быть уверен, что сообщение пришло от отправителя (серверное приложение). Но если клиентское приложение теперь отправляет что-то обратно на сервер (другой HTTP-запрос с некоторыми данными), сервер не может быть уверен, действительно ли сообщение пришло от того же клиентского приложения — любое потенциальное клиентское приложение могло бы использовать открытый ключ сервера для создания такого сообщения.
С другой стороны, если они делят секрет (как в HMAC), есть по крайней мере какая-то степень уверенности в том, что сообщение пришло от ожидаемого клиентского приложения.
Проблема с этим заключается в том, что секретная соль для создания MAC на самом деле не стоит много с недобросовестными клиентами (javascript или мобильные приложения), поскольку их всегда можно скомпрометировать.
Ответ или решение
Использование кодов аутентификации сообщения (MAC) вместо цифровых подписей может иметь несколько причин, несмотря на то, что обе эти технологии выполняют схожие функции, такие как проверка целостности данных и аутентификация сообщений. Ниже приведены основные аспекты, которые стоит учитывать.
### 1. Производительность
Основное преимущество MAC заключается в их быстродействии. Генерация и проверка MAC, как правило, требуют меньше вычислительных ресурсов, чем операции с цифровыми подписями, использующими асимметричное шифрование. В случае высокопроизводительных приложений, таких как защищенные соединения TLS, необходимо обеспечивать быструю обработку каждого пакета данных. Если, например, нужно добиться скорости передачи 10 МБ/с с размером пакета 10 кБ, время на создание или проверку подписи должно быть менее 1 мс. Это может оказаться невозможным при использовании цифровых подписей, особенно при больших объемах трафика.
### 2. Совместное использование ключа
MAC работает на основе симметричного ключа, который известен обеим сторонам (например, клиенту и серверу). Таким образом, если одна сторона видит действительный MAC, подписанный другой стороной, она знает, что сообщение действительно пришло от неё. В отличие от этого, цифровые подписи, несмотря на наличие свойства непередаваемости (non-repudiation), могут быть менее удобными для некоторых сценариев, когда нет необходимости в такой степени защиты.
### 3. Уровень доверия
В условиях, когда обе стороны в общении имеют доверительные отношения, использование MAC может быть более подходящим выбором. Например, в случаях, когда сообщения обменяются между двумя доверенными системами, использование MAC для аутентификации и обеспечения целостности верно выполненных данных может быть более чем достаточным.
С другой стороны, в таких сценариях, как обмен сообщениями с недоверенными клиентами (например, через веб-приложения или мобильные приложения), можно столкнуться с проблемами. Хотя MAC обеспечивает некоторую защиту, не следует забывать, что клиентские приложения могут быть скомпрометированы, и секретный ключ может быть раскрыт. Поэтому в таких случаях важно учитывать целостность и защиту секретного ключа, используются ли цифровые подписи или MAC.
### 4. Отсутствие требования к непередаваемости
Если сторонам не нужна функция непередаваемости, MAC могут быть предпочтительное решение, так как используются более простые и быстрые криптографические операции. Это может быть важно в сценариях, когда стороны предпочитают, чтобы ни одна из них не могла в будущем отклонять участие в обсуждении, что упрощает взаимодействие.
### Заключение
Каждая из технологий — MAC и цифровые подписи — имеет свои уникальные характеристики, соответственно, правильный выбор зависит от конкретных требований вашей системы. Если важна скорость и экономия ресурсов, MAC может быть предпочтительным выбором, особенно в средах с высоким уровнем активности передачи данных. Если же критичны такие аспекты, как непередаваемость и возможность проверки подлинности сторон, цифровые подписи будут более подходящими. Выбор между ними должен основываться на детальном анализе требований безопасности и производительности вашего приложения.