Использование Java смарт-карт для защиты ПО. Глава 4. Пишем первый апплет

[kalabro]

Мой товарищ-нехабраюзер, возмущённый качеством представленных здесь материалов по JavaCard, отрекомендовал читать книжки и не читать русскую википедию:

А всем интересующимся вот книжка на русском:
Java Card Technology for Smart Cards: Architecture and Programmer's Guide
Автор: Жикун Чен
Издательство: Техносфера
Серия: Мир программирования
ISBN 978-5-94836-143-7, 0-201-70329-7; 2008 г.

[FractalizeR]

Вы не могли бы попросить его прокомментировать его возмущение? Можно мне на почту, если у него нет доступа на Хабр.

Книга, на которую вы ссылаетесь, замечательная. Однако, на Хабре книги размещать смысла не имеет. И отсылать читателей Хабра к книгам тоже (иначе вообще зачем статьи писать?).

Я буду признателен за любую критику размещенных мной публикаций.

[receiver]

Спасибо за статью. Вы пишите, что int не поддерживается, на самом деле это не совсем так. Данный тип является опциональным по спецификации, и в конкретных реализациях JCRE он может быть, и может не быть.

По примеру:

        // Заполняем буфер произвольными байтами
        for (byte i = 0; i < 120; i++) {
            buffer[i] = i;
        }

Произвольные байты это не 1…120, как минимум рекомендуется сделать так:

RandomData.getInstance(RandomData.ALG_SECURE_RANDOM).generateData(buffer, (short)0, (short) 120);

будет надежнее и быстрее чем цикл.

Второй момент — фрагментация памяти карты при управлении апплетами. Апплет в памяти карты — что файл на жестком диске. Если вы удалите апплет, записанный перед каким-нибудь другим, в памяти карты останется «дырка» свободного пространства размером с удаленный апплет.

Здесь есть некоторая путаница,  следует различать код апплета и созданный экземпляр класса. Код апплета может храниться как в EEPROM, так и в ROM (маска). Экземпляр класса хранится в EEPROM.
Соотвественно, можно создать несколько экземпляров апплета с разными AID, и при этом будет выдяляться память необходимая именно на хранение экземляра класса апплета.

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

Тут все как раз просто. Есть встроенный в NetBeans отладчик правда для JC 3.0.4, есть JCOP Tools, а если хотите под все платформы и бесплатно, и еще писать unit-тесты — вот наш проект jCardSim.

[receiver]

Пардон, спросоня.
«Произвольные байты это не 1…120», имел в виду, конечно, 0...119.

[FractalizeR]

Да, я понял. Спасибо за комментарий.

По поводу int наверное, вы правы. Я не помню, чтобы в спецификации был какой-то запрет на поддержку этого типа. Однако в моей практике карты с его поддержкой не встречались. Кроме того, официальный конвертер из JC SDK 2.2.x не конвертит апплеты, в которых используется int. Говорит, неизвестный тип, если не ошибаюсь.

Что касается апплетов — все верно. Однако апплеты, хранящиеся в ROM я вообще не рассматривал. Понятно, что их загружать в карту не нужно. Достаточно создать экземпляр.

Про Netbeans я, по-моему, упоминал в статьях. Карт, поддерживающих 3.x версию SDK мне не попадалось. Поэтому и Netbeans я не использовал. Мне кажется, их и сейчас на рынке немного.

[receiver]

.

[receiver]

… конвертер из JC SDK 2.2.x не конвертит апплеты, в которых используется int...

-i опция конвертора (-i
Instructs the Converter to support the 32-bit integer type.)

Не совсем справедливо делать выводы о том как работает менеджер памяти и gc в общем случае, основываясь на поведении конкретных реализаций Java Card.

Карт, поддерживающих 3.x версию SDK мне не попадалось.

Карт, кстати, достаточно,  в том числе и российских www.esmart.ru/_products/_token-gost.  Опять таки, нужно разделять 3.0.x Classic  и Connected Edtion. Хоть Вы и говорите в начале о том, что речь пойдет о 2.2.1, но было бы здорово добавить, как дела обстоят сейчас.

[FractalizeR]

Разумеется, добавлю. Спасибо.

[maksimsuvorov]

Как данная технология защищена от кардшаринга (наподобие активно используемой в системах спутникового ТВ) в комплекте со средствами отладки ПО и MITM?

[FractalizeR]

Ява-карта — это просто черный ящик для вашего секретного апплета, который что-то там такое секретное делает. Все остальное зависит от вас как от разработчика. Сама карта за вас ничего не сделает.

• От отладки нужно защищаться средствами вроде Themida или StarForce (я об этом писал).
• По поводу Man-in-the-middle — не понял, что за ситуацию вы имеете ввиду. Эмуляцию карты?

От кардшаринга можно попробовать защититься так

• При начале работы софт устанавливает с картой защищенную сессию. При завершении работы — завершает ее, производя некий handshake с картой. Если осуществляется попытка начать новую сессию без завершения предыдущей, некий счетчик внутри карты увеличивается. При достижении X таких попыток карта блокируется. Но это сильно зависит от вашей специфики. Возможно, от таких мер просто взвоют пользователи.
• Софт, защищенный навесным протектором, может измерять скорость получения ответа от карты. Карта, расположенная локально, отвечать будет довольно быстро. Карта, расположенная в сети, будет отвечать заметно медленнее. В зависимости от качества соединения, расшаренная по сети карта скорее всего будет иметь непредсказуемое время ответа. Это можно замерять и блокировать карту при достижении определенных критериев.
  
• Карта сама может хранить несколько последних меток времени, полученных через протокол общения с ПО и действовать самостоятельно с учетом этой информации

Как вы понимаете, карта сама никак не может установить, расшарили ее или нет. В стандартных условиях канал связи с картой приложение обычно открывает эксклюзивно, поэтому без вторжения в ОС расшарить карту будет сложно. Но, конечно, можно пустить общение с картой через свой канал, сняв это ограничение.

[maksimsuvorov]

Да, я имел ввиду общение между софтом и картой через свой канал. Защиту от отладки при очень большом желании гипотетически можно снять. Блокировать карту при достижении счетчика определенных значений — тоже не лучший вариант, учитывая закон о защите прав потребителей (сначала нужно доказать, что это не какой-либо сбой), тем более, как правило, защищающие права потребителей стоят на стороне потребителей, плюс этим конкуренты могут воспользоваться и заполнить интернет негативом. По поводу измерения скорости получения ответа от карты — хороший вариант, но никто не запрещает поставить ПО на сервер, завести туда 1000 учетных записей с софтом и продавать решение в «облаке». Вопрос в том, насколько популярен софт и какую потенциальную прибыль он может принести разработчику. Я бы предложил разработчикам, пользующихся данным решением, добавить в подозрительных случаях СМС верификацию (например при переполнении счетчика карты), так как приплетать дополнительно смс шлюз с сим-картой для взлома — это уже перебор, хотя… В целом годная схема, спасибо

[FractalizeR]

Когда вы работаете с ява-картами, единственная вещь, которую сделать действительно невозможно — это извлечь ваш апплет из карты и проанализировать его. Поэтому, если в вашем ПО нет никакой логики, которую можно было бы поместить в апплет, защита не будет абсолютно надежной.

Мои клиенты — в основном авторы ПО для разблокировки сотовых телефонов. Как правило, там много чего можно в карту поместить (алгоритмы расчета кодов, ключи авторизации и прочее). Если у вас, скажем, бухгалтерское ПО, вряд ли использование ява-карты даст вам преимущество по сравнению с использованием какого-нибудь HASP или Guardant ключа.

[Blooderst]

Если кто-либо захочет использовать этот пример (я бы не советовал), не забудте вызвать в конструкторе после инициализации ключа еще и инициализацию чипера:

cipher.init(key, Cipher.MODE_ENCRYPT);

Ведь если ключ создавался, значит он для чего-нибудь нужен =)

[FractalizeR]

Этот апплет — "пример", как и указано в его заголовке. Поэтому, конечно, в прод его пускать не нужно.

[vvzvlad]

А можете что-нибудь сказать касательно JCOP-кард с поддержкой бесконтактной связи? В частности, интересует, как их программировать, насколько полный есть доступ к радиоинтерфейсу, как выглядит эмуляция mifare, можно ли перезаписывать апплеты через бесконтактный интерфейс, и так далее.

[FractalizeR]

Честно говоря, никогда не работал с такими. Я уже достаточно давно не имею дела с картами в целом. Для меня это уже в прошлом. Могу попробовать высказать догадки.

В частности, интересует, как их программировать

Полагаю, что обычным способом. Бесконтактный интерфейс — суть транспортный протокол. Его сложность должна скрываться драйверами ридеров.

насколько полный есть доступ к радиоинтерфейсу

Думаю, будет зависеть от ридера. Я не помню, чтобы в WinAPI было хоть что-то для работы с радиоинтерфейсом напрямую.

как выглядит эмуляция mifare

Если мне не изменяет память, в картах, с которыми работал я, ее не было вообще. Нужно смотреть в доку по конкретному варианту карт. JCOP — это ведь не модель карты, а только стандарт их разработки.

можно ли перезаписывать апплеты через бесконтактный интерфейс

Опять же, думаю, все будет зависеть от ридера. Ограничений программного уровня я тут не вижу. Протокол связи с картой не имеет значения. Для ее программирования в нее нужно посылать команды сильно похожие на те, что предназначены просто для общения с ней.

[alterpub]

Присоединяюсь к вопросу про JCOP-карты, интересно.
А вообще, посоветуйте, с каких ресурсов начинать как новичку в мире java карт?

[FractalizeR]

Присоединяюсь к вопросу про JCOP-карты, интересно.

Про JCOP я ответил чуть выше.

А вообще, посоветуйте, с каких ресурсов начинать как новичку в мире java карт?

Сложно сказать. Я начинал с мануала по картам egate. Они были достаточно примитивны, а мануал — достаточно верхнеуровнев, чтобы зайти в качестве helloworld. Потом я переключился на доку по GlobalPlatform, однако, карты иногда по-своему реализуют некоторые части стандарта, так что мануал рядом держать все равно стоит.

Можно в Амазоне поискать книжки по программированию смарт-карт, но я не читал ни одну, так что не могу тут ничего посоветовать. Есть шанс, что книга с названием "Smartcard programming" или что-то в этом роде будет совсем не про те карты, что у вас на руках.