Симптомы повреждения EEPROM

Предположим, что в апплете Java Card есть ошибка: временный массив байтов хранится в EEPROM, а не в RAM. Кроме того, предположим, что этот массив байтов перезаписывается с каждым APDU.

Этот баг рано или поздно должен повредить карту.

Какие симптомы мы можем ожидать? Неверные значения в массиве без каких-либо явных предупреждений или ошибок? Некоторые исключения, возникающие при доступе к этому массиву? Апплет нельзя выбрать? Вся карта полностью не отвечает?

Должна ли карта быть повреждена «раз и навсегда», или эти сбои будут происходить все чаще и чаще?

В моем эксперименте (J2E145) был первый сбой после 5 000 000 APDU и симптомом было то, что карта вообще не отправляла R-APDU и просто умерла. Однако следующий APDU снова был в порядке, затем примерно 1 APDU из 10000 вышел из строя (с увеличением частоты) и, наконец, после 5 100 000 APDU карта перестала обмениваться данными навсегда.

Есть ли какой-либо стандарт, который говорит, что должно произойти в случае повреждения EEPROM? (Искала, но не нашла.)

Я знаю, что вопрос широкий и, вероятно, зависит от конкретного чипа (особенно меня интересуют чипы NXP), но я думаю, что ваши комментарии, ответы и опыт могут помочь многим разработчикам Java Card, которые обнаружили ошибку в своем коде после развертывания.


smartcard eeprom corruption javacard
person vojta    schedule 04.06.2015    source источник

Ответы (2)


arrow_upward
3
arrow_downward

Я полагаю, что лучший способ найти информацию, не относящуюся к NDA, — это цели безопасности Common Criteria для конкретных платформ.

Пример для аппаратной платформы от NXP: Контроллеры безопасных смарт-карт NXP P5Cx128V0A/P5Cx145V0A, MSO (BSI-DSZ-CC-0645)

  • #P3# <блочная цитата> #P4#
  • #P5# <блочная цитата> #P6#
  • #P7# <блочная цитата> #P8#

Таким образом, эта аппаратная платформа способна обнаруживать сбои ячеек EEPROM и даже автоматически исправлять 1-битные ошибки в каждом байте. Для всех других обнаруженных ошибок будет вызвано исключение, которое может быть обработано программным обеспечением.

Это для аппаратной платформы (без ОС/JCRE). Итак, давайте посмотрим, что нам говорит цель безопасности JCOP. Я выбрал NXP J3A128 и J3A095 Secure Контроллер смарт-карт, версия 3 (BSI-DSZ-CC-0731).

  • Из функции безопасности SF.Audit:

    Возможны следующие реакции со стороны ОО на основании указания на потенциальное нарушение ПТП:

    • Throw an exception
    • Завершить действие карты (состояние жизненного цикла: TERMINATED)
    • Повторная инициализация системы Java Card (горячий сброс)
    • [...] EEPROM может исправить 1-битную ошибку в каждом байте. [...] EEPROM автоматически исправляет ошибки без участия пользователя [...]
    • Блокировка сеанса карты (просто останавливает обработку; выход с сбросом сеанса/разрывом карты)

    Основываясь на этих типах ответа/реакции, перечисленные выше события будут иметь следующее сопоставление:

    • Сбой EEPROM проверяется с помощью исключений в операциях чтения/записи и проверки согласованности/целостности: Блокировка сеанса карты
    • механизм самопроверки при запуске: Блокировка сеанса карты
    • Повреждение объектов контрольной суммы: Блокировка сеанса карты
  • #P14# <блочная цитата> #P15# #P16#

Итак, эта программная платформа (снова) способна обнаруживать сбои ячеек EEPROM и даже автоматически исправлять 1-битные ошибки в каждом байте. Для всех других обнаруженных ошибок EEPROM он "блокирует сеанс карты", что означает, что он просто прекращает обработку и выполняет сброс. Похоже, это соответствует вашему наблюдению "симптом заключался в том, что карта вообще не отправляла R-APDU и просто умерла".

person Michael Roland    schedule 05.06.2015
comment
Большое спасибо за исследование, отличная работа! ФБО запускают набор самопроверок во время первоначального запуска (при каждом включении питания)... Если обнаруживается ошибка, ОО переходит в безопасное состояние (сеанс блокировки карты) – это значит вся карта сломана и все ее апплеты и их данные утеряны, да? - person vojta; 05.06.2015
comment
Пожалуйста. Просмотр этих документов в поисках публично цитируемой ссылки был в моем списке задач в течение довольно долгого времени, и ваш вопрос дал повод, наконец, снова заняться этим. - person Michael Roland; 05.06.2015
comment
К сожалению, цели безопасности не дали четкого ответа о точных условиях проверки при включении, поэтому я ничего не могу сказать, не нарушая NDA. Если у вас есть доступ к JCOP UGM, вы можете найти что-нибудь по этому поводу (хотя и в очень обобщенном виде). - person Michael Roland; 05.06.2015
comment
Тем не менее, если эти тесты при включении не пройдут, сброс, вызванный сеансом блокировки карты, в конечном итоге заблокирует карту в цикле загрузки (или в какой-то более эффективной блокировке). - person Michael Roland; 05.06.2015

arrow_upward
3
arrow_downward

Вот картинка из родной операционной системы: При записи нового значения в энергонезависимую память аппаратная подпрограмма сама проверяет, правильно ли было записано значение, и в противном случае возвращает статус ошибки. Это преобразуется в SW1/SW2 из 65 81. Поврежденный файл или объект помечаются как поврежденные, и будущие попытки доступа к нему полностью отвергаются. Если это необходимо для приложения, это больше не сможет работать.

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

person guidot    schedule 04.06.2015