Натыкался на информацию, что на карточке может храниться фотография. Захотелось попробовать её найти. Найти не удалось (да и не факт, что продолжу ковыряться). Но, возможно, что некоторые мысли кому-то пригодятся.

И вот что удалось узнать (тем или иным способом, инфа явно не полная)...

На чипе есть что-то вроде иерархии папок/файлов (слеши просто для наглядности):
/foms_root/FOMS_ID:
\x02\x01 - основные данные
\x02\x02 - сертификат какой-то?

/foms_root/FOMS_INS
\x80\x01 - сертификат какой-то?

Возможно, что есть что-то ещё, но они не подвернулись.
Имена файлов двухбайтовые, из непечатаемых символов.

Обмен данными с чипом идёт через APDU-команды. Спецификации на команды APDU можно прочесть в ГОСТ Р ИСО/МЭК 7816-4-2013, либо в оригинальном стандарте ISO/IEC 7816-4 (не удалось найти). Очень сильно заинтересовала и помогла статья https://blog.regolit.com/2017/03/10/programming-and-smart-cards а так же чтение стандарта. В стандарте описывается структура приведённых в этом обсуждении APDU.

Логика работы с файлами не совсем понятна, но почитать их удалось. Для чтения файла требуется перейти в соответствующую папку при помощи команды SELECT, например:
1) переход в папку "foms_root": 00 A4 04 0C 09 66 6F 6D 73 5F 72 6F 6F 74 <-> SW = 0x9000
2) переход в папку "FOMS_ID" из "foms_root": 00 A4 04 0C 07 46 4F 4D 53 5F 49 44 <-> SW = 0x9000

Далее при помощи команды SELECT выбрать файл, например, тот же \x02\x01:
00 A4 02 0C 02 02 01 <-> SW = 0x9000

И выполнить чтение его, при помощи команды READ BINARY:
00 B0 00 00 00 <-> вернёт данные (до 256 (255?) байтов; содержимое меньше 256 (255?) байтов) и SW = 0x9000

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

Файл \x02\x02 содержит какой-то длинный сертификат. Чтение приходится выполнять за несколько раз, вычитывая командами вида:
00 B0 HH LL 80 <-> вернёт данные и SW = 0x9000
HH и LL - старший и младший байт смещения считываемых данных от начала файла, 80 - максимальный размер передаваемых в ответе данных (не считая SW), 80 взято просто для наглядности; команда считывания с разными смещениями посылаются до тех пор, пока не станет возвращать SW отличное от 0x9000. Скорее всего, чтение в таком виде неправильное и должно быть реализовано как-то иначе.

Таким же образом читается файл \x80\x10 из FOMS_INS. Помимо всего прочего к FOMS_INS можно применить команду GET DATA: 00 CA 01 B0 00, которая, собственно и возвращает всего два байта: 80 10 (имя файла ведь!?) и тот же SW = 0x9000. Число 01 B0 - "волшебный" проприетарный номер.

Касательно содержимого файла \x02\x01: судя по виду, в нём содержится TLV-дерево, состоящее из полей вида: XX YY LL [ DATA ], где XX YY, предположительно, теги/типы данных (те самые 0x6281, 0x7F30, 0x5FXX), LL - длина данных после этого трёхбайтного заголовка, ну и соответственно данные DATA. При этом теги 0x6281 и 0x7F30, судя по всему, являются вершинами дерева / контейнерами. Возможно, что номера тегов взяты не с потолка, а несут какую-то смысловую нагрузку из какого-либо стандарта (BER?). Текстовые данные хранятся в кодировке UTF-8. Помимо текста есть и "бинарщина", а именно BCD. В принципе структура и типы хранимых данных более-менее понятны даже по их виду.

P.S. писалось из под Linux на Си через PSCS-Lite (+ CCID); жалоб нет.