Как зашифрованный текст генерировался в кард-ридере с использованием шифрования DUKPT?
За
`BDK = "0123456789ABCDEFFEDCBA9876543210"` `KSN = "FFFF9876543210E00008"`
Созданный зашифрованный текст был ниже
"C25C1D1197D31CAA87285D59A892047426D9182EC11353C051ADD6D0F072A6CB3436560B3071FC1FD11D9F7E74886742D9BEE0CFD1EA1064C213BB55278B2F12"`
который я нашел здесь. Я знаю, что этот зашифрованный текст основан на BDK и KSN, но как был создан этот зашифрованный текст длиной 128? Какие шаги в этом задействованы или алгоритм, используемый для этого? Может ли кто-то объяснить в простых шагах. Мне было трудно понять документы, которые я получил, когда гуглил.
4 ответа
Что касается DUKPT, в Wiki есть несколько объяснений. Если вам этого не достаточно, вот краткое объяснение.
Цитирование http://www.maravis.com/library/derived-unique-key-per-transaction-dukpt/
Что такое ДУКПТ?
Производный уникальный ключ для транзакции (DUKPT) - это схема управления ключами. Он использует одноразовые ключи шифрования, полученные из секретного главного ключа, который совместно используется объектом (или устройством), который шифрует, и объектом (или устройством), который расшифровывает данные. Почему ДУКПТ? Любой алгоритм шифрования является таким же безопасным, как и его ключи. Самый сильный алгоритм бесполезен, если ключи, используемые для шифрования данных с помощью алгоритма, не защищены. Это похоже на запирание двери самым большим и сильным замком, но если вы спрятали ключ под половиком, сам замок бесполезен. Когда мы говорим о шифровании, мы также должны помнить, что данные должны быть расшифрованы на другом конце. Как правило, самым слабым звеном в любой схеме шифрования является совместное использование ключей между сторонами, выполняющими шифрование и дешифрование. DUKPT - это попытка гарантировать, что обе стороны могут шифровать и дешифровать данные, не передавая ключи шифрования / дешифрования. В документе Cryptographic Best Practices, опубликованном VISA, также рекомендуется использовать DUKPT для соответствия PCI DSS.
Как работает DUKPT
DUKPT использует одноразовые ключи, которые генерируются для каждой транзакции и затем отбрасываются. Преимущество состоит в том, что если один из этих ключей будет взломан, будет взломана только одна транзакция. В DUKPT исходная (скажем, устройство ввода пин-кода или PED) и принимающая стороны (процессор, шлюз и т. Д.) Совместно используют ключ. Этот ключ фактически не используется для шифрования. Вместо этого другой одноразовый ключ, полученный из этого мастер-ключа, используется для шифрования и дешифрования данных. Важно отметить, что главный ключ не может быть восстановлен из полученного одноразового ключа. Чтобы расшифровать данные, принимающая сторона должна знать, какой главный ключ использовался для генерации одноразового ключа. Это означает, что принимающая сторона должна хранить и отслеживать главный ключ для каждого устройства. Это может быть много работы для тех, кто поддерживает много устройств. Лучший способ требуется иметь дело с этим. Вот как это работает в реальной жизни: у получателя есть главный ключ, называемый ключом базовой деривации (BDK). Предполагается, что BDK является секретным и никогда не будет передан кому-либо. Этот ключ используется для генерации ключей, называемых начальным ключом шифрования пин-кода (IPEK). Из этого генерируется набор ключей, называемых Future Keys, и IPEK отбрасывается. Каждый из ключей Future встроен в PED изготовителем устройства, которому они передаются. Этот дополнительный шаг деривации означает, что получателю не нужно отслеживать каждый ключ, который входит в PED. Они могут быть сгенерированы заново при необходимости.
Получатель делится ключами Future с производителем PED, который встраивает один ключ в каждый PED. Если один из этих ключей скомпрометирован, PED может быть повторно введен в ключ с новым ключом Future, который получен из BDK, поскольку BDK по-прежнему безопасен.
Шифрование и дешифрование
Когда данные должны быть отправлены из PED в приемник, ключ Future в этом устройстве используется для генерации одноразового ключа, а затем этот ключ используется с алгоритмом шифрования для шифрования данных. Затем эти данные отправляются получателю вместе с серийным номером ключа (KSN), который состоит из идентификатора устройства и счетчика транзакций устройства.
На основе KSN получатель затем генерирует IPEK и на основе этого генерирует ключ будущего, который использовался устройством, а затем фактический ключ, который использовался для шифрования данных. С помощью этого ключа получатель сможет расшифровать данные.
Source
Во-первых, позвольте мне процитировать полный исходный код, который вы связали, и из которого вы предоставили только 3 строки...
require 'bundler/setup'
require 'test/unit'
require 'dukpt'
class DUKPT::DecrypterTest < Test::Unit::TestCase
def test_decrypt_track_data
bdk = "0123456789ABCDEFFEDCBA9876543210"
ksn = "FFFF9876543210E00008"
ciphertext = "C25C1D1197D31CAA87285D59A892047426D9182EC11353C051ADD6D0F072A6CB3436560B3071FC1FD11D9F7E74886742D9BEE0CFD1EA1064C213BB55278B2F12"
plaintext = "%B5452300551227189^HOGAN/PAUL ^08043210000000725000000?\x00\x00\x00\x00"
decrypter = DUKPT::Decrypter.new(bdk, "cbc")
assert_equal plaintext, decrypter.decrypt(ciphertext, ksn)
end
end
Теперь вы спрашиваете, как был создан "зашифрованный текст"...
Ну, во-первых, мы знаем, что он основан на "незашифрованном тексте", который используется в коде для проверки работоспособности дешифрования.
Открытый текст заполнен нулями, что соответствует шифрованию, которое проверяется путем проверки дешифрования с помощью этого тестового набора DecrypterTest.
Давайте посмотрим на код кодировки тогда...
Я нашел соответствующий код шифрования по адресу https://github.com/Shopify/dukpt/blob/master/lib/dukpt/encryption.rb.
Поскольку DecrypterTEst использует "cbc", становится очевидным, что шифрование использует:
@cipher_type_des = "des-cbc"
@cipher_type_tdes = "des-ede-cbc"
Чуть дальше код шифрования, следующее решает наш поиск ответа:
ciphertext = des_encrypt(...
Что показывает, что мы действительно смотрим на результат шифрования DES.
Теперь DES имеет размер блока 64 бита. Это (64/8=) 8-байтовый двоичный файл, или - поскольку "шифрованный текст" представляет собой шестнадцатеричное текстовое представление байтов - 16-значный шестнадцатеричный код.
"Зашифрованный текст" имеет длину 128 шестнадцатеричных символов, что означает, что он содержит (128 шестнадцатеричных символов /16 шестнадцатеричных символов =) 8 блоков DES с каждыми 64 битами зашифрованной информации.
Завершая все это простым ответом:
Когда вы смотрите на "зашифрованный текст", вы смотрите на (8 блоков) зашифрованных данных DES, которые представлены с помощью удобочитаемой шестнадцатеричной записи (2 шестнадцатеричных числа = 1 байт) вместо исходных двоичных байтов, которые шифрование DES будет выполнять. производить.
Что касается шагов, связанных с "воссозданием" зашифрованного текста, я склоняюсь к тому, чтобы вы просто использовали соответствующие части проекта ruby, на которых вы основывали свой вопрос. Просто нужно посмотреть на исходный код. Файл по адресу " https://github.com/Shopify/dukpt/blob/master/lib/dukpt/encryption.rb" в значительной степени объясняет все это, и я уверен, что все необходимые вам функции можно найти в GitHub проекта. репозиторий. Кроме того, вы можете попытаться воссоздать его самостоятельно, используя предпочитаемый вами язык программирования. Вам нужно обрабатывать только 2 вещи: шифрование / дешифрование DES и преобразование двоичного в шестнадцатеричное / шестнадцатеричное в двоичное.
Поскольку это одна из первых тем, которая возникла в связи с этим, я решил поделиться тем, как мне удалось зашифровать зашифрованный текст. Это первый раз, когда я работал с Ruby, и это было специально для работы с DUKPT
Сначала я должен был получить метод ipek и pek (такой же, как в расшифровке). Затем распакуйте текстовую строку. Преобразуйте распакованную строку в массив из 72 байтов (опять же, простите, если моя терминология неверна).
Я заметил, что в примере автора dukpt gem он использовал следующую текстовую строку
"%B5452300551227189^HOGAN/PAUL ^08043210000000725000000?\ X00\x00\x00\x00"
Я считаю, что эта строка неверна, так как после имени не должно быть пробела (AFAIK).. поэтому она должна быть
"% B5452300551227189 ^ Хоган / ПОЛ ^ +08043210000000725000000? \ X00\x00\x00\x00"
В общем, это решение, на котором я остановился, которое может зашифровать строку и затем расшифровать ее с помощью DUKPT.
class Encrypt
include DUKPT::Encryption
attr_reader :bdk
def initialize(bdk, mode=nil)
@bdk = bdk
self.cipher_mode = mode.nil? ? 'cbc' : mode
end
def encrypt(plaintext, ksn)
ipek = derive_IPEK(bdk, ksn)
pek = derive_PEK(ipek, ksn)
message = plaintext.unpack("H*").first
message = hex_string_from_unpacked(message, 72)
encrypted_cryptogram = triple_des_encrypt(pek,message).upcase
encrypted_cryptogram
end
def hex_string_from_unpacked val, bytes
val.ljust(bytes * 2, "0")
end
конец
boomedukpt FFFF9876543210E00008 "% B5452300551227189 ^ HOGAN / PAUL ^ 08043210000000725000000?"
(мой рубиновый драгоценный камень, KSN и текстовая строка)
2542353435323330303535313232373138395e484f47414e2f5041554c5e30383034333231303030303030303732353030303030303f000000000000000000000000000000000000
(мой рубиновый гем делает кладу на распакованную строку после вызова hex_string_from_unpacked)
C25C1D1197D31CAA87285D59A892047426D9182EC11353C0B82D407291CED53DA14FB107DC0AAB9974DB6E5943735BFFE7D72062708FB389E65A38C444432A6421B7F7EDD559AF11
(мой рубиновый самоцвет делает зашифрованную строку)
% B5452300551227189 ^ Хоган / ПОЛ ^ +08043210000000725000000?
(мой рубиновый драгоценный камень делает путы после вызова decrypt для драгоценного камня dukpt)
Посмотрите на это: https://github.com/sgbj/Dukpt.NET, я был в подобной ситуации, когда я задавался вопросом, как реализовать dukpt на терминале, когда у терминала есть свои собственные вызовы функций, которые принимают INIT и KSN для создания первый ключ, поэтому моя единственная проблема состояла в том, чтобы убедиться, что ключ INIT был сгенерирован на терминале так же, как и в вышеупомянутом коде репозитория, что было достаточно просто с использованием библиотеки шифрования ossl для 3des с ebc и применением соответствующих масок,