Получен уникальный ключ для каждой транзакции - Derived unique key per transaction

В криптография, Полученный уникальный ключ для транзакции (ДУКПТ) это ключевой менеджмент схема, в которой для каждой транзакции уникальный ключ используется, что является полученный от фиксированного ключа. Следовательно, если производный ключ скомпрометирован, данные будущих и прошлых транзакций по-прежнему защищены, поскольку следующий или предыдущий ключи не могут быть легко определены. DUKPT указан в ANSI X9.24, часть 1.

Обзор

DUKPT позволяет перемещать обработку шифрования с устройств, хранящих общий секрет. Шифрование выполняется с помощью полученный ключ, который не используется повторно после транзакции. DUKPT используется для шифрования транзакций электронной торговли. Хотя его можно использовать для защиты информации между двумя компаниями или банками, он обычно используется для шифрования информации о PIN-кодах, полученной устройствами для точек продаж (POS).

DUKPT сам по себе не является стандартом шифрования; скорее это ключевой метод управления. Особенности схемы ДУКПТ:

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

История

DUKPT был изобретен в Visa в конце 1980-х, но не получил широкого распространения до 1990-х, когда отраслевые практики сместились в сторону рекомендации, а позже и требования, чтобы каждое устройство имело отдельный ключ шифрования.

До DUKPT современное состояние было известно как Мастер / Сессия, который требовал, чтобы каждое устройство шифрования PIN-кода было инициализировано уникальным мастер-ключом. При обработке транзакций, исходящих от устройств, использующих управление главным / сеансовым ключом, нежелательным побочным эффектом была необходимость в таблице ключей шифрования, равной количеству развернутых устройств. У крупного торгового эквайера стол действительно может стать довольно большим. ДУКПТ решил это. В DUKPT каждое устройство по-прежнему инициализируется отдельным ключом, но все ключи инициализации всего семейства устройств являются производными от одного ключа, базового производного ключа (BDK). Чтобы расшифровать зашифрованные сообщения с устройств в полевых условиях, получателю нужно только сохранить BDK.

Ключи

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

Это смягчается тем фактом, что есть только две стороны, которые знают BDK:

  • получатель зашифрованных сообщений (обычно продавец-эквайер)
  • сторона, которая инициализирует устройства шифрования (обычно производитель устройства).

BDK обычно хранится внутри защищенный от взлома модуль безопасности (TRSM), или аппаратный модуль безопасности (HSM). Должно быть ясно, что этот ключ не тот, который используется для инициализации устройства шифрования, которое будет участвовать в операциях DUKPT. См. Ниже фактический процесс генерации ключа шифрования.

  • Первый: Ключ, полученный из BDK, он известен как IPEK (ключ шифрования исходного PIN-кода).
  • Второй: IPEK затем вводится в устройства, поэтому любая компрометация этого ключа ставит под угрозу только устройство, а не BDK. Это создает еще один набор ключей (внутри устройства), необратимо извлеченных из него (номинально называемый Ключи будущего)
  • Четвертый: После этого IPEK немедленно удаляется. ПРИМЕЧАНИЕ. Этот шаг противоречит разделу «Ключи сеанса», где он указывает, что создается только 21 «Ключ будущего». IPEK должен быть сохранен в терминале, чтобы сгенерировать следующую партию из 21 ключа будущего.
  • Пятый: Future Keys используются для шифрования транзакций в процессе DUKPT.

При обнаружении компрометации само устройство создается внутри и в процессе генерации производного ключа.

Коммуникация

Происхождение

На исходящей (шифровальной) стороне система работает следующим образом:

  1. Инициируется транзакция, которая включает в себя шифрование данных. Типичный случай - это PIN-код клиента.
  2. Ключ извлекается из набора «Future Keys»
  3. Это используется для шифрования сообщения, создавая криптограмма.
  4. Идентификатор, известный как «Серийный номер ключа» (KSN), возвращается от устройства шифрования вместе с криптограммой. KSN формируется из уникального идентификатора устройства и внутреннего счетчика транзакций.
  5. Пара (криптограмма, KSN) пересылается предполагаемому получателю, обычно продавцу-эквайеру, где она расшифровывается и обрабатывается.
  6. Внутри устройство выполняет следующие функции:
    1. Увеличивает количество транзакций (используя внутренний счетчик)
    2. Делает недействительным только что использованный ключ и
    3. При необходимости генерирует дополнительные ключи в будущем

Получение

На приемной (дешифрующей) стороне система работает следующим образом:

  1. Получена пара (криптограмма, KSN).
  2. Соответствующий BDK (если в системе их более одного) находится.
  3. Принимающая система сначала регенерирует IPEK, а затем выполняет процесс, аналогичный тому, который используется в исходной системе, чтобы получить тот же ключ шифрования, который был использован (ключ сеанса). Серийный номер ключа (KSN) предоставляет информацию, необходимую для этого.
  4. Криптограмма расшифровывается с помощью сеансового ключа.
  5. Любая дальнейшая обработка сделана. Для торговых эквайеров это обычно означает шифрование под другим ключом для пересылки на коммутатор (выполнение «перевода»), но для некоторых операций с обратной связью может потребоваться прямая обработка данных, например проверка PIN-кода.

Ключи сеанса

Метод получения ключей сеанса несколько отличается на исходной стороне и на принимающей стороне. На стороне отправителя между транзакциями сохраняется значительная информация о состоянии, включая счетчик транзакций, серийный номер и массив из 21 «будущих ключей». На принимающей стороне информация о состоянии не сохраняется; только BDK является постоянным для всех операций обработки. Такое расположение обеспечивает удобство приемника (можно обслуживать большое количество устройств, сохраняя только один ключ). Он также обеспечивает некоторую дополнительную безопасность по отношению к отправителю (устройства ввода PIN-кода часто развертываются в небезопасных средах; параметры безопасности в устройствах `` далеки '' от чувствительного BDK, и если устройство взломано, другие устройства не неявно скомпрометированы).

Использование регистров

Резервные регистры

Следующие области хранения, относящиеся к управлению ключами, поддерживаются с момента команды «Загрузить начальный ключ» в течение всего срока службы устройства ввода PIN-кода:

Регистр начального серийного номера ключа (59 бит)

Содержит 59 крайних левых битов серийного номера ключа, который был изначально введен в устройство ввода PIN-кода вместе с начальным ключом шифрования PIN-кода во время команды «Загрузить начальный ключ». Содержимое этого регистра остается неизменным в течение срока службы устройства ввода PIN-кода или до следующей команды «Загрузить начальный ключ».

Счетчик шифрования (21 бит)

Счетчик количества попыток шифрования ПИН-кода с момента первой инициализации устройства ввода ПИН-кода. Определенные значения счетчиков пропускаются (как описано ниже), поэтому возможно более 1 миллиона операций шифрования PIN. Примечание. Объединение (слева направо) регистра начального серийного номера ключа и счетчика шифрования образует 80-битный (20 шестнадцатеричных цифр) регистр серийного номера ключа.

Регистры будущих ключей (21 регистр по 34 шестнадцатеричных цифры в каждом)

Набор из 21 регистра, пронумерованных от # 1 до # 21, используется для хранения будущих ключей шифрования PIN. Каждый регистр включает в себя проверку продольным избыточным кодом (LRC) из 2 шестнадцатеричных цифр или циклический контроль избыточности (CRC) из 2 шестнадцатеричных цифр.


Временные регистры

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

Текущий ключевой указатель (примерно 4 шестнадцатеричных цифры)

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

Регистр сдвига (21 бит)

21-битный регистр, биты которого пронумерованы слева направо от # 1 до # 21. Этот регистр обычно содержит 20 «нулевых» битов и один бит «единица». Одно из применений этого регистра - выбор одного из регистров будущих ключей. Будущий ключевой регистр, который должен быть выбран, - это тот, который пронумерован идентично тому биту в регистре сдвига, который содержит единственную «единицу».

Crypto Register-1 (16 шестнадцатеричных цифр)

Регистр, используемый для выполнения криптографических операций.

Crypto Register-2 (16 шестнадцатеричных цифр)

Второй регистр, используемый для выполнения криптографических операций.

Ключевой регистр (32 шестнадцатеричных цифры)

Регистр, используемый для хранения криптографического ключа.

Практические вопросы (схема KSN)

В практических приложениях можно было бы иметь несколько записанных BDK, возможно, для разных клиентов или для ограничения объема взлома ключей. При обработке транзакций для получателя важно знать, какой BDK был использован для инициализации исходного устройства. Для этого 80-битный KSN состоит из трех частей: идентификатора набора ключей, идентификатора TRSM и счетчика транзакций. Алгоритм указывает, что счетчик транзакций является 21-битным, но обрабатывает оставшиеся 59 бит непрозрачно (алгоритм только указывает, что неиспользуемые биты должны быть дополнены 0 до границы полубайта, а затем дополнены 'f' до 80-битной границы). Из-за этого объект, управляющий созданием устройств DUKPT (обычно продавец-эквайер), может разделить 59 битов в соответствии со своими предпочтениями.

Промышленная практика заключается в обозначении разделения как серии из трех цифр, указывающих количество шестнадцатеричных цифр, используемых в каждой части: идентификатор набора ключей, идентификатор TRSM и счетчик транзакций. Обычный выбор - «6-5-5», что означает, что первые 6 шестнадцатеричных цифр KSN указывают ID набора ключей (то есть, какой BDK должен использоваться), следующие 5 - это TRSM ID (т.е. серийный номер устройства). число в диапазоне, инициализируемом через общий BDK), а последние 5 - это счетчик транзакций.

Эта схема записи не является строго точной, потому что счетчик транзакций составляет 21 бит, что не является четным числом, кратным 4 (количество бит в шестнадцатеричной цифре). Следовательно, счетчик транзакций фактически потребляет один бит поля, являющегося идентификатором TRSM (в этом примере это означает, что поле идентификатора TRSM может содержать 2(5*4-1) устройств, вместо 2(5*4), или около полумиллиона).

Кроме того, в отрасли распространено использование только 64-битного KSN (вероятно, по причинам, относящимся к устаревшим системам и шифрованию DES), что означает, что полный KSN дополняется слева четырьмя шестнадцатеричными буквами f цифры. Остальные 4 шестнадцатеричных цифры (16 бит), тем не менее, доступны для систем, которые могут их поддерживать.

Схема 6-5-5, упомянутая выше, разрешит около 16 миллионов BDK, 500 000 устройств на BDK и 1 миллион транзакций на устройство.