Изменить версию апплета javacard

Question

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

С уважением

Answer 1

Нашел ответ по поиску в интернете: проверьте эту ссылку

В ссылке сафармер сказал:

К сожалению, вы можете только удалить и установить снова. Насколько я понимаю, это связано с ограниченными ресурсами на карте. Вам потребуется иметь две копии апплета на карте, чтобы выполнить атомарное обновление, а затем удалить оригинал. Я не думаю, что это очень выполнимый подход.

Ключом к этому является выполнение в контролируемой среде, чтобы вы имели полный контроль и могли повторно выполнить работу в случае разрыва карты и т. Д., Например, не обновлять в Интернете через Интернет.

Также:

Вы определяете апплет, в котором хранятся данные, и SIO, который вы можете использовать для доступа к этому апплету. Бизнес-логика переходит в другой апплет и вызывает методы интерфейса для получения или установки данных в другом апплете. Ваша бизнес-логика может быть удалена и переустановлена ​​без ущерба для данных. Это упрощенная версия с одним абзацем.

Answer 2

Это результат моих поисков по поводу SIO:

Совместно используемые интерфейсы - это функция API Java Card, позволяющая взаимодействовать с апплетами. Для контекста-владельца SIO - это обычный объект, доступ к полям и методам которого можно получить. Для любого другого контекста SIO является экземпляром разделяемого интерфейса, и доступны только методы, определенные в разделяемом интерфейсе. Все остальные поля и методы SIO защищены межсетевым экраном. Совместно используемые интерфейсы обеспечивают безопасный механизм для взаимодействия между апплетами, а именно:

Серверный апплет A создает общий интерфейсный объект

1. Чтобы сделать объект доступным для совместного использования с другим апплетом в другом контексте, апплет A сначала определяет общий интерфейс, SI. Совместно используемый интерфейс расширяет интерфейс javacard.framework.Shareable. Методы, определенные в совместно используемом интерфейсе SI, представляют сервисы, которые апплет A делает доступными для других апплетов.

2. Затем апплет A определяет класс C, который реализует разделяемый интерфейс SI. C реализует методы, определенные в SI. C может также определять другие методы и поля, но они защищены межсетевым экраном апплета. Только методы, определенные в SI, доступны для других апплетов.

3. Апплет A создает экземпляр объекта O класса C. O принадлежит апплету A, а межсетевой экран позволяет A получать доступ к любым полям и методам O.

Клиентский апплет B получает разделяемый интерфейсный объект

1. Апплет B может запрашивать сервис у апплета A, вызывая один из разделяемых методов интерфейса SIO. Во время вызова виртуальная машина Java Card выполняет переключение контекста. Исходный в настоящее время активный контекст (B) сохраняется в стеке, и контекст владельца (A) фактического объекта (O) становится новым в настоящее время активным контекстом. Реализация метода совместного использования интерфейса (метод SI) А выполняется в контексте А.

2. Метод SI может узнать AID своего клиента (B) через метод JCSystem.getPreviousContextAID. Метод определяет, будет ли он выполнять службу для апплета B.

3. Из-за переключения контекста брандмауэр позволяет методу SI получать доступ ко всем полям и методам объекта O и любого другого объекта в контексте A. В то же время брандмауэр предотвращает доступ метода к объектам общего доступа в контекст Б.

4. Метод SI может получить доступ к параметрам, переданным B, и может обеспечить возвращаемое значение для B.

5. Во время возврата VM Card Java выполняет переключение контекста восстановления. Исходный в настоящее время активный контекст (B) извлекается из стека и снова становится текущим активным контекстом.

6. Из-за переключения контекста брандмауэр снова позволяет B получить доступ к любому из его объектов и предотвращает доступ B к объектам без общего доступа в контексте A.