Google+
Журнал Плас Плас Журнал http://www.plusworld.ru/
ул. Кржижановского, д. 29, корп. 5 Москва, 117218 Россия
+7 495 961 1065 http://www.plusworld.ru/upload/templates/logo_plus_ru.png
RSS RSS RSS RSS

Visa Open Platform

(Нет голосов)

21.07.1999 Количество просмотров 656 просмотров

В апреле 1999 г. на сервере международной платежной ассоциации VisaInternational было опубликовано бизнес-описание спецификаций VisaOpenPlatform. Предлагаемый читателю материал представляет собой краткое изложение этого документа.

В настоящее время, несмотря на обилие всевозможных карточных стандартов, разработка, развитие и внедрение технологических схем на базе микропроцессорных карточек продолжает встречать на своем пути всевозможные препятствия, основным из которых является отсутствие глобальной поддержки какого-либо одного стандарта большинством участников рынка. Каждая компания, занимающаяся производством терминального оборудования или разработкой карточных операционных систем, продолжает ориентироваться на собственные ноу-хау в архитектуре и функциональности. В результате разработчики ППО для карточек и терминалов должны обладать очень хорошим знанием специфики конкретных операционных систем и конкретных средств разработки и тестирования программных продуктов (toolkits). Таким образом, хорошо известные и понятные большинству участников рынка проблемы - длительный срок «вывода» нового продукта на рынок, отсутствие портируемости ППО, невозможность динамического обновления приложений в течение всего жизненного цикла карточки - продолжают оставаться актуальными.

Для преодоления подобных проблем и была создана Открытая Платформа Visa (далее - VOP), определяемая как «операционная среда для разработки и внедрения программ мультиаппликационных микропроцессорных карточек». По замыслу разработчиков,  Открытая Платформа Visa должна обеспечивать:

- платформонезависимость  (разрешается использовать практически любые операционные платформы для карточек и терминальных устройств, удовлетворяющие спецификациям VisaOpenPlatform в части архитектуры, безопасности, набора команд и форматов обмена сообщениями);

- портирование приложений на различные карточки и терминалы, соответствующие требованиям VOP, благодаря использованию стандартных API;

- стандартизацию пост-эмиссионной загрузки приложений (в спецификациях подробно регламентируется порядок загрузки и выгрузки приложений на/с карточки в различных устройствах уже после ее выпуска);

- поддержку на карточке/в терминале нескольких приложений с разделяемыми ресурсами;

- контроль эмитента карточки за ее содержимым при существовании формальной свободы держателя карточки в выборе необходимых ему приложений (таким образом, концепция моноэмитентных карточек, по сути дела, сохраняется; владельцы «посторонних» приложений выступают в качестве провайдеров доступа к дополнительным услугам);

- совместимость с существующими стандартами ISO/EMV и соответствующей этим стандартам инфраструктурой.

В качестве основной операционной среды для VisaOpenPlatform изначально выбрана Java, хотя использование других платформ в принципе не отвергается - при условии, что они соответствуют требованиям VOP.

 Описание VOP представляет собой пакет документов, в состав которого входят  Общие Требования к карточкам (OpenPlatformCardSpecifications), Специальные Tребования Visa к карточкам (VisaOpenPlatformCardImplementationSpecifications), Специальные требования Visa к терминальным устройствам (VisaOpenPlatformTerminalSpecifications), а также Требования к инструментам разработки, тестирования  и загрузки приложений (VisaOpenPlatformWorkbenchTools).

Специальные требования Visa к карточкам

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

Архитектура карточки включает операционную систему, виртуальную машину JavaCard и интерфейс к ней JavaCardAPI, интерфейс приложений VisaOpenPlatformAPI, а также набор приложений . В принципе, основные компоненты архитектуры соответствуют описанным в общих спецификациях  JavaCard, за исключением нескольких расширений Visa - Интерфейса приложений Открытой Платформы Visa (OpenPlatformAPI), Менеджера Карточки (CardManager) и Доменов безопасности провайдеров приложений (ProviderSecurityDomains).

Менеджер Карточки

Менеджер Карточки является основным компонентом карточки VOP и, по сути дела, выполняет функции центрального администратора: защищает интересы основного эмитента карточки, регистрируя и по возможности предотвращая попытки несанкционированного доступа к хранящейся на карточке информации, а также контролируя порядок загрузки и выгрузки приложений.

Основными функциями Менеджера Карточки являются:

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

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

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

- контроль Домена Безопасности Эмитента (IssuerSecurityDomain).

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

При этом Менеджер Карточки сам является одним из ее приложений, хотя и со специальными свойствами. Он может самостоятельно изменять свой статус (например, присваивать себе статус «выбрано» (SELECT) по внешней команде эмитента карточки для загрузки новых приложений).

В состав Менеджера Карточки входит также Реестр Карточки (CardRegistry), который является своего рода каталогом информационных ресурсов для управления содержимым карточки, жизненным циклом приложений, установкой и удалением приложений с карточки, блокированием, распределением ресурсов памяти и т. д.

Домены Безопасности Провайдеров

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

Модель жизненного цикла

Одно из наиболее привлекательных свойства VisaOpenPlatform  - ее динамическая природа, которая реализуется благодаря концепции жизненных циклов - карточки в целом, приложений, Доменов Безопасности. Еще до того, как карточка, удовлетворяющая спецификациям VOP, эмитируется, она уже содержит одно или несколько приложений, компоненты JavaCard и расширения VOP, описанные выше. Сразу же после эмиссии необходимо обеспечить изолированную работу находящихся на карточке приложений различных провайдеров, а также безопасную загрузку дополнительных приложений других провайдеров. С этой целью  карточка временно блокируется средствами Менеджера карточки, который искусственно изменяет ее статус.

Поскольку Менеджер Карточки отвечает за систему безопасности карточки в целом, администрирование и контроль ее содержимого, жизненный цикл этого приложения практически идентичен жизненному циклу карточки в целом [1] . Выделяется пять возможных статусов Менеджера Карточки, два из которых - «Готов к работе в VOP» и «Инициализирован» - характерны для предэмиссионного этапа, а три других - «Защищен», «Приостановлен» и «Ликвидирован» - для постэмиссионного периода.

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

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

До момента использования держателем карточки каждое из приложений должно быть персонализовано [2] , то есть обеспечено необходимыми для работы данными, специфичными для данного  держателя карточки или группы держателей карточек.

Находящиеся на карточке приложения могут блокироваться - как собственными силами, так и с помощью Менеджера Карточки - например, при выявлении попыток нарушить систему безопасности карточки. Блокирование может носить временный характер, однако, если угроза безопасности сохраняется, приложение может быть логически удалено с  карточки.

Система безопасности

В рамках системы безопасности VOP на эмитента карточки возлагаются следующие функции:

- генерация и загрузка ключей в Домен безопасности Эмитента Менеджера Карточки (если ранее это не было выполнено изготовителем);

- определение политики взаимоотношения с провайдерами карточных приложений в части разграничения ответственности;

- совместная работа с провайдерами приложений по загрузке и инициализации Доменов Безопасности Провайдеров;

- определение политики безопасности Менеджера Карточки на протяжении всего жизненного цикла карточки и приложений;

- загрузка приложений до и после эмиссии карточки;

- авторизация загрузки файлов Провайдерами приложений  с делегированными функциями управления.

В свою очередь, Провайдер приложения отвечает за:

-  генерацию ключей для Домена Безопасности Провайдера или получение ключей от доверенной третьей стороны;

- предоставление для загрузки на карточку приложений, соответствующих требованиям эмитента в части безопасности;

- подготовку файлов загрузки;

- управление ключами;

- получение разрешения эмитента на загрузку приложений и предоставление эмитенту отчетов по загрузке и инсталляции приложений.

Концепция VOP предусматривает возможность защищенного обмена данными между:

- Менеджером Карточки и эмитентом карточки;

- Доменами Безопасности Провайдеров приложений и провайдерами приложений;

- Доменами Безопасности Провайдеров приложений и приложениями.

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

Специальные требования Visa к терминальным устройствам

Специальные требования Visa описывают внутреннюю организацию, или архитектуру, терминальных устройств, а также прикладные интерфейсы к программным компонентам VisaOpenPlatform. Первая версия Требований была принята 30 октября 1998 г.

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

Отражая этот факт, терминальные приложения VOPсостоят из двух основных компонентов: платформозависимого и платформонезависимого блоков. В свою очередь, платформозависимый блок также имеет два уровня глубины - Уровень бизнес-логики (BLL) и Уровень операционного обслуживания (EC). Между ними располагается Уровень логики микросхемных компонентов (CLC), который, собственно и содержит платформонезависимый код . Этот уровень объединяет в себе несколько модулей для обеспечения работы различных приложений на различных аппаратных платформах. Таким образом, Уровень логики микросхемных компонентов использует Уровень операционного обслуживания, когда требуется выполнить одну и ту же операцию на различных терминальных платформах, и Уровень бизнес-логики, когда требуется выбрать из нескольких модулей модуль, необходимый для работы конкретного приложения.

Уровень бизнес-логики

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

Уровень логики микросхемных компонентов CLC

Как уже говорилось выше, каждое приложение, соответствующее требованиям VOP, частично реализуется на карточке, а частично - в терминале. Таким образом, терминальная часть для каждого используемого приложения размещается в CLC.

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

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

Поскольку Уровень микросхемной логики объединяет все платформонезависимые компоненты терминального ПО, он может быть разработан однократно и использован повсеместно в различных типах терминальных устройств. Для обеспечения портируемости в терминале также может размещаться виртуальная машина Java (хотя это и не является обязательным требованием VOP [1] , а скорее, ее дополнительным преимуществом - интерфейсная часть терминального ПО к компонентам VOP написана на Java и, следовательно, в этом случае легче наладить взаимодействие между «карточной» и «терминальной» частями одного и того же приложения).

Уровень операционного обслуживания

Операционная система терминала обеспечивает доступ к различным ресурсам устройства, начиная от клавиатуры, дисплея и картридера и заканчивая средствами взаимодействия с удаленными устройствами (порты передачи данных, модемы и т. д.). Используемые в терминалах закрытые операционные системы позволяют упростить разработку прикладного ПО для взаимодействия с ресурсами устройств, однако в результате ППО работает неустойчиво или не работает вообще на других аппаратных платформах. Для того, чтобы Уровень микросхемных компонентов действительно функционировал платформонезависимо, в спецификациях VOP был определен набор операционных сервисов, которые, в свою очередь, содержат интерфейсы к перечню ресурсов, обыкновенно используемых в большинстве терминалов (см. рис. 3 Архитектура операционной системы терминала в концепции VOP).

Очень важно, что в одном и том же терминале могут «мирно сосуществовать» и приложения VisaOpenPlatform, и используемые ранее приложения для работы с магнитными и микропроцессорными карточками. При этом все предыдущее ПО не требует переделки и может работать в том виде, в  каком оно и было установлено (в этом случае платформонезависимые компоненты CLC приложением не используются). Или, по желанию разработчика, старые приложения могут быть переписаны под VisaOpenPlatform - в этом случае платформонезависимые компоненты приложений могут браться из библиотек Уровня микросхемных компонентов .

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

Согласно VOP, размер памяти терминала VOP должен быть достаточен для хранения операционной системы, EC, CLC, виртуальной машины JAVA, которую использует CLC, а также данных приложения (например, черных списков карточек, журнала транзакций и т. д.).

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

Устройства приема карточек. Каждый терминал должен быть оборудован PCCA для приема карточки потребителя. Что касается карточки продавца, то, в зависимости от установленных на терминале приложений. В этом качестве может быть использован и SAM-модуль, и собственно карточка продавца.

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

Требования к структуре ППО

Требования по структуре ППО включают определение атомарной транзакции, контекста, введение контроля за запросами к сервисам Директории карточек или CLC, хранение данных, порядок асинхронной обработки событий  и т. д.

 Элементарная (атомарная) транзакция

EC обслуживает запросы от CardDirectory или CLC на уровне элементарных транзакций, причем в процессе выполнения каждой из таких транзакций может быть произведено несколько запросов к EC. Примерами элементарных транзакций являются  запрос баланса «электронного кошелька» кредитование (загрузка) или дебетование (платеж) «электронного кошелька».

Контекстный поиск

CLC спроектирован для работы в однозадачном режиме с тем, чтобы его можно было использовать в простейших терминальных устройствах. В результате, пока предыдущий запрос от EC на пользование сервисами CLC не обработан, новый на обработку не поступает. Следовательно, еще до отправки запроса на пользование сервисами EC должен на своем уровне определить, нужен ли такой запрос, в зависимости от того, с каким приложением он работает в данное время. Например, если SCCA поддерживают работу с несколькими карточками торговых предприятий или имеет несколько слотов для установки SIM-карт, то EC  должен предварительно выбрать, с каким слотом он будет работать в данной операции, и уже затем отправлять запрос в CLC.

Контроль

Обе части - «карточная» и «терминальная» (в частности, модуль CLC) - любого из приложений разрабатываются неразрывно друг от друга либо самим эмитентом, либо сторонней организацией по заказу эмитента. Следовательно, в обеих частях приложения будут защищаться прежде всего интересы эмитента. Между тем, в большинстве случаев эмитент и эквайрер карточки - не одно и то же лицо. Чтобы соблюсти баланс интересов, в VOP был введен принцип «topreserveinfrastructurerelationship», который и реализуется на уровне EC.

EC осуществляет тотальный контроль за запросами к Директории карточек или CLC и, фактически, защищает интересы эквайрера (структуры, которая установила терминал) аналогично тому, как Менеджер Карточки отстаивает интересы эмитента, а также - в определенной степени - бизнес-политику торгового предприятия (по аналогии с провайдерами приложений карточки).

Обработка асинхронных событий

EC отвечает за обработку асинхронных событий, которые обычно являются результатами внешних воздействий (установки карточки в картридер, нажатия клавиши и т. д.)

Платформонезависимость

EC не является платформонезависимым компонентом и разрабатывается для каждой аппаратной платформы. EC отвечает за прямое управление устройствами терминала - принтером, модемом, клавиатурой, дисплеем и т. д. Модули CLC могут общаться с устройствами посредством запросов через APIEC.

Безопасность

В концепции VOP терминал не является полностью защищенным устройством, и все приложения должны разрабатываться с учетом этого факта. Например, если требуется выполнение каких-либо секретных операций, необходимо предусмотреть использование SAM-модуля. Чтобы разрешить CLC-модулям доступ к PIN-клавиатуре, в архитектуру VOP был добавлен специальный интерфейс API.

Java-платформа терминала в трактовке VOP

В настоящее время известны 4 «вариации на тему Java» - Java, PersonalJava, EmbeddedJava, и JavaCard. С одной стороны, из всего перечисленного только JavaCard может быть реализована на терминалах с небольшим объемом памяти. С другой стороны,  возможности JavaCard в части поддержки работы cCLC весьма ограничены. Поэтому концепция VOP предусматривает использование в терминалах некоего промежуточного варианта между JavaCard и EbbeddedJavaCard (ближе к JavaCard), обеспечивающего портируемость программного обеспечения на различные аппаратные платформы.

Роль разработчиков терминального ПО  VOP

Термин «разработчик ПО» в  концепции VOP употребляется применительно к конструкторам прикладных программ (applicationdeveloper), поставщикам платформ (т. е. производителям терминальных устройств) и системным интеграторам .

Конструктор прикладных программ - организация, разрабатывающая и внедряющая функциональные спецификации программного продукта для микропроцессорных карточек - Приложения. Работает по заданию организации, заинтересованной в появлении такого приложения. В роли заинтересованной организации может выступать VisaInternational, отдельный банк - участник платежной системы и даже торговое предприятие, которое хочет внедрить у себя локальную карточную программу. Конструктор приложений разрабатывает «карточное» приложение, соответствующий этому приложению программно- и аппаратно независимый CLC - модуль,  а также подробное описание предоставляемых таким модулем сервисов. Впоследствии CLC-модуль и описание к нему передается Системному интегратору для реализации уровня бизнес-логики на базе EC

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

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

Требования к инструментам разработки, тестирования  и загрузки приложений

Предусмотренные в концепции VOP Требования позволяют эмитентам и эквайрерам:

- тестировать и квалифицировать карточные приложения индивидуально и независимо от того, какой тип карточки использовался;

- существенно сократить тестовый период для разработчиков приложений благодаря автоматизации тестов;

- использовать один и тот же инструментарий для разработки как «карточного», так и «терминального» компонентов приложений;

- стандартизировать процедуру персонализации приложений;

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

Инструменты Разработки VOP можно условно разделить на четыре группы:

- собственно инструментарий разработки приложений;

- инструментарий тестирования и квалификации приложений;

- инструментарий тестирования и квалификации приложений VOP;

- инструментарий  загрузки и персонализации приложений.

Инструментарий тестирования и квалификации приложений

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

Тестирование бизнес-логики требует задания набора «кейсов», или вариантов поведения приложения в зависимости от ситуации. Эти варианты формализуются, следовательно, и процедура тестирования бизнес-логики может быть автоматизирована.

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

Инструментарий тестирования и квалификации приложений VOP

Инструментарий тестирования и квалификации приложений VOP во многом схож с описанным выше набором программ для тестирования и квалификации обычных приложений. Отличие заключается в том, что вместо проверки правильности работы бизнес-логики осуществляется контроль функциональности самой Открытой Платформы Visa, а также правильности работы API интерфейсов Открытой Платформы.

Инструментарий загрузки и персонализации приложений

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

Конструктор Персонализационных Скриптов представляет собой интерактивное ПО, использующее в качестве исходных данных профайлы карточки и приложения, информацию о держателях карточек, а также секретные ключи для Менеджера Карточки, Доменов Безопасности Провайдеров и отдельных приложений.

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

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

 Данные о держателях карточек могут вводиться вручную или поступать в пакетном виде из базы данных держателей карточек.n



[1] VOP не устанавливает специальных требований к операционным системам в части способа реализации виртуальной машины JAVA. Виртуальная машина может встраиваться в операционную систему или реализовываться отдельно и независимо от нее.

 


[1] Этап «у производителя» в расчет не принимается

[2] В принципе, приложение может быть персонализовано еще до момента эмиссии карточки


 


Комментарии (0):

Добавлять комментарии могут только зарегистрированные Пользователи


Читайте в этом номере:
обновить

а вы знаете, что...

… деньги из раковин на Соломоновых островах отличаются устойчивостью к любым финансовым кризисам? Если население отдаленных островов используют раковины в качестве расчетной единицы, то в более цивилизованных местах архипелага такие деньги используются как надежный запас на черный день, в то время как расчеты ведутся «обычными» деньгами. Недостаток у них один – недолговечность: раковины хрупкие, часто ломаются. Из-за этого денежная масса остается стабильной и не нарастает, что позволяет поддерживать постоянный курс.