В данном цикле статей пойдет речь об использовании Java смарт-карт (более дешевых аналогов электронных ключей) для защиты программного обеспечения. Цикл разбит на несколько глав.
Для прочтения и осознания информации из статей вам понадобятся следующие навыки:
- Основы разработки ПО для Windows (достаточно умения программировать в любой визуальной среде, такой как Delphi или Visual Basic)
- Базовые знания из области криптографии (что такое шифр, симметричный, ассиметричный алгоритм, вектор инициализации, CBC и т.д. Рекомендую к обязательному прочтению Прикладную Криптографию Брюса Шнайера).
- Базовые навыки программирования на любом языке, хотя бы отдаленно напоминающем Java по синтаксису (Java, C++, C#, PHP и т.д.)
Цель цикла — познакомить читателя с Ява-картами (литературы на русском языке по их использованию крайне мало). Цикл не претендует на статус «Руководства по разработке защиты ПО на основе Ява-карт» или на звание «Справочника по Ява-картам».
Состав цикла:
- Глава 1. Ява-карта. Общие-сведения.
- Глава 2. Ява карта с точки зрения разработчика апплетов
- Глава 3. Установка и настройка IDE
- Глава 4. Пишем первый апплет
- Глава 5. Безопасность
В 90% случаев вы не сможете придумать такого алгоритма, который обладал бы всеми следующими свойствами:
- при удалении этого алгоритма из программы, ваше ПО становилось бы полностью нефункциональным
- хакер не мог бы угадать и сэмулировать этот алгоритм
Если вы попали на эти 90%, то вам в обязательном порядке следует:
- Шифровать все коммуникации с картой
- Защищать свое программное обеспечение навесным протектором типа Themida
1. Шифрование обмена данными с картой
Если вы желаете выстроить надежную защиту, ключи шифрования трафика должны меняться. Новый ключ следует генерировать как минимум каждый раз, когда запускается ваше приложение. Генерировать сессионные ключи следует на основании данных, как предоставленных картой, так и вашей программой. Механизм защищенной сессии может в примитивном варианте выглядеть, например, так:
- Есть некий мастер-ключ DES M. Его знают карта и софт.
- Карта генерирует 4 байта случайных данных (Ccard), софт генерирует 4 байта случайных данных (Csoft). Они обмениваются друг с другом этой информацией.
- Карта и софт совмещают оба массива (Ccard + Csoft), шифруют получившийся набор байтов мастер-ключом M. Получается 8 байт ключа 1DES, которым впоследствии будет шифроваться весь обмен в текущем сеансе.
Внимание! Ни в коем случае не делайте так, как описано.
В случае, если расшифрованные данные кажутся карте некорректными, ее следует заблокировать. Самый простой вариант реализовать подобный вариант — завести в классе апплета булево поле CardIsLocked и проверять его содержимое в методе process перед вызовом метода, соответствующего переданному коду команды. Если CardIsLocked — отдавать софту вместо данных ошибку.
2. Использование возможностей Themida
Themida по праву считается одним из самых трудных для снятия протекторов. Однако просто повесить сверху проектор — мало. Если вы желаете построить действительно надежную защиту, вам следует задействовать API Themida в полной мере:
- Обязательно используйте для защиты механизм виртуальных машин Themida
- Обратите особое внимание на раздел справки Themida, который называется «SecureEngine® Macros». Разрабатывая свой собственный механизм безопасной сессии для общения с картой, заключите весь код, обеспечивающий коммуникацию с картой в такие макросы, как VM_Start/End, Code_Replace_Start/End.
- Обычно защищенная сессия обмена данными с картой устанавливается один раз при запуске приложения. Если это справедливо и в вашем случае, поместите код, отвечающий за начало защищенной сессии в макросы Clear_Start/End, чтобы после установки защищенной сессии, код, который это делает был удален из адресного пространства процесса.
- Используйте внутри функций, работающих с картой, макросы CheckProtectionStart/End, CheckCodeIntegrityStart/End.
- Не позволяйте запускать вашу программу под виртуальными машинами (если это не требует ваше приложение)
3. Криптографические ловушки. Несколько из поджидающих вас миллионов.
Работая с криптографией важно понимать, что вы делаете, что можно делать, а чего нельзя. Разумеется, если вы защищаете смарт-картой консольный тетрис, вы можете позволить себе все, что угодно. Но если этот тетрис уникален и принесет вам завтра миллион долларов… Тогда, например, единожды использовав определенный вектор инициализации с конкретным DES ключом, не делайте это снова.
Не изобретайте собственных супер-секретных-никому-не-известных собственных алгоритмов шифрования и хеширования. Помните о судьбе GSM A5/3 шифра и его бедных авторах, решивших, что уж они-то суперкриптографы.
Спроектировав супер-стойкую систему защиты не оставляйте в ней тупых дырок, вроде той в банковском клиенте на базе BS-Client.
4. Благодарность терпеливым читателям
Спасибо всем, кто дочитал до этого места. Благодарности и негодования принимаются.
Буду рад любым вопросам в комментариях и постараюсь обновлять статью так, чтобы она включала ответы.
mmMike
Работая со smart картами более 10 последних лет, плохо себе представляю, где кому то (частному лицу) можно официально купить/добыть Java карту.
NXP… даже не смешно. С их системой безопасности и учета, замучаешься пока password к уже присланным тестовым семплам получим.
GemAlto, oberthur, sagem..? В розницу не торгуют.
Китайцы… но они только начали свои карты выпускать под свой UPI (и реализация Java на многих кривая и глюкавая!)
Если знаете — подскажите, пожалуйста.
Лично мне это не нужно. Пол тумбочки не использованным семплами/белым пластиком от разных производителей забито.
Просто любопытно.
FractalizeR Автор
www.smart-card.ru/karty
www.smartcardfocus.com/shop/ilp/se~88/gemalto-smartcards/p/index.shtml
Я думаю, в интернете купить карты в розницу несложно. Но дорого.
Китайские карты, пожалуй, лучше вообще не трогать ;)
Что касается кодов доступа — образцы, которые мне присылали поставщики, как правило имели либо дефолтовые ключи, либо был известен motherkey, по которому ключи рассчитывались по известному алгоритму. Проблем не было.
mmMike
Спасибо за ссылки. Даже не знал (точнее не интересовался).
Цена конечно с накруткой в 5 раз, но на розницу это даже весьма по божески.
Китайцы справятся. Еще год назад у них вообще чиповых карт не было. Но партия сказала «надо!» :)
Они еще весь мир завалят Java картами. Потеснят нынешних игроков и цены уронят. Впрочем NXP и GemAlto совсем не сочувствую.
Axalto после поглощения (по факту) Gemplus совсем стала не инновационной и коммерческой. Так, что не сочувствую ни сколько.
Дефолтные ключи или дефолтный KMC (4041..) сейчас практически у всех один и тот же…
FractalizeR Автор
Когда я был на конференции партнеров Gemalto несколько лет назад, я спросил у ребят оттуда «почему до сих пор у них в ассортименте нет карт с поддержкой JC API 3.x или хотя бы просто со сборщиком мусора». Получил ответ — «спроса нет».
Так что… инноваций действительно нет. Я думаю, там просто забыли, что инновации нужно создавать. Сами они не приходят. Тем более, что новинки востребованы.
Китайские карты я использовать побаиваюсь. Опасаюсь, что там, по заказу партии, дыр оставлено порядком. Да и не доверяю китайцам как разработчикам. Быть может, и напрасно.
mmMike
А смысл в сборщике мусора?
Он по определению, в данном случае (EEPROM) будет не эффективен и даже вреден (ибо не предсказуем). А с учетом, того, что апплеты все же пишут не под конкретного производителя, то и сборку мусора никто не будет использовать.
EMV приложение вполне обходится без сборки мусора. И вообще, приходится каждый каждую строчку оптимизировать, что бы и размер пакета был меньше и производительность в критичных местах не пострадала и памяти ОЗУ хватило.
Кстати, 1024 — это всего (минимум из современных карт). Реально, более чем на 300 байт transient лучше не размахиваться (300 байт — это исключая apdu буфер).
А то можно на какой то карте и обломаться…
FractalizeR Автор
Я согласен, но потребности бывают разные. Кому-то GC нужен, кто-то готов смириться с тем, что все буферы нужно продумывать заранее.