Java-реализация 3DES и DUKPT для дешифрования данных для чтения кредитных карт с помощью эмуляции клавиатуры?

Question

У нас есть интерактивный интерфейс ввода-вывода, а также возможность прокрутки кредитной карты поддержки. В сегодняшней индустрии считыватель карт должен шифровать информацию перед ее кодировкой в ​​ASCII, а затем расшифровывать ее на стороне сервера. (так что локальная машина никогда не видит информацию о карте)

Я использую устройство чтения карт MagTek в режиме эмуляции клавиатуры и снабжаю его стандартным ключом ANSI, введенным для тестирования. Как только декодирование & дешифрование будет успешным, мы получим собственный ключ, зарегистрированный в MagTek, и закажем некоторые устройства для чтения.

Я знаю, что это дешифрование было реализовано ранее на C# и других языках, но нужно что-то в Java или, возможно, какая-то другая программа, доступная для CLI, которая может быть включена в Java Webapp. Я собираюсь продолжить перенос кода на C# на Java, но сначала нужно настроить среду C#. (Я никогда не делал этого раньше.)

Как только я убедился, что версия C# работает хорошо, я знаю, что могу устранить любые ошибки при портировании с помощью обычных методов отладки.

Прежде чем я пройду через все это, если есть более простой способ, дайте мне знать. Я бы подумал, что это уже сделано на Java, но, возможно, нет ...

Answer 1

Частичный ответ, CW для тех, кому нужно добавить.

Во-первых, это не ясно (для меня), если вы хотите запускать на компьютерах или аналогичных устройствах, где находятся салфетки, возможно, загружены (например, апплет или веб-сайт) или просто получить зашифрованные данные салфетки (в веб-форме?) и отправить его на ваш сервер для расшифровки. Я предлагаю, чтобы последнее упростило PCI DSS.

Java crypto, безусловно, 3DES под названием DESede (без учета регистра, как и все имена JCA Cipher). Один слегка неочевидный момент: реализация в SunJCE обрабатывает только полные 24-байтные ключи. DUKPT использует «2-ключ 3DES», поэтому вам нужно скопировать «left» в байты 0-7, «вправо» на 8-15 и «влево» снова на 16-23. Если вы используете BouncyCastle (как мой магазин), он может взять 16-байтный ключ и сделать копию внутри, что немного удобнее. (Симметричный ключ в Java является массивом байтов в классе тонкой оболочки, обычно javax.crypto.spec.SecretKeySpec.)

Если вы не знакомы с криптографией Java в целом, шаблон состоит в том, что вы получаете «экземпляр» конкретного алгоритма или режим от «поставщика» (вы можете указать один или позволить Java выбирать автоматически: несколько встроенных и более могут быть добавлены, например, «bcprov» с сайта www.BouncyCastle.org) с использованием общего класса API Cipher, Signature, MessageDigest и т. д. , затем инициализируйте этот экземпляр необходимыми параметрами (такими как ключ или IV и направление), затем вызовите методы для ввода входных данных и возврата вывода либо в отдельные (возможно, несколько) шаги, либо в простой комбинированный doFinal (что отлично подходит для вашего случая). Руководство JCA http://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/CryptoSpec.html#Cipher и javadoc для применимого класса API javax.crypto.Cipher (по адресу http://docs.oracle.com/javase/8/docs/api/index.html, а также автоматически отображаются в ведущих IDE) содержит полную информацию об этом.

Я не видел никакой открытой/свободной реализации DUKPT, но это не доказывает, что ее нет. Просто, хотя и немного утомительно, просто скопировать шаги из X9.24, если никто не предлагает лучше.