7. Architektura SIM karet pro systém GSM

Čipová karta označovaná SIM (Subscriber Identity Module) tvoří jeden ze základních pilířů, na kterých je vystavěna flexibilita a zároveň bezpečnost mobilních datových zařízení v síti GSM. Zmíněná flexibilita spočívá zejména v tom, že veškeré informace o daném uživateli, nutné pro jeho práci v síti GSM, jsou uloženy právě v SIM. Konkrétní uživatel se může chovat flexibilně v tom smyslu, že má možnost používat jakékoliv GSM zařízení, do kterého vloží svůj modul SIM, přičemž jeho identita v dané síti bude stále tatáž. Na tuto výhodu ovšem zcela logicky navazuje požadavek zvýšené bezpečnosti, který má za úkol zabránit zejména padělání SIM a tím vytváření falešných či duplicitních identit. Technicky vzato je SIM mikroprocesorem řízená čipová karta (tedy "pravá" smartcard), jejíž základní charakteristiky podléhají normě ISO 7816. Pro úplnost dodejme, že většina karet komunikuje protokolem T=1 (asynchronní blokově orientovaný poloduplex) což ve většině případů znamená, že podporuje i protokol T=0, který jsme si popsali.
Pokud jde o konkrétní způsob realizace daného modulu SIM, panuje zde poměrně značná volnost. Obecně je ve specifikaci GSM uvedeno pouze to, že má jít o procesorem (osmi nebo šestnáctibitovým) řízenou kartu, pracující minimálně do frekvence 5 MHz, vybavenou dvěma až osmi kilobajty EEPROM, třemi až deseti kilobajty ROM a s kapacitou RAM 128 až 256 bajtů. Pro spolehlivou činnost by kartě mělo stačit napájecí napětí 4,75 až 5,25 voltu s maximálním odběrem pod 10 miliampérů. Potud tedy technická definice nutná spolu s protokolem ISO 7816 pro kompatibilitu mobilních zařízení a modulů SIM od různých výrobců. Malinko bližší specifikace podává snad jen ještě fakt, zda je daný modul určen pro fázi I, nebo pro fázi II. Rozdíl mezi nimi přitom spočívá zejména v kapacitě paměti EEPROM a také v základní adresářové struktuře. Fáze II (aktuální stadium) je například na rozdíl od své předchůdkyně schopna ukládat SMS zprávy. Vzhledem k tomu, že fáze I se dnes už prakticky nepoužívá, budeme se v dalším výkladu věnovat výhradně fázi II.
Podobná situace je i v případě operačního systému těchto karet. Zde je opět definována pouze základní množina příkazů, kterým musí daný SIM rozumět, aby bylo možné jeho použití v ME (takto budeme dále označovat mobilní zařízení, pracující nad SIM modulem) od různých výrobců. Konkrétní architektura použitého operačního systému a způsob jeho implementace už opět plně závisí na výrobci. Přehled základních funkcí udává následující tabulka:
 
Zaměření Příkazy
Práce se soubory Select, Read, Write, Update, Create, Delete, Extend, Increase, Invalidate, Rehabilitate, Seek
Autentizace VerifyCHV, ChangeCHV, DisableCHV, EnableCHV, UnblockCHV, External Auth, Internal Auth, Get Random
Přímý přístup do systémových oblastí Put Data, Get Data
Obecné Sleep, Switch Proto, Status, Get Response

Sekvence Answer-to-Reset

K této oblasti neexistuje pro tisk dostupná dokumentace, takže se bude vycházet z náhodně vybraného a změřeného vzorku. Z tabulky zachycené ATR sekvence je možné vyčíst tyto údaje:
 
Jméno kódu Hodnota/Význam
TS 0x3F - inverzní kódování
T0 0x2F - TB1 přítomen a následován T1… T15
TB1 0x00 - není třeba externí Vpp
T1… T15 0x80 0x69 0xaf 0x02 0x01 0x01 0x35 0x00 0x1 0x0a 0x0e 0x83 0x1e 0x9f 0x16

měřený SIM používal interní kódování, nepotřeboval zdroj Vpp (vyráběl si jej sám) a za hlavičkou ATR je přenášeno celkem 15 historářových znaků. Popis pole T1 až T15 je samozřejmě nedokumentován, takže se můžeme pouze domnívat, že zde budou uloženy hodnoty typu aktuální stav karty, kód výrobce atd. Zajímavé na této kartě též je, že umí pouze protokol T=0 (TDi chybí, tudíž T=0 je jediný a implicitní). Odchycenou sekvenci a absenci protokolu T=1 můžeme brát jako ukázkový příklad toho, že tam, kde není normou pro GSM stanoveno jinak, mohou se mezi SIM od různých výrobců projevovat značné rozdíly.

Systém souborů

Aplikaci musíme chápat ve světě čipových karet trochu jinak než ve světě „velkých" počítačů. Ačkoliv je v zásadě možné přidávat na kartu vlastní systémové programy, není toto to hlavní, co obvykle tvoří celou aplikaci. Jádrem aplikací ve světě čipových karet je totiž návrh adresářové a souborové struktury, způsob definice přístupových práv, umístění souborů s klíči a konečně definice vzájemných interakcí mezi právě zmíněnými entitami. Tato definice, která, myslím, přesně vystihuje většinu aplikací, se opírá zejména o hlavní myšlenku čipových karet – o filozofii zabezpečeného nosiče důvěrných informací různého stupně utajení. A nyní už k vlastním souborům.
Stejně jako u ostatních karet tohoto typu, i zde je možné ukládat data do souborového systému velice podobného tomu, který známe z osobních počítačů. Platí zde však omezení, které říká, že hloubka vnoření adresářů může být nejvýše jedna. Jak už bylo zmíněno, soubory se v čip. kartách neoznačují jménem, ale čísly. V případě SIM karet je číslo dvoubajtové a podléhá následujícím konvencím: 3F 00 označuje hlavní (kořenový) adresář, 7F XX označuje podadresář hlavního adresáře (může být tedy nejvýše 255 podadresářů), 2F XX je označení pro soubor (dále EF – Elementary File) v hlavním adresáři a konečně 6F XX označuje EF umístěný v některém z podadresářů. Kromě těchto čísel jsou ještě vyhrazena čísla, jejichž horní bajt není roven ani jedné z právě vyjmenovaných hodnot. Jejich jména a umístění v daných aplikacích však většinou nenajdeme, neboť jde o soubory velice úzce související s bezpečností.
Systém obsahuje několik typů souborů. Základním typem je takzvaný transparentní EF, což je v podstatě klasický lineární soubor s náhodným přístupem, tak jak jej známe třeba z MS-DOS. Druhý typ tvoří soubor nazývaný lineární soubor konstantní délky. Přesnější označení by asi bylo s konstantním přírůstkem, neboť data v tomto souboru jsou organizována do záznamů konstantní délky; záznamy jsou číslovány a jejich maximální počet a velikost nesmí přesáhnout hranici 255. Nad strukturou těchto souborů je definováno rozšíření standardních čtecích a zapisovacích funkcí tak, aby byly schopny jednak absolutní adresace po jednotlivých záznamech, jednak relativního pohybu v daném záznamovém řetězci. Posledním typem EF souborů je takzvaný cyklický soubor, jehož architektura je velice podobná tomu předcházejícímu s tím rozdílem, že zde tvoří všechny záznamy cyklický seznam. Platí, že zápis do souboru je vždy prováděn do nejstaršího záznamu, který po této operaci získá číslo jedna (čísla ostatních se "posunou"). Z toho vyplývá, že "nejčerstvější" záznam v souboru má vždy číslo jedna a nejstarší potom číslo n (n je počet záznamů v souboru) a stáří ostatních je úměrné jejich pořadí. Ačkoliv tento typ souboru vypadá na první pohled dost podivně, existuje v GSM řada oblastí, kterým je jeho struktura doslova ušita na míru. Za všechny jmenujme třeba způsob ukládání SMS zpráv.
Vlastní způsob práce se soubory je opět velice podobný tomu, který je zaváděn ve známých operačních systémech "normálních" počítačů. Jediný rozdíl je v tom, že zde nejsou deskriptory souboru, a tak není možné pracovat s více soubory najednou. Vlastní sémantika funkcí typu Read/Write a Update je taková, že operace vždy pracují s tím souborem, který byl naposled vybrán příkazem Select. Tento příkaz slouží též k otvírání adresářů. Pokud tedy budeme chtít přečíst třeba osm bajtů od offsetu nula ze souboru 6F 20 z adresáře 7F 20, potom použijeme následující sekvenci příkazů: Select (7F20), Select (6F20) a Read (0, 8). Za zmínku též stojí způsob, jakým zde pracuje funkce Write, respektive Update. Vzhledem k tomu, že tyto operace neumožňují měnit velikost daného souboru (na to jsou speciální funkce), je vždy možný pouze zápis na datové pozice "uvnitř" souboru. Přitom platí, že funkce Write provádí při zápisu logickou funkci OR mezi novým a starým obsahem dané buňky, zatímco Update umožňuje daná data v souboru přepsat "natvrdo" – tj. původní obsah je nahrazen novým. Důvodů k zavedení těchto dvou funkcí, které mimo jiné nalezneme též u mnoha ostatních karet tohoto typu, je celá řada. Jeden z nich můžeme najít třeba v implementaci přístupových práv, kdy rozdílná práva pro Write, respektive Update, mohou být za jistých okolností užitečná. Z čistě technického hlediska potom plyne, že operace Write je k použitému paměťovému médiu (zde EEPROM) mnohem šetrnější, neboť nevyžaduje přemazání dané buňky před vlastním zápisem (samozřejmě při dobře navržené architektuře).
Kromě výše zmíněných příkazů pro manipulaci s daty existují ještě operace pracující se soubory jako takovými – tedy známé Delete, Create, Extend atd. Dále je možné kompletně zneplatnit, či obráceně zase obnovit obsah celého souboru. Přehled všech těchto funkcí najdete v přiložené tabulce. Bohužel není možné publikovat jejich kódy a sémantiku v protokolu T=0, takže nám musí postačit alespoň jejich názvy.
 

Bezpečnost souborů

Při vytváření daného EF souboru či adresáře (ty se označují jako DF – Dedicated File) je možné specifikovat přístupová práva, která musí terminál (ME) získat, aby mohl požadovanou operaci s daným souborem provést.
Přehled práv poskytuje tato tabulka:
 
Kód úrovně  Typ práva (požadavku)
0 ALWAYS
15 NEVER
1, 2 CHV1, CHV2
4 Ext. AUT
8, 9 CHV1/Ext. AUT, CHV2/Ext. AUT
11, 12, 13, 14 ADM1, ADM2, ADM3, ADM4
3, 5, 6, 7, 10 RFU

Položky RFU (Reserved for Future Use) jsou pro nás v tuto chvíli nezajímavé. Dále jsou zde triviální případy typu Always/Never, kdy je daná operace přístupná buď vždy, anebo je zcela zakázána. Mezi těmito dvěma extrémy se potom pohybují ostatní typy přístupových práv, které znamenají toto: CHV1 či CHV2 říká, že ME musí znát PIN uložené v souboru CHV1 či CHV2. Totéž musí být splněno v případě práv ADM1-4 s tím rozdílem, že zde je příslušné PIN uloženo v souboru ADM 1, 2, 3 anebo 4. Velice zajímavá metoda přístupu je AUT, která předepisuje, že ME musí nejdříve projít procedurou externí autentizace (viz dále). Tuto autentizaci je dále možné kombinovat ještě se znalostí příslušného PIN, což umožňují práva typu CHVx/AUT. Zkoumáním jednotlivých přístupových požadavků (v tomto případě možná přesnější výraz pro termín "práv") bychom se dostali spíš už do oblasti kryptografie, takže tuhle oblast opustíme.
 

<-- <- ^ -> -->


Semestrální projekt z Číslicových počítačů II.
Autoři: Lumír Návrat, Jakub Konštacký, Zdeněk Šmíd, Pavel Oplatek