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

[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 нужен, кто-то готов смириться с тем, что все буферы нужно продумывать заранее.

[grossws]

Не позволяйте запускать вашу программу под виртуальными машинами (если это не требует ваше приложение)

Крайне не люблю товарищей, использующих этот совет. Из-за этого иногда приходится перезагружаться в винду вместо запуска её в виртуалке.

[FractalizeR]

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

[grossws]

Да, это понятно. Как всегда, компромисс между удобством и безопасностью.

Можно базировать антиотладочный модуль не на детектировании запуска в виртуальной машине (которые используются всё чаще и чаще, те же vdi), а, например, на синхронизации с внешними событиями (время, внешний сервер лицензий и т. п.).

[FractalizeR]

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