На днях мне пришлось в очередной раз объяснять дипломированному «специалисту по защите информации» что и как устроено в международных платёжных системах (МПС) да и просто в платёжных системах (ПС) в области криптографии. И что самое обидное, что его просто так не отправишь в Google или читай сюда, т.к. информации в сети очень разрозненная и не систематизирована с точки зрения что, зачем и куда.
Поэтому и родилась идея выложить краткий ликбез по криптографии в МПС.
В тексте есть некоторое не соответствие в обще принятых терминами, но она в большей степени искусственная и она сделана для того что избежать наездов копирастов.
Хотелось бы рассказать про:
- Общие определения и термины
- Какая информация есть на карточке с магнитной полосой и на основе чего она генерируется.
- Что происходит с ПИН-кодом от момента его ввода и при обработке в процессинговом центре.
- И как проверяется ПИН-код когда он только у Вас в голове!
Так же будут рассказаны некоторые «нюансы» и «не секретные секреты» безопасности в ПС и МПС.
Часть 1
Некоторые определения.
Алгоритм DES
Алгоритм DES смотрим формальное описание зедсь (http://ru.wikipedia.org/wiki/DES), если не понятно то просто принимаем что есть две функции:
f=E(K,t) и t=D(K,f)
где:
K-ключ длинной 56 бит;
t-открытый текст, длинной 64 бита;
f-зашифрованный текст, длинной 64 бита.
Пример
7B 2E 18 60 0A 02 51 BE — ключ
69 1A 4E 18 9A 10 65 E8 — открытый текст
14 D6 93 0D FE 0D 0A 18 — зашифрованный текст
Замечание про длину ключа. Стандарт FIPS 46-3 определяет длину ключа в 56 бит, но практически во всех системах используется длина 64 бита. Так вот каждые 7 бит реального ключа дополняются одним битом чётности, это бит самый младший из значимых. Это бит, может быть:
- просто не значимым;
- быть вычисленным, так что бы ключ был чётным — каждом байте ключа количество единичных битов было чётным;
- или наоборот, что бы количество единичных битов нечётным, данный вариант чаще всего и применяется
Соответственно говорят, что ключ чётный или нечётный.
Для примера если у нас байт в ключе равен E3 (1110 0011) то он остаётся без имений, но если для примера байт ключа равен A6 (1010 0110), то его необходимо преобразовать в A7(1010 0111).
Примеры
7C 23 69 70 5B 17 52 BE — не нормализованный на чётность/ нечётность
7C 23 68 70 5B 16 52 BF — нечётный ключ
7D 22 69 71 5A 17 53 BE — чётный ключ
EE FB 9B 48 8D EF C4 96 — не нормализованный на чётность/ нечётность
EF FB 9B 49 8C EF C4 97 — нечётный ключ
EE FA 9A 48 8D EE C5 96 — чётный ключ
Алгоритм 3DES
Т.к. 56 бит по нынешним меркам это просто несерьёзная длинна ключа. А информацию надо защищать и как бы подешевле, был предложен следующий выход: использовать несколько раундов шифрования DES с разными ключами. Таким образом родился так называемый TripleDES он же 3DES (Тройной DES)
f=E(K1,E(K2,E(K3,t))) т.е. По сути зашифровали последовательно один входной текст три раза, на трех ключах.
Но т.к. теперь надо хранить в 3 раза больше информации о значении ключей то это оказалось не так красиво и было предложено упрощение — приняли что ключ 1 равен ключу 3 т.е.
f=E(K1,E(K2,E(K1,t)))
хотя 112(128) бит это меньше чем 168(192) бит с тремя уникальными ключами, но все гораздо лучше чем 56 бит.
Также необходимо отметить, что не надо путать 3DES на наборе ключей K1,K2,K1 с так называемым 2DES где f=E(K1,E(K2,t)) где всего два раунда шифрования.
Далее будем писать, что f=E(K1,K2,t) подразумевая что K1 используется два раза и это классический 3DES
В зависимости от системы 3DES ключ может указываться и передаваться как:
- два ключа по 64 бита;
- один ключ в 128 бит
- три ключа по 64 бита (1-ый равен 3-ему ключу)
- один ключ в 192 бита
Замечания про чётность, нечётность ключей для 3DES имеют туже силу, что и для DES.
Пример
58 4B 85 9C 77 3F 7E 26 16 23 B7 65 A9 07 F0 F3 — ключ
69 1A 4E 18 9A 10 65 E8 — открытый текст
D6 36 BC A5 BF 3B 1F DC — зашифрованный текст
Проверка ключа
Как уже писал, чётность/нечётность ключа является некоторой защитой от возникновения единичной ошибки внутри байта ключа. Но это механизм ни как не страхует от двойной ошибки, тем более при ручном вводе когда могут ввести все что угодно. Для полной сверки ключа используется так называемое контрольное значение (check value). Некоторые личности ошибочно называю его/её контрольной суммой.
Для проверки ключа используется следующий интересный приём,
cv= f=E(K,0), т.е. ключом K шифруется нулевой текст — восемь(8) нулевых байт.
Обычно при передачи контрольного значения для сверки передаются старшие 2 или 3 байта в шестнадцатеричном виде. Хотя мне попадались записанные на бумажечках и младшие 2 байта.
Понятно что есть доля вероятности что контрольное значение может совпасть, но уж ни как для ключей отличающихся 1,2,3,5 цифрами.
Так все выше указанное применимо и для 3DES алгоритма мы на выходе получаем те же 64 бита данных из которых будут для контрольного значения использоваться старшие 2-3 байта.
Необходимо сказать что контрольное значение для 3DES ключа может быть приведено как для каждого полу ключа так и для всего ключа.
Контрольное значение обычно вычисляется системами автоматически сразу после ввода ключа и служит для ручного -визуального контроля правильности ввода. Бывает, что после ввода ключа система запрашивает ввод контрольного значения и если оно совпало с рассчитанным, то считается что ввод ключа прошёл успешно.
Пример
7B 2E 18 60 0A 02 51 BE — ключ
00 00 00 00 00 00 00 00 — нулевые данные
6F 54 EB 36 54 E4 21 A0 — результат шифрации
6F 54 EB — check value
Передача ключей
Понятно что для того что бы начать передать данные из точки А в точку B необходимо как то осуществить обмен ключами.
Различают два способа обмена ключами:
компонентный и через/под ZCMK (KEK)
Компонентный метод
Предполагается, что вы знаете как работает операция исключающего ИЛИ (XOR) и что она обладает свойством ассоциативности.
Пусть нас есть ключ K и его необходимо передать безопасно из А в точку B. Если его просто распечатать на бумаге то курьера появляется высокий риск подсмотреть его и похитить ключ. Поэтому решили что необходимо разбить ключ K на три компоненты (не в России писали эти стандарты) и эти три компоненты отдать трём разным курьерам- офицерам безопасности который каждый индивидуально доставит их из А в точку B (типа три не сговорятся).
K= A XOR B XOR C
Т.к. операция XOR ассоциативная то порядок ввода компонент A, B, C не важен.
Так же понятно, что при утере или отсутствии одной из компонент восстановить ключ K невозможно.
При вводе ключа из компонент возникает вопрос, что делать с контрольным значением? Обычно контрольное значение рассчитывается только для самого ключа K, а компоненты передаются без контрольного значения. Но т.к длинна компонент такая же как и ключа и обычно это 3DES, то здесь легко ошибиться. Бывает, что и компоненты сопровождаются контрольным значением хотя в этом случаи контрольное значение ключа как бы бесполезено, но оно скажем так обязательный атрибут ключа. При сверка ключа обычно достаточно сверить контрольное значение.
Три великих курьера-офицера безопасности успешно ножками доставляют ключ в нужную точку. Если же между точками A и B будет идти довольной плотный обмен ключами то каждый раз по три человека не напосылаешся, в этом случаи используется следующий механизм — обмен ключами под ZCMK.
Обмен ключами под ZCMK
ZСMK (zone control master key) — ключ используемый для передачи ключей между точками A и B и не более для чего. Это частный случай так называемых KEK (key exchange key) ключей — ключей для обмена ключами.
Т.е. вы вначале обмениваетесь компонентно единственным ключом Kzcmk. Потом этим ключом шифруете и передаёте из точки A в точку B необходимые ключи. Главное требование к ключу Kzсmk должен использоваться только для обмена ключами и не для чего более!
Соответственно если у вас какая то распределённая структура узлов типа графа, то на каждом ребре графа будет использоваться свой ключ Kzсmk.
Узел С знает только ZCMKmc;
Узел M знает ZCMKmc, ZCMKmd, ZCMKma, но не знает ZCMKad;
Узел D знает ZCMKmd, ZCMKad, но не знает ZCMKmc, ZCMKma;
Узел A знает ZCMKMac, ZCMKad, но не знает ZCMKmd, ZCMKmc.
Конец 1-ой части.
Автор: Cobolorum
