BG63233B1 - Чип-карта и метод за използване на чип-картата - Google Patents

Abstract

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

Description

(54) ЧИПКАРТА И МЕТОД ЗА ИЗПОЛЗВАНЕТО Й

Област на техниката

Изобретението се отнася до чипкарта, терминал за използване с чипкарта и метод за използване на чипкартата, както и чипкартна система.

Предшестващо състояние на техниката

Микропроцесорните чипкарти, имащи платежна функция (за разплащане), т.е електронен портфейл, налични парични средства, кредитна функция и т.н., са в процес на внедряване и в зависимост от тяхното естество са поставени предварителни условия от организациите, като например ZKA (Zentraler Kreditausschuss), VISA или EMV (Europav Mastercard VISA), така че те могат да бъдат използвани като средство за разплащане (заменящо наличните пари), както е посочено в с следните литературни източници:

ZKA, Zentraler Kreditausschuss, “interaction specification for the ec-card with chip”, 27.10.1995;

Europay International, “Integrated Circuit Card, Specification of Payment Systems, EMV’96”, V3.0, 30-Jun-1996;

ISO/IEC 7816-4, ‘Information technology

- Identification cards - Integrated circuit(s) cards with contacts, Part 4: Interindustry commands for interchange”, 01-09-1995;

prEN 1546-1, “Identification card systems

- Inter-sector electronic purse, Part 1: Definitions, concepts and structures”. 15.03.1995;

prEN 1546-2, “Identification card systems

- Inter - sector electronic purse, Part 2: Securin’ architecture”, 03.07.1995;

prEN 1546-3, “Identification card systems

- Inter-sector electronic purse, Part 3: Data elements and interchanges”, 09.12.1994.

Съвременен обзор за чип-карти може да се намери в лит.източник

Stefan Schutt, Bert Kohlgraf: “Chipkarten, Technische Merkmale, Normung, Einsatzgebiete”, (“Chip cards, Technical Characteristics, Standards, Fields of Employment”), R. Oldenbourg Verlag, Munich/Vienna, 1996, ISBN 3-486-23738-1.

Традиционните чип-карти са, обикновено, използвани само за отделни цели, напри20 мер като електронни парични средства или като електронни идентификационни (опознавателни) средства. Разбира се, заявките (исканията) , заложени в тези чип-карти , обикнове5 но са постоянни , т.е. те са заложени по време на производството (създаването) на чипкартата и се съхраняват непроменени през целия живот на картата.

Традиционните чипкарти са ограничени 10 от две страни - относно тяхната вариантност, както и относно тяхната функционалност. Поспециално традиционните чип-карти са фиксирани в съответствие с процеса на изготвянето им с оглед на тяхната функционалност и 15 могат да не се променят продължително време.

Същност на изобретението

Съгласно предмета на настоящото изобретение се използва чипкарта, функционалността на която е променлива.

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

Чипкартата трябва, например, да бъде реализирана с данните и технологичните засекретяващи условия (защити) съгласно ISO 7816: индивидуалните приложения на картата трябва, разбира се, да бъдат независими, особено от самата платка на картата.

Допълнителен предмет на изобретението е и да се реализира чипкарта, с която самият ползвател да може да определя (ограничава) или комбинира или променя броя или естеството на заявките, налични в неговата карта.

И още допълнителен предмет на изобретението е да се създаде чипкарта със средства, на която и вътрешните услуги (т.е. затворена, недостъпна вътрешна връзка за заявките, в смисъл на непозволени покупки или обслужващи трансфери (обмени), задължаващи вън2 шии партньори да вземат участие), както и взаимните услуги (т.е. заявки с допълнителни външни свързвания, включващи външни партньори) да са допустими и да могат да бъдат изпълнени.

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

Чрез подобно въвеждане (зареждане) чипкартата е така конфигурирана, че е създадена с нова функционалност, т.е. може да изпълни заявка, която преди не й е била разрешена. Въведената информация (данни) довежда до дефиниране на заявки и до осъществяването им заедно с основните функции на картата, например операционната система, които преди не са били реализирани на картата. В резултат функционалността на картата е разширена с такова въвеждане на заявка чрез това по-специално приложение.

В съответствие с допълнение към изобретението е осъществена информационна структура (DF_VAS) върху чипкартата съгласно изобретението, която последователно е подразделена на отделни структури и дефиниционна информационна мрежа, информационната структура специално се идентифицира чрез средствата на кодовото й идентифициране и е също така независима от платката на картата. Така наречените заявки могат отново да бъдат въведени в отделната структура, т.е. функциите или заявките на чипкартата. В резултат става възможно чрез въвеждане на отделна заявка от чипкартата, да се осъществи сделка между притежателя на картата и изпълнителя на услуга, специфична за тази заявка. Дефинираната информационна мрежа вътре в информационната структура съдържа данни, отнасящи се до естеството и/или съдържанието на заявките, въведени в специалната структура. Най-малко една структура от дефинираната информационна мрежа, за препоръчване обаче цялата информационна структура, са защитени чрез средството на най-малко един системен ключ срещу модификации и могат да бъдат модифицирани само чрез използване на този ключ. Вместо системен ключ друг защитен механизъм, също или защитни средства мо гат да бъдат постигнати чрез средство, за което защитата срещу модификации може да бъде осъществена, например чрез персонален идентификационен номер (PIN) или друго средство, изпълняващо същата защита.

Чрез посочената структура е възможно да се въведат в специалната структура множество заявки и също така да се изтрият (заличат) те още веднъж от специалната структура, чрез което картата става променлива от гледна точка на нейните функции или заявки, което може да бъде осъществено след това.

Въвеждането и изтриването (заличаването) на заявките се осъществява чрез запис на специфична информация за заявката и ключове в реализираната специална структура. Чрез защитата от системния ключ и кодирането на информационната структура, информационната структура, придобивайки мултифункционалност, се е превърнала в независима от платката на картата, например, и също е с поддържащ респект към нейната защитена архитектура и независимост от платката на картата.

В зависимост от заявките, въведени в специалната структура, е възможно тогава чрез средствата на картата да се реализират сделки между притежателя на картата и изпълнителя на услугата, които са зависими от въведените заявки.

За предпочитане е, по-нататък, чипкартата да съдържа област за обмен, в която информацията, обменяна по време на изпълнението на сделките, да може да бъде записана или от която би могло да се чете. По същите причини, заради четенето на информация от областта за обмен са създадени терминални специфични ключове, индивидуалните достъпи са представени независимо един от друг от гледна точка на сигурността (защитата).

Индивидуалните специални структури или заявки за реализиране в картата са, за предпочитане взаимнонезависими и всяка се възлага на специален изпълнител на услуга. Те представляват, така да се каже, информация за осъществяване на специфичната заявка, собствени права или специфични за този изпълнител на заявка. В съответствие с вида на заявката и съобразено с изпълнителя на услугата те за това съдържат различна информация, например данни, представляващи специфични стойности (бонификационни (bonus) точки, пресметнат баланс и т.н.), представящите заявката данни, представящите изпълнителя на услугата данни и т.н. За предпочитане е, разбира се, те в частност да съдържат ключове, които са специфични за заявката, чрез средствата на които достъпът до данните на специфичната структура се оказва възможен по начин, чиято техническа защита е независима от другите специални структури. Въвеждането или създаването на специалните структури или на самата заявка, от друга страна, е защитено чрез наймалко един изключително необходим системен ключ.

За предпочитане е, преди изпълнението на сделка взаимно да се установи автентичност между чипкартата и терминала, а на заявка - съответно специфичния ключ за автентичност на отделната структура, създаден за тази цел.

Възможно е при осъществяване на сделки, информацията, тогава, да бъде записана в специална структура, резервирана за специалните VAS заявки или да бъде четена оттам или сделките да бъдат осъществявани чрез смяната на запомнящата област за обмен. На първо място се използват специфичните ключове на заявката. В последния споменат случай е използван специфичен ключ на заявка и преди всичко, също, терминалният специфичен ключ, който, например, е реализиран чрез средство за създаване на ключ, изпълнено в картата, и от специфичната информация за заявката. Информацията е записана по такъв начин в паметта за обмен на данни, че да може да бъде изтеглена от изпълнителя на заявката чрез терминала, който предимно участва чрез 35 маркиране, когато е невалидна запомнената информация в паметта за обмен на данни. Ако това въвлича изпълнителя на услуга, който не е бил записан специално за операцията, това обърква изпълнението на т. нар. взаимни ус- 40 луги, т.е. данните за паричните средства са обменени между различни изпълнители на услуги заради или за сметка на притежателя на картата.

Освен това, за допълнителна сигурност, 45 е използван PIN или парола за потвърждение на правото за извършване на обменна процедура.

Променливата структура на картата позволява разполагането върху картата в раз- 50 лични времена на множество заявки като множество номера.

Автентичността на изтеглената информация от паметта за обмен е преди всичко защитена чрез използване на сигнатурен ключ или чрез използване на цифрова сигнатура или 5 поне само на ключ. Разбира се, в този контекст има специално предимство, ако изтеглената информация продължи да съществува в паметта за обмен и данните са само заличени, след като са били изтеглени чрез картата. По 10 този начин, от друга страна, е възможно да се получи информация, съдържаща представянето на сделката едва след като сделката е била извършена. По този начин и чрез средство за предпазване от изтегляне на данни се доказ15 ва, че сделката е била извършена само веднъж.

Има, освен това, специално предимство има случая, когато информацията (данните), записана в паметта за обмен, е закодирана 20 със заличени (изчезнали) данни, след което тя загубва своята стойност. Така става възможно да се изпълняват заявките, които, например, объркват осъществяването на възможен достъп, валиден само за специфичен период.

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

Като общо предимство чипкартата съгласно изобретението освен това съдържа йерархична информационна структура, която в индивидуалния си план е защитена чрез средствата на различни ключове срещу модификации и която на нивото на заявките, от гледна точка на защитената заявка в информационната база данни, е променлива, като всяка индивидуална заявка е защитена относно останалата част чрез собствения й специфичен ключ и е независима от останалата част, а общата структура е защитена най-малко чрез една система от ключове и чрез ключово идентифициране на структурата и е независима от платката на картата сама за себе си. Структурата на паметта за обмен позволява взаимен обмен на данни между притежателя на карта и изпълнителя на услуга, така както и между различните изпълнители на услуги. Също, четенето от и записът (въвеждането) в паметта за обмен е защитено чрез ключове, това засяга също картата и специфичната заявка, също така допълнително специфичния терминал. Установе4 ната предварително автентичност на всяка сделка, както и, незадължително, PIN или парола, допълнително увеличават защитата на чипкартата съгласно изобретението.

В патентните претенции от 21 до 30 е дефиниран терминал за използване с чипкартата съгласно изобретението. Този терминал служи за въвеждане или извеждане на заявки, за осъществяване на сделки, за преглед на информацията, както и за изпълнение на следващи действия, свързани със съответни заявки и сделки. Процесът за осъществяване на сделки между притежателя на карта и изпълнителя на услуга е дефиниран в претенции 31 до 33, въвеждането (зареждането) на информация в чипкартата съгласно изобретението е дефинирано в претенции 34 и 35, и претенция 36 дефинира общата система, съдържаща чипкарта и терминал.

Пояснение на приложените фигури

По-нататък изобретението е допълнително пояснено чрез предпочитан пример на изпълнение, с пояснение на приложените фигури, от които:

фигура 1 представлява графичноизображение на чипкартата съгласно изобретението;

фигура 2 - структурно представяне на общата система от компонентите на изобретението;

фигура 3 - потока от данни в цялата система;

фигура 4 - възможните групи заявки и операции чрез модел на сделка в схематична илюстрация;

фигура 5 - схематично илюстриране на защитната архитектура на чипкартата съгласно изобретението;

фигура 6 - информационна структура на основната група за изпълнение на VAS носителя;

фигура 7 - вариант на групи за изпълнение на VAS носителя, съгласно примерното действие от изобретението;

фигура 8 - информационна структура на VAS носителя съгласно примерното действие от изобретение;

фигура 9 - схематично информационната структура на групата за изпълнение DF_PT;

фигура 10 - схематично информационната структура на групата за изпълнение DF_AD.

Примери за изпълнение на изобретението

Дефинирането на използваните термини, както следва:

VAS: валутни (платежни) компютърни услуги;

VAS карта: VAS картата е чипкарта, със средствата на която е възможно да се извършват платежни компютърни услуги. VAS картата освен други заявки, като например заявки за плащания (т.е. електронни портфейли), съдържа VAS носител;

VAS носител: VAS носителят съдържа и информационна структура, условия за достъп, ключове и компютърни команди за администриране (управление и обработка) на VAS заявките и за достъп до функционирането на VAS заявките;

VAS заявка: VAS заявките (исканията) съдържат VAS данни. Достъпът до VAS данните е контролиран чрез VAS заявката. VAS изпълнител на услуга обработва във VAS носителя една или повече VAS заявки. Използването на VAS заявка е дефинирано чрез заявката, четейки и оперирайки с VAS данните. VAS заявката може да се отнася и до вътрешна и до взаимна (външна) услуга.

VAS изпълнител (доставчик)на услуга: VAS изпълнителят на услуга е отговорен за своята VAS заявка, която той обработва в съответствие с базовите (основните) условия на системния оператор и в съответствие с неговата лична свобода на действие, и едва след това осигурява достъп за използване на притежателя на карта чрез системния оператор и терминалите. VAS заявките трябва да бъдат въведени (заредени) във VAS носителя на VAS картата преди да бъде възможно участието й (използването й) в това отношение.

Вътрешна услуга: Вътрешната услуга е вид VAS заявка, използвана под изключителното управление на съответен VAS изпълнител на услуга. Заявките за вътрешна услуга са заявки в затворен кръг, което означава, че няма пресмятане и изпълнение на сделки с участие на външни партньори. VAS заявката може да бъде и двете - услуга от вътрешно или от взаимно естество.

Взаимни услуги: Заявките за взаимни (външни) услуги са заявки с вътрешни услуги, които чрез допълнителни (компютърни) външни връзки са свързани с външни партньори.

/ /

I

VAS заявката може да бъде и двете - вътрешна или външна услуга по естество.

SO, системен оператор: Системният оператор предлага на VAS изпълнителите на услуги и притежателите на карти VAS системата за използване от тях.

Изходен отвор: Изходният отвор или отворът за карта поема VAS картите, включващи VAS носители, в обръщение (употреба/

СН, притежател (предявител) на карта: Предявителят на карта или собственикът на карта е лице, което притежава и използва картата (в този случай: VAS карта) за възможно участие в платежни компютърни услуги. Това лице не е непременно истинският собственик на картата.

Терминал за услуга: Терминалът за услуга е станция на системния оператор за VAS заявки. От терминала за услуги приносителят на карта може да администрира (обработва) VAS заявките във VAS картата си (въвеждане, разглеждане, извеждане и обмен на VAS заявки).

Дилърски терминал (търговски, за сделки ): Дилърският терминал има платежни функции и допълнително предлага VAS функции. Това става, когато притежателят на карта привежда в ред своята VAS карта, от една страна, да извърши плащания и, от друга страна, да участвува в полза на VAS.

AID идентификатор на заявка): AID е име от заявките, не по-дълго от 16 байта, за точно диференциране на заявките и селекцията на заявки отстрани без познаване на информационната структура на картата. AID съдържа Изпълнител на Регистрирана Заявка ID (RID), с дължина 5 байта, и незадължително Собствен Идентифициращ Регистратор на Заявка (PIX), не по-дълъг от 11 байта.

DF: Файл на директория съгласно ISO 7816.

EF: Елементарен файл съгласно ISO 7816.

Валиден VAS носител: VAS носител, който има способност да установява автентичността си относно външния свят.

KID (Ключ идентификатор): Множество от ключове в Елементарния Файл, съдържащ ключовете.

R&R: Права и правила.

р: Максималният брой задачи от групата за изпълнение DF РТ.

а: Максималният брой задачи от групата за изпълнение DF_AD.

пгшк: Максималният общ брой задачи, пгшл = р + а

Броят на записите в EF_DIR е nrDIR. nrEF_TRANSFER: Броят записи в EF.TRANSFER.

Фигура 1 показва схематично структурата на чипкартата съгласно изобретението. В допълнение на постоянните, непроменящи се данни, използвани по време на обработващия процес, например Главният Файл MF и (незадължително реализирана) функцията на портфейла DF_PURSE, по-нататък има осъществени в картата в съответствие с изобретението индекс или структура с данни или информационна структура база данни DF_VAS. Това служи за постигане на допълнителни функции, така наречените платежни компютърни услуги, VAS. На базата на тези допълнителни функции, които позволяват заявките, които даже в по-следващ етап, както се казва, след като картата е била създадена (произведена), могат да бъдат въведени в картата, картата е променлива и вариантна по отношение на нейните функции и сделки, които могат да бъдат извършени след това. Така нареченият VAS носител (DF_VAS), реализиран в чипкартата в съответствие с изобретението, позволява вариантността и променливостта на чипкартата по отношение на функциите й и, освен това, прехвърля заявките, записани в чипкартата, технологично-защитени от платката на картата, превръщайки ги в независими от платката на картата и разрешавайки им даже да бъдат обменяни (прехвърляни) на друга карта.

Новите компютърни функции съгласно изобретението (Платежни компютърни услуги, VAS) са осъществени чрез микропроцесорни чипкарти. Промяната на тези допълнителни функции е причинена от VAS носителя. VAS носителят в микропроцесорната чипкарта разпределя пространството за съхраняване на VAS заявките. VAS заявките са съответно реализирани от специфичните компютърни функции.

В случая на електронен портфейл плащанията с помощта на картата (платежна функция) и използването на VAS заявка (компютърна функционалност) е представено чрез отделни механизми. От страна на ползувателя на картата или притежателя на картата това може, понякога, да изглежда като самостоя6 телна процедура.

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

VAS носителят също така използва механизми за получаване на терминални специфични ключове. С тези средства VAS носителят сам може активно да контролира автентичността на терминалите, респ. на подадените данни от тях.

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

Предимство на VAS носителя в сравнение с други опити за мулти- (много-) заявъчни карти е, че тази концепция е независима от специфичната платка на картата. Тя предлага защитна архитектура, която е независима от специфичните защитни механизми на платката (като например ключове, идентификационни данни, PIN, сигнатурни процедури).

Друго предимство на концепцията на VAS носителя е, че броят на отделните заявки в картата не е строго определен от ограничения и препоръки по време на изработването на картата или пускането й в обръщение (използване). Общоприетото зареждане на картата със заявки може да бъде свободно подбрано от ползувателя на картата и е ограни чено само от наличния капацитет (обем) на паметта в специфичната карта. Броят на VAS заявките, въведени в картата за някакво определено време, зависи от действителното използване на картата. Ползувателят на картата индивидуално въвежда (зарежда) VAS заявките в картата си. Това също така предизвиква модифицирането на комбинацията в следващата инстанция. VAS носителят позволява многофункционална карта, в която функционалността на картата в продължение на цикъла на живот на картата може да бъде натрупана и използвана по различни начини с оглед на броя и естеството на заявките. Също така е възможно да се въвежда (зарежда) една единствена карта за заявки, за което в миналото са били необходими индивидуални специални карти. VAS заявките могат също така да бъдат обменяни с други карти. Съответно, VAS заявките могат да оцелеят след цикъла на живот на картата, те съпровождат ползвателя на картата по време на цикъла на живот на същите заявки.

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

Фигура 2 показва диаграма на системата. Тя илюстрира компонентите на системата. Системният оператор прави системата достъпна. VAS заявките могат да бъдат въвеждани, извличани и обменяни от терминалите за услуги (ST), следващите операции са разпределяне, разглеждане, обработка и т.н. на VAS заявките.

Изпълнителите на VAS заявките, така наречените VAS изпълнители формулират своите собствени VAS заявки съгласно базовите условия на системния оператор и ако е възможно съгласно собствените си желания. Кореспондиращите терминални програми могат следо7

/ вателно да контролират автентичността чрез прекратяване (затваряне) с цифров знак.

Фигура 3 илюстрира потока от данни в системата.

VAS заявките са направени достъпни за 5 използване от притежателите на карти от терминалите чрез системния оператор. VAS заявките могат да бъдат записани във VAS носителя на чипкартата съгласно изобретението преди участието, в този смисъл, да бъде възмож- 10 но.

От дилърския терминал (НТ) VAS заявките, съществуващи в картата, се използват чрез заявката или чрез извеждането на VAS данните. 15

За да се реализира микропроцесорната чипкарта с VAS функционалност, VAS носителят е осъществен в картата в допълнение на съществуващите заявки (т.е. заявки за плащания, като например електронен портфейл). 20

VAS носителят използва функции, които позволяват въвеждане, извеждане или обмен на VAS заявки. Тези администриращи операции се използват изключително от системния оператор и са защитени в картата срещу 25 бъдещо използване. VAS носителят включва памет за обмен на данни, средствата на която осъществяват обмена на информация между VAS заявките.

Двете команди TRANSFER и ТАКЕ се 30 използват за контролиране на паметта за обмен. Командата TRANSFER управлява въвеждането в паметта за обмен на специфични данни за съответната заявка. Освен тези използвани данни, също се включват въвеждания, като нап- 35 ример данни, заличени данни и идентификационни данни, необходими за контрола на операциите. Чрез средствата на командата ТАКЕ задачите се извличат от паметта за обмен и се маркират, че са били извлечени. В съответ- 40 ствие със специфичността на заявката, заявките тогава се маркират или да останат валидни, или да се считат за невалидни. Обменяните данни се контролират от VAS носителя в съответствие с автентичността и уникалността. 45

VAS заявките използват VAS данни за осъществяване на достъп и контролиране на заявките. Достъпът до VAS данните се контролира чрез VAS заявка, използваща механизмите, които са валидни за всички заявки във 50 VAS носителя. VAS изпълнителят обработва във VAS носителя една или повече VAS заявки.

Използването на VAS заявка е дефинирано чрез въвеждането, четенето и оперирането с VAS данните.

VAS носителят подпомага взаимните (външните) услуги. Взаимните услуги изискват обмен за запознаване с данните, обмен на запитвания за услуги и фактуриране на услугите между различните партньори.

По-нататък услугите и заявките, направени възможни чрез чипкартата съгласно изобретението, ще бъдат разгледани с описания (цитиране) на примери.

За всеки случай описанието се отнася до реализацията и действието съгласно настоящото състояние на техниката. Занапред действието ще бъде илюстрирано чрез една или повече VAS заявки.

Най-напред ще бъдат представени вътрешните заявки.

Пример А: Клуб на купувачите.

Универсален магазин организира клуб на купувачите. Купувачите стават членове на клуба и съобразно с това положение получават специфични клубни услуги, които са недостъпни за нечленове. Сега клубният член се идентифицира в клубното общество чрез документ за клубно членство. Документът за клубно членство се приготвя при постъпване и е несменяем и, по правило, има ограничено времетраене. Неспецифичните сделки се осъществяват чрез клубната карта за членство, т.е. няма връзка с отказали се купувачи. По този начин клубната членска карта е разграничена от bonus (поощрителните, бонификационни) програми, при които съществува връзка между състояние и отказ.

Аналог: Членска карта за продажба (търговия) на едро, сенаторска карта, читателска карта (за библиотека или покупка на книги).

Задача: Клубната карта е за доказателство чрез заявка във VAS носителя.

Пример В: Bonus система (поощрителна, за допълнителни възнаграждения).

Купувач е кредитиран за всяка сделка чрез извънредно възнаграждение - bonus право. Bonus правото възниква и може по време на вземане на решение от купувача да бъде сменено с парична полза. Bonus правото е валидно за определен период и може да бъде администрирано анонимно или чрез лицето, за което се отнася. Bonus правото възниква при отказ или бързо използване.

Аналог: Точкови положения за Храни & Други.

Задача: Точковият сбор трябва да бъде администриран чрез заявка във VAS носителя.

Пример С: Отбив.

Купувачът получава списък с отказани отбиви. Отбивът е прикрепен (приложен) към всяка индивидуална сделка. Картата не администрира историята на отказите. Всяка сделка е самостоятелна (сама за себе си).

Задача: Правото на отбив да добие автентичност чрез VAS заявка.

Пример D: Идентичност на документ за действие.

Лицето (клиентът) има възможност чрез признаци в картата да докаже до три пъти своето право за предопределяне на услугите. Свързването на лицето с документ за идентичност (установяване на самоличността) трябва да бъде автентичен за всяка сделка (снимка, PIN, биологични белези - биометрия). Достоверността на документа за установяване на самоличността се използва като защитен признак.

Аналог: Вътрешен достъп, вътрешнобанков достъп, телефонна карта.

Задача: Разрешението да бъде осъществено чрез VAS заявка.

Пример F: Потребителско фактуриране (даване на разписка).

Използването на услугата се регистрира за период от време, честота или количество и е фактурирано в съответствие с движението. Размерите, до които услугата ще се разпростре, предварително не са известни.

Аналог: Купон за храна, краткосрочен талон за паркиране.

Задача: Чрез VAS заявка да се позволи фактуриране съгласно установени тарифи. Данните по заявката за фактуриране на всяко специфично ниво се въвеждат във VAS носителя.

Пример G: Запис на данни (подвижна база данни).

Тази заявка позволява обменът на данни от притежателя на карта с VAS изпълнителя. Сделките са, при това, автоматизирани, което сега все още трябва да се осъществява ръчно. Непаричният обмен може да бъде получен от тези данни.

Аналог: Запълване на номерата на талони за плувен басейн, пазарни листи, квитанции за плащане в брой, телефонни регистри.

Задача: VAS изпълнителят извлича данни от картата само тогава, когато е възможно директно осъществяване на поръчаната услуга (осъществяване на телефонна връзка, съставяне на списък за желани покупки, електронно попълване и записване на номерата на билетите за плувен басейн). Информацията (данните) може да се въведе в картата за кратък период от време или за дълъг период.

Тези примери на вътрешни услуги ще бъдат сега последвани от няколко примера за външни (взаимни) услуги.

Външна (взаимна) услуга възниква всеки път, когато множество от VAS изпълнители вземат участие в услуга. Има постоянно свързване на един VAS изпълнител с останалите общоизвестни данни. За информация има записи върху хартия.

Пример А: Възстановяване сума за пътуване.

Универсален магазин възстановява на купувача сумата за пътнически билет, издаден от предприятието за обществен транспорт, за пътуването до универсалния магазин. Купувачът може да пътува до универсалния магазин с единичен билет за пътуване. Универсалният магазин отбелязва върху билета, че трябва да бъде възстановен (средствата за него). Това е така, защото универсалният магазин получава от транспортното предприятие част от върнатото на клиента.

Задача: Процедурата по възстановяване се извършва по електронен път.

Пример В: Пътнически документ (билет за транспорт).

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

Задача: Наподобяване на механизмите чрез VAS заявки (въвеждайки електронно представяне на сметките между търговеца и предприятието за обществен транспорт).

Пример С: Паркинг за клиента.

Универсалният магазин възстановява на клиента (купувача) част от паркинг таксите, когато се използва частен гараж за паркира9 не. Гаражът за паркиране се управлява от независимо предприятие и получава от универсалния магазин парично заплащане за всяка оказана чест на купувач.

Задача: Наподобяване на механизмите 5 чрез VAS заявки, въвеждайки електронно представяне на сметките между търговеца и гаража за паркиране.

Пример D: Многостранни bonus (бонификационни) програми.

Група търговски предприятия и изпълнители на услуги се уговарят за съвместна bonus програма.

Задача: Всеки партньор може да дава или получава бонификоционни (bonus) точки срещу налична сметка или карта. Заплащането за услуги между партньори се извършва чрез подчинена система.

Пример Е: Признаване на bonus точките между партньори за услуги.

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

Задача: Осъществяване на обмена на bonus точките чрез картата. Всеки VAS изпълнител е определен да събира своите точки за себе си без намеса от някой друг. Осигурени са механизми за създаване на възможност за обмен.

Пример F: Такси през нощта.

Чрез купуване на билет за пътуване от обединението за обществен транспорт едновременно се придобива правото за пътуване в колективно такси (например след 22 часа). За изпълнение на предвиденото таксиметровото предприятие трябва да има предвид, че се представя билет за пътуване. Използването на такси се отбелязва върху билета с цел да се избегне злоупотреба.

Задача: VAS заявката е предназначена да позволи използване, контрол и осъществяване на тази услуга. 45

Както следва, структурирането на чипкартата съгласно изобретението ще бъде описано по-нататък.

По-специално, микропроцесорната чипкарта с VAS функционалност съдържа VAS но- 50 сител.

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

Част от валутните (платежни) компютърни услуги са сделки, представени от клиента на терминали на VAS изпълнители. VAS изпълнителят има интерес да контролира тези сделки или за целите на системния контрол или за събиране на статистически или други данни. За възможно оптимизиране и единство на информационните структури в картата, използването на специфичните идентификации на заявките не е препоръчително и е предложено използването на недвусмислен VAS носител ID, приложим за цялата система. Този номер може да бъде използван от VAS изпълнителя за упражняване на гореспоменатите функции и това го освобождава от задължението за администриране чрез собствената му номерационна система.

Защитната архитектура на VAS носителя използва тази разширена недвусмислена система ID- най-вече за получаване на специфичните ключове на картата. Използването на специфичния номер на картата би било възможно по принцип, но за препоръчване е да не се използва, защото VAS-носителят ще бъде реализиран върху различни платки, това може в известни отделни случаи да се използва за противопоставяне на номерационни системи.

VAS носителят ID се зарежда от системния оператор и се включва чрез изходния отвор за картата, когато се създава VAS носителят. Всичко това се разрушава при изчистване на VAS носителя и чрез това се премества (прехвърля) от системата. VAS носителят се смята, че е бил изчистен, ако той не съдържа VAS заявки и ако VAS носителят ID е бил прехвърлен.

По време на целия обмен на VAS носителя от старата в новата карта, VAS носителят ID се обменя съвместно с VAS заявките. Този обмен съответствува на преместване на VAS носителя от старата в новата карта. След тази процедура старата карта незадълго съхранява VAS носителя. VAS носителят, създаден в новата карта, е презаписан по време на тази операция и чрез това е изчистен. От момента на обмен на VAS носителя от старата в новата карта, не са необходими никакви трансформации на указващите номера в базовите системи на VAS изпълнителите.

Индивидуалните VAS заявки могат да бъдат обменяни между два различни VAS носителя само под контрола на водещия VAS изпълнител. По време на това действие връзките между VAS носителя ID и VAS заявката се променя, което може да бъде записано в базовата система на VAS изпълнителя.

VAS носителят не съдържа индивидуални признаци, VAS заявките могат да съдържат индивидуални данни, степента на които би трябвало , разбира се, да се поддържа минимална за условията за информационна защита и за подобряване използването на паметта. VAS заявките би трябвало, ако е необходимо, да съхраняват индивидуално, отнасящи се данни в базовата система и да създават връзката с картата чрез VAS носителя ID.

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

За резултатно изпълнение на взаимните услуги партньорите би трябвало (би било желателно) да имат достъп до наличната информация. Съвместният (Едновременният) достъп до данните се осъществява чрез множество стьпкови защитни механизми.

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

Втората фаза е изтриване на паричните стойности (валутните средства), представени чрез VAS информация. VAS изпълнителят въвежда паричните стойности във VAS информацията посредством специален ключ за въвеждане на информация. Валутните средства могат да бъдат консумирани (използвани) чрез взаимно услужващи си партньори, които имат валиден ключ за изтриване (ликвидиране) на средства, осъществяващо се от изцяло отговорния VAS изпълнител. На тази фаза партньорите, имащи взаимно различаващи се права, си взаимодействуват с необщодостьпната VAS информация.

Третата стъпка е директният информационен входен достъп до VAS информацията от всички участвуващи взаимно услужващи си партньори. Този метод изисква определена степен на доверие между партньорите, защото VAS информацията може да бъде модифицирана без ограничение. Областта за обмен служи като свързващо звено между VAS заявките. Данните в областта за обмен са възпроизведени чрез VAS заявките във VAS носителя. Данните, освен това, могат да бъдат въведени директно в областта за обмен, ако лицето, изпълняващо същото това, не обработва своята собствена VAS заявка във VAS носителя.

Областта за обмен е по принцип достъпна за всички заявки, разбира се, въвежданията могат да бъдат осъществени само от някой с дадено право за това (например чрез ключ). Само получателите, които са с дадено право за това посредством правилата, така наречените Права и Правила R&R, могат да преместват информация от областта за обмен. Получателят проверява за присъствие (наличие) на обменени данни, адресирани до него, и ги изтегля за работа в неговата собствена система.

Най-вече, за предпазване от манипулиране на обменяната информация при общодостъпен взаимообмен, производителят въвежда признак за автентичност и за VAS носителя въвежда пореден номер. Чрез тези елементи се защитава уникалността (само едно единствено) на решението за обмен и действителната информация се показва.

В случай на необходимост получателят на обменяни данни е снабден от производителя със средство за извършване на проверка за автентичност. Ако това не е направено, приемането на данните може да бъде осъществено на добра воля, в този случай признакът за автентичност е възможно само да бъде проверен, когато изпълнението започне в базовата система на работещия VAS изпълнител.

Изтеглянето на данни от областта за обмен е възможно само веднъж при липса на признак за автентичност. По време на изтеглянето данните се маркират и остават (като копие) в областта за обмен.

Това позволява проверка на процедурата за обмен едва след изтегляне на информацията за известен период.

Данните в областта за обмен съдържат извличаната информация. Чрез арбитриращи заявки извлечената информация може да бъде презаписана, когато е необходима. Данните в областта за обмен могат да бъдат маркирани при извличането, чрез което да бъдат свободни за незабавно презаписване. Би трябвало паметта за обмен, въпреки това, да бъде изцяло запълнена преди разпадане на връзката за обмена на информацията, притежателят на карта трябва да прекъсне входовете на терминала за услуги, които вече не са необходими.

За моделиране (оформяне) на VAS заявките са дефинирани три операции. Тези операции влияят върху VAS информацията. Въвеждането и извеждането са функции на VAS носителя и не са разгледани в следващите параграфи.

Купуване: Най-общо, покупка на право за услуги и заявяване (представяне) на доказателството за това във VAS данните на VAS заявката.

Анулиране (заличаване): Обикновено, изплащане на правото без или със пълна или с частична консумация на VAS данните на заявката. Процедурата включва електронен начин (инструкция), който е заявен в областта за обмен. Тази инструкция прехвърля присвоената извлечена информация, след което тя може да бъде заличена от паметта за обмен.

Извеждане: Обикновено създаване на електронна инструкция в областта за обмен за по-нататъшно действие (така наречената базова система). Копие от указанието остава и служи при проверка за “Анулирането”.

“Получаването” на VAS информация може да се изпълни само чрез съответния VAS изпълнител. “Анулирането” на VAS данните може да се осъществи чрез VAS изпълнителя, който ги е създал чрез “Купуване” или чрез партньор по взаимна услуга, за което е упълномощен от VAS изпълнителят.

“Извеждането” може да бъде изпълнено, също така, чрез някой друг VAS изпълнител. Взаимна услуга без равни права за достъп до VAS информацията струва задържане от партньора за преходен период на състоянието “Извеждане”. Електронната инструкция, чрез която се открива, може тогава да бъде представена чрез системния оператор и базовата система на VAS изпълнителя. “Купуване” и “Анулиране” могат да се осъществят в самастоятелна стъпка.

VAS заявки с известни признаци могат да бъдат разделени в отделни групи. Тези отделни групи формират базите на информационни структури във VAS носителя. VAS изпълнителят по време на изпълнението на негова заявка съхранява (запазва) групата заявки.

В този контекст ( в този смисъл) са дефинирани следващите групи заявки:

• Точкова база данни • Билет • Идентификационен документ • Платежен документ

Информационна база данни

Точковата база данни означава група заявки, в която пресмятането на точковите стойности е администрирано (архивирано). В и от точковите стойностни сметки може да се кредитира и да се изтегля. Кредитирането на стойности се осъществява чрез VAS изпълнителя, поради което в информационната база данни има въведен баланс на новите сметки. Вписването на стойностите на дълговете се извършва чрез “анулираща” операция, в чийто контекст като доказателство се заявява електронно получаване (постъпление) в паметта за обмен . Достъп до двете действия се разре12 шава чрез два различни ключа за достъп.

Билет означава група заявки, в чиято област за стойности е указано какво може да бъде анулирано и как да се консумира и в двата случая - веднъж или многократно. 5

Кредитирането на стойности в групата заявки Билет се изпълнява само веднъж.

Идентификационен документ (за установяване на самоличност) означава група заявки, при които VAS данните получават доказателство за право. Доказателството, обикновено, не се анулира при използване; разбира се, след предопределен критерий, т.е. след изтекло време, започва обявяването му за недействителен.. Съгласно дефинирането на заявката автентичността на идентификационния документ (т.е. разрешително за паркинг в съседство) или действието за представяне на документа се документира (т.е. колективно пътуване с такси, използвайки месечен билет (абонаментна карта): Издаване на електронна разписка чрез чипкартата. Разписката се представя от таксиметровото предприятие на сдружението за обществен транспорт и се отчита пропорционално.). Незадължително използването на идентификационен документ може да бъде документирано в паметта за обмен на картата по електронен път.

Платежен документ означава група заявки, чрез средствата на които правото за услуга (като правило кратковременно) се поста10 вя за временно съхранение в картата. Тези електронни платежни документи се съхраняват изключително в паметта за обмен на VAS носителя. Заявката, използваща платежния документ е, по правило, различна от обичайната заявка. Изтеглянето на платежния документ от мястото за съхраняване с цел обмен е възможно само веднъж и се документира от картата. По време на пресмятането в базовата система може да бъде използван признак за автентичност, създаден във VAS носителя.

Информационна база данни означава група заявки, при които VAS изпълнителят запомня данните във VAS носителя за осъществяване на компютърна услуга за клиента (т.е. минало меню в ресторант за бързо хранене, минал номер от номера за плуване, предимства за обслужване, списъци с предложения). Тези данни са само за информация и не представляват право за услуги според VAS изпълнителя. Достъпът до данните е контролиран от VAS изпълнителя.

Всяка група заявки е характеризирана чрез типичен цикъл на използване. Следващата таблица илюстрира честотата, с която трите току-що дефинирани операции са приложени към VAS данните на група заявки. (Моля да се отбележи: “Купуване” не се подразбира “въвеждане на заявка” и “изтегляне” не се подразбира “заличаване на заявка”).

Цикъл на използване

Таблица 1.

	Точкова база данни	Билет	Идентификационен документ	Платежен документ	Информационна база данни
Купуване Анулиране Изтегляне	Многочислена Многочислена Многочислена	Единичен Многократен Многократен	Единичен Многократен Многократен	Единичен Единичен Единичен	Многочислена*** Никога Никога

♦**В групата заявки “Информационна база данни” не може да се придобие право, заявката просто въвежда данни в заявката.

Фиг.4 показва по-горе обяснените групи заявки и операции чрез модел на сделка.

Както следва, ще бъде показана защит ната архитектура на чипкартата съгласно изобретението. За осигуряване на защита са дефинирани следните ключове:

Таблица 2.

Списък на ключовете

Име	Място	Притежател	Описание
KSO KAUT KSIG _ VASC KGKDEC KLVASP KRVASP KGKDEC.PIX KDEC	VAS носител VAS носител VAS носител VAS носител VAS заявка VAS заявка VAS изпълнител Дилърски терминал	Системен оператор Системен оператор Системен оператор Системен оператор VAS изпълнител VAS изпълнител VAS изпълнител VAS изпълнител	Ключ за администриране на VAS носителя Ключ за автентичност на VAS носителя Ключ за кодиране на данните за сделката Ключ за получаване на ключа KGKDEC.PIX Ключ за достъп за запис във VAS данните Ключ за достъп за четене от VAS данните Ключ за получаване на ключа KDEC Ключ за автентичност на дилърския терминал

Защитната архитектура се базира на цикъла на живот на VAS носителя или VAS заявките и се доизгражда в съответствие с удобството на участвуващите страни. Схематичната обяснителна илюстрация е очевидна от фиг.5.

Както следва, направени са някои разяснения на структурата на VAS носителите, също така на съответните им заявки.

VAS носителят, както и VAS специфичните компютърни команди, са въведени заедно в картата чрез изходния отвор за картата съвместно с други не VAS заявки или са най-вече обединени чрез терминала за услуги от оторизирания (упълномощения) VAS изпълнител в съществуващата платка на картата, поставена в терминала за услуги.

За втората възможност - следващият механизъм може да намери заявка: Системният оператор се съгласява за временния ключ KSO* с изходния отвор за картата. Изходният отвор отваря картата със своя ключ, които е познат само на него, установява областите на VAS носителя и по-точно записва KSO* в DF_VAS. Системният оператор може, тогава, от по-късна инстанция (т.е. картата влиза в контакт с терминала за услуги на първо време) да премества ключа KSO* чрез своя собствен KSO, който се знае само от него самия. Системният оператор може сега да въведе за себе си допълнителни данни, като например KGKDEC или да осъществи администриране в сулчай на платка с динаимчна памет, или да изчисти файловете за VAS заявки. Това е така защитено, че отворът след първото използване на VAS картата не за дълго има достъп до VAS носителя и че само системният оператор има достъп до VAS носителя. Поради отсъствие на някои известни информационни структури и взаимен обмен на данни с други заявки, защитната архитектура на VAS носителя е по такъв начин е независима от други реализирани заявки в платката на картата.

От специалното представяне на изобретението ползата е, разбира се, то да се направи при първа възможност. Отворът е необходим по инструкциите на системния оператор да подпомага VAS носителя при зареждане на всички ключове във VAS картите.

VAS носителят има предварително определена информационна структура, предварително определено съгласуване за достъп (ACS) и известно количество общодостъпна информация. Тази информация съдържа така наречения ключ KSO за въвеждане или заличаване на VAS заявки. Той е защитен чрез този ключ, познат само на системния оператор, при което само позволените VAS заявки могат да бъдат въведени. За тази цел картата удовлетворява условието за външна автентичност пред системния оператор спрямо KSO.

Понякога притежател на карта желае да въведе VAS заявка от терминал за услуги, съответният VAS изпълнител инструктира системния оператор съответно да извърши това от свое име. При въвеждане на VAS заявка във VAS носителя VAS изпълнителят обменя ключовете KLVASP и KRVASP със системния оператор, който след това ги въвежда в заявката. Ключът KLVASP позволява на VAS изпълнителя да защити данните на заявката срещу достъп за запис и съответно да защити вътрешната информация срещу достъп за четене. За тази цел картата удовлетворява условието за външна автентичност пред VAS изпълнителя, основаващ се на KLVASP: т.е. картата проверява действително автентичността на терминала. След сполучливото изпълнение на тази функция, на терминала се позволява достъп за запис на VAS заявка и достъп за четене от вътрешната VAS информация на заявката. Проверка за вътрешна автентичност, т.е. проверка на VAS заявката (и чрез това на картата), както и проверка за автентичност чрез дилърския терминал, може да се изпълни незадължително. Когато VAS заявката е използвана от притежател на карта, тези вътрешни VAS данни могат да бъдат записани в заявката или да бъдат модифицирани от произволни терминали, които имат достъп до ключа KLVASP.

Функцията “Купуване” е приложена за това чрез UPDATE RECORD команда, която трябва да бъде предхождана от проверка за външна автентичност чрез средствата на ключа KLVASP.

Достъпът за четене до всички невътрешни данни на VAS заявката се използва само ако предхождащото установяване на външна автентичност е извършено чрез KRVASP или чрез корекция на входа от PIN, или парола от системния оператор. Защитеният достъп чрез PIN/парола е осъществен с цел да позволи на притежателя на карта да ревизира данните от терминала или от портфейла. От терминал за услуга притежателят на карта може да реши да активира или дезактивира PIN/паролна защита за четене на стойностите или данните за състояние.

Общодостъпните данни на VAS носителя са съгласувани с ключ KSIG_VASN за отбелязване на изведените данни от областта за обмен. Посредством сигнатурата непокътнатостта на тези сделки може да бъде проверена всеки път, когато те трябва да бъдат защитени срещу манипулиране при обмен между взаимноуслужващи си партньори за взаимна сметка. В допълнение на сигнатурата, незадължително въведена от взаимноуслужващите си партньори, сигнатурата се базира на KSIG_VASC и на брояч на сделки, администриран от VAS носителя, които са подпомогнати от групи данни, избрани от картата чрез операцията “изтегляне”. Поради това, от една страна, чете нето от областта за обмен се изпълнява от някой друг, но от друга страна, сигнатурата на картата чрез KSIG_VASC може да бъде създадена, само когато е извикана за операция “изтегляне” (и това може да се случи само веднъж), всеки непозволен дубъл, използван за платежен документ, се разпознава. Всеки от взаимно услужващите партньори може да има автентичност и уникалност (да бъде единствен) за изтегляне на платежен документ, потвърдени от системния оператор. В допълнение, автентичността на VAS носителя може да бъде установена чрез проверка на сигнатурата от системния оператор.

В случай, че платката на картата употребява асиметрични ключови процедури, възможно е също в картата да се употреби като собствен (секретен) ключ KSIG_VASC за означаване на (задачите) намеренията или за създаване на такъв ключ от собствен Ключ Създаващ Ключ (KGK). VAS изпълнителите могат в същия случай да използват общоизвестни (несекретни) ключове за собствена проверка на сигнатурата, без да се консултират със системния оператор.

Част от данните на VAS носителя са формирани чрез общоизвестния Ключ Създаващ Ключ KGKDEC, който има способността да създава ключа за достъп KDEC за всички терминали на всички VAS изпълнители за оторизирана проверка за операцията “анулиране” (създаване на зависим ключ и проверката ще бъде осъществено отново както следва подолу). Заличаването на данни за парични стойности не е подчинено на някои защитни мерки като въвеждането или купуването на право върху нещо. За тази цел е достатъчно да се използва общоизвестният ключ вместо специфичния ключ за заявката. Този общоизвестен ключ се превръща първоначално при създаването в ключ на заявка и след това при възобновеното възпроизвеждане в терминален ключ. VAS изпълнителят е само за специфичното създаване на заявката от общоизвестния ключ за създаване на собствен терминален ключ. Това е описано кратко, както следва:

Означаваме като mac (k,d) пресмятането на предадения автентичен код за съобщение d и DES-ключ к чрез средствата на DES. Колкото и да е дълго съобщението, не е подълго от 8 байта, това съответствува на кодиране, като например (предполагайки ICV=0).

/

Означаваме като macp (k,d) пресмятането на mac(k,d) с последваща адаптация на равен брой бита. Резултатът к’ = macp(k,d) е още веднъж валидния DES ключ. Пресмятането на специфичния терминален ключ на заявката продължава, както следва:

1. Всяка карта съхранява ключ

KGKdec, който е еднакъв за всички карти и който пази секрета чрез системния оператор. Системният оператор действува така, че този ключ да се персонализира в картата. От този ключ могат да бъдат създадени всички други ключове на VAS заявки и терминали.

2. VAS изпълнител желае да въведе VAS заявка A с AIDa=RIDvas.PIX_a. Системният оператор сега пресмята от ключа KGKdec и PIX специфичния ключ на заявката

KGKDEc.PIX=macp(KGKDEc.PIXA) и предава този ключ на VAS изпълнителя.

3. Този VAS изпълнител чрез средствата на нейния (на заявката) терминал ID създава от KGKdec.pix за всички терминали, чиято TRANSFER команда е поставена за прилагане във VAS заявката А, нейните (на заявката) специфични ключове:

KDEc=macp(KGKdec.pix,Terminal ID) = macp (macp (KGKdec,PIXa) .Terminal ID)

VAS изпълнителят съхранява тези ключове във своите терминали. В случай че VAS изпълнителят сам не управлява терминалите, той създава ключове и ги разпределя на операторите на терминалите.

4. VAS картата само изпълнява TRANSFER командата, ако командата съдържа създадена от терминала криптограма (шифрован текст) С, която е формирана чрез специфичните данни - данни на съобщението в паметта за обмен. Картата сама разпознава KGKdec и получава от терминала вместо данните на съобщението и криптограмата С, терминалът ID също така PIX (или алтернативно картата сама знае PIX, за който вижда само описанието на командата TRANSFER). Картата вече може да пресметне криптограмата С’ чрез данните на ползувателя:

mac (macp (macp (KGKdec.PIX), Terminal ID), data)=mac(macp(KGKdec.pix,Terminal ID),data)“ mac (Kdec,data)=C’

Картата сравнява криптогравата C’, изчислена от самата нея с криптограмата С, изчислена от терминала. Ако те са различни, тогава се извършва прекратяване на сделката и грешното съобщение. В случай на съответствие VAS картата ще изпълни TRANSFER командата.

Вариантите на защитните мерки са в съответствие с различните конструкции на терминалите за услуги или дилърските терминали (респ. за въвеждане или купуване) и обикновени дилърски терминали (за анулиране). Терминал, за да изпълни анулиращата операция, трябва да докаже на картата сам автентичността си чрез разпознаване на Kdec. Ако този ключ Kdec е компрометиран, агресорът може просто да изпълни действието от този единичен терминал. Въпреки това, тази процедура е записана в картата. Документацията съдържа еднозначен последователен номер, анулирането и терминала ID. VAS заявките използват защитни услуги от VAS носителя, за да регулират обмена на VAS информацията. Изпълнението на VAS специфичните функции е ограничено до оторизирани части от дефинирането на правата за достъп.

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

Имайки предвид факта, че съгласно ISO 7816-4 картите не осигуряват диференцирано предимство за достъп за индивидуални записи на Елементарни Файлове (EF), необходимо е да се използва множество файлове, всеки съдържащ запис за излагане на различни страни на VAS заявката.

Така за групите Точков запис, Билет, Идентификационен документ и Информационна база данни диференцираният защитен достъп може да бъде разрешен от подразделянето на VAS данните в четири Елементарни файла, както е показано на фиг.6.

Четирите Елементарни файла съдържат следващата информация или са защитени по следния начин:

Таблица 3.

Резюме на файловете

Област	Съдържания	Типично използване	Защита за достъп
EF.KEY	Съдържа ключа Klvasp, Krvasp, който е познат само на VAS изпълнителя (3абележка:3а всяка VAS заявка и незадължително за всяка карта VAS изпълнителят създава една двойка ключове)	VAS изпълнителят трябва да докаже автентичността си спрямо Klvasp, преди да бъде позволено да записва VAS данни в EFJNFO, EFJNTERNAL и EF.VALUE, респ. преди да бъде позволено да чете данни от EFJNTERNAL, Терминалът трябва да докаже автентичността си чрез средствата на Krvasp, Преди да му бъде разрешено да чете VAS данни от EFJNFO, EF.VALUE
EFJNFO	Невътрешна информация посредством VAS заявката	’Информация за билети ♦Информация за bonus програми ♦Информация за идентификационен документ ♦Информация за талон за паркинг	Съдържанията на тези информационни части могат да бъдат записани само от VAS изпълнителя (вътрешна автентичност чрез разпознаване ОТ Klvasp). Четенето би било възможно само от терминали, имащи достъп ДО Krvasp ИЛИ Kso, или ако притежателят на карта въвежда верен PIN. (PIN-защитата може да бъде дезактивирана от притежателя на карта.)
EFJNTERNAL	Вътрешна информация за VAS заявката	Вътрешни броячи, счетоводни съобщения, информация за такси, компютърни ключове за: ♦Bonus програми ♦Таблици за отбив ♦Скрити идентификационни признаци ♦Кодове	Съдържанията на тези информационни части могат само за бъдат записвани и четени от VAS изпълнителя. Защитата за достъп се базира на вътрешното доказване на автентичност чрез разпознаване ОТ Klvasp.
EF.VALUE	Парични средства на VAS заявката	Тази информационна част съдържа пресметнатите стойности от VAS изпълнителя на заявка	Само VAS изпълнителя може да запише тези данни, изрично (външна автентичност чрез

*Счетоводни съобщения *Останали парични средства от билета за обществения транспорт •Кредит •Брояч на ползуватели

разпозпознаване от Klvasp). Безусловно, паричните средства могат да бъдат намалени чрез командата “анулиране” от партньора, на който е било дадено право да изпълни действието чрез VAS изпълнителя (чрез сигнатура на операцията за анулиране с Kdec) . Четене като за EFJNFO.

Тази структура на Елементарните файлове (EF) поставя известни диференцирани права за достъп за всички групи заявки.

Като се има предвид, че групите заявки сега са комбинирани в една група за изпълнение, която формулира броя и големината на Елементарните файлове, незапълнения обем памет, съответен на различни пространствени изисквания за заявките, може да бъде минимизиран. Групите заявки Точкова памет и Билет изискват известните ресурси EF_KEY, EF_INFO, EFJNTERNAL, EF_VALUE и са съответно комбинирани в група за изпълнение *DF_PT’. За групите заявки Идентификационен документ и Информационна база данни Еле- 30 ментарните Файлове EF_KEY и EF_INEO са достатъчни и са съответно комбинирани в групата за изпълнение *DF_AD’ . Разгледани откъм броя: има р задачи в групата за изпълнение *DF_PT’, и а задачи в групата за изпълне- 35 ние ‘DF_AD’ във VAS заявките от групите заявки точкова памет и билет, респ. идентификационен документ и информационна база данни, който (р и а) могат за бъдат въведени.

Специфично за групата заявки с плате- ₄θ жен документ (voucher), която би трябвало да се създаде за общодостъпно четене от всички VAS участници за целите на съвместен взаимообмен, е използвана от областта за обмен на групата за изпълнение. Достъпът за запис 45 е възможен изключително индиректно чрез прилагането на TRANSFER командата, което предполага сигнатура с верен KDEC. Тази група за изпълнение се състои от точно едно влизане в Елементарния файл EF_TRANSFER, принад- 50 лежащи на общодостъпната информация на VAS носителя. Задачите на тази група са за писани в този файл. Обръщаме се към тази група за изпълнение по същия начин като *EF_TRANSFER’.

Групите за изпълнение, показани на фиг.7, съществуват във VAS носителя. Тези групи за изпълнение формират модела на паметта на VAS носителя.

Моделът на паметта може да бъде направен действителен по два начина. Реализацията зависи от платката на картата.

Фиксирано разпределяне на съхраняващата (запомняща) област на VAS носителя:

За групите за изпълнение DF_PT и DF_AD, максималният брой р или а, като случаят може да бъде следният: за задачи - фиксиран от изходния отвор за картата, и въведен чрез изходния отвор в картата, използвайки CREATE FILE команди. Задачите са определени съответно като DF_PT и DF_AD. VAS заявките могат да бъдат въведени по-късно на места, свободни от задачи, т.е. незаангажирани от други VAS заявки. За въвеждане или извеждане на VAS заявки тогава са необходими само UPDATE RECORD команди.

Така отворът фиксира броя на възможните задачи на двете групи за изпълнение съгласно неговите собствени потребности; това може понякога да разграничи лицето притежател на картата от действителния VAS ползувател. Подразделянето се поддържа през целия цикъл на живот на картата. VAS заявка се въвежда към задача, принадлежаща на съответна група за изпълнение. Така например VAS заявка, представляваща идентификационен документ, може само да бъде реализирана в задача на групата за изпълнение DF_PT, ако немного задачи от групата за изпълнение

DF_AD са валидни. Присъединяването на VAS заявка към задача се осъществява чрез въвеждане на препятствие (PIX на VAS заявка, FID на въведената задача, точно текстово име на заявката) в общодостъпната информационна база данни EF_DIR на VAS носителя. Преместването на заявката е в съответствие с преместването на това препятствие от EF_DIR и разрушеното (прекъснато) четене (чрез UPDATE RECORD команди) на информация, въведена със заявката.

Тази модификация се използва с платки на карти, които не съдържат динамично създаване или изчистване на DF/EF структури.

Динамично поставяне на задачи в групата за изпълнение.

За всяка VAS заявка, за да бъдат въведени, файловете се формират чрез CREATE FILE команди като необходимост за основната (скритата) група за изпълнение. Когато се извежда VAS заявката, DF/EF, зает от нея, се прехвърля изцяло от картата и запомнящото пространство е освободено. Максималният брой задачи от групата за изпълнение тук не е изрично определен от изходния отвор и зависи само от обема памет на валидната карта.

Тази модификация предполага динамично администриране на информационната база данни от операционната система на картата.

В следващия пример за проследяване на работата ще започнем с първата модификация, защото следващата такава поставя важни въпроси пред наличната платка на картата. Разбира се, ако е възможно динамично запаметяващо администриране и е било възможно да се запази по-голям обем памет чрез динамично поставяне на задачите, което съответствува на администриращите разходи, то съ20 ществуващият замисъл може да бъде възприет и предлага повече гъвкавост на притежатела на карта.

Както следва, информационните струк5 тури и команди са представени чрез средства, от които VAS носителят и действието на VAS картата на клиента могат да бъдат прилагани в съчетание с други системни компоненти. Още повече VAS операциите са формулирани чрез 10 типични бизнесситуации, които описват съответното взоимодействие между VAS носителя и терминала.

За изпълнението важат следващите предварителни условия:

* Всяка карта, без зависимост от платката, прави възможно предаване на определеното количество данни и команди от дилърския терминал. Съответно, създадените команди са точно описани при тяхното кодиране.

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

В този контекст на фиг. 7 е показан схематично вариант на групи за изпълнение от VAS носителя . Фиг. 8 показва схематично информационната структура на VAS носителя. Фиг.9 показва схематично информационната структура на групата за изпълнение DF_PT, фиг. 10 показва информационната структура на групата DF_AD.

Достъпът до файловете на VAS носителя е ограничен изрично чрез следните условия за достъп (АС):

Условия за достъп

Таблица 4.

Информационна база данни	Администриране	Достъп за четене	Достъп за запис
DF_VAS	Kso	NEV	NEV
EF_ID	Kso	ALW	Kso
EF_DIR	Kso	ALW	Kso
global KEYs	Kso	NEV	Kso
PIN	Kso	NEV	Kso
EF_VERSION	Kso	ALW	Kso

EF_SEQ	Kso	ALW	Kso
EF_TRANSFER	Kso	ALW	Kso
DF_X (Х=РТ1,..,РТр, ADI,..., ADa)	KSO	NEV	NEV
EF.KEY	Kso	NEV	Kso
EF_INFO	Kso	PIN или Krvasp или Kso	Klvasp
EF_INTERNAL	Kso	Klvasp	Klvasp
EFVALUE	Kso	PIN or Krvasp ОГ Kso	Klvasp

В този контекст АС има следното значение:

ALW (Винаги) « Достъпът на командата до информационната база данни е винаги разрешен.

• NEV (Никога) = Достъпът на командата до информационната база данни никога не е разрешен.

• Kso = Преди достъп трябва да се установи предварително външната автентичност на системния оператор чрез ключа Kso.

• Klvasp = Преди достъп трябва да се установи външната автентичност на VAS изпълнителя чрез ключа Klvasp.

• Krvasp = Преди достъп трябва да се установи външната автентичност на оторизирания (разрешен) терминал за VAS изпълнителя чрез ключа Krvasp.

• PIN = Преди достъп верният PIN трябва да бъде въведен от притежателя на карта и да бъде прехвърлен свободно на картата чрез командата VERIFY.

• PIN или Krvasp или Kso = Преди достъп трябва да бъде изпълнено едно от двете: верният PIN трябва да бъде въведен от притежателя на картата или трябва да се установи външната автентичност чрез VAS изпълнителя, използвайки Krvasp или чрез системния оператор, използвайки Kso.

В този смисъл би трябвало да се отбележи, че ИЛИ свързването на правилата за достъп в действуващата система на картата, както е подчертано, не е изпълнено. Където се приложи, това би довело след себе си специални допълнителни разноски (друга възможност: специална READ команда с безусловно фиксиран защитен признак).

Информационните области вътре в записите на Елементарните файлове са диферен25 цирани съгласно следващите формати: ASCII, 15 Binary, BCD, Date, Format string.

Информационните елементи от вида “format string” съдържат VAS информация в пакетно представяне, което може да бъде показано на притежателя на картата върху тер2θ минала.

За оптимална илюстрация на съхранената информация точният текст и двоичните данни са смесени и възпроизведени на дисплея чрез форматиращи макроси.

Всички Елементарни файлове (EF) на VAS носителя са дефинирани съгласно ISO 7816-4 като линейно форматирани EF база данни със записи на константни дължини (линейно фиксирани файлове на запис).

Елементарният файл EF_ID от DF_VAS се състои от запис, който съдържа VAS носителя ID.

Елементарният файл EF_DIR от DF_VAS се състои от nrDIR записи. За всяка VAS заявка, въведена във VAS носителя, нейното подходящо идентифицирано състояние (PIX) и нейното физическо място за съхранение (FID на DF_X, в който заявката е била въведена) е фиксирано в записа на EF_DIR. PIX, т.е. като кодов номер, идентифицира заявката и изпълнителя на услугата, за който заявката е била предназначена.

Близанията в EF_DIR са динамични включвания на системния оператор от терминал за услуга. Записи без влизане са включвания с празна (без съдържание) TLV задача ‘61’.

Когато се въвежда VAS заявка, очевидно е наличие на свободна област за съхранение на групата за изпълнение, известните VAS данни са въведени там и накрая е създаден нов запис в EF_DIR.

При извеждането на заявка празната (без съдържание) TLV задача трябва съгласувано да бъде записана в EF_DIR.

Елементарният файл EF_VERSION на DF_VAS се състои от запис, които съдържа вариантен номер на VAS носителя.

Вариантният номер може да бъде използван чрез терминала за възможно диференциране между отделните модификации на VAS носителя и/или отделните software (програмни) версии.

Елементарният Файл EFJSEQ на DF_VAS се състои от запис, който съдържа номера на следващото влизане в областта на обмен.

Последователният номер се прочита чрез съпровождащата команда TRANSFER. Тогава тази команда създава в областта на обмен EF_TRANSFER запис, в който взаимно измисленият последователен номер от EF_SEQ се обменя. Съвместно с командата ТАКЕ, която осигурява за всеки запис от областта на обмен той да бъде изтеглен само веднъж, се записва този изтеглен запис чрез сигнатура към последователния номер, само веднъж може да бъде направена извадка от платежен документ или квитанция.

По-нататък паметта за обмен е разгледана по-детайлно.

Паметта за обмен е блок вътре във VAS носителя и съдържа nrEF_TRANSFER записи. Близанията в записите на тези файлове носят данни за обмен, осъществяван чрез TRANSFER командата. Взаимообменът на информация (данни) между VAS заявките, както и паметта за VAS данни на групата на платежния документ (Voucher) са представени чрез паметта за обмен.

Паметта за обмен може да бъде четена без ограничение, въпреки че достъпът до запис е възможен само чрез VAS специфичните команди TRANSFER и ТАКЕ.

Въвеждането на информационни области чрез TRANSFER командата се извършва чрез алгоритъм на “минало неотдавнашно използване” в картата. Старият запис в базата данни може да бъде детерминиран чрез проучване (търсене) за най-ниска стойност в първите два байта на записа.

Информационните области могат да бъдат маркирани чрез командата ТАКЕ в паметта за обмен като изтегляне и/или прехвърляне. Във всеки случай изтриването (заличава нето) на данни в паметта за обмен се осъществява чрез презапис с нови данни.

Всеки запис в паметта за обмен съдържа, например изтеглениО данни, терминалът ID, PIX,последователният номер и незадължителни допълнителни данни.

Всеки Елементарен файл EF_INFO вътре в списъците DF_X (където Х=РТ1,...,РТр, ADl,...,ADa) съдържа запис, съхраняващ изтеглените данни, както и основната VAS информация на VAS заявка. Например, естеството на билета (единичен или многократен билет) или информация за запазено място могат да бъдат включени тук. EF_INFO трябва, все пак, да съхрани най-накрая едно точно текстово име на заявката, което може да бъде четено при операцията показване (на дисплея) на VAS заявки. Важната информация трябва първо да бъде защитена от VAS изпълнителя чрез съответни външни ключови алгоритми.

Този EF е възможно да бъде прочетен, ако е налице установена външна автентичност с Kso или Krvasp или е уточнено къде притежателят на карта, в случай на активирана PINзащита, въвежда точния PIN.

Всеки Елементарен файл EF_INTERNAL в записите DF_X (където Х=РТ1,...,РТр, ADI,...,Ada) се състои от запис, който може да съхранява вътрешна VAS информация за VAS носител, съдържайки неговата въведена VAS заявка. Нито притежателят на картата, нито някой друг VAS изпълнител може да чете тази вътрешна информация. Всеки Елементарен Файл EF_VALUE вътре в записите DF_X (където X=PTl,...,PTp,ADl,..ADa) съдържа запис, който може да съхранява цяла област за парични стойности на VAS информацията. Този EF може да бъде четен, ако е налице установена външна автентичност с Kso или Krvasp или притежателят на карта в случай на активирана PINзащита въвежда точен PIN или вярна парола.

Следващите ключове на области са използвани от VAS носителя или от VAS заявката. По-нататък ще започнем с чисто DES кодирането, т.е. всички ключове на VAS носителя са DES-ключове и са кодирани в 8 байта (с изключение на аналогични битове).

Във VAS носителя и във VAS заявката следващите споменати ключове могат да бъдат проверени чрез техния KID (идентификационен ключ).

Таблица 5.

Ключове на VAS носителя

КЛЮЧОВЕ	KID
Kso	‘00’
Kaut	‘01’
Ksic VASC	‘02’
KGKdec	‘03’

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

Във VAS заявката следващите ключове могат да бъдат проверени чрез техния KID:

лет, които могат да бъдат въведени във VAS носителя едновременно.

• Максимален брой задачи от групата за изпълнение ОР_АО«*максимален брой VAS заявки от групите заявки Идентификационен документ и Информационна база данни, които могат да бъдат въведени едновременно във VAS носителя.

• nrDIR максимален допустим брой за10 дачи:

nrDIR=p+a

Броят записи в EF_DIR е nrDIR.

nrEF_TRANSFER е брой записи от EF_TRANSFER.

Необходимият обем памет за данните на описаните

Елементарни файлове е както следва: Основна информация

Таблица 6.

Ключове на VAS заявката

КЛЮЧОВЕ	KID
Klvasp	‘04’
Krvasp	‘05’

на VAS носителя: Байтове:

EFJD4

EF_DIR 9*(р+а)

EF_VERSION1

EF_SEQ2

Осн.ключове,РЖ64+2

Области на обмен:

Всеки ключ е свързан към операционния брояч на грешки. Това регистрира пренебрегнатите опити за установяване на автентичност с този ключ и блокира всякакво понататъшно използване, веднъж за този брояч е било реализирано ограничено влизане.

VAS носителят съдържа собствен идентификационен номер или парола (PIN). Това се използва за идентификация на притежателя на карта чрез VERIFY команда. PIN е свързан с операционния брояч за грешки, който регистрира всяко фалшиво включване и който за постигане на ограничение блокира PIN сравнението. Това блокиране може да бъде променено обратно от системния оператор, използвайки съответните администриращи команди. Операционният брояч на грешки е върнат обратно, веднъж верният PIN е бил въведен.

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

• р максимален брой задачи от групата за изпълнение ОР_РТ-максимален брой VAS заявки от групите заявки Точкова памет и Би30

EF.TRANSFER Лична информация на VAS изпълнителя: EF_KEY(p+a) EF_INFO(p+a) EFJNTERNAL EF_VALUEp

8*nrEF_TRANSFER ♦32 *62 p*10 *3

Ако уточним, т.е. за параметрите р, а и nrEF_TRANSFER, следващите стойности, то е необходим следващият минимум обем памет за VAS носителя (без необходимия обем памет за допълнителните команди):

Параметри: Необходим обем памет:

р=8, а=3, nrEF_TRANSFER=15 2030 байта p-10, а=5, nrEF_TRANSFER=20 2758 бай Максималният необходим обем памет трябва да бъде по-голям поне около 10% от минимално необходимия обем памет.

Командите на чипкартата съгласно изобретението разгледани по-детайлно по-нататък.

READ RECORD командата се използва за четене с извеждане на информация от линейните Елементарни файлове. В отговор кар50 тата запълва съдържанията на записите. EF е проверен чрез Краткия Идентификатор (SFI). Кодът за състояние ‘9000’ сигнализира за сполучливото изпълнение на командата; всеки различен от него код се счита за грешен.

UPDATE RECORD командата се използва най-вече за въвеждане на данни в записите на линейния EF. Съобщението на командата съдържа проверката на EF записа и данните .

Отговорът на картата съдържа кода на състоянията. Кодът на състоянията ‘9000’ сигнализира за сполучливото приключване на командата. Други кодове за състояние показват наличие на грешка.

GET CHALLENGE командата изисква от картата случаен номер. Случайният номер се използва за свързване с динамичното условие за автентичност в EXTERNAL AUTHENTICATE.

Съответното съобщение на картата съдържа случаен номер с 8 бита дължина и код на състоянието. Кодът на състоянието ‘9000’ показва сполучливото изпълнение на командата. Всички различни от него кодове показват грешка.

Командата EXTERNAL AUTHENTICATE осъществява проверката на терминал посредством картата. EXTERNAL AUTHENTICATE се използва в контекста на VAS заявките за проверка на автентичност от системния оператор и VAS изпълнителя. EXTERNAL AUTHENTICATE обменя криптограма в картата, която предварително е била създадена чрез терминала чрез кодиране на случаен номер. Картата сравнява криптограмата с проверена стойност, която е пресметната от самата нея, използвайки същата процедура. Ако и двете стойности са еднакви, картата отбелязва вътрешно, че съответствието на автентичността за обмен за този ключ е налице. Ако съответствието се окаже отрицателно, картата ще отбележи състояние “неоторизиран” и постановява грешка за вътрешния операционен брояч. Когато този брояч срещне стойност “0”, всякакво по-нататъшно изпълнение на EXTERNAL AUTHENTICATE е блокирано със състоянието “автентичност блокирана”.

Съответното съобщение на картата съдържа кода за състояние. Сполучливото изпълнение на командата за автентичност на терминала съвместно с картата е показано чрез кода на състоянието ‘9000’. Всякакви различни кодове за състояния показват грешка.

Командата INTERNAL AUTHENTICATE се използва най-вече за проверка на автентичността на VAS носителя чрез терминал. Картата за тази цел пресмята криптограма чрез проверка на данните, подадени от терминала. Терминалът при обръщението си формулира криптограмата и я сравнява със стойността на картата. В случай на еднаквост терминалът може да приеме автентичността на VAS носителя.

Отговорът на картата съдържа криптограмата и кода на състоянието за изпълнение на командата. Сполучливото изпълнение на командата е показано чрез кода на състоянието ‘9000’. Всички различни от него кодове на състояние показват грешка.

VERIFY командата се използва за потвърждение на PIN на притежателя на картата. Командата обменя PIN информацията, декодирана за картата, където се извършва сравнение със съхранената проверена стойност. Ако въведената и съхранената стойност са идентични, условията за обмен “PIN” се зачитат за съобразени.

Съответното съобщение на картата съдържа кода на състояние. Кодът на състояние ‘9000’ показва сполучливо изпълнение на командата. Други кодове на състояние показват грешка.

TRANSFER командата разрешава влизане в паметта за обмен. За командата са дефинирани следните три начина за обмен:

1. Разрешение за влизане в областта на обмен чрез преобразуване на стойностите в EF_VALUE областта на заявката за групата Билет или Точкова памет.

2. Разрешение за влизане в областта на обмен чрез създаване на условие в заявката за групата Идентифициращ документ.

3. Разрешение за влизане в областта на обмен чрез създаване на платежен документ в заявката от групата Платежен документ.

Начинът за действие е автоматично избран от картата: Ако командата е изпълнена вътре в избраната заявка DF представянето на EF_VALUE най-напред е проверено. Ако EF_VALUE е налице, картата изпълнява командата по начин 1, обратно на начин 2.

Ако във VAS носителя не е била избрана заявка DF, се използва начин 3.

Терминалът, когато е посочен за TRANSFER командата, зарежда картата със следните данни:

• Текущи данни;

Изходни (начални) данни за влизане в областта на обмен;

• Идентификация за терминала, която разрешава това влизане;

• Полезни данни за областта на обмен;

• PIX на VAS заявката (само начин 3);

• Брой на точките, които трябва да бъдат изведени (само начин 1);

• МАС, съдържащ по-горе споменатите данни, последователен номер и номер на VAS носителя.

Картата, при веднъж извикана TRANSFER команда, изпълнява следния ред от действия:

1. Проучване за свободно влизане в паметта за обмен. (Следващият списък изпълнява в обратен ред приоритета, в който съществуващите влизания трябва да бъдат презаписани: ’’Влизане, маркирано като прехмърляне”, “влизане, маркирано като извеждане” и “изчезнали (загубени) данни срещнати”.

2. Прилагане на PIX към данните на терминала при начин 1 и 2.

3. Прилагане на последователния номер към данните от стъпка 2.

4. Прилагане на VAS носителя към данните от стъпка 3.

5. Създаване на KGKdec.pix чрез кодиране на PIX според KGKdec.

6. Създаване на Kdec чрез кодиране на терминала ID според KGKdec.pix.

7. Създаване на МАС чрез данните от стъпка 4.

8. Сравняване на МАС от стъпка 7 с МАС от терминала. Ако стойностите са различни, картата прекъсва действието и подчинява грешно действуващия брояч на KGKdec.

9. За начин 1: Тестуване на областта за стойностите на паричните средства EF_VALUE в регистъра, в който е била въведена заявката. Ако са представени недостатъчно средства в тази област, картата прекъсва действието в тази точка. С други думи, областта за стойности в заявката е подчинена на това количество.

10. Инсталиране на съобщението на командата.

11. Отстраняване на съдържанията на EF_SEQ чрез 1.

Съобщението на командата съдържа, например области, включващи; изчезналите (загубените) данни, терминалът ID, данните за сделката, област за начина на действие (съдържания, т.е. в начин 3, PIX), както и криптограма.

Криптограмата е пресметната да ползва ключа Kdec, данните, формирани чрез МАС, 5 например, включващи в себе си данните за сделката и терминала ID.

Ответното съобщение от TRANSFER командата включва, когато е сполучливо, информационна област с 8 байта дължина и ко10 да за състояние ‘9000’, който е с 2 байта дължина. Ответни съобщения с кода за състояние, различен от ‘9000’, се считат за грешни кодове. Информационната област на ответното съобщение съдържа в свободно от грешка положение (т.е. по-точно криптограмата на съобщението на командата е била вярна), криптограмата е кодирана с KDEC от съобщението на командата. По този начин (вместо вътрешна автентичност се използва KAUT). Условието за автентичност е изпълнено безусловно от VAS изпълнителя.

Командата ТАКЕ служи за извеждане на задачи от групата за изпълнение EF_ TRANSFER. Технически, изпълнението на командата ТАКЕ означава четенето извън запис да бъде отбелязано от паметта EF_TRANSFER, записът се запомня в паметта, докато там не се почувства нужда от обем за ново въвеждане. Информационният пакет е маркиран като “изтеглен”. Разгледано технически никой не може да използва командата ТАКЕ, за да изтегли информационен пакет, обаче съгласно R&R, само VAS носителят, за който информационният пакет е бил предназначен, би могъл да направи това.

За преместващата (прехвърляща) процедура може да бъде допуснато следното: VAS изпълнителят, който желае да прехвърли платежен документ или разписка, търси съответен информационен пакет в паметта за обмен (т.е. чрез командата SEEK или чрез изрично четене на всеки запис). Информационният пакет, във всеки случай ще бъде прочетен и неговото съдържание може да бъде проверено.

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

Командата ТАКЕ се изпълнява за следващите случаи:

• Прехвърляне с едновременно отбелязване, че информацията е била невалидна;

• Прехвърляне без посоченото отбелязване. Това означава, че информацията е валидна.

Съобщението на командата съдържа области с терминал-ID, PIX на заявката и случаен номер, създаден от терминала.

PIX в командата отбелязва заявката, която прехвърля информация. Чрез PIX тя може да се отдели от информационния пакет, който е бил прехвърлен. Това служи изключително за създаване на KDEC от дилърския терминал, който осъществява прехвърлянето.

Съответното съобщение на картата съдържа криптограмата Cl с KSIG.VASC, състоящо се от информацията на записите в областта на обмен, представена (предадена) в съобщението на командата и VAS носителя ID, криптограма С2 с KDEC на терминала,осъществяващ прехвърлянето чрез С1, и случайния номер, носен от съобщението на командата. Съответното съобщение в допълнение съдържа код на съобщенията. Ключът KDEC се създава, както е описано, по-горе. Автентичността е безусловно изпълнена за VAS носителя по силата на криптограмата чрез KDEC. Доказателство за автентичността и уникалността (един единствен път) се изчислява чрез средствата на криптограмата С (от С е формиран чрез последователния номер прехвърлящ бит на записа от областта на обмен и VAS носителя ID), което може да бъде проверено и потвърдено от системния оператор.

Кодът на състояние ‘9000’ показва успешно изпълнение на командата. Различаващи се от него кодове на състояние се считат за грешки.

Може да се допусне, че SO изисква един AIDvas, съгласно IDO/IEC 7816-5. По-специално той изисква RIDVAS с 5 байта дължина за VAS системата.

AIDvas от списъка DF_VAS трябва да се чете: AIDvas=RIDvas.PIXdf_vas.

За всяка VAS заявка А е разрешен PIXa с 3 байта дължина, в съответствие с R&R, за да идентифицира недвусмислено първия в рамките на VAS носителя чрез AIDa=RIDvas.PIXa. След избора на DF_VAS списък, в който се съдържа VAS заявка А, може да бъде избрано използване на SELECT FILE <PIXa>.

UPDATE KEY (KID,K) означава команда, която се отнася до платката на картата, чрез която се прехвърля ключ за нова стой ност К, използвайки ключовия идентификатор ID.

Преди да бъде изведена VAS заявка от една от групите за изпълнение DF_PT или DF_AD (съответствуващи на групите заявки Точкова памет, Билет, Идентификационен документ или Информационна база данни) и да може да бъде оползотворено от притежателя на карта от дилърския терминал, то трябва да бъде въведено във VAS носителя от терминал за услуга от упълномощения VAS изпълнител. По принцип това е възможно само когато изходният отвор за карта, инструктиран от VAS изпълнителя и SO, въвежда една или повече заявки във VAS носителя едва когато VAS носителят е инсталиран. Такъв начин на въвеждане предполага специален случай, който е описан съгласно изобретението.

Процедура за въвеждане на VAS заявка:

1. Притежателят на карта поставя VAS картата в терминала за услуги.

2. Терминалът за услуги търси къде се намира VAS носителят:

• SELECT FILE <AIDvas> (грешен отговор, ако VAS носителят не е избираем) ;

• READ RECORD <SFI на EF_ID, 0> (на дисплея се показва номерът на VAS носителя).

Незадължително, се установява валидността на VAS носителя. За това терминалът за услуги изисква установяване на вътрешната автентичност на VAS носителя:

• INTERNAL AUTHENTICATE < случаен номер, KID на KAUT >

Терминалът за услуги търси съответствие и в случай на грешка (с грешка на дисплея) прекъсва процедурата.

3. Терминалът за услуги предлага на притежателя на карта избор от няколко възможности. Една от тях е въвеждане на VAS заявка. Избира се от притежателя на карта. Всички VAS заявки, които могат да бъдат въведени от терминала за услуги, вече са показани на притежателя на карта и се очаква изборът. За тази цел операцията показване на VAS заявки е активирана. Притежателят на карта избира VAS заявка от групата за изпълнение DF_PT или DF_AD.

4. Терминалът за услуги проверява VAS носителя чрез операцията избор на VAS заявка, както и дали избраната VAS заявка, има25 ζ

,/ ща ΡΙΧα, е била вече въведена в картата. При потвърждение се показва грешен сигнал на дисплея. Ако няма, прави се проверка дали задача от групата за изпълнение, принадлежаща на А, е с току що установена достъпност във VAS носителя. Това се отнася до търсене на свободно място за запис в EF_DIR (т.е. използване на командата SEEK). Ако нищо не е достъпно, се показва грешен сигнал на дисплея. Ако има свободно място за запис, това включва FIDDF_X на DF_X, в който не е била въведена VAS заявка.

5. Следващата свободна задача от групата за изпълнение, принадлежаща на А, при това, се въвежда с VAS заявката А. За тази цел терминалът за услуги пръв изисква off-line от VAS изпълнителя (т.е. чрез VAS изпълнител SAM) два ключа KLVASP и KRVASP и ги отбелязва към новата VAS заявка:

• SELECT FILE < FIDDF_X >

• GET CHALLENGE • EXTERNAL AUTHENTICATE < KSO (случаен номер), KID на Kso>

• UPDATE KEY < KID от KLVASP, K RVASP>

• UPDATE KEY < KID от Klvasp, Krvasp>

• GET CHALLENGE

EXTERNAL AUTHENTICATE < Klvasp (случаен номер), KID от Klvasp>

• UPDATE RECORD < SFI на EF_INFO от DF_X, данни>

UPDATE RECORD < SFI на EFJNTERNAL от DF_X, данни >

• Незадължителен (инициализиращ): UPDATE RECORD < SFI на EF_VALUE от DF_X, данни >

6. След сполучливо въвеждане в EF-те терминалът за услуги изпълнява операцията въвеждане на VAS 3aaeka<PIXA,FIDDEX>, която свързва DF_X с PIX и затова изпълнява SELECT FILE чрез средствата на ΡΙΧα (след предварителен избор чрез SELECT FILE AIDvas) .

Механизмът създава възможност чрез паметта за обмен да може, например същият да бъде използван от VAS изпълнители, които желаят да изпълнят вътрешни или взаимни услуги без собствените DF-структури. Притежател на карта, по-специално, преди да използва такава VAS заявка, не се нуждае първо да я въведе от терминал за услуги. Обратно, той може да изведе за себе си директно на дилърски терминал платежен документ или разписка и да има тази възможност (привилегия) от различен терминал (чрез операцията прехвърляне или само показване на платежния документ или разписката (за четене). Въвеждане на VAS заявка в групата за изпълнение EF_TRANSFER следователно, се осъществява безусловно чрез въвеждане на VAS информация или е предизвикано от същата операция. В този контекст прави се препратка към описанието на покупката в групата за изпълнение EF_TRANSFER, както следва по-долу.

Последователността на операциите за въвеждане на VAS заявки е описана по следния начин:

Ако VAS заявката е била въведена във VAS носителя, терминалът няма да знае физическото местоположение в коя DF_X, ката X означава» РТ1,...,РТр, ADl,...,ADa, VAS заявката е била въведена или къде тя е била въведена изобщо. От гледна точка на производителя на картата са допустими два възможни начина за изпълнение, които са за разделно търсене; в този контекст, близостта със ZKA стандарта трябва да бъде частично спазена.

Първи случай: Достъп до EF_DIR е възможен.

Трябва да се имат предвид следващите препоръки:

• EF_DIR (т.е. от DF_VAS), в който AIDте са разположени с FID-ве от DF_X, в който VAS заявките обикновено се намират, съществува по стандартен начин в платката на картата.

Този EF_DIR може да бъде четен от всеки (АС от READ RECORD: ALW).

• Ако VAS заявката А с ΡΙΧα е въведена от системния оператор в свободен (неизползван) DF_X, т.е. влизане е осъществено в съществуващите Елементарни файлове DF_X (не CREATE FILE), би трябвало тогава да е възможно да се разпростре информационната база данни EF_DIR за въвеждането ΡΙΧα чрез средствата на UPDATE RECORD, която се отнася за този DF_X чрез FIDX. АС на UPDATE RECORD би трябвало следователно да наблегне на установяването на външната автентичност чрез средствата на ключа Kso.

• Ако командата SELECT FILE < PIXa> след предварителен подбор на DF_VAS е предадена на картата, DF_X, в който VAS заяв26 ката А е била въведена, би трябвало да бъде директно избираем.

• Ако VAS заявката А, въведена в DF_X и съответните му Елементарни файлове, се изтрие от терминала за услуги по искане на притежателя на карта, съответните бази данни не се изтриват чрез DELETE FILE, но въведените данни са записани единствено с фиктивни стойности. След това е необходимо да се изтрие от EF_DIR въведеният PIXA (по-специално двойката PIXA и препратката към DF_X) (например чрез UPDATE RECORD с предварително установена външна автентичност посредством ключа Kso).

• След като броят на DF_X е фиксиран, броят на записите на EF_DIR се знае.

Ако този подход е реализуем, се постигат следните резултати:

• Директин избор на VAS заявка, използвайки SELECT FILE ΡΙΧα, е възможен след избор на DF_VAS.

Втори случай: Достъп до EF_DIR не е възможен.

В случай че в част от платката на картата EF_DIR не е достъпен или не може да се чете, или достъпът за запис до този EF_DIR (както е описано в предходния параграф) е невъзможен, зареждане може да се направи под управлението на DF_VAS за база данни EF_VASDIR, за свързване да се използва ΡΙΧα, за въвеждане на VAS заявка на нейното физическо място от паметта в DF_X, предизвикано от системния оператор чрез изрични UPDATE RECORD команди (след предварително установяване на външна автентичност посредством KSO).Четене и изтриване на записи от EF_VASDIR би било възможно, както е описано преди.

Изпълнението на операцията за въвеждане на VAS заявка протича както следва:

VAS заявка А, включваща PIXA, найнапред е била въведена в свободен DF_X с FIDdex. Номерът на записа, съдържащ FIDdex, се отбелязва от терминала за услуги.

1. SELECT FILE < AIDvas >(грешка на дисплея, ако VAS носителят е неизбираем).

2. GET CHALLENGE

3. EXTERNAL AUTHENTICATE < Kso (случаен номер), KID от Kso >

4. UPDATE RECORD < EF_DIR от DF_VAS, номер на запис c FIDDF_X, PIXA, FIDDF_X >

VAS заявки от групите за изпълнение DF_PT или DF_AD могат да бъдат само изтривани по искане на притежателя на карта от терминала за услуги (бидейки под контрола на системния оператор), VAS заявки от групата за изпълнение EF_TRANSFER могат да бъдат изтрити навсякъде и от всеки. Когато се изтрива, необходимо е да се прави разлика между VAS заявки от групите за изпълнение DF_PT и DF_AD, респ. групата за изпълнение EFTRANSFER.

Изтриване на такава VAS заявка от групата за изпълнение DF_PT или DF_AD протича, както следва:

1. Притежателят на карта поставя VAS картата в терминал за услуги.

2. Терминалът за услуги търси къде се намира VAS носителят.

• SELECT FILE < AIDvas > (грешка на дисплея, ако VAS носителят не е избираем)

READ RECORD <EF_ID > на дисплея се показва VAS носителят ID)

3. Терминалът за услуги обслужва притежателя на карта с избор на няколко възможности. Една от тях се чете катоизтриване на VAS заявка. Избира се от притежателя на картата. Всички VAS заявки от всички групи за изпълнение, въведени във VAS носителя, сега са показани на дисплея за притежателя на карта и се очаква неговият избор. За тази цел се активира операцията показване на VAS заявки . Притежателят на карта избира VAS заявка А от групата за изпълнение DF_PT или DF_AD чрез средствата на AIDA. Задачата, с която VAS заявката е била въведена, се приема да бъде отбелязана DF_A.

4. След избора на DF_A, терминалът за услуги установява автентичността му.

• SELECT FILE < ΡΙΧα >

• GET CHALLENGE • EXTERNAL AUTHENTICATE < Kso (случаен номер), KID от Kso >

5. Съдържанието на файловете на DF_A сега се изтрива (Klvasp се изисква за EF_KEY, EFJNTERNAL и EF_VALUE, по чието условие от системния оператор най-напред се изтрива първият) :

• UPDATE KEY < KID от KLVASP, “00...00” >

• UPDATE KEY < KID от KRVASP, “00...00” >

• GET CHALLENGE • EXTERNAL AUTHENTICATE < Klvasp(случаен номер), KID от Klvasp >

UPDATE RECORD < SFI на EFJNFO от DF_A, “00...00”>

• UPDATE RECORD < SFI на EFJNTERNAL от DF_A, “00...00”>

• UPDATE RECORD < SFI на EF_VALUE от DF_A, “00...00” >

б.След сполучливи влизания в EF-те, терминалът за услуги предизвиква да бъде изтрит записът на VAS заявката от EF_DIR.

• SELECT FILE < AIDvas > ( грешка на дисплея, ако VAS носителят е неизбираем) • UPDATE RECORD < SFI на EF_DIR от DF_VAS, номер на запис с FIDDF_A, “00...00”, FIDDF_A >

Взаимното свързване на PIXa с DF_A не е извършено заради SELECT FILE с PIXA, незадълго възможен .

Следва групата за изпълнение EFJTRANSFER:

VAS заявка от групата за изпълнение EF_TRANSFER, в съответствие с R&R, може само да бъде изтривана по изричното искане на притежател на карта от дилърски терминал или терминал за услуги (понякога се мисли, че това би могло да бъде технически възможно и за двата случая). Изтриването на задача от EF_TRANSFER става необходимо, по-специално, ако паметта за обмен няма повече място (свободен обем) за съхраняване на нова задача (т.е. платежен документ или разписка). Изтриването се осъществява винаги индиректно (косвено) чрез допълнителната команда ТАКЕ. Тази команда само маркира задача, както при прехвърляне. Едва след това е свободно да се премине по-нататък чрез следващата допълнителна команда TRANSFER. Изтриването на тази VAS заявка протича, както следва:

1. Притежателят на карта поставя VAS картата в терминал, способен да покаже на дисплея съдържанието на EF_TRANSFER (специален случай на показваща операция на VAS заявки).

2. Терминалът проверява (търси) къде се намира VAS носителят:

• SELECT FILE < AIDvas > (грешка на дисплея, ако VAS носителят е неизбираем) • READ RECORD < SFI на EFJD, 0 > ( на дисплея се показва VAS носителят ID)

3. Терминалът прави възможен за прите- жателя на карта избор от няколко възможности. Една от тях се чете като изтриване на VAS заявка. Избира от притежателя на карта. Накрая VAS заявките от групата за изпълне5 ние EF_TRANSFER се показват сега на дисплея за притежателя на карта и се извършва избор. Това се взема предвид като специален случай на операцията показване на VAS заявки. Притежателят на карта избира задача от групата за изпълнение , включваща платежен документ или разписка. Тази задача има номер на запис А. Притежателят на карта активира избора.

4.Терминалът маркира записа с номера на запис А, като при прехвърляне на който се предава А, случаен номер, пресметнат от него, неговият PIX и терминал ID, използвайки командата ТАКЕ:

• ТАКЕ < А, случаен номер, PIX терминал ID >

Записът се маркира, като че е бил прехвърлен, сега мястото е достъпно отново за приемане на нов платежен документ или разписка.

Изборът на VAS заявка се осъществява, както следва:

В случай че VAS заявка А от групата за изпълнение DF_PT или DF_AD е била въведена във VAS носителя чрез операцията въвеждане на VAS заявка, това може да се осъществи от терминал на два етапа. Първо се избира VAS носителят и след това VAS заявката, включваща нейния PIXA:

1. SELECT FILE < AIDVAS > (грешка на дисплея, ако VAS носителят е неизбираем)

Необходимо е терминалът за услуги да провери автентичността на VAS носителя. За тази цел терминалът за услуги запитва (проверява) за вътрешната автентичност на VAS носителя:

• READ RECORD < SFI на EFJD, 0 > (на дисплея се показва носителя ID) • INTERNAL AUTHENTICATE, случаен номер, KID от KAUT >

Терминалът за услуги проверява съответствието и прекъсва операцията в случай на грешка (с грешка на дисплея).

2. SELECT FILE < PIXa > (грешка на дисплея, ако VAS заявка А не е била въведена във VAS носителя)

Дилърски терминал (който няма валиден KGKAUT) може индиректно да определи автентичността на VAS носителя чрез проверка на автентичността на VAS заявката А. Това е така, защото VAS заявка може само да бъде въведена от терминал за услуги, който по време на въвеждащата процедура е проверил автентичността на VAS носителя. Автентичността, проверена за VAS заявката А, може да бъде подложена отново на тест от дилърския терминал, когато VAS носителят съдържа Klvasp или KRVASP за VAS заявката А. Това може да бъде проверено чрез дилърския терминал, например както следва:

• INTERNAL AUTHENTICATE <случаен номер, KID от Krvasp или Klvasp >

В случай на тест, когато VAS заявка А е въведена във VAS носителя, може да се избира случайно; базирано на грешката върху дисплея в съответното съобщение на SELECT FILE, решението може да бъде взето така, че да не се осъществи.

Избор на VAS заявка от групата за изпълнение EF_TRANSFER се осъществява безусловно чрез операцията показване на VASзаявки и информационната памет на терминала. Щом терминалът знае номера на запис на всяка показана заявка от EF_TRANSFER, възможно е да се избере накоя желана заявка за по-нататъшна обработка с препратка към номера на запис.

Изпълнението на показването на VAS заявка се осъществява, както следва:

Операцията показване на VAS заявки разлиства (изрежда) на екрана на терминала за услуги списъка на всички VAS заявки от групата за изпълнение DF_PT, DF_AD и EF_TRANSFER. Само VAS заявката от групата за изпълнение EF_TRANSFER може да бъде показана на дисплея на дилърски терминал, защото отсъствува защита за такъв достъп, и незадължително, също така, за заявки от групите за изпълнение DF_PT или DF_AD, за които дилърският терминал има право да чете (притежава Krvasp).

Всичко това за VAS заявка се осъществява, както следва:

1. Притежателят на карта поставя VAS картата (чипкарта с валиден VAS носител) в терминала.

2. Терминалът за услуги търси къде се намира VAS носителят:

• SELECT FILE < AIDvas > (грешка на дисплея, когато VAS носителят е неизбираем) • READ RECORD < SFI на EF_ID, 0 >(на дисплея се показва VAS носителя ID)

Незадължително валидността на VAS носителя се проверява. За тази цел терминалът за услуги запитва (проверява) вътрешната автентичност на VAS носителя:

• INTERNAL AUTHENTICATE< случаен номер, KID от KAUT >

Терминалът за услуги проверява съответствието и в случай на грешка (с грешка на дисплея) прекъсва процедурата.

3. Терминалът за услуги представя на притежателя на карта избор от няколко възможности. Една от тях се чете показване на VAS заявки. Тази се избира от притежятеля на карта.

4. Терминалът за услуги установява автентичността му:

• GET CHALLENGE • EXTERNAL AUTHENTICATE < KSO (случаен номер), KID от KSO >

5. За VAS заявки от групите за изпълнение DF_PT и DF_AD са избрани отделни VAS заявки, обработвани последователно чрез съдържанията на EF_DIR и, след установяване на външна автентичност с ключа KSO, съдържанията на отделния EF_INFO (или част от него съгласно R&R), както и EF_VALUE се показват на дисплея:

• За i=0,..., nrDIR - 1 • READ RECORD , SFI на EF_DIR, I >

В ответното съобщение на дисплея се показва PIXA, който е “00...00”, ако съответният DF не е въведен с VAS заявка. Като алтернатива на READ RECORD от EF_DIR е възможно също да се използва SEEK команда.

• Ако PIXa не е равно на “00...00” • SELECT FILE < PIXa >

• READ RECORD < SFI на EFJNFO, 0>

• Показване на дисплея (незадължително, само частично) на ответното съобщение • READ RECORD < SFI на EF_VALUE, 0 >

• SELECT FILE < AIDVAS >

6. 3a VAS заявки от групата за изпълнение EF_TRANSFER съдържанията (или части от тях съгласно R&R) на EF_TRANSFER от всеки запис се показват на дисплея:

• SELECT FILE < AIDVAS >

• Ако i=0,..., nrEF_TRANSFER -1

READ RECORD < SFI на EF_TRANSFER , i >

(ответното съобщение показва на дисплея съдържанията на i - записа от EF_TRANSFER) • Ако съдържанията не са пълни, те се показват на дисплея в обработена форма (нап- 5 ример изведени/изтрити).

Показването на заявките от групите за изпълнение DF_PT или DF_AD, за които дилърският терминал има право да показва (притежава Krvasp), се осъществява като описа- 10 ние - предмет на две размени. Например, установяване на автентичност с ключа Krvasp се използва вместо Kso, който е допустим само за системния оператор. Ако дилърски терминал няма валиден KGKaut и въпреки това 15 желае да провери автентичността на VAS заявките, дилърският терминал вместо за вътрешна автентичност може да проверява автентичността (поне на една) на VAS заявка. Това се осъществява като описание чрез разпозна- 20 ване на картата от съответните Krvasp или Klvasp ключове.

За VAS заявките от групата за изпълнение EF_TRANSFER съдържанията (или част от тях съгласно R&R) от EF_TRANSFER на 25 всеки запис са разлистени (подредени, разгънати) последователно в списък, както беше описано преди.

Операцията обработка на VAS заявки протича в следния ред. За тази цел термина- 30 лът предлага на притежателя на карта възможността обработка на VAS заявки за избор. Допълнително към информацията, която започва да се показва на дисплея, съответно на операцията показване, възможно е също 35 така да се покаже на дисплея информация от EF_INFO и EF_VALUE, които изискват обработка от страна на VAS изпълнителя, например външно кодирана информация, и информация от EF_TRANSFER, например храни от 40 предишни години с Храни & Други. Това понякога е възможно само за VAS заявки, за които VAS изпълнителят (от гледна точка на неговите собствени възможности) прави възможни съответните ключове на терминала. Ключът 45 Klvasp (външна автентичност) се използва за четене на EF_INTERNAL на VAS заявка. За външно кодирана информация в Елементарните файлове EF_INFO, EF_INTERNAL и EF_VALUE, както и в паметта за обмен 50 EF_TRANSFER се използват собствените ключове на VAS изпълнителя.Терминалната прог рама може чрез четене да разграничи с помощта на PIX избрана VAS заявка, за която ключовете за заявки са достъпни за обработка на информацията.

Операцията обмен на VAS заявки се отнася до обмена на всички или до избраните VAS заявки от съдържанието на картата в самата карта, поставена в терминала за услуги. Може да се направи заключение, че във VAS носителя на самата карта не всички VAS заявки са въведени и че след обмена всички VAS заявки се изтриват от съдържанието на картата. И двата случая могат да бъдат съпроводени от последователните приложения на операцията изтриване на VAS заявки. Още повече, автентичността на VAS картата трябва да бъде проверена и самата карта трябва да бъде запълнена адекватно на обема памет. Самата операция за обмен се базира главно на разпростирането на операцията показване на VAS заявки, за която допълнително се чете информацията от EF_INTERNAL и ключовете Klvasp и Krvasp и за повторна заявка се базира на операцията въвеждане на VAS заявка.

Заедно с VAS информацията VAS носителят ID, разбира се, обменя за картата последователно VAS заявките от самата карта за незабавно изпълнение, точно както те са записани в картата. Правилата, по които тези ключове са създадени от VAS изпълнителя, се съхраняват от VAS носителя ID, като ключовете понякога се повтарят без промяна. Още повече, VAS изпълнителят не смята да променя своето изчисление в базовата система, защото той обикновено идентифицира VAS картите чрез VAS носителя ID. Съществено е да се осигури по време на обмена от VAS носителя ID този номер, (който единствен) за системата да се изтрие от съдържанието на картата.

За да бъде възможно специално да се четат Елементарния файл EF_INTERNAL и ключовете Klvasp и Krvasp, терминалът за услуги след установяване на външна автентичност чрез средствата на ключа Kso (като при операция изтриване на VAS заявка) първо презаписва ключа Klvasp и тогава след възобновено установяване на автентичност с Klvasp презаписва информацията от EF_INTERNAL.

В допълнение към VAS заявките от групите за изпълнение DF_PT и DF_AD, файлът EF_TRANSFER трябва да бъде презаписан. За тази цел се използва последователно опера30 цията преместване (прехвърляне) за прехвърляне на задачи от тази група за изпълнение, които не са били все още маркирани като прехвърлени или изтрити (изчезнали), проверява се тяхната сигнатура чрез KSIG_VASC и се изпълнява обменът в EFJTRANSFER от самата карта. В самата карта, от друга страна, задачите са отбелязани като непрехвърлени, така че те остават валидни (действителни).

Накрая, трябва да бъде обменена общодостъпната информация на VAS носителя . Поспециално последователният номер от самата карта трябва да бъде прибавен към стойностите от съдържанието на картата.

Процедурата за въвеждане на VAS информация е описана, както следва:

Има три възможни случая за въвеждане на VAS информация от дилърски терминал, които се отнасят до естеството на VAS заявката.

Първо, покупка в случая на група за изпълнение DF_PT или DF_AD.

VAS изпълнител въвежда информация във VAS заявка А от групата за изпълнение DF_PT или DF_AD.

Въвеждането на VAS информация се осъществява, както следва:

1. Притежателят на карта поставя VAS картата в дилърски терминал.

2. Дилърският терминал проверява къде се намира VAS носителя:

• SELECT FILE < AIDvas > (грешка на дисплея, ако VAS носителят е неизбираем) • READ RECORD < SFI на EF_ID, 0 > (показване на дисплея на VAS носителя ID)

3. Проверява се автентичността на VAS носителя.

Ако дилърският терминал притежава главния ключ KGKaut, той може да установи външната автентичност на VAS носителя:

• INTERNAL AUTHENTICATE < случаен номер, KID от Kaut >

Дилърски терминал (който няма възможността на KGKaut) може индиректно (косвено) да провери автентичността на VAS носителя чрез проверка за автентичност на VAS заявката А. Правилата са такива, че VAS заявка може да бъде само въведена от терминал за услуги, който по време на въвеждането проверява автентичността на VAS носителя. Автентичността, проверена за VAS заявката А , може да бъде отнесена обратно към теста на дилърския терминал, където VAS носителят съ държа ключа Klvasp или ключа Krvasp за VAS заявката А. Това може да се провери чрез дилърския терминал, например чрез:

• SELECT FILE < PIXa > (грешка на дисплея, ако VAS заявката А не е въведена във VAShoot^r) • INTERNAL AUTHENTICATE < случаен номер, KID от Krvasp или Klvasp >

Дилърският терминал проверява съответствието и в случай на грешка ( с грешка на дисплея) прекъсва процедурата.

4. Дилърският терминал избира VAS заявката А, проверява я за автентичност и описва Елементарните файлове, които са необходими за изпълнение на сделката:

• SELECT FILE < PIXA > ( осуетен, ако е изпълнено това от стъпка 3) • GET CHALLENGE • EXTERNAL AUTHENTICATE, Klvasp (случаен номер, KID от Klvasp >

• незадължително: UPDATE RECORD < SFI на EFJNFO от DF_X, данни>

незадължително: UPDATE RECORD < EFI на EF_INTRNAL от DF_X, данни >

незадължително: UPDATE RECORD <SFI на EF_VALUE от DF_X, данни >

Сега следва покупка в случай на група за изпълнение EF_TRANSFER.

Специално за VAS заявки от групата за изпълнение EF_TRANSFER (група заявки Платежен документ) на VAS изпълнителя не е необходимо да разполага със собствен файл от структурата DF_X за своята заявка. Отговорът е такъв, че на притежателя на карта не е необходимо, преди да използва платежен документ от VAS заявка, да отиде до терминал за услуги, за да въведе VAS заявка. Той може, по-скоро, директно от дилърски терминал, да въведе платежен документ или разписка и да направи тези разплащания от друг терминал (чрез операцията прехвърляне) или само да покаже платежния документ или разписката (чрез четене). Въвеждането на VAS информация е съответно на отговорите при безусловно въвеждане на VAS заявки в групата за изпълнение EF_TRANSFER. За тази група заявки групата за изпълнение EF_TRANSFER проверява какво е зададено в индивидуалните задачи от записа. Влизане в EF_TRANSFER е възможно изключително чрез командата TRANSFER. За тази цел дилърският терминал трябва да притежава валиден ключ за анулиране

KDEC и трябва да има достъпен PIXA на VAS заявката А.

Въвеждането на VAS информация се осъществява, както следва:

1. Притежателят на карта поставя VAS картата в дилърския терминал.

2. Дилърският терминал проверява къде се намира VAS носителят:

• SELECT FILE < AIDvas > (грешка на дисплея, ако VAS носителят е неизбираем) • READ RECORD < SFI на EF_ID, 0 > ( на дисплея се показва номерът на VAS носителя

3. Дилърският терминал чете последователния номер, който допълнително въвежда МАС от стъпка 4:

• READ RECORD < SFI на EF_SEQ, 0 > (на дисплея се показва последователният номер)

4. Командата TRANSFER предизвиква да бъде въведен запис в EF_TRANSFER:

• TRANSFER < данни за сделката, изчезнали данни, код за създаване, данни, PIXa, MAC с Kdec >

5. Дилърският терминал може да провери чрез проверка на ответното съобщение от TRANSFER командата дали VAS носителят е достоверен (т.е. в притежание на взаимния секрет Kdec). В този контекст, избор, също така направен при ответно съобщение, следващо командата TRANSFER, е описан по-горе.

Накрая, покупка на VAS информация чрез анулиране на стойности.

VAS изпълнител може чрез стъпка за анулиране на стойности, използваща командата TRANSFER в областта на обмен EF_TRANSFER, да създаде право ( например платежен документ или разписка), което може да бъде използвано по-нататък от друг VAS изпълнител. Информацията от EF_VALUE или EF_INFO на VAS заявката А се анулира от VAS изпълнителя, предизвикващ анулирането. Притежателят на карта придобива правото си под формата на задача в EF_TRANSFER.

Въвеждане на VAS информация се осъществява, както следва:

1. Притежателят на карта поставя картата в дилърския терминал.

2. Дилърският терминал проверява къде се намира VAS носителят:

• SELECT FILE < AIDvas > (грешка на дисплея, ако VAS носителят е неизбираем) • READ RECORD < SFI на EF_ID, 0 > ( на дисплея се показва VAS носителя ID)

3. Дилърският терминал чете последователния номер , който, в допълнение, въвежда

МАС, както при стъпка 4:

• READ RECORD < SFI на EF_SEQ,0 >(на дисплея се показва последователният номер)

4. Дилърският терминал избира VAS за10 явката А:

• SELECT FILE < PIXa > (грешка на дисплея, ако VAS заявката А не е била въведена във VAS носителя)

5. Дилърският терминал използва коман- дата TRANSFER за анулиране на информация от EF_VALUE или EF_INFO, като случаят може да бъде следният:

• TRANSFER < данни, MAC с KDEC >

Съчетанието от командното съобщение на TRANSFER беше вече описано. Правото за изпълнение на анулиране се предизвиква от терминала, ако той може да формира вярна сигнатура, съдържаща информация за средствата на KDEC. Тази сигнатура се проверява от VAS носителя и последователният номер нараства.

6. Дилърският теминал може да провери чрез проверка на ответното съобщение на TRANSFER командата дали VAS носителят е автентичен (т.е. в притежание на познатия секрет Kdec) .

Процедурата по анулиране на VAS информация е следната. Има два случая на анулиращи процедури:

От една страна, VAS информацията за

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

От друга страна, VAS информацията мо45 же да бъде показана от EF_TRANSFER само веднъж чрез допълнителната команда ТАКЕ. В тази инстанция, правото е консумирано, информацията остава достъпна за по-нататъшно използване (например възстановеният билет е 50 току що използван за обратно пътуване) в областта на обмен, отбелязана е като че е била прехвърлена, докато бъде потърсена от други задачи при изпълнението им.

Анулиране на VAS информация чрез командата ТАКЕ се осъществява, както следва:

1. Притежателят на карта поставя картата в дилърския терминал.

2. Дилърският терминал проверява къде VAS носителят е достъпен:

• SELECT FILE < AIDvas > (грешка на дисплея, ако VAS носителят е неизбираем) • READ RECORD < SFI от EF_ID , 0 > (на дисплея се показва VAS носителят ID)

3. Дилърският терминал пръв показва на дисплея задачите от EF_TRANSFER, които са достъпни, използвайки специалния случай на операцията показване на VAS заявки , за да реши къде изпълнението на задачата е възможно. Обратно, командата SEEK може да бъде приложена единствено за търсене. Ако терминалът е успял, знае номера i на търсения запис.

4. Терминалът маркира записа за показване номера на записа i, за което той предава i, случайния номер, изчислен от него, неговия PIX и терминала ID с командата ТАКЕ:

• ТАКЕ < i, случаен номер, PIX, терминал ID >

Дилърският терминал използва командата ТАКЕ за четене на информация от EF_TRANSFER, приблизително идентифицирайки информацията като че е била изтеглена. Изпълнението на командата, в допълнение, се приема за създаване на две различни криптограми С1 и С2.

Криптограмата С1 се пресмята от VAS носителя, използвайки ключа Ksig_vasc. По този начин резултатът от прехвърлянето на задачата, отбелязано с С1, може да получи доказателство за уникалност (един единствен път) и автентичност от системния оператор. Уникалността и автентичността на сделката произтича от криптограмата на VAS изпълнителя, от което задачата е инициализирана оригинално (и която е проверена от картата, виж също така TRANSFER), и от поддържане на случайното броене на сделките, както и криптограмата С1 чрез картата по време на изтеглянето.

Криптограмата С2 е изчислена от VAS носителя, използвайки ключа KGKdec, който е създаден от VAS носителя от KGKDEC, PIX и терминала ID. За познаване на взаимния секрет Kdec, VAS носителят може директно да потвърди на терминала автентичността на VAS носителя. Като се има предвид факта, че по време на TRANSFER командата е направена проверка, също така, че само достоверни платежни документи или разписки са инсталирани в автентичния VAS носител, то автентичността на изтеглената задача може да бъде приета за убедителна. След като С2 е формирана индиректно (косвено) чрез последователния номер, изтегления бит и VAS носителят ID, VAS носителят може понякога да провери терминала за уникалност (един единствен път) за изтеглената задача.

Всеки има право да изтегля, използвайки командата ТАКЕ.

Освен това, от терминала за услуги дезактивирането или активирането, респективно на паролата или на PIN-защитата за четене на VAS заявки от групите за изпълнение DF_PT и DF_AD е възможно. В допълнение, PIN на VAS носителя може да бъде изменен от притежателя на карта, познавайки PIN и може да бъде възобновен от системния оператор чрез средствата на външната автентичност чрез KSO.

Неномерирани символи или последователен символ от известна поредица може също така да бъде използван като PIN или парола.

Claims (34)

1. Патентни претенции

   1. Чипкарта за осъществяване на сделки, при които парични средства или други данни за стойности, представляващи непарични права, се обменят между притежателя на карта, и по-специално един партньор по сделка (изпълнител на услуга) или се представя на изпълнителя на услугата за удостоверяване на права, при което чипкартата съдържа памет, в която е съхранена необходимата информация за извършване на сделките и чипкартата се характеризира с това, че съдържа следното: средство за въвеждане на една или повече заявки от карта (VAS заявки), които са определени за известен изпълнител на услуги, респ. в картата, като всяка от заявките позволява осъществяването на сделки между притежателя на картата и изпълнителя на услугата, определени от заявката;

   област от памет за обмен (EF_TRANSFER), която не принадлежи на изпълнителя на услуги за съхраняване на данни, които при изпълнението на сделката между различните изпъл33 нители на услуги се обменят взаимно или се показват, и които представляват паричните средства или непаричните права; и средство за запис на информация (данни) в паметта за обмен чрез действие на записваща команда (TRANSFER),
2. 2. Чипкарта съгласно претенция 1, в която средството за въвеждане съдържа:

   информационна структура (DF_VAS, VAS носител), съхраненото в която съдържа:

   отделна структура (DF_PT, DF_AD, VAS заявка), в която могат да бъдат въведени необходимите данни (VAS данни) за осъществяване на възможното изпълнение на сделка между притежателя на карта и изпълнителя на услуги;

   дефиниционна информационна мрежа, която съхранява информация, отнасяща се до естеството и/или структурата на съхранените данни в отделната структура (VAS заявка); и където дефиниционната информационна мрежа допълнително съдържа:

   главен признак (носител-ID), който идентифицира информационната структура (VAS носителя) и/или чипкартата; и допълнително една система ключове (Kso), която защитава цялостта на дефиниционната информационна мрежа и/или информационната структура (VAS носителя) срещу модификации.
3. 3. Чипкарта съгласно претенция 2, характеризираща се с това, че съдържа най-малко един от следващите признаци:

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

   средство за запис на данни в дефиниционната информационна мрежа за прилагане на данните от дефиниционната информационна мрежа към данните, въведени в отделната структура;

   средство за създаване допълнително на отделна структура, в която необходимата информация за изпълнение може да бъде въведена в информационната база данни от картата; и/или средство за динамично администриране в паметта на картата.
4. 4. Чипкарта съгласно претенция 2, характеризираща се с това, че отделните структури (VAS заявки) са представени чрез взаим- нонезависими отделни структури, всяка предварително определена за самостоятелен изпълнител на услуги;

   дефиниционната информационна мрежа 5 е защитена срещу модификация чрез най-малко един системен ключ (KSO) и може да бъде модифицирана само чрез средствата на този ключ; и че въвеждането в отделните структури (VAS заявки) може да продължи само със системния ключ, съхранен в информационната дефиниционна мрежа.
5. 5. Чипкарта съгласно претенция 2, характеризираща се с това, че дефиниционната информационна мрежа съдържа най-малко един от следващите признаци:

   най-малко един ключ за установяване на автентичност на правото на чипкартата по отношение на терминал и/или на автентичност на правото на терминал по отношение на чипкартата;

   най-малко един сигнатурен ключ (Ksig_vasc) за означаване на изтеглени данни от паметта за обмен;

   ключ, създаващ ключ (KGKdec) за действуващ терминал и специфични ключове на заявки за проверка правото за процедура на запис в паметта за обмен и/или за анулиране на информация за парични стойности;

   PIN за проверка правото за процедура за сделка от притежателя на карта;

   При това системният ключ (Kso), ключът за установяване на автентичност (Kaut) , сигнатурният ключ (Ksig_vasc) и ключът, създаващ ключ (KGKdec), са индивидуални ключове за картите или специфични за информационната структура (DF_VAS);

   а отделната структура (VAS заявка) съдържа най-малко един от следващите признаци:

   най-малко една памет за парични стойности (EF_VALUE) за съхраняване на информация за парични средства;

   най-малко една вътрешна памет (EF_INTERNAL) за съхраняване на вътрешна информация, отнасяща се до отделната структура;

   най-малко една информационна памет (EF_INFO) за съхраняване на невътрешна информация, отнасяща се до отделната структура;

   памет за ключове (EF_KEY) за съхра10 няване най-малко на един ключ (Klvasp, Krvasp), който осигурява защита за запис и/ или процедура за намиране на данни в или от паметта за парични стойности, и/или вътрешната памет, и/или информационната база данни. При това чипкартата допълнително включва:

   средство за запис и/или намиране на данните в или от паметта за парични стойности, вътрешната памет или информационната база данни а средството за въвеждане включва:

   средство за запис на ключ в паметта за ключове, защитена поне чрез един системен ключ.
6. 6. Чипкарта съгласно претенция 2, характеризираща се с това, че отделната структура съдържа най-малко една от следващите неразделни части:

   ключ (Klvasp) за проверка на правото за запис на данни в отделната структура;

   ключ (Krvasp) за проверка на правото за намиране на данни в отделната структура.
7. 7. Чипкарта съгласно претенция 2, характеризираща се с това, че ключовете, съхранени в паметта за ключове, са специфични за съответната отделна структура, като най-малко една отделна структура (VAS заявка) защитава изпълнението на сделки чрез средствата на най-малко един от специфичните ключове (Klvasp, Krvasp), който е специфичен за отделната структура (VAS заявка) и е независим от ключовете за другите отделни структури (VAS заявки).
8. 8. Чипкарта, съгласно претенция 2, характеризираща се с това, че картата съдържа множество от отделни структури (VAS заявки), всяка от които служи за изпълнение на сделки между отделен изпълнител на услуги и притежател на карта, като изпълнението на сделките включва запис и/или намиране на данни в или от областта на обмен и/или запис, и/ или намиране на данни в, респ. от паметта за парични стойности.
9. 9. Чипкарта съгласно претенция 2, характеризираща се с това, че допълнително включва:

   средство за изпълнение на сделките, както между индивидуалните отделни структури (VAS заявки), така и между отделна структура и изпълнител на услуги.
10. 10. Чипкарта съгласно претенция 2, ха рактеризираща се с това, че системният ключ (Kso) се знае само от системния оператор (SO) и е индивидуален ключ за карта и/или специфичен за информационната структура (VAS носител) , като ключовете, съхранени от дефиниционната информационна мрежа, са индивидуални ключове за картата и/или специфични за информационната структура (VAS носителя).
11. 11. Чипкарта съгласно претенция 2, характеризираща се с това, че дефиниционната информационна мрежа включва една или повече от следващите неразделни части:

    идентификационен номер (EF_ID), специален за информационната структура;

    адресен указател (директория) за отделните структури (EF_DIR), съхраняван в информационната структура, като адресният указател (директорията) на отделната структура съдържа специфични идентификационни номера за отделните структури (VAS заявки), въведени в информационните структури (VAS носители) , както и съхранената информация като част от информационната структура (VAS носителя), в която отделните структури (VAS заявки) са физически записани;

    променлив номер на информационната структура (EF_VERSION).
12. 12. Чипкарта съгласно претенция 2, характеризираща се с това, че включва най-малко един от следващите признаци:

    средство за изпълнение на процедура за изтегляне на данни (ТАКЕ), чрез средствата на която данните могат за бъдат прехвърляни и/или стойностно анулирани от паметта за обмен;

    средство за създаване на едни или повече признаци за автентичност на данните по време на изтеглянето или анулирането на данните от паметта за обмен.
13. 13. Чипкарта съгласно претенция 12, характеризираща се с това, че за създаване на признаци за идентичност чипкартата съдържа следното:

    сигнатурен ключ (KSIG_VASC) за създаване на цифрова сигнатура за изтегляне на данни;

    средство за създаване на номер на сделка, характеризиращ сделката, което средство се използва само при създаване на цифрова сигнатура.
14. 14. Чипкарта съгласно претенция 13, ха35 рактеризираща се с това, че сигнатурният ключ (Ksig_vasc) е собствен ключ, създаден от собствен ключ за създаване на ключове и че за проверка на сигнатурата от изпълнителя на услуги са използвани общоизвестни ключове.
15. 15. Чипкарта съгласно претенция 14, характеризираща се с това, че тя съдържа наймалко една от следващите неразделни части :

    средство за създаване на специфични ключове (Kdec) за терминалите и за отделните структури чрез средствата на ключа, създаващ ключ (KGKdec) ;

    средство за проверка на правото и/или защитата на сделка чрез използване най-малко на една от следващите неразделни части:

    • специфичен ключ (Kdec) за терминал и отделна структура, • най-малко един ключ за автентичност (Kaut), • най-малко един системен ключ (Kso), • най-малко един специфичен ключ (Klvasp, Krvasp) за отделна структура, • сигнатурен ключ (Ksig_vasc), • PIN, • идентификатор на отделна структура, • идентификатор на терминал.
16. 16. Чипкарта съгласно претенция 5, характеризираща се с това, че включва най-малко една от следващите неразделни части:

    средство за установяване на автентичност на право и/или на терминал чрез средството на ключ за автентичност преди стартирането на процедура за намиране или запис на данни;

    средство за изпълнение на процедури за намиране или запис на данни, които са защитени чрез цифрови сигнатури и/или създаден ключ.
17. 17. Чипкарта съгласно претенция 16, характеризираща се с това, че допълнително включва най-малко една от следващите неразделни части:

    средство за активиране и дезактивиране на PIN защитата;

    средство за смяна на PIN.
18. 18. Чипкарта съгласно претенция 2, характеризираща се с това, че информационната структура съгласно претенция 2 е независима от платката на картата, а чипкартата допълнително включва средство за обмен на информационната структура или на части от информационната структура с друга карта.
19. 19. Чипкарта съгласно претенция 2, характеризираща се с това, че съдържа следното:

    област от паметта , притежавана от изпълнителя на услуги, за запис или намиране на данни в или от областта на паметта от различни изпълнители на услуги за обмен на парични средства и/или стойностна информация, представляваща други непарични права, между различни изпълнители на услуги.
20. 20. Терминал за използване на чипкарта, съгласно претенция 2, характеризиращ се с това, че съдържа:

    средство за идентифициране на информационна структура (VAS носител) на чипкартата, както и за установяване на идентичност на характеристиката (носител-ID), идентифицираща информационната структура;

    като терминалът допълнително съдържа най-малко един от следващите признаци:

    средство за възстановяване на данните от най-малко от една от отделните структури и/или дефиниционната информационна мрежа, и/или паметта за обмен на картата;

    средство за запис на данни в паметта за обмен на картата;

    средство за въвеждане на данни, необходими за изпълнение на сделките в най-малко една от отделните структури (VAS заявки) на картата.
21. 21. Терминал съгласно претенция 20, характеризиращ се с това, че съдържа най-малко една от следващите неразделни части:

    средство за изпълнение на сделки между изпълнителя на услуги и притежателя на карта, като изпълнението на сделка включва наймалко една от следващите стъпки:

    запис на данни в паметта за парични стойности;

    запис на данни в паметта за обмен;

    прехвърляне и/или анулиране на данни от паметта за обмен;

    намиране на данни в отделната структура;

    намиране на данни в паметта за обмен.
22. 22. Терминал съгласно претенция 21, характеризиращ се с това, че допълнително съдържа:

    средство за проверка правото за и/или защитата на сделка с помощта на най-малко една от следващите неразделни части:

    специфичен за терминала и за отделна36 та структура - специфичен ключ (KDEC) най-малко един ключ за установяване на автентичност (Kaut), който е индивидуален за картата или специфичен за информационната структура (DF_VAS);

    най-малко един системен ключ (Kso), който е индивидуален за картата или специфичен за информационната структура (DF_VAS);

    най-малко един специфичен ключ за отделната структура (Klvasp, Krvasp);

    най-малко един сигнатурен ключ (Ksig_vasc), който е индивидуален за картата или специфичен за информационната структура (DF_VAS);

    PIN, който е индивидуален за картата или специфичен за информационната структура DFVAS);

    специфична характеристика на отделната структура от гледна точка на заявката;

    специфична характеристика на терминала от гледна точка на терминала.
23. 23. Терминал съгласно претенция 22, характеризиращ се с това, че средството за запис на данни в паметта за обмен съдържа:

    средство за кодиране на данните с използване на терминал и специфичен ключ на отделната структура (Kdec) за потвърждение правото за запис.
24. 24. Терминал съгласно претенция 20, характеризиращ се с това, че допълнително съдържа:

    средство за изпълнение процедурата по изтегляне на данни от паметта за обмен, чрез средствата на която данните са прехвърлени от паметта за обмен и/или са стойностно анулирани.
25. 25. Терминал, съгласно претенция 24, характеризиращ се с това, че допълнително съдържа най-малко една от следващите неразделни части:

    средство за характеризиране на информацията в паметта за обмен, когато е прехвърлена;

    средство за характеризиране на информацията в паметта за обмен, когато е изчезнала (загубена).
26. 26. Терминал, съгласно претенция 20, характеризиращ се с това, че средството за изпълнение на сделките съдържа най-малко една от следващите неразделни части:

    средство за смяна на стойностните данни в отделната структура;

    средство за извършване на сделки между различни изпълнители на услуги (взаимни услуги) за изразходване на сметка, както и вместо притежателя на картата.
27. 27. Терминал съгласно претенция 20, характеризиращ се с това, че допълнително съдържа:

    средство за установяване автентичност на правото от терминал, съответен на картата, и/или от карта, съответна на терминала, с помощта най-малко на един ключ за установяване на автентичност;

    средство за защита на сделка от притежател на карта чрез средствата на PIN;

    средство за активиране и дезактивиране на PIN защитата.
28. 28. Терминал съгласно претенция 20, характеризиращ се с това, че допълнително съдържа най-малко една от следващите неразделни части:

    средство за обмен на терминална специфична характеристика за картата;

    средство за обмен на специфичната характеристика на отделната структура за картата;

    средство за установяване автентичност на право за използване на специфичен ключ на терминал и на отделна структура, както и на специфичната характеристика на терминала и отделната структура;

    средство за осъществяване на процедури за намиране на данни или за запис на данни, които са защитени чрез цифрова сигнатура и/или кодиране.
29. 29. Терминал съгласно претенция 20, характеризиращ се с това, че допълнително съдържа най-малко една от следващите неразделни части:

    средство за селекция на отделна структура (VAS заявка);

    средство за показване на отделна структура на дисплея на терминала;

    средство за показване на данните на отделната структура на дисплея на терминала;

    средство за въвеждане на отделната структура (VAS заявка) в картата;

    средство за въвеждане на характеристиката към въведената отделна структура (VAS заявка) в картата;

    средство за изчистване на отделната структура от картата;

    средство за заместване на отделна струк37 тура с различни отделни структури;

    средство за обмен (прехвърляне) на отделна структура в друга карта;

    средство за обработка на отделната структура от гледна точка на нейната функционалност и свързания с нея изпълнител на услуги, както и за намиране на данни и за показване на съхранената в нея информация.
30. 30. Метод за осъществяване на сделки между притежател на карта и най-малко един изпълнител на услуги, участвуващ с използване на чипкарта, както и на терминал, при което методът съдържа поне една от следващите стъпки:

    създаване на съхраняваща (запомняща) информационна структура в чипкартата, в която данните за заявка, подходяща за изпълнител на услуги, могат да бъдат въведени за възможно осъществяване на сделката между притежателя на карта и така наречения изпълнител на услуги (VAS информация); както и запис в/или четене на данни от информационната структура (VAS заявка) за осъществяване на сделки между притежателя на карта и така наречения изпълнител на услуги;

    създаване на област от паметта за обмен (EF_TRANSFER), непринадлежаща на изпълнителя на услуги, за съхраняване на информация за парични стойности, представляващи непарични права, за да бъдат обменяни или представяни по време на осъществяване на сделката между различни изпълнители на услуги; както и запис на информация в паметта за обмен или намиране на информация в паметта за обмен.
31. 31. Метод съгласно претенция 30, характеризиращ се с това, че методът съдържа най-малко една от следващите стъпки:

    използване на чипкартата съгласно претенция 1;

    използване на терминал съгласно претенция 20;

    запис или намиране на данни в или от паметта за стойности или от външна памет, или от информационната памет на най-малко една от отделните структури (VAS заявки).
32. 32. Метод съгласно претенция 31, характеризиращ се с това, че допълнително включва най-малко една от следващите стъпки:

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

    защита на сделката чрез използване на цифрова сигнатура и/или кодиране с използване най-малко на един ключ.
33. 33. Метод за въвеждане на данни в чипкарта, използвайки терминал, характеризиращ се с това, че методът съдържа най-малко една от следващите стъпки:

    въвеждане на данни в отделната структура (VAS заявка) на картата;

    запис на данни в дефиниционната информационна мрежа на картата, като методът съдържа още поне една от следващите стъпки: използване на чипкарта съгласно претенция 1;

    използване на терминал съгласно претенция 20.
34. 34. Система за осъществяване на сделки, характеризираща се с използване на чипкарта съгласно претенция 1 и терминал съгласно претенция 20.

    Приложение: 10 фигури