Pull to refresh

Comments 10

Работая со smart картами более 10 последних лет, плохо себе представляю, где кому то (частному лицу) можно официально купить/добыть Java карту.


NXP… даже не смешно. С их системой безопасности и учета, замучаешься пока password к уже присланным тестовым семплам получим.
GemAlto, oberthur, sagem..? В розницу не торгуют.
Китайцы… но они только начали свои карты выпускать под свой UPI (и реализация Java на многих кривая и глюкавая!)

Если знаете — подскажите, пожалуйста.
Лично мне это не нужно. Пол тумбочки не использованным семплами/белым пластиком от разных производителей забито.
Просто любопытно.
www.smart-card.ru/karty
www.smartcardfocus.com/shop/ilp/se~88/gemalto-smartcards/p/index.shtml

Я думаю, в интернете купить карты в розницу несложно. Но дорого.

Китайские карты, пожалуй, лучше вообще не трогать ;)

Что касается кодов доступа — образцы, которые мне присылали поставщики, как правило имели либо дефолтовые ключи, либо был известен motherkey, по которому ключи рассчитывались по известному алгоритму. Проблем не было.
Спасибо за ссылки. Даже не знал (точнее не интересовался).
Цена конечно с накруткой в 5 раз, но на розницу это даже весьма по божески.

Китайцы справятся. Еще год назад у них вообще чиповых карт не было. Но партия сказала «надо!» :)
Они еще весь мир завалят Java картами. Потеснят нынешних игроков и цены уронят. Впрочем NXP и GemAlto совсем не сочувствую.
Axalto после поглощения (по факту) Gemplus совсем стала не инновационной и коммерческой. Так, что не сочувствую ни сколько.

Дефолтные ключи или дефолтный KMC (4041..) сейчас практически у всех один и тот же…
Когда я был на конференции партнеров Gemalto несколько лет назад, я спросил у ребят оттуда «почему до сих пор у них в ассортименте нет карт с поддержкой JC API 3.x или хотя бы просто со сборщиком мусора». Получил ответ — «спроса нет».

Так что… инноваций действительно нет. Я думаю, там просто забыли, что инновации нужно создавать. Сами они не приходят. Тем более, что новинки востребованы.

Китайские карты я использовать побаиваюсь. Опасаюсь, что там, по заказу партии, дыр оставлено порядком. Да и не доверяю китайцам как разработчикам. Быть может, и напрасно.
А смысл в сборщике мусора?
Он по определению, в данном случае (EEPROM) будет не эффективен и даже вреден (ибо не предсказуем). А с учетом, того, что апплеты все же пишут не под конкретного производителя, то и сборку мусора никто не будет использовать.
EMV приложение вполне обходится без сборки мусора. И вообще, приходится каждый каждую строчку оптимизировать, что бы и размер пакета был меньше и производительность в критичных местах не пострадала и памяти ОЗУ хватило.
Кстати, 1024 — это всего (минимум из современных карт). Реально, более чем на 300 байт transient лучше не размахиваться (300 байт — это исключая apdu буфер).
А то можно на какой то карте и обломаться…
Я согласен, но потребности бывают разные. Кому-то GC нужен, кто-то готов смириться с тем, что все буферы нужно продумывать заранее.
Не позволяйте запускать вашу программу под виртуальными машинами (если это не требует ваше приложение)
Крайне не люблю товарищей, использующих этот совет. Из-за этого иногда приходится перезагружаться в винду вместо запуска её в виртуалке.
Мне жаль, что вы меня не любите, но все же возможность запуска ПО под виртуальной машиной облегчает взлом.
Да, это понятно. Как всегда, компромисс между удобством и безопасностью.

Можно базировать антиотладочный модуль не на детектировании запуска в виртуальной машине (которые используются всё чаще и чаще, те же vdi), а, например, на синхронизации с внешними событиями (время, внешний сервер лицензий и т. п.).
Я не уверен, что это комфортнее для пользователя. В любом случае, решать не мне. Я могу только рекомендовать, а решение будет принимать разработчик конкретной защиты.
Sign up to leave a comment.

Articles