Заголовки контекста в ASP.NET Core

Статья
11/30/2023

Фон и теория

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

Большинство систем, поддерживающих криптографическую гибкость, делают это путем включения некоторых сведений об алгоритме внутри полезных данных. OID алгоритма, как правило, хороший кандидат для этого. Однако одна из проблем, с которыми мы столкнулись, заключается в том, что существует несколько способов указать один и тот же алгоритм: "AES" (CNG) и управляемые AesManaged, AesCryptoServiceProvider, AesCng и RijndaelManaged (с определенными параметрами) — это все то же самое, и мы должны поддерживать сопоставление всех этих элементов с правильным OID. Если разработчик хотел предоставить пользовательский алгоритм (или даже другую реализацию AES!), им придется сообщить нам о своем OID. Этот дополнительный шаг регистрации делает конфигурацию системы особенно болезненным.

Отступая назад, мы решили, что мы приближались к проблеме из неправильного направления. OID сообщает вам, что такое алгоритм, но мы на самом деле не заботимся об этом. Если нам нужно безопасно использовать одно энтропическое значение в двух разных алгоритмах, нам не нужно знать, какие алгоритмы на самом деле являются. То, что мы на самом деле заботимся о том, как они ведут себя. Любой достойный алгоритм шифра симметричного блока также является сильным псевдорандомом перемутации (PRP): исправьте входные данные (ключ, режим цепочки, IV, открытый текст) и выходные данные шифра будут отличаться от любого другого алгоритма шифра симметричного блока, учитывая те же входные данные. Аналогичным образом любая достойная хэш-функция с ключом также является сильной псевдорандомной функцией (PRF), и при условии фиксированного входного набора его выходные данные в подавляющем большинстве будут отличаться от любой другой хэш-функции с ключом.

Мы используем эту концепцию надежных PRP и PRF для создания заголовка контекста. Этот заголовок контекста по сути выступает в качестве стабильного отпечатка по алгоритмам, используемым для любой данной операции, и обеспечивает криптографическую гибкость, необходимую системой защиты данных. Этот заголовок воспроизводим и используется позже в процессе получения подраздела. Существует два разных способа построения заголовка контекста в зависимости от режимов работы базовых алгоритмов.

Шифрование в режиме CBC + проверка подлинности HMAC

Заголовок контекста состоит из следующих компонентов:

[16 бит] Значение 00 00, которое является маркером, что означает "шифрование CBC + проверка подлинности HMAC".
[32 бита] Длина ключа (в байтах, биг-эндиан) алгоритма шифра симметричного блока.
[32 бита] Размер блока (в байтах, биг-энди) алгоритма шифра симметричного блока.
[32 бита] Длина ключа (в байтах, биг-энди) алгоритма HMAC. (В настоящее время размер ключа всегда соответствует размеру дайджеста.)
[32 бита] Размер дайджеста (в байтах, биг-эндиан) алгоритма HMAC.
EncCBC(K_E, IV, ""), который является выходным результатом алгоритма шифра симметричного блока с использованием пустого строкового ввода и где IV является все равнонулевым вектором. Ниже описано K_E построение.
MAC(K_H, "")— выходные данные алгоритма HMAC с пустыми строковыми входами. Ниже описано K_H построение.

В идеале мы могли бы передать все нулевые векторы для K_E и K_H. Однако мы хотим избежать ситуации, когда базовый алгоритм проверка для существования слабых ключей перед выполнением каких-либо операций (в частности DES и 3DES), что исключает использование простого или повторяемого шаблона, например вектора со всеми нулями.

Вместо этого мы используем NIST SP800-108 KDF в режиме счетчика (см . NIST SP800-108, Sec. 5.1) с ключом нулевой длины, меткой и контекстом и HMACSHA512 в качестве базового PRF. Мы наследуем | K_E | + | K_H | байты выходных данных, а затем разлагаем результат на K_E сами по K_H себе. Математически это представлено следующим образом.

( K_E || K_H ) = SP800_108_CTR(prf = HMACSHA512, key = "", label = "", context = "")

Пример: AES-192-CBC + HMACSHA256

В качестве примера рассмотрим случай, когда алгоритм шифра симметричного блока — AES-192-CBC, а алгоритм проверки — HMACSHA256. Система создаст заголовок контекста, выполнив следующие действия.

Во-первых, давайте рассмотрим ( K_E || K_H ) = SP800_108_CTR(prf = HMACSHA512, key = "", label = "", context = ""), где | K_E | = 192 bits и | K_H | = 256 bits в соответствии с указанными алгоритмами. Это приводит к следующему K_H = A04A..00A9 примеруK_E = 5BB6..21DD:

5B B6 C9 83 13 78 22 1D 8E 10 73 CA CF 65 8E B0
61 62 42 71 CB 83 21 DD A0 4A 05 00 5B AB C0 A2
49 6F A5 61 E3 E2 49 87 AA 63 55 CD 74 0A DA C4
B7 92 3D BF 59 90 00 A9

Затем вычислить Enc_CBC (K_E, IV, "") для AES-192-CBC, заданного IV = 0* и K_E как описано выше.

result := F474B1872B3B53E4721DE19C0841DB6F

Затем вычислить MAC(K_H, "") для HMACSHA256, указанных K_H выше.

result := D4791184B996092EE1202F36E8608FA8FBD98ABDFF5402F264B1D7211536220C

При этом создается полный заголовок контекста ниже:

00 00 00 00 00 18 00 00 00 10 00 00 00 20 00 00
00 20 F4 74 B1 87 2B 3B 53 E4 72 1D E1 9C 08 41
DB 6F D4 79 11 84 B9 96 09 2E E1 20 2F 36 E8 60
8F A8 FB D9 8A BD FF 54 02 F2 64 B1 D7 21 15 36
22 0C

Этот заголовок контекста представляет собой отпечаток пары алгоритма шифрования с проверкой подлинности (шифрование AES-192-CBC + проверка HMACSHA256). Ниже приведены компоненты, как описано выше .

маркер (00 00)
Длина ключа шифра блока (00 00 00 18)
Размер блока шифра блока блоков блока (00 00 00 10)
Длина ключа HMAC (00 00 00 20)
Размер дайджеста HMAC (00 00 00 20)
Выходные данные (F4 74 - DB 6F) PRP блочного шифра и
Выходные данные (D4 79 - end)PRF HMAC.

Примечание.

Заголовок контекста проверки подлинности CBC + HMAC создается так же, независимо от того, предоставляются ли реализации алгоритмов Windows CNG или управляемыми типами SymmetricAlgorithm и KeyedHashAlgorithm. Это позволяет приложениям, работающим в разных операционных системах, надежно создавать один и тот же заголовок контекста, несмотря на то, что реализации алгоритмов отличаются от OSes. (На практике keyedHashAlgorithm не должен быть правильным HMAC. Это может быть любой тип хэш-алгоритма ключа.)

Пример: 3DES-192-CBC + HMACSHA1

Во-первых, давайте рассмотрим ( K_E || K_H ) = SP800_108_CTR(prf = HMACSHA512, key = "", label = "", context = ""), где | K_E | = 192 bits и | K_H | = 160 bits в соответствии с указанными алгоритмами. Это приводит к следующему K_H = DC4A..B464 примеруK_E = A219..E2BB:

A2 19 60 2F 83 A9 13 EA B0 61 3A 39 B8 A6 7E 22
61 D9 F8 6C 10 51 E2 BB DC 4A 00 D7 03 A2 48 3E
D1 F7 5A 34 EB 28 3E D7 D4 67 B4 64

Затем вычислительная среда Enc_CBC (K_E, IV, "") для 3DES-192-CBC, указанная IV = 0* и K_E как описано выше.

result := ABB100F81E53E10E

Затем вычислить MAC(K_H, "") для HMACSHA1, указанных K_H выше.

result := 76EB189B35CF03461DDF877CD9F4B1B4D63A7555

Это создает полный заголовок контекста, который является отпечатком пары алгоритмов шифрования с проверкой подлинности (шифрование 3DES-192-CBC + проверка HMACSHA1), показанной ниже:

00 00 00 00 00 18 00 00 00 08 00 00 00 14 00 00
00 14 AB B1 00 F8 1E 53 E1 0E 76 EB 18 9B 35 CF
03 46 1D DF 87 7C D9 F4 B1 B4 D6 3A 75 55

Компоненты разбиваются следующим образом:

маркер (00 00)
Длина ключа шифра блока (00 00 00 18)
Размер блока шифра блока блоков блока (00 00 00 08)
Длина ключа HMAC (00 00 00 14)
Размер дайджеста HMAC (00 00 00 14)
Выходные данные (AB B1 - E1 0E) PRP блочного шифра и
Выходные данные (76 EB - end)PRF HMAC.

Шифрование и проверка подлинности в режиме счетчика

Заголовок контекста состоит из следующих компонентов:

[16 бит] Значение 00 01, которое означает "шифрование GCM + проверка подлинности".
[32 бита] Длина ключа (в байтах, биг-эндиан) алгоритма шифра симметричного блока.
[32 бита] Размер nonce (в байтах, big-endian), используемый во время операций шифрования, прошедших проверку подлинности. (Для нашей системы это исправлено при размере nonce = 96 бит.)
[32 бита] Размер блока (в байтах, биг-энди) алгоритма шифра симметричного блока. (Для GCM это исправлено при размере блока = 128 бит.)
[32 бита] Размер тега проверки подлинности (в байтах, big-endian), созданный функцией шифрования с проверкой подлинности. (Для нашей системы это исправлено по размеру тега = 128 бит.)
[128 бит] Тег Enc_GCM (K_E, nonce, ""), который является выходным результатом алгоритма шифра симметричного блока, заданным пустым строковым вводом, и где nonce является 96-разрядным вектором со всеми нулевыми значениями.

K_E является производным с помощью того же механизма, что и в сценарии проверки подлинности CBC + HMAC. Тем не менее, так как здесь нет K_H в игре, у нас по сути есть | K_H | = 0, и алгоритм рухнет до следующей формы.

K_E = SP800_108_CTR(prf = HMACSHA512, key = "", label = "", context = "")

Пример: AES-256-GCM

Во-первых, позвольте K_E = SP800_108_CTR(prf = HMACSHA512, key = "", label = "", context = ""), где | K_E | = 256 bits.

K_E := 22BC6F1B171C08C4AE2F27444AF8FC8B3087A90006CAEA91FDCFB47C1B8733B8

Затем вычислить тег Enc_GCM (K_E, nonce, "") проверки подлинности для AES-256-GCM, заданный nonce = 096 и K_E как описано выше.

result := E7DCCE66DF855A323A6BB7BD7A59BE45