Чип-карта и способ ее применения

1 Настоящее изобретение относится к чипкарте (т.е. к карточке со встроенной микросхемой), терминалу, используемому вместе с чипкартой, способу применения чип-карты, а также к системе чип-карт. Уже используются микропроцессорные чип-карты с функцией оплаты, например с функцией "электронных денег", безналичной оплаты и получения наличности по системе еврочеков, функцией кредитной карточки и т.д. и,в зависимости от их выпуска такими организациями, как Центральное кредитное управление(Europay Mastercard VISA), установлены нормы,по которым их можно использовать как средство платежа ("суррогат денег"). В качестве примеров их описания в этой связи следует назвать следующие публикации:and interchanges", 09.12.1994. Актуальную обзорную информацию по чип-картам можно найти в публикации StefanOldenbourg Verlag, Mnchen/Wien, 1996, ISBN 3486-23738-1. Обычные чип-карты можно, как правило,использовать только для одной определенной цели, например, в качестве "электронных денег" или электронного удостоверения личности. Обусловлено это тем, что установленные в этих чип-картах прикладные программы (приложения) обычно статичны, т.е. они вводятся в чипкарту при ее изготовлении и остаются неизменными в течение всего срока службы чип-карты. Таким образом, обычные чип-карты ограничены как в отношении их вариабельности, так и в отношении их функциональных возможностей, в частности, функциональное назначение обычных чип-карт, заданное однажды в процессе их изготовления, впоследствии не может быть больше изменено. Исходя из вышеизложенного, в основу настоящего изобретения была положена задача 2 разработать чип-карту с варьируемыми функциональными возможностями. Следующая задача изобретения состоит в создании чип-карты, позволяющей и после процесса ее изготовления варьировать количество и тип реализуемых с помощью этой чип-карты приложений, соответственно прикладных программ и транзакций. Должна обеспечиваться возможность "загрузки" в эту чип-карту дополнительных приложений, возможность удаления приложений с чип-карты, а отдельные приложения должны быть описаны таким образом, чтобы обеспечить независимую друг от друга обработку и защиту данных и работать независимо друг от друга. Например, чип-карта должна соответствовать требованиям стандарта ИСО 7816 к обработке и защите данных, однако, сами по себе отдельные приложения чип-карты должны быть независимы, в частности, от платформы чипкарты. Еще одной задачей изобретения является создание чип-карты, позволяющей пользователю самому определять, соответственно подбирать и изменять количество и тип приложений,используемых в его чип-карте. Кроме того, задача настоящего изобретения заключается в создании чип-карты, дающей возможность и способной реализовывать как внутренние услуги (т.е. имеющей закрытые приложения в том отношении, что не может производиться никакого перевода платежей и расчетов с внешними партнерами), так и услуги связи (т.е. имеющей приложения, обеспечивающие дополнительные связи с внешними партнерами). Таким образом, одним из объектов изобретения является устройство, позволяющее загружать в чип-карту одно или несколько соответствующих приложений, дающих в каждом случае возможность производить транзакции между влaдельцем чип-карты и одним или несколькими поставщиками услуг (провайдерами). Загрузка обеспечивает чип-карте такую конфигурацию, при которой она приобретает новые функциональные возможности, т.е. у нее начинает работать приложение, которое прежде не могло у нее работать. Загруженные данные описывают, а в сочетании с выполняемыми основными функциями чип-карты типа, например,функции операционной системы реализуют такие приложения, которые прежде в чип-карте отсутствовали. Таким образом, функциональные возможности чип-карты в результате загрузки приложения увеличиваются на это самое приложение. В соответствии с одним примером выполнения изобретения предлагаемая в изобретении чип-карта имеет структуру данных (DFVAS),которая в свою очередь подразделяется на подструктуру и запись описания данных, причем структура данных однозначно определена с по 3 мощью идентифицирующего кода и сама по себе не зависит благодаря этому от платформы чип-карты. Такое решение позволяет загружать в подструктуру так называемые приложения,т.е. выполняемые чип-картой функции или прикладные программы. Таким образом становится возможным, загрузив в чип-карту определенное приложение, производить транзакции между владельцем чип-карты и специфицированным для данного приложения провайдером. Запись описания данных внутри структуры данных содержит информацию о типе и/или структуре загруженных в подструктуру приложений. По меньшей мере, запись описания данных, а предпочтительно и вся структура данных защищены от модификаций, по меньшей мере, одним системным ключом и могут быть изменены только при использовании этого ключа. Вместо системного ключа могут быть использованы и другие защитные механизмы или защитные устройства, позволяющие обеспечить защиту данных от модификаций, как, например, персональный идентификационный номер (так называемый ПИН-код) или другие обеспечивающих защиту устройств. Вышеописанная структура позволяет загружать в подструктуру, а также снова удалять из подструктуры различные приложения, изменяя чип-карту в отношении ее функциональных возможностей, соответственно реализуемых с ее помощью приложений. Загрузку и удаление приложений производят путем записи специфических данных и кодов этих приложений в имеющуюся подструктуру. Наличие системного ключа и кода, идентифицирующего структуру данных, делает эту обладающую многофункциональными возможностями структуру данных независимой от платформы чип-карты как таковой, а также самодостаточной и независимой от этой платформы в отношении ее архитектуры защиты данных. В таком варианте чип-карта дает возможность в зависимости от загруженных в подструктуру приложений осуществлять транзакции между ее владельцем и провайдерами, которые зависят от загруженных приложений. Кроме того, чип-карта предпочтительно имеет область памяти для пересылаемых данных, куда при обмене данными записывают,соответственно откуда считывают данные во время транзакций. Благодаря использованию для выборки данных из пересылающей эти данные области памяти специфических ключей терминалов отдельные операции доступа с точки зрения защиты данных не зависят друг от друга. Имеющиеся в чип-карте отдельные подструктуры, соответственно приложения предпочтительно независимы друг от друга и выделены в каждом случае определенному провайдеру. Для конкретного провайдера они, так сказать, представляют собой собственные или спе 001837 4 цифические данные, позволяющие ему использовать определенное приложение. Поэтому в зависимости от типа приложения и конкретного провайдера они содержат различную информацию, например, данные, выражающие определенную стоимость (баллы вознаграждения (бонус), остаток на счете и т.д.), информационные данные о приложении, информационные данные о провайдере и т.д. Предпочтительно, однако,они содержат, в частности, также специфические ключи этого приложения, обеспечивающие возможность доступа к данным подструктуры не зависящим от других подструктур с точки зрения защиты данных способом. В отличие от этого загрузка или создание самой подструктуры, соответственно приложения защищены, по меньшей мере, одним системным ключом более высокого уровня. Перед проведением транзакции между чип-картой и терминалом предпочтительно происходит взаимное опознавание с помощью предусмотренного для этой цели аутентификационного ключа, специфического для приложения, соответственно подструктуры. Затем для проведения транзакций данные записывают в соответствующую зарезервированную для ДУ-приложения (приложения дополнительных услуг) подструктуру, или считывают их из нее, или же они проходят через область памяти для пересылаемых данных. В первом случае используют специфические ключи приложений. В последнем случае используют специфический ключ приложения и предпочтительно также специфический ключ терминала,формируемый, например, с помощью имеющегося в чип-карте ключа формирования ключей на основании специфических данных приложения. Данные, записанные таким способом в область памяти для пересылаемых данных, провайдер может затем считывать через терминал,что предпочтительно происходит путем маркирования хранящихся в этой области памяти данных как погашенных. Если же речь при этом идет о провайдере, не специфицированном для производящего запись приложения, то результатом такой операции является выполнение так называемой услуги связи, т.е. обмен выражающими денежную стоимость данными между различными провайдерами в пользу, соответственно за счет владельца чип-карты. Кроме того,в качестве дополнительной защиты предусмотрено использование ПИН-кода или пароля,сравнение с которыми подтверждает право на проведение транзакции. Наличие у чип-карты варьируемой структуры позволяет в разные моменты времени размещать в ней разное количество различных приложений. Достоверность данных, считываемых из памяти для пересылаемых данных, предпочтительно обеспечивают, используя маркирующий ключ, соответственно используя цифровую 5 подпись или, по меньшей мере, один ключ. При этом наиболее предпочтителен вариант, при котором считанные данные продолжают оставаться в пересылающей данные области памяти и лишь помечаются чип-картой как считанные. Указанный вариант позволяет получать информацию о произведенной транзакции и после ее проведения. Таким способом и при защите выборки можно протоколировать одноразовость выборки данных. Кроме того, наиболее предпочтительно помечать данные, записанные в память для пересылаемых данных, датой окончания их срока хранения, после которой они теряют свое значение. Такой вариант дает возможность реализовать приложения, позволяющие, например, предоставлять билет, имеющий определенный срок действия. Предпочтительное наличие счетчика транзакций позволяет однозначно определять и идентифицировать транзакционные данные,соответственно цифровые данные в отношении их принадлежности к соответствующим транзакциям. Предлагаемая в изобретении чип-карта в предпочтительном варианте ее выполнения включает иерархическую концепцию памяти,которая защищена от изменений на различных ее уровнях различными ключами и которая может варьироваться на уровне приложений в отношении загруженных в память приложений,причем каждое отдельное приложение защищено собственными специфическими ключами от других приложений и не зависит от них, а вся структура защищена, по меньшей мере, одним системным ключом и идентифицирующим структуру кодом и не зависит от самой платформы чип-карты. Концепция памяти для пересылаемых данных позволяет производить обмен данными как между владельцем чип-карты и провайдером, так и между самими различными провайдерами. Выборка из памяти, соответственно запись в память для пересылаемых данных также защищены ключами, причем последние также специфицированы для чип-карт и приложений, а дополнительно еще и для терминалов. Производимая перед каждой транзакцией аутентификация, а также необязательное наличие ПИН-кода или пароля дополнительно повышают надежность защиты предлагаемой в изобретении чип-карты. В пп.21-30 формулы изобретения заявлен терминал, предназначенный для использования вместе с предлагаемой в изобретении чипкартой. Указанный терминал служит для загрузки и удаления приложений, проведения транзакций, просмотра данных, а также для осуществления других функций в сочетании с соответствующими приложениями и транзакциями. Способ проведения транзакций между владельцем чип-карты и провайдером представлен в пп.31-33 формулы изобретения, определение 6 загрузки данных в предлагаемую чип-карту указано в пп.34 и 35, а п.36 содержит определение всей системы, состоящей из чип-карты и терминала. Ниже изобретение более подробно поясняется на примере предпочтительных вариантов его осуществления со ссылкой на прилагаемые чертежи, на которых показано: на фиг. 1 - схематичное изображение предлагаемой в изобретении чип-карты; на фиг. 2 - схематичное изображение всей системы компонентов изобретения; на фиг. 3 - схема потока данных во всей системе; на фиг. 4 - схематичное изображение возможных классов приложений и операций в виде модели проведения транзакций; на фиг. 5 - схематичное изображение архитектуры защиты предлагаемой в изобретении чип-карты; на фиг. 6 - структура файлов общего класса реализации ДУ-контейнера; на фиг. 7 - различные классы реализации Д У-контейнера на примере одного из вариантов осуществления настоящего изобретения; на фиг. 8 - схема структуры файлов ДУконтейнера на примере одного из вариантов осуществления настоящего изобретения; на фиг. 9 - схематичное изображение структуры файлов класса реализации DFPT и на фиг. 10 - схематичное изображение структуры файлов класса реализации DFAD. Прежде, чем переходить к более подробному описанию изобретения, необходимо дать определение используемым ниже терминам. ДУ: дополнительные услуги (англ. VAS(Value Added Services. ДУ-чип-карта: чип-карта дополнительных услуг представляет собой чип-карту, позволяющую участвовать в пользовании дополнительными услугами. Наряду с другими приложениями типа, например, приложений оплаты (т.е. функцией электронных денег) ДУ-чип-карта имеет ДУ-контейнер. ДУ-контейнер: контейнер дополнительных услуг содержит структуры файлов, условия доступа, ключи и (вспомогательные) команды для управления ДУ-приложениями и предоставления функциональных возможностей ДУприложений. ДУ-приложения: приложения дополнительных услуг содержат ДУ-данные (данные дополнительных услуг). Доступом к ДУ-данным управляет ДУ-приложение. ДУ-провайдер (поставщик дополнительных услуг) работает в ДУконтейнере с одним или несколькими ДУприложениями. Пользование ДУ-приложением предусматривает ввод, считывание и обработку ДУ-данных. ДУ-приложение может быть предназначено либо для выполнения внутренних услуг, либо для выполнения услуг связи с внешними партнерами. 7 ДУ-провайдер: поставщик дополнительных услуг, отвечающий за свое ДУ-приложение,которое он разрабатывает в соответствии с общими (рамочными) условиями системного оператора и своими собственными требованиями, а затем через системного оператора и терминалы предоставляет в пользование владельцам чипкарт. Прежде, чем ими можно будет пользоваться, ДУ-приложения необходимо загрузить в ДУконтейнер ДУ-чип-карты. Внутренние услуги (Intraservice): определенный тип ДУ-приложения, используемый под исключительным руководством соответствующего провайдера. Приложения внутренних услуг являются закрытыми приложениями в том отношении, что отсутствуют перевод платежей или расчеты с внешними партнерами. ДУприложение может быть предназначено либо для выполнения внутренних услуг, либо для выполнения услуг связи с внешними партнерами. Приложения услуг связи (Interservices): представляют собой приложения внутренних услуг, поддерживающие через ДУ-контейнер дополнительные связи с внешними партнерами. ДУ-приложение может быть предназначено либо для выполнения внутренних услуг, либо для выполнения услуг связи с внешними партнерами. Системный оператор (СО): системный оператор, или владелец системы, предоставляет ДУ-систему провайдерам и держателям чипкарт для использования. Эмитент: лицо, выпускающее и пускающее в обращение ДУ-чип-карты с ДУ-контейнером. Держатель или владелец чип-карты (ДК): лицо, являющееся владельцем или пользователем чип-карты (в данном случае ДУ-чип-карты) и использующее эту чип-карту с целью участия в пользовании дополнительными услугами. Данное лицо не обязательно должно являться непосредственным собственником этой чипкарты. Сервисный терминал: сервисный терминал устанавливается системным оператором для ДУ-приложений. На сервисном терминале владелец ДУ-чип-карты может управлять имеющимися в ней ДУ-приложениями (загрузка, просмотр, удаление и передача ДУ-приложений). Торговый терминал: обладает функциями платежей и имеет, кроме того, функции дополнительных услуг. В него владелец чип-карты вставляет свою ДУ-чип-карту для того, чтобы, с одной стороны, произвести платеж, а, с другой стороны, чтобы воспользоваться преимуществами дополнительных услуг. Идентификатор приложения(ИДП): имеющее длину не более 16 байт имя приложений для их однозначного различения и возможности выбора приложений извне, не зная структуры файлов чип-карты. ИДП состоит из зарегистрированного идентификатора поставщика 8 приложения (англ. "Registered Application Provider ID" (RID, длиной 5 байт и необязательно из регистрации собственных идентификаторов приложений (англ. "Proprietary Applikation Identifier Registration" (PIX длиной не более 11 байт.DF (от англ. "Directory File"): справочный файл по стандарту ISO 7816. EF (от англ. "Elementary File"): элементарный файл по стандартуISO 7816. Действительный ДУ-контейнер: ДУконтейнер, который может аутентифицировать себя относительно "внешнего мира". Идентификатор ключа (ИК): номер ключа в содержащем ключи элементарном файле.RR (от англ. Rules and Regulations): нормативная база. р: максимальное количество объектов класса реализации DFPT. а: максимальное количество объектов класса реализацииDFAD. nrDIR: общее максимальное количество объектов: nrDIR: = р + а. Количество записей в элементарном файле EFDIR равно nrDIR.nrEFTRANSFER: количество записей в элементарном файле EFTRANSFER. На фиг. 1 схематично показана структура предлагаемой в изобретении чип-карты. В дополнение к вводимым в процессе изготовления статичным и неизменным данным типа главного файла (MF от англ. "Master File") и (необязательно присутствующей) функции электронных денег (справочный файл DFBrse (от нем."Brse" - кошелек) в предлагаемой чип-карте предусмотрен также каталог, соответственно структура данных или структура файлов (справочный файл DFVAS). Последняя служит для размещения дополнительных услуг (ДУ). Наличие указанных дополнительных услуг, представляющих собой приложения, которые можно загружать в чип-карту и в более поздние сроки,т.е. после ее изготовления, придает такой чипкарте гибкие возможности, позволяя варьировать ее функции и производимые с ее помощью транзакции. Предусмотренный в предлагаемой чип-карте так называемый ДУ-контейнер (справочный файл DFVAS) обеспечивает гибкие возможности варьирования функций чип-карты и, кроме того, отделяет находящиеся в чипкарте приложения в плане защиты данных от ее платформы, делая последние независимыми от платформы чип-карты и позволяя даже при необходимости переносить их в другую чип-карту. Реализация предлагаемых в изобретении новых дополнительных функций (ДУ) происходит на базе микропроцессорных чип-карт с помощью ДУ-контейнера. Имеющийся в микропроцессорной чип-карте ДУ-контейнер создает платформу для размещения ДУ-приложений. ДУ-приложения представляют собой соответствующие варианты реализации определенных дополнительных функций. В случае с функцией электронных денег для оплаты с помощью чип-карты (функция платежа) и для использования ДУ-приложения(дополнительная функция) предусмотрены отдельные механизмы, хотя с точки зрения пользователя, соответственно владельца чип-карты это может выглядеть как один процесс. Микропроцессорную карту расширяют,добавляя ДУ-контейнер, способный принимать различные и независимые приложения. Он предоставляет функции ввода, удаления и передачи этих приложений, пользоваться которыми может только уполномоченный системный оператор. С точки зрения обработки и защиты данных ДУ-контейнер не зависит от других системных компонентов интегральной схемы микропроцессора. ДУ-контейнер полностью содержит свое собственное описание и может работать самостоятельно. Для него определена независимая архитектура защиты данных, благодаря чему ДУ-приложения используют самостоятельные функции защиты. В архитектуре защиты используют специфические ключи чип-карт, не относящиеся к определенному изготовителю и не зависящие от идентификационных признаков платформы чип-карты. В ДУ-контейнере используют также механизмы получения производных специфических ключей терминалов. С их помощью ДУконтейнер может сам активно проверять достоверность терминалов, соответственно достоверность формируемых ими данных. В ДУ-контейнер помещают ДУприложения, которые, используя механизмы ДУ-контейнера, предоставляют данные, обеспечивая таким путем управление соответствующими интерфейсами. ДУ-контейнер обеспечивает возможность надежного обмена, а также управление обменом данными в рамках услуг связи между партнерами. ДУ-контейнер осуществляет активный контроль, проверяя достоверность и однократность передачи содержащихся в данных значений. Преимущество ДУ-контейнера по сравнению с другими подходами к созданию чип-карт,содержащих много приложений, состоит в том,что данная концепция независима от какой-либо определенной платформы чип-карты. Она обеспечивает такую архитектуру защиты, которая не зависит от специфических механизмов защиты платформы (таких, как ключи, идентификационные данные, ПИН, использование сигнатуры/цифровой подписи). Другое преимущество концепции ДУконтейнера состоит в том, что количество различных приложений чип-карты не является жестко заданным, обусловленным ограничениями и уставками, действующими на момент изготовления или выпуска чип-карты. Пользователь чип-карты может свободно подбирать нужный ему в настоящий момент набор приложений,который ограничивает только емкость имеющейся у соответствующей чип-карты памяти. Количество загруженных в чип-карту на данный момент ДУ-приложений зависит от фактическо 001837 10 го использования этой чип-карты. Пользователь чип-карты индивидуально составляет набор ДУприложений своей чип-карты. Сказанное относится и к возможности последующего изменения этого набора. ДУ-контейнер позволяет получить многофункциональную чип-карту,функции которой в течение срока ее службы можно подбирать и использовать, варьируя их по количеству и типу приложений. Такое решение дает также возможность, используя всего лишь одну чип-карту, помещать в нее приложения, для которых до сих пор требовались отдельные специальные чип-карты. Можно также передавать ДУ-приложения в другие чип-карты. Это позволяет ДУ-приложениям служить дольше срока службы одной чип-карты и сопровождать пользователя чип-карты в течение всего срока службы приложений. Предоставляющая дополнительные услуги микропроцессорная чип-карта является носителем информации, пригодным для распространения и продажи услуг, требующих доступа к защищенным данным. Такая микропроцессорная чип-карта может быть использована как средство платежа, арифметическое устройство и для сохранения информации о стоимости. Клиент обладает гибкими возможностями самостоятельно снабжать ее в соответствии со своими пожеланиями функциями дополнительных услуг и использовать ее для управления этими функциями. Чип-карта активно контролирует также подлинность и право доступа к информации участвующих в работе терминалов и обеспечивает одноразовость и достоверность передаваемых данных. На фиг. 2 показан общий вид системы с представленными на нем системными компонентами. Владелец системы (системный оператор) предоставляет систему в пользование. На сервисных терминалах (СТ) можно загружать, удалять и передавать ДУ-приложения. Другими операциями являются выбор, просмотр, интерпретация и т.д. ДУ-приложения. Поставщики ДУ-приложений, так называемые ДУ-провайдеры, разрабатывают собственные ДУ-приложения в соответствии с общими условиями системного оператора и по мере возможности в соответствии с собственными требованиями. Наличие в конце цифровой подписи позволяет проверять подлинность соответствующих программ терминала. На фиг. 3 показан поток данных в системе. Системный оператор выдает ДУприложения на терминалы для использования их пользователями чип-карт. Перед совместным использованием ДУ-приложения необходимо загрузить в ДУ-контейнер предлагаемой в изобретении чип-карты. Торговые терминалы (ТТ) позволяют пользоваться имеющимися в чип-карте ДУ 11 приложениями путем ввода, соответственно удаления ДУ-данных. Для получения микропроцессорной чипкарты с функциями дополнительных услуг (ДУ) в эту чип-карту наряду с другими существующими приложениями (например, приложения платежей типа электронных денег) загружают ДУ-контейнер. ДУ-контейнер использует функции, позволяющие загружать, удалять и переносить ДУприложения. Указанные управляющие функции применяет только системный оператор, и в чипкарте они защищены от несанкционированного использования. ДУ-контейнер имеет память для пересылаемых данных, обеспечивающую обмен данными между ДУ-приложениями. Для управления памятью для пересылаемых данных используют две команды: TRANSFER (ПЕРЕДАЧА) и TAKE (ВЫБОРКА). Команда TRANSFER формирует в памяти для пересылаемых данных входное сообщение, содержащее специфические данные соответствующего приложения. Наряду с полезной информацией сюда относятся и такие необходимые для обработки данных сведения, как дата,дата окончания срока хранения и идентификационные данные. Команда TAKE обеспечивает выборку объектов из памяти для пересылаемых данных и маркировку их как считанных. В зависимости от конкретного случая применения объекты затем маркируют как продолжающие оставаться действительными или как недействительные. ДУ-контейнер проверяет действительность переданных данных и однократность их передачи. Для предоставления прикладных программ и управления ими ДУ-приложения используют ДУ-данные. Доступом к ДУ-данным управляет ДУ-приложение, используя для этого механизмы, предоставляемые в ДУ-контейнере всем приложениям. ДУ-провайдер работает в ДУконтейнере с одним или несколькими ДУприложениями. Пользование ДУ-приложениями предусматривает ввод, считывание и обработку ДУ-данных. ДУ-контейнер поддерживает услуги связи. Услуги связи требуют доступа к информации общего пользования, передачи прав на получение выплат и расчета по платежам и услугам между различными партнерами. Ниже возможные услуги, соответственно приложения предлагаемой в изобретении чипкарты поясняются на примерах ее выполнения. Описание относится в каждом случае к способу выпуска и функции чип-карт в соответствии с уровнем техники. Данные функции в будущем будут воспроизводить с помощью одного или нескольких ДУ-приложений. Сначала представлены внутренние услуги. Пример А: Клуб клиентов. Универмаг организует клуб клиентов. Клиент становится членом этого клуба и полу 001837 12 чает вместе со статусом члена клуба определенные услуги, которые лица, не являющиеся членами клуба, получить не могут. Сегодня принадлежность члена клуба к его клубу определяют по наличию у него клубного членского билета. Членский билет оформляется при вступлении в клуб, не подлежит передаче другим лицам и имеет, как правило, определенный срок действия. С помощью членского билета не производится никаких определенных торговых операций, т.е. отсутствует какая-либо связь с объемом продаж товаров универмага покупателю. Этим членский билет клуба отличается от программ предоставления вознаграждений, в которых есть зависимость между статусом участника и объемом продаж. Аналогичные примеры: удостоверение оптовика/дистрибьютора, карточка Senator Card,членство в книжном клубе. Цель: принадлежность к клубу должна подтверждаться приложением в ДУ-контейнере. Пример Б. Система бонусов/вознаграждений. Покупатель или клиент получает за каждую транзакцию (операцию, сделку или покупку) право на определенное конечное вознаграждение. В результате накопления размер вознаграждения, на которое может претендовать данный покупатель или клиент, растет, и покупатель или клиент может в определенный, устанавливаемый им момент времени обменять это свое право на материальную услугу. Право на получение вознаграждения действует в течение определенного срока и может предоставляться определенным лицам или действовать без указания лица. Право на вознаграждение определяют исходя из оборота или объема продаж или на основании частоты пользования покупателя или клиента соответствующими услугами. Аналогичный пример: набранное количество баллов, используемое в системе скидокMilesMore, предоставляемых авиакомпаниями и фирмами по прокату автомобилей. Цель: счетом баллов должно управлять приложение в ДУ-контейнере. Пример В. Скидка. Покупатель или клиент получает плановую скидку с объема продаж/с оборота. Скидка предоставляется за каждую отдельную транзакцию/операцию. Чип-карта не управляет информацией по предыдущему обороту. Каждая транзакция представляет собой законченную операцию. Цель: ДУ-приложение должно показывать право на получение скидки. Пример Г. Функция удостоверения личности. Соответствующее лицо на основании отличительных признаков его чип-карты может подтвердить по отношению к третьим лицам свое право на получение определенных выплат или услуг. Принадлежность удостоверения лич 13 ности определенному лицу должна подтверждаться при каждой транзакции (фотография,ПИН-код, биометрические данные). Подлинность удостоверения личности используется в качестве защитного признака. Аналогичные примеры: доступ в "Интернет", доступ в электронную коммуникационную систему для связи с банками и другими финансово-кредитными учреждениями на дому (HomeBanking), телефонная карточка. Цель: ДУ-приложение должно подтверждать право на получение определенных выплат или услуг. Пример Д. Единицы стоимости. Единицы стоимости получают и расходуют в результате однократного или многократного пользования чип-картой. За одну транзакцию стоимость уменьшается на одну или несколько единиц. Право пользования может передаваться и может содержать ограничения пользования. Аналогичные примеры: разовый проездной билет, проездной билет на несколько поездок,концертный абонемент, билет на 10 сеансов игры в сквош, билет в кино, единицы оплачиваемого времени телефонного разговора. Цель: рационализация расчетов путем использования ДУ-приложения. Пример Е. Расчеты за пользование услугами. Пользование услугами учитывают по времени, частоте и количеству, а расчет производят по тарифам. Заранее не известно, в каком объеме будет затребована данная услуга. Аналогичные примеры: талон на питание,талон на кратковременную парковку. Цель: ДУ-приложение должно обеспечивать возможность расчетов по тарифам. Необходимая в каждом случае своевременная информация для расчетов должна храниться в ДУконтейнере. Пример Ж. Памятка (мобильная память данных). Это приложение делает возможной передачу данных владельца чип-карты провайдеру,позволяя автоматизировать процессы, в настоящее время все еще выполняемые вручную. Указанные данные не позволяют получить из них никакой информации о денежном эквиваленте данных. Аналогичные примеры: заполнение лотерейных билетов, чеки оплаты купленного товара, кассовые чеки, телефонный справочник. Цель: ДУ-провайдер должен иметь возможность считывать данные с чип-карты и таким путем непосредственно предоставлять соответствующую услугу (например, устанавливать телефонное соединение, подбирать перечень нужных товаров, электронными средствами заполнять и регистрировать лотерейный билет). Хранение данных в чип-карте может быть как кратковременным, так и долговременным. 14 Вслед за указанными примерами внутренних услуг следует привести несколько примеров услуг связи. Услуга связи всегда имеет место в случае участия в ней нескольких ДУ-провайдеров. Указанное обстоятельство неразрывно связано с тем, что информация покидает область действия одного ДУ-провайдера. На сегодняшний день этот процесс обеспечивают бумажные подтверждающие документы. Пример А. Возмещение стоимости проезда. Универмаг возмещает покупателю стоимость проезда до универмага общественным местным или пригородным пассажирским транспортом. Покупатель должен предъявить в универмаге разовый проездной билет. Универмаг отмечает на билете выплату компенсации. В определенных случаях универмаг может со своей стороны получить назад от транспортного предприятия часть выплаченной им покупателю компенсации. Цель: процесс возмещения расходов должен производиться электронными средствами. Пример Б. Талон на льготный проезд. Универмаг возмещает покупателю при покупке товара стоимость обратной поездки до дома, выдавая ему талон на льготный проезд. Покупатель получает по нему в билетной кассе один билет на поездку общественным местным или пригородным пассажирским транспортом,соответственно платит за билет меньшую стоимость. Транспортное предприятие производит расчет по этому талону с универмагом. Цель: отображение указанных механизмов ДУ-приложениями путем электронных расчетов между торговыми предприятиями и предприятиями общественного местного или пригородного пассажирского транспорта. Пример В. Автостоянка для покупателей. Универмаг частично возмещает покупателям стоимость парковки при пользовании ими определенной крытой автостоянкой. Владельцем крытой автостоянки является независимое предприятие, получающее от универмага денежное вознаграждение за каждого заприходованного покупателя. Цель: отображение указанных механизмов ДУ-приложениями путем электронных расчетов между торговым предприятием и крытой автостоянкой. Пример Г. Многосторонняя программа выплаты вознаграждений. Группа торговых предприятий и поставщиков услуг договаривается о единой программе выплаты вознаграждений. Цель: каждый партнер может записывать в кредит имеющегося в чип-карте общего счета или оплачивать баллы вознаграждения. Расчеты по платежам и услугам между партнерами производит работающая в фоновом режиме система. 15 Пример Д. Взаимное признание баллов вознаграждения поставщиками услуг. Каждый поставщик услуг работает с собственной программой выплаты вознаграждений,договариваясь, однако, с другими относительно признания набранных баллов. Известными примерами являются договоренности между прокатчиками автомобилей и авиакампаниями по набиранию "миль". Цель: поддержка передачи чип-картой баллов вознаграждения. Каждый провайдер должен вначале накапливать баллы для себя, без возможности постороннего вмешательства. Для передачи данных должны быть предоставлены надежные механизмы. Пример Е. Ночное такси. Наличие билета для проезда общественным местным или пригородным пассажирским транспортом одновременно дает право на проезд в такси, подбирающих поздних пассажиров(например, после 22.00 часов). Таксопарк должен при расчетах доказать предъявление проездного билета. Во избежание злоупотреблений пользование такси отмечается в чип-карте. Цель: ДУ-приложение должно обеспечить возможность пользования, контроля и расчетов по этой услуге. Ниже более подробно описана структура предлагаемой в изобретении чип-карты. Микропроцессорная чип-карта с функцией дополнительных услуг (ДУ) включает, в частности, ДУ-контейнер. ДУ-контейнер представляет собой самостоятельную прикладную программу, которая существует либо одна, либо наряду с другими приложениями, базируясь на платформе чипкарты. ДУ-контейнер полностью содержит в себе свое собственное описание и может работать самостоятельно. Он может работать без имеющейся, как правило, в той же чип-карте функции платежей. В частности, для ДУконтейнера определена независимая архитектура защиты данных, позволяющая ДУприложениям использовать самостоятельные функции защиты. Частью дополнительных услуг (ДУ) являются транзакции, производимые покупателем или клиентом на терминалах поставщика дополнительных услуг-провайдера. Провайдер заинтересован в отслеживании этих транзакций,будь то с целью контроля за системой или для сбора статистической и другой информации. Для оптимизации и унификации структур данных в чип-карте следует отказаться от использования специфических идентификаторов приложений и перейти к использованию однозначных для всей системы идентификаторов (ИД) ДУ-контейнера. Данный номер может быть использован провайдером для выполнения вышеназванных функций, избавляя его от необходимости управлять собственными схемами номеров. 16 Архитектура защиты ДУ-контейнера использует указанный однозначный для всей системы идентификатор для получения производных специфических ключей чип-карт. Использование специфических номеров чип-карт было бы, в принципе, возможно, но их предпочтительно не применять, поскольку в случае установки ДУ-контейнера на различных платформах последние при известных условиях используют схемы со сталкивающимися номерами. Идентификатор присваивает ДУконтейнеру системный оператор, а вводит издатель чип-карт при создании ДУ-контейнера. При стирании ДУ-контейнера идентификатор уничтожается и в результате удаляется из системы. ДУ-контейнер считают удаленным, когда в нем нет никаких ДУ-приложений и удален идентификатор ДУ-контейнера. При переносе всего ДУ-контейнера с прежней чип-карты в новую идентификатор ДУконтейнера передается вместе с ДУприложениями. Эта передача соответствует перемещению ДУ-контейнера с прежней чипкарты в новую. После данной операции прежняя чип-карта не содержит больше никакого ДУконтейнера. Имевшийся в новой чип-карте ДУконтейнер при этой операции подвергают перезаписи и таким образом удаляют. Поскольку идентификатор ДУ-контейнера переходит с прежней чип-карты в новую, для работающих в фоновом режиме систем провайдеров не требуется никакого преобразования идентификационных номеров. Отдельные ДУ-приложения можно перемещать между двумя различными ДУконтейнерами только под контролем соответствующего ДУ-провайдера. При осуществлении данной функции изменяется распределение идентификаторов ДУ-контейнеров и соответствующих им ДУ-приложений, что при известных условиях необходимо отмечать в работающей в фоновом режиме системе провайдера. ДУ-контейнер не содержит в себе никаких признаков, относящихся к личности. ДУприложения могут содержать данные о личности, однако их объем в целях защиты данных и лучшего использования памяти следует сократить до минимума. В случае необходимости ДУприложения должны хранить данные о личности в системе, работающей в фоновом режиме,обеспечив их привязку к чип-карте с помощью идентификатора ДУ-контейнера. Существенным отличительным признаком ДУ-контейнера является поддержка им услуг связи. Услуги связи требуют возможности доступа к данным общего пользования, передачи прав на получение выплат и услуг и расчета по платежам и услугам между различными партнерами. ДУ-контейнер должен обеспечивать указанные возможности и, несмотря на это, гарантировать защиту приложений в рамках внутренних услуг. 17 Так называемые ДУ-приложения внутренних услуг представляют собой приложения, работающие под исключительным контролем провайдера. Провайдер определяет защиту своего приложения независимо от какой-либо внешней инстанции. Без дальнейшей передачи ключей никто не может извне изменить ДУ-данные. Для эффективной работы услуг связи партнеры должны иметь возможность доступа к общим данным. Совместный доступ к данным обеспечивают механизмы многоуровневой защиты. На первом уровне совместный доступ осуществляется исключительно через общедоступные поля передачи данных. Провайдеры могут через эти поля обмениваться данными без необходимости знать приложения или ключи друг друга. Лишь для записи данных в эти поля терминалы должны иметь соответствующие ключи, но не для чтения. Читать может любой без ограничений. Обмен данными между провайдером и его партнером может осуществляться в обоих направлениях при условии, что каждый имеет свой ключ для записи данных. Передаваемые данные могут быть сформированы из ДУ-приложения внутренних услуг провайдера,или наоборот, провайдер может брать данные из поля передачи данных в свое ДУ-приложение внутренних услуг. На втором уровне происходит погашение единиц стоимости, выражаемых ДУ-данными. Провайдер вводит информацию о единицах стоимости в ДУ-данные с помощью специального ключа для записи. Единицы стоимости могут быть израсходованы партнерами по услугам связи, владеющими ключом для их погашения, который они получают от отвечающего за всю систему провайдера. На этом уровне партнеры, имеющие различные права, получают доступ к необщедоступным ДУ-данным. На третьем уровне предусмотрен прямой доступ к ДУ-данным с правом записи для всех участвующих в услугах связи партнеров. Указанный метод требует соответствующей степени доверия между участниками, имеющими возможность неограниченно изменять ДУ-данные. Поле передачи данных служит элементом сопряжения ДУ-приложений. Данные в поле передачи данных формируют находящиеся в ДУ-контейнере ДУ-приложения. Данные могут быть также помещены непосредственно в поле передачи данных, если сформировавший их партнер не имеет собственного ДУ-приложения в ДУ-контейнере. В принципе использовать поле передачи данных могут все приложения, но писать может только тот, у кого есть на это право (ключ). Только получатели, имеющие на это право согласно правилам, т.е. согласно нормативной базе (RulesRegulations, RR), могут считывать данные из поля передачи данных. Получатель проверяет наличие предназначенных для 18 него передаваемых данных и считывает их для обработки в собственной системе. Для недопущения манипуляций с передаваемыми данными при открытом обмене формирующий данные провайдер снабжает их признаком, подтверждающим их действительность,а ДУ-контейнер присваивает им порядковый номер. Указанные элементы гарантируют однократность передачи сообщения и подтверждают происхождение информации. При необходимости формирующий данные провайдер обеспечивает получателю передаваемых данных возможность произвести проверку их действительности. При отсутствии такого желания данные могут быть приняты на веру; в этом случае их действительность при известных условиях проверяют по соответствующему признаку лишь производя взаиморасчет в работающей в фоновом режиме системе формирующего данные провайдера. Данные могут быть взяты из поля передачи данных лишь один раз с получением признака действительности. При выборке данные помечают, и они остаются (в качестве копии) в поле передачи данных. Такое решение позволяет и после выборки данных в течение определенного времени подтверждать факт их передачи. Данные в поле передачи данных содержат дату, определяющую срок их хранения. Перезаписывать данные с истекшим сроком хранения при необходимости могут любые приложения. При выборке данные в поле передачи данных можно помечать, в результате чего они тут же освобождаются для перезаписи. Если же, тем не менее, память для пересылаемых данных полностью заполнится до истечения срока хранения записи с подлежащими передаче данными, владельцу чип-карты придется удалить на сервисном терминале те входные сообщения, которые ему больше не нужны. Для моделирования ДУ-приложений задают 3 операции. Эти операции оперируют ДУданными. Загрузка и удаление приложений являются функциями ДУ-контейнера и в последующих абзацах не рассматриваются. Операция "Приобретение" в общем виде представляет собой приобретение права на услугу или оплату и помещение подтверждения этому в ДУ-данные одного из ДУ-приложений. Операция "Погашение" в общем виде представляет собой реализацию права на услугу или оплату с полным или частичным использованием ДУ-данных приложения. Указанная операция формирует электронную квитанцию, помещаемую в поле передачи данных. Операция "Выборка" в общем виде представляет собой выборку данных электронной квитанции из поля передачи данных с целью их дальнейшей обработки (например, работающей в фоновом режиме системой). Копия квитанции остается в поле передачи данных и служит до 19 кументальным доказательством "погашения" квитанции."Приобретение" ДУ-данных может производить только соответствующий провайдер."Погашение" ДУ-данных может производить только сформировавший их с помощью операции "Приобретение" провайдер, или получивший от него на это право партнер по услугам связи. "Выборку" может производить любой другой провайдер. При услугах связи без равноправного доступа к ДУ-данным переход в состояние "Выборка" разрешает партнер. Расчеты по полученной таким образом электронной квитанции могут затем осуществляться через системного оператора и работающую в фоновом режиме систему провайдера. Операции "Приобретение" и "Погашение" могут производиться за один шаг программы. ДУ-приложения, обладающие общими признаками, можно подразделить на классы. Эти классы являются основой структуры данных в ДУ-контейнере. Провайдер выбирает при вводе в работу своей прикладной программы класс приложений. При этом различают следующие классы приложений:память балловбилетудостоверение личноститалонпамять данных"Память баллов" обозначает класс приложений, управляющих счетом стоимости баллов. На счет баллов могут поступать и с него могут сниматься единицы стоимости. Взносы на счет вносит провайдер, записывая в памяти новую сумму остатка на счете. Снятие единиц стоимости со счета производят с помощью операции"Погашение", помещая в память для пересылаемых данных в качестве счетного документа электронную квитанцию. Доступ к обеим этим функциями реализуют с помощью двух различных ключей доступа."Билет" обозначает класс приложений, в которых существует поле стоимости, единицы которой подвергаются однократному или многократному погашению и, таким образом, расходованию. В классе приложений "Билет" единицы стоимости заносят в счет однократно."Удостоверение личности" обозначает класс приложений, ДУ-данные в которых удостоверяют права на какие-либо услуги. Это удостоверение, как правило, не может быть израсходовано в результате его использования, одна 001837 20 ко, оно перестает действовать в соответствии с определенным критерием, например, истечением срока его действия. В зависимости от типа приложения оно документально подтверждает подлинность удостоверения (пример: удостоверение права на парковку вблизи собственного дома) или предъявление удостоверения (Пример: поездка на такси, подбирающем поздних пассажиров, по месячному проездному билету. Чип-карта выдает электронную квитанцию. Таксопарк предъявляет квитанцию предприятию общественного местного или пригородного пассажирского транспорта для пропорциональных взаиморасчетов). В качестве дополнительного варианта можно документально подтверждать пользование удостоверением на основании электронных квитанций, остающихся в памяти для пересылаемых данных чип-карты."Талон" обозначает класс приложений для промежуточного хранения в чип-карте (как правило, краткосрочных) прав на получение выплат или услуг. Указанные электронные талоны хранятся исключительно в памяти для пересылаемых данных ДУ-контейнера. Как правило, использует талон не то приложение, которое его формирует. Считывать талон из памяти для пересылаемых данных можно только один раз, и это считывание документально подтверждается чип-картой. Формируемый ДУ-контейнером признак действительности работающая в фоновом режиме система может использовать при расчетах."Память данных" обозначает класс приложений, позволяющих провайдеру хранить в ДУконтейнере данные, предоставляющие покупателю, посетителю или клиенту дополнительные услуги (например, меню с последним ассортиментом блюд в ресторане быстрого питанияFast-Food, последние числа, выпавшие при игре в лотерею (цифровое лото), льготы в обслуживании, списки кандидатов). Указанные данные предназначены лишь для информации и не предоставляют права на получение выплат или услуг от провайдера. Доступом к этим данным управляет провайдер. Каждый класс приложений характеризуется определенным циклом пользования. Приводимая ниже таблица показывает, с какой частотой три описанных выше операции используют по отношению к ДУ-данным каждого класса приложений. (Внимание "Приобретение" не означает "Загрузка приложения", а "Выборка" не означает "Удаление приложения"). Память баллов Приобретение многократно Погашение многократно Выборка многократноВ классе приложений ные в приложение. Таблица 1. Цикл пользования Удостоверение Билет Талон Память данных личности однократно однократно однократно многократно многократно многократно однократно никогда многократно многократно однократно никогда"Память данных" не приобретают прав, приложение лишь вводит дан На фиг. 4 приведенные выше классы приложений и операции наглядно показаны на примере модели транзакций. Ниже более подробно поясняется архитектура защиты предлагаемой в изобретении чипкарты. Для обеспечения защиты используют следующие ключи. Таблица 2. Сводная таблица ключей Владелец Описание системный оператор Ключ для управления ДУ-контейнером системный оператор Ключ для идентификации ДУ-контейнера системный оператор Ключ для маркировки данных при транзакциях системный оператор Ключ для получения производного ключаKGKDEC.PIX ДУ-приложение провайдер Ключ доступа к ДУ-данным с правом записи ДУ-приложение провайдер Ключ доступа к ДУ-данным с правом чтения ДУ-провайдер провайдер Ключ для получения производного ключа КDEC торговый терминал провайдер Ключ для идентификации торгового терминала Местонахождение ДУ-контейнер ДУ-контейнер ДУ-контейнер ДУ-контейнер Архитектура защиты основывается на сроке службы ДУ-контейнера, соответственно ДУприложений и ее уровни соответствуют степени ответственности участвующих инстанций. Поясняющая ее схема приводится на фиг. 5. Ниже даются некоторые пояснения к структуре ДУ-контейнера и находящимся в нем приложениям. ДУ-контейнер и специфические вспомогательные команды для дополнительных услуг(ДУ) либо вводит в чип-карту издатель вместе с другими, не относящимися к дополнительным услугам приложениями, или же, самое позднее,их устанавливает на сервисном терминале на существующую платформу чип-карты авторизованный для этого провайдер. Во втором случае может быть использован следующий механизм. Системный оператор договаривается с издателем о временном ключеKSO. Издатель открывает чип-карту своим, только ему известным ключом, создает там файлы ДУ-контейнера и, в частности, вписывает ключKSO в справочный файл структуры данныхDFVAS. При таком варианте системный оператор может впоследствии (например, когда чипкарту первый раз вставляют в сервисный терминал) заменить ключ КSO на свой собственный ключ КSO, который в этом случае будет знать только он. После этого системный оператор может сам вносить и другие данные, например ключ формирования ключей KGKDEC, или, имея платформу с динамическим управлением памятью, самому создавать, соответственно удалять файлы ДУ-приложений. Такая система гаранти рует, что издатель после первого пользования чип-картой не будет иметь больше доступа в ДУ-контейнер, а системный оператор будет иметь доступ только в ДУ-контейнер. Таким образом, отсутствие общих структур данных и какого-либо обмена данными с другими приложениями делает архитектуру защиты ДУконтейнера независимой от других приложений,установленных на платформе чип-карты. Однако в одном из конкретных вариантов выполнения изобретения предполагается использовать первую возможность, при которой издатель по поручению системного оператора устанавливает в чип-карты ДУ-контейнер вместе со всеми ключами. ДУ-контейнер содержит в себе заданную структуру данных, заданные условия доступаKSO для загрузки, соответственно удаления ДУприложений. Наличие такого известного только системному оператору ключа дает гарантированную возможность загружать только разрешенные ДУ-приложения. Для этого чип-карта требует подтверждения системным оператором права на внешний доступ с помощью ключа КSO. Когда владелец чип-карты хочет загрузить на сервисном терминале ДУ-приложение, соответствующий провайдер, поручает системному оператору сделать это для него. При загрузке ДУ-приложения в ДУ-контейнер провайдер передает системному оператору ключи КLVASP и КRVASP, которые тот вводит в приложение. Ключ КLVASP позволяет провайдеру защитить данные 23 приложения от доступа с правом записи и дополнительно внутренние данные от доступа с правом чтения. Для этого чип-карта требует от провайдера подтверждения ключом КLVASP права на внешний доступ, т.е. чип-карта активно контролирует действительность терминала. После успешного выполнения данной функции терминал получает разрешение на доступ в ДУприложение с правом записи и на доступ к внутренним ДУ-данным приложения с правом чтения. В качестве дополнительного варианта возможна внутренняя идентификация, т.е. проверка действительности ДУ-приложения (а, следовательно, и чип-карты) торговым терминалом. При пользовании владельца чип-карты ДУприложением указанные внутренние ДУ-данные можно вводить в приложение, соответственно изменять их на любых терминалах, имеющих ключ КLVASP. Поэтому функция "Приобретение" опирается на команду обновления записи UPDATE RECORD, обязательно предваряемую подтверждением права на внешний доступ с использованием ключа КLVASP. Доступ с правом чтения ко всем не внутренним данным ДУ-приложения разрешен только в случае предварительного подтверждения права на внешний доступ ключом КLVASP или ключом КSO, или в случае правильного ввода системным оператором ПИН-кода или пароля. Защита доступа ПИН-кодом или паролем предусмотрена для того, чтобы владелец чип-карты мог просматривать данные на терминалах или,пользуясь функцией электронных денег. На сервисном терминале владелец чип-карты может на выбор, для всех приложений одновременно,активизировать, соответственно деактивизировать защиту в виде ПИН-кода/пароля, предусмотренную для чтения цифровых данных (выражающих единицы стоимости), соответственно данных состояния. К глобальным данным ДУ-контейнера относится ключ KSIGVASC для маркировки данных,считанных из поля передачи данных. Сигнатура позволяет дополнительно проверить целостность передаваемых при транзакции данных при необходимости их передачи для взаиморасчетов между партнерами по услугам связи в защищенном от манипуляций виде. В дополнение к не обязательно вводимой партнерами по услугам связи сигнатуре, в записях, выдаваемых чип-картой при операции "Выборка", добавляют сигнатуру на основе маркирующего ключаKSIGVASC и показаний управляемого ДУконтейнером счетчика транзакций. Поскольку,хотя чтение в поле передачи данных разрешено каждому, но сигнатура чип-карты формируется ключом KSIGVASC только при вызове операции"Выборка" (а это может происходить только один раз), таким способом выявляют недопустимый двойной учет талонов. Каждый партнер по услугам связи может затребовать у системного оператора подтверждение действительности 24 и однократности передачи считанного талона. Кроме того, системный оператор может, проверив сигнатуру, подтвердить действительность ДУ-контейнера. При поддержке платформой чип-карты асимметричных способов кодирования внутри чип-карты для маркировки в качестве ключа КSIGVASC может быть использован и секретный ключ, или же подобный ключ может быть получен в качестве производного с применением секретного ключа формирования ключей (англ. название: Key Generating Key). Провайдеры могли бы в этом случае использовать открытые(не секретные) ключи для собственной проверки сигнатуры, избегая необходимости консультироваться с системным оператором. К данным ДУ-контейнера относится глобальный ключ формирования ключей (англ. обозначение: Key Generating Key, KGKDEC), способный формировать ключи KDEC для контроля права доступа при операции "Погашение" для всех терминалов всех провайдеров. (Подробнее о получении производных ключей и о контроле будет сказано позже). К защите от несанкционированного доступа при погашении выражающих денежную стоимость данных подходят с другими мерками, чем при загрузке, соответственно приобретении прав. В данном случае вместо собственного ключа приложения достаточно использовать глобальный ключ. Этот глобальный ключ путем получения производной сначала переводят в ключ приложения, а затем путем повторного дифференцирования получают ключ терминала. Провайдеру передают только относящуюся к данному приложению производную общего ключа для формирования им собственных ключей терминала. Краткое описание этого процесса приводится ниже. Выражение mac(k,d) обозначает расчет кода идентификации сообщения (от англ. MessageDES-ключа k, с помощью стандарта шифрования данных DES (от англ. Data Encryption Standard). Если длина сообщения не превышает 8 байт, это соответствует самой кодированной величине (при условии, что ICV=0). Выражениеmacp(k,d) обозначает расчет mac(k,d) с последующим уравниванием битов четности. Результатом k' = macp(k,d) снова является действительный DES-ключ. Расчет специфицированных по приложениям ключей терминалов производят в данном случае следующим образом: 1. Каждая чип-карта запоминает ключ формирования ключей KGKDEC, одинаковый для всех чип-карт и хранимый системным оператором в секрете. Системный оператор дает распоряжение о передаче этого ключа в чип-карту как персонального. С помощью этого ключа можно получить в качестве производных все ключи ДУ-приложений и терминалов. 25 2. Провайдер,хочет ввести ДУприложение А с помощью идентификатора приложения АIDA = RIDVAS.PIXA. В этом случае системный оператор рассчитывает на основании ключа формирования ключей KGKDEC и собственного идентификатора приложения (PIX) специфический ключ приложения по формуле:KGKDЕС,PIX = mаср(КGКDEC, РIXA) и передает этот ключ провайдеру. 3. Данный провайдер на основании ключа формирования ключей KGKDEC,PIX получает для всех терминалов, использующих по отношению к ДУ-приложению А команду TRANSFER (ПЕРЕДАЧА), с помощью их идентификаторов (ID) терминала их специфические производные ключи по формуле:macp(macp(KGKDEC, РIХA), ID терминала). Провайдер запоминает эти ключи в своих терминалах. В случае, когда сам провайдер не работает на этих терминалах, он создает ключи и раздает их операторам терминалов. 4. ДУ-чип-карта выполняет команду передачи данных TRANSFER лишь в том случае,когда команда содержит в себе генерируемую терминалом криптограмму С, формируемую в памяти для пересылаемых данных определенными данными "data" сообщения. Сама чипкарта "знает" ключ KGKDEC и получает от терминала наряду с полезными данными "data" и криптограммой С посылаемые ей идентификатор (ID) терминала, а также собственный идентификатор приложения (PIX) (соответственно чип-карта может сама "знать" идентификаторPIX, на эту тему см. также описание команды передачи данных TRANSFER. В этом случае чип-карта может, используя полезные данные,сама вычислить криптограмму С' по следующей формуле:=С' Затем чип-карта сравнивает самостоятельно вычисленную криптограмму С' с криптограммой С, вычисленной терминалом. При их несовпадении транзакция прерывается и следует сообщение о сбое. При их совпадении ДУ-чипкарта выполняет команду передачи данных 26 Различные масштабы мер защиты соответствуют различной конструкции сервисных, соответственно торговых терминалов (для операций загрузки, соoтветственно приобретения) и простых торговых терминалов (для операции погашения). Для выполнения операции "Погашение" терминал должен знать ключ KDEC и с его помощью подтвердить чип-карте свое право на доступ. Покушаясь на ключ KDEC посягнувший сможет воспользоваться лишь функциями одного данного терминала. Однако эту операцию запротоколирует чип-карта. Протокол будет содержать однозначно определенный порядковый номер, операцию погашения и идентификатор терминала. Для регламентации доступа к ДУ-данным ДУ-приложения используют средства защиты ДУ-контейнера. Выполнение специфических функций дополнительных услуг ограничено определением прав доступа только для имеющих эти права участников. В целом для каждого ДУ-приложения должны быть предусмотрены общедоступные зоны памяти (например, для считывания выраженных в единицах стоимости данных при пользовании функцией электронных денег) и индивидуальные зоны памяти ответственного провайдера, которые он способен защитить от несанкционированного доступа со стороны других лиц (например, внутренние данные администрирования). Поскольку чип-карты согласно стандарту ИСО 7816-4 не имеют никакой дифференцированной защиты от несанкционированного доступа для отдельных записей в элементарных файлах (англ. обозначение: Elementary Files(EF, то для представления различных классификаций одного ДУ-приложения приходится использовать несколько файлов, каждый из которых содержит по одной записи. Такая система позволяет, как показано на фиг. 6, разделив ДУ-данные на четыре элементарных файла, реализовать для классов приложений "Память баллов", "Билет", "Удостоверение личности" и "Память данных" дифференцированную защиту от несанкционированного доступа. Указанные четыре элементарных файла содержат следующие данные, соответственно имеют следующую защиту: Таблица 3. Сводная таблица файлов Типичное использование Защита от доступа Провайдер должен ключомKLVASP подтверждать свое право на доступ, прежде чем он сможет писать ДУ-данные в файлыEFVALUE, соответственно прежде чем он сможет считывать данные из файла EFINTERNAL. Терминал должен с помощью ключа KRVASP подтверждать свое право на доступ, прежде чем он сможет считывать ДУ-данные из файлов EFINFO, EFVALUE Содержание указанного элементаEFINFO Не внутренняя ин-Информация о билетах данных может вводить в память формация о ДУ Информация о программе ботолько провайдер (подтвердив приложении нусовИнформация об удостоверении право на внешний доступ знанием ключа KLVASP.) Считывание личностиИнформация о талонах на пар- данных должно быть возможно ковку только на терминалах, имеющих ключ KRVASP или клю KSO; или при вводе владельцем чип-карты соответствующего ПИН-кодаEFINTERN Внутренние данные Внутренние счетчики, остатки на Содержание указанного элементаAL ДУ-приложения счетах, управляющая информа- данных может вводить в память и ция, дополнительные ключи для: считывать только провайдер. Защита от несанкционированногопрограмм бонусов доступа основана на подтвержде дифференцированных нии права на внешний доступ скидок знанием ключа KLVASP.скрытых признаков удостоверения личностикодовEFVALUE Единицы стоимости Этот элемент данных содержит В явном виде только провайдер ДУ-приложения бухучетные единицы стоимости может вводить в память эти данприложения провайдера по сле- ные (подтвердив право на доступ извне знанием ключа KLVASP). В дующим позициям:остаток на счете неявном виде значение можетостаточная стоимость быть уменьшено командой "Попроездного билета гашение", поданной партнером, активы получившим от провайдера правосчетчик пользования на выполнение этой функции (с помощью сигнатуры операции"Погашение", используя ключ КDEC). Считывание производят так же как и в файле EFINFO. Поле Содержание Содержит известные лишь провайдеру ключи KLVASP,KRVASP(Примечание: Провайдер выдает по паре ключей на каждое ДУприложение и, в дополнительном варианте, на каждую чип-карту) Данная структура элементарных файлов(EF) поддерживает одинаковые дифференцированные права доступа для всех классов приложений. Поскольку теперь однотипные классы приложений в каждом случае объединены в соответствующий класс реализации, определяющий количество и размер элементарных файлов,смешение приложений, требующих различного объема памяти, может быть сведено к минимуму. Классы приложений "Память баллов" и "Билет" используют одни и те же ресурсы элементарных файловEFKEY,EFINFO,EFINTERNAL, EFVALUE, поэтому они объединены в класс реализации "DFPT". Для классов приложений "Удостоверение личности" и"Память данных" достаточно элементарных файлов EFKEY и EFINFO, поэтому они объе 29 динены в класс реализации "DFAD". Если рассматривать данную ситуацию с количественной точки зрения, то имеются объекты класса реализации "DFPT" в количестве р и объекты класса реализации "DFAD" в количестве а, в которые могут быть загружены ДУ-приложения классов приложений "Память баллов" и "Билет", соответственно "Удостоверение личности" и "Память данных". Специально для класса приложений "Талон", который должен быть открыт для доступа с правом чтения всем партнерам по дополнительным услугам для их взаимного обмена информацией, используют класс реализации "Поле передачи данных". Доступы с правом записи возможны исключительно косвенным путем, с использованием команды передачи данныхTRANSFER, требующей сигнатуру с соответствующим ключом КDEC: Указанный класс реализации состоит из ровно одного элемента в элементарном файле EFTRANSFER, входящем в глобальные данные ДУ-контейнера. Объектами этого класса являются записи в данном файле. Этот класс реализации может иметь также обозначение "EFTRANSFER". Представленные на фиг. 7 классы реализации находятся внутри ДУ-контейнера. Эти классы реализации образуют модель памяти ДУ-контейнера. Данная модель памяти может быть предоставлена двумя следующими способами, выбор которых зависит от платформы чип-карты:- Разбиение области памяти ДУконтейнера на постоянные сектора. Издатель определяет для классов реализации DFPT и DFAD соответствующее максимальное количество (р, соответственно а) их объектов, которые он загружает в чип-карту командами создания файла CREATE FILE. Объекты имеют обозначение DFPTi, соответственно DFADi. ДУ-приложения могут быть впоследствии загружены в свободные, т.е. не занятые другими ДУ-приложениями объекты. Для загрузки,соответственно удаления ДУприложений в этом случае требуются только команды обновления записи UPDATE RECORD. Итак, издатель устанавливает количество возможных объектов в обоих классах реализации в соответствии со своими собственными потребностями, что не обязательно согласуется с фактическим использованием дополнительных услуг владельцем чип-карты. Такое секционирование памяти сохраняется в течение всего срока службы чип-карты. ДУ-приложение загружают в объект, относящийся к соответствующему классу реализации. Так, например,ДУ-приложение, представляющее удостоверение личности, может быть загружено и в объект,относящийся к классу реализации DFPT, если в классе реализации DFAD не останется больше свободных объектов. Привязка ДУ-приложения 30 к объекту производится путем записи трех параметров (собственного идентификатора (PIX) ДУ-приложения, идентификтора файла (FID) занятого объекта, полнотекстового имени приложения) в глобальный файл EFDIR ДУконтейнера. Удаление приложения соответствует удалению указанных трех параметров из элементарного файла EFDIR и сопровождаемому стиранием считыванию (с помощью команд обновления записи UPDATE RECORD) данных из занятой этим приложением памяти. Этот вариант находит применение при использовании чип-карт с платформами, не поддерживающими динамического формирования,соответственно удаления структур справочных и элементарных файлов.- Динамическое формирование объектов класса реализации. Для каждого загружаемого ДУприложения, используя команды создания файла CREATE FILE, формируют файлы, необходимые для того класса реализации, на котором оно базируется. При удалении ДУ-приложения занимаемые им справочные и элементарные файлы полностью удаляются из чип-карты, освобождая место в памяти. Максимальное количество объектов в классах реализации издателем в данном случае в явном виде не определяется, а зависит лишь от имеющегося в распоряжении объема памяти чип-карты. Данный вариант требует от операционной системы чип-карты динамического управления памятью. В предлагаемом примере выполнения изобретения рассматривается первый вариант, поскольку второй вариант предъявляет повышенные требования к имеющейся платформе чипкарты. Однако при наличии динамического управления памятью и гарантии того, что динамическое формирование объектов позволит сэкономить больше памяти, чем стоит управление ею, можно воспользоваться существующей концепцией, предоставляющей владельцу чипкарты более гибкие возможности. Ниже представлены структуры данных и команды, позволяющие реализовать ДУконтейнер и функциональные возможности принадлежащей клиенту чип-карты по отношению к другим системным компонентам. Кроме того, определены ДУ-операции для типичных случаев коммерческих операций, описывающие соответствующее взаимодействие между ДУконтейнером и терминалом. Для реализации названного варианта необходимо выполнение следующих предварительных условий:- На торговом терминале любая чип-карта независимо от ее платформы предоставляет один и тот же интерфейс данных и команд. Поэтому необходимые команды имеют однозначное описание их кодировки.- Сервисные терминалы способны распознавать платформу чип-карты. Поэтому выполняемые функции могут быть получены с помощью специфических команд платформы. По этой причине указанные процессы описаны отчасти неформально. Как будет предоставлена конкретная функция, решает изготовитель чипкарты. В этой связи на фиг. 7 схематически показаны различные классы реализации ДУФайл 32 контейнера. На фиг. 8 схематически показана структура данных ДУ-контейнера. На фиг. 9 схематически показана структура данных класса реализации DFPT. На фиг. 10 схематически показана структура данных класса реализацииDFAD. Доступ к файлам ДУ-контейнера в явном виде ограничен следующими условиями доступа (англ. обозначение: Access Conditions, (AC: При этом указанные условия доступа имеют следующее значение:ВСЕГДА (ALW от англ. Always) - доступ команды в файл всегда разрешен;НИКОГДА (NEV от англ. Never) - доступ команды в файл никогда не разрешен;KSO - перед доступом системный оператор должен подтвердить право на внешний доступ ключом KSO;KLVASP - перед доступом провайдер должен подтвердить право на внешний доступ ключом КLVASP;KRVASP - перед доступом авторизованный провайдером терминал должен подтвердить право на внешний доступ ключом KRVASP;ПИН - перед доступом владелец чипкарты должен ввести нужный ПИН-код и послать его с полнотекстовой командой верификации VERIFY в чип-карту;ПИН или KRVASP или KSO = Перед доступом либо владелец чип-карты должен ввести нужный ПИН-код, либо свое право на внешний доступ подтверждает провайдер ключом КRVASP,или системный оператор ключом KSO. При этом следует заметить, что описанная выше логическая операция ИЛИ для прав доступа в операционных системах чип-карт, как правило, не предусмотрена. Данное обстоятельство может привести к особым затратам на реализацию этой операции. (Альтернативный вариант: специальная команда чтения READ с заданным в неявном виде атрибутом защиты.) Для полей данных внутри записей элементарных файлов различают следующие форматы:ASCII, Вingr, BCD, Datum, Formatstring. Элементы данных в формате "Formatstring" содержат в упакованном/сжатом виде ДУданные, которые могут быть показаны владельцу чип-карты на терминале. Для оптимального использования памяти полнотекстовые данные и данные в двоичном коде смешивают, давая возможность представлять их с помощью макросов форматирования. Все элементарные файлы (EF) ДУконтейнера определены в соответствии со стандартом ISO 7816-4 как линейные форматированные элементарные файлы с записями постоянной длины (англ. определение: linear fixedrecord files). Элементарный файл EFID структуры данных (справочный файл DFVAS) состоит из одной записи, содержащей идентификаторыnDIR количества записей. Для каждого загруженного в ДУ-контейнер ДУ-приложения в элементарном файле EF-DIR существует запись, в которой зафиксировано его расширение собственного идентификатора приложения (PIX) (англ. обозначение: Proprietary Identifier Extention(PIX и его физическое место в памяти (идентификатор (FID) файла DFX, в который загружено приложение). Расширение собственного идентификатора приложения (PIX) позволяет в качестве условного числа определить, напри 33 мер, приложение и провайдера, к которому оно относится. Вводимые данные динамически размещает в файле EFDIR сервисный терминал системного оператора. Записи, не содержащие введенных данных, формируют с помощью пустого объекта TLV '61'. При загрузке ДУ-приложения вначале идет поиск свободной области памяти в подходящем ему классе реализации, сюда заносят определенные ДУ-данные и, наконец, формируют новую запись в элементарном файле EFDIR. При удалении приложения в элементарный файл EFDIR необходимо соответственно вписать пустой объект TLV. Элементарный файл EFVERSION структуры данных (справочный файл DFVAS) состоит из одной записи, содержащей номер версии ДУ-контейнера. Номер версии может быть использован терминалами для того, чтобы отличать друг от друга различные варианты ДУ-контейнеров и/или различные версии программного обеспечения. Элементарный файл EFSEQ структуры данных (справочный файл DFVAS) состоит из одной записи, содержащей номер следующего входного сообщения в поле передачи данных. Порядковый номер считывают с помощью вспомогательной команды передачи данныхTRANSFER. После проведения этой операции указанная команда формирует в поле передачи данных (элементарный файл EFTRANSFER) запись, в которую переходит, в частности, порядковый номер из элементарного файлаEFSEQ. Вместе с командой выборки TAKE,обеспечивающей одноразовость выборки каждой записи из поля передачи данных и документирующей эту выборку с помощью сигнатуры по порядковому номеру, такая система позволяет гарантировать одноразовость выборки (оригиналов) талонов, соответственно квитанций. Ниже более подробно описывается память для пересылаемых данных. Память для пересылаемых данных, формируемая внутри ДУ-контейнера, включаетnrEFTRANSFER записей. Содержание записей этого файла представляет собой передаваемые данные, формируемые командой передачи данныхTRANSFER. Память для пересылаемых данных служит как для обмена данными между ДУприложениями, так и для хранения ДУ-данных класса "Талон". Память для пересылаемых данных не имеет ограничения на выборку данных, однако доступ в нее с правом записи возможен только с помощью относящихся к функции дополнительных услуг команд передачи и выборки данных TRANSFER и TAKE. Заполнение полей данных по команде передачи данных TRANSFER происходит с помощью имеющегося в чип-карте алгоритма "по 001837 34 следний из недавно использовавшихся" (англ. обозначение "last recently used"). Самую старую запись в файле можно определить путем нахождения наименьшего значения в первых 2 разрядах записи. Поля данных можно с помощью команды выборки TAKE маркировать в памяти для пересылаемых данных как выбранные и/или удаленные. В любом случае удаление данных из памяти для пересылаемых данных происходит в результате их перезаписи новыми данными. Каждая запись, находящаяся в памяти для пересылаемых данных, включает , например,дату окончания ее срока хранения, идентификатор (ID) терминала, собственный идентификатор приложения (PIX), порядковый номер и другие возможные данные. Каждый элементарный файл EFINFO внутри каталогов справочных файлов DFX (где Х = РТ 1 РТp, AD1 ADa) состоит из одной записи, содержащей дату окончания срока хранения, а также общие ДУ-данные ДУприложения. Например, в ней могут быть указаны вид билета (разовый или на несколько поездок) или пункт отправления. Однако, файлEFINFO должен содержать, по меньшей мере,одно полнотекстовое имя приложения, которое можно считывать при операции "Просмотр ДУприложений". Данные, не предназначенные для общего пользования, провайдер должен защищать с помощью соответствующих внешних кодирующих алгоритмов. Названный элементарный файл можно считывать при получении права на внешний доступ с помощью ключей KSO или КRVASP, или при вводе владельцем чип-карты соответствующего ПИН-кода в случае активизации использующей это число защиты. Каждый элементарный файлEFINTERNAL внутри каталогов справочных файлов DFX (где Х = РТ 1 РТp, AD1 АDa) состоит из одной записи, которая может содержать внутренние ДУ-данные провайдера относительно загруженных им ДУ-приложений. Ни владелец чип-карты, ни какой-либо другой провайдер не могут считывать эти внутренние данные. Каждый элементарный файл EFVALUE внутри каталогов справочных файлов DFX (где Х = PT1 РТp, AD1 ADa) состоит из одной записи, которая может содержать поле выраженных целыми числовыми значениями ДУданных. Этот элементарный файл можно считывать при получении права на внешний доступ с помощью ключей KSO или KRVASP, или при вводе владельцем чип-карты соответствующего ПИНкода, соответственно нужного пароля в случае активизиации использующей это число защиты. Указанные ниже поля ключей используются ДУ-контейнером или ДУ-приложением. Последующее описание исходит из варианта использования при шифровании только стандарта 35 шифрования данных DES, т.е. все ключи ДУконтейнера представляют собой DES-ключи длиной 8 байт (включая бит четности). Внутри ДУ-контейнера и внутри ДУприложений можно, используя соответствующий идентификатор ключа KID (от англ. KeyIdentifier -идентификатор ключа), обращаться к следующим ключам: Таблица 5. Ключи ДУ-контейнера Ключ Идентификатор ключа KID'03' Каждый ключ связан со счетчиком попыток неправильного использования, который регистрирует неудачные попытки получить доступ, используя данный ключ, и блокирует дальнейшее пользование ключом по достижении заданного в этом счетчике лимита попыток. Внутри ДУ-приложения можно, используя соответствующие идентификаторы ключа(KID), обращаться к следующим ключам: Таблица 6. Ключи ДУ-приложения Ключ Идентификатор ключа KID'05' Каждый ключ связан со счетчиком попыток неправильного использования, который регистрирует неудачные попытки получить доступ, используя данный ключ, и блокирует дальнейшее пользование ключом по достижении заданного в этом счетчике лимита попыток. ДУ-контейнер содержит личный идентификационный номер или пароль (ПИН), используемые командой верификации VERIFY для идентификации владельца чип-карты. Этот номер или пароль ПИН связан со счетчиком попыток неправильного использования, который регистрирует каждый случай неправильного ввода этого номера или пароля и блокирует сравнение введенного номера или пароля с заданным по достижении определенного лимита попыток. Указанная блокировка может быть снята системным оператором с помощью соответствующих команд администрирования. При правильно введенном идентификационном номере или пароле ПИН счетчик сбрасывает показание. Приводимые ниже параметры ДУконтейнера издатель чип-карт может подбирать,исходя из имеющегося в наличии места в платформе чип-карты и в соответствии со своими собственными пожеланиями.р Максимальное количество объектов класса реализации DFPT = максимальное количество ДУ-приложений в классах приложений "Память данных" и "Билет", которые можно одновременно загрузить в ДУ-контейнер; 36 а Максимальное количество объектов класса реализации DFAD = максимальное количество ДУ-приложений в классах приложений "Удостоверение личности" и "Память данных", которые можно одновременно загрузить в ДУ-контейнер;nDIR Максимальное общее количество объектов: nDIR = р + а. Количество записей в элементарном файлеEFDIR равно nDIR;nrEFTRANSFER Количество записей элементарного файла EFTRANSFER. Размер памяти, необходимой исходя из величины описанных выше элементарных файлов: Глобальные данные ДУ-контейнера: Поле передачи данных Собственные данные провайдеров: При выборе, например, для параметров а, р и nrEFTRANSFER, указанных ниже значений получаем следующий необходимый для ДУконтейнера минимальный размер памяти (без памяти, необходимой для вспомогательных команд): Параметры р = 8, а = 3, nrEFTRANSFER = 15 р = 10, а = 5, nrEFTRANSFER = 20 Максимальная потребность в памяти, вероятно, примерно на 10% выше минимальной потребности. Ниже приводится более подробное описание команд предлагаемой в изобретении чипкарты. Команду чтения записи READ RECORD используют для считывания данных из линейных элементарных файлов. Чип-карта в ответ передает содержание записи. Обращение в элементарный файл EF обеспечивает краткий идентификатор файла, англ. обозначение Shot FileIdentifier (SFI). Код состояния '9000' указывает на успешное выполнение команды; любой другой код оценивается как ошибка. Команду обновления записи UPDATE RECORD применяют для ввода данных в записи линейного элементарного файла EF. Командное сообщение содержит в себе ссылку на элементарный файл EF, запись и данные. Ответ чип-карты содержит в себе код состояния. Код состояния '9000' указывает на успешное завершение выполнения команды. Другие коды состояния означают ошибку. 37 Команда вызова случайного числа GETCHALLENGE затребует у чип-карты случайное число. Случайное число используют в связи с динамическим подтверждением права на внешний доступ в команде внешней идентификацииEXTERNAL AUTHENTICATE. Ответное сообщение чип-карты содержит случайное число длиной 8 байт и код состояния. Код состояния '9000' указывает на успешное выполнение команды. Другие коды статуса означают ошибку. Команда внешней идентификации EXTERNAL AUTHENTICATE позволяет подтверждать право доступа терминала в чип-карту. Команду EXTERNAL AUTHENTICATE используют в рамках ДУ-приложений для подтверждения права доступа системного оператора и провайдера. Команда EXTERNAL AUTHENTICATE передает в чип-карту криптограмму, которую перед этим должен сформировать терминал путем кодирования случайного числа. Чипкарта сравнивает криптограмму с контрольным значением, которое она сама вычисляет тем же способом. При совпадении обоих значений чипкарта отмечает внутри себя выполнение условия подтверждения права доступа для этого ключа. При отрицательном результате сравнения чипкарта передает в ответ код состояния "Не авторизован" и уменьшает число попыток во внутреннем счетчике попыток неправильного использования на одну единицу. При достижении названным счетчиком значения нуля происходит переход чип-карты в состояние "Идентификация блокирована", которое блокирует любое дальнейшее выполнение команды внешней идентификации EXTERNAL AUTHENTICATE. Ответное сообщение чип-карты содержит код состояния. Успешное выполнение команды и подтверждение права доступа терминала в чип-карту показывает код состояния '9000'. Все другие коды состояния указывают на ошибку. Команду внутренней идентификации INTERNAL AUTHENTICATE используют для предоставления терминалу возможности проверить действительность ДУ-контейнера. Для этой цели чип-карта по полученным от терминала исходным данным рассчитывает криптограмму. Терминал со своей стороны создает криптограмму и сравнивает ее со значением, полученным чип-картой. При их совпадении терминал может принять действительность ДУконтейнера. Ответ чип-карты содержит криптограмму и код состояния для выполнения команды. Успешное выполнение команды показывает код состояния '9000'. Все другие коды состояния указывают на ошибку. Команду верификации VERIFY используют для проверки полномочий доступа владельца чип-карты по его личному идентификационному номеру или паролю (ПИН). Команда передает в незашифрованном виде данные номера или 38 пароля ПИН в чип-карту, и здесь происходит их сравнение с хранящемся в памяти контрольным значением. При совпадении введенного и хранящегося значений условие доступа "ПИН" считается выполненным. Ответное сообщение чип-карты содержит код состояния. Код состояния '9000' показывает успешное выполнение команды. Другие коды состояния указывают на ошибку. Команда передачи данных TRANSFER формирует входное сообщение в памяти для пересылаемых данных. Для этой команды определены три рабочих режима: 1. Формирование входного сообщения в поле передачи данных путем уменьшения значений в элементарном файле EFVALUE приложения класса "Билет" или "Счетчик баллов". 2. Формирование входного сообщения в поле передачи данных путем формирования квитанции в приложениях класса "Удостоверение личности". 3. Формирование входного сообщения в поле передачи данных путем формирования талона в приложениях класса "Талон". Рабочий режим карта выбирает автоматически. При выполнении команды в пределах выбранного справочного файла приложения вначале проверяют наличие элементарного файла EFVALUE. При наличии данного файла чип-карта выполняет команду в первом режиме,в остальных случаях - во втором режиме. Если справочный файл приложения в пределах ДУконтейнера не выбран, используют третий режим. При вызове команды передачи данныхTRANSFER терминал снабжает чип-карту следующими данными:Текущая датаДата окончания срока хранения входного сообщения в поле передачи данныхИдентификация терминала, формирующего это входное сообщениеПолезные данные для поля передачи данныхСобственный идентификатор (PIX) ДУприложения (только для режима 3)Количество вычитаемых единиц (только для режима 1)Код идентификации сообщения (МАC) по вышеназванным данным, порядковому номеру и номеру ДУ-контейнера. При вызове команды передачи данныхTRANSFER чип-карта выполняет операции в следующей последовательности: 1. Поиск свободного входного сообщения в памяти для пересылаемых данных (приводимое перечисление показывает в порядке убывания приоритеты, с учетом которых должна происходить перезапись имеющихся входных сообщений: "Сообщение отмечено как удаленное","Сообщение отмечено как считанное" и "Дата 39 окончания срока наступила", "Дата окончания срока наступила"). 2. Добавление к данным терминала собственного идентификатора (PIX) ДУ-приложения в режимах 1 и 2. 3. Добавление к данным из шага 2 программы порядкового номера. 4. Добавление к данным из шага 3 программы идентификатора (ID) ДУ-контейнера. 5. Получение производного ключа формирования ключей KGKDEC,PIX из ключа формирования ключей KGKDEC путем кодирования собственного идентификатора(PIX) ДУприложения. 6. Получение производного ключа КDEC из ключа формирования ключей KGKDEC,PIX путем кодирования идентификатора (ID) терминала. 7. Формирование кода идентификации сообщения (МАC) по данным из шага 4 программы. 8. Сравнение кода идентификации сообщения (MAC) из шага 7 с кодом идентификации сообщения (МАC) терминала. При несовпадении значений чип-карта прерывает действие данной функции и уменьшает количество попыток в счетчике попыток неправильного использования ключа формирования ключей KGKDEC. 9. Для режима 1: контроль поля значенийEFVALUE в том каталоге, в который загружено приложение. При недостаточном наличии единиц в указанном поле чип-карта прерывает в этом месте действие функции. В противном случае количество единиц стоимости в поле этого приложения уменьшается на соответствующую сумму. 10. Составление командного сообщения. 11. Увеличение содержимого элементарного файла EFSEQ на одну единицу. При такой системе выдача информационной записи в ответе не нужна. Можно и дальше исходить из того, что номер записи известен. Команда выборки TAKE предоставляет следующие режимы:Выборка с одновременной отметкой того,что данные стали недействительными.Выборка без вышеназванной отметки. Данные продолжают оставаться действительными. Командное сообщение включает поля с идентификатором (ID) терминала, собственным идентификатором (PIX) приложения и формируемое терминалом случайное число. Собственный идентификатор (PIX) в команде обозначает производящее выборку приложение. Он может отличаться от собственного индентификатора (PIX) считываемой записи. Он служит исключительно для получения производного ключа КDEC производящего выборку торгового терминала. Ответное сообщение чип-карты содержит криптограмму С 1 с ключом KSIGVASC по данным 40 указанной в командном сообщении записи в поле передачи данных и идентификатор (ID) ДУ-контейнера, криптограмму С 2 с ключом КDEC производящего выборку терминала по С 1 и случайное число из командного сообщения. Ответное сообщение дополнительно содержит код состояния. Производный ключ KDEC получают согласно приведенному выше описанию. С помощью криптограммы по ключу КDEC ДУконтейнер в неявном виде доказывает свою действительность. С помощью криптограммы С происходит расчет для доказательства действительности ДУ-контейнера и однократности выборки информации (поскольку криптограмма С формируется на основании порядкового номера,бита выборки записи из поля передачи данных,и идентификатора (ID) ДУ-контейнера), что может верифицировать системный оператор. Код статуса '9000' указывает на успешное выполнение команды. Иные коды статуса интерпретируют как ошибки. Следует исходить из того, что системный оператор запрашивает один идентификатор(AIDVAS) приложения в соответствии со стандартом ISO/IEC 7816-5. Точнее, он запрашивает имеющий длину 5 байт зарегистрированный идентификатор поставщика приложения (RIDVAS) для системы дополнительных услуг. Идентификатор (AIDVAS) приложения каталога структуры данных (справочного файлаDFVAS) должен выглядеть следующим образом: АIDVAS = RIDVASPIXDFVAS. Командное сообщение содержит, например, поля с датой окончания срока хранения,идентификатором (ID) терминала, данными транзакций, поле рабочего режима (содержащее, например, собственный идентификатор(PIX) в режиме 3), а также криптограмму. Криптограмму рассчитывают, используя ключ KDEC, причем данные, по которым формируют код идентификации сообщения (МАC),включают, например, данные транзакций и идентификатор (ID) терминала. Ответное сообщение команды передачи данных TRANSFER состоит в положительном случае из поля данных длиной 8 байт и кода состояния '9000' длиной 2 байта. Ответные сообщения с кодами состояния, отличными от кода '9000', интерпретируют как ошибочный код. Поле данных ответного сообщения содержит в случае отсутствия ошибки (т.е., в частности, в случае правильности криптограммы в командном сообщении) зашифрованную ключом КDEC криптограмму командного сообщения. Таким способом ДУ-контейнер в неявном виде подтверждает свою действительность (вместо внутреннего идентификации с помощью идентифицирующего ключа КAUT). Команду выборки TAKE используют для выборки объектов из класса реализацииEFTRANSFER. Технически выполнение данной команды означает считывание указываемой 41 записи из файла EFTRANSFER, причем эта запись остается в файле с пометкой "выбрана/считана" до тех пор, пока ее место в памяти не понадобится для ввода новых сообщений. С технической точки зрения любой может воспользоваться командой TAKE для считывания записей, однако с точки зрения норм (RR) делать это должен лишь тот провайдер, для кого эта запись предназначена. Для операции выборки можно принять следующую схему. Провайдер, собирающийся произвести выборку талона или квитанции, просматривает всю память для пересылаемых данных в поиске подходящей информационной записи (например, с помощью команды поискаSEEK, или читая в явном виде каждую запись). В любом случае происходит считывание записи и при необходимости проверка ее содержания. Каждое ДУ-приложение А получает в соответствии с нормами собственный идентификатор (РIХA) длиной 3 байта, позволяющий однозначно идентифицировать его внутри ДУконтейнера с помощью идентификатора (АIDA) приложения А по формуле: АIDA =RIDVASPIXA. После того, как выбран справочный файл DFVAS структуры данных, командой выбора файла SELECT FILE РIХA может быть выбран каталог, в котором находится ДУприложение А. Выражение UPDATE KEY (KID, К) обозначает зависящую от платформы чип-карты команду, заменяющую ключ с идентификатором ключа KID на новое значение ключа К. Прежде, чем владелец чип-карты сможет пользоваться на торговых терминалах ДУприложением одного из классов реализации DFPT или DFAD (что соответствует классам приложений "Память баллов", "Билет", "Удостоверение личности" или "Память данных"), это приложение должно быть загружено в ДУконтейнер на сервисном терминале соответствующего провайдера. В принципе возможен также вариант, при котором издатель чип-карты по поручению какого-либо провайдера, и какого-либо системного оператора уже при установке ДУ-контейнера загружает в него одно или несколько ДУ-приложений. Такой процесс загрузки представляет собой особый случай данного описания. Процесс загрузки ДУ-приложения выглядит следующим образом: 1. Владелец чип-карты вставляет ДУ-чипкарту в сервисный терминал. 2. Сервисный терминал проверяет наличие ДУ-контейнера, используя следующие команды:ВЫБОР ФАЙЛА: SELECT FILEAIDVAS (сообщение об ошибке при невозможности произвести выбор контейнера).ЧТЕНИЕ ЗАПИСИ: READ RECORD 42 В дополнительном варианте происходит проверка действительности ДУ-контейнера. Для этого сервисный терминал требует от ДУконтейнера внутренней идентификации:ВНУТРЕННЯЯ ИДЕНТИФИКАЦИЯ:INTERNAL AUTHENTICATE случайное число, KID из КAUT. Сервисный терминал проверяет ответ и прекращает операцию в случае ошибки, выдавая сообщение об ошибке. 3. Сервисный терминал предоставляет владельцу чип-карты на выбор насколько дополнительных вариантов. Одним из них является "Загрузка ДУ-приложения". Владелец чип-карты выбирает его. Затем сервисный терминал запускает операцию "Просмотр ДУ-приложений",показывая владельцу чип-карты все ДУприложения, которые он может загрузить, и ждет его выбора. Владелец чип-карты выбирает какое-либо ДУ-приложение А из класса реализации DFPT или DFAD. 4. Сервисный терминал в ходе операции"Выбор ДУ-приложения" проверяет ДУконтейнер, определяя, не было ли выбранное ДУ-приложение с собственным идентификатором PIXA уже загружено в чип-карту. В этом случае он выдает сообщение об ошибке. В случае отсутствия этого приложения в чип-карте сервисный терминал проверяет, нет ли в ДУконтейнере еще свободного объекта, соответствующего по классу реализации ДУ-приложению А. Эта проверка осуществляется путем поискаEFDIR. При отсутствии свободной записи поступает сообщение об ошибке. При наличии такой свободной записи она содержит идентификатор FIDDFX файла (каталога) DFX, в который не загружено никакого ДУ-приложения. 5. Следующий свободный объект соответствующего ДУ-приложению А класса реализации занимают под ДУ-приложение А. При этом сервисный терминал сначала запрашивает у провайдера в режиме offline (например, используя управление защищенным доступом (SAM) провайдера) два ключа KLVASP и KRVASP и присваивает их новому ДУ-приложению, используя следующие команды:ВЫБОР ФАЙЛА: SELECT FILEDFX, данныеОБНОВЛЕНИЕ ЗАПИСИ: UPDATE RECORD SFI файла EFINTERNAL из файла (каталога) DFX, данныеФакультативно (инициация): ОБНОВЛЕНИЕ ЗАПИСИ: UPDATE RECORD SFI файла EFVALUE из файла (каталога) DFX,данные 6. После успешной записи информации в элементарные файлы (EF) сервисный терминал выполняет операцию ввода ДУ-приложения:Eintrag VAS-Applikation РIХA, FIDDFX, соединяющую файл DFX с собственным идентификатором (РIХA) приложения, позволяя таким образом выполнять команду выбора файла SELECT FILE с помощью собственного идентификатора (PIXA) приложения (после предварительного выбора с использованием командыSELECT FILE АIDVAS). Предоставляемый памятью для пересылаемых данных механизм может быть использован, например, провайдерами, желающими оказывать внутренние услуги и услуги связи без собственных структур справочных файлов. В этом случае владельцу чип-карты не требуется,в частности, перед использованием ДУприложения сначала загружать его на сервисном терминале. Вместо этого он может получить на торговом терминале талон или квитанцию и получить за них компенсацию на другом терминале (с помощью операции выборки), или просто предъявить этот талон, соответственно квитанцию (операция чтения). Таким образом,загрузка ДУ-приложения класса реализацииEFTRANSFER происходит в неявном виде в результате ввода ДУ-данных, соответственно сводится к ней. В этой связи следует указать на приводимое позже описание операции "Приобретение" класса реализации EFTRANSFER. Ниже дается описание последовательности операции ввода ДУ-приложения. Когда ДУприложение загружено в ДУ-контейнер, терминалу не известно его физическое местонахождение, в какой файл DFX, где Х = РТ 1, РТp,AD1, ADa, загружено ДУ-приложение и загружено ли оно вообще. С точки зрения изготовителя чип-карты имеются два возможных, подлежащих отдельному рассмотрению способа реализации, при этом необходимо, в частности,учитывать совместимость со стандартом Центрального кредитного управления ZKA. Первый случай: доступ в элементарный файл EFDIR возможен. В этом случае необходимо выполнение следующих предварительных условий:В платформе чип-карты стандартно должен быть элементарный файл EFDIR каталога(например, в структуре данных справочного файла DFVAS), в котором идентификаторы приложений AID распределены по идентификаторам FID тех файлов DFX, в которых в данное время находятся ДУ-приложения.Этот элементарный файл EFDIR должен быть доступен для чтения всем (условие доступа (АС) команды чтения записи READ RECORD: ALW -ВСЕГДА).При загрузке системным оператором ДУ-приложения А, имеющего собственный идентификатор РIХA, в свободный (неиспользуемый) справочный файл DFX, т.е. при внесении записей в имеющиеся элементарные файлы данного справочного файла DFX (не при создании нового файла командой CREATE FILE) должна существовать возможность, используя команду обновления записи UPDATE RECORD,снабдить файл EFDIR расширением в виде записи этого собственного идентификатора РIХA,указывающего идентификатором FIDX на названный справочный файл DFX. Поэтому условие доступа АС команды обновления записиUPDATE RECORD должно обеспечивать внешнюю идентификацию ключом KSO.При передаче чип-карте команды выбора файла SELECT FILE РIХA после предварительного выбора справочного файла DFVAS структуры данных должна быть возможность прямого выбора того справочного файла DFX,в который загружено ДУ-приложение А.При удалении на сервисном терминале по желанию владельца чип-карты ДУ-приложения А, загруженного в справочный файл DFX и в расположенные под ним элементарные файлы,соответствующие файлы не стирают командой удаления файла DELETE FILE, а лишь записывают сверху фиктивные значения. После этого должна быть возможность удалить запись РIХA из файла EFDIR (точнее, пару, состоящую из собственного идентификатора РIХA и ссылки на справочный файл DFX), например, командой обновления записи UPDATE RECORD с предварительным подтверждением права на внешний доступ с помощью ключа KSO.Поскольку количество справочных файлов DFX неизменно, известно и количество записей элементарных файлов EFDIR. В случае возможности реализации такого подхода можно сделать следующий вывод:Выбор ДУ-приложения командой выбора файла SELECT PILE РIХA сразу же после выбора справочного файла DFVAS структуры данных ДУ-контейнера возможен. Второй случай: доступ в элементарный файл EFDIR невозможен. При отсутствии в платформе чип-карты файла EF-DIR, или при отсутствии описанной в предыдущем разделе возможности доступа в этот файл с правом чтения и записи, в справочном файле DF-VAS структуры данных ДУконтейнера должен присутствовать элементар 45 ный файл EFVASDIR, в котором системный оператор подаваемыми в явном виде командами обновления записи UPDATE RECORD (после предварительного подтверждения права на внешний доступ ключом KSO) устанавливает связь собственного идентификатора РIХA загруженных ДУ-приложений с их физическим местонахождением в памяти в справочном файлеDFX. Должна существовать возможность чтения и удаления записей из файла EFVASDIR аналогично предыдущему описанию. Операция ввода ДУ-приложения проходит в следующей последовательности: ДУ-приложение А с собственным идентификатором РIХA приложения предварительно загружают в свободный справочный файлDFX, имеющий идентификатор FIDDFX. Сервисный терминал отмечает номер записи с идентификатором FIDDFX файла. Затем следуют команды: 1. ВЫБОР ФАЙЛА: SELECT FILE АIDVAS (Сообщение об ошибке при невозможности произвести выбор контейнера). 2. ВЫЗОВ СЛУЧАЙНОГО ЧИСЛА ЧИПКАРТЫ: GET CHALLENGE 3. ВНЕШНЯЯ ИДЕНТИФИКАЦИЯ: EXTERNAL AUTHENTICATE KSO (случайное число), KID из KSO 4. ОБНОВЛЕНИЕ ЗАПИСИ: UPDATEDFPT или DFAD могут быть удалены только на сервисных терминалах (поскольку находятся в распоряжении системного oператора) по желанию владельца чип-карты, ДУ-приложения класса реализации EF-TRANSFER могут быть удалены где угодно и кем угодно. При удалении следует различать ДУ-приложения классов реализации DFPT и DFAD и, соответственно,класса реализации ERTRANSFER. Удаление подобного ДУ-приложения, относящегося к классу реализации DFPT илиDFAD производят в следующем порядке: 1. Владелец чип-карты вставляет ДУ-чипкарту в сервисный терминал. 2. Сервисный терминал проверяет наличие ДУ-контейнера, используя следующие команды:ВЫБОР ФАЙЛА: SELECT FILEAIDVAS (Сообщение об ошибке при невозможности произвести выбор контейнера).ЧТЕНИЕ ЗАПИСИ: READ RECORDEFID (считывание идентификатора ДУконтейнера). 3. Сервисный терминал предоставляет владельцу чип-карты на выбор насколько дополнительных вариантов. Одним из них является"Удаление ДУ-приложения". Владелец чипкарты выбирает его. Затем сервисный терминал запускает операцию 46 все ДУ-приложения всех классов реализации,загруженные в ДУ-контейнер, и ждет его выбора. Владелец чип-карты выбирает ДУприложение А из класса реализации DFPT илиDFA. 4. После выбора объекта DFA сервисный терминал подтверждает свое право доступа следующими командами:ВЫБОР ФАЙЛА: SELECT FILE РIХAВЫЗОВ СЛУЧАЙНОГО ЧИСЛА ЧИПКАРТЫ: GET CHALLENGEВНЕШНЯЯ ИДЕНТИФИКАЦИЯ: EXTERNAL AUTHENTICATE KSO (случайное число), KID из KSO 5. Затем из объекта, справочного файлаDFA, удаляют содержимое файлов (для элементарных файлов RFKEY, EFINTERNAL иEFVALUE необходим ключ КLVASP, поэтому системный оператор сначала удаляет его), используя следующие команды:ОБНОВЛЕНИЕ КЛЮЧА: UPDATE KEYDFA, "0000"ОБНОВЛЕНИЕ ЗАПИСИ: UPDATE RECORD SFI файла EFINTERNAL из файла (каталога) DFA, "0000"ОБНОВЛЕНИЕ ЗАПИСИ: UPDATE RECORD SFI файла EFVALUE из файла (каталога) DFA, "0000" 6. После успешной записи информации в элементарные файлы (EF) сервисный терминал в завершение удаляет введенные данные ДУприложения из файла EFDIR, используя следующие команды:ВЫБОР ФАЙЛА: SELECT FILEAIDVAS (Сообщение об ошибке при невозможности произвести выбор контейнера).ОБНОВЛЕНИЕ ЗАПИСИ: UPDATE RECORD SFI файла EFDIR из файла (каталога)DFVAS, номер записи с FIDDFA, "0000",FIDDFA . В результате связь идентификатора РIХA загруженного ДУ-приложения с объектом,справочным файлом DFA прерывается и выполнение команды выбора файла SELECT FILE с использованием идентификатора РIХA становится в итоге невозможным. Рассмотрим теперь удаление ДУприложения класса реализации EFTRANSFER. В соответствии с нормами (RR) удаление ДУ-приложения класса реализацииEFTRANSFER должно быть возможно только по выраженному в явном виде пожеланию владельца чип-карты на торговом или на сервисном терминале (даже если с технической точки зрения это было бы возможно сделать на обоих терминалах). В частности, удаление объекта из класса реализации EFTRANSFER бывает необходимо в том случае, когда в памяти для пересылаемых данных не остается больше места для размещения нового объекта (например, талона или квитанции). Удаление производят всегда напрямую с помощью вспомогательной команды выборки TAKE. Данная команда лишь маркирует какой-либо объект как удаленный, позволяя перезаписывать его с помощью последующей вспомогательной команды передачи данных TRANSFER. Удаление названного ДУприложения производят в следующем порядке: 1. Владелец чип-карты вставляет ДУ-чипкарту в терминал, который может показать содержимое класса реализации EFTRANSFER(Особый случай операции "Просмотр ДУприложений). 2. Сервисный терминал проверяет наличие ДУ-контейнера, используя следующие команды:ВЫБОР ФАЙЛА: SELECT FILEAIDVAS (Сообщение об ошибке при невозможности произвести выбор ДУ-контейнера).ЧТЕНИЕ ЗАПИСИ: READ RECORDSFI из EFID, 0 (считывание идентификатора ДУ-контейнера). 3. Сервисный терминал предоставляет владельцу чип-карты на выбор насколько дополнительных вариантов. Одним из них является"Удаление ДУ-приложения". Владелец чипкарты выбирает его. Затем сервисный терминал запускает операцию"Просмотр ДУприложений", показывая владельцу чип-карты,по меньшей мере, ДУ-приложения класса реализации EFTRANSFER, и ждет его выбора. Владелец чип-карты выбирает объект этого класса реализации, содержащий талон, соответственно квитанцию. Допустим, что объект имеет номер записи приложения А. Владелец чипкарты подтверждает свой выбор. 4. Терминал маркирует запись с номером приложения А как удаленную, передавая номер приложения А, вычисленное им случайное число, его собственный идентификатор PIX и идентификатор (ID) терминала с помощью команды выборки TAKE:ВЫБОРКА: TAKE А, случайное число,PIX, ID терминала. Теперь помеченная как удаленная запись снова готова принять данные нового талона или квитанции. Ниже описана последовательность операций при выборе ДУ-приложения. Если ДУ-приложение А классов реализации DFPT или DFAD было загружено в ДУконтейнер операцией"Загрузка ДУприложения", то выбор его терминалом может 48 происходить в две стадии. Вначале происходит выбор ДУ-контейнера, а затем выбор ДУприложения с его собственным идентификатором РIХA с использованием следующих команд: 1. ВЫБОР ФАЙЛА: SELECT FILE АIDVAS (Сообщение об ошибке при невозможности произвести выбор контейнера). Сервисный терминал может проверить действительность ДУ-контейнера. С этой целью сервисный терминал затребует внутреннюю идентификацию ДУ-контейнера, используя команды:ЧТЕНИЕ ЗАПИСИ: READ RECORDINTERNAL AUTHENTIVICATE случайное число, KID из КAUT Сервисный терминал проверяет ответ и прекращает операцию при неправильном ответе(Сообщение об ошибке, если ДУ-приложение А не загружено в ДУ-контейнер). Торговый терминал (не имеющий ключа формирования ключей KGKAUT) может косвенно проверить действительность ДУконтейнера путем проверки действительности ДУ-приложения А. Дело в том, что ДУприложение могло быть загружено только на сервисном терминале, проверившем в процессе загрузки действительность ДУ-контейнера. Проверка действительности ДУ-приложения А может быть сведена к проверке торговым терминалом того, имеет ли ДУ-контейнер ключKLVASP или KRVASP к ДУ-приложению А. Торговый терминал может проверить это, например, с помощью команды:ВНУТРЕННЯЯ ИДЕНТИФИКАЦИЯ:KRVASP Чтобы проверить, загружено ли ДУприложение А в ДУ-контейнер, можно попробовать выбрать его; ответное сообщение об ошибке после команды выбора файла SELECTFILE будет указывать на его отсутствие. Выбор ДУ-приложения класса реализацииEFTRANSFER происходит в неявном виде в результате выполнения операции "Просмотр ДУ-приложений" и запоминания данных в терминале. Пoскольку терминал знает номер записи каждого показываемого объекта из класса реализации EFTRANSFER, с помощью номера записи путем ссылки на этот номер можно выбрать любой объект для его дальнейшей обработки. Ниже описан порядок просмотра ДУприложения. При операции "Просмотр ДУ-приложений" сервисный терминал показывает перечень всех ДУ-приложений, относящихся к классам реали 49 зации DFPT, DF-AD и EFTRANSFER. Торговый терминал может показывать только ДУприложения класса реализации EFTRANSFER,поскольку для них не существует защиты от доступа, и, факультативно, приложения класса реализации DFPT, соответственно DFAD, на которые торговый терминал имеет права чтения(владеет ключом KRVASP). Порядок просмотра ДУ-приложения: 1. Владелец чип-карты вставляет в терминал ДУ-чип-карту (чип-карту с действительным ДУ-контейнером). 2. Сервисный терминал проверяет наличие ДУ-контейнера, используя следующие команды:ВЫБОР ФАЙЛА: SELECT FILE АIDVAS (Сообщение об ошибке при невозможности произвести выбор контейнера).ЧТЕНИЕ ЗАПИСИ: READ RECORDSPI из EFID, 0 (считывание идентификатора ДУ-контейнера). Факультативно терминал проверяет действительность ДУ-контейнера. Для этого сервисный терминал требует внутренней идентификации ДУ-контейнера, используя команду:ВНУТРЕННЯЯ ИДЕНТИФИКАЦИЯ:INTERNAL AUTHENTIVICATE случайное число, KID из КAUT Сервисный терминал проверяет ответ и прекращает операцию при неправильном ответе(с сообщением об ошибке). 3. Сервисный терминал предоставляет владельцу чип-карты на выбор несколько дополнительных вариантов. Один из них называется"Просмотр ДУ-приложений". Владелец чипкарты выбирает его. 4. Сервисный терминал подтверждает свое право на доступ следующими командами:ВЫЗОВ СЛУЧАЙНОГО ЧИСЛА ЧИПКАРТЫ: GET CHALLENGEВНЕШНЯЯ ИДЕНТИФИКАЦИЯ: EXTERNAL AUTHENTICATE KSO (случайное число), KID из KSO 5. У ДУ-приложений классов реализацииDFPT и DFAD происходит управляемый по содержанию элементарного файла EFDIR каталога последовательный выбор одного за другим отдельных ДУ-приложений и, после подтверждения права на внешний доступ ключомKSO, показ содержимого отдельных элементарных файлов EFINFO (или их части в соответствии с нормативной базой RR), а также элементарного файла EF VALUE. При этом используют следующие команды: При i = 0, , nrDIR - 1 используют команду:ЧТЕНИЕ ЗАПИСИ: READ RECORDSFI из EFID, i Ответное сообщение содержит собственный идентификатор РIХA приложения, равный"0000", если в соответствующий справочный файл DF не загружено никакого ДУприложения. В качестве альтернативы командеREAD RECORD чтения записи из элементарно 001837 50 го файла EFDIR каталога в определенных случаях может быть использована и команда поиска SEEK. При РIХA не равном "0000" используют команды:ВЫБОР ФАЙЛА: SELECT FILE РIХAЧТЕНИЕ ЗАПИСИ: READ RECORDEFTRANSFER производят считывание содержания (или его части в соответствии с нормами(Ответное сообщение передает содержание имеющей порядковый номер i записи вEFTRANSFER)При наличии содержания его показывают в интерпретированном виде (например, "данные считаны"/"срок хранения истек"). Просмотр приложений класса реализацииDFPT, соответственно DFAD, по отношению к которым торговый терминал имеет права чтения (владеет ключом KRVASP) происходит согласно приведенному описанию, но с двумя отличиями: для подтверждения права внешнего доступа вместо ключа KSO, которым владеет только системный оператор, используют ключKRVASP. Если торговый терминал не имеет ключа формирования ключей KGKAUT, но, тем не менее, хотел бы проверить действительность ДУ-приложений, то этот торговый терминал вместо внутренней идентификации может потребовать идентификации (по меньшей мере одного) ДУ-приложения. Эта проверка основана, как уже говорилось, на знании чип-картой соответствующего ключа KRVASP или KLVASP. У ДУ-приложений класса реализацииEFTRANSFER идет последовательное, описанное выше перечисление содержания (или его части согласно нормам RR) одной за другой каждой записи EFTRANSFER. Операция"Интерпретация ДУприложений" проходит аналогично описанному выше. Для этой цели терминал предоставляет владельцу чип-карты на выбор дополнительный вариант "Интерпретация ДУ-приложений". В дополнение к визуально представляемой при операции просмотра информации, могут быть представлены данные из элементарных файловEFINFO и EFVALUE, нуждающиеся в интер 51 претации провайдера (например, данные, закодированные извне), и данные из элементарного файла EFINTERNAL (например, количество миль, набранное за прошлые годы для получения скидок по системе MilesMore). Указанная операция возможна, однако, лишь для тех ДУ-приложений, для которых провайдер (по своему собственному усмотрению) предоставит на терминале соответствующие ключи. Для чтения элементарного файла EFINTERNAL ДУприложения необходим ключ KLVASP (подтверждение права на доступ извне). Для закодированных извне данных внутри элементарных файлов EFINFO, EFINTERN и EFVALUE, а также памяти для пересылаемых данныхEFTRANSFER необходимы соответствующие ключи провайдера. Программа терминала на основании собственного идентификатора PIX выбранного ДУ-приложения может легко решить, для каких приложений есть ключи для интерпретации данных. Операция "Передача ДУ-приложений" означает передачу на сервисном терминале всех или выбранных ДУ-приложений с исходной чип-карты в чип-карту назначения. При этом необходимо, чтобы в ДУ-контейнере чип-карты назначения не было загруженных ДУприложений и, чтобы после передачи происходило удаление всех ДУ-приложений из исходной чип-карты. И то, и другое может быть достигнуто путем последовательного применения операции "Удаление ДУ-приложения". Кроме того, должна быть проверена действительность ДУ-чип-карт, а чип-карты назначения должны иметь достаточно места в памяти. Сама операция передачи приложений базируется в основном на расширении операции "Просмотр ДУприложений" за счет дополнительного считывания данных из элементарного файлаEFINTERNAL и ключей KLVASP и KRVASP и многократного применения операции "Загрузка ДУ-приложения". Вместе с ДУ-данными в чип-карту назначения переходит и идентификатор (ID) ДУконтейнера для того, чтобы ДУ-приложения вели себя в чип-карте назначения точно так же,как и в исходной чип-карте. Причина такого решения состоит в том, что формируемые провайдером производные ключи, основывающиеся на идентификаторе (ID) ДУ-контейнера, при копировании не изменяются. Кроме того, провайдер не хочет менять ведение учета в работающей в фоновом режиме системе, поскольку он обычно идентифицирует ДУ-чип-карты по ДУ-контейнерам. Необходимо обязательно следить за тем, чтобы при передаче идентификатора (ID) ДУ-контейнера происходило удаление этого однозначно определенного во всей системе номера из исходной чип-карты. Для того, чтобы иметь возможность читать, в особенности, элементарный файл 52 висный терминал после проверки права на доступ извне ключом KSO (аналогично операции"Удаление ДУ-приложения") сначала перезаписывает ключи КLVASP, благодаря чему он может после повторной проверки права на доступ ключом КLVASP пересылать данные из элементарного файла EFINTERNAL. Кроме ДУ-приложений классов реализации DFPT и DFAD необходимо пересылать файл EFTRANSFER. Для этого операцией"Выборка" последовательно удаляют один за другим объекты этого класса, не отмеченные еще как удаленные или как объекты с истекшим сроком хранения, их сигнатуру проверяют ключом КSIGVASC и пeредают в файл EFTRANSFER чип-карты назначения. Однако в чип-карте назначения эти объекты помечают как не взятые,чтобы они продолжали оставаться действительными. В заключение необходимо еще передать глобальные данные ДУ-контейнера. В частности, счетчик порядковых номеров чип-карты назначения должен быть выставлен на значение исходной чип-карты. Ниже описан способ ввода ДУ-данных. Существует три возможных случая ввода ДУ-данных на торговом терминале в зависимости от типа ДУ-приложений. Вначале будет рассмотрено приобретение данных в случае, относящемся к классам реализации DFPT или DFAD. Провайдеру нужно записать данные в ДУприложение А класса реализации DFPT илиDFAD. Порядок ввода ДУ-данных: 1. Владелец чип-карты вставляет ДУ-чипкарту в торговый терминал. 2. Торговый терминал проверяет наличие ДУ-контейнера, используя следующие команды:ВЫБОР ФАЙЛА: SELECT FILEAIDVAS (Сообщение об ошибке при невозможности произвести выбор контейнера).ЧТЕНИЕ ЗАПИСИ: READ RECORD(ID) ДУ-контейнера). 3. Проверка действительности ДУконтейнера. Если торговый терминал не имеет сам ключа формирования ключей КGКAUT, он может потребовать у ДУ-контейнера внутренней идентификации:ВНУТРЕННЯЯ ИДЕНТИФИКАЦИЯ:INTERNAL AUTHENTIVICATE случайное число, KID из КAUT Торговый терминал (не имеющий ключа формирования ключей КGКAUT) может косвенно проверить действительность ДУ-контейнера путем проверки действительности ДУприложения А. Дело в том, что ДУ-приложение могло быть загружено только на сервисном терминале, проверившем в процессе загрузки действительность ДУ-контейнера. Проверка действительности ДУ-приложения А может 53 быть сведена к проверке торговым терминалом того, имеет ли ДУ-контейнер ключ КLVASP илиKRVASP к ДУ-приложению А. Торговый терминал может проверить это, например, с помощью команд:ВЫБОР ФАЙЛА: SELECT FILE РIХAINTERNAL AUTHENTIVICATE случайное число, KID из КLVASP или KRVASP Торговый терминал проверяет ответ и прекращает операцию при неправильном ответе (с сообщением об ошибке). 4. Торговый терминал выбирает ДУприложение А, идентифицирует себя и описывает элементарные файлы, необходимые для проведения транзакции, используя следующие команды:ВЫБОР ФАЙЛА: SELECT FILE РIХA(если эта команда уже была выполнена на шаге 3 программы, ее не используют)ВЫЗОВ СЛУЧАЙНОГО ЧИСЛА ЧИПКАРТЫ: GET CHALLENGEВНЕШНЯЯ ИДЕНТИФИКАЦИЯ: EXTERNAL AUTHENTICATEKLVASP (случайное число), KID из КLVASPФакультативно: ОБНОВЛЕНИЕ ЗАПИСИ: UPDATE RECORD SFI файла EFINFO из файла (каталога) DFX, данныеФакультативно: ОБНОВЛЕНИЕ ЗАПИСИ:EFINTERNAL из файла (каталога) DFX, данныеФакультативно: ОБНОВЛЕНИЕ ЗАПИСИ: UPDATE RECORD SFI файла EFVALUE из файла (каталога) DFX, данные Следующий случай представляет собой приобретение данных в классе реализации"Талон") провайдеру не требуется занимать под свое приложение никакой собственной структуры файлов DFX. Благодаря такому решению владелец чип-карты не должен перед использованием ДУ-приложения "Талон" идти к сервисному терминалу для загрузки ДУ-приложения. Вместо этого он может непосредственно на торговом терминале приобрести талон или квитанцию и получить за них компенсацию на другом терминале (с помощью операции выборки), или просто лишь предъявить этот талон, соответственно квитанцию (с помощью операции чтения). Таким образом, в результате ввода ДУданных в неявном виде происходит загрузка ДУ-приложений класса реализацииEFTRANSFER. Для этого класса приложений существует класс реализации EFTRANSFER,состоящий из отдельных объектов, имеющих вид записей. Ввод данных в EFTRANSFER возможен исключительно с помощью команды 54 передачи данных TRANSFER. Для этого торговый терминал должен обладать действительным ключом погашения КDEC и иметь собственный идентификатор РIХA ДУ-приложения А. Порядок ввода ДУ-данных: 1. Владелец чип-карты вставляет ДУ-чипкарту в торговый терминал. 2. Торговый терминал проверяет наличие ДУ-контейнера, используя следующие команды:ВЫБОР ФАЙЛА: SELECT PILE AID (Сообщение об ошибке при невозможностиSFI из EFID, 0 (считывание номера ДУконтейнера). 3. Торговый терминал считывает порядковый номер, дополнительно включаемый в код идентификации сообщения (МАC) из шага 4 программы:ЧТЕНИЕ ЗАПИСИ: READ RECORDSFI из EFSEQ, 0 (считывание порядкового номера). 4. Командой передачи данных TRANSFER в элементарный файл EFTRANSFER вводят запись:ПЕРЕДАЧА ДАННЫХ: TRANSFER дата транзакции, дата окончания срока хранения,код формирователя, данные, собственный идентификатор (РIХA) приложения, код идентификации сообщения (МАC) с ключом KDЕС 5. Проверкой ответного сообщения команды передачи данных TRANSFER торговый терминал может проконтролировать действительность ДУ-контейнера (владеет ли тот совместным секретом ключа KDEC). На эту тему см. приведенное выше описание ответного сообщения команды TRANSFER. В заключение об операции приобретения ДУ-данных путем операции погашения. Провайдер может с помощью операцииTRANSFER сформировать в поле передачи данных элементарного файла EF-TRANSFER право(в виде, например, талона или квитанции), которым может в дальнейшем воспользоваться другой провайдер. Погашению подвергают данные из элементарного файла EFVALUE, соответственно EFINFO ДУ-приложения А производящего погашение провайдера. Владелец чипкарты получает это право в виде объекта в элементарном файлеEFTRANSFER. Порядок ввода ДУ-данных: 1. Владелец чип-карты вставляет ДУ-чипкарту в торговый терминал. 2. Торговый терминал проверяет наличие ДУ-контейнера, используя следующие команды:ВЫБОР ФАЙЛА: SELECT FILE AID (сообщение об ошибке при невозможностиSFI из EFID, 0 (считывание идентификатора ДУ-контейнера). 3. Торговый терминал считывает порядковый номер с дополнительно включенным в него кодом идентификации сообщения (МАC) из шага 4 программы:ЧТЕНИЕ ЗАПИСИ: READ RECORDSFI из EFSEQ, 0 (считывание порядкового номера ДУ-контейнера). 4. Торговый терминал выбирает ДУприложение А:ВЫБОР ФАЙЛА: SELECT FILE РIХA(Сообщение об ошибке, если ДУ-приложение А не загружено в ДУ-контейнер). 5. Торговый терминал использует команду передачи данных TRANSFER для погашения данных из файла EFVALUE, соответственно из файла EFINFO:ПЕРЕДАЧА ДАННЫХ: TRANSFER данные, код идентификации сообщения (МАC) с ключом KDEC Состав командного сообщения команды передачи данных TRANSFER уже описан выше. Право на операцию погашения терминал получает в том случае, когда он может с помощью ключа КDEC сформировать по данным правильную сигнатуру, проверяемую ДУ-контейнером. В положительном случае ДУ-контейнер создает в элементарном файле класса реализацииEFTRANSFER запись и увеличивает на одну единицу порядковый номер. 6. Проверкой ответного сообщения команды передачи данных TRANSFER торговый терминал может проконтролировать действительность ДУ-контейнера (владеет ли тот совместным секретом ключа КDEC). И, наконец, необходимо описать еще способ погашения ДУ-данных. Существуют два вида операции погашения. Во-первых, данные ДУ-приложений класса реализации DFPT или DFAD могут быть погашены соответствующим провайдером с помощью операции "Погашение", т.е. путем приобретения ДУ-данных через погашение. В результате происходит использование одного значения (стоимости) и при этом возникает потенциальное право на следующее значение (стоимости). Во-вторых, данные могут быть однократно взяты из элементарного файла класса реализации EFTRANSFER с помощью вспомогательной команды выборки TAKE. В этом случае право считают использованным, данные остаются для их возможного дальнейшего использования (например, билет после компенсации стоимости проезда бывает все еще нужен для обратной поездки) в поле передачи данных с пометкой считанных до тех пор, пока их не перезапишут при необходимости другими объектами. 56 Порядок погашения ДУ-данных командой выборки TAKE: 1. Владелец чип-карты вставляет ДУ-чипкарту в торговый терминал. 2. Торговый терминал проверяет наличие ДУ-контейнера, используя следующие команды:ВЫБОР ФАЙЛА: SELECT FILEAIDVAS (Сообщение об ошибке при невозможности произвести выбор контейнера).ЧТЕНИЕ ЗАПИСИ: READ RECORDSFI из EFID, 0 (считывание идентификатора ДУ-контейнера). 3. Вначале торговый терминал с помощью специального варианта операции "Просмотр ДУ-данных" считывает имеющиеся объекты из элементарного файла класса реализацииEFTRANSFER с целью определить наличие искомого объекта. В альтернативном варианте можно производить поиск, используя команду поиска SEEK в определенной комбинации. В случае успеха терминал определяет номер i искомой записи. 4. Терминал помечает запись с номером i как удаленную, передавая номер i, вычисленное им случайное число, ее собственный идентификатор (PIX) приложения и идентификатор (ID) терминала командой выборки TAKE:ВЫБОРКА: TAKE i, случайное число,PIX, ID терминала. Торговый терминал использует команду выборки TAKE для считывания данных из элементарного файла класса реализацииEFTRANSFER, одновременно помечая эти данные кодом выборки. Выполнение указанной команды дополнительно приводит к формированию двух различных криптограмм C1 и С 2. Криптограмму С 1 рассчитывает ДУконтейнер с помощью ключа KSIGVASC. С ее помощью пользователь, предъявляющий взятый с пометкой C1 объект, может получить у системного оператора подтверждение его действительности и одноразовости его передачи. Действительность и одноразовость транзакции определяют на основании криптограммы провайдера, от которого исходит данный объект (и которая была проверена чип-картой, см. описание команды передачи данных TRANSFER) и показаний счетчика порядковых номеров транзакций, а также криптограммы C1, вычисляемой чип-картой при выборке. Криптограмму С 2 вычисляет ДУконтейнер, используя производный ключ КDEC,полученный на основании ключа формирования ключей KGKDEC, собственного идентификатора(PIX) приложения и идентификатора (ID) терминала. Зная совместный секрет ключа КDEC,ДУ-контейнер может напрямую подтверждать терминалу свою действительность. Поскольку при выполнении команды передачи данныхTRANSFER проверяют также, чтобы в память действительного ДУ-контейнера вводились только действительные талоны, соответственно 57 квитанции, на основании этой информации можно делать вывод о действительности взятого объекта. В связи с тем, что криптограмму С 2 косвенно формируют на основании порядкового номера, разряда/бита кода выборки и идентификатора (ID) ДУ-контейнера, ДУ-контейнер может даже подтвердить терминалу однократность выборки объекта. Право на выборку с использованием команды выборки TAKE имеют все. Кроме того, сервисный терминал предоставляет возможность деактивизации, соответственно активизации использующей пароль или ПИН защиты чтения ДУ-приложений классов реализации DFPT и DFAD. Помимо этого владелец чип-карты может, зная пароль или ПИН-код, изменять его, а системный оператор может возвращать его в исходное состояние,используя подтверждение ключом KSO права на внешний доступ. В качестве ПИН-кода или пароля могут быть использованы и нецифровые знаки или цепочки знаков произвольной длины. ФОРМУЛА ИЗОБРЕТЕНИЯ 1. Чип-карта, служащая для проведения транзакций, при которых единицы денежной стоимости или иные, выражающие не финансовые требования/права цифровые данные передают между владельцем чип-карты и, по меньшей мере, одним партнером по транзакции(провайдером) или предъявляют провайдеру для удостоверения этих требований/прав, причем чип-карта имеет память, хранящую необходимые для проведения указанных транзакций данные, отличающаяся наличием следующих средств:- устройства для загрузки в чип-карту одного или нескольких соответствующих в каждом случае определенному провайдеру приложений чип-карты (ДУ-приложений), каждое из которых позволяет проводить транзакции между владельцем чип-карты и тем провайдером,которому выделено это приложение,- не являющейся для провайдера собственной области памяти для пересылаемых данных(EFTRANSFER), предназначенная для размещения обмениваемых или предъявляемых при проведении транзакций между различными провайдерами данных, представляющих единицы денежной стоимости или нефинансовые требования/права, и- устройства для записи данных в память для пересылаемых данных в ответ на команду записи/передачи данных (TRANSFER). 2. Чип-карта по п.1, у которой устройство для загрузки имеет следующие компоненты: хранящаяся внутри структура данных 58 которую могут быть загружены данные (ДУданные), необходимые для обеспечения возможности проведения транзакции между владельцем чип-карты и провайдером;(KSO), защищающий целостность записи описания данных и/или структуру данных (ДУконтейнер) от модификаций. 3. Чип-карта по любому из пп.1 или 2, отличающаяся тем, что она, помимо этого, имеет,по меньшей мере, один из следующих отличительных признаков:- устройство для загрузки необходимых для проведения транзакций данных в подструктуру с использованием, по меньшей мере, одного системного ключа;- устройство для ввода данных в запись описания данных с целью согласования данных этой записи с загруженными в подструктуру данными;- устройство для формирования в памяти чип-карты еще одной подструктуры, в которую могут быть загружены необходимые для проведения транзакции данные, и/или- устройство для динамического управления памятью в чип-карте. 4. Чип-карта по любому из предыдущих пунктов, отличающаяся тем, что: в случае с подструктурами (ДУприложениями) речь идет о независимых друг от друга подструктурах, выделенных в каждом случае одному определенному провайдеру,запись описания данных защищена от модификаций, по меньшей мере, одним системным ключом (KSO) и может быть изменена только посредством этого ключа, и тем, что загрузку подструктур (ДУ-приложений) можно производить только с использованием имеющегося в записи описания данных системного ключа. 5. Чип-карта по любому из предыдущих пунктов, отличающаяся далее тем, что запись описания данных имеет, по меньшей мере, один из следующих отличительных признаков:- по меньшей мере, один идентифицирующий ключ (КAUT) для проверки права доступа чип-карты по отношению к терминалу и/или для проверки права доступа терминала по отношению к чип-карте;- по меньшей мере, один маркирующий ключ (КSIGVASC) для маркировки данных, взятых из памяти для пересылаемых данных;- ключ формирования ключей (KGKDEC) для формирования специфических ключей тер 59 миналов и приложений, предназначенных для проверки права на запись данных в память для пересылаемых данных и/или для погашения цифровых данных;- персональный идентификационный номер (ПИН) для верификации владельцем чипкарты права на транзакцию; а также тем, что системный ключ (KSO),идентифицирующий ключ (КAUT), маркирующий ключ (KSIGVASC) и ключ формирования ключей (KGKDEC) являются индивидуальными ключами чип-карт или специфическими ключами структуры данных (DFVAS),и тем, что подструктура (ДУ-приложение) имеет, по меньшей мере, один из следующих отличительных признаков:(EFVALUE) для хранения цифровых данных;(EFINTERNAL) для хранения внутренних данных по подструктуре;(EFINFO) для хранения информационных, не внутренних данных по подструктуре;(КLVASP, KRVASP), защищающих процессы записи данных в раздел и/или считывания данных из раздела памяти для цифровых данных, и/или раздела памяти для внутренних данных, и/или раздела памяти для информационных данных, и тем, что чип-карта включает далее:- устройство для записи данных в раздел и/или считывания данных из раздела памяти для цифровых данных, раздела памяти для внутренних данных и раздела памяти для информационных данных,и тем, что устройство загрузки включает:- устройство для записи ключей в раздел памяти для хранения ключей под защитой, по меньшей мере, одного системного ключа. 6. Чип-карта по любому из предыдущих пунктов, отличающаяся тем, что подструктура имеет, по меньшей мере, один из следующих отличительных признаков:- ключ (КLVASP) для проверки права записи данных в подструктуру;- ключ (KRVASP) для проверки права считывания данных из подструктуры. 7. Чип-карта по любому из предыдущих пунктов, отличающаяся тем, что раздел памяти для хранения ключей хранит для каждой подструктуры свой специфический ключ, и тем,что, по меньшей мере, одна подструктура (ДУприложение) обеспечивает проведение транзакций посредством, по меньшей мере, одного из специфических ключей (KLVASP, KRVASP), каждый из которых специфичен для соответствующей подструктуры (ДУ-приложения) и не зависит от ключей других подструктур (ДУприложений). 60 8. Чип-карта по любому из предыдущих пунктов, отличающаяся тем, что эта чип-карта имеет несколько подструктур (ДУ-приложений),служащих соответственно для проведения транзакций между определенными провайдерами и владельцем чип-карты, и тем, что проведение транзакций включает запись данных в поле,и/или считывание данных из поля передачи данных, и/или запись данных в раздел, и/или считывание данных из раздела памяти для цифровых данных. 9. Чип-карта по любому из предыдущих пунктов, отличающаяся тем, что она, кроме того, включает: устройство для проведения транзакций как между отдельными подструктурами (ДУприложениями), так и между одной подструктурой и одним провайдером. 10. Чип-карта по любому из предыдущих пунктов, отличающаяся тем, что:- системный ключ (KSO) известен только владельцу системы (системному оператору, СО) и является индивидуальным ключом чип-карты и/или специфическим ключом структуры данных (ДУ-контейнера),и тем, что другие ключи, содержащиеся в записи описания данных, являются индивидуальными ключами чип-карты и/или специфическими ключами структуры данных (ДУконтейнера). 11. Чип-карта по любому из предыдущих пунктов, отличающаяся тем, что запись описания данных имеет один или несколько следующих отличительных признаков:- каталог содержащихся в структуре данных подструктур (EFDIR), при этом указанный каталог содержит специфические идентификационные номера загруженных в структуру данных(ДУприложений), а также информацию о той части структуры данных (ДУ-контейнера), в которой физически хранятся эти подструктуры (ДУприложения);- номер версии структуры данных(EFVERSION). 12. Чип-карта по любому из предыдущих пунктов, отличающаяся наличием, по меньшей мере, одного из следующих отличительных признаков:- устройство для проведения процесса выборки (Take), обеспечивающее выборку и погашение данных, содержащихся в памяти для пересылаемых данных;- устройство формирования одного или нескольких признаков действительности данных при выборке, соответственно при погашении данных, содержащихся в памяти для пересылаемых данных. 13. Чип-карта по любому из предыдущих пунктов, отличающаяся тем, что указанная чип