В задачах защиты данных на уровне приложения чаще всего требуется решить одну из двух фундаментальных задач: подтвердить целостность сообщения и удостовериться в его происхождении. Для этого в Web Crypto API используются два принципиально разных механизма — HMAC и цифровая подпись.
Несмотря на внешнее сходство (оба механизма позволяют проверить, что данные не были изменены), их криптографическая природа, модель доверия и сценарии применения различаются настолько существенно, что их корректное понимание определяет архитектуру безопасности веб-приложений.
HMAC (Hash-based Message Authentication Code) основан на симметричной криптографии. Он использует общий секретный ключ для генерации и проверки кода аутентификации сообщения.
HMAC строится поверх хеш-функции (например, SHA-256):
Один и тот же секретный ключ используется для:
Без знания ключа невозможно подделать корректный код
В Web Crypto API это реализуется через алгоритм "HMAC" с
указанием хеш-функции:
const key = await crypto.subtle.generateKey(
{
name: "HMAC",
hash: "SHA-256"
},
true,
["sign", "verify"]
);const encoder = new TextEncoder();
const data = encoder.encode("сообщение");
const signature = await crypto.subtle.sign(
"HMAC",
key,
data
);
const isValid = await crypto.subtle.verify(
"HMAC",
key,
signature,
data
);HMAC предполагает, что обе стороны уже обладают одинаковым секретом. Это означает:
Цифровая подпись основана на асимметричных ключах:
Это фундаментально меняет модель безопасности.
В Web Crypto API используется алгоритм
"RSASSA-PKCS1-v1_5" или "ECDSA":
const keyPair = await crypto.subtle.generateKey(
{
name: "RSASSA-PKCS1-v1_5",
modulusLength: 2048,
publicExponent: new Uint8Array([1, 0, 1]),
hash: "SHA-256"
},
true,
["sign", "verify"]
);const encoder = new TextEncoder();
const data = encoder.encode("сообщение");
const signature = await crypto.subtle.sign(
"RSASSA-PKCS1-v1_5",
keyPair.privateKey,
data
);const isValid = await crypto.subtle.verify(
"RSASSA-PKCS1-v1_5",
keyPair.publicKey,
signature,
data
);Безопасность полностью зависит от сохранности одного ключа. Если он известен:
Таким образом HMAC обеспечивает только целостность и аутентичность в рамках закрытого канала.
Здесь важен факт владения приватным ключом:
Это создаёт модель “проверяемого происхождения”, а не просто “общего секрета”.
Проблема масштабирования возникает при увеличении числа участников:
Масштабируется естественно:
Попытка использовать HMAC там, где ключи распространяются между клиентами, приводит к фундаментальной уязвимости: любой клиент становится потенциальным подписантом.
Применение асимметричных алгоритмов там, где достаточно HMAC, приводит к избыточной нагрузке и усложнению системы без реальной выгоды.
| Характеристика | HMAC | Цифровая подпись |
|---|---|---|
| Тип криптографии | Симметричная | Асимметричная |
| Количество ключей | Один | Пара |
| Скорость | Высокая | Ниже |
| Масштабируемость | Ограниченная | Высокая |
| Распределение доверия | Общий секрет | Публичная проверка |
| Основной риск | Утечка ключа | Компрометация приватного ключа |
CryptoKeysign и verifyHMAC отвечает на вопрос:
“Знает ли отправитель общий секрет?”
Цифровая подпись отвечает на вопрос:
“Кто именно подписал данные?”
HMAC — это механизм доверия внутри замкнутой системы.
Цифровая подпись — это механизм доверия в открытой системе, где участники не обязаны доверять друг другу заранее.
Разделение этих подходов является базовым принципом проектирования безопасных протоколов в Web Crypto API и определяет архитектуру любой криптографически защищённой веб-системы.