CZ7899A3 - Čipová karta, bezpečný aplikační modul, systém obsahující bezpečný aplikační modul a terminál a způsob řízení obslužných akcí prováděných bezpečným aplikačním modulem na čipové kartě - Google Patents

Description

Člpová karta /=ICC, Integrated Circuit Card/ Je se souborově orientovanou paměťovou strukturou. Bezpečný aplikační modul /=SAM, Secure Application Module/ je se souborově orientovanou paměťovou strukturou. Systém obsahuje SAM a terminál. Způsob řízení obslužných akcí v mechanizmu služeb pro více aplikací, které je prováděno na ICC pomocí terminálu a zahrnuje následující kroky: a/ zjištění, zda daný terminál /2/ je oprávněn provést danou obslužnou akci na dané integrované kartě služeb, pomocí alespoň jednoho klíče uloženého na zmíněné ICC i ve zmíněném SAM a ověřením předem stanovených přístupových práv, uložených na SAM pomocí zmíněného SAM a b/ provedení obslužné akce na integrované kartě služeb.

(13) Druh dokumentu: A3 (51) Int. Cl.⁶:

G 07 F 7/10

12086

Čipová karta, bezpečný aplikační modul, systém obsahující bezpečný aplikační modul a terminál a způsob řízení obslužných akcí prováděných bezpečným aplikačním modulem na čipové kartě

Oblast techniky

Předkládaný vynález se týká čipové karty vybavené paměťovými prostředky uchovávajícími obslužná data vztahující se k alespoň jedné službě.

Dosavadní stav techniky

Čipové karty jsou dnes široce používány. Předkládaný vynález předpokládá využití v autorizačních mechanizmech pro více aplikací. Příklady autorizačních mechanizmů pro více aplikací byly dříve popsané například v US-A-5 473 690, WO-A92/06451, EP-A-0 640 945, EP-A-0 644 513, WO-A-87/07060, EP-A0 262 025 a EP-A-0 661 675.

Tyto známé autorizační mechanizmy pro více aplikací sdílejí společnou paměťovou strukturu s přímým přístupem, v níž se nepoužívají žádné adresáře a soubory. Společným rysem známých mechanizmů je použití tajného kódu na čipové kartě pro kontrolu oprávněnosti přístupu bezpečného aplikačního modulu k aplikaci označené jednoznačným identifikátorem. Tento tajný kód je nutno reprodukovat, kdykoli bezpečný aplikační modul požaduje přístup k této službě.

Jelikož tyto známé mechanizmy nepoužívají adresáře ani souborové struktury, na čipových kartách je potřebná přítomnost přístupových tabulek. Tyto přístupové tabulky obsahují několik položek sestávajících z tajného kódu pro danou aplikaci, označení paměťových míst na čipové kartě používaných touto • ·

aplikací a příslušných přístupových práv spojených s touto aplikací, jako jsou práva ke čtení a zápisu, PIN, atd. Většinou je ke zpřístupnění tajného kódu potřebný tajný klíč.

Nevýhodou výše uvedených známých mechanizmů je to, že přístupové tabulky na čipové kartě zabírají paměťový prostor. Protože současná čipová karta má k dispozici jen přibližně 8 kilobitů paměťového prostoru, představuje to značnou nevýhodu .

Podstata vynálezu

Cílem předkládaného vynálezu je poskytnout čápovou kartu s pamětí organizovanou do adresářové a souborové struktury, kde dochází k úsporám paměťového prostoru pomoci omezení režijních dat každé aplikace na čipové kartě.

K dosažení tohoto cíle poskytuje předkládaný vynález čápovou kartu definovanou v úvodu nároku 1, která se vyznačuje tím, že alespoň jedna část paměťových prostředků obsahuje služební data v souborových strukturách v rámci jednoho adresáře obsahujícího první soubor a druhý soubor, přičemž služební data jsou sdružena v služebních datových blocích, kde každý služební slot je rozdělen na dvě části: profil a data, přičemž každý profil obsahuje číslo slotu, je uložen v prvním souboru a dále obsahuje jednoznačný identifikátor aplikace, a každá datová část je uložena v druhém souboru a obsahuje data vztahující se k dané službě, přičemž paměťové prostředky uchovávají alespoň jeden klíč chránící přístup k zápisu do prvního a druhého souboru.

Pokud je paměť na čipové kartě strukturována tak, jak bylo výše popsáno, stačí na kartě uchovávat pouze jeden nebo dva klíče společné pro několik služebních aplikací. Tím je na kar9 · tě zapotřebí méně režijních dat vztahujících se k jednotlivým služebním aplikacím a tudíž čipová karta může podporovat více služebních aplikací.

U jednoho provedení obsahuje alespoň jedna profilová část rovněž data vztahující se k době platnosti daného služebního slotu. Taková data vztahující se k době platnosti mohou být testována bezpečným aplikačním modulem při komunikaci s čipovou kartou. Pokud se zjistí, že doba platnosti již vypršela, služební slot je považován za volný pro jakoukoli jinou novou služební aplikaci. Takto nemusí existovat žádné složité úmluvy mezi dodavatelem hardware, dodavatelem software a stranou, která poskytuje službu uživateli čipové karty. Dostupnost služebního slotu, jehož doba platnosti vypršela, lze testovat automaticky.

Když existují různí dodavatelé aplikačního software vztahujícího se k různým službám, jsou služební sloty přednostně strukturovány tak, že obsahují vlastní profilovou část i vlastní datovou část, přičemž profilové části jsou implementovány jako záznamy v prvním souboru, datové části jsou implementovány jako záznamy v druhém souboru a paměťový prostředek dále uchovává klíč k ochraně přístupu k prvnímu souboru.

V takovém případě mohou být tyto služební sloty nazvány „generickými služebními sloty“.

Pokud však existuje pouze jeden dodavatel aplikačního software pro několik služeb, implementované služební sloty přednostně sdílejí jednu společnou profilovou část, přičemž ale každý služební slot obsahuje vlastní datovou část. Společná profilová část je implementovaná jako jeden záznam v prvním souboru a datové části jsou implementovány jako oddělené záznamy v druhém souboru. Tyto služební sloty mohou být nazvány „dedikovanými služebními sloty“. V takovém případě obsahuje první soubor pouze jeden záznam, čímž se dosahuje úspory potřebného paměťového prostoru pro data profilové části.

Adresář na čipové kartě může být rozšířen o třetí soubor tak, že alespoň jeden služební slot obsahuje doplňkovou datovou část ve třetím souboru pro uchovávání doplňkových dat. Některé služební aplikace vyžadují mnoho doplňkových dat, která mohou být uchovávána v takové doplňkové datové části.

Předkládaný vynález se rovněž týká bezpečného aplikačního modulu vybaveného pro komunikaci s čipovou kartou podle kteréhokoli z nároků 1 až 7, vybaveného paměťovými prostředky uchovávajícími služební data vztahující se k alespoň jedné službě a vyznačujícího se tím, že alespoň část paměťových prostředků obsahuje služební data v souborových strukturách v jednom adresáři, kde tento adresář obsahuje alespoň jeden soubor, jenž uchovává služební data vztahující se k jedné konkrétní službě a sdružená do:

- definičních dat aplikace/služby, jež obsahují jednoznačný identifikátor služby a údaj o typu služby,

- nejméně dvou aplikačních čítačů pro správu počtu alokací a pro generování jednoznačného čísla transakce na záznamu,

- služebního pořadového čítače pro generování jednoznačného čísla objektu a správu počtu vytvořených služebních obj ektů,

- desetinného čísla pro správu počtu buďto vydaných nebo přijatých cenových jednotek a

- dat týkajících se přístupových práv, která definují obslužné akce, jež mohou provádět jednotlivé terminály, a tím, že paměťové prostředky zahrnují alespoň první klíč a druhý klíč k ochraně jakékoli datové komunikace s čipovou

« · *

Definiční data služby a klíče v bezpečném aplikačním modulu slouží ke správě služební aplikace, což bylo v zařízeních podle dosavadního stavu techniky řízeno přístupovými tabulkami na čipové kartě. Řídící data pro správu jsou tudíž uložena v bezpečném aplikačním modulu a nikoli na čipové kartě jako dosud. Toto však není příliš na závadu, jelikož paměťový prostor, jenž je k dispozicí v bezpečném aplikačním modulu je méně kritický než prostor na samotné čipové kartě. Navíc má taková konstrukce několik výhod.

Předně může být správa aplikací snadněji realizována, protože vystavitel čápových karet může vždy zřídit přímé spojení mezi bezpečným aplikačním modulem a centrálním systémem sběru dat, což je mnohem obtížněji proveditelné mezí čipovými kartami a centrálním systémem sběru dat.

Dále mohou být různí příjemci služeb, t.j. strany, které zřizují přímé spojení mezi čipovými kartami a bezpečným aplikačním modulem pro zprostředkování služby, autorizováni s různými přístupovými právy. Bezpečný aplikační modul může snadno zkontrolovat, které obslužné akce mohou být příjemcem služby na čipové kartě provedeny. Může jít například o přičtení či odečtení věrnostních bodů, nebo pouhé zobrazení celkového počtu věrnostních bodů přítomných na čipové kartě.

Použitím záznamů v souborové struktuře mechanizmu služebních slotů se předchází použití přístupových tabulek na čipové kartě. Bezpečný aplikační modul povolí vždy pouze využití záznamu s konkrétním číslem, které bylo přečteno zabezpečenou cestou.

Předkládaný vynález se rovněž týká systému, obsahujícího bezpečný aplikační modul podle vynálezu a alespoň jeden terminál spojený s bezpečným aplikačním modulem. Tento terminál je vybaven pro komunikaci s bezpečným aplikačním modulem a s alespoň jedním čipem podle vynálezu, pro řízení služby prováděné na alespoň jedné čipové kartě.

Navíc se současný vynález týká způsobu řízení obslužné akce prováděné terminálem na čipové kartě podle kteréhokoli z nároků 1 až Ί, kdy terminál je ve spojení jak s bezpečným aplikačním modulem podle kteréhokoli z nároků 8 a 9, tak i s čipovou kartou, zahrnujícího následující kroky:

a) zjištění, zda terminál je oprávněn provádět obslužnou akci na integrované kartě služeb, pomocí alespoň jednoho kódu a alespoň jednoho tajného klíče, kdy jak tento kód tak i tento klíč jsou oba uloženy jak na čipové kartě tak i v bezpečném aplikačním modulu, a ověřením předem stanovených přístupových práv,

b) provedení obslužné akce na integrované kartě služeb,

c) ověření kroku b) na terminálu, a vyznačujícího se tím, že:

ověření předem stanovených přístupových práv v kroku a) je prováděno v bezpečném aplikačním modulu pomocí dat, vztahujících se k přístupovým právům, uložených v bezpečném aplikačním modulu a alespoň jednoho kódu.

U způsobu podle vynálezu je tudíž více kroků aplikačního mechanizmu prováděno v bezpečném aplikačním modulu než u způsobů podle dosavadního stavu techniky. Tím se dosahuje úspory paměťového prostoru na čipových kartách a zjednodušuje se správa více aplikací na čipových kartách.

Jelikož je paměťový prostor, dostupný v bezpečných aplikačních modulech, méně kritický než na čipových kartách, paleta možných přístupových práv může být poměrně velká. Přístupová práva mohou být definována složitěji než pro pouhé čtení a zápis. V souladu s vynálezem mohou přístupová práva zahrnovat vytvářeni, mazání, zvyšování a snižování, validaci, označování « · · · · · · · · · * · « * · · · · · »«· » · · · » ··· ·· a verifikaci služebních slotů na čipové kartě a modifikaci doplňkových dat, pokud jsou přítomna. Toto jsou pouze příklady, v bezpečném aplikačním modulu lze přirozeně implementovat další typy přístupových práv.

V alternativním provedení je výše definovaný způsob charakterizován tím, že ověření předem stanovených přístupových práv v kroku a) předchází následující krok: čtení služebních dat ze služebního slotu a uložení předem stanovené části dat, která má zůstat beze změny, v bezpečném aplikačním modulu, a tím, že krok b) je proveden beze změny předem stanovené části dat na čipové kartě.

Přehled obrázků na výkresech

Předkládaný vynález bude vysvětlen níže s odkazem na několik obrázků. Tyto obrázky jsou zamýšleny pouze jako ilustrace předkládaného vynálezu a nemají omezit jeho rozsah.

Obrázek 1 zobrazuje procesy zajišťující služby čipové karty, jako je „elektronická peněženka“, obrázek 2 zobrazuje schematický vývojový diagram kroků prováděných na čipové kartě, terminálu a v bezpečném aplikačním modulu pro zajištění takové služby u způsobu podle dosavadního stavu techniky, obrázek 3 zobrazuje strukturu bezpečného aplikačního modulu pro několik aplikací, obrázek 4 zobrazuje prostředí služební aplikace na čipové kartě, které lze použít pro služby stejného typu pocházející od různých dodavatelů aplikací (generické služební sloty), obrázek 5 zobrazuje strukturu alternativního prostředí služební aplikace pro služby různých typů, pocházející pouze od jednoho dodavatele aplikací (dedikované služební sloty), obrázek 6 zobrazuje strukturu prostředí služební aplikace v bezpečném aplikačním modulu v souladu s předkládaným vynálezem, obrázek 7 zobrazuje bezpečný aplikační modul a jeho vztah k různým stranám zúčastněným na poskytování a zajišťování jisté služby, obrázek 8a zobrazuje schematický vývojový diagram kroků prováděných na čipové kartě, terminálu a v bezpečném aplikačním modulu pro zajištění jedné z následujících obslužných akcí: vytváření, mazání nebo modifikace služebního objektu, obrázek 8b zobrazuje vývojový diagram se změnami vůči diagramu z obrázku 8a a znázorňuje kroky při provádění jedné z následujících obslužných akcí: zvyšování a snižování, válidači a označování existujícího služebního objektu, obrázek 9 zobrazuje příklad přesné struktury služebního slotu.

Příklady provedeni vynálezu

S odkazem na obrázek 1 může být čipová karta 1_ v souladu s dosavadním stavem techniky nosičem jedné nebo několika služeb, jako například služby „elektronické peněženky“.

Uživatel 5 může vložit čipovou kartu 1_ do vhodného komunikačního zařízení (nezobrazeno) terminálu 2. Terminál 2 je ve spojení s bezpečným aplikačním modulem 3. Systém sběru dat 4 je spojen s bezpečným aplikačním modulem (3 přes terminálové rozhraní. Spojení mezi terminálem 2, bezpečným aplikačním modulem 3, systémem sběru dat 4_ a čipovou kartou 1 může probíhat po konvenčních vodičích, optických vláknech nebo jakoukoli bezdrátovou přenosovou technologií.

Terminál 2 funguje jako rozhraní mezi čipovou kartou 1 a bezpečným aplikačním modulem j3.

Pro usnadnění popisu budou nejdříve uvedeny definice několika používaných pojmů.

Typ služby: typ služby vázané na kartu, kterou bude využívat držitel karty 5. Příklady takových typů služeb mohou být elektronická peněženka, věrnostní čítače, věrnostní kupóny, identifikace, předplatné, lístky používané např. pro parkování, hromadnou dopravu, kina, koncerty atd.

Služební aplikace: sada používaných služebních objektů, ukládaných na čipové kartě ji a v bezpečném aplikačním modulu 3, potřebných pro využívání služby. Příklady služebních objektů jsou: věrnostní body, vstupenky, předplatné, atd.

Parametr služby; služební objekt vyžadovaný bezpečným aplikačním modulem 3 pro umožnění služební aplikace, např. identifikátor aplikace, identifikátor služby, přístupová práva ke službě, atd.

Obslužná akce: (autorizované) provedeni jedné nebo více softwarových procedur, jež má za následek modifikaci, vytvoření nebo smazání služebního objektu, například vytvoření nebo verifikaci vstupenky, nebo zvýšení či snížení počtu věrnostních bodů na věrnostním kupónu.

Přístupová práva ke službě: určené autorizační pravidlo pro využití jisté obslužné akce stanoveným terminálem 2, některé terminály 2 mohou například mít právo pouze ke čtení počtu věrnostních bodů na čipové kartě í, zatímco jiné mohou mít právo k modifikaci tohoto počtu věrnostních bodů.

Služební objekt: datová struktura týkající se služby, která je bezpečně uložena na čipové kartě _1 a která může být modifikována obslužnou akcí (např. vstupenky, kupóny, věrnostní čítače).

• 0 ·

0 0·· • 00 ♦ ♦·

- 10 Dodavatel· hardware: strana, která dodává čipovou kartu 1^ vystavitelům karty a bezpečný aplikační modul 3 příjemcům karty. Tyto čipové karty 1 a bezpečné aplikační moduly 3 jsou vybaveny základními aplikacemi pro využití například elektronické peněženky. Část paměti dodávaných čápových karet JL a bezpečných aplikačních modulů 3 může být využita k uchování dalších aplikací určených vystavitelem a příjemcem karty.

Vystavitel karty: strana, která vystavuje čipové karty 1 zákazníkům. Tato strana určuje volitelné aplikace čipových karet JL, obvykle po právní smlouvě s dodavatelem hardware.

Příjemce karty: strana, která nakupuje potřebné bezpečné aplikační moduly 3 od dodavatele hardware, aby mohla nabídnout držitelům karty 5 některé služby vázané na kartu. Tyto bezpečné aplikační moduly 3 musí být ve spojení s terminály g příjemce karty. Příjemce karty určuje volitelné aplikace na bezpečném aplikačním modulu 3, obvykle po právní smlouvě s dodavatelem hardware.

Dodavatel aplikací; strana, která zajišťuje tyto na kartu vázané služby prostřednictvím modulů služebních aplikací uložených na čipové kartě 1 a v bezpečných aplikačních modulech 2· Tato strana musí rovněž poskytnout potřebný software pro terminály 2 příjemce karty.

Poskytovatel služby: strana, která (finančně) využívá službu vázanou na kartu nabízenou příjemcem karty a zajištěnou dodavatelem aplikací.

Příjemce služby: strana, která zřizuje přímé spojení mezi držitelem karty 5 a jistou službou prostřednictvím on-line serveru nebo off-line terminálu služby. Tato strana provádí obslužné akce na uložených služebních objektech, pro které mé oprávnění k použití.

Držitel karty 5: zákazník, který využívá čipovou kartu 1_ pro několik služeb vytvořením příslušného spojení mezi čipovou kartou ý a terminálem 2, např. vložením Chipperu do čtečky u prodejce nebo komunikací přes Tele-Chipper®.

S odkazem na obrázek 1 řídí terminál 2 veškeré služební transakce poté, co zákazník 5 k terminálu 2_ připojil svou čipovou kartu K Terminál 2 provádí veškeré potřebné obslužné akce a aktualizuje služební objekt na čípové kartě _1. Zároveň terminál provádí potřebné akce v bezpečném aplikačním modulu 3 .

Systém sběru dat 4 během sběrné relace shromažďuje parametry služeb z bezpečného aplikačního modulu 3 a nahrává do něj nové parametry služeb.

Sběrná relace znázorněná na obrázku 1 je známa odborníkům v daném oboru a nebude zde detailně popisována.

Jak bylo naznačeno výše, již dříve bylo popsáno několik autorizačních mechanizmů pro více aplikací, jako např. v US-A5 473 690, WO-A-92/06451, EP-A-0 640 945, EP-A-0 644 513, WOA-87/07060, EP-A-0 262 025 a EP-A-0 661 675. Tyto známé autorizační mechanizmy pro více aplikací sdílejí paměťovou strukturu s přímým přístupem, t.j. bez adresářů nebo souborových struktur. Pro přistupování k aplikaci s identifikátorem I_ na čipové kartě )L se používá tajný kód C. Kdykoli požaduje bezpečný aplikační modul 3 přístup k této aplikaci, musí být schopen vygenerovat tento tajný kód C. Tento tajný kód C může být při přenosu do čipové karty 1^ zašifrován, aby se předešlo vnějšímu odhalení. Jako další alternativa může být tento kód přenášen přímo. Řídící mechanizmus čipové karty 1 může počítat, kolikrát byl zadán nesprávný kód C.

Druhým rysem všech těchto známých mechanizmů je přítomnost přístupové tabulky na čipové kartě 1. Taková tabulka vět12

šinou obsahuje sadu položek sestávajících z 1) tajného kódu C pro danou aplikaci, 2) označení paměťových míst M na čipové kartě p používaných touto aplikací (např. ukazateli na oblasti, počty bajtú, offsety, záznamy, atd.) a 3) příslušných přístupových práv A platných pro tuto aplikací (např. práva ke čtení/zápisu, PIN, atd.). Pro použití části 1) nebo 2) je požadován tajný klíč Ks.

Obrázek 2 zobrazuje schematický vývojový diagram obecně shrnující mechanizmus podle dosavadního stavu techniky při zápisu dat D na paměťové místo M pro aplikaci s kódem C. Lze rozpoznat čtyři fáze mechanizmu: inicializační fázi ve které je na čipovou kartu (ICC) p a bezpečný aplikační modul (SAM) 3 uloženo několik parametrů, fázi přístupu k aplikaci, v níž čipová karta p kontroluje, zda zadaný tajný kód C je správný, fázi požadavku aplikace, v níž se vznáší požadavek k zápisu dat D na paměťové místo M, a fázi provedení autorizovaného požadavku, v níž je terminál oprávněn zapsat data na paměťové místo M s danými přístupovými právy A a kódem C. Použití náhodného čísla RND je volitelné, ale používá se k zamezení takzvaným „replay-attacks“, tedy pokusům o narušení pomocí záznamu předchozí komunikace. Náhodné číslo RND je použito bezpečným aplikačním modulem p k zašifrování kódu C při jeho přenosu z bezpečného aplikačního modulu 3 na čipovou kartu p. Čipová karta p je vybavena prostředky k dekódování zakódovaného tajného kódu C. Terminál 2 tudíž při přenosu zašifrovaného tajného kódu C z bezpečného aplikačního modulu 3 na čipovou kartu p nezná hodnotu tajného kódu C a nebude schopen bez autorizace provést na čipové kartě p žádnou další akci.

Vývojový diagram na obrázku 2 je rozdělen do tří částí příslušejících čipové kartě (ICC) p, terminálu 2 a bezpečnému aplikačnímu modulu (SAM) 3.

- 13 V kroku 201 jsou na čipové kartě 1_ uloženy následující parametry pro danou aplikaci: identifikátor JE, tajný kód C, paměťové místo M a přístupová práva A.

V kroku 202 je na čipové kartě 1_ uložen tajný klíč Ks.

V inicializační fázi v kroku 203 je v bezpečném aplikačním modulu 3 uložen identifikátor I' a tajný kód CJ_. V kroku 204 jev bezpečném aplikačním modulu _3 uložen tajný klíč Ks.

Pro stejnou aplikaci je požadováno, aby 1=1’ a C = C'.

Ve fázi přístupu k aplikaci jsou vykonány následující kroky.

V kroku 205 čipová karta 1 generuje náhodné číslo RND, jež je v kroku 206 uloženo.

V kroku 207 je náhodné číslo RND přeneseno na terminál 2.

Krok 208 označuje, že terminál 2 čeká na přijetí náhodného čísla RND. Terminál 2 čeká do doby, až bude náhodné číslo RND přijato.

Jakmile terminál 2 přijme náhodné číslo RND, přenese toto náhodné číslo RND v kroku 209 do bezpečného aplikačního modulu

3.

Krok 210 označuje, že ve fázi přístupu k aplikaci bezpečný aplikační modul 3 čeká na přijetí náhodného čísla RND.

Jakmile bylo náhodné číslo RND přijato, bezpečný aplikační modul _3 spočte hodnotu parametru Y podle vzorce:

Y := Enc(RND,C' ) Ks

Parametr Y je tedy zašifrovanou formou tajného kódu C ¹ , přičemž jeho hodnota je dále určena hodnotou náhodného čísla RND přijatého v kroku 210 a tajným klíčem Ks.

V kroku 212 přenese bezpečný aplikační modul 3 identifikátor aplikace I^T a parametr Y do terminálu 2.

Krok 213 označuje, že terminál 2 čeká na přijetí identifikátoru aplikace I’ a parametru Y.

·» 99 *··* »9 9· ·· · · * 9999 • 9 9« 9 · 9 · ·

Jakmile terminál 2 přijme identifikátor aplikace 1' a parametr Y, přenese identifikátor aplikace I¹ a parametr Y na čipovou kartu 1^.

Krok 215 označuje, že čipová karta JL čeká na přijetí identifikátoru aplikace I' a parametru Y.

Jakmile čipová karta 1^ přijala identifikátor aplikace 1' a parametr Y, vyhledá položku s identifikátorem aplikace I^T v kroku 216.

Poté čipová karta 1. spočte hodnotu parametru X podle vzorce:

X := Dec (RND, C) Ks

Pokud se tajný kód C rovná tajnému kódu C', pak hodnota parametru X musí být rovna hodnotě parametru Y. Tato rovnost se testuje v kroku 218, kde se booiský parametr R spočte pomocí boolské operace X = Y?

V kroku 219 je boolská hodnota parametru R přenesena do terminálu 2.

Terminál 2 čeká v kroku 220 na přijetí parametru R. Jakmile je parametr R přijat, terminál 2 kontroluje v kroku 221, zda R = true. Pokud ne, terminál 2 vydá chybové hlášení v kroku 222, které může být pomocí vhodných zobrazovacích prostředků (nezobrazeno) vypsáno uživateli.

Pokud R = true, může začít fáze požadavku aplikace.

Ve fázi požadavku aplikace požaduje terminál 2 v kroku 223, aby čipová karta 1^ vygenerovala náhodné číslo RND.

Krok 224 označuje, že čipová karta čeká na takový požadavek.

Po přijetí zmíněného požadavku v kroku 225 generuje čipová karta 1. náhodné číslo RND, které je uloženo v kroku 226.

Poté v kroku 227 přenáší čipová karta j_ náhodné číslo RND do terminálu 2.

4«

- 15 Krok 228 označuje, že terminál 2 čeká na přijetí náhodného čísla RND.

Když se tak stalo, náhodné číslo RND je v kroku 229 přeneseno do bezpečného aplikačního modulu 3.

Krok 230 označuje, 2e bezpečný aplikační modul 3 čeká na přijetí náhodného čísla RND.

Poté, co terminál 2 přenesl náhodné číslo RND v kroku 229, začne terminál 2 v kroku 231 operaci zápisu zasláním požadavku k zápisu bezpečnému aplikačnímu modulu 3.

Krok 232 označuje, že bezpečný aplikační modul 3 čeká na takový požadavek k zápisu. Když se tak stalo, spočte v kroku 233 hodnotu parametru Y podle vzorce:

Y := MAC(RND,D,M)Ks

V je tedy získáno aplikací autentikačního kódu zprávy (MAC, message authentication code) na hodnoty náhodného čísla RND, dat D a paměťového místa M pomocí tajného klíče Ks.

V kroku 234 přenáší bezpečný aplikační modul 3 hodnotu Y do terminálu 2.

Krok 235 označuje, že terminál 2_ čeká na přijetí Y.

Když se tak stane, může začít provedení autorizovaného požadavku.

Fázi provedení autorizovaného požadavku začíná terminál 2 požadavkem k zápisu dat D na paměťové místo M na čipové kartě p při použití hodnoty Y. To označuje vztahové číslo 236.

V kroku 237 čipová karta čeká na přijetí takového požadavku k zápisu.

Když se tak stalo, čipová karta p spočte hodnotu parametru X podle vzorce:

X := MAC(RND,D,M)Ks

Pokud tedy byla řádně uložena hodnota klíče Ks jak na čipové kartě 1 tak i v bezpečném aplikačním modulu 3, X se musí « 99 99 9·9· «9 99

Μ * · ·· · · 9 9 · «*« · · 9 * · 9 9 « «99 « 9 9 9 9 999 99* « 999«· 9 9

999 9« 9* *9 99 9* rovnat Υ. Το je ověřeno v kroku 239, kde čipová karta spočte hodnotu boolského parametru R podle vztahu X = Y?

V kroku 24 0 zjišťuje čipová karta _1, zda je terminál 2_ oprávněn zapisovat data D na paměťové místo M při daných hodnotách přístupových práv A a tajného kódu C. Pokud ne, čipová karta _1 může v kroku 241 vygenerovat chybové hlášení, které může být zasláno terminálu 2 k vypsání na zobrazovacích prostředcích (nezobrazeno).

Pokud je terminál 2 oprávněn k zápisu, pak čipová karta 1 zapíše data D na paměťové místo M, jak je označeno v kroku 242.

V kroku 243 přenáší čipová karta JL hodnotu boolského parametru R do terminálu 2.

Krok 244 označuje, že terminál 2 čeká na přijetí boolského parametru R.

Když se tak stalo, terminál 2 vyhodnotí boolský parametr R v kroku 245, aby zjistil, zda byla operace zápisu řádně provedena .

Kroky 246, 247 a 248 označují konec zpracování na čipové kartě terminálu 2_ a bezpečném aplikačním modulu 3.

Ačkoli se obrázek 2 týká operace zápisu, bude odborníkovi v daném oboru zřejmé, že se jedná pouze o příklad. Operace čtení a další operace mohou být u dosavadního stavu techniky zpracovány stejným způsobem.

Z obrázku 2 tedy může být zřejmé, že u dosavadního stavu techniky obsahuje čipová karta 2 u autorizačních mechanizmů pro více aplikací tabulku pro každou jednotlivou aplikaci. Každá z těchto tabulek obsahuje identifikátor aplikace J, tajný kód C, odkaz na paměťové oblasti M, kde je aplikace uložena, a definici přístupových práv A volitelně spojenou s více než jedním příjemcem služby.

* · * ···· • ··· · · « 9 9 ··· 999 • · · « 9 · · · »« * · 9 9 9 « « · · ·

Na rozdíl od tohoto známého mechanizmu je autorizační mechanizmus pro více aplikací podle předkládaného vynálezu založen na adresářové a souborové struktuře v paměti čipové karty ý. Navíc podle předkládaného vynálezu nejsou tabulky přístupových práv uloženy na čipové kartě samotné, nýbrž v bezpečném aplikačním modulu, čímž dochází k úspoře paměťového prostoru čipové karty JL.

V praxi musí být v jednom bezpečném aplikačním modulu 2 implementována jak aplikace elektronické peněženky, tak i jedna nebo více jiných služeb. Tyto služby musí zřejmě být vzájemně odděleny.

Podle tohoto vynálezu se k zajištění služebních aplikací odlišných od stávající aplikace elektronické peněženky používá mechanizmus „služebních slotů“. Toto bude vysvětleno níže.

Obrázek 3 schematicky znázorňuje, že v rámci bezpečného aplikačního modulu 3 musí mechanizmus služebních slotů 1_ koexistovat se stávajícím mechanizmem elektronické peněženky (3. Jak mechanizmus služebních slotů Ί_ tak i mechanizmus elektronické peněženky _8 jsou implementovány pomocí generických prostředků bezpečného aplikačního modulu, jako jsou interní soubory a interní konečný automat.

Níže bude uveden příklad použití služebních slotů.

V tomto příkladu budou použity dříve uvedené definice, čímž budou dále objasněny.

Předpokládá se, že se v příkladu používají „generické“ služební sloty (což bude vysvětleno s odkazem na obrázek 4). Pokud je použita některá z výše uvedených definicí, je vytištěna kurzívou.

Místní nákupní středisko (poskytovatel služby) se rozhodne nabídnout svým častým návštěvníkům (držitelům karty) regionální věrnostní systém. Přáním střediska je, aby všichni pro18 « ·* ·9 9994 49 99

99<· · 9 · · 9 9 ·

9* 99 9 9999 • 999 9 4 « 99 »99 99»

99999 9 9 •9*99 «9 99 99 99 dejci (příjemci služby), kteří se zapojí do věrnostního systému, mohli bezpečně ukládat věrnostní body (služba 1) na čápovou kartu 1. Většina prodejců již přijímá čipovou kartu 1 k placení malých sum, čipová karta _1 tedy již slouží pro aplikaci elektronické peněženky. Představa je taková, že zákazník (držitel karty), který nasbíral 100 takových věrnostních bodů, je může u speciálního věrnostního terminálu 2 na určeném místě střediska vyměnit za věrnostní kupón (služba 2). Tento kupón pak může být pouze vyměněn za jistý produkt v obchodě u jistého prodejce.

Nákupní středisko se domluví s dodavatelem hardware a příslušným vystavitelem karty na tom, že k implementaci věrnostního systému (služební aplikace) budou použity dva „generické služební sloty“. Pro používáni čipové karty 1 ve věrnostním systému musí dodavatel hardware, jenž jev tomto případě rovněž dodavatelem aplikace, poskytnout bezpečným aplikačním modulům 3 zúčastněných prodejců potřebné parametry služby. Tyto potřebné parametry služby jsou nahrány do bezpečného aplikačního modulu ý během sběrné relace (viz obrázek 1), která je již dodavatelem hardware zajišťována. Proto musí mít dodavatel hardware k dispozici identifikátory bezpečných aplikačních modulů. Pomocí těchto parametrů služby mohou prodejci provádět jisté obslužné akce.

U normálních platebních terminálů 2 musí mít prodejce možnost zvýšit hodnotu věrnostního čítače na čipové kartě 1 a přijmout věrnostní kupóny uložené na čipové kartě (1. Prodejce však nesmí mít možnost snížit hodnotu čítače nebo vytvářet věrnostní kupóny. Jinými slovy, přístupová práva ke službě pro libovolného zúčastněného prodejce, t.j. libovolný terminál 2 musí být dobře definována. Při zvyšování hodnoty věrnostního

0» 00 0440 ♦· 0« «0 « 0 ·0 0 4 · 0 *

000 00 « 0 0 0 0 • til 40 0 00 4·· 000

40000 0 0 • 00 00 00 00 00 00 čítače nebo přijímání věrnostního kupónu prodejce ukládá na čipovou kartu 1 „razítko“ udávající místo poslední věrnostní transakce.

Při vytváření věrnostních bodů je věrnostní čítač v bezpečném aplikačním modulu 3 zúčastněného terminálu 2_ zvýšen o počet vytvořených bodů. Totéž se provádí při vytváření věrnostních kupónů na věrnostním terminálu. Hodnota těchto čítačů je rovněž shromažďována dodavatelem hardware během sběrné relace (viz obrázek 1) a poté distribuována centrálnímu systému střediska. Pro umožnění správy uspořených bodů pro každého držitele karty musí věrnostní systém používat záznamy věrnostních transakcí zpracovávané centrálním systémem, který může být implementován na osobním počítači. Pokud pak zákazník 5 ztratí nebo poškodí svou čipovou kartu _1, nákupní středisko může obnovit počet nasbíraných bodů na nové čipové kartě _1.

Pro omezení počtu bodů, které lze vydat, musí být každý platební terminál schopen vydat např. 10 000 věrnostních bodů. Prodejce musí rovněž zaplatit na centrální účet nákupního střediska stanovenou sumu peněz za každý bod, který plánuje vydat. Proto musí být bezpečný aplikační modul 3 příslušného terminálu 2 znovu naplněn 10 000 body pokaždé, když byly všechny body vydány (např. jednou za týden). Doplňování bezpečného aplikačního modulu _3 se provádí v rámci sběrné relace (viz obrázek 1) .

Po zařízení všeho uvedeného jsou prodejci schopni přijímat čipovou kartu 2 v rámci svého věrnostního systému. Pro to, aby se do věrnostního systému mohl zapojit zákazník 5, musí prodejce alokovat na jeho čipové kartě JL dva „generické služební sloty“. Jeden z těchto „generických služebních slotů“ se používá pro uchovávání bodů a druhý pro uchovávání kupónů. Pokud má zákazník 5 k dispozici dva volné služební sloty, může • v

autorizovat alokaci zadáním svého PIN. Zákazníkovo PIN je vyžadováno pouze pro alokaci slotů, nikoli pro uchováváni bodů nebo kupónů. Poté, co prodejce alokoval na čipové kartě 1^ dva sloty, zvýší se alokační čítač v bezpečném aplikačním modulu 3 o dva. Podle tohoto alokačního čítače účtuje dodavatel hardware nákupnímu středisku jistou sumu peněz. Během sběrné relace (viz obrázek 1) je tento alokační čítač bezpečným způsobem přečten.

V souladu s tímto vynálezem se typy služeb čipové karty (např. služba věrnostních bodů) nebo skupiny typů služeb uchovávají v jedné služební doméně, chráněné jednoznačným klíčem (jedna služební doména je jednou sadou souborů, tedy profilu, dat a doplňkového souboru), t.j. v jednom společném adresáři na čipové kartě JL. Tento adresář obsahuje několik „generických služebních slotů“. Každý z těchto „generických služebních slotů“ obsahuje data pro jednu služební aplikací. „Generické služební sloty“ se používají pro služby stejného typu (nebo stejné skupiny typů), pocházející od různých dodavatelů aplikací .

Každá služební doména je chráněna jednoznačnou sadou šifrovacích klíčů Ksl, Ks2, viz obrázek 4. Takto je každý z generických služebních slotů příslušících k aplikačnímu prostředí chráněn stejnými dvěma klíči Ksl a Ks2. K zamezení čteni a zápisu těchto generických služebních slotů neautorizovanými stranami a pro nutnost použití PIN při inicializaci generického služebního slotu musí být generický služební slot rozdělen na profilovou a datovou část. To je naznačeno na obrázku 4. Profilová část funguje jako autorizační mechanizmus pro každý z generických služebních slotů. Tento mechanizmus musí být vždy použit vedle kryptografické bezpečnostní architektury příslušného aplikačního prostředí (adresáře) .

Jak je uvedeno na obrázku 4, profilové částí přítomných generických služebních slotů jsou sdruženy v rámci prvního souboru. Navíc datové části přítomných generických služebních slotů jsou sdruženy v rámci odděleného druhého souboru.

Každý z generických služebních slotů může obsahovat doplňkovou datovou část pro ukládání doplňkových dat. Doplňkové datové části generických služebních slotu jsou sdruženy v rámci odděleného třetího souboru.

Každý generický služební slot i uvnitř aplikačního prostředí (adresáře) může být snadno vyhledán pomocí čísla záznamu RN (i). Pro libovolné i jsou profilová část, datová část i příslušná doplňková data uloženy ve stejných záznamech RN(i) třech různých souborů.

Profilová část může například obsahovat 20 bajtů. Pro každou aplikaci obsahuje příslušná profilová část jednoznačný identifikátor aplikace a návěští slotu. U přednostního provedení obsahuje profilová část generického služebního slotu údaj o době platnosti. Tato doba platnosti se týká data, kdy příslušná služba přestane pro danou čipovou kartu jL platit. Od toho dne je příslušný generický služební slot dostupný pro použití libovolnou jinou služební aplikací, t.j. data v daném generickém služebním slotu mohou být smazány a do daného generického služebního slotu může automaticky zapisovat jiná služba.

Datová část generického služebního slotu obsahuje data, jež závisí na typu služby, pro kterou se generický služební slot používá. Například data pro věrnostní systém budou jiná než data pro předplatné.

Doplňková datová část závisí na typu služby. Dává možnost uchování doplňkových dat v případě potřeby. Některé aplikace nevyžadují žádnou doplňkovou datovou část.

Podrobný popis struktury generického služebního slotu bude uveden později, s odkazem na obrázek 9.

Obrázek 5 zobrazuje alternativní strukturu aplikačního prostředí na čipové kartě 1. Takto alternativní struktura je použitelná, pokud si jediný dodavatel aplikací přeje zajišťovat různé typy služeb, např. věrnostní body, vstupenky, předplatné atd. V takovém případě by mohlo být použito několik generických služebních slotů, jak bylo vysvětleno s odkazem na obrázek 4. To by však mělo za následek 1) ztrátu výkonu v důsledku času vyžadovaného k přepínáni mezi aplikacemi a 2) ztrátu paměti v důsledku přítomnosti identických profilových částí. Proto musí být dodavateli aplikací rovněž umožněno použít různé typy služeb v rámci jednoho aplikačního prostředí.

Potřebné služební objekty pro tyto různé typy služeb budou pak uchovány v „dedikovaných služebních blocích“, jak je označeno na obrázku 5. Tyto dedikované služební sloty budou používány pouze pro služby různého typu, pocházející od jediného dodavatele aplikaci.

K používání takových dedikovaných služebních slotů stačí pouze jedna profilová část, protože všechny datové části jsou používány stejným dodavatelem aplikací. Jelikož však obsah dedikované profilové části je přímo spojen s jedním klíčovým prostředím (jednoho dodavatele aplikací), tato profilová část nemusí být kontrolována příslušným bezpečným aplikačním modulem _3·

V provedení podle obrázku 5 jsou tudíž nadále používány tři různé soubory (nebo dva soubory v případě, že doplňkové datové části jsou přebytečné). Soubor profilových částí však obsahuje pouze jedinou profilovou část a proto zabírá méně paměťových míst než v provedení podle obrázku 4.

Příkladem provedení podle obrázku 5 je situace, kdy jediná firma veřejné hromadné dopravy nabízí několik různých služeb a kdy jedna nebo více železničních firem a jedna nebo více autobusových firem funguje jako příjemce služby. Různé služby vázané na kartu se potom mohou týkat uchovávání železničních jízdenek, autobusových jízdenek, věrnostních bodů atd.

Zatímco služební sloty na kartě (obrázky 4 a 5) jsou seskupeny podle typu služby, služební sloty bezpečného aplikačního modulu jsou seskupeny podle dodavatele aplikace a uloženy v jednom jediném aplikačním prostředí bezpečného aplikačního modulu, t.j. v jednom společném adresáři v bezpečném aplikačním modulu. Například prodejce může poskytovat věrnostní body, věrnostní kupóny a věrnostní body za křížový prodej, zatímco jiná organizace může na téže čipové kartě 1_ nabízet elektronické vstupenky a elektronické předplatné. Bezpečný aplikační modul tohoto prodejce může umět zpracovávat pouze tyto věrnostní body, věrnostní kupóny a věrnostní body za křížový prodej. Bezpečný aplikační modul oné organizace může umět zpracovávat pouze elektronické vstupenky a elektronické předplatné. Proto je aplikační prostředí v bezpečném aplikačním modulu organizováno do jiných služebních slotů, jak je vidět na obrázku 6. Služební slot bezpečného aplikačního modulu sestává z definice aplikační služby, dvou aplikačních čítačů, služebního desetinného čísla (float), služebního pořadového čítače a přístupových práv ke službě pro daný terminál. Definice aplikační služby se používá k uchování jednoznačného identifikátoru služby a k určení typu služby. Aplikační čítače tvoří počítadlo alokací pro správu počtu alokací a počítadlo transakcí pro generování jednoznačného čísla transakce na záznamu. Služební desetinné číslo uchovává počet vydaných nebo

0

přijatých cenových jednotek, pokud jsou používány. Služební pořadový čítač generuje jednoznačné číslo objektu a uchovává počet vytvořených služebních objektů.

Práva ke službě musí vymezovat obslužné akce, které smí příslušný bezpečný aplikační modul provádět. Bezpečný aplikační modul může být například autorizován vydávat věrnostní body, t.j. zvyšovat věrnostní čítač na čipové kartě JL, nikoli však přijímat věrnostní body, t.j. snižovat věrnostní čítač. Práva ke službě zahrnují rovněž potřebné parametry pro používání interních proměnných bezpečného aplikačního modulu.

Pro přiřazení jisté služby služebnímu slotu bezpečného aplikačního modulu musí být do volného služebního slotu zavedeny parametry služby. Zavádění těchto parametrů bude chráněno jistým kryptografickým prostředkem, t.j. šifrovacím klíčem Ksam, jak je uvedeno na obrázcích 2 a 8.

Na požádání může být každému příjemci karet, jenž má smlouvu nebo dohodu s dodavatelem hardware, dodáno několik bezpečných aplikačních modulů. Obvykle je každý bezpečný aplikační modul vybaven alespoň službou elektronické peněženky a jednou nebo více dalšími službami zajišťovanými jedním nebo více dalšími dodavateli aplikací. Výběr služeb nabízených terminálem příjemce karet může být proveden během personalizace bezpečného aplikačního modulu, ale může být také proveden až po instalaci bezpečného aplikačního modulu u příjemce karet.

Jak je schematicky zobrazeno na obrázku 7, bezpečný aplikační modul 3 musí zajišťovat vrstvenou aplikační a bezpečnostní strukturu. Bezpečný aplikační modul 3 je dodáván dodavatelem hardware a používán autorizovaným příjemcem karet.

Přitom musí být splněny následující podmínky:

- každý bezpečný aplikační modul 3 musí podporovat aplikace dodávané jedním nebo více dodavateli aplikací, např. dodavatelem. aplikace elektronické peněženky,

- každá aplikace musí podporovat služby jednoho nebo více poskytovatelů služeb, kteří sdílejí jedno aplikační prostředí služby v bezpečném aplikačním modulu 3,

- každá služba bude používána jedním nebo více příjemci služby, kteří jsou autorizováni prostřednictvím stanovených práv ke službě.

Práce se služebními sloty

Pro využívání služebních slotů na kartě musí terminál zpracovat jak tyto služební sloty tak i aplikaci se služebními sloty v SAM. Nyní bude uveden popis možných obslužných akcí na profilové a datové části služebního slotu. Tyto obslužné akce mohou být rozděleny na profilové akce, které se provádějí na profilu slotu, a objektové akce prováděné na datové části.

Byly definovány následující profilové akce:

• alokuj služební slot (použitelné pouze pro generické služební sloty) • uvolni služební slot (použitelné pouze pro generické služební sloty) • zablokuj služební slot (použitelné pro oba typy slotů) • odblokuj služební slot (použitelné pro oba typy slotů) • modifikuj profil (použitelné pro oba typy slotů)

První dvě profilové akce se používají pouze pro generické služební sloty, zatímco poslední tří akce jsou použitelné jak pro dedikované služební sloty tak i pro generické služební

sloty. Pokud jsou poslední tři akce použity v dedikované aplikaci, může být vynecháno použití PIN.

Alokace služebního slotu

Pokud jíž byla inicializována aplikace se služebními sloty v SAM, terminál (t.j. SAM) by měl být schopen alokovat generický služební slot na čipové kartě. K tomu musí být dostupný volný služební slot a držitel karty musí správně zadat svůj PIN. V závislosti na přístupových právech pro aplikaci bude terminál schopen alokovat generický služební blok. K tomu je potřeba provést následující kroky:

1. ověření přístupových práv k aplikaci

2. ověření, že služební slot je volný

3. nalezení (čísla záznamu) volného služebního slotu na kartě

4. kontrola PIN uživatele

5. určeni doby platnosti generického služebního slotu

6. aktualizace alokačního čítače v SAM

7. inicializace profilu slotu (pomocí identifikátoru aplikace uloženého v SAM).

Uvolnění služebního slotu

Vedle alokace generického služebního slotu musí být rovněž možné generický služební slot uvolnit. To se provádí podobným mechanizmem jako při alokaci služebního slotu na kartě. Místo zavádění autorizačních parametrů však služební slot musí být přepsán jistým pevným nulovým vzorem (udávajícím, že slot je volně k dispozici). Pouze dodavatel aplikace alokovaného slotu může svůj slot uvolnit. Musí však existovat i možnost, aby libovolný dodavatel aplikace alokoval slot, jemuž vypršela doba platnosti. To by bylo možné, pokud by do SAM bylo bezpečně zavedeno datum sběru. Je k tomu potřeba provést následující kroky:

1. ověření přístupových práv k aplikaci ··♦

2. určení generického služebního slotu, jenž má být uvolněn

3. nalezení (čísla záznamu) (prošlého) služebního slotu na kartě

4. kontrola PIN uživatele

5. inicializace profilu slotu (pomocí pevného nulového vzoru).

Zablokování služebního slotu

Pomocí stavového bajtu uloženého v profilu slotu je možné zablokovat generický služební blok. Tuto možnost lze využít při provádění on-line relací k zajištění integrity aplikace (např. podobně jako při použití příznaku znovuzavedení - reload flag - v aplikaci elektronické peněženky na kartě).

Pokud byl generický služební slot zablokován, nemůže být znovu použit, dokud nebude opět odblokován. Je k tomu potřeba provést následující kroky:

1. ověření přístupových práv k aplikaci

2. určení generického služebního slotu, jenž má být zablokován

3. nalezení (čísla záznamu) služebního slotu na kartě

4. kontrola PIN uživatele

5. modifikace prvního bajtu profilu slotu (pomocí pevného blokovacího vzoru).

Odblokování služebního slotu

Pomocí této profilové akce je stavový bajt v profilu slotu nastaven znovu na nulu. Autorizace k provedení této akce závisí na přístupových právech uložených v SAM.

Když byl generický služební slot odblokován, může být znovu používán. Je k tomu potřeba provést následující kroky:

1. ověření přístupových práv k aplikaci

2. určení generického služebního slotu, jenž má být odblokován

3. nalezení (čísla záznamu) služebního slotu na kartě

4. kontrola PIN uživatele

Μ·

- 28 5. modifikace prvního bajtu profilu slotu (pomocí pevného odblokovacího vzoru).

Modifikace služebního slotu

Pomocí této obslužné akce může poskytovatel služby modifikovat nekritická data profilu slotu (např. posledních 11 bajtů). Tyto bajty by mohly být použity k uchování doplňkových dat, jako jsou profil zákazníka, návěští nebo jiné informace. Je k tomu potřeba provést následující kroky;

1. ověření přístupových práv k aplikaci

2. určení generického služebního slotu, jenž má být modifikován

3. nalezení (čísla záznamu) služebního slotu na kartě

4. kontrola PIN uživatele

5. modifikace nekritických dat profilu slotu, např. posledních 11 bajtů profilu slotu (pomocí libovolných dat).

Datová část generického či dedikovaného služebního slotu může být upravována pomocí několika objektových akcí v závislosti na příslušné službě (např. věrnostní body, vstupenky atd.). Bezpečný aplikační modul však vždy musí autorizovat požadované obslužné akce prostřednictvím určených přístupových práv ke službě. Byly definovány následující obslužné akce;

- vytvoř služební slot

- smaž služební slot

- zvyš služební slot

- sniž služební slot

- validuj služební slot

- označ služební slot

- verifikuj služební slot

- modifikuj doplňkovou datovou část •

Je vidět, že při vytváření nebo mazání služebního slotu může volitelně být vypuštěn krok 3 („nalezení volného služebního slotu “) , jak byl definován v odstavci týkajícím se alokace služebního slotu.

Dále budou s odkazem na obrázky 8a a 8b popsány příklady obslužných akcí na služebním slotu čipové karty 1. Obrázek 8a je použitelný pro následující obslužné akce: vytváření, mazání nebo modifikace služebního objektu, zatímco obrázek 8b je použitelný pro jednu z následujících obslužných akcí: zvyšování, snižování, validace nebo označování existujícího služebního objektu.

Obrázky 8a a 8b jsou předkládány ve formě vývojových diagramů zobrazujících akce, které mají být prováděny na čipové kartě 1, terminálu 2_ a bezpečném aplikačním modulu 3. Vývojové diagramy obrázku 8a i 8b jsou rozděleny na čtyři fáze: inicializace, požadavek a autorizace aplikace, požadavek a autorizace obslužné akce a provedení obslužné akce.

V inicializační fázi se na čipovou kartu zavedou dva klíče Ksl, Ks2. Tytéž klíče Ksl, Ks2 jsou zavedeny do bezpečného aplikačního modulu 3, do něhož se rovněž zavádí další klíč Ksam. Toto je znázorněno na řádku 801.

Čipová karta 1_ rovněž zapíše do své paměti pomocí klíče Ks2 aplikační kód C' a služební kód S', t.j. alokuje slot, řádek 802. Bezpečný aplikační modul J3 zapíše, jak je rovněž znázorněno na řádku 802, do své paměti pomocí klíče Ksam aplikační kód C a služební kód S, jakož i přístupové podmínky k aplikaci či službě A. Tím je inicializační fáze ukončena.

Fáze požadavku a autorizace aplikace začíná požadavkem terminálu 2_ k volbě profilu souboru na čipové kartě 1^ uvedené do komunikačního kontaktu s terminálem 2. Čipová karta 1 přijímá požadavek k volbě profilu souboru na řádku 803.

Řádek 804 označuje, že čipová karta p pokračuje volbou správného souboru.

Dalším krokem je, že terminál 2 žádá čipovou kartu 1 o vyhledání kódu aplikace Cj_ a kódu služby S ^T . Na řádku 805 je označeno, že čipová karta přijímá požadavek, zatímco na řádku 806 je označeno, že hledá kód aplikace C' a kód služby S¹.

Na řádku 807 je označeno, že čipová karta p odpovídá vrácením čísla záznamu RN' příslušného kódu aplikace C¹ a kódu služby sp. Toto číslo záznamu RN¹ je přijato terminálem 2 na řádku 807 a jeho platnost je zkontrolována na řádku 808.

Pokud je platnost čísla záznamu RN' v pořádku, pak na řádku 809 žádá terminál 2 bezpečný aplikační modul 3 o vygenerování náhodného čísla RNDl. Po přijetí požadavku (řádek 809) bezpečný aplikační modul p generuje požadované náhodné číslo RND1, řádek 810, a uloží je do své paměti, řádek 811.

Na řádku 812 vrací bezpečný aplikační modul p vygenerované náhodné číslo RND1 terminálu p, který je předává čipové kartě p.

Dalším krokem je, jak uvádí řádek 813, že terminál 2 žádá čipovou kartu p o čtení obsahu záznamu s číslem RN¹. Jak je rovněž uvedeno na řádku 813, požadavek je přijat čipovou kartou p.

Potom, na řádku 814, čipová karta spočte hodnotu parametru Y:

Y := MAC(RNDl,RN¹,C')Ksl

Hodnota Y je tedy spočtena aplikací autentikačního kódu zprávy (MAC) na hodnoty náhodného čísla RNDl, čísla záznamu RN' a kódu aplikace C' pomocí klíče Ksl.

Na řádku 815 čipová karta p přenáší kód aplikace C¹ a parametr Y do terminálu 2, který je přijímá, jak je rovněž uvedeno na řádku 815.

Na řádku 816 terminál 2 přenáší požadavek do bezpečného aplikačního modulu 3 k verifikaci hodnoty Y, prostřednictvím přenesení kódu aplikace C' , čísla záznamu RN' a parametru Y do bezpečného aplikačního modulu 3.

Po přijetí těchto parametrů (řádek 816) bezpečný aplikační modul 2 uloží na řádku 817 kód aplikace C' a číslo záznamu RN' .

Na řádku 818 bezpečný aplikační modul 3 spočte hodnotu boolského parametru R podle vzorce:

R := Bool (C'==C)

Na řádku 819 bezpečný aplikační modul 3 zkontroluje, zda R = true.

Pokud tomu tak je, bezpečný aplikační modul 3 spočte na řádku 820 hodnotu parametru X:

X := MAC(RND1,RN',C')Ksl

Hodnota X je tedy spočtena aplikací autentikačního kódu zprávy (MAC) na hodnoty náhodného čísla RND1, čísla záznamu RN' a kódu aplikace C¹ pomocí klíče Ksl. Parametr X je tedy spočten podobně jako parametr Y. Pokud jsou klíče Ksl stejné, musi být X rovno Y. To se testuje na řádcích 821 a 822, kde je nejdříve spočten boolský parametr R podle vzorce

R = Bool (X⁼—Y) a poté je otestováno, zda R - true.

Na řádku 823 je hodnota boolského parametru R přenesena do terminálu 2, kde je při přijetí zkontrolována.

Pokud je boolský parametr R = true, může začít další fáze, tedy požadavek a autorizace obslužné akce.

Na řádku 824 žádá terminál 2 čipovou kartu 1^ o volbu služebního souboru. Tento požadavek je přijat čipovou kartou 1_ rovněž na řádku 824.

Po přijetí požadavku vybírá na řádku 825 čipová karta 1_ správný soubor.

Poté terminál p požaduje na řádku 826 od čipové karty 1 vygenerování náhodného čísla RND2.

Požadavek je čipovou kartou p přijat na řádku 826. Po přijetí požadavku čipová karta 1 vygeneruje na řádku 827 náhodné číslo RND2 a uloží je na řádku 828.

Na řádku 829 je vygenerované náhodné číslo RND2 přeneseno do terminálu 2, jenž je předá bezpečnému aplikačnímu modulu 3, jak je rovněž označeno na řádku 829.

Potom se terminál 2 na řádku 830 dotazuje bezpečného aplikačního modulu p, zda je oprávněn provést jistou obslužnou akci, např. zápis, na čipové kartě p. Dotaz je přijat bezpečným aplikačním modulem p na řádku 830. Přijatý dotaz se vztahuje k zápisu dat D do záznamu s číslem RN¹ při daném kódu služby S¹.

Potom bezpečný aplikační modul 3 spočte v kroku 831 hodnotu boolského parametru R podle vzorce:

R := Bool (RN'==RN)

Na řádku 832 bezpečný aplikační modul 3 testuje, zda R = true. Když tomu tak je, je zřejmé, že se dotaz vztahuje ke správnému číslu záznamu RN.

Na řádku 833 bezpečný aplikační modul 3 spočte boolský parametr R podle vzorce:

R := Bool (S'==S)

Poté, na řádku 834, bezpečný aplikační modul p testuje, zda R = true. Když tomu tak je, je zřejmé, že se dotaz vztahuje ke správné službě.

Na řádku 835 bezpečný aplikační modul p spočte boolský parametr R podle vzorce:

R := authorize (WRITE,C,S,A)

Poté, na řádku 836, bezpečný aplikační modul p testuje, zda R = true. Když tomu tak je, pak je terminál autorizován

provádět obslužnou akci na záznamu s daným číslem RN na čipové kartě U jak bylo dotazováno.

Na řádku 8 3 7 bezpečný aplikační modul 3_ spočte hodnotu parametru X podle vzorce:

X := MAC(RND2,S,D,RN)Ks2

Hodnota X je tedy spočtena aplikací autentikačního kódu zprávy (MAC) na hodnoty parametrů (RND2, S, D a RN) pomocí klíče Ks2.

V kroku 838 je parametr X přenesen do terminálu 2. Terminál 2 přijímá parametr X na řádku 838 a kontroluje jeho platnost na řádku 839.

Po kontrole platnosti parametru X terminálem 2_ může začít fáze provedení obslužné akce.

Tato poslední fáze začíná požadavkem terminálu 2 k zápisu služebních dat D do záznamu číslo RN při daném kódu služby S a parametru X. Požadavek je na řádku 840 přijat čipovou kartou

1.

Po přijeti spočte čipová karta 1^ hodnotu parametru Y podle vzorce:

Y := MAC(RND2,S,D,RN)Ks2

Hodnota Y tedy musí být rovna hodnotě X, pokud jsou hodnoty klíče Ks2 uloženého na čipové kartě a v bezpečném aplikačním modulu 3 stejné.

Tato rovnost je testována na řádcích 842 a 843. Nejdříve je spočten boolský parametr R podle vzorce:

R := Bool (X==Y)

Potom, na řádku 819, čipová karta _1 zkontroluje, zda R = true.

Když tomu tak je, všechny provedené testy jsou pozitivní a čipová karta 1 může na řádku 844 načíst záznam číslo RN.

V « · · · ·

• «I · · ·

Na řádku 845 čipová karta zapisuje služební data D jakož i kód služby S do záznamu s číslem RN, t.j. provede požadovaný zápis.

Pro úspěšné ukončení obslužné akce přenáší čipová karta 1 na řádku 846 hodnotu boolského parametru R do terminálu 2.

Po přijetí boolského parametru R (řádek 846) terminál 2 testuje obsah boolského parametru R na řádku 847, aby se ujistil, že požadavek k zápisu přenášený na řádku 840 byl řádně proveden.

Ty kroky, jež jsou podstatné pro provedení obslužné akce zobrazené na obrázku 8a, jsou označeny obdélníkovým rámečkem. Použití náhodných čísel RND1 a RND2 je volitelné, podobně jako v dosavadním stavu techniky. V praxi se náhodná čísla používají vždy pro zamezení takzvaným „replay-attacks“, jak bylo vysvětleno s odkazem na obrázek 2.

Obrázek 8b obsahuje vývojový diagram se změnami vzhledem k diagramu z obrázku 8a. Vývojový diagram na obrázku 8b znázorňuje kroky při provádění jedné z následujících obslužných akcí: zvyšování, snižování, validaci a označování existujícího služebního objektu na čipové kartě JL.

Ty kroky na obrázku 8b, jež jsou totožné s kroky z obrázku 8a, jsou označeny stejnými čísly řádků. Jejich význam nebude znovu vysvětlován. Existuje pouze několik odlišných kroků ve fázi požadavku a autorizace obslužné akce, uvedených na řádcích 825a-825p a upravených řádcích 830a, 837a a 837b. Tyto budou dále vysvětleny.

Hlavní rozdíl mezi obslužnými akcemi z obrázku 8a (t.j. vytváření, mazání nebo modifikace služebního objektu) a z obrázku 8b (t.j. zvyšování, snižování, validace nebo označování služebního objektu) je v tom, že v prvním případě nemusí být verifikován stávající datový obsah služebního slotu v němž φ ·«· · · · 0 · <·· ··· « 0 0 0 *0 O ···· · V 00 00 0· bude prováděna obslužná akce, zatímco v druhém případě to potřebné je. Při provádění obslužných akcí podle obrázku 8b se mění pouze jistá část datového obsahu služebního objektu (tato datová část je na obrázku 8b označována „D.var“ zatímco zbylá část dat služebního objektu, která má zůstat stejná, je na obrázku 8b označena „D.fixed“) . Aby byl známý obsah této zbylé části dat D. fixed, je na čipové kartě 2 prováděna na řádcích 825a-825p bezpečná operace čtení.

Na obrázku 8b jsou ty kroky, jež jsou podstatné pro provedení obslužné akce, opět označeny obdélníkovým rámečkem.

Na řádku 825a obrázku 8b poté, co čipová karta vybrala správný soubor během fáze požadavku a autorizace obslužné akce, požaduje terminál 2, aby bezpečný aplikační modul 3 vygeneroval náhodné číslo RND3).

Na řádku 825a je rovněž zobrazeno, že bezpečný aplikační modul 3 přijímá tento požadavek.

Poté bezpečný aplikační modul 2 generuje náhodné číslo RND3 (řádek 825b) a ukládá je do své paměti (řádek 825c). Potom je náhodné číslo RND3 přeneseno na čipovou kartu 2 přes terminál 2, jak je uvedeno na řádku 825d.

Pak terminál 2 požaduje na řádku 825e, aby čipová karta 2 přečetla obsah záznamu číslo RN'.

Po přijetí požadavku (řádek 825e) čipová karta 2 spočte obsah parametru Y podle vzorce:

Y := MAC(RND3, Μ', S',D')Ksl

Hodnota Y je tedy spočtena aplikací autentikačního kódu zprávy (MAC) na hodnoty parametrů RND3, Μ¹, S¹, D' pomocí klíče Ksl. S' zde odkazuje na příslušný kód služby a D' odkazuje na obsah čteného záznamu RN'.

Na řádku 825g čipová karta 2 přenáší kód služby 5', data D’ a parametr Y do terminálu 2.

• ·

Na řádku 825h terminál 2 požaduje, aby bezpečný aplikační modul verifikoval obsah dat D¹ pro záznam číslo RN’.

Na řádku 825h bezpečný aplikační modul 3 přijímá kód služby S ’ , data D' , číslo záznamu RN' a parametr Y.

Na řádku 825i bezpečný aplikační modul spočte boolský parametr R podle vzorce:

R := Bool (S'==S)

Na řádku 825j bezpečný aplikační modul 2 testuje, zda

R = true,

Bezpečný aplikační modul 3 uloží do své paměti kód služby S', data D ¹ , číslo záznamu RN*, řádek 825k. Ty bity dat D¹ , jež mají zůstat nezměněny, t.j. D.fixed, jsou bezpečným aplikačním modulem 3 automaticky získány z dat D’ a uloženy v jeho paměti, řádek 8251.

Potom bezpečný aplikační modul spočte na řádku 825m parametr X podle vzorce:

X := MAC(RND3, S', D’, M')Ksl

Hodnota X je tedy spočtena aplikací autentikačního kódu zprávy (MAC) na hodnoty parametrů RND3, S’, D', M* pomocí klíče Ksl.

Pokud jsou klíče Ksl na čipové kartě 1 a v bezpečném aplikačním modulu 3 shodné, musí se shodovat hodnoty X a Y. Toto je testováno v krocích prováděných na řádcích 825n a 825o, kde je nejdříve spočten boolský parametr R podle vzorce:

R := Bool (X==Y) a poté otestováno, zda R = true.

Na řádku 825p je hodnota boolského parametru R přenesena do terminálu 2, kde je zkontrolován jeho obsah.

Takto je po provedení kroku uvedených na řádcích 825a825p ta část D.fixed dat D', jež má zůstat nezměněna, bezpečně ·« *· · · · ♦ ·· · · • »« « · · · * • · · 9 9 9 9 9

999 9 9 9 9 · *·· »·· • · · · 9 · 9

9 9 9 9 9 99 9 9 přečtena z čipové karty 1 a uložena v bezpečném aplikačním modulu 3_.

Fáze požadavku a autorizace obslužné akce obsahuje převážně tytéž kroky, jež jsou uvedeny na řádcích 826-828 obrázku 8a. Na řádku 830 však terminál požaduje od bezpečného aplikačního modulu pouze autorizaci k zápisu proměnné části D.var dat D v záznamu s číslem RN. Navíc kroku z řádku 837 na obrázku 8a, který byl na obrázku 8b přečíslován na řádek 837b, předchází ještě krok výpočtu dat D podle následujícího vzorce:

D := D’.fixed + D.var

Hodnota D.fixed dat D se tedy rovná neměnné části D' . f ixed předchozích dat D', jelikož tato byla předtím přečtena v krocích prováděných na řádcích 825a-825b a poté byla zahrnuta do nových dat D používaných ve fázi provedení obslužné akce zobrazené na řádcích 840-847.

Při srovnání vývojových diagramů na obrázcích 2, 8a a 8b je vidět následující rozdíly mezi dosavadním stavem techniky, kdy se nepoužívají adresáře a soubory, a předkládaným vynálezem:

- čipová karta .1 neobsahuje žádné tabulky s identifikátory aplikací či hesly, přístupovými právy a ukazateli do paměťových oblastí,

- přístupová práva k aplikaci A jsou uložena v bezpečném aplikačním modulu 3,

- na čipové kartě se využívají dva klíče Ksl a Ks2, zatímco v bezpečném aplikačním modulu 3 jsou uloženy tři klíče Ksl, Ks2 a Ksam,

- na čipové kartě 1_ se pro podporu bezpečnostní architektury používají adresářové a souborové struktury, ··

- v rámci souborové struktury se používají záznamy a čísla záznamů k vytvoření bezpečnostní architektury na úrovní různých služeb a poskytovatelů služeb,

- kontrola, zda terminál 2 je oprávněn provádět jistou obslužnou akci na čipové kartě 1, se provádí v bezpečném aplikačním modulu 3, a nikoli na čipové kartě ý, čímž na ní dochází k úspoře paměťového prostoru.

Obrázek 9 přesně znázorňuje jednu možnou strukturu služebního slotu. Služební slot je rozdělen na tři části: soubor 1, soubor 2 a soubor 3 (volitelně). Soubor 1 obsahuje profil služebního slotu a zahrnuje stav, kód aplikace, dobu platnosti, návěští aplikace (text) a několik volných bitů. Tyto volné bity mohou být použity např. pro další data poskytovatele služby.

Soubor 2 obsahuje data služebního slotu a zahrnuje hodnotu (např. cenu vstupenky nebo věrnostní čítač) , validitu, kód služby a několik volných bitů. Tyto volné bity se používají k označení, zda je služební objekt nadále platný, např. zda kupón nebo vstupenka mohou být nadále využívány.

Jelikož obslužné akce vytváření, validace a označování smějí změnit pouze proměnnou část D.var dat D, volné bity souboru 2 služebního objektu jsou rozděleny na části pro vytváření, validaci a označování. Do části pro vytváření se zapisuje jednou při vytváření objektu, do části pro validaci se zapisuje v omezeném počtu případů v závislosti na čítači validity, zatímco do označovací části se může psát bez omezení.

Soubor 3 obsahuje předem daný počet volných bitů, sloužících k uložení doplňkových dat služebního slotu.

V alternativním provedení vynálezu se řeší možnost dočasného uchování dat služebního slotu čipové karty v paměti třetí strany. Třetí stranou může být poskytovatel služby, ale pří·· 4·44 • ·* • · ·

4 » 4 4 4 4 4 • · 4 4 4 4 ««4 44 *· 44 ••4 ·44

4 · 4 pádně i banka, notář či vystavitel karty. Taková možnost může být užitečná, pokud například držitel karty zakoupí vstupenku na koncert několik měsíců před samotným koncertem a nechce o tuto vstupenku přijít.

Uchování dat služebního slotu čipové karty v paměti třetí strany musí být realizováno bezpečně.

K realizaci takové dočasné úschovy může třetí strana využít funkcionalitu standardního služebního slotu, avšak bez omezení daného jednoznačným identifikátorem aplikace uloženým v definiční části a identifikátorem služby uloženým v datové části. Třetí strana musí být vybavena bezpečným aplikačním modulem uspořádaným ke čtení dat (t.j. definice slotu, dat slotu a doplňkových dat slotu), k verifikaci služebního slotu a k zápisu dat (vytvoření služebního slotu a smazání služebního slotu).

Pro takovou doplňkovou službu musí být provedeny následující kroky.

Příslušná data musí být bezpečně přečtena z příslušné čipové karty, což zahrnuje následující podkroky:

- čtení ID čipové karty,

- volba služebního bloku vztahujícího se k ID čipové karty,

- čtení a verifikace dat služebního slotu, definice služebního slotu a doplňkových dat služebního slotu, pokud jsou použita,

- uložení orazítkovaného MAC a náhodného čísla z definice služebního slotu a dat služebního slotu k zajištění toho, aby držitel karty mohl mimo jiné dokázat, že příslušný služební slot karty obsahoval data, jež měla být dočasně uložena v paměti třetí strany, kde v roli náhodného čísla lze použít časové razítko,

9 · 9	• ·	•	·· * · ·
i ···	4 · Í	• ·	<4 ·
• ·	• 9	• ·	•
1« ··	«*		« t

- bezpečné uložení ID, definice služebního slotu, dat služebního slotu a doplňkových dat služebního slotu, pokud jsou přítomna, do paměti třetí strany,

- smazání služebního slotu a uvolnění definice služebního slotu na čipové kartě.

Když si držitel karty přeje, aby jeho data byla přenesena zpět z paměti třetí strany na jeho kartu, musí být provedeny následující kroky:

- ověření PIN uživatele, pokud je vyžadováno,

- ověření, zda data v paměti třetí strany byla přečtená z příslušné čipové karty, pomocí testu, zda se uložené ID rovná ID čipové karty,

- volba volného služebního slotu,

- alokace volného služebního slotu s definicí služebního slotu

- zápis dat služebního slotu a případně doplňkových dat služebního slotu do zvoleného volného služebního slotu (vytvoř služební slot, případně modifikuj služební slot), a

- smazání obsahu paměti třetí strany.

V dalším alternativním provedení je místo přenosu obsahu služebního slotu do paměti třetí strany možné uzamknout služební slot na čipové kartě samotné. Toto může být provedeno pomocí zařízení Tele-Chipper® nebo přes Internet, např. změnou obsahu jednoho bitu v definicí služebního slotu. Poté by použití tohoto služebního slotu bylo dočasně zablokováno, např. do doby, než se koncert bude skutečně konat.

PATENTOVÉ NÁROKY

Claims (13)

1. Čipová karta (1) vybavená paměťovými prostředky k uchování služebních dat vztahujících se k alespoň jedné službě, vyznačující se tím, že alespoň část uvedených paměťových prostředku obsahuje služební data v souborových strukturách v rámci jednoho adresáře obsahujícího první soubor a druhý soubor, přičemž služební data jsou seskupena do služebních slotů a každý služební slot je rozdělen na profilovou část a datovou část, kdy každá profilová část má číslo slotu (RN(i)), je uložena v uvedeném prvním souboru a obsahuje jednoznačný identifikátor aplikace, a každá datová část je uložena v uvedeném druhém souboru a obsahuje data vztahující se k službě, přičemž uvedené paměťové prostředky uchovávají alespoň jeden klíč (Ks2), jenž chrání přístup k zápisu do uvedeného prvního a druhého souboru.

2. Čipová karta (1) podle nároku 1, vyznačující se t í m , že alespoň jedna profilová část obsahuje rovněž data týkající se doby platnosti příslušného služebního slotu.

3. Čipová karta (1) podle kteréhokoli z nároků 1 a 2, vyznačující se tím, že alespoň jedna profilové část rovněž obsahuje data týkající se stavu aplikace.

4. Čipová karta (1} podle kteréhokoli z předchozích nároků, vyznačující se tím, že každý služební slot obsahuje vlastní profilovou část a vlastní datovou část, kdy každá profilová část je implementována jako záznam v uvedeném prvním souboru a každá datová část je implementována jako záznam v uvedeném druhém souboru, přičemž paměťové prostředky uchovávají další klíč (Ksl) k ochraně přístupu k uvedenému prvnímu souboru.

5. Čipová karta (1) podle kteréhokoli z nároků 1 až 3, vyznačující se tím, že implementované služební sloty sdílejí jednu společnou profilovou část, ale každý služební slot obsahuje vlastní datovou část, přičemž uvedená profilová část je implementována jako jeden záznam v uvedeném prvním souboru a datové části jsou implementovány jako oddělené záznamy v uvedeném druhém souboru.

6. Čipová karta (1) podle kteréhokoli z předchozích nároků, vyznačující se tím, že uvedený adresář rovněž obsahuje třetí soubor a alespoň jeden služební slot obsahuje doplňkovou datovou část v uvedeném třetím souboru k uchování doplňkových dat.

7. Čipová karta (1) podle nároku 6, vyznačující se t í m , že alespoň jedna doplňková datová část je implementována jako záznam.

8. Bezpečný aplikační modul (3) vybavený pro komunikaci s čápovou kartou podle kteréhokoli z nároků 1 až 7, opatřený paměťovými prostředky k uchování služebních dat týkajících se alespoň jedné služby, vyznačující se tím, že alespoň část uvedených paměťových prostředků obsahuje služební data v souborových strukturách v rámci jednoho adresáře, kdy uvedený adresář obsahuje alespoň jeden soubor a tento soubor uchovává služební data týkající se jedné jediné služby, sdružená do:

- definičních dat aplikace/služby, jež obsahují jednoznačný identifikátor služby a údaj o typu služby,

- nejméně dvou aplikačních čítačů pro správu počtu alokací a pro generování jednoznačného čísla transakce na záznamu, « * · ·

- 43 - služebního pořadového čítače pro generování jednoznačného čísla objektu a správu počtu vytvořených služebních objektů,

- desetinného čísla pro správu počtu buďto vydaných nebo přijatých cenových jednotek a

- dat týkajících se přístupových práv (A), která definuji obslužné akce, jež mohou provádět jednotlivé terminály (2) , a tím, že uvedené paměťové prostředky zahrnují alespoň první klíč (Ks2) a druhý klíč (Ksam) k ochraně jakékoli datové komunikace s čipovou kartou.

9. Bezpečný aplikační modul (3) podle nároku 8, vyznačující se tím, že uvedené paměťové prostředky uchovávají třetí klíč (Ksl) k ochraně jakékoli datové komunikace s čipovou kartou.

10. Systém obsahující bezpečný aplikační modul (3) podle nároků 8 až 9 a alespoň jeden terminál (2) spojený s uvedeným bezpečným aplikačním modulem, vyznačující se tím, že uvedený terminál (2) je vybaven pro komunikaci s uvedeným bezpečným aplikačním modulem a s alespoň jednou čipovou kartou (1) podle kteréhokoli z nároků 1 až 7 za účelem řízení obslužné akce prováděné na uvedené alespoň jedné čipové kartě.

11. Způsob pro řízení obslužné akce prováděné terminálem (2) na čipové kartě (1) podle kteréhokoli z nároků 1 až 7, přičemž uvedený terminál (2) je spojený jak s bezpečným aplikačním modulem (3) podle kteréhokoli z nároků 8 až 9 tak i s uvedenou čipovou kartou (1), zahrnující následující kroky

a) zjištění, zda uvedený terminál (2) je oprávněn provádět uvedenou obslužnou akci na uvedené čipové kartě (1) pomocí alespoň jednoho kódu (C, S) a alespoň jednoho tajné« *

- 44 ho klíče (Ks2), kde jak uvedený kód (C, S) tak i uvedený klíč (Ks2) jsou uloženy i na uvedené čipové kartě (1) i v uvedeném bezpečném aplikačním modulu (3) a pomocí ověření stanovených přístupových práv (A) a

b) provedení uvedené obslužné akce na uvedené čipové kartě (1) ,

c) ověření kroku b) na uvedeném terminálu (2), vyznačující se tím, že:

uvedené ověření stanovených přístupových práv (A) v kroku a) (kroky na řádcích 831-836) je provedeno v uvedeném bezpečném aplikačním modulu (3) pomocí uvedených dat týkajících se přístupových práv (A) uložených v uvedeném bezpečném aplikačním modulu (3) a pomocí uvedeného alespoň jednoho kódu (C, S).

12. Způsob podle nároku 11, vyznačující se tím, že ověření stanovených přístupových práv (A) v rámci kroku a) předchází následující krok: čtení služebních dat (D) ze služebního slotu a uložení stanovené datové části (D.fixed), jež má zůstat nezměněna, v uvedeném bezpečném aplikačním modulu (3) , a dále tím, že krok b) je prováděn beze změny uvedené stanovené datové části (D.fixed) uvedených dat (D) na uvedené čipové kartě (1).

13. Způsob podle kteréhokoli z nároků 11 až 12, vyznačující se tím, že obslužná akce obsahuje bezpečné čtení z čipové karty, které zahrnuje následující podkroky:

- čtení ID čipové karty,

- volba služebního bloku vztahujícího se k ID čipové