Обработка неисправных APDU ISO7816

Есть ли в Java Card API, спецификациях RE или VM какие-либо спецификации относительно того, как карта должна реагировать на неисправные APDU ISO7816-4 (при условии, что такие искаженные APDU вообще передаются на карту)?

Существуют ли другие требования для обработки APDU апплетов?

Если бы я должен был отправить, например. (ошибочный) первый межотраслевой APDU длиной 3 байта на карту/апплет - кто должен обнаружить/сообщить об этой ошибке?

Кто обнаружит/сообщит о первом межотраслевом APDU, содержащем неверное поле длины LC?


person Thomas Lieven    schedule 01.10.2013    source источник


Ответы (1)


Нет, не существует универсальной спецификации, определяющей, как обрабатывать неправильно сформированные APDU.

Как правило, вы всегда должны возвращать слово состояния, которое находится в допустимом диапазоне ISO 7816-3/4. Какой из них полностью зависит от контекста. Как правило, вы должны стараться всегда выдавать ISOException со словом логического состояния при возникновении ошибки. Вы должны стараться никогда не возвращать слово состояния 6F00, которое возвращается, если метод Applet.process() завершается с исключением, отличным от ISOException. Наиболее распространенные (не все) слова состояния ISO были определены в интерфейсе ISO7816.

К сожалению, ISO 7816-4 дает лишь некоторые подсказки относительно того, какие слова состояния можно ожидать. С другой стороны, если ошибка не является очень специфичной (например, неверный PIN-код), терминал мало что может сделать, если он получает слово состояния в синтаксически неправильном APDU (вряд ли это можно исправить). неправильное поле данных команды APDU). Любые конкретные слова состояния должны определяться протоколами более высокого уровня. Сам ISO 7816-4 можно использовать только как (гнилую) основу для других протоколов. Не определены четкие правила обработки синтаксических (неправильная длина) или семантических (неправильный PIN-код) ошибок.

Что касается неправильно сформированных APDU: 3-байтовые APDU не будут получены апплетом. Могут быть получены байты с неправильным байтом Lc. Однако было бы более логично, если бы это повлияло на транспортный уровень таким образом, что транспортный уровень либо истечет время ожидания, потому что ожидает больше данных, либо ложные байты будут отброшены. Не помешает проверить и вернуть неверную ошибку длины, но, если вы решите продолжить, используйте значения APDU.getIncomingLength() или APDU.setIncomingAndReceive() в качестве окончательных значений для Ne.

person Maarten Bodewes    schedule 01.10.2013
comment
Боюсь, мой вопрос был не таким точным. - person Thomas Lieven; 04.10.2013
comment
Вообще меня интересует, кто (терминал, карта, апплет) должен иметь дело с какими ошибочными APDU. Вы уже говорили, что 3-х байтный APDU не дойдёт до апплета, а до карты дойдёт или уже будет пойман терминалом? Есть ли какие-то спецификации, которые определяют именно это распределение обязанностей? - person Thomas Lieven; 04.10.2013
comment
@ThomasLieven, это зависит от реализации и обработки ошибок протокола транспортного уровня как терминалом, так и, возможно, картой. На практике, я думаю, вы не можете сказать много об этом. Однако 3-байтовые команды не должны обрабатываться апплетами Java Card - это указано в спецификациях Java Card, и они особенно строги. - person Maarten Bodewes; 06.10.2013