Удалить команду APDU с помощью SSD в поле данных, возвращает 6985

#javacard #globalplatform

#javacard #globalplatform

Вопрос:

У меня есть Javacard, который содержит SSD (дополнительный домен безопасности), и я хочу его удалить. Обычно, когда я хочу удалить апплет или пакет со своей карты, я отправляю следующую команду УДАЛЕНИЯ APDU после успешного процесса взаимной аутентификации (шифрование MAC или поля данных не требуется, и Security Level == 0 этого достаточно для команды УДАЛЕНИЯ APDU):

 --> 80 E4 00 00 LC 4F <AID Len> <AID>
<-- 90 00
  

Приведенная выше команда отлично работает для обычных апплетов. Но когда я добавляю в нее поддержку своего SSD, карта отвечает словами состояния 69 85, что означает «Условия использования не выполнены»..

Поскольку на моей карте включена функция делегированного управления, а в ISD загружены открытый ключ токена и ключ квитанции, я подумал, что, возможно, упомянутая ошибка связана с тем, что не используется токен удаления в команде УДАЛЕНИЯ APDU. Итак, я вычислил токен удаления, как показано ниже:

Глобальная спецификация карты платформы 2.2.0.7: Рисунок C-8: удаление вычисления токена введите описание изображения здесь

 DeleteToken = RSA_Sign("00 00 LC 4F <SSD AID Len> <SSD AID>", TokenPrivateKey)
  

А затем я попытался удалить SSD с помощью следующей команды:

 --> 80 E4 00 00 <LC Len(DeleteToken)> 4F <SSD AID Len> <SSD AID> 9E <Len(DeleteToken> <DeleteToken>
<-- 69 85
  

Но я снова получил слова состояния 6985. Кто-нибудь имеет представление о том, в чем проблема и как я могу ее решить?

Обновить:

Я даже попробовал команду УДАЛЕНИЯ APDU с P2 = 0x80 помощью, чтобы удалить SSD со всеми связанными объектами. Но это тоже не удалось:

 -->  80 E4 00 80 09 4F <SSD AID Len> <SSD AID>
<--  6A 86 (= Incorrect P1 or P2 parameter)
  

Update2:

Я даже пытался отправить команду УДАЛЕНИЯ APDU по защищенному каналу (SecLevel = 03). Но опять же, я получил 6985 слов состояния. Какой алгоритм хеширования мне нужно использовать для генерации токена удаления? Насколько я знаю, в спецификации GP не указан алгоритм хэширования.

Update3:

Указанный SSD создается из пакета ISD карты с 0E привилегиями, что означает:

Домен безопасности делегированное управление проверка DAP

Update4:

Я думаю, что нашел проблему!

Запрошено из 2.1.1_Mapping_guidelines_v1.0.1-Final.pdf:

6.1. УДАЛИТЬ

6.1.2. Рекомендация

Поле данных, отправленное в командном сообщении

(бла-бла)

В реализации, поддерживающей дополнительные домены безопасности, если предпринимается попытка удалить экземпляр дополнительного домена безопасности, а Дополнительный домен безопасности имеет привилегию проверки DAP (бит 7 набора байтов привилегий), домен безопасности не удаляется и возвращается ответ ‘6985’.

Вопрос1: Есть идеи, почему это реализовано / рекомендуется именно так? Какова цель сделать этот тип SSD (SSD с привилегией проверки DAP) несъемным?

Update5:

Я попытался изменить привилегии моего SSD, чтобы удалить с него привилегию проверки DAP, используя INSTALL Для ОБНОВЛЕНИЯ РЕЕСТРА, а затем удалить SSD. Но это не удалось со 6A 80 словами состояния (что означает «Параметры в поле данных неверны»).

 -->  00 A4 04 00 08 A0 00 00 00 03 00 00 00
<--  6F 10 84 08 A0 00 00 00 03 00 00 00 A5 04 9F 65 01 FF 90 00

-->  80 50 00 00 08 DF 4B 4B B7 15 35 5A 93
<--  00 00 41 89 00 24 94 97 41 21 01 02 00 77 5C 2B 50 27 5A F4 8A 18 C0 8B 2D C2 20 50 90 00

-->  84 82 00 00 10 30 AD 04 C4 60 A2 80 8B 5A 61 7E 49 3A 39 B6 C6
<--  90 00

-->  80 E6 40 00 16 08 A0 00 00 00 03 00 00 00 00 07 <SSD AID> 01 80 00 00
<--  6A 80
  

Вопрос2: Что не так с командой INSTALL For Registry Update?

Комментарии:

1. > Вопрос1: В той же спецификации несколькими строками выше указано: «В реализации, поддерживающей дополнительные домены безопасности, команда DELETE может удалить экземпляр дополнительного домена безопасности, который имеет привилегию проверки DAP, однако домен безопасности с установленной привилегией DAP не может быть удален». Этот раздел каким-то образом непоследователен. Для обязательного DAP это имеет смысл, в противном случае, удалив SSD, можно было бы обойти обязательные проверки DAP для управления апплетами. Для SSD только с DAP, нет. Возможно, разработчики просто следовали спецификации здесь.

Ответ №1:

Делегированный токен управления при использовании RSA должен использовать SHA-1 в качестве механизма хеширования со схемой PKCS # 1. У меня есть некоторый непроверенный код подписи и для сборки данных токена. Возможно, это полезно для начала.

Что касается Вопроса2:

Я этого раньше не делал, но вы передаете поддержку SSD и в качестве поддержки приложения снова. Помощь приложению требуется только в том случае, если вы хотите изменить привилегии приложения, например, привилегии, выбранные по умолчанию.

Вместо:

 80 E6 40 00 16 08 A0 00 00 00 03 00 00 00 00 07 <SSD AID> 01 80 00 00
  

Я бы попробовал это:

 80 E6 40 00 16 <Length SSD AID> <SSD AID> 00 01 80 00 00
  

Комментарии:

1. Я пробовал их, но все они потерпели неудачу. К вопросу добавлен журнал решений P2 = 0x80. Спасибо.

2. Может быть, SSD просто нельзя удалить? Например, в eUICCs есть ECASD, и его удаление приведет к потере большей части функциональности карты.

3. Ну, я уверен, что это можно удалить, потому что я сам создал и установил этот SSD.