Смарт-карты для самых маленьких

Поскольку статья вводная и обзорная, то рассматриваться будет простейшая разновидность смарт-карт — SIM-карты, полагаю, что таких карт на планете сейчас больше всего.
По сегодняшним меркам стандарт SIM выглядит архаично, но зато он идеален для первого знакомства с миром смарт-карт, усвоение принципов, которые заложены в основу этого стандарта, облегчит дальнейшее погружение в тему.
Если Вы «карточник», то вряд ли узнаете для себя что-то новое, разве что какие-нибудь не очень понятные моменты разложатся по полочкам, а может быть Вы разложете по полочкам то, что недопонял автор (но, напоминаю, держимся в рамках SIM!).

Смарт-карта является программно-аппаратным комплексом, по сути — миниатюрным компьютером, в состав которого входят, как минимум:

• процессор;
• оперативная память;
• подсистема хранения данных;
• операционная система.

Часто, но не всегда, в состав карты входит и Java VM. ОС, как таковая, конечному пользователю не видна.

APDU

Роль API выполняет обмен данными с картой посредством т.н. APDU.
Множество различных APDU представляет из себя набор команд, каждая из которых имеет следующую структуру (согласно ISO7816-4):

APDU принято записывать в виде набора шестнадцатиричных цифр, вот так:

A0 A4 00 00 02 3F00

Для GSM SIM-карт используется CLA = A0.
Приведу несколько кодов инструкций:

В ответ на APDU карта всегда возвращает, как минимум, 2 байта, т.н. Status Word (SW),
причем первый и второй байт соответственно принято называть SW1 и SW2. По SW можно определить статус исполнения команды, причем SW1 обычно предоставляет основную информацию, а SW2 — дополнительную. В случае SIM-карт об успехе выполнения будут говорить статусы 90 00 и 9F xx (здесь xx — шестнадцатиричная цифра, длина дополнительной информации, о которой ниже).
Помимо SW карта может вернуть и данные. Есть также команды, после выполнения которых возможно получить дополнительную информацию.
Для этого предназначена команда:

GET RESPONSE

Для того, чтобы воспользоваться «услугами» этой инструкции, нужно иметь в виду, что она должна быть вызвана сразу после той команды, результат которой требуется запросить. При вызове любой инструкции, отличной от GET RESPONSE, контекст предыдущей команды будет утрачен.
Если какая-либо инструкция позволяет использовать после своего вызова GET RESPONSE, то она в SW2 возвращает объем данных в байтах, который вернет команда GET RESPONSE.
Одним из ярких применений GET RESPONSE является ее использование после команды SELECT — оно дает возможность получить полезную информацию о выбранном объекте файловой системы.

Подсистема хранения данных

Кстати, самое время вспомнить о файловой системе карты. Система эта является иерархической, существует корневая папка (Master File, MF), обычные папки (Dedicated File, DF) и, собственно, файлы (Elementary File, EF). Каждый объект файловой системы имеет идентификатор (File ID, FID), который, в простейшем случае, состоит из четырех шестнадцатиричных цифр и который заменяет ему имя. Например, MF всегда имеет идентификатор 3F00. В рамках каждого карточного стандарта существует свой перечень зарезервированных файловых идентификаторов, например, файл адресной книги на SIM имеет идентификатор 6F3A, а файл для хранения SMS — 6F3C. У стандартных файлов также имеются и произносимые имена (исключительно для удобства человека, API их не использует), для указанных выше файлов они, такие:
EF ADN для 6F3A;
EF SMS для 6F3С.

В случае с SIM-картами стандартные сценарии использования не предусматривают модификации файловой структуры, т.е. невозможно создать EF или DF.
Возможно только модифицировать содержимое файлов. Конечно, жизнь диктует и нестандартные сценарии, но сейчас мы их рассматривать не будем.

Типы файлов

API смарт-карт предусматривает манипуляции с тремя типами файлов:

1. Transparent

   аналог обычного бинарного файла любой файловой системы.
   Средства работы с такими файлами — пара команд READ BINARY/UPDATE BINARY.

2. Linear Fixed

   Файл, состоящий из фиксированного количества записей, причем все записи одинаковой длины, длина записи задается при создании файла.
   Записей не может быть больше 255 шт., каждая запись не может быть длинее 255 байт.
   Средство работы — пара READ RECORD/UPDATE RECORD.
   Можно использовать как абсолютную (по номеру записи) так и относительную адресацию (следующая/предыдущая, но без цикличности).
   Пример использования — записная книжка на SIM-карте.

3. Cyclic

   В целом — то же, что и Linear Fixed, но со следующей дополнительной функциональностью:
   При чтении: замкнутость — при использовании относительной адресации, переходя с последней на следующую запись попадаем на первую, переходя с первой на предыдущую запись, попадаем на последнюю.
   При записи: допустима только относительная адресация с обращением только к предыдущей записи. Есть даже специальная команда, только для циклических файлов, которая обновляет самую старую запись файла (после этого она становится самой новой) — INCREASE.
   Первая запись всегда хранит самые новые данные, а последняя — самые старые.
   Пример использования — список ранее набранных номеров. Вообще, файлы данного типа используются гораздо реже, чем файлы других типов.

В API отсутствует возможность запросить список всех файлов/папок для MF или DF, соответственно, для того, чтобы проверить наличие файла по заданному пути, необходимо попытаться выбрать этот файл командой SELECT и проанализировать SW.
Виды обобщенных операций с файлами представлены в данной таблице:

Кратко поясню по последним двум командам:

1. INVALIDATE — обратимо изменяет состояние файла так, что:
   • для него выставляется специальный флаг, т.е. мы можем узнать о том, что файл инвалидирован.
   • в зависимости от настроек инвалидированного файла операции чтения и записи могут стать невозможны.

2. REHABILITATE — возвращает инвалидированный ранее файл в обычное состояние, при этом возможные ограничения, наложенные инвалидацией, снимаются.

Пример использования — механизм активации режима фиксированного набора (когда звонить можно только абонентам из специальной телефонной книги) построен на инвалидации файла основной телефонной книги SIM-карты. О других применениях данного механизма мне неизвестно.
Определившись с обобщенными типами операций над файлами, мы можем перейти к знакомству с принципами разграничения доступа.

Разграничение доступа

В основе этих принципов лежат понятия:

1. Access Condition (AC) — состояние карты, в пределах текущей сесии, при котором для определенного файла возможен определенный вид операции.
2. Условия доступа, самым известным из которых является предъявление PIN-кода.

Возможные условия доступа:

Оба кода PIN предъявляются карте командой VERIFY CODE. ADM предъявляется проприетарной командой (какая команда вздумается производителю, такую он и использует, поскольку стандартом это не регламентировано).
Предъявление кода — это операция масштаба сессии работы с картой, если вы предъявили PIN или ADM однажды, то можете выполнять операции со всеми файлами, которые требуют соответствующего кода, пока сессия не завершится.
Для каждого файла и каждой операции карта хранит маппинг: обобщенная операция — условие доступа.
Например, для файла EF ICCID, в котором хранится уникальный серийный номер карты (не путать с номером абонента мобильной связи), AC будут выглядеть так:

Для основной телефонной книги:

Если предъявление определенного кода отключено, как сейчас часто операторы делают с PIN1, то данный код считается предъявленным с начала сеcсии карты.

Для операции SELECT все AC равны Always. Чтобы узнать AC для конкретного файла, необходимо его выбрать (SELECT), а потом выполнить команду GET RESPONSE.

К папкам на SIM-картах (MF и DF) AC вообще неприменимы. Когда над файлом выполняется недопустимая, с точки зрения AC, операция (вроде попытки выполнить обновление EF ICCID), то в выполнении операции будет отказано, а код ошибки будет предоставлен в SW.

Конечно же, то, что я здесь описал, не является реальной файловой системой — как правило, за этой абстракцией, на уровне ОС, спрятана знакомая всем FAT.

В завершение я просто обязан привести пример использования данного API в реальной жизни.
Думаю, многие уже догадались (или знали?), что самым известным и массовым устройством, использующим этот API постоянно и интенсивно, является обыкновенный мобильный терминал.

PS:
В следующей статье планирую рассказать о том, как можно применить полученные сейчас знания, работая с картой программно.

PPS: Спасибо добрым людям за инвайт!

Автор: brake

Источник