Изменить версию javacard applet

Question

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

С уважением

Answer 1

Найденный ответ прибегая к помощи Интернет: проверить this link

В ссылке, safarmer сказал:

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

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

также:

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

Answer 2

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

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

Сервера апплет строит совместно используемого интерфейсного объект

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

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

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

Client апплет B Получает Объект Разделяется Интерфейс

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

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

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

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

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

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