Способ установки приложения на защищенный элемент - RU2673394C2

Чертежи

Описание

Настоящее изобретение, относится к способу установки приложения на защищенный элемент, способ реализуется защищенным элементом.

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

Защищенный элемент обычно отвечает стандартам ISO/IEC 7816 и/или нормам Общих критериев и/или нормам FIPS. Он предоставляет аппаратную и программную защищенность, которая определена, к примеру, в этих самых нормах. Он содержит память, выполненную с возможностью хранить данные и приложения. Он также содержит операционную систему, ответственную за выполнение набора инструкций, которые, к примеру, позволяют приложениям управлять этими данными. Защищенный элемент чаще всего еще располагает, по меньшей мере, интерфейсом связи. Когда он представлен картой с микросхемой, этот интерфейс связи может быть представлен контактной пластиной. Этот интерфейс связи также может быть антенной, позволяющей связываться с внешней средой, к примеру, с бесконтактным считывающим устройством, выполненным с возможностью сопрягаться с упомянутой антенной. Этот интерфейс позволяет микросхеме связываться с внешним устройством, с помощью команд, к примеру, типа APDU (Application Protocol Data Unit).

Такой защищенный элемент выполнен с возможностью обрабатывать безопасным образом данные, хранимые в его памяти и реализовывать функции, для которых он получил одно или несколько приложений. Таким образом, такой защищенный элемент используется как средство оплаты, средство идентификации, транспортный билет, электронная дисконтная карта, медицинская карта (Carte Vitale) или еще абонементная телефонная карта UICC, обычно называемая как SIM-карта.

Защищенный элемент может нести несколько приложений, использующих общие или даже обменивающиеся информацией между собой.

В качестве примеров приложений, можно привести приложение международных платежей (Visa, MasterCard), национальных платежей (Carte Bleue), снятия наличных в банкомате, приложение электронного кошелька, приложение управления дисконтных карт, приложение, позволяющее аутентифицировать лицо, застрахованное в системе национального страхования, и засвидетельствовать его права, или еще приложение управления тарифом на мобильный телефон.

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

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

Приложение устанавливается согласно функциональности, которую желает клиент или нет видеть в его приложении. Эти функции идентифицируются с помощью опций конфигураций, переданных на защищенный элемент. Поэтому они называются параметрами реализации и установки и порождают создание файловой структуры, модулей и генерацию их содержимого. Таким образом, приложение связано с файловой структурой, содержащей каталог («Directory file») который содержит в себе набор модулей, также называемых элементарными файлами («Elementary Files») согласно нормам ISO/IEC 7816.

В области установки приложений на защищенный элемент, в настоящее время существует два типа операционной среды.

Первый тип среды, основанный на использовании виртуальной машины, к примеру, виртуальной машины Java, проще использовать тем, что он занимается аппаратными возможностями, в частности распределением памяти. Достаточно подчинить ей опции конфигурации и операционная среда занимается, к примеру, предоставлением необходимого объема памяти. Тем не менее эта кажущаяся простота, из-за использования виртуальной машины, требует большого объема памяти и по этим же причинам ведет к пониженной эффективности, далекой от оптимальной. Кроме того, среда, основанная на использовании виртуальной машины, не дает возможности совместно использовать данные между двумя экземплярами приложений.

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

В операционной среде, обрабатывающей нативный код, пользователь должен вручную реализовывать файловую структуру, адаптированную для приложения, идентифицировать содержимое каждого модуля в зависимости от его опций конфигурации, и вручную определять необходимый объем для этих модулей в зависимости от элементов, которые они содержат. Этот способ, который соответствует, к примеру, норме Europay MasterCard Common Personalization, нуждается в передаче большого количества команд с соблюдением точного порядка при передаче указанных команд, под угрозой провала установки приложения. Большое количество операций обмена порождает большую длительность способа установки приложения. Кроме того, по соображениям безопасности, иногда невозможно удалить каталоги и модули, созданные на защищенном элементе. Тогда, в случае неудачи, защищенный элемент должен быть заменен.

Как только один из элементов ввода изменяется, является ли он опцией конфигурации приложения или кодом, хранимым в энергонезависимой памяти, например ПЗУ, микросхемы, которая изменяется (например, в случае изменения микросхемы), процесс должен быть частично или полностью повторен. Эта ситуация является утомительной, и кроме того, служит причиной ошибок из-за увеличения требуемых элементарных операций.

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

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

Изобретение относится к способу установки приложения на защищенный элемент, причем способ реализуется защищенным элементом и содержит этапы, на которых: принимают параметры реализации и установки приложения, анализируют параметры реализации и установки, вычисляют объем памяти, необходимый для установки приложения, идентифицируют доступный объем памяти, сравнивают необходимый объем памяти и доступный объем памяти, и если доступный объем памяти больше или равен необходимому объему памяти: создают файловую структуру, адаптированную для приложения и содержащую, по меньшей мере, один модуль, генерируют содержимое, по меньшей мере, одного модуля, адаптированного для приложения.

Согласно другой характеристике изобретения, этап вычисления определяет необходимый объем памяти, добавляя элементарный объем памяти для каждого модуля и дополнительный объем памяти для каталога, содержащего модули.

Согласно другой характеристике изобретения, элементарный объем памяти для модуля указывают параметром реализации и установки приложения.

Согласно другому признаку изобретения, модуль является совместно используемым, и элементарный объем для этого модуля затем уменьшают до объема средства адресации.

Согласно другому признаку изобретения, элементарный объем для модуля определяют анализом содержимого модуля.

Согласно другому признаку изобретения, элементарный объем для модуля определяют анализом, по меньшей мере, одного элемента, который он содержит.

Согласно другому признаку изобретения, первый модуль содержит, по меньшей мере, один элемент, совместно используемый со вторым модулем, и элементарный объем для этого элемента уменьшают таким образом до размера средства адресации.

Согласно другому признаку изобретения, этап анализа включает в себя анализ таблицы, идентифицирующей модули, совместно используемые приложениями и/или элементы, совместно используемые модулями.

Согласно другому признаку изобретения, этап анализа содержит автоматическое дополнение родового модуля, модуля, вызванного параметром реализации и установки и/или модуля, вызванного присутствием другого модуля.

Согласно другому признаку изобретения, способ выполняется защищенным элементом.

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

Согласно другой характеристике изобретения, операционная среда, выполняемая на защищенном элементе, обрабатывает нативный язык.

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

Другие характеристики, детали и преимущества настоящего изобретения станут более очевидными из подробного описания, приведенного ниже, в качестве примера, вместе с чертежами, на которых:

Фиг. 1 показывает систему разработки приложения для карты с микросхемой,

Фиг. 2 демонстрирует пример файловой структуры приложения,

Фиг. 3 демонстрирует блок-схему варианта осуществления способа, в соответствии с идеями изобретения.

Фиг. 1 показывает систему 10 разработки приложения 20 иллюстрированного на фиг. 2 для карты 11 с микросхемой. Карта 11 с микросхемой включает в себя контактную пластину 12. Станция или терминал 13 подключен к карте 11 и, главным образом, к ее микросхеме по линии 14. Информация, передаваемая линией 14, соответствует, к примеру, командам APDU. Станция или терминал 13 обеспечивает функции интерфейса человек-машина для карты 11 с микросхемой, которая его не имеет. Следует отметить, что в описанном здесь примере, станция или терминал 13 ограничен этими функциями интерфейса человек-машина и, что функции обработки реализуются микросхемой карты 11, как описано ниже.

Установщик управляет системой разработки через эту станцию или терминал 13, выбирая опции конфигурации, связанные с функциями или функционалом, что он желает видеть реализованным в карте 11 с микросхемой. Эти опции конфигурации могут влиять как на содержание приложения 20, так и на режим его установки. Выбор опций конфигурации приводит к передаче соответствующих параметров реализации и установки на карту 11 с микросхемой.

Способ 20, описанный на фиг. 3, установки приложения 20 на карту 11 с микросхемой в соответствии с изобретением, срабатывает при получении команды, предпочтительно единственной, инициированной установщиком через станцию 13.

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

Система, показанная на фиг. 1, может в действительности быть более сложной. Распространитель, например, банк, конфигурирует приложение 20, например, платежное приложение, через станцию или терминал 13, который обеспечивает функции интерфейса человек-машина. Распространитель конфигурирует приложение 20 для каждого из своих клиентов. Все эти конфигурации записаны в базе данных, которая передается установщику, расположенному на заводе настройки. Затем, для каждой карты 11 с микросхемой, установщик запускает способ 20, описанный на фиг. 3, установки приложения 20.

На фиг. 2 показан пример файловой структуры иллюстративного приложения 20, содержащего четыре модуля 22-25. Выбор пользователем приложения 20 и связанной с ним функции или функций вызывает создание на карте с микросхемой модуля или модулей 22-25 соответствующего этой функции. Модуль 22-25 содержит данные, то есть другими словами элементы разного объема, которые, как уже отмечено дальше, используются программой приложения, хранящейся в энергонезависимой памяти карты с микросхемой, например, ПЗУ.

Таким образом, например, намеренно упрощенное приложение оплаты, можно охарактеризовать двумя опциями конфигурации: использование ПИН-кода, и интерфейс, предусмотренный при оплате, в частности бесконтактный интерфейс. Это приложение включает в себя основной модуль оплаты, содержащий основные функции, модуль использования PIN-кода, и модуль, содержащий необходимые элементы для использования бесконтактного интерфейса. На уровне файловой структуры, приложение 20 содержит все модули 22-25, связанные с различными функциями, которые желают видеть в приложении 20.

Эти модули 22-25 генерируются на лету картой с микросхемой, и элементы, которые они содержат, могут зависеть от опций конфигурации, выбранных установщиком.

Объем модуля также зависит от опций конфигурации. Таким образом, при выборе способа асимметричного шифрования RSA, например, для шифрования PIN-кода, программа установки может выбрать длину ключа 256 битов или 2048 битов, в зависимости от желаемого уровня безопасности.

Во время установки, приложение 20 хранится в каталоге 21, который объединяет и включает в себя все модули 22-25.

Фиг. 3 показывает пример способа установки приложения 20 на карту 11 с микросхемой. На предварительном этапе, установщик начинает процесс, выбирая первую функциональность, связанную с модулем 21, и вторую функциональность, связанную с модулем 24.

Команда дополняется другими параметрами, более точно определяющими условия реализации и установки. Эти параметры позволяют, например, идентифицировать модуль или модули, совместно используемые с другими приложениями, как описано ниже.

Способ 30 в соответствии с изобретением, как показано на фиг. 3, начинает и выполняет следующие этапы. Первый этап E31 заключается в приеме картой с микросхемой, параметров реализации и установки, предоставленных установщиком. Конфигурация и установка приложения соответствует созданию файловой структуры и генерации содержимого файлов (или модулей) в энергонезависимой памяти карты 11 с микросхемой, как правило память ЭСППЗУ. Тем временем, код приложения может заранее хранится во второй энергонезависимой памяти, обычно память ПЗУ. Исходный код приложения компилируется и может быть записан в памяти ПЗУ микросхемы создателем микросхемы. Этот код определяет в частности основную родовую файловую структуру, связанную с приложением. Параметры конфигурации, которые не определены жестко в этом коде приложения, позволяют настроить, другими словами привязать, структуру данных, связанную с приложением в соответствии с пожеланиями пользователя.

Второй этап E32 заключается в анализе опций конфигурации.

После того, как параметры конфигурации проанализированы, можно перейти к третьему этапу E33 заключающемуся в вычислении объема, необходимого приложению 20. Метод вычисления детально описан ниже. Такой этап необходим в среде нативного языка, поскольку все распределение памяти обязательно должно быть выполнено статически, то есть путем объявления фактически выделенного объема, который затем более не может быть расширен. Ни одна виртуальная машина не резервирует пространство с этой целью. Действительно, виртуальная машина имеет средства для добавления, удаления и редактирования на лету объектов, хранимых в энергонезависимой памяти. Виртуальная машина организует эти объекты и их расположение в памяти, чтобы разгрузить приложение от этих функций. Эти механизмы не доступны с операционной средой, обрабатывающей нативный язык, и их реализация приведет к значительному использованию энергонезависимой памяти типа ПЗУ. В этом заключается причина неэкономного использования памяти, на которую изобретение отвечает удовлетворительно, вычисляя и выделяя объем памяти четко достаточный для приложения.

Использование нативного языка, таким образом, позволяет экономить пространство памяти, выделяя его по мере необходимости. Это использование позволяет оптимизировать использование энергонезависимой памяти, например, ЭСППЗУ, стоимость которой для карты с микросхемой может быть высокой. Кроме того, нативный язык позволяет конструировать приложения, которые работают быстрее, в основном из-за отсутствия слоя виртуальной машины, которая обязательно требует временных и пространственных ресурсов. Также использование нативного языка выгодно тем, что позволяет, с теми же функциями, создать приложение 20, которое работает быстрее и использует меньше места в памяти. Это позволяет оптимизировать ресурсы необходимые микросхеме 11, или даже снизить ее стоимость. Таким образом, можно получить устройство, способное выполнять функцию, состоящее из карты 11 с микросхемой, более производительное, и менее дорогое.

Затем надлежит, перед переходом к фактической установке приложения 20, проверить что объем доступный на карте 11, в частности в энергонезависимой памяти микросхемы, достаточен, и, следовательно, больше или равен необходимому объему.

В этом случае необходимо, до перехода к фактической установке приложения 20, проверить, что доступный объем на плате 11, более предпочтительно в энергонезависимой памяти микросхемы, достаточен и, следовательно, больше или равен необходимому объему.

Для этого, на четвертом этапа E34, переходят к идентификации доступного объема памяти. Этот доступный объем памяти, как правило, управляется индикатором, присутствующим в памяти микросхемы, и обновляемым при каждой загрузке, при каждой новой установке, или напротив, если позволяют параметры безопасности, при каждом осуществлении освобождения места в памяти карты 11. На этом этапе E34, способ 30 использует эту функциональную возможность, чтобы получить доступный объем.

На пятом этапе E35, доступный объем, полученный на этапе E34, сравнивается с необходимым объемом, вычисленным на этапе E33.

Если доступный объем меньше необходимого объема, установка невозможна и способ 20 может остановиться. Преимущественно, в этом случае, индикатор ошибки может быть доведен до сведения установщика, который тогда способен откорректировать свои опции конфигурации.

Если доступный объем больше или равен необходимому объему, установка возможна и способ 30 может перейти к следующим этапам.

На шестом этапе E36, можно приступать к созданию файловой структуры состоящей из каталога, содержащего модули в энергонезависимой памяти микросхемы, обычно память ЭСППЗУ.

На седьмом этапе Е37, можно приступать к генерации, на лету, элементов, записанных в этих модулях, адаптированных к приложению 20.

Преимущественно, такой способ 30 позволяет перегруппировать и реализовать прозрачно для установщика, предпочтительно в одной команде, все операции, связанные с реализацией и установкой приложения 20. После того, как установщик указал, с помощью параметров конфигурации, функциональные возможности приложения 20, все операции происходят автоматически и управляют соответствующими материальными возможностями, как это описано ниже.

Способ 30 может быть выполнен для персонализации карты 11 с микросхемой. В этом случае, опционально, способ 30 реализует этап E38 (не показан), на котором установщик передает карте 11 с микросхемой информацию персонализации (например, имя владельца или PIN) с помощью команд "Store Data", которые соответствуют, например, нормам Europay Mastercard Visa Common Personalization. На этапе Е39 (не показан), эта информация записывается в файловой структуре, записанной в энергонезависимой памяти ЭСППЗУ микросхемы.

Способ 30 установки приложения 20 на защищенном элементе реализуется защищенным элементом.

Важным этапом является этап E33 вычисления памяти необходимой приложению 20. Как показано на фигуре 2, приложение содержит последовательность модулей 22-25, расположенных в каталоге 21. Объем памяти, необходимый приложению 20 получают, добавляя элементарный объем каждого модуля 22-25 и дополнительный объем для каталога 21, содержащего их. Элементарный объем каждого модуля 22-25 может зависеть от объема элементов, содержащихся в этих модулях 22-25, и его определение подробно описано ранее. Дополнительный объем, данный каталогу 21, может, в зависимости от среды, быть постоянным или зависеть от количества модулей или содержания модулей 22-25. Определение элементарного объема модуля 22-25 зависит от типа модуля 22-25 и от содержимого самого модуля. Модуль 22-25 может быть, по меньшей мере, трех типов: он может быть родовым, автоматическим или совместно используемым.

В соответствии с первым типом, модуль, такой как модуль 22, является родовым. Этот тип соответствует модулю, связанному с функциональностью явно выбранной установщиком в начале способа 20. Здесь возможно много вариантов реализации определения элементарного объема этого модуля 22. В соответствии с первым вариантом осуществления, элементарный объем определяют анализом содержимого модуля 22. Этот анализ выполняется самой картой с микросхемой. В другом варианте осуществления элементарный объем необходимый для установки модуля 22 указан установщиком, например, с помощью параметра.

В соответствии со вторым типом, модуль, такой как модуль 24 является совместно используемым. Такой совместно используемый модуль 24 совместно используется с другим приложением, представленным на той же карте 11 с микросхемой. Такая конфигурация может быть реализована только как часть операционной среды, основанной на использовании нативного языка.

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

Таким образом, модуль 24, ранее связанный с первым приложением карты с микросхемой, может быть полностью совместно используемым со вторым приложением. Это называется полное совместное использование, так как все данные файла совместно используются. Это второе приложение, вместо того, чтобы записать модуль 24 еще раз, повторно использует тот, идентичный уже установленный первым приложением. Для этого такой модуль 24 объявляется совместно используемым вторым приложением. Совместно используемый модуль указывается как совместно используемый установщиком, например, с помощью опции конфигурации.

Для этого необходимо, однако, чтобы второе существующее приложение включало в себя средство 241 адресации, позволяющее ему отмечать указанный модуль 24. Такой подход имеет преимущество в том, что он позволяет экономить память карты 11 с микросхемой, память является дефицитным ресурсом на носителе такого небольшого размера. Такой подход позволяет определить объект, который является совместно используемым для нескольких приложений. Этот объект может быть счетчиком транзакций, совместно используемым между двумя платежными приложениями, например, "MasterCard", которая предлагает средство международного платежа и "Carte Bleue", которая предлагает средство национального платежа.

В результате этого подхода элементарный объем, принимаемый во внимание на этапе E33 вычисления необходимого объема, снижается. Элементарный объем такого совместно используемого модуля 24 существенно снижается до размера, указанного средства 241 адресации.

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

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

Третий тип модуля, или автоматический тип, описан ниже. Он может быть совместно используемым или нет. Что касается определения элементарного объема такого модуля 23, если он является совместно используемым, его элементарный объем определяется, как и у совместно используемого модуля, и если он не является совместно используемым, применяются те же соображения, что и для родового модуля 22.

Согласно другой характеристике изобретения способ может дополнительно помочь установщику в решении этой задачи, автоматически добавляя некоторые модули, уменьшая эту задачу предоставлением или указанием способу 20 только конкретных модулей. Модули 23, называемые автоматическими, затем добавляются способом 20, на этапе E32 анализа параметров реализации и установки, без прямого предоставления или указания установщика.

Такой автоматический модуль 23 может содержать родовой модуль. Родовой модуль содержит ресурс, используемый всем приложением. Поскольку такой модуль имеет важное значение для всего приложения, нет необходимости его указывать способу 20. Способ 20 может его включать систематически, указал ли его установщик или нет.

Автоматический модуль 23 может дополнительно содержать один или более вызванных модулей 25. Модуль может быть вызван опцией конфигурации. Таким образом, если параметр указывает, например, что аутентификация должна выполняться приложением 20, модуль или модули необходимые для реализации функции аутентификации являются необходимыми, и способ 20 включает их на этапе E32 анализа, даже если установщик не указывает их явно в его опциях конфигурации.

Модуль также может быть вызван наличием, в явно указанных установщиком модулях, конкретного модуля. Таким образом, если модуль является частью, например, триплета всегда связанных модулей, наличие одного из этих модулей, указывает, что два других должны быть включены. Также способ 30 может их включать на этапе E32 анализа, даже если они прямо не соответствуют опции конфигурации выбранной установщиком.

Таким образом, установщик может определять только специфические особенности его приложения 20, по минимальному списку. Прозрачным для него образом, модули, родовые или вызванные, затем автоматически устанавливаются самим способом 30. Кроме того, способ 30 может дополнить, в последовательности, недостающие модули.

Все это облегчает задачу установщика, при одновременном снижении риска ошибки.

Реализация некоторых шагов, таких как вычисление E33 объема необходимой памяти, создание E36 файловой структуры или адресация совместно используемого модуля 24 зависит от кода приложения предварительно сохраненного в памяти ПЗУ.

В соответствии с предыдущим уровнем техники, основной недостаток заключается в том, что все этапы, зависящие от кода предварительно сохраненного в памяти ПЗУ, могут потребовать адаптации, когда код, предварительно сохраненный в памяти ПЗУ, модифицируется (к примеру, в случае изменения микросхемы).

Согласно предпочтительной характеристике настоящего изобретения, способ 30 способен управлять установкой E36 приложения 20, в соответствии с кодом, ранее сохраненным в ПЗУ, прозрачным для установщика образом.

Это позволяет преимущественно, сделать полностью прозрачной операцию изменения кода, ранее сохраненного в ПЗУ (например, в случае изменения микросхемы). Такое изменение требует только повторения способа 30, с выбором опций конфигурации полностью идентичным для установщика, способ 30 берет на себя реализацию всех модификаций, вызванных изменением типа микросхемы 11, автоматически.

В частности, при использовании новых рамок родовой файловой структуры, которая может быть заранее записана в памяти ПЗУ микросхемы, реализация этапов Е33, E36 и E37 может изменяться, но данное изобретение обеспечивает преимущество адаптироваться и возвращать это прозрачное для установщика изменение. Таким образом, если размер объекта изменяется новой рамкой родовой файловой структуры, значение необходимого объема памяти отличается, но это изменение не влияет на установщика.

Следует отметить, что способ согласно описанным вариантам осуществления производит устройство. Карта 11 с микросхемой, как только оснащена приложением, становится устройством способным реализовать функцию. Таким образом, карта 11 с микросхемой, получив необходимые элементы настройки с использованием способа, который обеспечивает приложение 20, становится инструментом пригодным для использования владельцем.

Например, на основе пустой карты 11 и платежного приложения, изготовленного и установленного с использованием способа в соответствии с изобретением, производится платежная карта, позволяющая ее пользователю осуществлять платежи или снимать наличные в банкомате. Способ 30, таким образом, превращает карту 11 в средство платежа.

Реферат

Изобретение относится к области установки приложений. Техническим результатом является установка приложения на защищенный элемент, причем установка реализуется защищенным элементом. Раскрыт способ установки приложения на защищенный элемент, причем указанный способ реализуется защищенным элементом, на котором выполняется операционная среда, обрабатывающая нативный язык, отличающийся тем, что он содержит этапы, на которых: принимают параметры реализации и установки, идентифицирующие функцию или функции, имеющиеся в приложении, анализируют параметры реализации и установки, вычисляют объем памяти, необходимый для установки приложения, идентифицируют доступный объем памяти, сравнивают необходимый объем памяти и доступный объем памяти, если доступный объем памяти больше или равен необходимому объему памяти: создают, в первой энергонезависимой памяти защищенного элемента, файловую структуру для приложения и содержащую, по меньшей мере, один модуль, соответствующий функции или функциям, идентифицированной(ым) параметрами реализации и установки, генерируют содержимое по меньшей мере одного модуля, соответствующего функции или функциям, имеющимся в приложении, на основании нативного кода, предварительно сохраненного во второй энергонезависимой памяти защищенного элемента, при этом этап вычисления определяет необходимый объем памяти, добавляя элементарный объем памяти для каждого модуля и дополнительный объем памяти для каталога, содержащего модули. 3 н. и 7 з.п. ф-лы, 3 ил.

Формула