SP 800-38D · Рекомендация по режимам работы блочных шифров: режим Галуа/счётчика (GCM) и GMAC

Рекомендация по режимам работы блочных шифров: режим Галуа/счётчика (GCM) и GMAC

Специальная публикация NIST 800-38D

Ноябрь 2007 г.

Моррис Дворкин

К О М П Ь Ю Т Е Р Н А Я   Б Е З О П А С Н О С Т Ь

Национальный институт стандартов и технологий (NIST)

Министерство торговли США

Рекомендация по режимам работы блочных шифров: режим Галуа/счётчика (GCM) и GMAC

Специальная публикация NIST 800-38D

Моррис Дворкин

К О М П Ь Ю Т Е Р Н А Я   Б Е З О П А С Н О С Т Ь

Отдел компьютерной безопасности
Лаборатория информационных технологий
Национальный институт стандартов и технологий
Гейтерсберг, штат Мэриленд 20899-8930

Ноябрь 2007 г.

Министерство торговли США
Карлос М. Гутьеррес, министр

Национальный институт стандартов и технологий
Джеймс М. Тёрнер, исполняющий обязанности директора

Специальная публикация NIST 800-38D

Отчёты по технологиям информационной безопасности

Лаборатория информационных технологий (ITL) Национального института стандартов и технологий (NIST) содействует экономике и общественному благосостоянию США, обеспечивая техническое лидерство в области национальной инфраструктуры измерений и стандартов. ITL разрабатывает испытания, методы испытаний, справочные данные, реализации для подтверждения концепции и технические анализы для содействия развитию и продуктивному использованию информационных технологий. В обязанности ITL входит разработка технических, физических, административных и управленческих стандартов и руководств для экономически эффективного обеспечения безопасности и конфиденциальности чувствительной несекретной информации в федеральных компьютерных системах. В настоящей Специальной публикации серии 800 сообщается об исследованиях, руководствах и информационно-разъяснительной деятельности ITL в области компьютерной безопасности, а также о её совместной деятельности с промышленностью, правительством и академическими организациями.

Некоторые коммерческие организации, оборудование или материалы могут быть указаны в настоящем документе, чтобы надлежащим образом описать экспериментальную процедуру или концепцию. Такое указание не предназначено для подразумевания рекомендации или одобрения со стороны Национального института стандартов и технологий; также оно не предназначено для подразумевания того, что данные организации, материалы или оборудование обязательно являются наилучшими доступными для этой цели.

Специальная публикация Национального института стандартов и технологий 800-38D
Natl. Inst. Stand. Technol. Spec. Publ. 800-38D 37 pages (November 2007)
CODEN: NSPUE2

ii

Специальная публикация NIST 800-38D

Благодарности

Автор хотел бы поблагодарить Дэвида Макгрю, который совместно изобрёл GCM и представил его в NIST, а также коллег автора, которые рецензировали проекты настоящего документа и внесли вклад в его разработку, в особенности Элейн Баркер, Джона Келси, Аллена Рогински, Донну Додсон, Тима Полка и Билла Берра. Автор также с благодарностью отмечает многочисленные замечания представителей государственного и частного секторов, способствовавшие повышению качества и полезности этой публикации.

iii

Специальная публикация NIST 800-38D

Аннотация

Настоящая Рекомендация определяет режим Галуа/счётчика (GCM) — алгоритм для аутентифицированного шифрования со связанными данными — и его специализацию GMAC для формирования кода аутентификации сообщения (MAC) по данным, которые не шифруются. GCM и GMAC являются режимами работы для базового одобренного симметричного блочного шифра с секретным ключом.

КЛЮЧЕВЫЕ СЛОВА: аутентифицированное шифрование; аутентификация; блочный шифр; конфиденциальность; криптография; шифрование; информационная безопасность; режим работы.

iv

NIST Special Publication 800-38D

Содержание

1. ЦЕЛЬ ...........................................................................................................................................................1
2. ПОЛНОМОЧИЯ .....................................................................................................................................................1
3. ВВЕДЕНИЕ ..............................................................................................................................................1
4. ОПРЕДЕЛЕНИЯ, СОКРАЩЕНИЯ И ОБОЗНАЧЕНИЯ .................................................................................2
   1. ОПРЕДЕЛЕНИЯ И СОКРАЩЕНИЯ .............................................................................................................2
   2. ОБОЗНАЧЕНИЯ ....................................................................................................................................................5
      1. Переменные ................................................................................................................................................5
      2. Операции и функции .............................................................................................................................6
5. ЭЛЕМЕНТЫ GCM ......................................................................................................................................7
   1. БЛОЧНЫЙ ШИФР ............................................................................................................................................7
   2. ДВЕ ФУНКЦИИ GCM ...............................................................................................................................7
      1. Функция аутентифицированного шифрования .......................................................................8
      2. Функция аутентифицированного расшифрования ...................................................................9
   3. ПРИМИТИВЫ ДЛЯ КОНФИДЕНЦИАЛЬНОСТИ И АУТЕНТИФИКАЦИИ ........................................................................9
6. МАТЕМАТИЧЕСКИЕ КОМПОНЕНТЫ GCM ...........................................................................................10
   1. ПРИМЕРЫ ОСНОВНЫХ ОПЕРАЦИЙ И ФУНКЦИЙ НАД СТРОКАМИ .............................................................10
   2. ФУНКЦИЯ ИНКРЕМЕНТИРОВАНИЯ ........................................................................................................................11
   3. ОПЕРАЦИЯ УМНОЖЕНИЯ НАД БЛОКАМИ ................................................................................................11
   4. ФУНКЦИЯ GHASH ...................................................................................................................................12
   5. ФУНКЦИЯ GCTR ......................................................................................................................................13
7. СПЕЦИФИКАЦИЯ GCM .........................................................................................................................14
   1. АЛГОРИТМ ДЛЯ ФУНКЦИИ АУТЕНТИФИЦИРОВАННОГО ШИФРОВАНИЯ ..............................................................14
   2. АЛГОРИТМ ДЛЯ ФУНКЦИИ АУТЕНТИФИЦИРОВАННОГО РАСШИФРОВАНИЯ ..............................................................16
8. ТРЕБОВАНИЕ УНИКАЛЬНОСТИ ДЛЯ IV И КЛЮЧЕЙ ..............................................................................18
   1. УСТАНОВЛЕНИЕ КЛЮЧА ...............................................................................................................................19
   2. КОНСТРУКЦИИ IV ..................................................................................................................................19
      1. Детерминированная конструкция ..................................................................................................20
      2. Конструкция на основе RBG .....................................................................................................................20
   3. ОГРАНИЧЕНИЯ НА ЧИСЛО ВЫЗОВОВ .....................................................................................................21
9. ПРАКТИЧЕСКИЕ СООБРАЖЕНИЯ ПО ВАЛИДАЦИИ РЕАЛИЗАЦИЙ .........................................................22
   1. СООБРАЖЕНИЯ ПО ПРОЕКТИРОВАНИЮ .........................................................................................................22
   2. ЭКСПЛУАТАЦИОННЫЕ СООБРАЖЕНИЯ ......................................................................................................23
10. СООТВЕТСТВИЕ ...........................................................................................................................................24

ПРИЛОЖЕНИЕ A: ВАЖНОСТЬ ТРЕБОВАНИЯ УНИКАЛЬНОСТИ ДЛЯ IV .....................................25

ПРИЛОЖЕНИЕ B: ОБЕСПЕЧЕНИЕ АУТЕНТИЧНОСТИ ...........................................................................................26

ПРИЛОЖЕНИЕ C: ТРЕБОВАНИЯ И РУКОВОДСТВА ПО ИСПОЛЬЗОВАНИЮ КОРОТКИХ ТЕГОВ ....................................28

ПРИЛОЖЕНИЕ D: ЗАЩИТА ОТ ПОВТОРНОГО ВОСПРОИЗВЕДЕНИЯ СООБЩЕНИЙ .............................................................30

ПРИЛОЖЕНИЕ E: БИБЛИОГРАФИЯ ..........................................................................................................................31

Список рисунков

Рисунок 1: GHASH_H (X₁ || X₂ || ... || X_m) = Y .................................................................................13

Рисунок 2: GCTR_K (ICB, X₁ || X₂ || ... || X_n^*) = Y₁ || Y₂ || ... || Y_n^* .....................................................14

Рисунок 3: GCM-AE_K (IV, P, A) = (C, T) ......................................................................................16

Рисунок 4: GCM-AD_K (IV, C, A, T) = P or FAIL ...........................................................................18

Список таблиц

Таблица 1: Ограничения для 32-битных тегов ..........................................................................................29

Таблица 2: Ограничения для 64-битных тегов ..........................................................................................29

1   Цель

Настоящая публикация является четвёртой частью серии рекомендаций, относящихся к режимам работы блочных шифров с симметричным ключом.

2   Полномочия

Этот документ разработан Национальным институтом стандартов и технологий (National Institute of Standards and Technology, NIST) в целях исполнения его установленных законом обязанностей в соответствии с Федеральным законом об управлении информационной безопасностью (Federal Information Security Management Act (FISMA) of 2002, Public Law 107-347).

NIST отвечает за разработку стандартов и руководств, включая минимальные требования, для обеспечения надлежащей информационной безопасности всех операций и активов ведомств, однако такие стандарты и руководства не применяются к системам национальной безопасности. Настоящее руководство согласуется с требованиями циркуляра A-130 Управления по вопросам управления и бюджета (Office of Management and Budget, OMB), раздел 8b(3), Securing Agency Information Systems, в соответствии с анализом, приведённым в A-130, приложение IV: Analysis of Key Sections. Дополнительные сведения приведены в A-130, приложении III.

Эта Рекомендация подготовлена для использования федеральными ведомствами. Она может использоваться негосударственными организациями на добровольной основе и не является объектом авторского права. (NIST был бы признателен за указание авторства.)

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

Тестирование соответствия реализаций режима работы, который определён в этой части Рекомендации, будет проводиться в рамках Программы валидации криптографических модулей (Cryptographic Module Validation Program, CMVP) — совместной инициативы NIST и Центра безопасности связи Правительства Канады (Communications Security Establishment of the Government of Canada). Реализация режима работы должна соответствовать требованиям настоящей Рекомендации, чтобы быть валидированной в рамках CMVP. Требования настоящей Рекомендации обозначаются словом «shall».

3   Введение

Настоящая Рекомендация определяет алгоритм под названием режим Галуа/счётчика (Galois/Counter Mode, GCM) для аутентифицированного шифрования со связанными данными. GCM строится из одобренного блочного шифра с симметричным ключом и размером блока 128 бит, такого как алгоритм Advanced Encryption Standard (AES), определённый в Federal Information Processing Standard (FIPS) Pub. 197 [2]. Таким образом, GCM является режимом работы алгоритма AES.

GCM обеспечивает конфиденциальность данных, используя для шифрования разновидность режима счётчика. GCM обеспечивает аутентичность конфиденциальных данных (до примерно 64 гигабайт за один вызов), используя универсальную хеш-функцию, определённую над бинарным полем Галуа (то есть конечным полем). GCM также может обеспечивать аутентификацию дополнительных данных (практически неограниченной длины за один вызов), которые не шифруются.

Если входные данные GCM ограничены данными, которые не должны шифроваться, то получающаяся специализация GCM, называемая GMAC, является просто режимом аутентификации входных данных. В остальной части этого документа утверждения о GCM также применимы к GMAC.

GCM обеспечивает более надёжную аутентификацию, чем (некриптографическая) контрольная сумма или код обнаружения ошибок; в частности, GCM может обнаруживать как 1) случайные изменения данных, так и 2) преднамеренные несанкционированные изменения.

Две функции GCM называются аутентифицированным шифрованием и аутентифицированным расшифрованием. Каждая из этих функций сравнительно эффективна и допускает распараллеливание; следовательно, реализации с высокой пропускной способностью возможны как в аппаратном, так и в программном обеспечении. GCM обладает рядом других полезных характеристик, включая следующие:

• Функции GCM являются «потоковыми» в том смысле, что длины конфиденциальных данных и дополнительных, неконфиденциальных данных не требуются заранее; вместо этого длины могут вычисляться по мере поступления и обработки данных.
• Для функций GCM требуется только прямое направление базового блочного шифра (то есть обратное направление не требуется).
• Аутентичность защищённых данных может быть проверена независимо от восстановления конфиденциальных данных из их зашифрованной формы.
• Если уникальная строка инициализации предсказуема и длина конфиденциальных данных известна, то вызовы блочного шифра в механизме шифрования GCM могут быть предварительно вычислены.
• Если часть или все дополнительные, неконфиденциальные данные фиксированы, то соответствующие элементы механизма аутентификации GCM могут быть предварительно вычислены.

Важное предостережение при использовании GCM состоит в том, что нарушение требования раздела 8 об уникальности строк инициализации может почти полностью скомпрометировать обеспечение безопасности, как подробно изложено в ссылке [5] и кратко приведено в приложении A. Поэтому этот режим работы не следует развёртывать, если не обеспечено соблюдение этого требования уникальности. Некоторые практические соображения дополнительно обсуждаются в разделах 9.1 и 9.2.

Разработчиками GCM являются McGrew и Viega. Они представили GCM в NIST в ссылке [6] и подробно рассматривают его безопасность и производительность в ссылке [7].

4   Определения, сокращения и обозначения

4.1   Определения и сокращения

Специальная публикация NIST 800-38D

4.2 Обозначения

4.2.1 Переменные

A

Дополнительные аутентифицируемые данные

C

Шифротекст.

H

Подключ хеширования.

ICB

Начальный блок счётчика

IV

Вектор инициализации.

K

Ключ блочного шифра.

P

Открытый текст.

R

Константа в алгоритме для операции умножения блоков.

T

Тег аутентификации.

t

Битовая длина тега аутентификации.

4.2.2 Операции и функции

0^s

Битовая строка, состоящая из s битов «0».

CIPH_K(X)

Выход функции прямого шифрования блочного шифра при ключе K, применённой к блоку X.

GCTR_K(ICB, X)

Выход функции GCTR для заданного блочного шифра с ключом K, применённой к битовой строке X с начальным блоком счётчика ICB.

GHASH_H(X)

Выход функции GHASH при подключе хеширования H, применённой к битовой строке X.

inc_s(X)

Результат увеличения на 1 по модулю 2^s крайних правых s битов битовой строки X, рассматриваемых как двоичное представление целого числа.

int(X)

Целое число, для которого битовая строка X является двоичным представлением.

len(X)

Битовая длина битовой строки X.

LSB_s(X)

Битовая строка, состоящая из s крайних правых битов битовой строки X.

MSB_s(X)

Битовая строка, состоящая из s крайних левых битов битовой строки X.

⌈x⌉

Наименьшее целое число, не меньшее действительного числа x.

[x]_s

Двоичное представление неотрицательного целого числа x в виде строки из s битов, где x<2^s.

X >> 1

Битовая строка, получаемая отбрасыванием крайнего правого бита битовой строки X и добавлением бита «0» слева.

X || Y

Конкатенация двух битовых строк X и Y.

X ⊕ Y

Побитовое исключающее ИЛИ двух битовых строк X и Y одинаковой длины.

X • Y

Произведение двух блоков X и Y, рассматриваемых как элементы некоторого двоичного поля Галуа.

Xⁱ

Для положительного целого числа i — i-я степень X относительно произведения «•».

x·y

Произведение двух целых чисел x и y.

5 Элементы GCM

Элементы GCM, а также связанные с ними обозначения и требования вводятся в трёх следующих разделах. Базовый блочный шифр и ключ рассматриваются в разд. 5.1. Элементы данных функций аутентифицированного шифрования и аутентифицированного расшифрования GCM рассматриваются в разд. 5.2. Криптографические примитивы для конфиденциальности и аутентификации в рамках этих двух функций рассматриваются в разд. 5.3.

5.1 Блочный шифр

Операции GCM зависят от выбора базового симметричного ключевого блочного шифра и поэтому могут рассматриваться как режим работы (сокращённо — режим) блочного шифра. Ключ GCM является ключом блочного шифра (сокращённо — ключом).

Для любого заданного ключа базовый блочный шифр режима состоит из двух функций, обратных друг другу. Выбор блочного шифра включает назначение одной из двух функций блочного шифра функцией прямого шифрования, как в спецификации алгоритма AES в ссылке [2]. GCM не использует функцию обратного шифрования.

Функция прямого шифрования является перестановкой над битовыми строками фиксированной длины; эти строки называются блоками. Длина блока называется размером блока. Ключ обозначается K, а получаемая функция прямого шифрования блочного шифра обозначается CIPH_K.

Базовый блочный шифр ДОЛЖЕН (SHALL) быть одобренным, размер блока ДОЛЖЕН (SHALL) составлять 128 битов, а размер ключа ДОЛЖЕН (SHALL) быть не менее 128 битов. Ключ ДОЛЖЕН (SHALL) генерироваться равномерно случайным образом или почти равномерно случайным образом, то есть так, чтобы вероятность генерации каждого возможного ключа была (почти) одинаковой. Следовательно, ключ с высокой вероятностью будет свежим, то есть не равным никакому предыдущему ключу. Ключ ДОЛЖЕН (SHALL) быть секретным и ДОЛЖЕН (SHALL) использоваться исключительно для GCM с выбранным блочным шифром. Дополнительные требования к установлению ключей и управлению ими рассматриваются в разд. 8.1.

5.2 Две функции GCM

Две функции, составляющие GCM, называются аутентифицированным шифрованием и аутентифицированным расшифрованием. Функция аутентифицированного шифрования шифрует конфиденциальные данные и вычисляет тег аутентификации как по конфиденциальным данным, так и по любым дополнительным неконфиденциальным данным. Функция аутентифицированного расшифрования расшифровывает конфиденциальные данные при условии проверки тега.

Реализация МОЖЕТ (MAY) ограничивать вход неконфиденциальными данными, то есть не включать никаких конфиденциальных данных. Получающийся вариант GCM называется GMAC. Для GMAC функции аутентифицированного шифрования и расшифрования становятся функциями создания и проверки тега аутентификации по неконфиденциальным данным.

Требования и обозначения для входных и выходных данных этих функций рассматриваются в разд. 5.2.1 и 5.2.2. Алгоритмы вычисления этих функций приведены в разд. 7.

5.2.1 Функция аутентифицированного шифрования

5.2.1.1 Входные данные

При выборе одобренного блочного шифра и ключа функция аутентифицированного шифрования имеет три входные строки:

• открытый текст, обозначаемый P;
• дополнительные аутентифицируемые данные (AAD), обозначаемые A; и
• вектор инициализации (IV), обозначаемый IV.

Открытый текст и AAD — две категории данных, которые защищает GCM. GCM защищает подлинность открытого текста и AAD; GCM также защищает конфиденциальность открытого текста, тогда как AAD остаётся открытым. Например, в сетевом протоколе AAD могут включать адреса, порты, номера последовательности, номера версий протокола и другие поля, указывающие, как следует обрабатывать открытый текст.

IV по существу является одноразовым значением (nonce), то есть значением, уникальным в заданном контексте, которое определяет вызов функции аутентифицированного шифрования для защищаемых входных данных. Требование уникальности IV (и ключей) точно сформулировано в разд. 8, а два подхода к построению IV приведены в разд. 8.2. Практические соображения по обеспечению этого требования рассматриваются в разд. 9.1 и 9.2. Критическая важность уникальности IV подробно изложена в ссылке [5] и кратко изложена в приложении A.

Битовые длины входных строк функции аутентифицированного шифрования ДОЛЖНЫ (SHALL) удовлетворять следующим требованиям:

• len(P) ≤ 2³⁹-256;
• len(A) ≤ 2⁶⁴-1;
• 1 ≤ len(IV) ≤ 2⁶⁴-1.

Хотя GCM определён над битовыми строками, битовые длины открытого текста, AAD и IV ДОЛЖНЫ (SHALL) быть кратны 8, чтобы эти значения были байтовыми строками.

Реализация МОЖЕТ (MAY) дополнительно ограничивать битовые длины этих входных данных в соответствии с приведёнными выше требованиями; например, реализация МОЖЕТ (MAY) устанавливать меньшие максимальные значения. Битовые длины, допускаемые реализацией, называются поддерживаемыми битовыми длинами. Для всей реализации, независимо от ключа, СЛЕДУЕТ (SHOULD) установить единый набор поддерживаемых битовых длин для каждого из трёх входных данных.

Для IV реализациям СЛЕДУЕТ (RECOMMENDED) ограничить поддержку длиной 96 битов, чтобы способствовать совместимости, эффективности и простоте проектирования.

5.2.1.2 Выходные данные

Следующие две битовые строки составляют выходные данные функции аутентифицированного шифрования:

NIST Special Publication 800-38D

• Шифротекст, обозначаемый C, битовая длина которого совпадает с битовой длиной открытого текста.
• Тег аутентификации, или для краткости тег, обозначаемый T.

Битовая длина тега, обозначаемая t, является параметром безопасности, как обсуждается в Приложении B. В общем случае t может принимать любое из следующих пяти значений: 128, 120, 112, 104 или 96. Для некоторых применений t может быть равно 64 или 32; указания по использованию этих двух длин тега, включая требования к длине входных данных и сроку службы ключа в этих случаях, приведены в Приложении C.

Реализация НЕ ДОЛЖНА (SHALL NOT) поддерживать значения t, отличные от семи вариантов, указанных в предыдущем абзаце. Реализация МОЖЕТ (MAY) ограничить поддержку всего одним из этих значений. С каждым ключом ДОЛЖНО (SHALL) быть связано одно фиксированное значение t из числа поддерживаемых вариантов.

5.2.2 Функция аутентифицированного расшифрования

При выбранных одобренном блочном шифре, ключе и связанной длине тега входными данными функции аутентифицированного расшифрования являются значения IV, A, C и T, как описано выше в разд. 5.2.1. Результатом является один из следующих вариантов:

• открытый текст P, соответствующий шифротексту C; либо
• специальный код ошибки, обозначаемый в настоящем документе FAIL.

Результат P указывает, что T является корректным тегом аутентификации для IV, A и C; в противном случае результатом является FAIL. Гарантии аутентификации, которые можно вывести в каждом случае, обсуждаются в Приложении B.

Значения len(C), len(A) и len(IV), которые реализация поддерживает для функции аутентифицированного расшифрования, ДОЛЖНЫ (SHALL) быть такими же, как значения len(P), len(A) и len(IV), которые реализация поддерживает для функции аутентифицированного шифрования.

5.3 Примитивы конфиденциальности и аутентификации

Механизм обеспечения конфиденциальности открытого текста в GCM представляет собой вариант режима счётчика [10] с особой функцией инкрементирования, обозначаемой inc32, для генерации необходимой последовательности блоков счётчика. Первый блок счётчика для шифрования открытого текста генерируется инкрементированием блока, генерируемого из IV.

Механизм аутентификации в GCM основан на хеш-функции, называемой GHASH¹, которая использует умножение на фиксированный параметр, называемый хеш-подключом, в двоичном поле Галуа.

¹ Разработчики GCM определяют GHASH несколько иначе, добавляя кодировки длин двух её аргументов. В настоящей Рекомендации эти кодировки вместо этого включены в определения функций аутентифицированного шифрования/расшифрования. Спецификации функций аутентифицированного шифрования/расшифрования в конечном итоге эквивалентны, но упрощённая версия GHASH в настоящей Рекомендации не обладает всеми свойствами, которые показаны для определения GHASH, данного разработчиками, в ссылке [7].

Хеш-подключ, обозначаемый H, генерируется применением блочного шифра к «нулевому» блоку. Полученный экземпляр этой хеш-функции, обозначаемый GHASHH, используется для сжатия кодировки AAD и шифротекста в один блок, который затем шифруется для получения тега аутентификации.

GHASH является хеш-функцией с ключом, но сама по себе не является криптографической хеш-функцией. Настоящая Рекомендация одобряет GHASH только для использования в контексте GCM.

Промежуточные значения при выполнении функций GCM ДОЛЖНЫ (SHALL) быть секретными. В частности, это требование исключает систему, в которой GCM реализован с публичным использованием хеш-подключа для иной цели, например как непредсказуемого значения или значения проверки целостности ключа.

6 Математические компоненты GCM

В этом разделе представлены математические компоненты, встречающиеся в спецификациях функций аутентифицированного шифрования и аутентифицированного расшифрования в разд. 7 ниже. Примеры базовых операций и функций над битовыми строками приведены в разд. 6.1. Функция инкрементирования определена в разд. 6.2. Алгоритм 1 для «умножения» блоков определён в разд. 6.3. Алгоритм 2 для функции GHASH, построенной на этом умножении, определён в разд. 6.4. Алгоритм 3 для функции GCTR определён в разд. 6.5.

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

6.1 Примеры базовых операций и функций над строками

В этом документе бит «0» и бит «1» обозначаются шрифтом courier, чтобы помочь отличить их от целых чисел 0 и 1.

Для вещественного числа x функция округления вверх, обозначаемая ⎡x⎤, есть наименьшее целое число, не меньшее x. Например, ⎡2.1⎤ = 3, а ⎡4⎤ = 4.

Для положительного целого числа s 0s обозначает строку, состоящую из s битов «0». Например, 08 = 00000000.

Операция конкатенации битовых строк обозначается ||; например, 001 || 10111 = 00110111.

Для битовых строк равной длины операция исключающего ИЛИ (XOR), обозначаемая ⊕, задаёт сложение по модулю 2 битов в каждой битовой позиции, то есть без переносов. Например, 10011 ⊕ 10101 = 00110.

Для битовой строки X её битовая длина обозначается len(X). Например, len(00010)=5.

Для битовой строки X и неотрицательного целого числа s такого, что len(X)≥s, функции LSBs(X) и MSBs(X) возвращают соответственно s наименее значимых (то есть самых правых) битов и s наиболее значимых (то есть самых левых) битов X. Например, LSB3(111011010) = 010, а MSB4(111011010) = 1110.

Для битовой строки X функция (однократного) сдвига вправо, обозначаемая X >> 1, есть MSBlen(X)(0 || X). Например, 0110111 >> 1 = 0011011.

Для положительного целого числа s и неотрицательного целого числа x, меньшего 2s, функция преобразования целого числа в строку, обозначаемая [x]s, является двоичным представлением x в виде строки битовой длины s с наименее значимым битом справа. Например, для целого числа 39 (в десятичной системе) двоичное представление (в системе с основанием 2) равно 100111, поэтому [39]8 = 00100111.

Для (непустой) битовой строки X функция преобразования строки в целое число, обозначаемая int(X), есть целое число x, такое что [x]len(X) = X. Иными словами, int(X) — это неотрицательное целое число, меньшее 2len(X), двоичным представлением которого является X. Например, int(00011010) = 26.

6.2 Функция инкрементирования

Для положительного целого числа s и битовой строки X, такой что len(X)≥s, определим s-битовую функцию инкрементирования, обозначаемую incs(X), следующим образом:

incs(X)=MSBlen(X)-s(X) || [int(LSBs(X))+1 mod 2s]s

Иными словами, функция увеличивает на единицу самые правые s битов строки, рассматриваемые как двоичное представление целого числа, по модулю 2s; остальные, самые левые len(X)-s битов остаются неизменными.

6.3 Операция умножения над блоками

Пусть R — битовая строка 11100001 || 0120. Для двух блоков X и Y Алгоритм 1 ниже вычисляет блок «произведения», обозначаемый X • Y:

Алгоритм 1: X • Y

Входные данные:

блоки X, Y.

Выходные данные:

блок X • Y.

Шаги:

1. Пусть x₀x₁…x₁₂₇ обозначает последовательность битов в X.
2. Пусть Z0 = 0128 и V0 = Y.
3. Для i = 0 до 127 вычислить блоки Zi+1 и Vi+1 следующим образом:

             ⎧ Zi             если xi = 0;
   Zi+1 = ⎨
             ⎩ Zi ⊕ Vi       если xi = 1.
   
             ⎧ Vi >> 1                 если LSB1(Vi) = 0;
   Vi+1 = ⎨
             ⎩ (Vi >> 1) ⊕ R           если LSB1(Vi) = 1.

4. Вернуть Z128.

Операция • над (парами) 2128 возможных блоков соответствует операции умножения в двоичном поле Галуа (конечном поле) из 2128 элементов. Фиксированный блок R определяет представление этого поля как модульное умножение двоичных многочленов степени меньше 128. Соглашение об интерпретации строк как многочленов — «little endian»: то есть если u является переменной многочлена, то блок x₀x₁…x₁₂₇ соответствует многочлену x₀ + x₁u + x₂u² + … + x₁₂₇u¹²⁷. Операция XOR используется для сложения коэффициентов «подобных» членов при умножении. Модулем редукции является многочлен степени 128, соответствующий R || 1. Ссылка [6] подробно рассматривает это поле.

Для положительного целого числа i i-я степень блока X при этой операции умножения обозначается Xⁱ. Например, H2=H•H, H3=H•H•H и т. д.

6.4 Функция GHASH

Алгоритм 2 ниже задаёт функцию GHASH:

Алгоритм 2: GHASH_H(X)

Предварительные условия:

блок H, хеш-подключ.

Входные данные:

битовая строка X, такая что len(X) = 128m для некоторого положительного целого числа m.

Выходные данные:

блок GHASHH(X).

Шаги:

1. Пусть X₁, X₂, …, X_m-1, X_m обозначают единственную последовательность блоков, такую что X = X1 || X2 || … || Xm-1 || Xm.
2. Пусть Y0 будет «нулевым блоком», 0128.
3. Для i = 1, …, m пусть Yi = (Yi-1 ⊕ Xi) • H.
4. Вернуть Ym.

Фактически функция GHASH вычисляет X1•Hm ⊕ X2•Hm-1 ⊕ … ⊕ Xm-1•H2 ⊕ Xm•H. Ссылка [6] описывает методы оптимизации реализаций GHASH как в аппаратных, так и в программных средствах.

Функция GHASH проиллюстрирована на рисунке 1 ниже без нулевого блока Y0, исключающее ИЛИ которого с X1 не изменяет X1.

6.5 Функция GCTR

Алгоритм 3 ниже задаёт функцию GCTR. Предлагаемое обозначение не указывает выбор лежащего в основе блочного шифра.

Алгоритм 3: GCTR_K(ICB, X)

Предварительные условия:

одобренный блочный шифр CIPH с размером блока 128 бит;
ключ K.

Входные данные:

начальный блок счётчика ICB;
битовая строка X произвольной длины.

Выходные данные:

битовая строка Y битовой длины len(X).

Шаги:

1. Если X — пустая строка, вернуть пустую строку в качестве Y.
2. Пусть n = ⎡len(X)/128⎤.
3. Пусть X₁, X₂, …, X_n-1, X_n^* обозначают единственную последовательность битовых строк, такую что X = X1 || X2 || … || Xn−1 || Xn*; X₁, X₂, …, X_n-1 являются полными блоками.²
4. Пусть CB1 = ICB.
5. Для i = 2 до n пусть CBi = inc32(CBi-1).
6. Для i = 1 до n−1 пусть Yi = Xi ⊕ CIPHK(CBi).
7. Пусть Yn* = Xn* ⊕ MSBlen(Xn*)(CIPHK(CBn)).
8. Пусть Y = Y1 || Y2 || … || Yn*.
9. Вернуть Y.

² Следовательно, X_n^* является либо полным блоком, либо непустым частичным блоком, и если 1 ≤ len(X) ≤ 128, то X = X1*.

На шагах 1 и 2 входная строка произвольной длины разбивается на последовательность блоков в максимально возможной степени, так что только самая правая строка последовательности может быть «частичным» блоком. На шагах 3 и 4 функция 32-битного инкрементирования итеративно применяется к входному начальному блоку счётчика для генерации последовательности блоков счётчика; входной блок является первым блоком последовательности. На шагах 5 и 6 блочный шифр применяется к блокам счётчика, а результаты подвергаются XOR с соответствующими блоками (или частичным блоком) разбиения входной строки. На шаге 7 последовательность результатов конкатенируется для формирования выхода.

Рисунок 2 ниже иллюстрирует функцию GCTR.

7 Спецификация GCM

Алгоритмы 4 и 5 для функций аутентифицированного шифрования и аутентифицированного расшифрования GCM определены в разд. 7.1 и 7.2 ниже. Спецификации включают входные данные, выходные данные, шаги алгоритма, диаграммы и сводки. Предлагаемое обозначение не указывает выбор лежащего в основе блочного шифра. Входные данные, которые обычно фиксированы при многих вызовах функции, называются предварительными условиями; однако некоторые предварительные условия также могут рассматриваться как (изменяющиеся) входные данные. Предварительные условия и другие входные данные ДОЛЖНЫ (SHALL) отвечать требованиям разд. 5.

Для обоих алгоритмов допускаются эквивалентные наборы шагов, дающие корректный результат. Например, в Алгоритме 5 проверка тега может предшествовать вычислению открытого текста.

7.1 Алгоритм функции аутентифицированного шифрования

Алгоритм 4 ниже задаёт функцию аутентифицированного шифрования:

NIST Special Publication 800-38D

Алгоритм 4: GCM-AE_K (IV, P, A)

Предварительные условия:
утверждённый блочный шифр CIPH с размером блока 128 бит;
ключ K;
определения поддерживаемых длин ввода-вывода;
поддерживаемая длина тега t, связанная с ключом.

Ввод:
вектор инициализации IV (длина которого поддерживается);
открытый текст P (длина которого поддерживается);
дополнительные аутентифицированные данные A (длина которых поддерживается).

Вывод:
шифртекст C;
тег аутентификации T.

Шаги:

1. Положить H = CIPH_K(0¹²⁸).
2. Определить блок J₀ следующим образом:
   Если len(IV)=96, то положить J₀ = IV || 0³¹ || 1.
   Если len(IV) ≠ 96, то положить s = 128⌈len(IV)/128⌉−len(IV) и положить J₀=GHASH_H(IV||0^s+64||[len(IV)]₆₄).
3. Положить C=GCTR_K(inc₃₂(J₀), P).
4. Положить u =128·⌈len(C)/128⌉−len(C) и v =128·⌈len(A)/128⌉−len(A).
5. Определить блок S следующим образом:
   S = GHASH_H(A || 0^v || C || 0^u || [len(A)]₆₄ || [len(C)]₆₄).
6. Положить T = MSB_t(GCTR_K(J₀, S)).
7. Вернуть (C, T).

На шаге 1 хеш-подключ для функции GHASH генерируется применением блочного шифра к «нулевому» блоку. На шаге 2 из IV генерируется предсчётный блок (J₀). В частности, когда длина IV составляет 96 бит, к IV присоединяется строка заполнения 0³¹||1 для формирования предсчётного блока. В противном случае к IV добавляется минимальное число битов «0», возможно ни одного, так, чтобы длина результирующей строки была кратна 128 битам (размеру блока); затем к этой строке присоединяются 64 дополнительных бита «0», за которыми следует 64-битное представление длины IV, и к результирующей строке применяется функция GHASH для формирования предсчётного блока. На шаге 3 к предсчётному блоку применяется 32-битная функция инкрементирования, чтобы получить начальный счётный блок для вызова функции GCTR над открытым текстом. Результат этого вызова функции GCTR является шифртекстом.

На шагах 4 и 5 к дополнительным аутентифицированным данным (AAD) и шифртексту каждому присоединяется минимальное число битов «0», возможно ни одного, так, чтобы битовые длины результирующих строк были кратны размеру блока. К конкатенации этих строк присоединяются 64-битные представления длин AAD и шифртекста, а затем к результату применяется функция GHASH для получения одного выходного блока. На шаге 6 этот выходной блок шифруется с использованием функции GCTR с предсчётным блоком, сгенерированным на шаге 2, а результат усекается до указанной длины тега для формирования тега аутентификации. Шифртекст и тег возвращаются в качестве результата на шаге 7.

Функция аутентифицированного шифрования проиллюстрирована на рисунке 3 выше. Определение J₀ из IV (шаг 2) не показано.

7.2 Алгоритм для функции аутентифицированного расшифрования

Алгоритм 5 ниже задаёт функцию аутентифицированного расшифрования:

Алгоритм 5: GCM-AD_K (IV, C, A, T)

Предварительные условия:
утверждённый блочный шифр CIPH с размером блока 128 бит;
ключ K;
определения поддерживаемых длин ввода-вывода;
поддерживаемая длина тега t, связанная с ключом.

Ввод:
вектор инициализации IV;
шифртекст C;
дополнительные аутентифицированные данные A;
тег аутентификации T.

Вывод:
открытый текст P либо указание на неаутентичность FAIL.

Шаги:

1. Если битовые длины IV, A или C не поддерживаются либо если len(T) ≠ t, то вернуть FAIL.
2. Положить H = CIPH_K(0¹²⁸).
3. Определить блок J₀ следующим образом:
   Если len(IV)=96, то J₀ = IV || 0³¹ || 1.
   Если len(IV) ≠ 96, то положить s = 128⌈len(IV)/128⌉−len(IV) и J₀=GHASH_H(IV||0^s+64||[len(IV)]₆₄).
4. Положить P=GCTR_K(inc₃₂(J₀),C).
5. Положить u =128·⌈len(C)/128⌉−len(C) и v =128·⌈len(A)/128⌉−len(A).
6. Определить блок S следующим образом:
   S = GHASH_H(A || 0^v || C || 0^u || [len(A)]₆₄ || [len(C)]₆₄).
7. Положить T′=MSB_t(GCTR_K(J₀,S)).
8. Если T = T′, то вернуть P; иначе вернуть FAIL.

На шаге 1 проверяется поддержка реализацией длин IV, шифртекста, AAD и тега аутентификации. На шаге 2 хеш-подключ для функции GHASH генерируется применением блочного шифра к «нулевому» блоку. На шаге 3 предсчётный блок (J₀) формируется так же, как для функции аутентифицированного шифрования (шаг 2 раздела 7.1). На шаге 4 к предсчётному блоку применяется 32-битная функция инкрементирования, чтобы получить начальный счётный блок для вызова функции GCTR над шифртекстом. Результат этого вызова функции GCTR является открытым текстом, соответствующим шифртексту для заданного IV.

На шагах 5 и 6 к AAD и шифртексту каждому присоединяется минимальное число битов «0», возможно ни одного, так, чтобы битовые длины результирующих строк были кратны размеру блока. К конкатенации этих строк присоединяются 64-битные представления длин AAD и шифртекста, а затем к результату применяется функция GHASH для получения одного выходного блока. На шаге 7 этот выходной блок шифруется с использованием функции GCTR с предсчётным блоком, сгенерированным на шаге 3, а результат усекается до указанной длины тега для формирования тега аутентификации. На шаге 8 результат шага 7 сравнивается с тегом аутентификации, полученным в качестве входных данных: если они идентичны, возвращается открытый текст; в противном случае возвращается FAIL.

Допускаются эквивалентные наборы шагов, дающие правильный результат. В частности, проверка тега может предшествовать вычислению открытого текста.

Функция аутентифицированного расшифрования проиллюстрирована на рисунке 4 ниже. Определение J₀ из IV (шаг 3) не показано.

8 Требование уникальности для IV и ключей

IV в GCM ДОЛЖНЫ (shall) удовлетворять следующему требованию «уникальности»:

Вероятность того, что функция аутентифицированного шифрования когда-либо будет вызвана с одним и тем же IV и одним и тем же ключом для двух (или более) различных наборов входных данных, ДОЛЖНА (shall) быть не больше 2⁻³².

Соблюдение этого требования критически важно для безопасности GCM. Во всех экземплярах функции аутентифицированного шифрования с данным ключом, если хотя бы один IV когда-либо будет повторён, реализация может быть уязвима для атак подделки, описанных в ссылке [5] и кратко изложенных в приложении A. На практике это требование почти столь же важно, как секретность ключа.

Роль установления ключа в обеспечении выполнения этого требования рассматривается в разделе 8.1. Две разрешённые конструкции IV для выполнения этого требования приведены в разделе 8.2. Ограничения на число вызовов функции аутентифицированного шифрования приведены в разделе 8.3.

8.1 Установление ключа

Следующее требование, являющееся нормой для криптографических алгоритмов с секретным ключом в целом, приобретает явную важность для GCM в целях обеспечения требования уникальности в разделе 8:

Любой ключ GCM, установленный между его предполагаемыми пользователями, ДОЛЖЕН (shall) с высокой вероятностью быть свежим.

На практике требования раздела 5.1 должны обеспечивать свежесть ключа при его генерации, если механизм генерации устойчив к вмешательству. Достижение такой устойчивости обычно налагает требования на управление механизмом генерации ключей.

В частности, если механизм генерации ключей является детерминированным, то управление этим механизмом ДОЛЖНО (shall) обеспечивать надёжную гарантию того, что никакая внешняя сущность не может вызвать повторение предыдущего набора входных данных для механизма или иным образом вызвать повторение предыдущего результата. Например, ключи GCM МОГУТ (may) устанавливаться с использованием функций выработки ключей следующих протоколов, как разрешено в [9]: Transport Layer Security, Internet Key Exchange v1 и v2 и Secure Shell.

Аналогично, если новый ключ должен быть передан его предполагаемому получателю (получателям), метод передачи/распространения ДОЛЖЕН (shall) обеспечивать надёжную гарантию защиты от «повторного воспроизведения» («replay»), чтобы никакая сторона не могла вызвать подмену предполагаемого ключа предыдущим ключом.

Ключи GCM СЛЕДУЕТ (should) устанавливать в рамках утверждённой структуры управления ключами для обеспечения их свежести, а также их конфиденциальности и аутентичности; подробности таких структур выходят за рамки настоящей Рекомендации.

8.2 Конструкции IV

Настоящая Рекомендация предоставляет две структуры для построения IV. Первая конструкция, описанная в разделе 8.2.1, опирается на детерминированные элементы для достижения требования уникальности из раздела 8; вторая конструкция, описанная в разделе 8.2.2, опирается на достаточно длинную выходную строку утверждённого RBG с достаточной стойкостью.

Для любой поддерживаемой длины IV, строго меньшей 96 бит, конструкция из раздела 8.2.1 ДОЛЖНА (shall) использоваться во всех экземплярах функции аутентифицированного шифрования с данным ключом.

Для любой поддерживаемой длины IV, равной 96 битам или большей, ДОЛЖНА (shall) использоваться ровно одна из конструкций, но не обе, во всех экземплярах функции аутентифицированного шифрования с данным ключом.

Например, предположим, что реализация поддерживает длины IV 64 бита, 96 бит, 128 бит и 160 бит. Для 64-битных IV единственным выбором является конструкция из раздела 8.2.1. Для трёх остальных длин IV одной возможной комбинацией выборов является конструкция из раздела 8.2.1 для 96-битных IV и конструкция из раздела 8.2.2 для 128-битных и 160-битных IV.

8.2.1 Детерминированная конструкция

В детерминированной конструкции IV является конкатенацией двух полей, называемых фиксированным полем и полем вызова. Фиксированное поле ДОЛЖНО (shall) идентифицировать устройство или, в более общем случае, контекст для экземпляра функции аутентифицированного шифрования. Поле вызова ДОЛЖНО (shall) идентифицировать наборы входных данных для функции аутентифицированного шифрования в этом конкретном устройстве.

Для любого заданного ключа никакие два различных устройства НЕ ДОЛЖНЫ (shall) совместно использовать одно и то же фиксированное поле, и никакие два различных набора входных данных для любого одного устройства НЕ ДОЛЖНЫ (shall) совместно использовать одно и то же поле вызова. Соблюдение этих двух требований подразумевает соблюдение требования уникальности для IV из раздела 8.

При желании само фиксированное поле МОЖЕТ (may) быть построено из двух или более меньших полей. Кроме того, одно из этих меньших полей могло бы состоять из произвольных битов (то есть не обязательно детерминированных или уникальных для устройства), при условии, что оставшиеся биты обеспечивают отсутствие полного повторения фиксированного поля для какого-либо другого устройства с тем же ключом.

Аналогично, всё фиксированное поле МОЖЕТ (may) состоять из произвольных битов, когда требуется идентифицировать только один контекст, например когда свежий ключ ограничен одним сеансом протокола связи. В этом случае, если различные участники сеанса совместно используют общее фиксированное поле, протокол ДОЛЖЕН (shall) обеспечивать различие полей вызова для различных входных данных.

Поле вызова обычно является либо 1) целочисленным счётчиком, либо 2) регистром сдвига с линейной обратной связью, управляемым примитивным полиномом для обеспечения максимальной длины цикла. В любом случае поле вызова увеличивается при каждом вызове функции аутентифицированного шифрования.

Длины и позиции фиксированного поля и поля вызова ДОЛЖНЫ (shall) быть фиксированы для каждой поддерживаемой длины IV на протяжении срока жизни ключа. Для содействия совместимости при длине IV по умолчанию, равной 96 битам, настоящая Рекомендация предлагает, но не требует, чтобы первые (то есть крайние левые) 32 бита IV содержали фиксированное поле, а последние (то есть крайние правые) 64 бита содержали поле вызова.

8.2.2 Конструкция на основе RBG

В конструкции на основе RBG IV является конкатенацией двух полей, называемых случайным полем и свободным полем. Для каждой длины IV, поддерживаемой реализацией и используемой с конструкцией на основе RBG, длины этих полей ДОЛЖНЫ (shall) быть фиксированы на протяжении срока жизни ключа. Кроме того, длина случайного поля ДОЛЖНА (shall) быть не менее 96 бит; свободное поле МОЖЕТ (may) быть пустым.

Если i — поддерживаемая длина IV, связанная с конструкцией на основе RBG, то пусть r(i) обозначает битовую длину случайного поля. Случайное поле ДОЛЖНО (shall) состоять либо из 1) выходной строки длиной r(i) битов от утверждённого RBG с достаточной стойкостью, либо из 2) результата применения функции инкрементирования длиной r(i) битов к случайному полю предшествующего IV для данного ключа. Выходная строка RBG длиной r(i) битов называется прямой случайной строкой, а случайные поля, получающиеся в результате применения функции инкрементирования длиной r(i) битов, называются её последователями.

NIST Special Publication 800-38D

К битам в свободном поле не предъявляется требований. Например, они могут идентифицировать устройство, аналогично фиксированному полю детерминированной конструкции, за исключением того, что в конструкции на основе RBG эти идентификаторы не обязаны быть различными для каждого устройства. Для любой длины IV, связанной с конструкцией на основе RBG, свободное поле рекомендуется оставлять пустым, чтобы случайное поле составляло весь IV.

Экземпляры RBG на любых двух различных устройствах ДОЛЖНЫ (SHALL) быть независимыми, чтобы распределение прямых случайных строк по всем экземплярам RBG, как ожидается, было равномерным. Например, если инициализация экземпляров RBG зависит только от секретного начального значения, то каждый экземпляр ДОЛЖЕН (SHALL) инициализироваться отдельным начальным значением.

8.3 Ограничения на число вызовов

Следующее требование применяется ко всем реализациям, использующим либо 1) детерминированную конструкцию с IV, длина которых не равна 96, либо 2) конструкцию на основе RBG для IV любой длины. Иными словами, если только реализация не использует исключительно 96-битные IV, генерируемые детерминированной конструкцией:

Общее число вызовов функции аутентифицированного шифрования НЕ ДОЛЖНО (SHALL NOT) превышать 2³², включая все длины IV и все экземпляры функции аутентифицированного шифрования с данным ключом.

Это «глобальное» требование, которое может быть выполнено посредством надлежащих «локальных» ограничений для каждого экземпляра функции аутентифицированного шифрования с данным ключом. Например, предположим, что реализация состоит из 2¹⁰ устройств, поддерживающих только 64-битные, 96-битные и 128-битные IV. Одним из способов выполнить указанное выше требование было бы ограничить каждое устройство 2²⁰ вызовами с 64-битными IV, 2²¹ вызовами с 96-битными IV и 2²⁰ вызовами с 128-битными IV.

Для конструкции IV на основе RBG указанное выше требование в сочетании с требованием r(i)≥96 достаточно для обеспечения требования уникальности из разд. 8, как следует из обсуждения в ссылке [4].

Для детерминированной конструкции длины двух полей обусловливают два дополнительных эксплуатационных ограничения. Эти ограничения применяются к любой поддерживаемой длине IV, включая 96 бит:

• Битовая длина поля вызова ограничивает число вызовов функции аутентифицированного шифрования с любым заданным фиксированным полем и ключом. В частности, если s обозначает число битов в поле вызова, то функция аутентифицированного шифрования НЕ МОЖЕТ (CANNOT) быть вызвана для более чем 2^s различных наборов входных данных без нарушения требования уникальности.
• Аналогично, s-битное фиксированное поле предполагает ограничение 2^s на число различных устройств/контекстов, которые могут реализовывать функцию аутентифицированного шифрования для данного ключа с IV заданной длины.

NIST Special Publication 800-38D

9 Практические соображения по валидации реализаций

Как разработчик реализации GCM, так и специалист по информационным технологиям (IT), который развертывает и обслуживает её в рамках определённой системы, играют важные роли в выполнении требования уникальности из разд. 8, как обсуждается ниже в разд. 9.1 и 9.2.

Дополнительные требования в этих двух разделах приведены с целью демонстрации соблюдения требования уникальности из разд. 8 в рамках программы валидации. В частности, по аналогии с требованиями в ссылке [9], требования этих двух разделов применяются к реализациям, валидируемым на соответствие требованиям FIPS Pub. 140-2 (ссылка [3]) или любой заменяющей версии FIPS 140.

Реализации, не валидируемые на соответствие требованиям FIPS Pub. 140-2, МОГУТ (MAY) трактовать требования разд. 9.1 и 9.2 как рекомендации.

9.1 Соображения по проектированию

Чтобы воспрепятствовать неавторизованной стороне управлять генерацией IV или влиять на неё, GCM ДОЛЖЕН (SHALL) реализовываться только внутри криптографического модуля, отвечающего требованиям FIPS Pub. 140-2. В частности, криптографическая граница модуля ДОЛЖНА (SHALL) содержать «блок генерации», который вырабатывает IV в соответствии с одной из конструкций, приведённых выше в разд. 8.2.

Документация модуля для его валидации на соответствие требованиям FIPS 140-2 ДОЛЖНА (SHALL) описывать, каким образом модуль соблюдает требование уникальности для IV. Как минимум документация ДОЛЖНА (SHALL) рассматривать соображения настоящего раздела и чётко документировать обязанности IT-специалиста, который конфигурирует, развертывает и обслуживает реализации GCM в составе более крупной системы.

Ниже приведены три важных соображения по проектированию модулей GCM:

1. Свежесть ключей ДОЛЖНА (SHALL) быть обеспечена, как обсуждается в разд. 8.1.
2. IV ДОЛЖЕН (SHALL) быть критическим параметром безопасности согласно определению в FIPS Pub. 140-2 до тех пор, пока функция аутентифицированного шифрования не будет вызвана с этим IV. До этого вызова IV ДОЛЖНА (SHALL) предоставляться такая же защита, как и другим критическим параметрам безопасности в модуле, валидируемом на соответствие требованиям FIPS Pub. 140-2.
3. Потеря питания модуля НЕ ДОЛЖНА (SHALL NOT) приводить к повторению IV. Если блок генерации НЕ МОЖЕТ (CANNOT) восстановиться после потери питания, то функция аутентифицированного шифрования ДОЛЖНА (SHALL) перейти в состояние отказа, пока не будет установлен свежий ключ.

Конструкция IV, реализуемая согласно разд. 8.2 выше, влияет на варианты восстановления после потери питания. Для детерминированной конструкции все детерминированные элементы, необходимые для построения IV, должны были бы быть доступны при восстановлении питания. Например, эти элементы могли бы храниться в энергонезависимой памяти.

NIST Special Publication 800-38D

При восстановлении питания ни предшествующий IV, ни какой-либо другой ранее использованный IV НЕ ДОЛЖЕН (SHALL) немедленно повторяться для данного ключа. Один из способов избежать такого повторения состоит в обеспечении того, чтобы значение поля вызова, периодически сохраняемое в энергонезависимой памяти, всегда опережало рабочее значение в последовательности на одно или несколько значений.

Одно из потенциальных преимуществ конструкции на основе RBG заключается в том, что RBG может быть спроектирован для простого восстановления после потери питания, то есть без необходимости действий со стороны IT-специалиста, обслуживающего систему. Например, RBG может включать недетерминированный источник битов, который автоматически был бы доступен RBG при восстановлении питания.

В качестве альтернативы всё состояние RBG может периодически сохраняться в энергонезависимой памяти. В этом случае, аналогично детерминированной конструкции, при восстановлении питания проект ДОЛЖЕН (SHALL) обеспечивать, чтобы RBG НЕ ВЫДАВАЛ (SHALL NOT) строки для использования в новых IV, пока состояние RBG не будет продвинуто за состояние, сгенерировавшее последний IV для данного ключа. Иными словами, прямая случайная строка для первого нового IV ДОЛЖНА (SHALL) с высокой вероятностью отличаться от прямой случайной строки в любом IV, сгенерированном до потери питания.

Даже если процесс не является автоматическим, IT-специалист, обслуживающий систему, может просто повторно инициализировать RBG при восстановлении питания, например свежим начальным значением. В этом случае либо конструкция модуля, либо IT-специалист, обслуживающий систему, ДОЛЖНЫ (SHALL) обеспечить сохранение соответствия условию независимости RBG из разд. 8.2.2.

9.2 Эксплуатационные соображения

Соблюдение требования уникальности для IV и, следовательно, безопасность GCM в конечном счёте зависят от IT-специалиста, который конфигурирует, развертывает и обслуживает модули GCM в определённой системе. Документация для модуля GCM ДОЛЖНА (SHALL) предоставлять IT-специалисту подробные инструкции, адаптированные к конкретной конструкции модуля.

Ниже приведены некоторые типичные эксплуатационные соображения относительно требования уникальности:

• Подвержена ли конфигурация какого-либо модуля GCM или какое-либо рабочее значение управлению или влиянию со стороны какой-либо неавторизованной стороны?
• Каким образом для любого данного ключа обеспечивается соблюдение выбранных настроек конфигурации во всех модулях, которые когда-либо реализуют функцию аутентифицированного шифрования?
• Как обеспечивается свежесть ключей, как обсуждается в разд. 8.1?
• Если реализация не использует исключительно 96-битные IV, генерируемые детерминированной конструкцией, то как обеспечивается выполнение требования разд. 8.3 о числе вызовов?
• Как обсуждается в разд. 9.1, каким образом генерация IV внутри модулей восстанавливается после потери питания, не нарушая требования уникальности для IV?

NIST Special Publication 800-38D

Следующие соображения относятся к детерминированной конструкции:

• Каким образом идентификаторы устройств устанавливаются в фиксированное поле, чтобы было обеспечено соблюдение требований к фиксированному полю из разд. 8.2.1 как для первоначально развернутых модулей, так и для любых впоследствии развернутых модулей?
• Достаточна ли длина поля вызова для поддержки всех вызовов, которые могут происходить в любом модуле в течение срока действия любого ключа, как обсуждается в первом пункте списка в разд. 8.3?
• Достаточна ли для любого данного ключа и длины IV длина фиксированного поля для поддержки числа модулей, которые будут реализовывать аутентифицированное шифрование, как обсуждается во втором пункте списка в разд. 8.3?
• Если настройка по умолчанию для длин фиксированного поля и поля вызова может быть изменена, то каким образом обеспечивается соблюдение этого выбора во всех модулях с любым данным ключом?

Следующее соображение относится к конструкции на основе RBG:

• Каким образом RBG для генерации IV инициализируются так, чтобы обеспечивалось соблюдение требования независимости из разд. 8.2.2 как для первоначально развернутых модулей, так и для любых впоследствии развернутых модулей?

10 Соответствие

Двумя категориями реализаций, которые МОГУТ (MAY) заявлять о соответствии данной Рекомендации, являются GCM и GMAC.

Реализации МОГУТ (MAY) ограничивать поддерживаемые ими битовые длины открытого текста, AAD, IV и тегов аутентификации, как обсуждается выше в разд. 5.2.1.1 и 5.2.1.2. Хотя такие ограничения могут влиять на совместимость, отдельной категорией реализации считается только полное исключение открытого текста, то есть GMAC.

Для каждого алгоритма, указанного в данной Рекомендации, соответствующая реализация МОЖЕТ (MAY) заменять данный набор шагов любыми математически эквивалентными наборами шагов. Иными словами, допускаются различные процедуры, дающие правильный вывод для любых входных данных.

NIST Special Publication 800-38D

Приложение A: Важность требования уникальности для IV

Раздел 8 содержит требование уникальности для IV в GCM, распространяющееся на все реализации функции аутентифицированного шифрования с любым заданным ключом. В настоящем приложении обобщается, почему это требование критически важно для безопасности GCM, как впервые описано в ссылке [5].

Безопасная работа криптографического алгоритма зависит не только от надлежащей реализации шагов алгоритма, но и от соблюдения связанных с ним требований. Очевидный пример для любого алгоритма с симметричным ключом состоит в том, что ключ необходимо хранить в тайне. Для GCM требование уникальности IV из раздела 5.2.1 почти столь же важно, хотя и не столь очевидно.

Сначала рассмотрим требование режима Counter из ссылки [10] об уникальности блоков счётчика. Если это требование нарушено, функция шифрования в режиме Counter может (may) не обеспечить ожидаемую конфиденциальность блоков данных, соответствующих повторяющимся блокам счётчика, хотя другие блоки данных не затрагиваются.

Функция расшифрования в режиме Counter имеет уязвимость, которая, возможно, более серьёзна. Шифротекст режима Counter является «податливым» (malleable) в том смысле, что изменение любого из его битов приводит при расшифровании к изменению соответствующих битов открытого текста. Поэтому, если нарушитель знает пару «открытый текст — шифротекст» и может (can) заставить функцию расшифрования использовать блоки счётчика из известной пары, то, выбирая, какие биты изменить в известном шифротексте, нарушитель может (can) управлять результатом расшифрования в пределах длины известного открытого текста.

Эта уязвимость служит причиной объединения механизма шифрования режима Counter с механизмом аутентификации, как это происходит в GCM. Идея состоит в том, чтобы предотвратить принятие изменённого нарушителем шифротекста в качестве действительного. Однако, как подробно описано в ссылке [5], гарантия аутентичности в GCM критически зависит от уникальности IV.

В частности, если IV когда-либо повторяются для функции аутентифицированного шифрования GCM при заданном ключе, то вероятно, что нарушитель сможет (will be able to) определить подключ хеширования по полученным шифротекстам. Затем нарушитель мог бы (could) легко сконструировать подделку шифротекста. В частности, зная результаты в виде шифротекста и тега для одного вызова функции аутентифицированного шифрования, а также соответствующие входные IV и AAD, нарушитель мог бы (could) подставить любые строки шифротекста и AAD и использовать подключ для создания действительного подменяющего тега. Хотя такая подделка использовала бы тот же IV, в большинстве случаев функции аутентифицированного расшифрования будет невозможно обнаружить повторение. Таким образом, гарантия аутентичности по существу утрачивается.

Что ещё хуже, утрата аутентичности означает, что GCM наследует проблематичную податливость своего шифротекста режима Counter. В описанном выше сценарии, зная исходный открытый текст, соответствующий данному шифротексту, нарушитель может (can) сконструировать подменяющий шифротекст так, чтобы он соответствовал любому желаемому открытому тексту той же длины. Иными словами, нарушитель по существу мог бы (could) управлять выдаваемым функцией аутентифицированного расшифрования открытым текстом.

Приложение B: Гарантия аутентичности

Создание тега аутентификации функцией аутентифицированного шифрования предоставляет механизм, посредством которого при выполнении функции аутентифицированного расшифрования может быть получена гарантия аутентичности открытого текста и AAD (и IV). Характер этой гарантии зависит от результата функции аутентифицированного расшифрования:

• Если результатом является открытый текст, то конструкция режима предоставляет сильную, но не абсолютную гарантию того, что заявленный источник данных создал тег, то есть что открытый текст и AAD (а также IV и тег) являются аутентичными. Следовательно, режим также предоставляет сильную гарантию того, что эта информация впоследствии не была изменена — намеренно или непреднамеренно.
• Если результатом является FAIL, то достоверно, что по меньшей мере один из предоставленных входов (то есть шифротекст, AAD, IV или тег) не является аутентичным.

В первом случае гарантия не является абсолютной, поскольку подделки в принципе возможны. Иными словами, нарушитель, то есть сторона без доступа к ключу или к функции аутентифицированного шифрования, может (may) быть способен создать правильный тег для некоторой тройки из шифротекста, AAD и IV.

Как и в любом механизме аутентификации на основе тегов, если нарушитель выбирает случайный тег длиной t бит, ожидается, что он будет правильным для заданных данных с вероятностью 1/2^t. Однако в GCM нарушитель может (can) выбирать теги, увеличивающие эту вероятность пропорционально общей длине шифротекста и AAD. Следовательно, GCM плохо подходит для применения с короткими длинами тегов или очень длинными сообщениями.

В частности, если n обозначает общее число блоков в кодировании шифротекста и AAD (то есть во входе функции GHASH при определении S в разделах 7.1 и 7.2 выше), то существует метод построения «целенаправленной» подделки шифротекста, которая, как ожидается, будет успешной с вероятностью приблизительно n/2^t. Более того, каждая успешная подделка в этой атаке: 1) увеличивает вероятность успеха последующих целенаправленных подделок и 2) раскрывает информацию о подключе хеширования H. В конечном итоге H может (may) быть полностью скомпрометирован с последствиями, описанными в конце приложения A: гарантия аутентичности полностью утрачивается.

В ссылке [1] описана атака, а в ссылке [7] подробно рассмотрены свойства безопасности GCM. В приложении C приведены рекомендации и требования для использования двух тегов наименьшего размера — 32 и 64 бита.

Независимо от этой атаки нарушитель может (may) попытаться систематически угадывать множество различных тегов для заданного входа функции аутентифицированного расшифрования и тем самым увеличить вероятность того, что один (или несколько) из них в конечном счёте будет принят как действительный. По этой причине система или протокол, реализующие GCM, СЛЕДУЕТ (should) отслеживать и, при необходимости, ограничивать число неуспешных попыток проверки для каждого ключа.

Кроме того, как и в случае большинства режимов работы блочных шифров, гарантия безопасности GCM ухудшается по мере обработки большего объёма данных одним ключом. Поэтому общее число блоков открытого текста и AAD, защищаемых вызовами функции аутентифицированного шифрования в течение срока действия ключа, СЛЕДУЕТ (should) ограничивать. Разумным пределом для большинства приложений было бы 2⁶⁴, что согласуется с требованием к числу вызовов в разделе 8.3.

Приложение C: Требования и рекомендации по использованию коротких тегов

Для некоторых голосовых или видеоприложений короткие теги аутентификации могут (can) быть уместны. Подделка некоторой доли отдельных аутентифицированных «пакетов» может (may) быть допустима, поскольку каждый пакет данных в большом потоке может (may) нести очень малую часть общего смысла.

Однако даже для голосовых и видеоприложений короткие теги могут (can) быть проблематичны для GCM из-за целенаправленной атаки с подделкой, которая обобщена в приложении B и подробно описана в ссылке [1]. При отсутствии требований и рекомендаций настоящего приложения для атаки может (may) оказаться практически осуществимым получение подключа хеширования H, после чего гарантия аутентичности полностью утрачивается. Тем не менее настоящая Рекомендация не исключает короткие теги полностью, поскольку квалифицированные специалисты по безопасности должны быть способны управлять рисками, связанными с этой атакой и её возможным усовершенствованием.

Следующие рекомендации неявно описывают особые обстоятельства, которые могут (may) быть уместны для коротких тегов. Пакет в данном контексте представляет собой набор входов функции аутентифицированного расшифрования.

1. Пакеты, не прошедшие проверку целостности внутри функции аутентифицированного расшифрования, СЛЕДУЕТ (should) молча отбрасывать. Иными словами, управляющий протокол/система, через который принимаются пакеты, НЕ СЛЕДУЕТ (should not) предоставлять ответ ACK/NACK относительно целостности отдельных пакетов. Однако получателю СЛЕДУЕТ (should) регистрировать ошибки аутентификации во внутренних журналах — способом, не обнаружимым по информации побочных каналов, — и завершать соединение либо уведомлять пользователя, если процент ошибок превышает то, что считалось бы нормальным. Это является стандартной практикой безопасности при любом выборе протокола/системы и алгоритма.
2. AAD в пакетах СЛЕДУЕТ (should) ограничивать необходимой информацией заголовка; оно НЕ СЛЕДУЕТ (should not) содержать сообщения, подлежащие аутентификации наряду с зашифрованными данными.
3. Содержание или смысл общего сообщения, состоящего из большого числа пакетов, НЕ СЛЕДУЕТ (should not) утрачивать или ставить под угрозу вследствие подделки одного произвольного пакета. Например, пакеты могут (could) нести последовательность фрагментов голоса или визуальных данных, но отдельный пакет НЕ СЛЕДУЕТ (should not) использовать для переноса файла .txt или .doc. В идеале данные открытого текста, лежащие в основе шифрования, НЕ СЛЕДУЕТ (should not) делать настолько стереотипными, чтобы их можно было угадать.
4. Управляющий протокол/система СЛЕДУЕТ (should) часто устанавливать новый ключ GCM — и, следовательно, новый подключ хеширования H — в зависимости от максимальной суммарной длины шифротекста и AAD, которая может (can) возникнуть в одном пакете. Кроме того, для 32-битных тегов эта суммарная длина СЛЕДУЕТ (should) быть очень малой — порядка десятков или сотен байтов; для 64-битных тегов максимальная суммарная длина увеличивается до миллионов байтов.

Примером протокола, соответствующего этим рекомендациям, является Secure Real-time Transport Protocol, переносящий Voice over Internet Protocol и работающий поверх User Datagram Protocol.

В таблицах 1 и 2 ниже количественно выражены рекомендации пункта 4 выше для 32-битных и 64-битных тегов соответственно. Каждая строка содержит две величины: 1) максимальную суммарную длину шифротекста и AAD в одном пакете в байтах и 2) соответствующее максимальное число вызовов функции аутентифицированного расшифрования во всех экземплярах GCM с заданным ключом.

Для любой реализации, поддерживающей 32-битные или 64-битные теги, соответственно ДОЛЖНА (shall) применяться одна из строк таблицы 1 или таблицы 2. В частности, поддерживаемые длины открытого текста/шифротекста и AAD ДОЛЖНЫ (shall) обеспечивать, чтобы каждый действительный пакет удовлетворял ограничению длины в строке, а управляющий протокол/система ДОЛЖЕН (shall) обеспечивать смену ключа до того, как функция аутентифицированного расшифрования будет вызвана более максимального числа раз, указанного в строке. Также может (may) применяться меньшее максимальное значение.

Приложение D: Защита от повторного воспроизведения сообщений

Как описано в приложении B, успешная проверка тега внутри функции аутентифицированного расшифрования даёт гарантию аутентичности данных; однако сторона, предоставляющая входные данные функции аутентифицированного расшифрования, может (may) не быть первоначальным источником открытого текста и AAD. Иными словами, GCM, как и многие другие механизмы аутентификации, сам по себе не предотвращает перехват нарушителем результата вызова аутентифицированного шифрования и его «повторное воспроизведение» для аутентифицированного расшифрования позднее, например в попытке выдать себя за сторону, имеющую доступ к ключу. В некоторых протоколах нарушитель может (may) даже быть способен использовать данные, ранее сгенерированные в протоколе самим проверяющим.

Управляющая система или протокол может (may) защищать от такого события, отслеживая любое дублирование IV, представляемых для аутентифицированного расшифрования. В качестве альтернативы в AAD может (can) быть включена определённая идентифицирующая информация. Примерами такой информации являются последовательный номер сообщения или метка времени. После успешной проверки аутентичности эта информация может (may) предоставлять средство для обнаружения повторно воспроизведённых сообщений, сообщений вне последовательности или отсутствующих сообщений.

NIST Special Publication 800-38D

Приложение E: Библиография

[1] Ferguson, N., Authentication Weaknesses in GCM, Natl. Inst. Stand. Technol. [Веб-страница], http://www.csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC-GCM/Ferguson2.pdf, May 20, 2005.

[2] FIPS Publication 197, The Advanced Encryption Standard (AES), U.S. DoC/NIST, November 26, 2001.

[3] FIPS Publication 140-2, Security Requirements for Cryptographic Modules, U.S. DoC/NIST, May 25, 2001.

[4] IEEE P1619.1™/D23, Draft Standard for Authenticated Encryption with Length Expansion for Storage Devices.

[5] A. Joux, Authentication Failures in NIST version of GCM, Natl. Inst. Stand. Technol. [Веб-страница], http://www.csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/800-38_Series-Drafts/GCM/Joux_comments.pdf.

[6] D. McGrew, J. Viega, The Galois/Counter Mode of Operation (GCM), Natl. Inst. Stand. Technol. [Веб-страница], http://www.csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/gcm/gcm-revised-spec.pdf, May 31, 2005.

[7] D. McGrew and J. Viega. The Security and Performance of the Galois/Counter Mode (GCM) of Operation. Proceedings of INDOCRYPT ’04, Springer-Verlag, 2004. Полная статья доступна в IACR Cryptology ePrint Archive: Report 2004/193, [Веб-страница], http://eprint.iacr.org/2004/193/, October 7, 2004.

[9] National Institute of Standards and Technology and Communications Security Establishment, Implementation Guidance for FIPS Pub. 140-2 and the Cryptographic Module Validation Program, Natl. Inst. Stand. Technol. [Веб-страница], http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf.

[10] NIST Special Publication 800-38A, 2001 ED, Version 1, Recommendation for Block Cipher Modes of Operation—Methods and Techniques, December 2001, Natl. Inst. Stand. Technol. [Веб-страница], http://www.csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf.

31