Привет, Гиктаймс!

Сегодня я бы хотел поговорить о JavaCard. Данная статья будет посвящена понятию JavaCard и обзору ее архитектуры. Если есть интерес к этой теме, то я бы мог написать отдельную серию статей, в которых будут подробно освящаться все аспекты JavaCard. Сразу скажу, что я не собираюсь учить вас, как написать свое первое приложение в JavaCard, т.к. по этому поводу уже существует слишком много статей в Интернете. Мы поговорим сегодня преимущественно о принципах работы JavaCard.

Итак, смарт-карта на основе JavaCard — это карта, на которой приложения исполняются на JavaCard Virtual Machine (ограниченная версия Java Virtual Machine, адаптированная для смарт-карт) в так называемом JavaCard Runtime Environment (который с Java Runtime Environment имеет очень мало общего).

Что касается терминологии, то приложения называются Applets и содержатся в Packages (пакетах). Пакеты распространяются в CAP-files (вместо Jar-files). Пакеты и приложения имеют собственный AID (Application Identifier). Это необходимо для того, чтобы их можно было однозначно идентифицировать в таких командах, как: SELECT, INSTALL, DELETE, и т.д. (SELECT описывается в ISO7816-4, а JavaCard и остальные команды — в Global Platform).

Жизненный цикл Applets несколько отличается от привычного жизненного цикла приложений для компьютеров. Applet — это любой класс, наследующий от базового класса «Applet». При установке приложений вызывается его статический метод install. Этот метод должен создать объект соответствующего класса и вызвать на него метод register. Впоследствии объект будет сохранен в системе и получит собственный AID, который будет использован для дальнейшего общения с приложением. Объект и его поля данных сохраняются в NVM (Non-Volatile Memory). Каждый объект или массив, созданный приложением с помощью оператора «new», также будет находиться в NVM. Это означает, что, в отличие от традиционных компьютерных программ, состояние приложений JavaCard является постоянным и не теряется даже при выключении карты.

Привет, Гиктаймс!

В прошлой части мы видели как происходит общение между терминалом и картой. Мы посмотрели форматы C-APDU и R-APDU, но мы не обращали внимания на то, какие данные содержат эти APDU. В этой части мы рассмотрим самые распространенные форматы, в которых передается информация между терминалом и картой (и наоборот). Все они относятся к одному семейству — TLV.

TLV означает Tag, Length, Value и используется для того, чтобы структурировать информацию. На очень абстрактном уровне, TLV можно рассматривать как бинарную версию XML. Однако что такое Tag, Length, Value?

• Tag: он говорит, какой вид информации находится в TLV. Видом может быть, к примеру, простая строка или номер, идентификатор или даже сложная структура. В некоторых вариантах Tag также содержит мета-информацию о TLV.
• Length: длина, в байтах, элемента Value.
• Value: данные, содержащиеся в TLV

Каждый вариант TLV имеет свои правила кодирования каждого элемента. Далее мы посмотрим самые распространенные варианты TLV. Хочу сразу отметить, что данная статья будет, в основном, посвящена BER-TLV, поскольку это самый распространенный, гибкий и сложный формат. Остальные варианты TLV будут рассмотрены лишь вкратце.

Совсем недавно я окунулся в мир роботики и решил запрограммировать собственного робота на основе RasPi. Для этого я использовал Elixir, сравнительно новый, к слову сказать, язык программирования, который компилируется в байткод для Erlang VM. У меня сразу же возникла трудность с управлением контактами GPIO. Тогда я нашел библиотеку, которая вроде бы решала все мои проблемы. Однако она была написана как Port, из-за чего каждый вызов ее функций занимал слишком много времени, что влияло на правильность работы моего робота.

Немного подумав, я все-таки решился переписать библиотеку в виде NIF. Так как я не нашел много информации по этому поводу, я решил поделиться своим опытом написания NIF в Elixir с вами. Как пример я буду использовать то, что я создал.

Привет, Гиктаймс!

После общей информации, описанной в первой части, сегодня поговорим об APDU в формате, описанном в стандарте ISO7816-4.

APDU (application protocol data unit) — это формат общения карты и терминала. Терминал посылает Command APDU (C-APDU), а карта отвечает с Response APDU (R-APDU).

C-APDU

Формат C-APDU таков:

Header	Body
CLA INS P1 P2	[Lc field] [Data field] [Le field]

Каждый элемент заголовка (header) сохранен на одном байте и является обязательным. К заголовку вернемся чуть позже, сейчас поговорим о body команды.

Элементы body следующие:

• Lc: длина элемента Data в байтах.
• Data: данные команды.
• Le: ожидаемая длина данных ответа в байтах, исключая длину Status Word.

Lc и Le, если присутствуют, могут занимать 1 (Short Length) или 3 байта (Extended Length) каждый. При Short Length кодируются значения от 1 до 256. Длина данных на 256 байтов записывается как «00». При Extended Length кодируются значения от 1 до 65536. Первый байт всегда «00» и остальные 2 байта — номер в формате Big Endian. Когда Lc или Le — «00 00 00», то длина данных — 65536 байтов.

В зависимости от присутствия или отсутствия элементы body команды можно разделить на 4 категории:

• Case 1: Body полностью отсутсвует, то есть команда не содержит в себе никаких данных и не ожидается получение каких либо данных от карты при ответе.
• Case 2: В body присутствует только Le, то есть команда не содержит в себе никаких данных, но при этом ожидается получение данных от карты.
• Case 3: В body присутствуют Lc и Data, то есть команда содержит в себе данные, но при этом не ожидается получение данных от карты.
• Case 4: В body присутствуют все элементы, а значит команда содержит в себе данные и ожидается получение данных от карты.

Все мы пользуемся разными видами смарт-карт в повседневной жизни. Наиболее яркими примерами смарт-карт являются: SIM-карты, кредитные карты, электронные документы и т.д.

По сути, смарт-карта — это оптимизированный для криптографии микроконтроллер с повышенным уровнем безопасности. Что это означает? В отличие от стандартного микроконтроллера доступ к памяти смарт-карты строго контролируется процессором. Таким образом, чтение данных с карты их написание на ней регулируются ПО самой карты. Более того, производители чипов предпринимают меры по предотвращению несанкционированного доступа (копирования всей памяти, перепрограммирования) к карте на электронном и физическом уровне.