Выбор карты для кобренда: аналитика и эксперимент
Как подобрать карту, характеристики которой позволят использовать ее в кобрендинге?
В прошлом номере журнала «ПЛАС» мы подробно рассмотрели специфику реализации кобренда с участием банка, включая выбор носителя. В этой статье мы уделим внимание задаче выбора карты для кобренда.
Как известно, кобрендовым называется карточный проект, в котором на одной карте (далее будем называть ее кобрендовой картой, КК) размещаются как минимум два приложения (апплета), например, платежное и лояльное. Еще на стадии проектирования кобрендового проекта структуре, отвечающей за выбор карты, приходится решать достаточно сложную задачу выбора из множества карточных продуктов, предлагаемых различными производителями, карты, оптимальной по своим стоимостным характеристикам и гарантирующей при этом корректную работу размещенных на ней апплетов в рамках кобрендового проекта. Далее будем называть такую структуру карточным интегратором (КИ), а карту, которую исследует КИ с целью выяснения возможности использования в кобрендовом проекте, картой-претендентом (КП).
Сложность задачи выбора карты состоит в том, что персобюро, обеспечивающее массовый выпуск карт, обычно предоставляют КИ набор сертификатов, удостоверяющих, что конкретное персобюро способно корректно персонализировать все апплеты, которые после персонализации соответствуют требованиям владельцев этих апплетов, но только при определенных условиях. В большинстве случаев среди этих условий упоминается тот момент, что на исследованные сертификационными лабораториями тестовые карты был загружен только один апплет.
Очевидно, что в нашем случае наличие таких сертификатов является необходимым, но не достаточным условием для того, чтобы КИ выбрал КП в качестве кобрендинговой карты проекта. Ведь КП может не обладать ресурсами, достаточными для обеспечения корректной работы всех апплетов в кобрендовом проекте. В настоящей статье мы рассмотрим пути решения задачи выбора карты, которая по своим характеристикам может быть использована в кобрендовом проекте.
Специфика сертификации кобрендовой карты
Как известно, механизм сертификаций используется для того, чтобы удостоверить потребителя в том, что карта с размещенным на ней апплетом соответствует требованиям владельца этого апплета. Сертификат является письменным свидетельством того факта, что владелец апплета, возможно привлекая аккредитованную им лабораторию, подтверждает факт соответствия конкретного решения своим требованиям. Под решением в этом случае понимается карта с загруженным и персонализированным на ней апплетом.
Так, например, Mastercard проводит сертификацию своих решений с помощью аккредитованных лабораторий, наиболее известными из которых являются Fime и UL. В результате такой сертификации то или иное решение получает сертификат, называемый Letter of Approval. Имеет свою собственную сертификационную лабораторию и АО «НСПК».
В свою очередь, компания СКАНТЕК также проводит сертификацию карт с загруженными на них апплетами, владельцем которых является СКАНТЕК, в собственной сертификационной лаборатории. Результатом сертификации является сертификат [1], подтверждающий факт соответствия решения, полученного некоторым персобюро с помощью некоторого персорешения, требованиям владельца апплета.
Таким образом, если, например, в проекте планируется использовать два приложения – MСhip и LoyApp, но для некоторой КП отсутствует Letter of Approval на MChip и/или сертификат на LoyApp, то ИК должна исключить эту КП из списка претендентов на кобрендовую карту проекта (по крайней мере до момента получения указанных сертификатов).
Как известно, кобрендовым называется карточный проект, в котором на одной карте (далее будем называть ее кобрендовой картой, КК) размещаются как минимум два приложения (апплета), например, платежное и лояльное. Еще на стадии проектирования кобрендового проекта структуре, отвечающей за выбор карты, приходится решать достаточно сложную задачу выбора из множества карточных продуктов, предлагаемых различными производителями, карты, оптимальной по своим стоимостным характеристикам и гарантирующей при этом корректную работу размещенных на ней апплетов в рамках кобрендового проекта. Далее будем называть такую структуру карточным интегратором (КИ), а карту, которую исследует КИ с целью выяснения возможности использования в кобрендовом проекте, картой-претендентом (КП).
Сложность задачи выбора карты состоит в том, что персобюро, обеспечивающее массовый выпуск карт, обычно предоставляют КИ набор сертификатов, удостоверяющих, что конкретное персобюро способно корректно персонализировать все апплеты, которые после персонализации соответствуют требованиям владельцев этих апплетов, но только при определенных условиях. В большинстве случаев среди этих условий упоминается тот момент, что на исследованные сертификационными лабораториями тестовые карты был загружен только один апплет.
Очевидно, что в нашем случае наличие таких сертификатов является необходимым, но не достаточным условием для того, чтобы КИ выбрал КП в качестве кобрендинговой карты проекта. Ведь КП может не обладать ресурсами, достаточными для обеспечения корректной работы всех апплетов в кобрендовом проекте. В настоящей статье мы рассмотрим пути решения задачи выбора карты, которая по своим характеристикам может быть использована в кобрендовом проекте.
Специфика сертификации кобрендовой карты
Как известно, механизм сертификаций используется для того, чтобы удостоверить потребителя в том, что карта с размещенным на ней апплетом соответствует требованиям владельца этого апплета. Сертификат является письменным свидетельством того факта, что владелец апплета, возможно привлекая аккредитованную им лабораторию, подтверждает факт соответствия конкретного решения своим требованиям. Под решением в этом случае понимается карта с загруженным и персонализированным на ней апплетом.
Так, например, Mastercard проводит сертификацию своих решений с помощью аккредитованных лабораторий, наиболее известными из которых являются Fime и UL. В результате такой сертификации то или иное решение получает сертификат, называемый Letter of Approval. Имеет свою собственную сертификационную лабораторию и АО «НСПК».
В свою очередь, компания СКАНТЕК также проводит сертификацию карт с загруженными на них апплетами, владельцем которых является СКАНТЕК, в собственной сертификационной лаборатории. Результатом сертификации является сертификат [1], подтверждающий факт соответствия решения, полученного некоторым персобюро с помощью некоторого персорешения, требованиям владельца апплета.
Таким образом, если, например, в проекте планируется использовать два приложения – MСhip и LoyApp, но для некоторой КП отсутствует Letter of Approval на MChip и/или сертификат на LoyApp, то ИК должна исключить эту КП из списка претендентов на кобрендовую карту проекта (по крайней мере до момента получения указанных сертификатов).
Александр Спесивцев
генеральный директор компании СКАНТЕК
СКАНТЕК проводит сертификацию карт с загруженными на них апплетами, владельцем которых является СКАНТЕК, в собственной сертификационной лаборатории
Ключевые характеристики кобрендовой карты
Современная карта – это сложное устройство, имеющее процессор, криптографический сопроцессор, операционную систему, контактный и бесконтактный интерфейсы, а также память типа ROM, EEPROM и RAM. Будем называть указанные сущности ресурсами карты.
Наиболее распространенной карточной ОС является Java, поэтому далее мы будем считать, что на карте используется ОС Java. В общепринятых терминах операционных систем все java-апплеты представляют собой виртуальные машины (VM), работающие под управлением монитора виртуальных машин, называемого в ОС Java – Javacard Runtime Environment (JCRE).
VM в процессе работы могут запрашивать у JCRE некоторые ресурсы карты, например, память EEPROM, доступ к бесконтактному интерфейсу и т. п.
При обращении к некоторым ресурсам карты, например, процессору, контактному интерфейсу и т. п., VM всегда получает к ним доступ в том смысле, что JCRE не может отказать VM в предоставлении этого ресурса. Будем называть ресурсы, которые всегда могут быть предоставлены VM и для которых не требуется предварительно запрашивать их наличие, неделимыми.
Однако при обращении к другим ресурсам карты, например, EEPROM или RAM, виртуальная машина может получить отказ в предоставлении доступа к ним со стороны JCRE. Такие ресурсы характеризуются некоторой мерой, которую мы будем в дальнейшем называть объемом. Так, например, объем EEPROM – это килобайты.
JCRE отказывает в запросе VM на выделение запрашиваемого ей объема делимого ресурса, если текущий оставшийся «объем» этого ресурса на карте меньше, чем запрашиваемый со стороны VM. Будем называть ресурсы, которые выделяются по запросу со стороны VM и объема которых может не хватить для корректной работы VM, делимыми.
Современная карта – это сложное устройство, имеющее процессор, криптографический сопроцессор, операционную систему, контактный и бесконтактный интерфейсы, а также память типа ROM, EEPROM и RAM. Будем называть указанные сущности ресурсами карты.
Наиболее распространенной карточной ОС является Java, поэтому далее мы будем считать, что на карте используется ОС Java. В общепринятых терминах операционных систем все java-апплеты представляют собой виртуальные машины (VM), работающие под управлением монитора виртуальных машин, называемого в ОС Java – Javacard Runtime Environment (JCRE).
VM в процессе работы могут запрашивать у JCRE некоторые ресурсы карты, например, память EEPROM, доступ к бесконтактному интерфейсу и т. п.
При обращении к некоторым ресурсам карты, например, процессору, контактному интерфейсу и т. п., VM всегда получает к ним доступ в том смысле, что JCRE не может отказать VM в предоставлении этого ресурса. Будем называть ресурсы, которые всегда могут быть предоставлены VM и для которых не требуется предварительно запрашивать их наличие, неделимыми.
Однако при обращении к другим ресурсам карты, например, EEPROM или RAM, виртуальная машина может получить отказ в предоставлении доступа к ним со стороны JCRE. Такие ресурсы характеризуются некоторой мерой, которую мы будем в дальнейшем называть объемом. Так, например, объем EEPROM – это килобайты.
JCRE отказывает в запросе VM на выделение запрашиваемого ей объема делимого ресурса, если текущий оставшийся «объем» этого ресурса на карте меньше, чем запрашиваемый со стороны VM. Будем называть ресурсы, которые выделяются по запросу со стороны VM и объема которых может не хватить для корректной работы VM, делимыми.
“
Сертификат свидетельствует, что владелец апплета подтверждает соответствие решения своим требованиям
Запрос делимых ресурсов может осуществляться в процессе загрузки, инициализации, персонализации и функционирования апплета. Если недостаток ресурса случился при запросе во время загрузки, инициализации или персонализации апплета, то эта ситуация легко выявляется по соответствующим журналам. А вот нехватка ресурса, возникающая в процессе функционирования апплета, уже представляет собой серьезный риск, так как карта с апплетом может быть передана клиенту, и в какой-то момент времени некоторая операция в реальной системе может завершиться некорректно. Указанная ситуация характеризуется и высокой сложностью в выявлении причин такого некорректного завершения, так как в процессе функционирования апплета журналы уже не ведутся.
Основополагающим принципом работы JCRE является исключение влияния одной VM на другую VM. Иными словами, каждая VM в процессе своей работы может считать, что только она одна работает со всеми выделенными ей ресурсами, и она не может оказывать никакого влияния на другие VM, так же как другие VM не могут оказывать никакого влияния на ее ресурсы. Этот принцип является очень важным для ИК, так как (с аналитической точки зрения) позволяет декомпозировать общую задачу проверки КП с точки зрения корректной работы на ней совокупности апплетов кобрендового проекта на несколько (по числу апплетов) задач исследования работоспособности отдельно взятых апплетов на КП. Фактически данный принцип дает возможность прийти к следующему выводу: «если всем апплетам в процессе загрузки, персонализации и функционирования хватает делимых ресурсов КП, то каждый апплет должен работать так же корректно, как если бы только он один был загружен на КП». Хочется отметить, что на практике справедливость данного аналитического положения необходимо всегда проверять, так как в природе отсутствуют программы, свободные от ошибок.
Основополагающим принципом работы JCRE является исключение влияния одной VM на другую VM. Иными словами, каждая VM в процессе своей работы может считать, что только она одна работает со всеми выделенными ей ресурсами, и она не может оказывать никакого влияния на другие VM, так же как другие VM не могут оказывать никакого влияния на ее ресурсы. Этот принцип является очень важным для ИК, так как (с аналитической точки зрения) позволяет декомпозировать общую задачу проверки КП с точки зрения корректной работы на ней совокупности апплетов кобрендового проекта на несколько (по числу апплетов) задач исследования работоспособности отдельно взятых апплетов на КП. Фактически данный принцип дает возможность прийти к следующему выводу: «если всем апплетам в процессе загрузки, персонализации и функционирования хватает делимых ресурсов КП, то каждый апплет должен работать так же корректно, как если бы только он один был загружен на КП». Хочется отметить, что на практике справедливость данного аналитического положения необходимо всегда проверять, так как в природе отсутствуют программы, свободные от ошибок.
Ситуация, когда делимых ресурсов не хватает, и является распространенной причиной некорректной работы апплетов с динамическим запросом ресурсов
Характеристики апплетов
Создавая апплет, разработчик всегда ориентируется на то, что на карте должны быть те или иные ресурсы, необходимые для работы апплета. Все апплеты являются реентерабельными программами, коды которых (пакеты) размещаются либо в ROM (native-апплеты), либо в EEPROM (java-апплеты). В процессе персонализации апплету выделяется EEPROM-память (instance), в которую записываются некоторые данные и резервируются поля, используемые апплетом в процессе дальнейшей работы.
С точки зрения своего функционирования апплеты могут быть написаны с использованием одного из следующих двух способов распределения (выделения) делимых ресурсов – статического и динамического.
При статическом распределении ресурсов весь объем делимого ресурса, необходимый апплету в процессе функционирования, предоставляется ему (резервируется за ним) до этапа функционирования, поэтому на этапе функционирования апплет не запрашивает дополнительных делимых ресурсов.
При динамическом распределении ресурсов на этапе персонализации апплету предоставляется некоторый объем дели- мого ресурса, а в процессе работы апплет может дополнительно запрашивать тот или иной объем делимого ресурса у JCRE.
Так как на этапе функционирования апплеты со статическим выделением ресурсов не запрашивают больше делимых ресурсов, чем изначально выделено, то можно пред- полагать, что после успешной персонализации функционирование таких апплетов в кобрендовой программе будет корректным. Таким образом, для апплетов, запрашивающих все необходимые для функционирования делимые ресурсы до этапа персонализации (включительно), справедлив принцип: «если персонализация апплета прошла корректно, то и функционирование апплета также будет корректным (с точки зрения достаточности ресурсов)».
Если же аплеты запрашивают (и освобождают) делимые ресурсы динамически во время своего выполнения, то возможна ситуация, когда персонализация карты завершилась успешно, но во время ее функционирования некоторый апплет запросил делимый ресурс, объема которого в момент запроса оказалось на карте недостаточно. Это может произойти, например, если весь объем этого ресурса был запрошен другими апплетами. Именно эта ситуация, когда делимых ресурсов не хватает, и является распространенной причиной некорректной работы апплетов с динамическим запросом ресурсов.
В данной статье мы не ставим перед собой задачу анализа достоинств и недостатков методов статического и динамического распределения ресурсов, но обращаем внимание, что для ИК очень важно знать способ, который каждый применяемый в кобрендовом проекте апплет использует для получения от операционной системы делимых ресурсов, необходимых ему для работы.
Создавая апплет, разработчик всегда ориентируется на то, что на карте должны быть те или иные ресурсы, необходимые для работы апплета. Все апплеты являются реентерабельными программами, коды которых (пакеты) размещаются либо в ROM (native-апплеты), либо в EEPROM (java-апплеты). В процессе персонализации апплету выделяется EEPROM-память (instance), в которую записываются некоторые данные и резервируются поля, используемые апплетом в процессе дальнейшей работы.
С точки зрения своего функционирования апплеты могут быть написаны с использованием одного из следующих двух способов распределения (выделения) делимых ресурсов – статического и динамического.
При статическом распределении ресурсов весь объем делимого ресурса, необходимый апплету в процессе функционирования, предоставляется ему (резервируется за ним) до этапа функционирования, поэтому на этапе функционирования апплет не запрашивает дополнительных делимых ресурсов.
При динамическом распределении ресурсов на этапе персонализации апплету предоставляется некоторый объем дели- мого ресурса, а в процессе работы апплет может дополнительно запрашивать тот или иной объем делимого ресурса у JCRE.
Так как на этапе функционирования апплеты со статическим выделением ресурсов не запрашивают больше делимых ресурсов, чем изначально выделено, то можно пред- полагать, что после успешной персонализации функционирование таких апплетов в кобрендовой программе будет корректным. Таким образом, для апплетов, запрашивающих все необходимые для функционирования делимые ресурсы до этапа персонализации (включительно), справедлив принцип: «если персонализация апплета прошла корректно, то и функционирование апплета также будет корректным (с точки зрения достаточности ресурсов)».
Если же аплеты запрашивают (и освобождают) делимые ресурсы динамически во время своего выполнения, то возможна ситуация, когда персонализация карты завершилась успешно, но во время ее функционирования некоторый апплет запросил делимый ресурс, объема которого в момент запроса оказалось на карте недостаточно. Это может произойти, например, если весь объем этого ресурса был запрошен другими апплетами. Именно эта ситуация, когда делимых ресурсов не хватает, и является распространенной причиной некорректной работы апплетов с динамическим запросом ресурсов.
В данной статье мы не ставим перед собой задачу анализа достоинств и недостатков методов статического и динамического распределения ресурсов, но обращаем внимание, что для ИК очень важно знать способ, который каждый применяемый в кобрендовом проекте апплет использует для получения от операционной системы делимых ресурсов, необходимых ему для работы.
“
Если карта-претендент прошла аналитическую проверку, для ее выбора необходима экспериментальная проверка
Этапы проверки КП
Процесс проверки (выбора) КП мы предлагаем разбить на два этапа – аналитический и экспериментальный.
Во время аналитической проверки определяется достаточность ресурсов КП, для того чтобы ее можно было выбрать в качестве кобрендовой карты (КК). Аналитическая проверка осуществляется с помощью сравнения ресурсов КП с минимально необходимыми ресурсами для корректной работы апплетов в кобрендинговом проекте. Если у КП не хватает ресурсов, то КП не проходит аналитическую проверку, если ресурсов хватает, то проверка считается успешно пройденной.
По сути такой аналитической проверкой является тендер, так как в рамках тендера все компании-участники должны подавать предложения по своим КП, которые соответствуют техническим требованиям (ТТ), определяющим, какими ресурсами должна обладать КК. Таким образом, компании-у- частники, подавая предложение на тендер, должны позаботиться о том, чтобы их КП прошли аналитическую проверку, так как в противном случае их предложения будут отвергнуты тендерной комиссией как не соответствующие ТТ.
Затем среди всех КП, прошедших аналитическую проверку, выбираются КП с наиболее низкими ценовыми характеристиками.
Далее КП с наименьшей ценой подвергаются экспериментальной проверке, основанной на системе экспериментальных тестов, проверяющих корректность персонализации и функционирования апплетов.
КП, прошедшую экспериментальную проверку, можно выбрать в качестве КК.
Рассмотрим более подробно каждый из перечисленных этапов.
Аналитическая проверка карты
Идея аналитической проверки состоит в том, чтобы на основе ТТ к апплетам и TT к картам сформировать систему аналитических тестов, гарантирующих (с аналитической точки зрения), что в слу- чае прохождения КП этой системы тестов КП может быть использована в качестве КК; а в случае их непрохождения КП не может быть использована в качестве КК. Таким образом, с помощью аналитической проверки можно отсечь ряд КП, которые точно не подходят на роль кобрендовой карты проекта, и не тратить время на экспериментальную проверку этих КП. В то же время еще раз подчеркнем: если КП успешно прошла аналитическую проверку, то для выбора ее в качестве КК и начала массового производства карте в любом случае необходимо пройти экспериментальную проверку.
Удобно интерпретировать ТТ к ресурсам карты в виде некоторой аналитической карты (АК), обладающей ресурсами, указанными в ТТ. По сути АК является аналитической моделью реальной физической смарт-карты. Будем говорить, что ресурсов на некоторой АК1 «меньше», чем ресурсов на АК2, если объем этих ресурсов на АК1 меньше, чем на АК2. Например, если на АК1 имеется 16 Мбайт EEPROM, а на АК2 имеется 32 Кбайт EEPROM, тогда будем говорить, что ресурса «EEPROM» на АК1 меньше, чем на АК2. Еще пример: если на АК1 имеется криптопроцессор, выполняющий некоторое криптопреобразование за 100 мс, а на АК2 имеется криптопроцессор, выполняющий это же криптопреобразование за 60 мс, то будем говорить, что объема ресурса «криптопроцессор» на АК1 имеется «меньше», чем на АК2. Очевидно, что если объем ресурсов на АК1 меньше, чем на АК2, и апплеты на АК1 корректно функционируют, то апплеты будут корректно функционировать и на АК2.
Будем называть некоторую АК аналитически необходимой картой (АНК), если (с аналитической точки зрения) из корректного функционирования апплетов (т. е. для того, чтобы им хватило ресурсов) на АК следует, что объем ресурсов АК не меньший, чем АНК. Будем называть некоторую АК аналитически достаточной картой (АДК), если (с аналитической точки зрения) при объеме ресурсов этой АК не меньшем, чем объем ресурсов АДК, следует, что апплеты будут корректно функционировать (т. е. ресурсов апплетам хватит) на этой АК. Будем называть некоторую АК аналитически необходимой и достаточной картой (АНДК), если АК является АНК и АДК одновременно.
Учитывая данные определения, задача КИ по формированию технических тре- бований к КП, подаваемым на конкурс, фактически состоит в формировании АНДК. А собственно аналитическая проверка пригодности КП для использования в кобрендовом проекте сводится к тому, чтобы для всех ресурсов проверить, «не меньше» ли их на КП, чем на АНДК. Если некоторого проверяемого ресурса на КП «меньше», то КП не может быть выбрана в качестве КК проекта. Если всех ресурсов на КП «больше или равно», чем на АНДК, то КП с аналитической точки зрения может быть выбрана в качестве КК проекта.
Отдельно рассмотрим, как «строят» АНДК для случая делимых и неделимых ресурсов.
Процесс проверки (выбора) КП мы предлагаем разбить на два этапа – аналитический и экспериментальный.
Во время аналитической проверки определяется достаточность ресурсов КП, для того чтобы ее можно было выбрать в качестве кобрендовой карты (КК). Аналитическая проверка осуществляется с помощью сравнения ресурсов КП с минимально необходимыми ресурсами для корректной работы апплетов в кобрендинговом проекте. Если у КП не хватает ресурсов, то КП не проходит аналитическую проверку, если ресурсов хватает, то проверка считается успешно пройденной.
По сути такой аналитической проверкой является тендер, так как в рамках тендера все компании-участники должны подавать предложения по своим КП, которые соответствуют техническим требованиям (ТТ), определяющим, какими ресурсами должна обладать КК. Таким образом, компании-у- частники, подавая предложение на тендер, должны позаботиться о том, чтобы их КП прошли аналитическую проверку, так как в противном случае их предложения будут отвергнуты тендерной комиссией как не соответствующие ТТ.
Затем среди всех КП, прошедших аналитическую проверку, выбираются КП с наиболее низкими ценовыми характеристиками.
Далее КП с наименьшей ценой подвергаются экспериментальной проверке, основанной на системе экспериментальных тестов, проверяющих корректность персонализации и функционирования апплетов.
КП, прошедшую экспериментальную проверку, можно выбрать в качестве КК.
Рассмотрим более подробно каждый из перечисленных этапов.
Аналитическая проверка карты
Идея аналитической проверки состоит в том, чтобы на основе ТТ к апплетам и TT к картам сформировать систему аналитических тестов, гарантирующих (с аналитической точки зрения), что в слу- чае прохождения КП этой системы тестов КП может быть использована в качестве КК; а в случае их непрохождения КП не может быть использована в качестве КК. Таким образом, с помощью аналитической проверки можно отсечь ряд КП, которые точно не подходят на роль кобрендовой карты проекта, и не тратить время на экспериментальную проверку этих КП. В то же время еще раз подчеркнем: если КП успешно прошла аналитическую проверку, то для выбора ее в качестве КК и начала массового производства карте в любом случае необходимо пройти экспериментальную проверку.
Удобно интерпретировать ТТ к ресурсам карты в виде некоторой аналитической карты (АК), обладающей ресурсами, указанными в ТТ. По сути АК является аналитической моделью реальной физической смарт-карты. Будем говорить, что ресурсов на некоторой АК1 «меньше», чем ресурсов на АК2, если объем этих ресурсов на АК1 меньше, чем на АК2. Например, если на АК1 имеется 16 Мбайт EEPROM, а на АК2 имеется 32 Кбайт EEPROM, тогда будем говорить, что ресурса «EEPROM» на АК1 меньше, чем на АК2. Еще пример: если на АК1 имеется криптопроцессор, выполняющий некоторое криптопреобразование за 100 мс, а на АК2 имеется криптопроцессор, выполняющий это же криптопреобразование за 60 мс, то будем говорить, что объема ресурса «криптопроцессор» на АК1 имеется «меньше», чем на АК2. Очевидно, что если объем ресурсов на АК1 меньше, чем на АК2, и апплеты на АК1 корректно функционируют, то апплеты будут корректно функционировать и на АК2.
Будем называть некоторую АК аналитически необходимой картой (АНК), если (с аналитической точки зрения) из корректного функционирования апплетов (т. е. для того, чтобы им хватило ресурсов) на АК следует, что объем ресурсов АК не меньший, чем АНК. Будем называть некоторую АК аналитически достаточной картой (АДК), если (с аналитической точки зрения) при объеме ресурсов этой АК не меньшем, чем объем ресурсов АДК, следует, что апплеты будут корректно функционировать (т. е. ресурсов апплетам хватит) на этой АК. Будем называть некоторую АК аналитически необходимой и достаточной картой (АНДК), если АК является АНК и АДК одновременно.
Учитывая данные определения, задача КИ по формированию технических тре- бований к КП, подаваемым на конкурс, фактически состоит в формировании АНДК. А собственно аналитическая проверка пригодности КП для использования в кобрендовом проекте сводится к тому, чтобы для всех ресурсов проверить, «не меньше» ли их на КП, чем на АНДК. Если некоторого проверяемого ресурса на КП «меньше», то КП не может быть выбрана в качестве КК проекта. Если всех ресурсов на КП «больше или равно», чем на АНДК, то КП с аналитической точки зрения может быть выбрана в качестве КК проекта.
Отдельно рассмотрим, как «строят» АНДК для случая делимых и неделимых ресурсов.
“
Никакая аналитическая проверка не может служить достаточным основанием для выбора КП в качестве КК проекта
Формирование неделимых ресурсов АНДК
Имея представленный владельцами апплетов список характеристик ресурсов карты, на которых апплеты работают, КИ формирует характеристики делимых ресурсов АНДК очевидным способом:
• если для работы одного апплета необходима ОС Java Card версия Java Card не ниже 2.0, а для другого апплета необходима ОС Java Card версия Java Card не ниже 2.2, то для АНДК выбирается ОС Java Card версия Java Card не ниже 2.2;
• если для одного апплета необходим криптопроцессор, который должен выполнять некоторое криптопреобразование не менее чем за 100 мс, а для другого апплета – не менее чем за 60 мс, то для АНДК выбирается криптопроцессор, выполняющий данное криптопреобразование не менее чем за 60 мс.
• и т. д.
Формирование делимых ресурсов АНДК
Если все апплеты статически запрашивают некоторый делимый ресурс, то для совместного корректного функционирования всех апплетов АНДК должна иметь объем этого делимого ресурса, равный сумме объемов рассматриваемого делимого ресурса, запрашиваемого всеми апплетами.
В ситуации, когда некоторые апплеты динамически запрашивают делимые ресурсы, КИ должен убедиться в том, что объемы делимых ресурсов КП достаточны для всех апплетов в процессе их работы в кобрендовом проекте. Это более сложная задача, так как требует от КИ понимания динамики потребления объемов ресурсов в процессе функционирования апплетов. Для решения этой задачи КИ должен запросить у персобюро (или владельцев апплетов) информацию о том, когда и сколько делимых ресурсов запрашивают все апплеты в процессе функционирования. Имея эту информацию, КИ может построить график зависимости объема делимых ресурсов, необходимых для корректной работы апплетов, от событий, происходящих в кобрендовом проекте. Максимальное значение графика объема – это и есть «объем» исследуемого ресурса, который необходим и достаточен для корректной работы апплетов в кобрендовом проекте и, следовательно, определяет значение объема этого ресурса для АНДК.
Очевидно, что в общем случае задача определения максимального значения графика достаточно сложна, поэтому вместо АНДК можно взять некоторую АДК, которая по ресурсам не сильно превосходит АНДК. Например, можно воспользоваться следующим подходом – запросить у владельцев апплетов объем делимых ресурсов, необходимых на этапе персонализации, и максимальный дополнительный объем делимых ресурсов, необходимых апплету во время его работы. Тогда для корректной персонализации и работы апплета ему достаточно объема делимого ресурса, равного сумме этих двух показателей. Заметим, что в большинстве случаев разработчики апплета указывают именно этот максимальный объем делимого ресурса, который достаточен для корректной загрузки, персонализации и функционирования апплета.
Таким образом, задачу построения АНДК для апплетов с динамическим запросом ресурсов можно свести к более простой задаче построения АДК со статическим запросом ресурсов, решение которой было рассмотрено в начале данного раздела. Конечно, построенная таким способом АК может оказаться избыточной в том смысле, что «объем» ее делимых ресурсов «завышен» по сравнению с тем объемом, который минимально необходим. Иными словами, возможна ситуация, когда ресурсы аналитически сформированной таким образом АК «больше», чем ресурсы некоторой КП, но все апплеты кобрендового проекта можно корректно персонализировать на этой КП, и в дальнейшем апплеты будут корректно работать в рамках кобрендового проекта, в чем можно убедиться экспериментально, сделав персонализацию и тестирование КП. Вместе с тем данным огрублением можно воспользоваться в ряде случаев, особенно когда объем динамически запрашиваемых ресурсов в процессе работы апплета мал по сравнению с объемом ресурсов, запрашиваемых им на этапе персонализации.
Имея представленный владельцами апплетов список характеристик ресурсов карты, на которых апплеты работают, КИ формирует характеристики делимых ресурсов АНДК очевидным способом:
• если для работы одного апплета необходима ОС Java Card версия Java Card не ниже 2.0, а для другого апплета необходима ОС Java Card версия Java Card не ниже 2.2, то для АНДК выбирается ОС Java Card версия Java Card не ниже 2.2;
• если для одного апплета необходим криптопроцессор, который должен выполнять некоторое криптопреобразование не менее чем за 100 мс, а для другого апплета – не менее чем за 60 мс, то для АНДК выбирается криптопроцессор, выполняющий данное криптопреобразование не менее чем за 60 мс.
• и т. д.
Формирование делимых ресурсов АНДК
Если все апплеты статически запрашивают некоторый делимый ресурс, то для совместного корректного функционирования всех апплетов АНДК должна иметь объем этого делимого ресурса, равный сумме объемов рассматриваемого делимого ресурса, запрашиваемого всеми апплетами.
В ситуации, когда некоторые апплеты динамически запрашивают делимые ресурсы, КИ должен убедиться в том, что объемы делимых ресурсов КП достаточны для всех апплетов в процессе их работы в кобрендовом проекте. Это более сложная задача, так как требует от КИ понимания динамики потребления объемов ресурсов в процессе функционирования апплетов. Для решения этой задачи КИ должен запросить у персобюро (или владельцев апплетов) информацию о том, когда и сколько делимых ресурсов запрашивают все апплеты в процессе функционирования. Имея эту информацию, КИ может построить график зависимости объема делимых ресурсов, необходимых для корректной работы апплетов, от событий, происходящих в кобрендовом проекте. Максимальное значение графика объема – это и есть «объем» исследуемого ресурса, который необходим и достаточен для корректной работы апплетов в кобрендовом проекте и, следовательно, определяет значение объема этого ресурса для АНДК.
Очевидно, что в общем случае задача определения максимального значения графика достаточно сложна, поэтому вместо АНДК можно взять некоторую АДК, которая по ресурсам не сильно превосходит АНДК. Например, можно воспользоваться следующим подходом – запросить у владельцев апплетов объем делимых ресурсов, необходимых на этапе персонализации, и максимальный дополнительный объем делимых ресурсов, необходимых апплету во время его работы. Тогда для корректной персонализации и работы апплета ему достаточно объема делимого ресурса, равного сумме этих двух показателей. Заметим, что в большинстве случаев разработчики апплета указывают именно этот максимальный объем делимого ресурса, который достаточен для корректной загрузки, персонализации и функционирования апплета.
Таким образом, задачу построения АНДК для апплетов с динамическим запросом ресурсов можно свести к более простой задаче построения АДК со статическим запросом ресурсов, решение которой было рассмотрено в начале данного раздела. Конечно, построенная таким способом АК может оказаться избыточной в том смысле, что «объем» ее делимых ресурсов «завышен» по сравнению с тем объемом, который минимально необходим. Иными словами, возможна ситуация, когда ресурсы аналитически сформированной таким образом АК «больше», чем ресурсы некоторой КП, но все апплеты кобрендового проекта можно корректно персонализировать на этой КП, и в дальнейшем апплеты будут корректно работать в рамках кобрендового проекта, в чем можно убедиться экспериментально, сделав персонализацию и тестирование КП. Вместе с тем данным огрублением можно воспользоваться в ряде случаев, особенно когда объем динамически запрашиваемых ресурсов в процессе работы апплета мал по сравнению с объемом ресурсов, запрашиваемых им на этапе персонализации.
Экспериментальная проверка карты
Все МПС и все известные нам разработчики апплетов предписывают обязательную экспериментальную проверку правильности работы карты после ее персонализации в своих лабораториях. Это объясняется тем, что как процессы персонализации, так и процессы функционирования апплетов являются сложными и многофакторными процессами, требующими проверки аналитических выводов на практике. Никакая аналитическая проверка не может служить достаточным основанием для выбора КП в качестве КК проекта.
Последовательность шагов
В качестве примера рассмотрим последовательность действий КИ для выбора КК кобрендового проекта, в котором пред- полагается использовать два апплета – MChip и LoyApp. Вследствие того, что практически все производители карт уже имеют в своих продуктовых портфелях КП с загруженным в ROM апплетом MChip, фактически требуется определить, хватает ли оставшихся ресурсов КП для:
1. загрузки, инициализации и персонализации апплета LoyApp;
2. персонализации апплета MChip;
3. дальнейшей корректной работы указанных двух апплетов в кобрендовом проекте.
Мы предлагаем карточным интеграторам руководствоваться следующей последовательностью действий:
1. Получить от владельца апплета LoyApp требования к ресурсам карты, которые необходимы апплету LoyApp для корректной работы, т. е. КИ формирует ТТ к ресурсам КП.
2. КИ включает ТТ к ресурсам КП в условия тендера. На основе ресурсов, необходимых для LoyApp и MChip, для каждой КП строится АНДК. Выбираются КП, у которых ресурсов не меньше, чем нужно для соответствующих им АНДК.
3. Для КП, прошедших проверку на шаге 2, проверяется наличие сертификатов (в условиях размещения на КП только одного апплета) от всех владельцев апплетов, т. е. наличие Letter of Approval для MChip от MasterCard и сертификата на LoyApp для апплета LoyApp от владельца LoyApp.
4. Проверяется наличие документов от всех владельцев апплетов, удостоверяющих отсутствие необходимости повторной сертификации КП, если она будет кобрендовой картой, либо соответствующего сертификата от владельца апплета для КП в случае, когда на КП размещены множество апплетов кобрендового проекта.
5. Проводится тендер и выбираются карты с минимальной ценой.
6. Участник – победитель тендера выпускает персонализированные тестовые карты для кобрендового проекта.
7. Владельцы апплетов проводят про- верку правильности персонализации своих апплетов – MasterCard предоставляет CPV Report для апплета MChip, и владелец апплета LoyApp предоставляет заключение для апплета LoyApp.
8. Выпускаются «боевые» карты, так называемые BAP-карты. КИ организует проведение приемо-сдаточных испытаний (ПСИ), в которых принимают участие все стороны кобрендового проекта. На ПСИ проверяется правильность работы BAP-карт. Участники кобрендового проекта подписывают акт об успешном функционировании BAP-карт во всех процессах проекта.
После прохождения всех указанных выше шагов КИ может с минимальным риском выбрать КП в качестве кобрендовой карты для проекта и разрешить персобюро начать массовый выпуск таких карт.
Все МПС и все известные нам разработчики апплетов предписывают обязательную экспериментальную проверку правильности работы карты после ее персонализации в своих лабораториях. Это объясняется тем, что как процессы персонализации, так и процессы функционирования апплетов являются сложными и многофакторными процессами, требующими проверки аналитических выводов на практике. Никакая аналитическая проверка не может служить достаточным основанием для выбора КП в качестве КК проекта.
Последовательность шагов
В качестве примера рассмотрим последовательность действий КИ для выбора КК кобрендового проекта, в котором пред- полагается использовать два апплета – MChip и LoyApp. Вследствие того, что практически все производители карт уже имеют в своих продуктовых портфелях КП с загруженным в ROM апплетом MChip, фактически требуется определить, хватает ли оставшихся ресурсов КП для:
1. загрузки, инициализации и персонализации апплета LoyApp;
2. персонализации апплета MChip;
3. дальнейшей корректной работы указанных двух апплетов в кобрендовом проекте.
Мы предлагаем карточным интеграторам руководствоваться следующей последовательностью действий:
1. Получить от владельца апплета LoyApp требования к ресурсам карты, которые необходимы апплету LoyApp для корректной работы, т. е. КИ формирует ТТ к ресурсам КП.
2. КИ включает ТТ к ресурсам КП в условия тендера. На основе ресурсов, необходимых для LoyApp и MChip, для каждой КП строится АНДК. Выбираются КП, у которых ресурсов не меньше, чем нужно для соответствующих им АНДК.
3. Для КП, прошедших проверку на шаге 2, проверяется наличие сертификатов (в условиях размещения на КП только одного апплета) от всех владельцев апплетов, т. е. наличие Letter of Approval для MChip от MasterCard и сертификата на LoyApp для апплета LoyApp от владельца LoyApp.
4. Проверяется наличие документов от всех владельцев апплетов, удостоверяющих отсутствие необходимости повторной сертификации КП, если она будет кобрендовой картой, либо соответствующего сертификата от владельца апплета для КП в случае, когда на КП размещены множество апплетов кобрендового проекта.
5. Проводится тендер и выбираются карты с минимальной ценой.
6. Участник – победитель тендера выпускает персонализированные тестовые карты для кобрендового проекта.
7. Владельцы апплетов проводят про- верку правильности персонализации своих апплетов – MasterCard предоставляет CPV Report для апплета MChip, и владелец апплета LoyApp предоставляет заключение для апплета LoyApp.
8. Выпускаются «боевые» карты, так называемые BAP-карты. КИ организует проведение приемо-сдаточных испытаний (ПСИ), в которых принимают участие все стороны кобрендового проекта. На ПСИ проверяется правильность работы BAP-карт. Участники кобрендового проекта подписывают акт об успешном функционировании BAP-карт во всех процессах проекта.
После прохождения всех указанных выше шагов КИ может с минимальным риском выбрать КП в качестве кобрендовой карты для проекта и разрешить персобюро начать массовый выпуск таких карт.
 |